From nobody Thu Dec 1 10:41:11 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F639129868 for ; Thu, 1 Dec 2016 10:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVjOQv17LxSg for ; Thu, 1 Dec 2016 10:40:59 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E26F12986C for ; Thu, 1 Dec 2016 10:40:59 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id x190so254543608qkb.0 for ; Thu, 01 Dec 2016 10:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KrtM5WXjsC0fpwH0neSXH+lhBpL/zl00hrsDiycyKfY=; b=jiyHsm1yv10HZyU7BIAPCrS/p6sNVKz2HLQmsXSA4YMoE2KtBXoAJuNWK+DKR750Mk sa2f1zINYse5KBWyj8PLZbfLo6um/Ewh2vW/6wV9NCSIbX3R0wdN4Dx9em2YqnkSsIPK w7VdrgaFiqM/c0B+D1DL/ZkYg6Rg3VLeMVb9RqUulrskAH36xNpUbmnAPqpYvdOPj2EL mpOYhWAvKDy5BCPsLfybW92LS+zBzul8aQ2rGTYgPebb3EoKNwTcBHHpfrGaGCXmLO1b /sx5CvGXyPCzZgfGRnoNa0RFWHuXQvuuznP4qrrs8cKSiJ7KBKRxITwEEqzYee5rQWHP 7iCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KrtM5WXjsC0fpwH0neSXH+lhBpL/zl00hrsDiycyKfY=; b=OyDCkEI62aiMwXraIsqlc1KT2pKm0xdGnfylO9Kp4oFDCt4jA7a3gwRbwYvk592xLD ZgCOm7Vl8/KSZocZaOdN8ekxQFL3ffekKDpsy0A4Y3JGRyEXYaggHIN/HE5Lft3wJP7V 9E5QrMmwJ+HsjNmthwI0LAPmF/2JSIe3CUXNeXy9htw3zSRtD1Ppm51AI3SJVKj7+jZj gUP7+7GhN95iIBsb1vWRtuX+Cn6XVi+O8g1eINBBMVUg6PPVePeWNYhn30kYnYDvbXRu 9hZlFIiX52U2hzLIooiJMk/i8nqbwrwZVx6Y+0gZO9ARLIjkV3ngwyymGdsMBoyZO1JO 8xNA== X-Gm-Message-State: AKaTC03X4Wksj2ytbX1yKAPPVIkmGZ4yI9NZQYZ+1Ned7qTUTAPAm/tGEFNtfQxFhqweYqGDznQBKmk512KsFw== X-Received: by 10.55.152.4 with SMTP id a4mr33335898qke.69.1480617658252; Thu, 01 Dec 2016 10:40:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Thu, 1 Dec 2016 10:40:57 -0800 (PST) In-Reply-To: <538c1bd0cc1445059350d7f43f272af1@XCH-RTP-013.cisco.com> References: <538c1bd0cc1445059350d7f43f272af1@XCH-RTP-013.cisco.com> From: Andy Bierman Date: Thu, 1 Dec 2016 10:40:57 -0800 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/mixed; boundary=94eb2c07ecfa9217a205429d2979 Archived-At: Cc: "netconf@ietf.org" , "alex@clemm.org" Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 18:41:05 -0000 --94eb2c07ecfa9217a205429d2979 Content-Type: multipart/alternative; boundary=94eb2c07ecfa92179f05429d2977 --94eb2c07ecfa92179f05429d2977 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I worked on the filtering problem a bit more. Here is filter.yang, a filtering framework, and topic.yang, and example of a filter type that can be used in filter.yang. Topic-based filtering was briefly discussed in Seoul. IMO filters will continue to evolve over time so the solution needs to allo= w them to be added and combined with other filters. The current YANG choice-stmt is not extensible enough or powerful enough. Andy On Tue, Nov 29, 2016 at 7:11 PM, Eric Voit (evoit) wrote: > *From:* Andy Bierman, November 29, 2016 8:30 PM > > On Tue, Nov 29, 2016 at 8:05 AM, Eric Voit (evoit) > wrote: > > Thanks Martin, > > More in line. Also I extracted areas where we already agree to make thi= s > easier to follow. > > > From: Martin Bjorklund, November 29, 2016 6:40 AM > > > >If I understand the intention correctly, this document is supposed t= o > > > >*define* how notifications are sent over NETCONF. But there is no > > > >such definition in this document. Instead it simply repeats > > > >information already defined in draft-ietf-netconf-rfc5277bis-01.txt, > > > >and provides lots of examples of how the YANG operations defined in > > > >rfc5277bis are encoded in XML and sent over NETCONF. > > > > > > > >I suggest that this document is rewritten. Since the idea is to > > > >replace RFC 5277, it needs to focus on how notifications are sent > > > >over NETCONF, and not how RPCs are encoded in XML. > > > I agree -- maybe get rid of it and just have rfc5277bis contain this > > > text > > > > > > 5277bis is supposed to allow transports other than NETCONF. If > we put > > the NETCONF specific stuff in here we lose that separation. > > > > We need *some* document that defines how notifications are sent over > > NETCONF. This document needs to have the specification for the > > > element. > > > > Then we need a protocol-independent document that defines the concept o= f > > streams and subscriptions, stream discovery, etc. > > > > I *think* that your intention is that new clients really should be usin= g > > instead of , since it is > protocol- > > independent and support modification and deletion. > > > > If we also want to be fully backwards compatible with 5277, I think we > should > > create a document that is much closer to the current 5277 - essentially > just > > creating a YANG model for the config false data and for the "old" > > subscription>. > > We absolutely want to have a full backwards compatible capability. The > question is how to best frame this in documents. It is possible to rebui= ld > RFC-5277 with a YANG model. But then you can't just layer on new > capabilities driving this work. (And this is why we need separate > namespaces.) > > > > > > We need to parse and understand "full backwards compatible". > > > > Do we want existing implementations to be leveraged into the new > solution? Yes > > A server should be capable of supporting for > > old, deprecated subscriptions, and for the new > current subscriptions. > > > > Do we need to update RFC 5277 or replace it? IMO, replace it. > > Since the RPC was never in a YANG module, > > it can be left out of the new module. > > > > I believe at minimum that should be pulled out > of the new module. It needs its separate namespace. Perhaps nobody is > ready to advocate for a parallel 5277-legacy YANG model since new > development should go to the new paradigm anyway. In this case, we could > just have a standalone legacy 5277 section in the document for anything > needed. This would make things simpler and easier to tease apart. > > > > Even more radical, I think streams should be removed, even the NETCONF > stream. > > They really serve no purpose now that subscriptions are formalized and ca= n > > even be configured. It is also bad design to couple the output message > encoding > > into the input stream. (e.g., NETCONF stream MUST be XML encoded). > > > > Even as we move away from streams, I still can see reasons for it. > (Adding Balazs & Alex as they have been proponents.) The biggest reason > for streams is that a robust customer designed filters are hard. If a > vendor/customer/etc. is able to pre-filter notifications or datastore in = an > interesting and useful way not supportable by our filtering semantics, th= is > is a good way to allow the pre-filtering. Some examples which could be > interesting: > > =C2=B7 Event notifications when new devices connect to a network > > =C2=B7 Alarms potentially set across multiple YANG models > > > > Currently, filters are defined as a choice-stmt. > > This implied OR-expr is too simplistic. An explicit combination of OR, > AND, and NOT is required > > for different types of filters. (similar to YANG 1.1 if-feature-stmt > syntax). > > > > Totally agree that we need robust filters. Figuring this problem > space out is a full time job. Figuring out how to encoding filtering > capabilities supported on different types of constrained platforms is > non-trivial. I would love to see someone take this on for the industry. > Any takers? > > > > Eric > > > > Andy > > > > > > As layering upon RFC-5277 cannot give the new capabilities being requeste= d > of us in places like RFC-7923 (e.g., multiple subscriptions/session), we > are moving now to put all elements just needed for backwards compatibilit= y > in the netconf transport draft. We could also separate all this out into > another independent backwards compatibility extension. But we felt we ha= d > enough drafts in progress where we didn't want/need a fifth one. > > > > [AG] FWIW, the scope of each doc is summarized on > > > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf > > > (slide > > > #5) > > > [AG] The key is that the spec for NC comes from the union of 5277-bis > > > and the NC transport doc > > > (draft-ietf-netconf-netconf-event-notifications-01.txt) The NC > > > transport doc is not meant to stand alone. > > > The doc contains how 5277-bis concepts are realized when using NC and > > > NC-specific aspects. E.g.: > > > - the use of NC call-home for configured subscriptions > > > - backwards compatibility > > > - the existence of a NETCONF stream > > > - support of /netconf/streams > > > Yes, any 5277bis topic specific to only NETCONF transport should > > > be in netconf-event-notifications > > > > > > I agree with Martin that duplicating normative text is bad. > > > Not having any normative text is even worse. > > > > > > +1. To help address that, I just built a whole list of pending > changes > > across the four drafts. And in quite a few places I pulled out > duplicative text. > > > > > > - the definition of create-subscription may be moved to this doc so > > > that other transports would ignore create-subscription and use only > > > establish-subscription, simplifying the solution > > > > > > > > > That seems wrong since 5277 had create-subscription so it should stay > > > in 5277bis > > > > > > It is really a style thing so it doesn=E2=80=99t matter that muc= h either > way. > > Current thinking is that as we need both the new and old namespaces. > > Therefore it seems simpler to have anything in the old namespace > (=E2=80=9Ccreate- > > subscription=E2=80=9D) in netconf-event-notification draft. > > > > I agree with Andy that anything that comes from 5277 that you need to > keep > > for backwards compatibility reasons should go into 5277bis. > > Right now it is in 5277bis. But we already can't have everything needed > for backwards compatibility since the 5277bis is transport (NETCONF) > independent. So it seemed logical to put it NETCONF transport draft. > (Again we were trying to limit the proliferation of drafts.) > > In the end, I am ok as long as it lands somewhere. So if people prefer, > we could also have this as a completely separate backwards compatibility > section + YANG model in 5277bis. > > > > - how to issue notifications in JSON are sent using NC (this is also > > > in 5277-bis). Arguably, it belongs in the NC transport doc > > > > > > > > > > > > This is poorly defined. > > > NETCONF does not support JSON encoding and IMO should not define JSON > > > encoding unless the entire protocol supports it cleanly. > > > The proposal seems to be to use XML for and , but > > > allow some special mode where is sent in JSON. > > > > > > > > > > >o Section 2.1 > > > > > > > > The text says: > > > > > > > > The NETCONF event stream contains all > > > > NETCONF XML event notifications supported by the publisher, > > > > > > > > First of all, since this document is protocol-agnostic, should it > > > > really define the stream "NETCONF"? > > > > > > Agree, which is why this is going to netconf-event-notification. > > > > > > > Secondly, this would be a new requirement. There is nothing in RF= C > > > > 5277 that says that a notification is sent on "NETCONF" be default= . > > > > > > 5277 section 3.2.3 talks about the default event stream which ha= s > > > all NETCONF event notifications > > > > You're right. The question is then what is an "NETCONF XML event > > notification"? I think the intention was that these would be > "notifications > > related to NETCONF", rather than "all YANG-defined notifications". Thi= s > needs > > some disucssion. > > Agree > > > > > I think this text should be removed. How notifications are mapped > > > > to streams is should be out of scope for this document. > > > > > > Yes, streams as a whole were something we deferred for a while. > Latest > > thinking is we minimize streams to the degree possible. Look for legac= y > stuff to > > be in netconf-event-notification. > > > > Do you mean that you plan to update the text around streams? If so, > that's > > fine. > > Yes > > > > > In list "filter", change "filter-id" to "id". > > > > > > > > In list "subscription", change "subscription-id" to "id". > > > > > > Model purity-wise you are correct. With both subscription id an= d > filter > > id, several people expressed they wanted the objects to be immediately > and > > obviously differentiable. Hopefully others will chime in here. > > > > I think we should try to keep the same style across IETF documents. > > Most models do not use redundant qualifiers, especially not for generic > names > > like 'id' or 'name' when used as a key. > > I am happy with whatever convention the WG chooses. > > > > > In list "subscription", change "startTime" to "start-time" and > > > > "stopTime" to "stop-time", for consistency. > > > > > > we kept the old names for backwards equivalency to 5277. > > > > But there is nothing to be backwards compatible with in this case. > > The input paramters to the existing cannot be > changed, > > but new nodes should be kept consistent. > > Ok. So you want start-time in the YANG model, and startTime in the RPC. > That can be done. > > > > > In list "subscription", change choice "push-source" to a better > > > > name, maybe "egress-interface" (this is how it is described). > > > > > > push-source can also be an IP Address. Another name possibility > for this > > might be =E2=80=9COriginates-from=E2=80=9D, that is the basic idea. > > > > The current draft has: > > > > choice push-source { > > description > > "Identifies the egress interface on the Publisher from > > which notifications will or are being sent."; > > > > You probably need to adjust this, and make it clear what the ip-address > case > > really means. > > agree > > > > > In list "receiver", what is a "multipoint address"? > > > > > > we are trying not to limit receivers to hosts. Perhaps multicast > address is > > ok. Really we would be good with type: inet:host. > > > > The type is inet:host already. > > > > You should probably clarify the descriptions. > > agree > > > > > Remove the leaf "source-vrf"; this should eventually be aligned > > > > with draft-ietf-rtgwg-ni-model. > > > > > > Perhaps a place for schema-mount? > > > > Not really, rather an augment. > > Happy to go with whatever convention people want to use. > > > > We should leave source-vrf in > > > place until we have the proper definition. > > > > No I say remove it until you have a proper definition. If you keep it > you need to > > have a proper definition of what it is, and it needs to be interoperabl= e > across > > implementations. > > We will address with the proper convention in the next draft > > > > But we could update the text showing there is a pending decision. > > > > > > > You have made the stream name an identity. In RFC 5277 it was a > > > > string. By using an identity, you severly limit how it can be used= ; > > > > with a string new streams can be dynamically created at run-time, > > > > but with an identity stream names must be known at design-time. > > > > I think the stream name should be changed back to a string. > > > > > > as the majority of the people in the informal design team were > against > > the expansion of streams, this is likely a moot point. > > > > I don't know what "expansion of streams" means, and I don't understand > what > > "this" refers to in "this is likely a moot point". > > > > But if we keep the stream name as an identity we're no longer backwards > > compatible with RFC 5277, and we severly limit the functionality. I > strongly > > object to such a change. > > I am fine with string, especially as: > (a) we are moving away from strings in favor of filters > (b) custom streams are likely to be the dominant use. > Anyone have an objection to this change? > > > > >o Section 4.1 > > > > > > > > The text says: > > > > > > > > If the > > > > request is rejected because the publisher is not able to serve it= , > > > > the publisher SHOULD include in the returned error what > subscription > > > > parameters would have been accepted for the request when it was > > > > processed. > > > > > > > > I think this is a pretty weird idea. It seems extremely difficult > > > > to implement, and the use case is not clear at all. In an > > > > automation deployment, do we expect that the client application cod= e > > > > contains logic to rewrite itself to send proper requests the next > > > > time? If it is for debugging purposes I think this should be up = to > > > > implementations to figure out. We shouldn't add such things to > > > > standard RPCs. > > > > > > there has been lots of discussion on this one. The biggest issu= e > has been > > that there are enough variations of parameters where the guidance on wh= at > > might be acceptable is the only way to make some scenarios work. (Was > it the > > period which was a problem? Was it the complexity of the filter?) > Obviously > > we do need to bound what could be provided back to the subscriber. > > > > So then the text should encourage implementations to provide good error > > messages. > > yes > > > > The good news is that if a publisher cannot support negotiation, it > can just > > send back a failure. Which is why the requirement is only a SHOULD. > > > > SHOULD is too strong. And even so, this just adds complexity to the > > specification. I think this should be removed. > > RFC7923 has it as a MUST (see section 4.2.2.) Going to SHOULD is already > easing off the requirement. > > > > A worse outcome would be if a Subscriber kept guessing at acceptable > > parameters and pounding the Publisher with load on this. This would ta= ke > > more resources than providing hints. > > > > That would also be quite weird. But I can't imagine a use case where a > client > > needs a certain combination of parameters, the server rejcets them but > suggest > > some other parameters that will give the same result, and then the clie= nt > > would use them? Or worse, the server suggest something that gives > another > > result and the client somehow adjust to them? > > When a subscription is rejected, we can provide a hint at why. This is a > new dampening period, a suggestion to use on-change, etc. Without this > hint, a subscriber could just keep guessing at parameters without > guidance. That is all negotiation is. > > > > >o Section 6 > > > > > > > > The text says: > > > > > > > > The event notifications must also include the subscription-id if > the > > > > establish-subscription was used in its establishment, or if it wa= s > > > > configured via an operational interface. > > > > > > > > How is this "sucbscription-id" supposed to be included? Where? > > > > There is no such field defined in a . > > > > > > Unlike yang-push, the Notification events are not specified via > the > > document. The examples following the requirement do not include a > > subscription-id when they absolutely should. (And this proves the poin= t > that > > these are needed :-). We will update the examples. > > > > Well, examples are good, but you also need a normative definition. > > Will do. > > Eric > > > /martin > > > > > > > > > > Thanks again, > > > Eric > > > --94eb2c07ecfa92179f05429d2977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I worked on the filtering problem a= bit more.
Here is filter.yang, a filtering framework, and topic.= yang, and example of a filter type
that can be used in filter.yan= g. Topic-based filtering was briefly discussed in Seoul.

IMO filters will continue to evolve over time so the solution needs = to allow
them to be added and combined with other filters.=C2=A0 = The current YANG choice-stmt
is not extensible enough or powerful= enough.


Andy

<= /div>

On Tue, Nov = 29, 2016 at 7:11 PM, Eric Voit (evoit) <evoit@cisco.com> wrote= :

From: Andy Bierman, November 29, 201= 6 8:30 PM

On Tue, Nov 29, 2016 at 8:05 AM, Eric Voit (evoit) &= lt;evoit@cisco.com= > wrote:

Thanks Martin,

More in line.=C2=A0 =C2=A0Also I extracted areas where we already agree to = make this easier to follow.

> From: Martin Bjorklund, November 29, 2016 6:40 AM
> > >If I understand the intention correctly, this document is sup= posed to
> > >*define* how notifications are sent over NETCONF.=C2=A0 But t= here is no
> > >such definition in this document.=C2=A0 Instead it simply rep= eats
> > >information already defined in draft-ietf-netconf-rfc5277bis-= 01.txt,
> > >and provides lots of examples of how the YANG operations defi= ned in
> > >rfc5277bis are encoded in XML and sent over NETCONF.
> > >
> > >I suggest that this document is rewritten.=C2=A0 Since the id= ea is to
> > >replace RFC 5277, it needs to focus on how notifications are = sent
> > >over NETCONF, and not how RPCs are encoded in XML.
> > I agree -- maybe get rid of it and just have rfc5277bis contain t= his
> > text
> >
> > <ev> 5277bis is supposed to allow transports other than NET= CONF.=C2=A0 If we put
> the NETCONF specific stuff in here we lose that separation.
>
> We need *some* document that defines how notifications are sent over > NETCONF.=C2=A0 This document needs to have the specification for the &= lt;notification>
> element.
>
> Then we need a protocol-independent document that defines the concept = of
> streams and subscriptions, stream discovery, etc.
>
> I *think* that your intention is that new clients really should be usi= ng
> <establish-subscription> instead of <create-subscription>,= since it is protocol-
> independent and support modification and deletion.
>
> If we also want to be fully backwards compatible with 5277, I think we= should
> create a document that is much closer to the current 5277 - essentiall= y just
> creating a YANG model for the config false data and for the "old&= quot; <create-
> subscription>.

We absolutely want to have a full backwards compatible capability.=C2=A0 Th= e question is how to best frame this in documents.=C2=A0 It is possible to = rebuild RFC-5277 with a YANG model.=C2=A0 But then you can't just layer= on new capabilities driving this work.=C2=A0 (And this is why we need separate namespaces.)

=C2=A0

=C2=A0

We need to parse and understand "full backwards= compatible".

=C2=A0

Do we want existing implementations to be leveraged = into the new solution?=C2=A0 Yes

A server should be capable of supporting <create-= subscription> for

old, deprecated subscriptions, and <establish-sub= scription> for the new current subscriptions.

=C2=A0

Do we need to update RFC 5277 or replace it? IMO, re= place it.

Since the <create-subscription> RPC was never = in a YANG module,

it can be left out of the new module.=C2=A0

=C2=A0

<ev> I believe at minimum that = <create subscription> should be pulled out of the new module.=C2=A0 I= t needs its separate namespace.=C2=A0 =C2=A0Perhaps nobody is ready to advo= cate for a parallel 5277-legacy YANG model since new development should go to t= he new paradigm anyway.=C2=A0 In this case, we could just have a standalone= legacy 5277 section in the document for anything needed.=C2=A0 This would = make things simpler and easier to tease apart.

=C2=A0

Even more radical, I think streams should be removed= , even the NETCONF stream.

They really serve no purpose now that subscriptions = are formalized and can

even be configured.=C2=A0 It is also bad design to c= ouple the output message encoding

into the input stream. (e.g., NETCONF stream MUST be= XML encoded).

=C2=A0

<ev> Even as we move away from = streams, I still can see reasons for it.=C2=A0 (Adding Balazs & Alex as= they have been proponents.)=C2=A0 The biggest reason for streams is that a robust customer designed filters are hard.=C2=A0 If a vendor/cus= tomer/etc. is able to pre-filter notifications or datastore in an interesti= ng and useful way not supportable by our filtering semantics, this is a goo= d way to allow the pre-filtering. Some examples which could be interesting:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Event notifications when new dev= ices connect to a network

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Alarms potentially set across mu= ltiple YANG models

=C2=A0

Currently, filters are defined as a choice-stmt.<= /u>

This implied OR-expr is too simplistic. An explicit = combination of OR, AND, and NOT is required

for different types of filters. =C2=A0(similar to YA= NG 1.1 if-feature-stmt syntax).

=C2=A0

<ev> Totally agree that we need= robust filters.=C2=A0 Figuring this problem space out is a full time job.= =C2=A0 Figuring out how to encoding filtering capabilities supported on different types of constrained platforms is non-trivial.=C2=A0 I would = love to see someone take this on for the industry.=C2=A0 Any takers?=

=C2=A0

Eric

=C2=A0

Andy

=C2=A0

=C2=A0

As layering upon RFC-5277 cannot give the new capabi= lities being requested of us in places like RFC-7923 (e.g., multiple subscr= iptions/session), we are moving now to put all elements just needed for bac= kwards compatibility in the netconf transport draft.=C2=A0 We could also separate all this out into another in= dependent backwards compatibility extension.=C2=A0 But we felt we had enoug= h drafts in progress where we didn't want/need a fifth one.

> > [AG] FWIW, the scope of each doc is summarized on
> > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pd= f
> > (slide
> > #5)
> > [AG] The key is that the spec for NC comes from the union of 5277= -bis
> > and the NC transport doc
> > (draft-ietf-netconf-netconf-event-notifications-01.txt) The = NC
> > transport doc is not meant to stand alone.
> > The doc contains how 5277-bis concepts are realized when using NC= and
> > NC-specific aspects. E.g.:
> > - the use of NC call-home for configured subscriptions
> > - backwards compatibility
> >=C2=A0 =C2=A0 - the existence of a NETCONF stream
> >=C2=A0 =C2=A0 - support of /netconf/streams
> > <ev> Yes, any 5277bis topic specific to only NETCONF transp= ort should
> > be in netconf-event-notifications
> >
> > I agree with Martin that duplicating normative text is bad.
> > Not having any normative text is even worse.
> >
> > <ev> +1.=C2=A0 To help address that, I just built a whole l= ist of pending changes
> across the four drafts.=C2=A0 And in quite a few places I pulled out d= uplicative text.
> >
> > - the definition of create-subscription may be moved to this doc = so
> > that other transports would ignore create-subscription and use on= ly
> > establish-subscription, simplifying the solution
> >
> >
> > That seems wrong since 5277 had create-subscription so it should = stay
> > in 5277bis
> >
> > <ev> It is really a style thing so it doesn=E2=80=99t matte= r that much either way.
> Current thinking is that as we need both the new and old namespaces. > Therefore it seems simpler to have anything in the old namespace (=E2= =80=9Ccreate-
> subscription=E2=80=9D) in netconf-event-notification draft.
>
> I agree with Andy that anything that comes from 5277 that you need to = keep
> for backwards compatibility reasons should go into 5277bis.

Right now it is in 5277bis.=C2=A0 But we already can't have everything = needed for backwards compatibility since the 5277bis is transport (NETCONF)= independent.=C2=A0 So it seemed logical to put it NETCONF transport draft.= =C2=A0 (Again we were trying to limit the proliferation of drafts.)

In the end, I am ok as long as it lands somewhere.=C2=A0 So if people prefe= r, we could also have this as a completely separate backwards compatibility= section + YANG model in 5277bis.

> > - how to issue notifications in JSON are sent using NC (this is a= lso
> > in 5277-bis). Arguably, it belongs in the NC transport doc
> >
> >
> >
> > This is poorly defined.
> > NETCONF does not support JSON encoding and IMO should not define = JSON
> > encoding unless the entire protocol supports it cleanly.
> > The proposal seems to be to use XML for <rpc> and <rpc-r= eply>, but
> > allow some special mode where <notification> is sent in JSO= N.
> >
> > >
> > >o=C2=A0 Section 2.1
> > >
> > >=C2=A0 The text says:
> > >
> > >=C2=A0 =C2=A0The NETCONF event stream contains all
> > >=C2=A0 =C2=A0NETCONF XML event notifications supported by the= publisher,
> > >
> > >=C2=A0 First of all, since this document is protocol-agnostic= , should it
> > > really define the stream "NETCONF"?
> >
> > <ev> Agree, which is why this is going to netconf-event-not= ification.
> >
> > >=C2=A0 Secondly, this would be a new requirement.=C2=A0 There= is nothing in RFC
> > >=C2=A0 5277 that says that a notification is sent on "NE= TCONF" be default.
> >
> > <ev> 5277 section 3.2.3 talks about the default event strea= m which has
> > all NETCONF event notifications
>
> You're right.=C2=A0 The question is then what is an "NETCONF = XML event
> notification"?=C2=A0 I think the intention was that these would b= e "notifications
> related to NETCONF", rather than "all YANG-defined notificat= ions".=C2=A0 This needs
> some disucssion.

Agree

> > >=C2=A0 I think this text should be removed.=C2=A0 How notific= ations are mapped
> > > to streams is should be out of scope for this document.
> >
> > <ev> Yes, streams as a whole were something we deferred for= a while.=C2=A0 Latest
> thinking is we minimize streams to the degree possible.=C2=A0 Look for= legacy stuff to
> be in netconf-event-notification.
>
> Do you mean that you plan to update the text around streams?=C2=A0 If = so, that's
> fine.

Yes

> > >=C2=A0 In list "filter", change "filter-id&quo= t; to "id".
> > >
> > >=C2=A0 In list "subscription", change "subscri= ption-id" to "id".
> >
> > <ev> Model purity-wise you are correct.=C2=A0 With both sub= scription id and filter
> id, several people expressed they wanted the objects to be immediately= and
> obviously differentiable.=C2=A0 =C2=A0Hopefully others will chime in h= ere.
>
> I think we should try to keep the same style across IETF documents. > Most models do not use redundant qualifiers, especially not for generi= c names
> like 'id' or 'name' when used as a key.

I am happy with whatever convention the WG chooses.

> > >=C2=A0 In list "subscription", change "startTi= me" to "start-time" and
> > > "stopTime" to "stop-time", for consisten= cy.
> >
> > <ev> we kept the old names for backwards equivalency to 527= 7.
>
> But there is nothing to be backwards compatible with in this case.
> The input paramters to the existing <create-subscription> cannot= be changed,
> but new nodes should be kept consistent.

Ok.=C2=A0 So you want start-time in the YANG model, and startTime in the RP= C.=C2=A0 That can be done.

> > >=C2=A0 In list "subscription", change choice "= push-source" to a better
> > > name, maybe "egress-interface" (this is how it is = described).
> >
> > <ev> push-source can also be an IP Address.=C2=A0 Another n= ame possibility for this
> might be =E2=80=9COriginates-from=E2=80=9D, that is the basic idea. >
> The current draft has:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 choice push-source {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Identifies the egress i= nterface on the Publisher from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which notifications wil= l or are being sent.";
>
> You probably need to adjust this, and make it clear what the ip-addres= s case
> really means.

agree

> > >=C2=A0 In list "receiver", what is a "multipoi= nt address"?
> >
> > <ev> we are trying not to limit receivers to hosts. Perhaps= multicast address is
> ok.=C2=A0 Really we would be good with type: inet:host.
>
> The type is inet:host already.
>
> You should probably clarify the descriptions.

agree

> > >=C2=A0 Remove the leaf "source-vrf"; this should ev= entually be aligned
> > > with=C2=A0 draft-ietf-rtgwg-ni-model.
> >
> > Perhaps a place for schema-mount?
>
> Not really, rather an augment.

Happy to go with whatever convention people want to use.

> > We should leave source-vrf in
> > place until we have the proper definition.
>
> No I say remove it until you have a proper definition.=C2=A0 If you ke= ep it you need to
> have a proper definition of what it is, and it needs to be interoperab= le across
> implementations.

We will address with the proper convention in the next draft

> > But we could update the text showing there is a pending decision.=
> >
> > >=C2=A0 You have made the stream name an identity.=C2=A0 In RF= C 5277 it was a
> > > string.=C2=A0 By using an identity, you severly limit how it= can be used;
> > > with a string new streams can be dynamically created at run-= time,
> > > but with an identity stream names must be known at design-ti= me.
> > >=C2=A0 I think the stream name should be changed back to a st= ring.
> >
> > <ev> as the majority of the people in the informal design t= eam were against
> the expansion of streams, this is likely a moot point.
>
> I don't know what "expansion of streams" means, and I do= n't understand what
> "this" refers to in "this is likely a moot point".=
>
> But if we keep the stream name as an identity we're no longer back= wards
> compatible with RFC 5277, and we severly limit the functionality.=C2= =A0 I strongly
> object to such a change.

I am fine with string, especially as:
(a) we are moving away from strings in favor of filters
(b) custom streams are likely to be the dominant use.
Anyone have an objection=C2=A0 to this change?

> > >o=C2=A0 Section 4.1
> > >
> > >=C2=A0 The text says:
> > >
> > >=C2=A0 =C2=A0If the
> > >=C2=A0 =C2=A0request is rejected because the publisher is not= able to serve it,
> > >=C2=A0 =C2=A0the publisher SHOULD include in the returned err= or what subscription
> > >=C2=A0 =C2=A0parameters would have been accepted for the requ= est when it was
> > >=C2=A0 =C2=A0processed.
> > >
> > >=C2=A0 I think this is a pretty weird idea.=C2=A0 It seems ex= tremely difficult
> > > to implement, and the use case is not clear at all.=C2=A0 In= an
> > > automation deployment, do we expect that the client applicat= ion code
> > > contains logic to rewrite itself to send proper requests the= next
> > >=C2=A0 time?=C2=A0 =C2=A0If it is for debugging purposes I th= ink this should be up to
> > >=C2=A0 implementations to figure out.=C2=A0 We shouldn't = add such things to
> > > standard RPCs.
> >
> > <ev> there has been lots of discussion on this one.=C2=A0 T= he biggest issue has been
> that there are enough variations of parameters where the guidance on w= hat
> might be acceptable is the only way to make some scenarios work.=C2=A0= (Was it the
> period which was a problem?=C2=A0 Was it the complexity of the filter?= )=C2=A0 Obviously
> we do need to bound what could be provided back to the subscriber.
>
> So then the text should encourage implementations to provide good erro= r
> messages.

yes

> > The good news is that if a publisher cannot support negotiation, = it can just
> send back a failure.=C2=A0 Which is why the requirement is only a SHOU= LD.
>
> SHOULD is too strong.=C2=A0 And even so, this just adds complexity to = the
> specification.=C2=A0 I think this should be removed.

RFC7923 has it as a MUST (see section 4.2.2.)=C2=A0 Going to SHOULD is alre= ady easing off the requirement.

> > A worse outcome would be if a Subscriber kept guessing at accepta= ble
> parameters and pounding the Publisher with load on this.=C2=A0 This wo= uld take
> more resources than providing hints.
>
> That would also be quite weird.=C2=A0 But I can't imagine a use ca= se where a client
> needs a certain combination of parameters, the server rejcets them but= suggest
> some other parameters that will give the same result, and then the cli= ent
> would use them?=C2=A0 Or worse, the server suggest something that give= s another
> result and the client somehow adjust to them?

When a subscription is rejected, we can provide a hint at why.=C2=A0 This i= s a new dampening period, a suggestion to use on-change, etc.=C2=A0 Without= this hint, a subscriber could just keep guessing at parameters without gui= dance.=C2=A0 That is all negotiation is.

> > >o=C2=A0 Section 6
> > >
> > >=C2=A0 The text says:
> > >
> > >=C2=A0 =C2=A0The event notifications must also include the su= bscription-id if the
> > >=C2=A0 =C2=A0establish-subscription was used in its establish= ment, or if it was
> > >=C2=A0 =C2=A0configured via an operational interface.
> > >
> > >=C2=A0 How is this "sucbscription-id" supposed to b= e included?=C2=A0 Where?
> > >=C2=A0 There is no such field defined in a <notification&g= t;.
> >
> > <ev> Unlike yang-push, the Notification events are not spec= ified via the
> document.=C2=A0 =C2=A0The examples following the requirement do not in= clude a
> subscription-id when they absolutely should.=C2=A0 (And this proves th= e point that
> these are needed :-).=C2=A0 =C2=A0We will update the examples.
>
> Well, examples are good, but you also need a normative definition.

Will do.

Eric

> /martin
>
>
> >
> > Thanks again,
> > Eric

=C2=A0


--94eb2c07ecfa92179f05429d2977-- --94eb2c07ecfa9217a205429d2979 Content-Type: application/octet-stream; name="filter.yang" Content-Disposition: attachment; filename="filter.yang" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iw6pglq30 bW9kdWxlIGZpbHRlciB7CiAgeWFuZy12ZXJzaW9uIDEuMTsKICBuYW1lc3BhY2UgInVybjp0ZXN0 OmZpbHRlciI7CiAgcHJlZml4IGZpbDsKICBpbXBvcnQgaWV0Zi15YW5nLXR5cGVzIHsgcHJlZml4 IHlhbmc7IH0KCiAgaW1wb3J0IGlldGYtZXZlbnQtbm90aWZpY2F0aW9ucyB7CiAgICBwcmVmaXgg bm90aWYtYmlzOwogIH0KCiAgcmV2aXNpb24gMjAxNi0xMi0wMTsKCiAgaWRlbnRpdHkgZmlsdGVy LXR5cGU7CgogIGlkZW50aXR5IHN1YnRyZWUtZmlsdGVyIHsKICAgIGJhc2UgZmlsdGVyLXR5cGU7 CiAgfQoKICBpZGVudGl0eSB4cGF0aC1maWx0ZXIgewogICAgYmFzZSBmaWx0ZXItdHlwZTsKICB9 CgogIHR5cGVkZWYgZmlsdGVyLWV4cHIgewogICAgdHlwZSBzdHJpbmc7CiAgICBkZXNjcmlwdGlv bgogICAgICAiVGhpcyB0eXBlIHJlcHJlc2VudHMgZmlsdGVyIGxvZ2ljIGZvciBzZWxlY3Rpb24g cHJvY2Vzc2luZwogICAgICAgb2YgZGF0YSBkZWZpbmVkIGluIFlBTkcuICBJdCBjb250YWlucyBh IHN0cmluZyB3aGljaAogICAgICAgcmVwcmVzZW50cyBhIGxvZ2ljYWwgZXhwcmVzc2lvbiwgYW5k IGlzIGJhc2VkIG9uIHRoZQogICAgICAgWUFORyAxLjEgJ2lmLWZlYXR1cmUtc3RtdC1zdHInIEFC TkYgZnJvbSBSRkMgNzk1MC4KICAgICAgIFRoZSAnaWRlbnRpZmllci1yZWYtYXJnJyByZXByZXNl bnRpbmcgYSBxdWFsaWZpZWQKICAgICAgIGZlYXR1cmUgbmFtZSBpcyByZXBsYWNlZCBieSAnZmls dGVyLXJlZi1hcmcnIHdoaWNoCiAgICAgICByZXByZXNlbnRzIHRoZSBuYW1lIG9mIGEgZmlsdGVy IGluIHRoZSAvZmlsdGVycy9maWx0ZXIKICAgICAgIGxpc3QuCgogICAgICAgZmlsdGVyLWV4cHIt c3RyID0gPCBhIHN0cmluZyB0aGF0IG1hdGNoZXMgdGhlIHJ1bGUgPgogICAgICAgICAgICAgICAg ICAgICAgICAgPCBmaWx0ZXItZXhwciA+CgogICAgICAgZmlsdGVyLWV4cHIgICAgID0gZmlsdGVy LXRlcm0KICAgICAgICAgICAgICAgICAgICAgICAgIFtzZXAgb3Ita2V5d29yZCBzZXAgZmlsdGVy LWV4cHJdCgogICAgICAgZmlsdGVyLXRlcm0gICAgID0gaWYtZmlsdGVyLWZhY3RvcgogICAgICAg ICAgICAgICAgICAgICAgICAgW3NlcCBhbmQta2V5d29yZCBzZXAgZmlsdGVyLXRlcm1dCgogICAg ICAgZmlsdGVyLWZhY3RvciAgID0gbm90LWtleXdvcmQgc2VwIGZpbHRlci1mYWN0b3IgLwogICAg ICAgICAgICAgICAgICAgICAgICAnKCcgb3B0c2VwIGZpbHRlci1leHByIG9wdHNlcCAnKScgLwog ICAgICAgICAgICAgICAgICAgICAgICBmaWx0ZXItcmVmLWFyZwogICAgICAgZmlsdGVyLXJlZi1h cmcgID0gPCBhIHN0cmluZyB0aGF0IG1hdGNoZXMgdGhlIG5hbWUKICAgICAgICAgICAgICAgICAg ICAgICAgICAgb2YgYW4gZW50cnkgaW4gdGhlIC9maWx0ZXJzL2ZpbHRlcgogICAgICAgICAgICAg ICAgICAgICAgICAgICBsaXN0ID4KCiAgICAgICBFeGFtcGxlOgogICAgICAgICAgQXNzdW1lIG5h bWVkIGZpbHRlcnMgJ2ZpbHRlci0xJywgJ2ZpbHRlci0yJywKICAgICAgICAgIGFuZCAnZmlsdGVy LTMnLiBUaGUgZm9sbG93aW5nIGlzIGEgdmFsaWQKICAgICAgICAgIGZpbHRlciBleHByZXNzaW9u OgoKICAgICAgICAgJ2ZpbHRlci1hIGFuZCAoZmlsdGVyLWIgb3Igbm90IGZpbHRlci1jKScKICAg ICAgICI7CiAgICByZWZlcmVuY2UgIlJGQyA3OTUwLCBzZWN0aW9uIDE0IjsKICB9CgogIGNvbnRh aW5lciBmaWx0ZXJzIHsKICAgIGRlc2NyaXB0aW9uCiAgICAgICJTZXQgb2YgZmlsdGVycyBmb3Ig dXNlIHdpdGggYSBmaWx0ZXIgZXhwcmVzc2lvbi4KICAgICAgIFByb3ZpZGVzIGEgc2ltcGxlIGFu ZCBleHRlbnNpYmxlIGZpbHRlcmluZyBmcmFtZXdvcmsuIjsKCiAgICBsaXN0IGZpbHRlciB7CiAg ICAgIGtleSBuYW1lOwogICAgICBkZXNjcmlwdGlvbgogICAgICAgICJGaWx0ZXIgZW50cnkgdGVt cGxhdGUuCiAgICAgICAgIFRvIGFkZCBhIGZpbHRlciB0eXBlOgogICAgICAgICAgMSkgQ3JlYXRl IGEgbmV3IGlkZW50aXR5IHdpdGggYmFzZSAnZmlsdGVyLXR5cGUnCiAgICAgICAgICAgICB0byBp ZGVudGlmeSB0aGUgdHlwZSBvZiBmaWx0ZXIuCiAgICAgICAgICAyKSBJZiBhbnkgcGFyYW1ldGVy cyBhcmUgbmVlZGVkIGZvciB0aGUgZmlsdGVyCiAgICAgICAgICAgICB0aGVuIGF1Z21lbnQgdGhp cyBsaXN0IHdpdGggdGhlIHBhcmFtZXRlcnMKICAgICAgICAgICAgIHVzaW5nIGFuIGF1Z21lbnQt c3RtdCB3aXRoIGEgd2hlbi1zdG10CiAgICAgICAgICAgICB0aGF0IHNlbGVjdHMgdGhlIGlkZW50 aXR5IGRlZmluZWQgaW4gc3RlcCAxLgoKICAgICAgICAgICBhdWdtZW50IC9maWw6ZmlsdGVycy9m aWw6ZmlsdGVyIHsKICAgICAgICAgICAgIHdoZW4gJ2Rlcml2ZWQtZnJvbS1vci1zZWxmKHR5cGUs ICdteW1vZDpteWZpbHRlcicpJzsKICAgICAgICAgICAgIC8vIGFkZGl0aW9uYWwgcGFyYW1ldGVy cwogICAgICAgICAgIH0KICAgICAgICAiOwoKICAgICAgbGVhZiBuYW1lIHsgdHlwZSBzdHJpbmc7 IH0KICAgICAgbGVhZiB0eXBlIHsKICAgICAgICB0eXBlIGlkZW50aXR5cmVmIHsKICAgICAgICAg IGJhc2UgZmlsdGVyLXR5cGU7CiAgICAgICAgfQogICAgICB9CiAgICB9CiAgfQoKCiAgLy8gc3Vi dHJlZQogIGF1Z21lbnQgL2ZpbHRlcnMvZmlsdGVyIHsKICAgIHdoZW4gImRlcml2ZWQtZnJvbS1v ci1zZWxmKHR5cGUsICdmaWw6c3VidHJlZS1maWx0ZXInKSI7CiAgICBhbnlkYXRhIHN1YnRyZWUt ZmlsdGVyOwogIH0KCiAgLy8geHBhdGgKICBhdWdtZW50IC9maWx0ZXJzL2ZpbHRlciB7CiAgICB3 aGVuICJkZXJpdmVkLWZyb20tb3Itc2VsZih0eXBlLCAnZmlsOnhwYXRoLWZpbHRlcicpIjsKICAg IGxlYWYgeHBhdGgtZmlsdGVyIHsKICAgICAgdHlwZSB5YW5nOnhwYXRoMS4wOwogICAgfQogIH0K CiAgLy8gZXhhbXBsZSBmaWx0ZXIgdG8gcmVwbGFjZSBhIHN0cmVhbQogIC8vIG5vIG5lZWQgdG8g YWRkIGFueSBwYXJhbWV0ZXJzIGJlY2F1c2UgdGhleSBhcmUKICAvLyBoYXJkLXdpcmVkIGludG8g dGhlIHN0cmVhbSBkZWZpbml0aW9uCgogIGlkZW50aXR5IG15LXN0cmVhbSB7CiAgICBiYXNlIGZp bHRlci10eXBlOwogIH0KCiAgaWRlbnRpdHkgbmV0Y29uZi1zdHJlYW0gewogICAgYmFzZSBmaWx0 ZXItdHlwZTsKICAgIGRlc2NyaXB0aW9uCiAgICAgICJSZXByZXNlbnRzIHRoZSBsZWdhY3kgTkVU Q09ORiBldmVudCBzdHJlYW0iOwogICAgcmVmZXJlbmNlICJSRkMgNTI3Nywgc2VjdGlvbiAzLjIi OwogIH0KCiAgZ3JvdXBpbmcgZmlsdGVyLXBhcmFtcyB7CiAgICBsZWFmIGZpbHRlci1leHByIHsK ICAgICAgdHlwZSBmaWx0ZXItZXhwcjsKICAgICAgZGVzY3JpcHRpb24KICAgICAgICAiUmVwcmVz ZW50cyB0aGUgZmlsdGVyIGV4cHJlc3Npb24gdG8gYXBwbHkgdG8gdGhlCiAgICAgICAgIHN1YnNj cmlwdGlvbiI7CiAgICB9CiAgfQoKICAvLyBFeGFtcGxlIGZvciBkeW5hbWljIHN1YnNjcmlwdGlv bnMsIHRoZSBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uCiAgLy8gb3BlcmF0aW9uIGlzIGF1Z21lbnRl ZCB3aXRoIGEgZmlsdGVyIGV4cHJlc3Npb24KCiAgYXVnbWVudCAiL25vdGlmLWJpczplc3RhYmxp c2gtc3Vic2NyaXB0aW9uL25vdGlmLWJpczppbnB1dCIgewogICAgdXNlcyBmaWx0ZXItcGFyYW1z OwogIH0KCiAgLy8gRXhhbXBsZSBmb3IgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zLCB0aGUgc3Vi c2NyaXB0aW9uIGxpc3QKICAvLyBpcyBhdWdtZW50ZWQgd2l0aCBhIGZpbHRlciBleHByZXNzaW9u CgogIGF1Z21lbnQgIi9ub3RpZi1iaXM6c3Vic2NyaXB0aW9uLWNvbmZpZy9ub3RpZi1iaXM6c3Vi c2NyaXB0aW9uIiB7CiAgICB1c2VzIGZpbHRlci1wYXJhbXM7CiAgfQoKfQo= --94eb2c07ecfa9217a205429d2979 Content-Type: application/octet-stream; name="topic.yang" Content-Disposition: attachment; filename="topic.yang" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iw6pglqt1 bW9kdWxlIHRvcGljIHsKICBuYW1lc3BhY2UgInVybjp0ZXN0OnRvcGljIjsKICBwcmVmaXggdG9w OwoKICBpbXBvcnQgZmlsdGVyIHsgcHJlZml4IGZpbDsgfQoKICByZXZpc2lvbiAyMDE2LTEyLTAx OwoKICBleHRlbnNpb24gZXZlbnQtdG9waWMgewogICAgYXJndW1lbnQgaWQ7CiAgICBkZXNjcmlw dGlvbgogICAgICAiQW4gZXh0ZW5zaW9uIHRvIG1hcCBhIHNjaGVtYSBub2RlIHRvIGEgc3BlY2lm aWMgdG9waWMKICAgICAgIGlkZW50aWZpZXIuIEFuIHJwYywgbm90aWZpY2F0aW9uLCBhY3Rpb24s IG9yIGRhdGEtZGVmCiAgICAgICBzdGF0ZW1lbnQgY29udGFpbmluZyB0aGlzIGV4dGVybmFsIHN0 YXRlbWVudCBpcyBtYXBwZWQKICAgICAgIHRvIHRoZSBldmVudC10b3BpYyBpZGVudGl0eSByZXBy ZXNlbnRlZCBieSB0aGUgJ2lkJwogICAgICAgcGFyYW1ldGVyLgoKICAgICAgIFRoZSBzeW50YXgg b2YgdGhlICdpZCcgYXJndW1lbnQgaXMgdGhlIGlkZW50aXR5cmVmCiAgICAgICBkYXRhIHR5cGUu CgogICAgICAgRXhhbXBsZToKCiAgICAgICAgIGNvbnRhaW5lciBleGFtcGxlLXZwbiB7CiAgICAg ICAgICAgdG9wOmV2ZW50LXRvcGljICdleGFtcGxlOnZwbi1ldmVudCc7CiAgICAgICAgICAgLi4u CiAgICAgICAgIH0KICAgICAgICAgY29udGFpbmVyIGV4YW1wbGUtdnBuLXN0YXRlIHsKICAgICAg ICAgICB0b3A6ZXZlbnQtdG9waWMgJ2V4YW1wbGU6dnBuLWV2ZW50JzsKICAgICAgICAgICAuLi4K ICAgICAgICAgfQogICAgICAgICBub3RpZmljYXRpb24gZXhhbXBsZS12cG4tZXZlbnQgewogICAg ICAgICAgIHRvcDpldmVudC10b3BpYyAnZXhhbXBsZTp2cG4tZXZlbnQnOwogICAgICAgICAgIC4u LgogICAgICAgICB9CiAgICAgICI7CiAgfQoKICBpZGVudGl0eSB0b3BpYy1maWx0ZXIgewogICAg YmFzZSBmaWw6ZmlsdGVyLXR5cGU7CiAgICBkZXNjcmlwdGlvbgogICAgICAiRmlsdGVyIHR5cGUg aWRlbnRpZmllciBmb3IgdG9waWMgZmlsdGVycy4iOwogIH0KCiAgaWRlbnRpdHkgdG9waWMtaWQg ewogICAgZGVzY3JpcHRpb24KICAgICAgIkJhc2UgaWRlbnRpdHkgZnJvbSB3aGljaCB0b3BpYyBp ZGVudGlmaWVycyBhcmUgZGVyaXZlZC4iOwogIH0KCiAgLyoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqCiAgICAgZXhhbXBsZSB0b3BpYyBzdWJ0cmVlCgogICAgKyB0b3BpYy1pZAogICAg ICB8CiAgICAgICsgc2VydmljZS10b3BpYwogICAgICAgIHwKICAgICAgICArIHJvdXRpbmctdG9w aWMKICAgICAgICAgIHwKICAgICAgICAgICsgYmdwLXRvcGljCiAgICAgICAgICB8CiAgICAgICAg ICArIGlzaXMtdG9waWMKCiAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KCiAg aWRlbnRpdHkgc2VydmljZS10b3BpYyB7CiAgICBiYXNlIHRvcGljLWlkOwogICAgZGVzY3JpcHRp b24KICAgICAgIkJhc2UgaWRlbnRpdHkgZnJvbSB3aGljaCBzZXJ2aWNlLXJlbGF0ZWQgdG9waWMg aWRlbnRpZmllcnMKICAgICAgICBhcmUgZGVyaXZlZC4iOwogIH0KCiAgaWRlbnRpdHkgcm91dGlu Zy10b3BpYyB7CiAgICBiYXNlIHNlcnZpY2UtdG9waWM7CiAgICBkZXNjcmlwdGlvbgogICAgICAi QmFzZSBpZGVudGl0eSBmcm9tIHdoaWNoIHJvdXRpbmcgcmVsYXRlZCB0b3BpYyBpZGVudGlmaWVy cwogICAgICAgIGFyZSBkZXJpdmVkLiI7CiAgfQoKICBpZGVudGl0eSBiZ3AtdG9waWMgewogICAg YmFzZSByb3V0aW5nLXRvcGljOwogICAgZGVzY3JpcHRpb24KICAgICAgIkJhc2UgaWRlbnRpdHkg ZnJvbSB3aGljaCBCR1AgcmVsYXRlZCB0b3BpYyBpZGVudGlmaWVycwogICAgICAgIGFyZSBkZXJp dmVkLiI7CiAgfQoKICBpZGVudGl0eSBpc2lzLXRvcGljIHsKICAgIGJhc2Ugcm91dGluZy10b3Bp YzsKICAgIGRlc2NyaXB0aW9uCiAgICAgICJCYXNlIGlkZW50aXR5IGZyb20gd2hpY2ggSVMtSVMg cmVsYXRlZCB0b3BpYyBpZGVudGlmaWVycwogICAgICAgIGFyZSBkZXJpdmVkLiI7CiAgfQoKICBj b250YWluZXIgdG9waWMtbWFwcyB7CiAgICBjb25maWcgZmFsc2U7CiAgICBkZXNjcmlwdGlvbgog ICAgICAiVGhlIHNldCBvZiB0b3BpYy1pZCB0byBzY2hlbWEgbm9kZSBtYXBwaW5ncyB1c2VkIGJ5 CiAgICAgICB0aGUgc2VydmVyIjsKCiAgICBsaXN0IHRvcGljLW1hcCB7CiAgICAgIGtleSAiaWQg bm9kZSI7CiAgICAgIGxlYWYgaWQgewogICAgICAgIHR5cGUgaWRlbnRpdHlyZWYgewogICAgICAg ICAgYmFzZSB0b3BpYy1pZDsKICAgICAgICB9CiAgICAgICAgZGVzY3JpcHRpb24gIlRoZSB0b3Bp YyBpZGVudGlmaWVyIGZvciB0aGlzIG1hcHBpbmciOwogICAgICB9CiAgICAgIGxlYWYgbm9kZSB7 CiAgICAgICAgdHlwZSBzdHJpbmc7IC8vIHJlYWxseSBzY2hlbWEtbm9kZS1pZGVudGlmaWVyIGZy b20gNjUzNWJpcwogICAgICAgIGRlc2NyaXB0aW9uICJUaGUgc2NoZW1hIG5vZGUgZm9yIHRoaXMg bWFwcGluZyI7CiAgICAgIH0KICAgIH0KICB9CgogIGF1Z21lbnQgIi9maWw6ZmlsdGVycy9maWw6 ZmlsdGVyIiB7CiAgICB3aGVuICJkZXJpdmVkLWZyb20tb3Itc2VsZihmaWw6dHlwZSwgJ3RvcDp0 b3BpYy1maWx0ZXInKSI7CgogICAgZGVzY3JpcHRpb24gIlNldCBvZiB0b3BpYyBmaWx0ZXIgcGFy YW1ldGVycyI7CgogICAgbGVhZi1saXN0IHRvcGljLWZpbHRlciB7CiAgICAgIHR5cGUgaWRlbnRp dHlyZWYgewogICAgICAgIGJhc2UgdG9waWMtaWQ7CiAgICAgIH0KICAgICAgZGVzY3JpcHRpb24K ICAgICAgICAiSWRlbnRpZmllcyBhIHRvcGljIHRoYXQgaXMgaW5jbHVkZWQgaW4gdGhlCiAgICAg ICAgIHN1YnNjcmlwdGlvbi4gTXVsdGlwbGUgaW5zdGFuY2VzIHJlcHJlc2VudCBhCiAgICAgICAg IGxvZ2ljYWwgQU5EIGV4cHJlc3Npb24uIEVhY2ggdG9waWMtZmlsdGVyCiAgICAgICAgIGluc3Rh bmNlIG11c3QgZXZhbHVhdGUgdG8gJ3RydWUnIGluIG9yZGVyIGZvcgogICAgICAgICB0aGUgc3Vi c2NyaXB0aW9uIHRvIGFjY2VwdCB0aGUgZXZlbnQuCgogICAgICAgICBBIHRvcGljIG1hdGNoZXMg dGhlIGZpbHRlciBpZiB0aGVyZSBpcyBhdCBsZWFzdCBvbmUKICAgICAgICAgdG9waWMtaWQgYXNz b2NpYXRlZCB3aXRoIHRoZSBldmVudCBub2RlIG9yIG5vdGlmaWNhdGlvbgogICAgICAgICB0aGF0 IGlzIGRlcml2ZWQgZnJvbSBvciBlcXVhbCB0byB0aGUgdG9waWMtZmlsdGVyIHZhbHVlLiI7CiAg ICB9CiAgfQoKfQo= --94eb2c07ecfa9217a205429d2979-- From nobody Thu Dec 1 12:56:44 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18141298C4 for ; Thu, 1 Dec 2016 12:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 WpRRz6hk9Huw for ; Thu, 1 Dec 2016 12:56:39 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003: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 9F35C1299BF for ; Thu, 1 Dec 2016 12:48:11 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id b126so243611558oia.2 for ; Thu, 01 Dec 2016 12:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=mnrY3Z2rC6zbCetQ3lluh2mUGwxMDVg2TaAOJmsmKHY=; b=dhUO4kqQUCvHdTgV91MfZMM4TFTEKlyPsdUnikhh4XdMQpn+ulZLvU+BldFZcXwMKB bKv4isaf6RyPnm0rib77gKBEVIk5yGashEaG0Seupjc3dLZINku8jb+rwMFw9Z42fjhl gmwJMaBZ3Spfww5QbWPJIvF9L7LZP/l7XTqt/IK8eW2CqKlZ/24WxMj2TNoxz2HKLTHn hbvRBmCNkUaQri/N1a/BcGQKrvsPojNfU3wwqdi54wKSXa+zqKRQbaM0Fs5RLy78vANU E3pVkFdste3QL2shRs5nGn4ncMHxBVUZ7rMF8w7f7rXzyIYyIds0xVuRfze+c9KiaK9c ZYYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=mnrY3Z2rC6zbCetQ3lluh2mUGwxMDVg2TaAOJmsmKHY=; b=aIM/AR0ckEHbfhllgBi5GZ+d4A1ysSN+yYsFAlOXEZmUhli51vPXW+ExudwJjwWP7C oUgoMn0XG244CsdQ4puvZDXi5QTWZdwXJ9y2tS35ZBVEG4dOB+WkLV2/09ExZVdVR+0A wwTzPVE+rqOINk43C2rQ9Y+JsqFhN8vZ3MrL29AOr3Q6tzUU/YngWZVaHlnrrMfWWVK2 bcqlG7dbMmMgMYkWluBAxWCcvb0P1++j5trdXQDyzzVuLZ16CQSzq8P7aheOpTjMBDU3 K4MbEfdcvTMRFTUoiE8Jb0PraYnqRUNzKh+MMLXVbsk7wlzxwmOHLklah+yQnIwoPHA5 p7Eg== X-Gm-Message-State: AKaTC01RyNlrss1YItn4fkgw4D6eXjIzJYiJtg/EkZ/O40DP4/UP+KbWvSko+ldmFwnMHA== X-Received: by 10.157.52.145 with SMTP id g17mr19613932otc.179.1480625290304; Thu, 01 Dec 2016 12:48:10 -0800 (PST) Received: from dhcp-128-107-151-84.cisco.com (dhcp-128-107-151-84.cisco.com. [128.107.151.84]) by smtp.gmail.com with ESMTPSA id 90sm572859otw.15.2016.12.01.12.48.09 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Dec 2016 12:48:09 -0800 (PST) From: Mahesh Jethanandani Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2D4FA314-718A-43C0-ABB9-B03189EBF772@gmail.com> Date: Thu, 1 Dec 2016 12:48:10 -0800 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] Minutes from IETF 97 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 20:56:42 -0000 First of all, the chairs would like to thank the note takers from IETF = 97. Folks who presented or who came to mike might want to look at the = notes to make sure their comments were accurately recorded. Please note that you can only update what was said in the meeting. These = notes and any updates received by December 8 will form the final = minutes. Thanks Mahesh & Mehmet = --------------------------------------------------------------------------= --------------------------------------------------------------------------= ------ Working group status: Assigned jabber scribe, note takers Displayed/explained Note Well Provided a status of chartered WG items since IETF 96 Agenda presentation and bashing Provided an updated of milestones (no objection noted to milestones = presented) =20 Andy Bierman: 8-12 months to update the draft (RESTCONF Collection = Resource). Mehmet: 8-12 months is too long. Andy: Perhaps we can just drop it for the moment. Mehmet: Can we put it on hold? Conclusion seems to be to put it on hold. Benoit Claise: Can put it on hold, but a difficult choice. Whether = we do it now or later we reach the same conclusion. Until people agree = to do something that nothing happens. Perhaps just send the status to = the mailing list, or perhaps find a new editor. Mehmet asks room: Who knows this draft? Just a few hands shown? Mehmet asks room: Who is interesting in continuing this work? Just = Kent. Kent: RESTCONF is an incomplete solution without support for very = large lists, this needs to be done sooner or later, otherwise there will = be lots of proprietary solutions. Mehmet: Not keen on dropping this .... Andy: We have the same problem in NETCONF (i.e. large lists), and it = doesn't seem to be an issue there. Do we need to do this work? Mahesh asks room: Who is interested in working on the draft? Kent = showed interest in working on the draft after the current set of drafts = he has on his plate. Lada: Agrees that pagination would be useful, perhaps some existing = RESTful solution can be reused? Kent: Clarification, are you saying that we can just leverage an = existing solution? Lada: Yes. Kent: One of the co-authors already has such a solution, the aim now = is to make it standard. Mehmet: We will take this to the mailing list Benoit: Nice that Kent wants to work on this, but it shouldn't be a = top priority. Keytstore is the top priority Mehmet: Will decide on a milestone later. =20 Chair noted that based on dependencies Keystore draft is important = to complete =20 Chartered items: 1. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. = Watsen (15 min.) =20 https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-11=20 =20 =20 Kent presenting: Noted that there were no formal issues open but there might be a = problem with the complexity of bag of CRLs; use of CMS vs PKCS#7 and if the operators would even accept the = solution Ian Farriar: DT believes there are places where this can be useful Bob Moskowitz : You should look at doing an OpenSSL implementation. = I've done signing certificated on OpenSSL. This is a cheap solution = that you would never deploy in a production deployment but it provided = that the technology works. Kent: When saying operators he meant the larger community including = enterprises. Asked for clarification if the should be a reference = implementation using OpenSSL Bob: I would think so, you can pretty much do all of this. Used a = mail server as an example. Kent: There is an example in github, but currently isn't usable, but = I would try and make it so.??? Kent: ???Question to Ian, what was it???? Ian Farrer: ? Ian Farrer: RFC7223 gives an example. This won't work for DHCP4, so = will end up with a more complicated example. Kent: This can be a new open issue that will be addressed. Was = hoping that both these cases could be handled in the same way, but they = will need to be slightly different. Ian: ??? Kent: I'm not a DHCP expect, there might be a similar issue related = to a DNS server. Hopefully a DNS expect in the room that can help = review? [No one in the room offers] Benoit: Take it to DNSOPS mailing list, just reach to those guys. =20 Kent believes the draft is ready for last call. Kent asked if any has implemented or plans to implement the draft Rick Talyor: I want to implement this, but it is a better further = down the line. Andy: Indicated significant interest in call home, zero touch and = server modules Radek Krejci: We are working on it. Bob: I'm coming from DOTS WG, discussion about whether they will use = their own protocols, or use RESTCONF or NETCONF. DOTS have the problem = of inter organization trust issues. Trying to work whether Kent's draft = helps with this. I.e. can DOTS use this draft, or learn from it. Mehmet: Please can you take this discussion offline, but take it to = the mailing list. Kent is asking for last call, so please bring any = issues to the WG now. Kent said he would like to got WGLC after the next update Mehment: Noted that there is support to go to WGLC =20 Server Model Drafts: ------------------------- 2. Keystore Model - K. Watsen (10 min) https://tools.ietf.org/html/draft-ietf-netconf-keystore-00 =20 =20 Kent presenting: Keystore draft is highest priority, so will focus on that draft. Kent: Asks for questions. [No questions] Benoit: Are all drafts waiting on Keystore or something else Kent: No there is other work to be done other than Keystore =20 3. SSH Client Server Models - K. Watsen (5 min) = https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-01 4. TLS Client Server Models - K. Watsen (5 min) = https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-01=20 5. NETCONF Client Server Models - K. Watsen (5 min) = =20 = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-01=20= 6. RESTCONF Client Server Models - K. Watsen (5 min) = =20 = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-01 =20 All server model drafts above were presented together (notes under = "Keystore Model"). =20 =20 NETCONF Notification Drafts: ----------------------------------- 7. Subscribing to YANG datastore push updates - Eric Voit (15 min) = =20 https://tools.ietf.org/html/draft-ietf-netconf-yang-push-04=20 8. Subscribing for Event Notifications (RFC 5277bis) - Eric Voit (10 = min) https://tools.ietf.org/html/draft-ietf-netconf-rfc5277bis-01=20 9. NETCONF Support for Event Notifications - Eric Voit (5 min) = https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications= -01=20 10. RESTCONF & HTTP Transport for Event Notifications - Eric Voit (5 = min) https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif-01=20= 11. NETCONF Access Control Model - A. Bierman (10 min) =20 https://tools.ietf.org/html/draft-bierman-netconf-rfc6536bis-00=20= =20 Eric Voit presenting: Mehmet: Clarified that the design team is informal team open to = anyone, not chairs/AD organized. Informal design team has met 14 times, meetings/recordings are = available on Github site (as per slides) Jason Stern: Regarding dampening, there might still be some = inconsistencies in the draft. These have to do with per-object = dampening still appear in the text. He will mail out where he saw this. Eric: Please point out those inconsistencies on the mail list Eric: Asked if the streams need to be optional or mandatory (no = opinion from the room) Eric: There is an issue with filtering on meta-data - basically, = complex intersection filters across various forms of metadata are not = framed. Issue is independent of subscription. Expect something to = mailing list when fully articulated. Andy: Discussed filtering based on topics instead of data or content. = Topics would be based on YANG identities Andy: Is there interest in this type of filtering, to create a topic = tree, next to the model tree Kent: Requested clarification of topics Andy: Correct Kent: Requested clarification how this related to YANG PUSH Eric: A topic would be a filter on the data that is returned. Andy: Critical has been dropped. Rick: Adding metadata labels, but adds a load on the to the servers. Andy: Yes, it does add a load on the servers. Eric: Topic filtering will be a future work if there is interest Rob Wilton: I think that adding a sequence number would be a good = idea. =20 Eric presenting on RFC 5277bis =20 Eric presenting on Restconf/HTTP2 Rob Wilton: Asked if support should be HTTP2 mandatory and HTTP1.1 = optional Eric: Requested help in aligning the protocol with gRPC Benoit: [is nodding head]. There is someone in this room that knows = gRPC pretty well. Mahesh: Eric has already left. Benoit: Will introduce over e-mail. =20 Eric presenting Notif-netconf Eric asking room: Do you have any opinion of Call Home via a known = port?? [No comment from the room] [No futher questions] Mehmet: If no open provides any comments then the solution proposal = gets adopted, please can everyone provide their comments and opinions on = the solution proposal. Andy: If the design team didn't exist, there were still be drafts to = review, nothing in the process has changed. =20 =20 12: NetworkConfiguration Protocol (NETCONF) Access Control Model=20 Andy Bierman presenting Dean Bogdanovic: Can we use NACM with schema-mount? Andy: We will see if we need any edits here, or if we can keep that = complexity in schema-mount. Andy: Noted 2 issues left Schema Mount and I2RS Dean: Two new cases, one to see through the whole tree, (2) black = boxes, child can't see into the parent, parent can't see into the child. Martin Bjorklund: WG needs to adopt the draft first. Mehmet: Needs to understand all the issues with I2RS before adopting Andy: One issue is assigning priorities to clients, second issue is = related to access control on the dynamic datastores (e.g. I2RS) Lada: Noted an issue in RFC 6536 with parent/child relationships = that's important for RESTCONF. For example, if a client has read access = to a target node, does he also have read access to the ancestor nodes in = order to be able to read the target node's data? Is this addressed in = new draft? Andy: Can only select from subtree down, in RESTCONF I can set the = target URL to a subtree. Lada: It would be good to clarify these cases. Mehmet: Maybe sections that address the I2RS and schema mount issues = noted Mahesh: NACM has tried to solve Authentication and Authorization, but = is silent on Accounting. This is an issue for our customers. Is there = a standard defined for Accounting records. Is there interest in this = working group to try and formalize what an accounting record would look = like. Mehmet: Asked if there was interest in an accounting format (group = showed interest) Ashesh (=46rom Ciena): If this group does not define it, someone else = will. =20 Juergen + Martin + Balazs: Accounting should not be done in NACM; use = a different draft Martin: Authentication is not done in NACM, it only does = Authorization Dean: Clarified authorization from Authentication and Accounting from = authorization =20 Non-Chartered items: =20 =20 1. Voucher and Voucher Revocation Profiles for Bootstrapping = Protocols - K. Watsen (5 min) https://tools.ietf.org/html/draft-kwatsen-netconf-voucher-00=20 =20 Kent Watsen presenting: Kent asked if there were any comments on the encoding issue (no = comments; taking it to the list) Rick Taylor: Signing makes a point encoding (CBOR/YANG) Kent: Doesn't matter once it is in a file; its just signing the file. Mehmet: If you have any comments here - please bring them up on the = list Chairs noted that it might make sense to keep=20 Dean B: Other workings might have better use cases for the vouchers; = although they can bring back those needs here Mehmet: Does Anima have any other use case documents that explain = voucher uses Ken: Use and no; actually zerotouch does have some use cases Mehmet: Who is interested in working on draft in NETCONF? (5 people) Dean: Interested in working on the draft Benoit: Need to see from the Security ADs if anything (use cases or = work) has been done on vouchers Mehmet to Benoit: What would be the direction on how to determine = which group would adopt the draft Benoit: Need to coordinate this with the leadership of Security AD, = Anima and 6tisch =20 2. Datastore DT Discussion - Phil Shafer, et.al. (45 min) A Revised Conceptual Model for YANG Datastores = https://tools.ietf.org/html/draft-nmdsdt-netmod-revised-datastores-00=20 =20 Rob Wilton presenting: Mahesh: asked if anyone here has not seen this presentation in NETMOD = so we can focus on REST/NETCONF details Lada: Dynamic configuration is shown 2 is this a mistake Rob: No - it dependent on the origin Jason Sterne: Origin is good; noted the fix to operational-state Mahesh: Show of hand of supporting the solution into the netconf = (very good support) =20 Rob Presenting Protocol implications: Asked for comments on the datastores needed in NETCONF Kent: Asked clarification for if op-state was required Rob: ? Rob: Questions on how to return origin meta-data Martin: Leave get-config as is Rob: can we deprecate as its obsoleted by op-state Parviz Yegani : are datastores consistency in the draft Rob: Yes Parviz: Asked if there was consistency between multiple devices in = drafts Rob: No Parviz: Does latency become an issues Rob: Doesn't believe latency would be an issue Eric: Eventual consistency is the goal; latency isn't the issue Parviz: ? Rick Taylor: Clarify get/getdata if op-state is support; its part a = capability not sure what the question was.... Jurgen and Martin and Andy: get has a certain semantics; cant change = it Andy: shouldn't be deprecated Rob: Solution solves more than latency Martin: works fine with existing data models but not new ones Sue: What datastores does validate apply Kent: Validate should apply to the new datastores Rob: yes the datastores are intended applied and opstate Mehmet: Take it to the list =20 Presenting RESTCONF implications Andy: RESTCONF needs to remain simple opposed to changing restconf Kent: The change is necessary for future data models where the -state = part of the model no longer exists. Andy: ? Mehmet: Need to validate support for document on mailing list; to = NETMOD chair are we send work progress to both NETMOD and NETCONF list Lou: Yes - It will go to both lists but the process needs to be run = from one place Mehmet: NETMOD is the home Kent: Should we just CC NETCONF Lou: one message to both list and please discuss to both lists Andy: There are no drafts so there isn't any work for NETCONF Benoit: Charters will need updated of there no objection to the work =20 Session ended=E2=80=A6 From nobody Fri Dec 2 08:04:39 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F1D129705; Fri, 2 Dec 2016 08:04:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148069467767.29639.6481305304509372149.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 08:04:37 -0800 Archived-At: Cc: draft-ietf-netconf-yang-patch@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org Subject: [Netconf] Kathleen Moriarty's No Objection on draft-ietf-netconf-yang-patch-14: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 16:04:38 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-netconf-yang-patch-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my prior discuss question. From nobody Fri Dec 2 09:58:38 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0744C12944F; Fri, 2 Dec 2016 09:58:31 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148070151102.29693.7423536215499371074.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 09:58:31 -0800 Archived-At: Cc: netconf-chairs@ietf.org, The IESG , draft-ietf-netconf-yang-patch@ietf.org, rfc-editor@rfc-editor.org, netconf@ietf.org Subject: [Netconf] Protocol Action: 'YANG Patch Media Type' to Proposed Standard (draft-ietf-netconf-yang-patch-14.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 17:58:31 -0000 The IESG has approved the following document: - 'YANG Patch Media Type' (draft-ietf-netconf-yang-patch-14.txt) as Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ Technical Summary This draft defines YANG Patch, a method by which configuration can be modified on a device. It also defines a media type that can be used with HTTP Patch method to perform the YANG Patch. Working Group Summary This document is a companion document to YANG 1.1 (draft-ietf-netmod-rfc6020bis) and is meant to be used with YANG 1.1. It describes a method for applying patch to configuration datastores. Document Quality This document was extensively reviewed and comments were provided both in IETF meetings and on the mailing list. Personnel The document shepherd is Mahesh Jethanandani. The responsible AD will be Benoit Claise. https://www.iana.org/assignments/xml-registry expert: Tim Bray, Martin Thomson From nobody Fri Dec 2 12:28:29 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E21128824 for ; Fri, 2 Dec 2016 12:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoDDrJWidiqe for ; Fri, 2 Dec 2016 12:28:26 -0800 (PST) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A27128E18 for ; Fri, 2 Dec 2016 12:28:26 -0800 (PST) Received: by mail-io0-x241.google.com with SMTP id h133so2003866ioe.2 for ; Fri, 02 Dec 2016 12:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=eqn5JLMaI1jvAbKESFbI3IqovPwC7iVNVa/glTYHFmE=; b=pUw5f7vdVQMNQ1nrbAeGMNIV4Vu0HzSOsE7nvWXuC7r6Rx5cAwl4xlTE7kPjunLKwO CGrZifhPWZ/Bk1KbGKry+zS1z/5JcVemdIpmwx2zRNzIEBH9umEzXssJpv/H5ltEpb0r sDpcLQ/5Jc/0A0f+9raEBb/5YpLCeY7tWHLLFjmlNO6CEubdt8TcpFQw4t5GvyW1x0kj wxIw2XPp2ULVRaGBsN9gwDEwnCQS3sSYwX/GvNW5gxKXL9gn1hX26GYjAMtVGgyV1q7j ZIGr8MRv5tTrLluuQ1hIacP5629LC6858tOGJC2atbRCw4QWklFHgGugFGGKLHWlCFi+ Vj5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eqn5JLMaI1jvAbKESFbI3IqovPwC7iVNVa/glTYHFmE=; b=irlan4p8uiDYYIXfGnYu2xi1yoIJMvoGajV3V0iZ0uDr+AhHKq9bmmw0KwXNjZ5cr7 iyNNVgANR5UBcxCi2AH3BHSMbKLkL0eTw1HQ1Jbdhzn0GrtoZpg6OAjvzwMfkr1GtaF2 jsrRSt/6p7QtBVrAptwIfMbF4BHvYdu2BdjK7LKCOUS04w5n+SaXS3W2xxVPyb10LY/S u8wAsBMtdRZsBJ4sxyeSPyw6jHYZ0euQxQYyc4fS4UKhw3tiroIwnSaO3mYk7vYq/+AG g+MbWhrr4cG7g9uw+GChb3jqnQnRzXkpww31lIL7yBeINwXO5SqsTQytnAg7etyFrCTD ZZEw== X-Gm-Message-State: AKaTC03cMhfYNDP0VS3Yf4vlR6sFEyPmcRZa62HTGuHN1MtGv39fJmc6F5OoVFcMDS2QYHQ8263Q9uEbyOFm7A== X-Received: by 10.36.116.10 with SMTP id o10mr4269043itc.19.1480710506011; Fri, 02 Dec 2016 12:28:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.129.88 with HTTP; Fri, 2 Dec 2016 12:27:45 -0800 (PST) From: MehmetErsue Date: Fri, 2 Dec 2016 21:27:45 +0100 Message-ID: To: netconf@ietf.org Content-Type: multipart/alternative; boundary=001a114aa888b9e1b90542b2c7ab Archived-At: Subject: [Netconf] My mail address changed X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 20:28:28 -0000 --001a114aa888b9e1b90542b2c7ab Content-Type: text/plain; charset=UTF-8 New address is: mersue@gmail.com Mehmet --001a114aa888b9e1b90542b2c7ab Content-Type: text/html; charset=UTF-8
New address is: mersue@gmail.com

Mehmet

--001a114aa888b9e1b90542b2c7ab-- From nobody Fri Dec 2 12:44:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2192F1293DA for ; Fri, 2 Dec 2016 12:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtmHDYXZOOVx for ; Fri, 2 Dec 2016 12:44:16 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 CF53F1293E9 for ; Fri, 2 Dec 2016 12:44:15 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id c21so458713140ioj.1 for ; Fri, 02 Dec 2016 12:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KfVhJJ6kVsLc2adcOFXP9ubtdDBBJxRp9zi0WWucKl0=; b=CecYHWpyS/QRvmhFSafn18KfLiAodVzB+qunjrgGGNLFOnKAxPE6+/fiAaE5sUUsk8 wYUVjZIl/1qrX3APa4fxwxEUQCyHGag+IHI0t626M8dlQKRK1qgDjNCphBlYICpZP1s3 /UxJFarqlXx2Dh9IMngw81klQ25wHbT2ea3pTFdc2jgW/3AOmQ4sajJ1RTQfczdI0caz o2U2Qex0hJ66cuAEhJr2RoniYoUPsvHnxMeKZa40ZtbuDOOFlGuVZD+UBVqc2qP2+MDT 9wu0VYMt3xKMW/RbAri7ROLE6ZVBQ15SRdFLOl09ViMqWigr6tRtqRweoCNPzITnwEUQ M9cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KfVhJJ6kVsLc2adcOFXP9ubtdDBBJxRp9zi0WWucKl0=; b=XbHGz74iR9hpamDQGWS6X55iFFAHUyiUPUsGMSYPdlY+KFGiPgLFmRNZyjIz2i6H9T NaaQZTydYD995n7QLLEPbHI5jBFClPjKNkKTFcrBNas6t+DO31z6elcC/6Mv0XCoyzR+ X2pFDmsc4PrxWv2q+oZ/+P7u+MGMSp6nfhcvFpbGRpQFhudt+XDC5h/5kUW7Zdo4sEIJ 77YbuyxaVrHXJn9syI53Dgdkm8z6a4sj3fZPChYihqPg54JkzRJOEv2xh2/5u7JGRFwa ghHv/7hqZPuv23IcAsOX1BIDS1NOe99XqFYuDa2f2mNVd1Wc7AmS9ZATjqpJFToRGe2b +Qvw== X-Gm-Message-State: AKaTC00tPzydgiW+wmxEZmG16Gk1ZGHAmSzhQI4h/p3cAQ/q5RvKfWglrUc9kNcARXPRB/Jx7zcLrKEHOOeLvA== X-Received: by 10.107.53.36 with SMTP id c36mr39822442ioa.55.1480711454861; Fri, 02 Dec 2016 12:44:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.129.88 with HTTP; Fri, 2 Dec 2016 12:43:34 -0800 (PST) In-Reply-To: References: From: MehmetErsue Date: Fri, 2 Dec 2016 21:43:34 +0100 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a1144939a484be00542b30053 Archived-At: Cc: "netconf@ietf.org" , "Mahesh Jethanandani \(mahesh\)" Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 20:44:24 -0000 --001a1144939a484be00542b30053 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Eric, All, yes, we need a charter change since there is a difference between enhancing and replacing. As I remember the charter discussion people were keen of having backwards compatibility because of deployed implementations. I believe we need to understand better the implications and what kind of "replacing" we would strive for. Does replacing mean full deprecation of 5277 or will the compatibility between e.g. old client and new server be possible? I believe we need a discussion on this on the maillist and get the opinion of all parties. At the end the WG will decide. @All: Please comment on replacing instead of enhancing 5277. Please explain why you are in favor of replacing or against. If you are in favor please explain what kind of replacing (i.e. compatibility level) you would like to have. If you are in favor of keeping 5277 as standard and developing an additional independent notification mechanism please make its case. Thanks, Mehmet On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit) wrote: > Hi Mehmet, > > Hi Mahesh, > > Hi Benoit, > > > > Item #6 in the NETCONF charter is: =E2=80=9CEnhance RFC 5277 with the abi= lity to > delete subscriptions without closing the client session, to modify existi= ng > subscriptions, and to have multiple subscriptions on an established clien= t > session. These changes should not affect older clients that do not suppor= t > these particular subscription requirements. The RPCs and the data models > in RFC 5277 should be converted to YANG.=E2=80=9D > > > > Those attending the Event Notification Dezign Team today believe that it > is better to Obsolete 5277 it rather than Enhance it. The main reasons > are: > > =C2=B7 The existing 5277 rpc and the new rpcs= need > to be in independent namespaces. Not supporting 5277 > and a separate namespace / model will significantly simplify the new > specification. > > =C2=B7 We can=E2=80=99t think of a reason why any YANG model develo= ped for > legacy 5277 namespace should be developed. New development is more likel= y > to focus on the new model and its new capabilities > > =C2=B7 Any clients & servers desiring to support the old capabiliti= es > can certainly do this. Independent capability sets can be advertised. > Backwards compatibility is not compromised. > > =C2=B7 Leaving backwards compatibility to embedded server code > significantly reduces new development needs. > > > > As obsoleting 5277 with this new spec is a significant step, we wanted to > get your and the community=E2=80=99s feedback and buy-in before we modify= any of > the documents in this direction. > > > > Would such a move mean a charter change? My suspicion is no as we are > enhancing the functions supported by 5277 (but without bringing along the > RPC). Do you have any guidance here? Is this worth having an interim > meeting to discuss and finalize? > > > > Thanks, > > Eric > > > > P.S.: Additional discussion on this is contained in minutes 2 to15 minute= s > of the WebEx audio recording below. > > > > *From:* Eric Voit, November 30, 2016 5:58 PM > > Minutes posted at: > > https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-11-30 > > =C2=B7 As always, our DezignTM Team is a gathering of individuals > providing informal input to NETCONF. We ask NETCONF WG to comment on our > discussion results as a preparation for the WG consensus. Please approach > Eric Voit if you want to be included directly in these meetings. > > > > *Meeting Materials* > > *Attending* > > WebEx Recording > > > password: bXeveFV5 > > Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eri= c > Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika Tripathy, Sharon > Chisholm > > *Obsolete RFC5277 or 5277bis?* > > - If you are going to support both old and new capabilities, you will > have your old 5277 code, and you will have your new code. Why develop = a > backwards compatible part of the spec which no one would or should > implement. People should develop to the new capability. > - 5277 already has enough changes to it (e.g., dataplane has moved > to 6241 filtered notifications) > - Recommendation for people on today's call is to Obsolete 5277 > - Must go to the WG, its chairs, and Benoit to confirm this > recommendation before we adjust current documentation > > *Changes to the documents discussed today* > > *[5277bis]* > > - Scrub for error types in various subscription states. Authorization > and other errors should be reported using the protocol-specific error > codes; not specialized errors per these new RPCs. They still need to b= e > identified though. Distinguish error types from subscription state so = that > you know the state a particular error happened during. > - Expose operational state of subscriptions in a separate YANG model > or container. (i.e., add =E2=80=9C-state=E2=80=9D into naming conventi= on for the ro part) > - Should subscription-id and filter-id both be id? (double-check, but > we can do to the shorter description =E2=80=9Cidentifier=E2=80=9D) > - Do we rename push-source to =E2=80=9Coriginates from=E2=80=9D to be = more > explicit/accurate? (better name is needed. Include it in the terminolo= gy > section.) > - Section 2.3 has SHOULD for 5277 filters. Not sure why this isn=E2=80= =99t a > MUST. Also we need a better name for 5277 filters. This name doesn=E2= =80=99t expose > what is possible, and what is not. Especially if we jettison 5277 > compatibility, we need a better name for 6241, and we need to define t= he > boundaries of filter solution. Andy has a strawman proposal. > - Delete create-subscription RPC and legacy namespace should WG agree. > - Do we do a test-only operation? (Let=E2=80=99s not do this work with= out an > advocate) > - We need a way to test if the filters are doing what we expect they > are doing. (Perhaps counters/captures on an active subscription?) > - For configured subscriptions, make receiver key ip address and port. > At this point we don=E2=80=99t want VRF > - Change source-vrf description to indicate that we should align with > names from draft-ietf-rtgwg-ni-model-01 should it complete in time. > - start-time in the YANG model from startTime as we don=E2=80=99t have= to > worry about backwards compatible RPC. > - Make stream type string rather than identity (preference for > identity, but not willing to fight. Note: this could change based on w= hat > happens with filters) > > *[Yang-push]* > > - Need to define error type for each subscription parameter such as > =E2=80=9Cencoding not defined=E2=80=9D, =E2=80=9CFilter syntax not sup= ported=E2=80=9D or =E2=80=9Cfilter complexity > not supportable by platform=E2=80=9D. > - Section 3.1 =E2=80=93 Discussion on the Editors note - the addition = of a > =E2=80=9Cchanges-only=E2=80=9D flag for a periodic subscription. (Some= support for this, > but more discussion is needed as the work is non-trivial.) > - Section 3.8.4 =E2=80=93 recommend removal (ok) > - Section 4.4: reduce this just to the new parameters (can we remove > this entirely considering section 3.1? Or do we merge 3.1 into here?) = (Eric > talk to Alex, likely ok) > - Section 4.6.2 Is there any reason why we can=E2=80=99t have the time= stamp on > the yang push include the number of significant digits as expressed by > trailing zeros if necessary on the =E2=80=9Ctime-of-update=E2=80=9D. T= his would let > platforms express what they are capable of doing. (Note: seconds would= be a > minimum granularity). (we should go with this if possible. Susan H. is > going to check on binary representations here to see if variable field > lengths might pose a problem for an update.) > - Section 4.6.2 Do we do something on YANG-Push statistics (e.g. > counters of object changes, of update messages)? (Both=E2=80=A6 Test a= nd normal > operations need to be covered.. Match to filters working operation que= stion) > > *Dampening:* > > - Dampen can mean lessen. We should choose Damp or Dampen based on > usage therefore. > - Google search for =E2=80=9Croute damping=E2=80=9D =3D 4,850 hits. > - Google search for =E2=80=9Croute dampening=E2=80=9D =3D 11,600 hi= ts > - The more common usage is dampening, so we should stick with that. > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --=20 Cheers, Mehmet --001a1144939a484be00542b30053 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Eric, All,

yes, we need a charter chan= ge since there is a=20 difference between enhancing and replacing.
As I remember=20 the charter discussion people were keen of having backwards compatibility= =20 because of deployed implementations.

I believe we need to=20 understand better the implications and what kind of "replacing" w= e would strive for.
Does=20 replacing mean full deprecation of 5277 or will the compatibility between e= .g. old client and new server be possible?

I believe we need a disc= ussion on this on the maillist and get the opinion of all parties.
At th= e end the WG will decide.

@All:
Please comment on replacin= g instead of enhancing 5277.
Please explain why you are in favor o= f replacing or against.
If you are in favor please explain what kind of = replacing (i.e. compatibility level) you would like to have.
If you= are in favor of keeping 5277 as standard and developing an additional inde= pendent notification mechanism please make its case.

Thanks,
Mehmet

On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoi= t) <evoit@cisco.com> wrote:

Hi Mehmet,

Hi Mahesh,

Hi Benoit,

=C2=A0

Item #6 in the NETCONF charter is: = =E2=80=9CEnhance RFC 5277 with the ability to delete subscriptions without= =C2=A0closing the client session, to modify existing subscriptions, and to=C2=A0have multiple subscriptions on an established client session. = These=C2=A0changes should not affect older clients that do not support thes= e=C2=A0particular subscription requirements. The RPCs and the data models i= n=C2=A0RFC 5277 should be converted to YANG.=E2=80=9D<= /p>

=C2=A0

Those attending the Event Notificatio= n Dezign Team today believe that it is better to Obsolete 5277 it rather th= an Enhance it.=C2=A0=C2=A0 The main reasons are:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The existing 5277 <create sub= scription> rpc and the new rpcs need to be in independent namespaces. No= t supporting 5277 <create subscription> and a separate namespace / model will significantly simplify the new specification.=C2=A0=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 We can=E2=80=99t think of a reas= on why any YANG model developed for legacy 5277 namespace should be develop= ed.=C2=A0 New development is more likely to focus on the new model and its new capabilities

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Any clients & servers desiri= ng to support the old capabilities can certainly do this.=C2=A0 Independent= capability sets can be advertised.=C2=A0 Backwards compatibility is not compromised.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Leaving backwards compatibility = to embedded server code significantly reduces new development needs.=

=C2=A0

As obsoleting 5277 with this new spec= is a significant step, we wanted to get your and the community=E2=80=99s f= eedback and buy-in before we modify any of the documents in this direction.

=C2=A0

Would such a move mean a charter chan= ge?=C2=A0=C2=A0 My suspicion is no as we are enhancing the functions suppor= ted by 5277 (but without bringing along the RPC).=C2=A0 Do you have any guidance here?=C2=A0=C2=A0 Is this worth having an interim meetin= g to discuss and finalize?

=C2=A0

Thanks,

Eric

=C2=A0

P.S.: Additional discussion on this i= s contained in minutes 2 to15 minutes of the WebEx audio recording below.

= =C2=A0

From: Eric Voit, November 30, 2016 5= :58 PM

Minutes posted at:

https://github.com/netconf-wg/yang-push/wiki/M= inutes-2016-11-30

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As always, our DezignTM T= eam is a gathering of individuals providing informal input to NETCONF. We a= sk NETCONF WG to comment on our discussion results as a preparation for the WG consensus. Please approach Eric Voit i= f you want to be included directly in these meetings.<= /p>

=C2=A0

M= eeting Materials

A= ttending

WebEx Recording

password: bXeveFV5=

Andy Bierman, Alexander C= lemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs= Lengyel, Susan Hares Ambika Tripathy, Sharon Chisholm=

Obsolete RFC5277 or 5277bis?

  • If you are going t= o support both old and new capabilities, you will have your old 5277 code, = and you will have your new code. Why develop a backwards compatible part of= the spec which no one would or should implement. People should develop to the new capability.
    • 5277 already has e= nough changes to it (e.g., dataplane has moved to 6241 filtered notificatio= ns)
  • Recommendation for= people on today's call is to Obsolete 5277
    • Must go to the WG,= its chairs, and Benoit to confirm this recommendation before we adjust cur= rent documentation

Changes to the documents discussed today

[5277bis]

  • Scrub for error ty= pes in various subscription states. Authorization and other errors should b= e reported using the protocol-specific error codes; not specialized errors = per these new RPCs. They still need to be identified though. Distinguish error types from subscription state so that you know t= he state a particular error happened during.
  • Expose operational= state of subscriptions in a separate YANG model or container. (i.e., add = =E2=80=9C-state=E2=80=9D into naming convention for the ro part)<= /u>
  • Should subscriptio= n-id and filter-id both be id? (double-check, but we can do to the shorter = description =E2=80=9Cidentifier=E2=80=9D)
  • Do we rename push-= source to =E2=80=9Coriginates from=E2=80=9D to be more explicit/accurate? (= better name is needed. Include it in the terminology section.)
  • Section 2.3 has SH= OULD for 5277 filters. Not sure why this isn=E2=80=99t a MUST. Also we need= a better name for 5277 filters. This name doesn=E2=80=99t expose what is p= ossible, and what is not. Especially if we jettison 5277 compatibility, we need a better name for 6241, and we need to define the boundaries of fi= lter solution. Andy has a strawman proposal.
  • Delete create-subs= cription RPC and legacy namespace should WG agree.
  • Do we do a test-on= ly operation? (Let=E2=80=99s not do this work without an advocate)
  • We need a way to t= est if the filters are doing what we expect they are doing. (Perhaps counte= rs/captures on an active subscription?)
  • For configured sub= scriptions, make receiver key ip address and port. At this point we don=E2= =80=99t want VRF
  • Change source-vrf = description to indicate that we should align with names from draft-ietf-rtg= wg-ni-model-01 should it complete in time.
  • start-time in the = YANG model from startTime as we don=E2=80=99t have to worry about backwards= compatible RPC.
  • Make stream type s= tring rather than identity (preference for identity, but not willing to fig= ht. Note: this could change based on what happens with filters)

[Yang-push]

  • Need to define err= or type for each subscription parameter such as =E2=80=9Cencoding not defin= ed=E2=80=9D, =E2=80=9CFilter syntax not supported=E2=80=9D or =E2=80=9Cfilt= er complexity not supportable by platform=E2=80=9D.
  • Section 3.1 =E2=80= =93 Discussion on the Editors note - the addition of a =E2=80=9Cchanges-onl= y=E2=80=9D flag for a periodic subscription. (Some support for this, but mo= re discussion is needed as the work is non-trivial.)
  • Section 3.8.4 =E2= =80=93 recommend removal (ok)
  • Section 4.4: reduc= e this just to the new parameters (can we remove this entirely considering = section 3.1? Or do we merge 3.1 into here?) (Eric talk to Alex, likely ok)<= u>
  • Section 4.6.2 Is t= here any reason why we can=E2=80=99t have the timestamp on the yang push in= clude the number of significant digits as expressed by trailing zeros if ne= cessary on the =E2=80=9Ctime-of-update=E2=80=9D. This would let platforms express what they are capable of doing. (Note: seconds would be a minimum = granularity). (we should go with this if possible. Susan H. is going to che= ck on binary representations here to see if variable field lengths might po= se a problem for an update.)
  • Section 4.6.2 Do w= e do something on YANG-Push statistics (e.g. counters of object changes, of= update messages)? (Both=E2=80=A6 Test and normal operations need to be cov= ered.. Match to filters working operation question)

Dampening:

  • Dampen can mean le= ssen. We should choose Damp or Dampen based on usage therefore.
    • Google search for = =E2=80=9Croute damping=E2=80=9D =3D 4,850 hits.
      • Google search for = =E2=80=9Croute dampening=E2=80=9D =3D 11,600 hits=
  • The more common us= age is dampening, so we should stick with that.

    • =C2=A0


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



--
Cheers,
Mehmet

--001a1144939a484be00542b30053-- From nobody Fri Dec 2 12:56:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A791293E8 for ; Fri, 2 Dec 2016 12:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVb7U80a5rWW for ; Fri, 2 Dec 2016 12:56:07 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 4F07E120725 for ; Fri, 2 Dec 2016 12:56:07 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id c21so459214109ioj.1 for ; Fri, 02 Dec 2016 12:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Uried/29UzxiiqRNU/NpW3bcYEpyxtFypJP6ZO3UkUE=; b=0MNFBXoz6o+Bow3mwZuajmjrWrj123419lj8TjjiWw/WUfwux2eC9w3CW+7wuUzbDp gxKmVz3iVHc1QGH21P3fgRRVt/DyNnMBQihUjTF1HxglwS4Mecyl077BFN/u5tqhOfPZ ed8cvQ+itARj9Ws3eM4TZ1bsyPkD7D4xWOjUokghhP1a2w+HmV0+a0o8aYpVPyWNaMK2 r7bxmZEd/CdyNczHZ6mvp2iXj+gGN9GiclQOxms0hMEs0WX3UEq3XEg1z5tpXvGHQak8 fL3yGqn2tcLcHNx62zcbbeL9d3fqx37VYBziw1xWO2DVoQIV1jqfffJ5vgNhEomdNlRf yu+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Uried/29UzxiiqRNU/NpW3bcYEpyxtFypJP6ZO3UkUE=; b=UtdBfon6fBItAicnfra2Y9T7neJFDo2M9AslHpJyBASduDHlDPhmzCGHMWVu5xZaGM qK1wmBWufo9Kt0iOS5Tfn4ygNvp1kA8J9N/un2bXN3dGAhmpw1jR5IseSzRBn/ztDe2j 1FgsY3gbCIrXRfgL79yrIeIYawkLiBMrSKnYj8cVT26hWfRJQ7Xl0ufj6ub68yfzn6Tw rLqXKUhY7F4pmKxTITl1N+zIspgJXXAZH0dRO/g9slpunDdzKMS8dM9deeRpJjK4EU+O kSVSJKE+mlw4Njo3Tp1VL3KHVJxpqrzPR4jPnVp8/s4dwYN53Jz/JGcvw7h35VleubKG czow== X-Gm-Message-State: AKaTC02inBltpYgd8JeqfH1AzMQoqxA//8pTENzW47HHFznvJtvrNGGPTwDmxgSBqXHwZvXovawM4H/jxyEb2g== X-Received: by 10.107.34.74 with SMTP id i71mr35633496ioi.24.1480712166562; Fri, 02 Dec 2016 12:56:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.129.88 with HTTP; Fri, 2 Dec 2016 12:55:26 -0800 (PST) In-Reply-To: References: From: MehmetErsue Date: Fri, 2 Dec 2016 21:55:26 +0100 Message-ID: To: Andy Bierman Content-Type: multipart/alternative; boundary=001a1140f254b3fc800542b32a39 Archived-At: Cc: Netconf Subject: Re: [Netconf] new NACM draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 20:56:09 -0000 --001a1140f254b3fc800542b32a39 Content-Type: text/plain; charset=UTF-8 Hi Andy, Martin, thank you for the initial draft. We discussed in IETF 97 different issues and the additional sections we could add. IIRC the list was: - schema-mount related text into schema-mount or the NACM draft, - assigning priorities to clients, - access control on dynamic datastores (e.g. I2RS), - the issue from RFC 6536 with parent/child relationships which is important for RESTCONF. I would like to suggest to have a discussion on these issues and understand whether they should be included. Mehmet On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman wrote: > Hi, > > A new version of draft-bierman-netconf-rfc6536bis has been posted: > https://www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt > > > We would like this draft to be adopted as the starting point for item #5 > in the current NETCONF charter. > > > > Andy and Martin > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > -- Cheers, Mehmet --001a1140f254b3fc800542b32a39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andy, Martin,

thank you for the = initial draft.

We discussed in IETF 97 different issues and the addi= tional sections we could add.
IIRC the list was:
- schema-mount= related text into schema-mount or the NACM draft,
- assigning prioritie= s to clients,
- access control on dynamic datastores (e.g. I2RS),
- = the issue from RFC 6536 with parent/child relationships which is important = for RESTCONF.

I would like to suggest to have a discussion on these issu= es and understand whether they should be included.

Mehmet

On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman <<= a href=3D"mailto:andy@yumaworks.com" target=3D"_blank">andy@yumaworks.com> wrote:
<= div dir=3D"ltr">Hi,

A new version of draft-bierman-netco= nf-rfc6536bis has been posted:
https://ww= w.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt


We would like this draft to be adopted= as the starting point for item #5
in the current NETCONF charter= .



Andy and Martin


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



--
Cheers,
Mehmet

--001a1140f254b3fc800542b32a39-- From nobody Fri Dec 2 13:09:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79428129409 for ; Fri, 2 Dec 2016 13:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Av4dRmtTmtA for ; Fri, 2 Dec 2016 13:09:38 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE185128E19 for ; Fri, 2 Dec 2016 13:09:37 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id n204so292020776qke.2 for ; Fri, 02 Dec 2016 13:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AUa2MBLz2NMB4va4EQ5+gNlB9xVaKw+aJf0BbIq4IUk=; b=FFKLfPvowlkYRRKR3ozVc5j4uTyMq5UWMl/JQiMM4GVHKpCEGNyvgAgAmNY1Y3xohB 576mDK35hvM90HP1/tUpH5b0lT+cBaq+AvamRWKCtykpzzlYecIYx4YAqqDn10Xw3Z7L QyPlS6K04BWc+e1oKJtqh0gFEpNBbSWizufm4nTQ/rcF3g+khbr5anq9qcnu/6xZVOO5 l/pgwMSK9dzHrmN/ewr/ZMwWY/vUpPtFtDHowsv/qqEJ7aTuOmpsOf8m9VkdZyQ3CrqF UyWRB49XNnQ/+LrNLc7vCN3iHEtsptaGK46dF5X1LMmWw1nkwud83c3085WbWxBo4JxZ B1GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AUa2MBLz2NMB4va4EQ5+gNlB9xVaKw+aJf0BbIq4IUk=; b=X/OPPkYpp7py+9v+NR8BQKtt8wbAlEfUwVN8wlrx87H75MdqSzXo58mUUXSDpPbCLy hotW8nuA2Kz0Xy4jsc48RAIWd/iNVZ/2ZQz1hFXbaW6nUxg54862zRK2ZSIFN4BuGCy9 rFYZ+40tDMxKDJ4XVLedRIpUK/3QmJoYmg2+dVcLlar8+rfcaih0i9/ZpgJQ88Lt0QXr sNAB84h6hNisBUIAmcfL/Ghu5w9iwqDetpnzoc9hwH2+Ngr6BKIDatKTKpwCN/1lp4CS JXqWCfSmh4qMvrDLzdhA1SY/AohU4YgMgqEF8LwNLDUHlK0SIRaYUdDAe2gdgqRjKdH3 N8Qg== X-Gm-Message-State: AKaTC028LTrzeL1IwYaDfy+8sg51WKw78O/YXpn5AokIYj97komK9LuJOf0RmKiBQJ7H5Nlc2BYV+KL8EW/X8g== X-Received: by 10.55.7.17 with SMTP id 17mr46613208qkh.228.1480712976898; Fri, 02 Dec 2016 13:09:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Fri, 2 Dec 2016 13:09:36 -0800 (PST) In-Reply-To: References: From: Andy Bierman Date: Fri, 2 Dec 2016 13:09:36 -0800 Message-ID: To: MehmetErsue Content-Type: multipart/alternative; boundary=001a1148cbea0131fb0542b35bc4 Archived-At: Cc: "netconf@ietf.org" , "Mahesh Jethanandani \(mahesh\)" Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:09:41 -0000 --001a1148cbea0131fb0542b35bc4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, This is a gray area. How much old functionality has to remain to call it a 'bis' draft? If we are working on new features hat do not exist in RFC 5277, using a 5277bis draft that obsoletes 5277 seems OK. I think the update rules only apply wrt/ standards track status. Since we are cycling at Proposed Standard, that does not matter. One option is to keep the 5277bis draft, but just remove all the parts that do not apply to the new solution. Andy On Fri, Dec 2, 2016 at 12:43 PM, MehmetErsue wrote: > Hi Eric, All, > > yes, we need a charter change since there is a difference between > enhancing and replacing. > As I remember the charter discussion people were keen of having backwards > compatibility because of deployed implementations. > > I believe we need to understand better the implications and what kind of > "replacing" we would strive for. > Does replacing mean full deprecation of 5277 or will the compatibility > between e.g. old client and new server be possible? > > I believe we need a discussion on this on the maillist and get the opinio= n > of all parties. > At the end the WG will decide. > > @All: > Please comment on replacing instead of enhancing 5277. > Please explain why you are in favor of replacing or against. > If you are in favor please explain what kind of replacing (i.e. > compatibility level) you would like to have. > If you are in favor of keeping 5277 as standard and developing an > additional independent notification mechanism please make its case. > > Thanks, > Mehmet > > > On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit) wrote= : > >> Hi Mehmet, >> >> Hi Mahesh, >> >> Hi Benoit, >> >> >> >> Item #6 in the NETCONF charter is: =E2=80=9CEnhance RFC 5277 with the ab= ility to >> delete subscriptions without closing the client session, to modify exist= ing >> subscriptions, and to have multiple subscriptions on an established clie= nt >> session. These changes should not affect older clients that do not suppo= rt >> these particular subscription requirements. The RPCs and the data models >> in RFC 5277 should be converted to YANG.=E2=80=9D >> >> >> >> Those attending the Event Notification Dezign Team today believe that it >> is better to Obsolete 5277 it rather than Enhance it. The main reasons >> are: >> >> =C2=B7 The existing 5277 rpc and the new rpc= s >> need to be in independent namespaces. Not supporting 5277 > subscription> and a separate namespace / model will significantly simpli= fy >> the new specification. >> >> =C2=B7 We can=E2=80=99t think of a reason why any YANG model devel= oped for >> legacy 5277 namespace should be developed. New development is more like= ly >> to focus on the new model and its new capabilities >> >> =C2=B7 Any clients & servers desiring to support the old capabilit= ies >> can certainly do this. Independent capability sets can be advertised. >> Backwards compatibility is not compromised. >> >> =C2=B7 Leaving backwards compatibility to embedded server code >> significantly reduces new development needs. >> >> >> >> As obsoleting 5277 with this new spec is a significant step, we wanted t= o >> get your and the community=E2=80=99s feedback and buy-in before we modif= y any of >> the documents in this direction. >> >> >> >> Would such a move mean a charter change? My suspicion is no as we are >> enhancing the functions supported by 5277 (but without bringing along th= e >> RPC). Do you have any guidance here? Is this worth having an interim >> meeting to discuss and finalize? >> >> >> >> Thanks, >> >> Eric >> >> >> >> P.S.: Additional discussion on this is contained in minutes 2 to15 >> minutes of the WebEx audio recording below. >> >> >> >> *From:* Eric Voit, November 30, 2016 5:58 PM >> >> Minutes posted at: >> >> https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-11-30 >> >> =C2=B7 As always, our DezignTM Team is a gathering of individuals >> providing informal input to NETCONF. We ask NETCONF WG to comment on our >> discussion results as a preparation for the WG consensus. Please approac= h >> Eric Voit if you want to be included directly in these meetings. >> >> >> >> *Meeting Materials* >> >> *Attending* >> >> WebEx Recording >> >> >> password: bXeveFV5 >> >> Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, >> Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika Tripathy, Sha= ron >> Chisholm >> >> *Obsolete RFC5277 or 5277bis?* >> >> - If you are going to support both old and new capabilities, you will >> have your old 5277 code, and you will have your new code. Why develop= a >> backwards compatible part of the spec which no one would or should >> implement. People should develop to the new capability. >> - 5277 already has enough changes to it (e.g., dataplane has moved >> to 6241 filtered notifications) >> - Recommendation for people on today's call is to Obsolete 5277 >> - Must go to the WG, its chairs, and Benoit to confirm this >> recommendation before we adjust current documentation >> >> *Changes to the documents discussed today* >> >> *[5277bis]* >> >> - Scrub for error types in various subscription states. Authorization >> and other errors should be reported using the protocol-specific error >> codes; not specialized errors per these new RPCs. They still need to = be >> identified though. Distinguish error types from subscription state so= that >> you know the state a particular error happened during. >> - Expose operational state of subscriptions in a separate YANG model >> or container. (i.e., add =E2=80=9C-state=E2=80=9D into naming convent= ion for the ro part) >> - Should subscription-id and filter-id both be id? (double-check, but >> we can do to the shorter description =E2=80=9Cidentifier=E2=80=9D) >> - Do we rename push-source to =E2=80=9Coriginates from=E2=80=9D to be= more >> explicit/accurate? (better name is needed. Include it in the terminol= ogy >> section.) >> - Section 2.3 has SHOULD for 5277 filters. Not sure why this isn=E2= =80=99t a >> MUST. Also we need a better name for 5277 filters. This name doesn=E2= =80=99t expose >> what is possible, and what is not. Especially if we jettison 5277 >> compatibility, we need a better name for 6241, and we need to define = the >> boundaries of filter solution. Andy has a strawman proposal. >> - Delete create-subscription RPC and legacy namespace should WG agree= . >> - Do we do a test-only operation? (Let=E2=80=99s not do this work wit= hout an >> advocate) >> - We need a way to test if the filters are doing what we expect they >> are doing. (Perhaps counters/captures on an active subscription?) >> - For configured subscriptions, make receiver key ip address and >> port. At this point we don=E2=80=99t want VRF >> - Change source-vrf description to indicate that we should align with >> names from draft-ietf-rtgwg-ni-model-01 should it complete in time. >> - start-time in the YANG model from startTime as we don=E2=80=99t hav= e to >> worry about backwards compatible RPC. >> - Make stream type string rather than identity (preference for >> identity, but not willing to fight. Note: this could change based on = what >> happens with filters) >> >> *[Yang-push]* >> >> - Need to define error type for each subscription parameter such as >> =E2=80=9Cencoding not defined=E2=80=9D, =E2=80=9CFilter syntax not su= pported=E2=80=9D or =E2=80=9Cfilter complexity >> not supportable by platform=E2=80=9D. >> - Section 3.1 =E2=80=93 Discussion on the Editors note - the addition= of a >> =E2=80=9Cchanges-only=E2=80=9D flag for a periodic subscription. (Som= e support for this, >> but more discussion is needed as the work is non-trivial.) >> - Section 3.8.4 =E2=80=93 recommend removal (ok) >> - Section 4.4: reduce this just to the new parameters (can we remove >> this entirely considering section 3.1? Or do we merge 3.1 into here?)= (Eric >> talk to Alex, likely ok) >> - Section 4.6.2 Is there any reason why we can=E2=80=99t have the tim= estamp >> on the yang push include the number of significant digits as expresse= d by >> trailing zeros if necessary on the =E2=80=9Ctime-of-update=E2=80=9D. = This would let >> platforms express what they are capable of doing. (Note: seconds woul= d be a >> minimum granularity). (we should go with this if possible. Susan H. i= s >> going to check on binary representations here to see if variable fiel= d >> lengths might pose a problem for an update.) >> - Section 4.6.2 Do we do something on YANG-Push statistics (e.g. >> counters of object changes, of update messages)? (Both=E2=80=A6 Test = and normal >> operations need to be covered.. Match to filters working operation qu= estion) >> >> *Dampening:* >> >> - Dampen can mean lessen. We should choose Damp or Dampen based on >> usage therefore. >> - Google search for =E2=80=9Croute damping=E2=80=9D =3D 4,850 hits= . >> - Google search for =E2=80=9Croute dampening=E2=80=9D =3D 11,600 h= its >> - The more common usage is dampening, so we should stick with that. >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > > > -- > Cheers, > Mehmet > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a1148cbea0131fb0542b35bc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This is a gray area. How much old f= unctionality
has to remain to call it a 'bis' draft?
If we are working on new features hat do not exist in RFC 5277,
=
using a 5277bis draft that obsoletes 5277 seems OK.
I think = the update rules only apply wrt/ standards track status.
Since we= are cycling at Proposed Standard, that does not matter.

One option is to keep the 5277bis draft, but just remove all the par= ts that
do not apply to the new solution.


Andy

=
On Fri, Dec 2, 2016 at 12:43 PM, MehmetErsue= <mersue@gmail.com> wrote:
=
Hi Eric, All,

yes, we need a charter chan= ge since there is a=20 difference between enhancing and replacing.
As I remember=20 the charter discussion people were keen of having backwards compatibility= =20 because of deployed implementations.

I believe we need to=20 understand better the implications and what kind of "replacing" w= e would strive for.
Does=20 replacing mean full deprecation of 5277 or will the compatibility between e= .g. old client and new server be possible?

I believe we need a disc= ussion on this on the maillist and get the opinion of all parties.
At th= e end the WG will decide.

@All:
Please comment on replacin= g instead of enhancing 5277.
Please explain why you are in favor o= f replacing or against.
If you are in favor please explain what kind of = replacing (i.e. compatibility level) you would like to have.
If you= are in favor of keeping 5277 as standard and developing an additional inde= pendent notification mechanism please make its case.

Thanks,
Mehmet

On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoi= t) <evoit@cisco.com> wrote:

Hi Mehmet,

Hi Mahesh,

Hi Benoit,

=C2=A0

Item #6 in the NETCONF charter is: = =E2=80=9CEnhance RFC 5277 with the ability to delete subscriptions without= =C2=A0closing the client session, to modify existing subscriptions, and to=C2=A0have multiple subscriptions on an established client session. = These=C2=A0changes should not affect older clients that do not support thes= e=C2=A0particular subscription requirements. The RPCs and the data models i= n=C2=A0RFC 5277 should be converted to YANG.=E2=80=9D<= /p>

=C2=A0

Those attending the Event Notificatio= n Dezign Team today believe that it is better to Obsolete 5277 it rather th= an Enhance it.=C2=A0=C2=A0 The main reasons are:

= =C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The existing 5277 <create sub= scription> rpc and the new rpcs need to be in independent namespaces. No= t supporting 5277 <create subscription> and a separate namespace / model will significantly simplify the new specification.=C2=A0=

= =C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 We can=E2=80=99t think of a reas= on why any YANG model developed for legacy 5277 namespace should be develop= ed.=C2=A0 New development is more likely to focus on the new model and its new capabilities

= =C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Any clients & servers desiri= ng to support the old capabilities can certainly do this.=C2=A0 Independent= capability sets can be advertised.=C2=A0 Backwards compatibility is not compromised.

= =C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Leaving backwards compatibility = to embedded server code significantly reduces new development needs.=

=C2=A0

As obsoleting 5277 with this new spec= is a significant step, we wanted to get your and the community=E2=80=99s f= eedback and buy-in before we modify any of the documents in this direction.

=C2=A0

Would such a move mean a charter chan= ge?=C2=A0=C2=A0 My suspicion is no as we are enhancing the functions suppor= ted by 5277 (but without bringing along the RPC).=C2=A0 Do you have any guidance here?=C2=A0=C2=A0 Is this worth having an interim meetin= g to discuss and finalize?

=C2=A0

Thanks,

Eric

=C2=A0

P.S.: Additional discussion on this i= s contained in minutes 2 to15 minutes of the WebEx audio recording below.

= =C2=A0

From: Eric Voit, November 30, 2016 5= :58 PM

Minutes posted at:

https://github.com/netconf-wg/yang-push/wiki/M= inutes-2016-11-30

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As always, our DezignTM T= eam is a gathering of individuals providing informal input to NETCONF. We a= sk NETCONF WG to comment on our discussion results as a preparation for the WG consensus. Please approach Eric Voit i= f you want to be included directly in these meetings.<= /p>

=C2=A0

M= eeting Materials

A= ttending

WebEx Recording

password: bXeveFV5=

Andy Bierman, Alexander C= lemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs= Lengyel, Susan Hares Ambika Tripathy, Sharon Chisholm=

Obsolete RFC5277 or 5277bis?

  • If you are going t= o support both old and new capabilities, you will have your old 5277 code, = and you will have your new code. Why develop a backwards compatible part of= the spec which no one would or should implement. People should develop to the new capability.
    • 5277 already has e= nough changes to it (e.g., dataplane has moved to 6241 filtered notificatio= ns)
  • Recommendation for= people on today's call is to Obsolete 5277
    • Must go to the WG,= its chairs, and Benoit to confirm this recommendation before we adjust cur= rent documentation

Changes to the documents discussed today

[5277bis]

  • Scrub for error ty= pes in various subscription states. Authorization and other errors should b= e reported using the protocol-specific error codes; not specialized errors = per these new RPCs. They still need to be identified though. Distinguish error types from subscription state so that you know t= he state a particular error happened during.
  • Expose operational= state of subscriptions in a separate YANG model or container. (i.e., add = =E2=80=9C-state=E2=80=9D into naming convention for the ro part)<= /u>
  • Should subscriptio= n-id and filter-id both be id? (double-check, but we can do to the shorter = description =E2=80=9Cidentifier=E2=80=9D)
  • Do we rename push-= source to =E2=80=9Coriginates from=E2=80=9D to be more explicit/accurate? (= better name is needed. Include it in the terminology section.)
  • Section 2.3 has SH= OULD for 5277 filters. Not sure why this isn=E2=80=99t a MUST. Also we need= a better name for 5277 filters. This name doesn=E2=80=99t expose what is p= ossible, and what is not. Especially if we jettison 5277 compatibility, we need a better name for 6241, and we need to define the boundaries of fi= lter solution. Andy has a strawman proposal.
  • Delete create-subs= cription RPC and legacy namespace should WG agree.
  • Do we do a test-on= ly operation? (Let=E2=80=99s not do this work without an advocate)
  • We need a way to t= est if the filters are doing what we expect they are doing. (Perhaps counte= rs/captures on an active subscription?)
  • For configured sub= scriptions, make receiver key ip address and port. At this point we don=E2= =80=99t want VRF
  • Change source-vrf = description to indicate that we should align with names from draft-ietf-rtg= wg-ni-model-01 should it complete in time.
  • start-time in the = YANG model from startTime as we don=E2=80=99t have to worry about backwards= compatible RPC.
  • Make stream type s= tring rather than identity (preference for identity, but not willing to fig= ht. Note: this could change based on what happens with filters)

[Yang-push]

  • Need to define err= or type for each subscription parameter such as =E2=80=9Cencoding not defin= ed=E2=80=9D, =E2=80=9CFilter syntax not supported=E2=80=9D or =E2=80=9Cfilt= er complexity not supportable by platform=E2=80=9D.
  • Section 3.1 =E2=80= =93 Discussion on the Editors note - the addition of a =E2=80=9Cchanges-onl= y=E2=80=9D flag for a periodic subscription. (Some support for this, but mo= re discussion is needed as the work is non-trivial.)
  • Section 3.8.4 =E2= =80=93 recommend removal (ok)
  • Section 4.4: reduc= e this just to the new parameters (can we remove this entirely considering = section 3.1? Or do we merge 3.1 into here?) (Eric talk to Alex, likely ok)<= u>
  • Section 4.6.2 Is t= here any reason why we can=E2=80=99t have the timestamp on the yang push in= clude the number of significant digits as expressed by trailing zeros if ne= cessary on the =E2=80=9Ctime-of-update=E2=80=9D. This would let platforms express what they are capable of doing. (Note: seconds would be a minimum = granularity). (we should go with this if possible. Susan H. is going to che= ck on binary representations here to see if variable field lengths might po= se a problem for an update.)
  • Section 4.6.2 Do w= e do something on YANG-Push statistics (e.g. counters of object changes, of= update messages)? (Both=E2=80=A6 Test and normal operations need to be cov= ered.. Match to filters working operation question)

Dampening:

  • Dampen can mean le= ssen. We should choose Damp or Dampen based on usage therefore.
    • Google search for = =E2=80=9Croute damping=E2=80=9D =3D 4,850 hits.
      • Google search for = =E2=80=9Croute dampening=E2=80=9D =3D 11,600 hits=
  • The more common us= age is dampening, so we should stick with that.

    • =C2=A0


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

<= br clear=3D"all">
--
Cheers,
Mehmet


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

--001a1148cbea0131fb0542b35bc4-- From nobody Fri Dec 2 13:26:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76471129412 for ; Fri, 2 Dec 2016 13:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 IymbGQ0JvDh4 for ; Fri, 2 Dec 2016 13:26:46 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id E8AAF129416 for ; Fri, 2 Dec 2016 13:26:43 -0800 (PST) Received: (qmail 23211 invoked by uid 0); 2 Dec 2016 21:26:43 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 2 Dec 2016 21:26:43 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id F9Se1u0072SSUrH019ShAf; Fri, 02 Dec 2016 14:26:41 -0700 X-Authority-Analysis: v=2.1 cv=E8Je+8tl c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=hr3fZA_3Cl8A:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=p48BXsAlf3bYlEjPzqgA: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:Subject:From:Cc:To; bh=23u7vEoO9dSCuF+6vKz8Fz67xp449Qt8IMwHUjxHdPg=; b=j/uEtd+ldomqALAQkKjcyMUw8H tzcSxUntqsBl+0mWbcEeCJi2pF9RsrFzuVmhSHQPOGyRbazndPlenaJwE9Tjj9k/2VI0Moc7Su3hn l1tle0CFT5nCMj+PiI3FA0mlm; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:39607 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cCvLr-0004U5-Ml; Fri, 02 Dec 2016 14:26:39 -0700 To: NetMod WG , NetConf WG From: Lou Berger Message-ID: Date: Fri, 2 Dec 2016 16:26:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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.85.191 X-Exim-ID: 1cCvLr-0004U5-Ml X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:39607 X-Source-Auth: lberger@labn.net X-Email-Count: 10 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs Subject: [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:26:48 -0000 All, This is start of a two week poll on making draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group document. This document is unusual in that WG last call will be jointly held in both the NetConf and NetMod WGs, while adoption and day-to-day processing will take place in NetMod. 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 December 16. Thank you, NetConf and NetMod WG Chairs From nobody Fri Dec 2 13:44:44 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6280412941C for ; Fri, 2 Dec 2016 13:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 WoUM2ppQbSLm for ; Fri, 2 Dec 2016 13:44:39 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6E3129418 for ; Fri, 2 Dec 2016 13:44:35 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id p16so264106039qta.0 for ; Fri, 02 Dec 2016 13:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8IYpm5ZwkCvPjNbyZRDpiJWdiF21zKCncZB2vMgLRzA=; b=T6+hwjEa/YgrKP15PETgbESbI69W3ehZc5uw5Wav4CxMpLFvfWOrDea5Zvat9J9Jzi R3azPiIsZUNN3TDIpDDCItoqefTP0rAtRZSe48z36s2aDO9xIsFOSKOkryl5ASJBXEFp niMUIM4bmO52mhsOQTjFFYTaABNwepU0FQga20u9ZLiNNjRsR2ADY16IOZL4EmJtipG+ XplUbEqLKxYYjAEpik7Xfa44nigVCmgbHmdG7OH7zuF7UW9dame2k3gwPvM243hmZ6j3 5GO+AMNT36sKhgR3gXaBX6QcX/+NiTppOxQIKzl0u+HvKkM6mi/9V5JgLht+TfLf+lDx /ZYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8IYpm5ZwkCvPjNbyZRDpiJWdiF21zKCncZB2vMgLRzA=; b=Q8E6sQE3J3ZNOJbmCIO/85u6Wkv9C42rUfQCqzcn3GQQMjT9z9Iw8rziPPzIigkJtn MS99mUELpgNBFNAGQYC2vpz6y6nWXgv1PbxkwFZ7mn+JENULdTFddHwIBKei0sLpPHaY ieBEqdVQ7m/WRBR8SDJXrEqq31DadfsK3LkW5KHThYXAyyTCfEymIXlpm5JjIdHzH4KD YXDwd012JqgNn3ED18nnyQq5PdnERyy0Eu/9Zik10/k53yvK2JSShvtou9pKpQcTte2g 4DzKWaD+2kp//FSHPkeCXVlPVA9lM+/gS1CezTv8nEJ86m/2YVYqoC/o0nACGyllfWCG ELIg== X-Gm-Message-State: AKaTC033siYgBF7GRwhdfEz1rb7pyPHAvVW56/YJjz8H+6+ZYpVkQqZEqdzndUoY6cPPXqGpGgrR9p1P6Bfa4A== X-Received: by 10.237.63.25 with SMTP id p25mr39693832qtf.18.1480715074462; Fri, 02 Dec 2016 13:44:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Fri, 2 Dec 2016 13:44:34 -0800 (PST) In-Reply-To: References: From: Andy Bierman Date: Fri, 2 Dec 2016 13:44:34 -0800 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a1138ed6e06fc8f0542b3d8c4 Archived-At: Cc: NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs Subject: Re: [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:44:41 -0000 --001a1138ed6e06fc8f0542b3d8c4 Content-Type: text/plain; charset=UTF-8 Hi, Which specific NETMOD WG charter item authorizes this work? I have concerns about impact of this work on all YANG-based protocols. I have asked several times "how do you decide which servers need to implement the intended and applied datastores?" and never got an answer. I think an Applicability Statement is needed for this work because some systems converge so fast that the difference between intended and applied (for real edits, forget cards not plugged in) will be insignificant. Andy On Fri, Dec 2, 2016 at 1:26 PM, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > document. This document is unusual in that WG last call will be jointly > held in both the NetConf and NetMod WGs, while adoption and day-to-day > processing > will take place in NetMod. > > 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 December 16. > > Thank you, > NetConf and NetMod WG Chairs > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1138ed6e06fc8f0542b3d8c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Which specific NETMOD WG charter it= em authorizes this work?

I have concerns about imp= act of this work on all YANG-based protocols.
I have asked severa= l times "how do you decide which servers need to
implement t= he intended and applied datastores?" and never got an answer.

I think an Applicability Statement is needed for this work= because some systems
converge so fast that the difference betwee= n intended and applied
(for real edits, forget cards not plugged = in) will be insignificant.


Andy



On Fri, Dec 2, 2016 at 1:26 PM, Lou Berger <lberger@= labn.net> wrote:
All,

This is start of a two week poll on making
draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group
document.=C2=A0 This document is unusual in that WG last call will be joint= ly
held in both the NetConf and NetMod WGs, while adoption and day-to-day proc= essing
will take place in NetMod.

Please send email to the list indicating "yes/support" or "n= o/do not
support".=C2=A0 If indicating no, please state your reservations with = the
document.=C2=A0 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 December 16.

Thank you,
NetConf and NetMod WG Chairs

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

--001a1138ed6e06fc8f0542b3d8c4-- From nobody Fri Dec 2 13:46:39 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A7612941D; Fri, 2 Dec 2016 13:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8z_xXEBJhkg; Fri, 2 Dec 2016 13:46:32 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A265B12941A; Fri, 2 Dec 2016 13:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=941; q=dns/txt; s=iport; t=1480715192; x=1481924792; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4LEyasIEqJ9aVOq1Qed3SQTaEFzRlVykImySqf56V1A=; b=g8jzob3mfa3bc/lMJfhlkolAJV6G9Y9xHF5l49D+gSNMn+vDqf8P/EqB /KKywnOGiCv0kY2Tg64S2BFSBSItIwry217mb0gc+f3nzb62C97H+JiaY 0q+n2F8j6HkrIGcHnRW8UAaRv2AyoPWHn7CV6DsrEDuT8+AR/4uwizj9Z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQB160FY/49dJa1WBhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM4AQEBAQEfWoEGB40/rAeCBh4LhS9KAoIdPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRpAgQBATg0CxACAQgOKBAnCyUCBAENBYhvDq5li0QBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEXBYsZhBsRAQ6FbwWaYwGRE4FyhHyJS5IMAR83YTgjhTJyhlCBIYE?= =?us-ascii?q?NAQEB?= X-IronPort-AV: E=Sophos;i="5.33,288,1477958400"; d="scan'208";a="181708374" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 21:46:26 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uB2LkQcC029780 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2016 21:46: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.1210.3; Fri, 2 Dec 2016 16:46:25 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 2 Dec 2016 16:46:25 -0500 From: "Acee Lindem (acee)" To: Lou Berger , NetMod WG , NetConf WG Thread-Topic: [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 Thread-Index: AQHSTOLZwuoJLAnCWkuIzILo37i0BaD1MUUA Date: Fri, 2 Dec 2016 21:46: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.204] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:46:37 -0000 Yes/Support On 12/2/16, 4:26 PM, "netmod on behalf of Lou Berger" wrote: >All, > >This is start of a two week poll on making >draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group >document. This document is unusual in that WG last call will be jointly >held in both the NetConf and NetMod WGs, while adoption and day-to-day >processing >will take place in NetMod. > >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 December 16. > >Thank you, >NetConf and NetMod WG Chairs > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Dec 2 14:04:37 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819A5129426 for ; Fri, 2 Dec 2016 14:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 imXqFmFaZL2C for ; Fri, 2 Dec 2016 14:04:32 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id A06BD12942F for ; Fri, 2 Dec 2016 14:04:31 -0800 (PST) Received: (qmail 4989 invoked by uid 0); 2 Dec 2016 22:04:29 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 2 Dec 2016 22:04:29 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id FA4R1u00T2SSUrH01A4UdQ; Fri, 02 Dec 2016 15:04:29 -0700 X-Authority-Analysis: v=2.1 cv=Zpp+dbLG c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=7UnvXNs-l5HMQwuUSsoA: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:Cc:References:To:Subject; bh=JAl095fmHBtDoodxllT5aimewgeyeQ4PcPvQTRvpdlw=; b=THYgVsfm151YMS5slXLf5o6KYP N12YZhedTWDRWqzfTNmE4PK3kDyj4S0OjkS9CYR+cEoV5rlI3dFAyN68PvtiaFXM7NOm5wA+47R/T 5VKLjktbX5o72cQW/dq1vHEV7; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:33159 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cCvwP-0001AB-9k; Fri, 02 Dec 2016 15:04:25 -0700 To: Andy Bierman References: From: Lou Berger Message-ID: <1591c9b5-5949-bf16-0dee-f8d34cc45011@labn.net> Date: Fri, 2 Dec 2016 17:04:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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.85.191 X-Exim-ID: 1cCvwP-0001AB-9k X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:33159 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs Subject: [Netconf] Charter updates (was: WG adoption poll draft-nmdsdt-netmod-revised-datastores-00) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 22:04:33 -0000 Andy, There are different approaches to detail in charters, I'm personally comfortable with this work being covered by our/netmod current charter(under supporting ongoing deployment of YANG). This said, the chairs expect there to be discussions with our AD on respective charter updates. Obviously the WG will have an opportunity to provide input on any update. Do you have any specific changes you'd like to propose? Thanks, Lou On 12/2/2016 4:44 PM, Andy Bierman wrote: > Hi, > > Which specific NETMOD WG charter item authorizes this work? > > I have concerns about impact of this work on all YANG-based protocols. > I have asked several times "how do you decide which servers need to > implement the intended and applied datastores?" and never got an answer. > > I think an Applicability Statement is needed for this work because > some systems > converge so fast that the difference between intended and applied > (for real edits, forget cards not plugged in) will be insignificant. > > > Andy > > > > On Fri, Dec 2, 2016 at 1:26 PM, Lou Berger > wrote: > > All, > > This is start of a two week poll on making > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > document. This document is unusual in that WG last call will be > jointly > held in both the NetConf and NetMod WGs, while adoption and > day-to-day processing > will take place in NetMod. > > 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 December 16. > > Thank you, > NetConf and NetMod WG Chairs > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > From nobody Fri Dec 2 14:15:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7C412944F for ; Fri, 2 Dec 2016 14:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 AoWtlUsmi3NB for ; Fri, 2 Dec 2016 14:15:49 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542AA129449 for ; Fri, 2 Dec 2016 14:15:47 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id p16so264758594qta.0 for ; Fri, 02 Dec 2016 14:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KRSTtgEZbJn2/mAnz5KpGjDt64P45uF/C/B4kkBY8Wg=; b=Q33zLthpedG7aMbPx3/IRaaZ1L5oXg+jdXz5LoivUokKfaQn8cpy1XtjzoxxjY5Amj TxSMuEQ+g1sYl8vGsfFTz77wtb7t7VIaQNhtpagMNN3xLiNiKknVkPaIGLCaOFsRHczi ZLCnwary0u7i1UbE81QB6a6u1ytKCiyTvTvN/HuWdbTdP1JpeZzDFTBlzpue1g91vvsx dWXHrTKFibRJqMgCUp7/iXuuc8Rf3Al16uQ5jMcNNvIHeoe+qZY0uVocmGkXilO6dLHd 41EvogA3PRoTDuLdH9b4HJtEubkVsdEhCi7mLBYTK0VccleZJzzHaLMbPhAP+crW9yFj qcYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KRSTtgEZbJn2/mAnz5KpGjDt64P45uF/C/B4kkBY8Wg=; b=ienPi78sfvQkARpqjSAxRq5zk6Zfj1oDarBDqZ64QCj8hHINF4yyv7A41WffdzuEyC ytuqU3ySa/vg5ZDf3IkUSSJ1g9ewgKkI6YiJTcKoV/D8Sp+zUCO53gt39PWp5MCo3vw1 C5/Mg/yFG7Y/0rtqwNCrkZDLQNZxfUOt6eeYy802AlVhVbU4PbhN19GawoKBoK7tQeQt RBhuUus+gYki90mDNFT6/Xatz0+wybFxcyZcQm6px0Q98aq1115C+yQ0fiTqPJHzID2+ EpLpdMTWm5KEYAYl4osicqCprDLHNXR6ojYjkWWpdX8euQhigvwA87UT8SDPlReZFo6u mgBg== X-Gm-Message-State: AKaTC01SzUvv7A3lJ82t/QocfhHNvN7yzJyHY0YrxkBHTQXPIKjRWGV9m/pPTph3KOj5GQjPaLN+nQcGdeAbzQ== X-Received: by 10.200.37.52 with SMTP id 49mr39251698qtm.240.1480716946466; Fri, 02 Dec 2016 14:15:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Fri, 2 Dec 2016 14:15:46 -0800 (PST) In-Reply-To: <1591c9b5-5949-bf16-0dee-f8d34cc45011@labn.net> References: <1591c9b5-5949-bf16-0dee-f8d34cc45011@labn.net> From: Andy Bierman Date: Fri, 2 Dec 2016 14:15:46 -0800 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a1135b1ec9b87480542b44748 Archived-At: Cc: NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs Subject: Re: [Netconf] Charter updates (was: WG adoption poll draft-nmdsdt-netmod-revised-datastores-00) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 22:15:51 -0000 --001a1135b1ec9b87480542b44748 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 2, 2016 at 2:04 PM, Lou Berger wrote: > Andy, > > There are different approaches to detail in charters, I'm personally > comfortable with this work being covered by our/netmod current > charter(under supporting ongoing deployment of YANG). This said, the > chairs expect there to be discussions with our AD on respective charter > updates. Obviously the WG will have an opportunity to provide input on > any update. > > Do you have any specific changes you'd like to propose? > > I assume you mean this bullet in the charter: The NETMOD WG may also develop any additional data models written in YANG that the WG considers core building blocks and that do not fall under the charters of other active IETF working groups. The NETMOD WG may simply add such milestones as it sees fit, with the advice and consent of the responsible AD. I do not have charter changes to propose. > Thanks, > > Lou > > Andy > > On 12/2/2016 4:44 PM, Andy Bierman wrote: > > Hi, > > > > Which specific NETMOD WG charter item authorizes this work? > > > > I have concerns about impact of this work on all YANG-based protocols. > > I have asked several times "how do you decide which servers need to > > implement the intended and applied datastores?" and never got an answer. > > > > I think an Applicability Statement is needed for this work because > > some systems > > converge so fast that the difference between intended and applied > > (for real edits, forget cards not plugged in) will be insignificant. > > > > > > Andy > > > > > > > > On Fri, Dec 2, 2016 at 1:26 PM, Lou Berger > > wrote: > > > > All, > > > > This is start of a two week poll on making > > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > > document. This document is unusual in that WG last call will be > > jointly > > held in both the NetConf and NetMod WGs, while adoption and > > day-to-day processing > > will take place in NetMod. > > > > 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 December 16. > > > > Thank you, > > NetConf and NetMod WG Chairs > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > --001a1135b1ec9b87480542b44748 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 2, 2016 at 2:04 PM, Lou Berger <lberger@labn.net> wrote:
Andy,

There are different approaches to detail in charters, I'm personally comfortable with this work being covered by our/netmod current
charter(under supporting ongoing deployment of YANG).=C2=A0 This said, the<= br> chairs expect there to be discussions with our AD on respective charter
updates.=C2=A0 Obviously the WG will have an opportunity to provide input o= n
any update.

Do you have any specific=C2=A0 changes you'd like to propose?


I assume you mean this bullet in the c= harter:

The NETMOD WG may also develop any additional data models written in YAN= G that the WG considers core building blocks and that do not fall under the= charters of other active IETF working groups. The NETMOD WG may simply add= such milestones as it sees fit, with the advice and consent of the respons= ible AD.


I do not have chart= er changes to propose.


=C2=A0
=
Thanks,

Lou



Andy
=C2=A0

On 12/2/2016 4:44 PM, Andy Bierman wrote:
> Hi,
>
> Which specific NETMOD WG charter item authorizes this work?
>
> I have concerns about impact of this work on all YANG-based protocols.=
> I have asked several times "how do you decide which servers need = to
> implement the intended and applied datastores?" and never got an = answer.
>
> I think an Applicability Statement is needed for this work because
> some systems
> converge so fast that the difference between intended and applied
> (for real edits, forget cards not plugged in) will be insignificant. >
>
> Andy
>
>
>
> On Fri, Dec 2, 2016 at 1:26 PM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0All,
>
>=C2=A0 =C2=A0 =C2=A0This is start of a two week poll on making
>=C2=A0 =C2=A0 =C2=A0draft-nmdsdt-netmod-revised-datastores-00 a Ne= tMod working group
>=C2=A0 =C2=A0 =C2=A0document.=C2=A0 This document is unusual in that WG= last call will be
>=C2=A0 =C2=A0 =C2=A0jointly
>=C2=A0 =C2=A0 =C2=A0held in both the NetConf and NetMod WGs, while adop= tion and
>=C2=A0 =C2=A0 =C2=A0day-to-day processing
>=C2=A0 =C2=A0 =C2=A0will take place in NetMod.
>
>=C2=A0 =C2=A0 =C2=A0Please send email to the list indicating "yes/= support" or "no/do not
>=C2=A0 =C2=A0 =C2=A0support".=C2=A0 If indicating no, please state= your reservations with the
>=C2=A0 =C2=A0 =C2=A0document.=C2=A0 If yes, please also feel free to pr= ovide comments you'd
>=C2=A0 =C2=A0 =C2=A0like
>=C2=A0 =C2=A0 =C2=A0to see addressed once the document is a WG document= .
>
>=C2=A0 =C2=A0 =C2=A0The poll ends December 16.
>
>=C2=A0 =C2=A0 =C2=A0Thank you,
>=C2=A0 =C2=A0 =C2=A0NetConf and NetMod WG Chairs
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0Netconf mailing list
>=C2=A0 =C2=A0 =C2=A0Netconf@ietf.or= g <mailto:Netconf@ietf.org&g= t;
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/netconf
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailma= n/listinfo/netconf>
>
>


--001a1135b1ec9b87480542b44748-- From nobody Fri Dec 2 15:20:30 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB4B129475 for ; Fri, 2 Dec 2016 15:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 7Xi-uaFDpHkJ for ; Fri, 2 Dec 2016 15:20:23 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::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 0B803129450 for ; Fri, 2 Dec 2016 15:20:22 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id x23so112351377pgx.1 for ; Fri, 02 Dec 2016 15:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=XunIyMrlHPhn9iw6aHyN2hiHZZYnz5YjQFpYdG/xuzw=; b=e1DB3PxCdQjOpW4JgcpkgXv7CHXm5vE6v0DPHRagh0xFc4WSKsVJAPxpX+m8xXII+V lf30g3qxPMAsQjQOfZFkmajuyCR2HzfxnWyKcR1qo5dbdKht3Qy9DndTv3yFlx8RGvYA 6SatrbN7pJlC7/K2q261ipqFzOz6IJYRyaa/WYlNc8z9sR5RVsdeoVrqeBaSLhZ9KIdL E4kVf+mwtk0KdKA5jSY8KheA5mdRf7h9+4CW7oSjwE41Lts0AHfow+ltJujcmMok27gi XMBHyJlj5ap2KAZjBGJGGv0RW7Kp+YDGHvSyN+jooCrJ0xp1EDqaWcjvzczyIgGGGAh0 zQow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XunIyMrlHPhn9iw6aHyN2hiHZZYnz5YjQFpYdG/xuzw=; b=g8xCa2Pp2jFaj0RYdaBtDm51qqPFiXh30wudrlxXH5X2y+3fr4k4/G4E2QgcJZH93l IIiZ2XyySQxNXfO7dGrSSYTEIXFX3zQGLK5T+3pz6soJiX1M45DPuIuiepyGf3sv8wch /BxdNRHnwFvO1HNQFPb+XOkQHMlXB/MeTRShb3n2osJ9xHlL4kcnq2jd1Gm0fWPEeBZc jCLNin3Mm5Zt6WKJog4JoE2fdO2VPsOUWSL+3BnjucaTkhsE0aSoFa4SSsvs32Jyhnut 2emOR2U4Htn46ztU0DDfXSSw4abstm8GDvqRsTsaNLUEuR3YIUBHggP37Fei1FjJERDe n7ag== X-Gm-Message-State: AKaTC00E/h4ADKIRyGxhn+o9QdiMtG/zDoc42VAEfrsOVtQX+eQAzXfBpSwn4QaWPPlA4A== X-Received: by 10.84.150.101 with SMTP id g92mr101614573plg.39.1480720822442; Fri, 02 Dec 2016 15:20:22 -0800 (PST) Received: from [10.154.162.21] ([128.107.241.172]) by smtp.gmail.com with ESMTPSA id q145sm10127726pfq.22.2016.12.02.15.20.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Dec 2016 15:20:21 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_893CBC2B-09EC-4D6D-BD94-D753EF1EB20F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Fri, 2 Dec 2016 15:20:20 -0800 Message-Id: <9573F76E-A55D-40AA-8FB2-53E207EA1FCF@gmail.com> References: To: Mehmet Ersue X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 23:20:27 -0000 --Apple-Mail=_893CBC2B-09EC-4D6D-BD94-D753EF1EB20F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Chair hat off] Eric,=20 What would help is to understand what the backward compatibility section = would look like with your proposal. Currently it says that 5277bis will = advertise "urn:ietf:params:netconf:capability:notification:1.0=E2=80=9D = and "urn:ietf:params:netconf:capability:notification:1.1=E2=80=9D. = Clients can then choose which capability they are capable of and want to = support. With the new proposal, are we dropping advertisement of = "urn:ietf:params:netconf:capability:notification:1.0=E2=80=9D? If the namespaces are truly different, and the server already supports = 5277, what would be the implication of having two , = in two different namespaces? [Chair hat on] Echoing what Mehmet has already said. This is essentially a WG call. If = you like/do not like this proposal, or have questions about it, this = would be the time to speak up. Cheers. > On Dec 2, 2016, at 12:43 PM, MehmetErsue wrote: >=20 > Hi Eric, All, >=20 > yes, we need a charter change since there is a difference between = enhancing and replacing.=20 > As I remember the charter discussion people were keen of having = backwards compatibility because of deployed implementations.=20 >=20 > I believe we need to understand better the implications and what kind = of "replacing" we would strive for.=20 > Does replacing mean full deprecation of 5277 or will the compatibility = between e.g. old client and new server be possible?=20 >=20 > I believe we need a discussion on this on the maillist and get the = opinion of all parties. > At the end the WG will decide. >=20 > @All:=20 > Please comment on replacing instead of enhancing 5277. > Please explain why you are in favor of replacing or against. > If you are in favor please explain what kind of replacing (i.e. = compatibility level) you would like to have. > If you are in favor of keeping 5277 as standard and developing an = additional independent notification mechanism please make its case. >=20 > Thanks, > Mehmet=20 >=20 >=20 > On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit) > wrote: > Hi Mehmet, >=20 > Hi Mahesh, >=20 > Hi Benoit, >=20 > =20 >=20 > Item #6 in the NETCONF charter is: =E2=80=9CEnhance RFC 5277 with the = ability to delete subscriptions without closing the client session, to = modify existing subscriptions, and to have multiple subscriptions on an = established client session. These changes should not affect older = clients that do not support these particular subscription requirements. = The RPCs and the data models in RFC 5277 should be converted to YANG.=E2=80= =9D >=20 > =20 >=20 > Those attending the Event Notification Dezign Team today believe that = it is better to Obsolete 5277 it rather than Enhance it. The main = reasons are: >=20 > =C2=B7 The existing 5277 rpc and the new = rpcs need to be in independent namespaces. Not supporting 5277 and a separate namespace / model will significantly = simplify the new specification. =20 >=20 > =C2=B7 We can=E2=80=99t think of a reason why any YANG model = developed for legacy 5277 namespace should be developed. New = development is more likely to focus on the new model and its new = capabilities >=20 > =C2=B7 Any clients & servers desiring to support the old = capabilities can certainly do this. Independent capability sets can be = advertised. Backwards compatibility is not compromised. >=20 > =C2=B7 Leaving backwards compatibility to embedded server code = significantly reduces new development needs. >=20 > =20 >=20 > As obsoleting 5277 with this new spec is a significant step, we wanted = to get your and the community=E2=80=99s feedback and buy-in before we = modify any of the documents in this direction. >=20 > =20 >=20 > Would such a move mean a charter change? My suspicion is no as we = are enhancing the functions supported by 5277 (but without bringing = along the RPC). Do you have any guidance here? Is this worth having = an interim meeting to discuss and finalize? >=20 > =20 >=20 > Thanks, >=20 > Eric >=20 > =20 >=20 > P.S.: Additional discussion on this is contained in minutes 2 to15 = minutes of the WebEx audio recording below. >=20 > =20 >=20 > From: Eric Voit, November 30, 2016 5:58 PM >=20 >=20 > Minutes posted at: >=20 > https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-11-30 = > =C2=B7 As always, our DezignTM Team is a gathering of = individuals providing informal input to NETCONF. We ask NETCONF WG to = comment on our discussion results as a preparation for the WG consensus. = Please approach Eric Voit if you want to be included directly in these = meetings. >=20 > =20 >=20 > Meeting Materials >=20 > Attending >=20 > WebEx Recording = > password: bXeveFV5 >=20 > Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, = Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika Tripathy, = Sharon Chisholm >=20 > Obsolete RFC5277 or 5277bis? >=20 > If you are going to support both old and new capabilities, you will = have your old 5277 code, and you will have your new code. Why develop a = backwards compatible part of the spec which no one would or should = implement. People should develop to the new capability. > 5277 already has enough changes to it (e.g., dataplane has moved to = 6241 filtered notifications) > Recommendation for people on today's call is to Obsolete 5277 > Must go to the WG, its chairs, and Benoit to confirm this = recommendation before we adjust current documentation > Changes to the documents discussed today >=20 > [5277bis] >=20 > Scrub for error types in various subscription states. Authorization = and other errors should be reported using the protocol-specific error = codes; not specialized errors per these new RPCs. They still need to be = identified though. Distinguish error types from subscription state so = that you know the state a particular error happened during. > Expose operational state of subscriptions in a separate YANG model or = container. (i.e., add =E2=80=9C-state=E2=80=9D into naming convention = for the ro part) > Should subscription-id and filter-id both be id? (double-check, but we = can do to the shorter description =E2=80=9Cidentifier=E2=80=9D) > Do we rename push-source to =E2=80=9Coriginates from=E2=80=9D to be = more explicit/accurate? (better name is needed. Include it in the = terminology section.) > Section 2.3 has SHOULD for 5277 filters. Not sure why this isn=E2=80=99t= a MUST. Also we need a better name for 5277 filters. This name = doesn=E2=80=99t expose what is possible, and what is not. Especially if = we jettison 5277 compatibility, we need a better name for 6241, and we = need to define the boundaries of filter solution. Andy has a strawman = proposal. > Delete create-subscription RPC and legacy namespace should WG agree. > Do we do a test-only operation? (Let=E2=80=99s not do this work = without an advocate) > We need a way to test if the filters are doing what we expect they are = doing. (Perhaps counters/captures on an active subscription?) > For configured subscriptions, make receiver key ip address and port. = At this point we don=E2=80=99t want VRF > Change source-vrf description to indicate that we should align with = names from draft-ietf-rtgwg-ni-model-01 should it complete in time. > start-time in the YANG model from startTime as we don=E2=80=99t have = to worry about backwards compatible RPC. > Make stream type string rather than identity (preference for identity, = but not willing to fight. Note: this could change based on what happens = with filters) > [Yang-push] >=20 > Need to define error type for each subscription parameter such as = =E2=80=9Cencoding not defined=E2=80=9D, =E2=80=9CFilter syntax not = supported=E2=80=9D or =E2=80=9Cfilter complexity not supportable by = platform=E2=80=9D. > Section 3.1 =E2=80=93 Discussion on the Editors note - the addition of = a =E2=80=9Cchanges-only=E2=80=9D flag for a periodic subscription. (Some = support for this, but more discussion is needed as the work is = non-trivial.) > Section 3.8.4 =E2=80=93 recommend removal (ok) > Section 4.4: reduce this just to the new parameters (can we remove = this entirely considering section 3.1? Or do we merge 3.1 into here?) = (Eric talk to Alex, likely ok) > Section 4.6.2 Is there any reason why we can=E2=80=99t have the = timestamp on the yang push include the number of significant digits as = expressed by trailing zeros if necessary on the =E2=80=9Ctime-of-update=E2= =80=9D. This would let platforms express what they are capable of doing. = (Note: seconds would be a minimum granularity). (we should go with this = if possible. Susan H. is going to check on binary representations here = to see if variable field lengths might pose a problem for an update.) > Section 4.6.2 Do we do something on YANG-Push statistics (e.g. = counters of object changes, of update messages)? (Both=E2=80=A6 Test and = normal operations need to be covered.. Match to filters working = operation question) > Dampening: >=20 > Dampen can mean lessen. We should choose Damp or Dampen based on usage = therefore. > Google search for =E2=80=9Croute damping=E2=80=9D =3D 4,850 hits. > Google search for =E2=80=9Croute dampening=E2=80=9D =3D 11,600 hits > The more common usage is dampening, so we should stick with that. > =20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = >=20 >=20 >=20 >=20 > --=20 > Cheers, > Mehmet >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_893CBC2B-09EC-4D6D-BD94-D753EF1EB20F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [Chair hat off]

Eric, 

What would help is to = understand what the backward compatibility section would look like with = your proposal. Currently it says that 5277bis will advertise "urn:ietf:params:netconf:capability:notification:1.0=E2=80=9D = and "urn:ietf:params:netconf:capability:notification:1.1=E2=80= =9D. Clients can then choose which capability they are capable of and = want to support. With the new proposal, are we dropping advertisement = of "urn:ietf:params:netconf:capability:notification:1.0=E2=80=9D?

If the = namespaces are truly different, and the server already supports 5277, = what would be the implication of having two <create-subscription>, = in two different namespaces?

[Chair hat on]

Echoing what Mehmet has already said. This is essentially a = WG call. If you like/do not like this proposal, or have questions about = it, this would be the time to speak up.

Cheers.

On Dec 2, 2016, at 12:43 PM, MehmetErsue = <mersue@gmail.com> wrote:

Hi Eric, All,

yes, we need a = charter change since there is a difference between enhancing and = replacing. 
As I remember the charter discussion people were keen of = having backwards compatibility because of deployed implementations. 

I believe we need to understand better the implications and = what kind of "replacing" we would strive for. 
Does = replacing mean full deprecation of 5277 or will the compatibility = between e.g. old client and new server be possible? 

I believe we need a discussion on this on the maillist and = get the opinion of all parties.
At the end the WG will = decide.

@All: 
Please = comment on replacing instead of enhancing 5277.
Please= explain why you are in favor of replacing or against.
If = you are in favor please explain what kind of replacing (i.e. = compatibility level) you would like to have.
If you are in favor of keeping 5277 as standard and = developing an additional independent notification mechanism please make = its case.

Thanks,
Mehmet 


On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit = (evoit) <evoit@cisco.com> wrote:

Hi Mehmet,

Hi Mahesh,

Hi Benoit,

 

Item #6 in the NETCONF charter is: =E2=80=9CEnhance RFC 5277 = with the ability to delete subscriptions without closing the client = session, to modify existing subscriptions, and to have multiple = subscriptions on an established client session. These changes = should not affect older clients that do not support = these particular subscription requirements. The RPCs and the data = models in RFC 5277 should be converted to YANG.=E2=80=9D

 

Those attending the Event Notification Dezign Team today = believe that it is better to Obsolete 5277 it rather than Enhance = it.   The main reasons are:

=C2=B7       The existing 5277 = <create subscription> rpc and the new rpcs need to be in = independent namespaces. Not supporting 5277 <create subscription> = and a separate namespace / model will significantly simplify the new = specification.  

=C2=B7       We can=E2=80=99t think = of a reason why any YANG model developed for legacy 5277 namespace = should be developed.  New development is more likely to focus on = the new model and its new capabilities

=C2=B7       Any clients & = servers desiring to support the old capabilities can certainly do = this.  Independent capability sets can be advertised.  = Backwards compatibility is not compromised.

=C2=B7       Leaving backwards = compatibility to embedded server code significantly reduces new = development needs.

 

As obsoleting = 5277 with this new spec is a significant step, we wanted to get your and = the community=E2=80=99s feedback and buy-in before we modify any of the = documents in this direction.

 

Would such a = move mean a charter change?   My suspicion is no as we are = enhancing the functions supported by 5277 (but without bringing along = the RPC).  Do you have any guidance here?   Is this worth = having an interim meeting to discuss and finalize?

 

Thanks,

Eric

 

P.S.: = Additional discussion on this is contained in minutes 2 to15 minutes of = the WebEx audio recording below.

 

From: Eric Voit, = November 30, 2016 5:58 PM

Minutes posted at:

https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-11-30

=C2=B7        As always, our DezignTM Team is a gathering of = individuals providing informal input to NETCONF. We ask NETCONF WG to = comment on our discussion results as a preparation for the WG consensus. = Please approach Eric Voit if you want to be included directly in these = meetings.

 

Meeting Materials

Attending

WebEx = Recording

password: bXeveFV5

Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar = Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares = Ambika Tripathy, Sharon Chisholm

Obsolete RFC5277 or 5277bis?

  • If = you are going to support both old and new capabilities, you will have = your old 5277 code, and you will have your new code. Why develop a = backwards compatible part of the spec which no one would or should = implement. People should develop to the new capability.
    • 5277 = already has enough changes to it (e.g., dataplane has moved to 6241 = filtered notifications)
  • Recommendation for people on today's call is to Obsolete = 5277
  • Must go to the WG, its chairs, and Benoit to = confirm this recommendation before we adjust current documentation

Changes to the documents discussed today

[5277bis]

  • Scrub= for error types in various subscription states. Authorization and other = errors should be reported using the protocol-specific error codes; not = specialized errors per these new RPCs. They still need to be identified = though. Distinguish error types from subscription state so that you know = the state a particular error happened during.
  • Expose operational state of subscriptions in a separate YANG = model or container. (i.e., add =E2=80=9C-state=E2=80=9D into naming = convention for the ro part)
  • Should subscription-id and filter-id both be id? = (double-check, but we can do to the shorter description = =E2=80=9Cidentifier=E2=80=9D)
  • Do = we rename push-source to =E2=80=9Coriginates from=E2=80=9D to be more = explicit/accurate? (better name is needed. Include it in the terminology = section.)
  • Section 2.3 has SHOULD for 5277 filters. Not = sure why this isn=E2=80=99t a MUST. Also we need a better name for 5277 = filters. This name doesn=E2=80=99t expose what is possible, and what is = not. Especially if we jettison 5277 compatibility, we need a better name = for 6241, and we need to define the boundaries of filter solution. Andy = has a strawman proposal.
  • Delete create-subscription RPC and legacy namespace should WG = agree.
  • Do we do a test-only operation? (Let=E2=80=99s = not do this work without an advocate)
  • We = need a way to test if the filters are doing what we expect they are = doing. (Perhaps counters/captures on an active subscription?)
  • For = configured subscriptions, make receiver key ip address and port. At this = point we don=E2=80=99t want VRF
  • Change source-vrf description to indicate that we should = align with names from draft-ietf-rtgwg-ni-model-01 should it complete in = time.
  • start-time in the YANG model from startTime as = we don=E2=80=99t have to worry about backwards compatible RPC.
  • Make = stream type string rather than identity (preference for identity, but = not willing to fight. Note: this could change based on what happens with = filters)

[Yang-push]

  • Need = to define error type for each subscription parameter such as =E2=80=9Cenco= ding not defined=E2=80=9D, =E2=80=9CFilter syntax not supported=E2=80=9D = or =E2=80=9Cfilter complexity not supportable by platform=E2=80=9D.
  • Section 3.1 =E2=80=93 Discussion on the Editors note - the = addition of a =E2=80=9Cchanges-only=E2=80=9D flag for a periodic = subscription. (Some support for this, but more discussion is needed as = the work is non-trivial.)
  • Section 3.8.4 =E2=80=93 recommend removal (ok)
  • Section 4.4: reduce this just to the new parameters (can we = remove this entirely considering section 3.1? Or do we merge 3.1 into = here?) (Eric talk to Alex, likely ok)
  • Section 4.6.2 Is there any reason why we can=E2=80=99t have = the timestamp on the yang push include the number of significant digits = as expressed by trailing zeros if necessary on the =E2=80=9Ctime-of-update= =E2=80=9D. This would let platforms express what they are capable of = doing. (Note: seconds would be a minimum granularity). (we should go = with this if possible. Susan H. is going to check on binary = representations here to see if variable field lengths might pose a = problem for an update.)
    • Section 4.6.2 Do we do something on YANG-Push = statistics (e.g. counters of object changes, of update messages)? = (Both=E2=80=A6 Test and normal operations need to be covered.. Match to = filters working operation question)

Dampening:

  • Dampen can mean lessen. We should choose Damp or Dampen based = on usage therefore.
    • Google search for =E2=80=9Croute = damping=E2=80=9D =3D 4,850 hits.
    • Google search for =E2=80=9Croute dampening=E2=80=9D =3D = 11,600 hits
  • The more common usage is dampening, so we should = stick with that.

 


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




-- 
Cheers,
Mehmet

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

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_893CBC2B-09EC-4D6D-BD94-D753EF1EB20F-- From nobody Fri Dec 2 15:49:23 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B702D12947F for ; Fri, 2 Dec 2016 15:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0EKyqHAvvAB for ; Fri, 2 Dec 2016 15:49:15 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4C912945F for ; Fri, 2 Dec 2016 15:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=80278; q=dns/txt; s=iport; t=1480722554; x=1481932154; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+ZfSJ9KP23/6ymI76WWWloGV08Pvq5j0RtftPQStqw8=; b=OsYgFMjok6tbCkdHz7QnMfeKYpvp94kiz7tyJ95CNY7LU3DlP+prh4wR 8xAS6Aa/hr6leRb1KSNngWwokyvV5qLrErqSHjC3cqGnhACvKEik3JFVP 4LNsQOe3/y6HUlq7obj1SdDIHri3JBaZQCmjpa7h4m7wCg9ZeHUhWd5No c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQBWB0JY/5tdJa1CEQkZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCc0UBAQEBAR9agQYHjT+XC4dzjQmCAwMeAQyFLUoCGoIDPxQ?= =?us-ascii?q?BAgEBAQEBAQFiKIRoAQEBBAEBIQpBCxACAQgOBxALCAEDAwMCAgIfBgsUEQIEA?= =?us-ascii?q?Q0FCAwHiDoDFw4urB+CKYNYg2sNg3YBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYY?= =?us-ascii?q?+hFuCSEOBFxFMGII2gl0Fjn2FfYU0NQGGSoMJDYNVg1WBe4R8iUuHX4FthDQQI?= =?us-ascii?q?INcAR83PVwjgzkcgV1yAQSHbIENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,289,1477958400"; d="scan'208,217";a="182374517" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 23:49:13 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB2NnCON002667 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2016 23:49:12 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 18:49:11 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 2 Dec 2016 18:49:11 -0500 From: "Eric Voit (evoit)" To: Mahesh Jethanandani , Mehmet Ersue Thread-Topic: [Netconf] 5277 Backwards Compatibility: how to deliver Thread-Index: AQHSTPKpMbSMFOERPEaUZemTbQCTuKD1UOxA Date: Fri, 2 Dec 2016 23:49:11 +0000 Message-ID: References: <9573F76E-A55D-40AA-8FB2-53E207EA1FCF@gmail.com> In-Reply-To: <9573F76E-A55D-40AA-8FB2-53E207EA1FCF@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_d554e8e5e8f24d528965163de8f02ef1XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 23:49:19 -0000 --_000_d554e8e5e8f24d528965163de8f02ef1XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTWFoZXNoIEpldGhhbmFuZGFuaSwgRGVjZW1iZXIgMiwgMjAxNiA2OjIwIFBNDQoNCltD aGFpciBoYXQgb2ZmXQ0KDQpFcmljLA0KDQpXaGF0IHdvdWxkIGhlbHAgaXMgdG8gdW5kZXJzdGFu ZCB3aGF0IHRoZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHNlY3Rpb24gd291bGQgbG9vayBsaWtl IHdpdGggeW91ciBwcm9wb3NhbC4gQ3VycmVudGx5IGl0IHNheXMgdGhhdCA1Mjc3YmlzIHdpbGwg YWR2ZXJ0aXNlICJ1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlv bjoxLjDigJ0gYW5kICJ1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNh dGlvbjoxLjHigJ0uIENsaWVudHMgY2FuIHRoZW4gY2hvb3NlIHdoaWNoIGNhcGFiaWxpdHkgdGhl eSBhcmUgY2FwYWJsZSBvZiBhbmQgd2FudCB0byBzdXBwb3J0LiBXaXRoIHRoZSBuZXcgcHJvcG9z YWwsIGFyZSB3ZSBkcm9wcGluZyBhZHZlcnRpc2VtZW50IG9mICJ1cm46aWV0ZjpwYXJhbXM6bmV0 Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjoxLjDigJ0/DQoNClllcy4gIEFueW9uZSB3aG8g d2FudHMgdG8gdXNlIGV4aXN0aW5nIDUyNzcgd291bGQganVzdCBsZXZlcmFnZSB0byB0aGUgb2xk IG5hbWVzcGFjZS4NCg0KSWYgdGhlIG5hbWVzcGFjZXMgYXJlIHRydWx5IGRpZmZlcmVudCwgYW5k IHRoZSBzZXJ2ZXIgYWxyZWFkeSBzdXBwb3J0cyA1Mjc3LCB3aGF0IHdvdWxkIGJlIHRoZSBpbXBs aWNhdGlvbiBvZiBoYXZpbmcgdHdvIDxjcmVhdGUtc3Vic2NyaXB0aW9uPiwgaW4gdHdvIGRpZmZl cmVudCBuYW1lc3BhY2VzPw0KDQpUaGVyZSB3b3VsZCBiZSBubyA8Y3JlYXRlLXN1YnNjcmlwdGlv bj4gaW4gMS4xLiAgIFdpdGggNTI3N2JpcyB0aGUgcmVjb21tZW5kZWQgUlBDIGdvaW5nIGZvcndh cmQgaXMgPGVzdGFibGlzaC1zdWJzY3JpcHRpb24+LiAgSW4gdGhpcyB3YXkgZXZlcnl0aGluZyBz dGF5cyBpbmRlcGVuZGVudC4gIEJ1dCBhIHNlcnZlciBjb3VsZCBjaG9zZSB0byBzdXBwb3J0IGJv dGggMS4wICYgMS4xLiAgIFRoaXMgZ2l2ZXMgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgaW4gYSBz aW5nbGUgZGVwbG95bWVudC4NCg0KW0NoYWlyIGhhdCBvbl0NCg0KRWNob2luZyB3aGF0IE1laG1l dCBoYXMgYWxyZWFkeSBzYWlkLiBUaGlzIGlzIGVzc2VudGlhbGx5IGEgV0cgY2FsbC4gSWYgeW91 IGxpa2UvZG8gbm90IGxpa2UgdGhpcyBwcm9wb3NhbCwgb3IgaGF2ZSBxdWVzdGlvbnMgYWJvdXQg aXQsIHRoaXMgd291bGQgYmUgdGhlIHRpbWUgdG8gc3BlYWsgdXAuDQoNCkkgYW0gYWJzb2x1dGVs eSBnb29kIHRvIGdvIHdpdGggd2hhdGV2ZXIgdGhlIFdHIGRlY2lkZXMuICAgSSBkbyBiZWxpZXZl IHRoYXQgb2Jzb2xldGluZyA1Mjc3IG1ha2VzIHNwZWNpZmljYXRpb24gYW5kIGltcGxlbWVudGF0 aW9uIHNpbXBsZXIsIHdpdGggbm8gbWVhbmluZ2Z1bCBsb3NzIG9mIGZ1bmN0aW9uYWxpdHkuDQoN CkVyaWMNCg0KQ2hlZXJzLg0KDQpPbiBEZWMgMiwgMjAxNiwgYXQgMTI6NDMgUE0sIE1laG1ldEVy c3VlIDxtZXJzdWVAZ21haWwuY29tPG1haWx0bzptZXJzdWVAZ21haWwuY29tPj4gd3JvdGU6DQoN CkhpIEVyaWMsIEFsbCwNCg0KeWVzLCB3ZSBuZWVkIGEgY2hhcnRlciBjaGFuZ2Ugc2luY2UgdGhl cmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gZW5oYW5jaW5nIGFuZCByZXBsYWNpbmcuDQpBcyBJ IHJlbWVtYmVyIHRoZSBjaGFydGVyIGRpc2N1c3Npb24gcGVvcGxlIHdlcmUga2VlbiBvZiBoYXZp bmcgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgYmVjYXVzZSBvZiBkZXBsb3llZCBpbXBsZW1lbnRh dGlvbnMuDQoNCkkgYmVsaWV2ZSB3ZSBuZWVkIHRvIHVuZGVyc3RhbmQgYmV0dGVyIHRoZSBpbXBs aWNhdGlvbnMgYW5kIHdoYXQga2luZCBvZiAicmVwbGFjaW5nIiB3ZSB3b3VsZCBzdHJpdmUgZm9y Lg0KRG9lcyByZXBsYWNpbmcgbWVhbiBmdWxsIGRlcHJlY2F0aW9uIG9mIDUyNzcgb3Igd2lsbCB0 aGUgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIGUuZy4gb2xkIGNsaWVudCBhbmQgbmV3IHNlcnZlciBi ZSBwb3NzaWJsZT8NCg0KSSBiZWxpZXZlIHdlIG5lZWQgYSBkaXNjdXNzaW9uIG9uIHRoaXMgb24g dGhlIG1haWxsaXN0IGFuZCBnZXQgdGhlIG9waW5pb24gb2YgYWxsIHBhcnRpZXMuDQpBdCB0aGUg ZW5kIHRoZSBXRyB3aWxsIGRlY2lkZS4NCkBBbGw6DQpQbGVhc2UgY29tbWVudCBvbiByZXBsYWNp bmcgaW5zdGVhZCBvZiBlbmhhbmNpbmcgNTI3Ny4NClBsZWFzZSBleHBsYWluIHdoeSB5b3UgYXJl IGluIGZhdm9yIG9mIHJlcGxhY2luZyBvciBhZ2FpbnN0Lg0KSWYgeW91IGFyZSBpbiBmYXZvciBw bGVhc2UgZXhwbGFpbiB3aGF0IGtpbmQgb2YgcmVwbGFjaW5nIChpLmUuIGNvbXBhdGliaWxpdHkg bGV2ZWwpIHlvdSB3b3VsZCBsaWtlIHRvIGhhdmUuDQpJZiB5b3UgYXJlIGluIGZhdm9yIG9mIGtl ZXBpbmcgNTI3NyBhcyBzdGFuZGFyZCBhbmQgZGV2ZWxvcGluZyBhbiBhZGRpdGlvbmFsIGluZGVw ZW5kZW50IG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gcGxlYXNlIG1ha2UgaXRzIGNhc2UuDQpUaGFu a3MsDQpNZWhtZXQNCg0KT24gVGh1LCBEZWMgMSwgMjAxNiBhdCAyOjI3IEFNLCBFcmljIFZvaXQg KGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5jb20+PiB3cm90ZToN CkhpIE1laG1ldCwNCkhpIE1haGVzaCwNCkhpIEJlbm9pdCwNCg0KSXRlbSAjNiBpbiB0aGUgTkVU Q09ORiBjaGFydGVyIGlzOiDigJxFbmhhbmNlIFJGQyA1Mjc3IHdpdGggdGhlIGFiaWxpdHkgdG8g ZGVsZXRlIHN1YnNjcmlwdGlvbnMgd2l0aG91dCBjbG9zaW5nIHRoZSBjbGllbnQgc2Vzc2lvbiwg dG8gbW9kaWZ5IGV4aXN0aW5nIHN1YnNjcmlwdGlvbnMsIGFuZCB0byBoYXZlIG11bHRpcGxlIHN1 YnNjcmlwdGlvbnMgb24gYW4gZXN0YWJsaXNoZWQgY2xpZW50IHNlc3Npb24uIFRoZXNlIGNoYW5n ZXMgc2hvdWxkIG5vdCBhZmZlY3Qgb2xkZXIgY2xpZW50cyB0aGF0IGRvIG5vdCBzdXBwb3J0IHRo ZXNlIHBhcnRpY3VsYXIgc3Vic2NyaXB0aW9uIHJlcXVpcmVtZW50cy4gVGhlIFJQQ3MgYW5kIHRo ZSBkYXRhIG1vZGVscyBpbiBSRkMgNTI3NyBzaG91bGQgYmUgY29udmVydGVkIHRvIFlBTkcu4oCd DQoNClRob3NlIGF0dGVuZGluZyB0aGUgRXZlbnQgTm90aWZpY2F0aW9uIERlemlnbiBUZWFtIHRv ZGF5IGJlbGlldmUgdGhhdCBpdCBpcyBiZXR0ZXIgdG8gT2Jzb2xldGUgNTI3NyBpdCByYXRoZXIg dGhhbiBFbmhhbmNlIGl0LiAgIFRoZSBtYWluIHJlYXNvbnMgYXJlOg0KDQrigKIgICAgICAgVGhl IGV4aXN0aW5nIDUyNzcgPGNyZWF0ZSBzdWJzY3JpcHRpb24+IHJwYyBhbmQgdGhlIG5ldyBycGNz IG5lZWQgdG8gYmUgaW4gaW5kZXBlbmRlbnQgbmFtZXNwYWNlcy4gTm90IHN1cHBvcnRpbmcgNTI3 NyA8Y3JlYXRlIHN1YnNjcmlwdGlvbj4gYW5kIGEgc2VwYXJhdGUgbmFtZXNwYWNlIC8gbW9kZWwg d2lsbCBzaWduaWZpY2FudGx5IHNpbXBsaWZ5IHRoZSBuZXcgc3BlY2lmaWNhdGlvbi4NCg0K4oCi ICAgICAgIFdlIGNhbuKAmXQgdGhpbmsgb2YgYSByZWFzb24gd2h5IGFueSBZQU5HIG1vZGVsIGRl dmVsb3BlZCBmb3IgbGVnYWN5IDUyNzcgbmFtZXNwYWNlIHNob3VsZCBiZSBkZXZlbG9wZWQuICBO ZXcgZGV2ZWxvcG1lbnQgaXMgbW9yZSBsaWtlbHkgdG8gZm9jdXMgb24gdGhlIG5ldyBtb2RlbCBh bmQgaXRzIG5ldyBjYXBhYmlsaXRpZXMNCg0K4oCiICAgICAgIEFueSBjbGllbnRzICYgc2VydmVy cyBkZXNpcmluZyB0byBzdXBwb3J0IHRoZSBvbGQgY2FwYWJpbGl0aWVzIGNhbiBjZXJ0YWlubHkg ZG8gdGhpcy4gIEluZGVwZW5kZW50IGNhcGFiaWxpdHkgc2V0cyBjYW4gYmUgYWR2ZXJ0aXNlZC4g IEJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGlzIG5vdCBjb21wcm9taXNlZC4NCg0K4oCiICAgICAg IExlYXZpbmcgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgdG8gZW1iZWRkZWQgc2VydmVyIGNvZGUg c2lnbmlmaWNhbnRseSByZWR1Y2VzIG5ldyBkZXZlbG9wbWVudCBuZWVkcy4NCg0KQXMgb2Jzb2xl dGluZyA1Mjc3IHdpdGggdGhpcyBuZXcgc3BlYyBpcyBhIHNpZ25pZmljYW50IHN0ZXAsIHdlIHdh bnRlZCB0byBnZXQgeW91ciBhbmQgdGhlIGNvbW11bml0eeKAmXMgZmVlZGJhY2sgYW5kIGJ1eS1p biBiZWZvcmUgd2UgbW9kaWZ5IGFueSBvZiB0aGUgZG9jdW1lbnRzIGluIHRoaXMgZGlyZWN0aW9u Lg0KDQpXb3VsZCBzdWNoIGEgbW92ZSBtZWFuIGEgY2hhcnRlciBjaGFuZ2U/ICAgTXkgc3VzcGlj aW9uIGlzIG5vIGFzIHdlIGFyZSBlbmhhbmNpbmcgdGhlIGZ1bmN0aW9ucyBzdXBwb3J0ZWQgYnkg NTI3NyAoYnV0IHdpdGhvdXQgYnJpbmdpbmcgYWxvbmcgdGhlIFJQQykuICBEbyB5b3UgaGF2ZSBh bnkgZ3VpZGFuY2UgaGVyZT8gICBJcyB0aGlzIHdvcnRoIGhhdmluZyBhbiBpbnRlcmltIG1lZXRp bmcgdG8gZGlzY3VzcyBhbmQgZmluYWxpemU/DQoNClRoYW5rcywNCkVyaWMNCg0KUC5TLjogQWRk aXRpb25hbCBkaXNjdXNzaW9uIG9uIHRoaXMgaXMgY29udGFpbmVkIGluIG1pbnV0ZXMgMiB0bzE1 IG1pbnV0ZXMgb2YgdGhlIFdlYkV4IGF1ZGlvIHJlY29yZGluZyBiZWxvdy4NCg0KRnJvbTogRXJp YyBWb2l0LCBOb3ZlbWJlciAzMCwgMjAxNiA1OjU4IFBNDQpNaW51dGVzIHBvc3RlZCBhdDoNCmh0 dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3lhbmctcHVzaC93aWtpL01pbnV0ZXMtMjAxNi0x MS0zMA0KDQrigKIgICAgICAgIEFzIGFsd2F5cywgb3VyIERlemlnblRNIFRlYW0gaXMgYSBnYXRo ZXJpbmcgb2YgaW5kaXZpZHVhbHMgcHJvdmlkaW5nIGluZm9ybWFsIGlucHV0IHRvIE5FVENPTkYu IFdlIGFzayBORVRDT05GIFdHIHRvIGNvbW1lbnQgb24gb3VyIGRpc2N1c3Npb24gcmVzdWx0cyBh cyBhIHByZXBhcmF0aW9uIGZvciB0aGUgV0cgY29uc2Vuc3VzLiBQbGVhc2UgYXBwcm9hY2ggRXJp YyBWb2l0IGlmIHlvdSB3YW50IHRvIGJlIGluY2x1ZGVkIGRpcmVjdGx5IGluIHRoZXNlIG1lZXRp bmdzLg0KDQpNZWV0aW5nIE1hdGVyaWFscw0KDQpBdHRlbmRpbmcNCg0KV2ViRXggUmVjb3JkaW5n PGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvbHNyLnBocD9SQ0lEPTg3Y2RlMjQ1 MjkzYzQ3ZGQ4Y2ZmMzc3MjczOWY2NmM0Pg0KcGFzc3dvcmQ6IGJYZXZlRlY1DQoNCkFuZHkgQmll cm1hbiwgQWxleGFuZGVyIENsZW1tLCBBbWJpa2EgVHJpcGF0aHksIEVpbmFyIE5pbHNlbi1OeWdh YXJkLCBFcmljIFZvaXQsIFRpbSBKZW5raW5zLCBCYWxhenMgTGVuZ3llbCwgU3VzYW4gSGFyZXMg QW1iaWthIFRyaXBhdGh5LCBTaGFyb24gQ2hpc2hvbG0NCg0KT2Jzb2xldGUgUkZDNTI3NyBvciA1 Mjc3YmlzPw0KDQogICogICBJZiB5b3UgYXJlIGdvaW5nIHRvIHN1cHBvcnQgYm90aCBvbGQgYW5k IG5ldyBjYXBhYmlsaXRpZXMsIHlvdSB3aWxsIGhhdmUgeW91ciBvbGQgNTI3NyBjb2RlLCBhbmQg eW91IHdpbGwgaGF2ZSB5b3VyIG5ldyBjb2RlLiBXaHkgZGV2ZWxvcCBhIGJhY2t3YXJkcyBjb21w YXRpYmxlIHBhcnQgb2YgdGhlIHNwZWMgd2hpY2ggbm8gb25lIHdvdWxkIG9yIHNob3VsZCBpbXBs ZW1lbnQuIFBlb3BsZSBzaG91bGQgZGV2ZWxvcCB0byB0aGUgbmV3IGNhcGFiaWxpdHkuDQoNCiAg ICAgKiAgIDUyNzcgYWxyZWFkeSBoYXMgZW5vdWdoIGNoYW5nZXMgdG8gaXQgKGUuZy4sIGRhdGFw bGFuZSBoYXMgbW92ZWQgdG8gNjI0MSBmaWx0ZXJlZCBub3RpZmljYXRpb25zKQ0KDQogICogICBS ZWNvbW1lbmRhdGlvbiBmb3IgcGVvcGxlIG9uIHRvZGF5J3MgY2FsbCBpcyB0byBPYnNvbGV0ZSA1 Mjc3DQogICogICBNdXN0IGdvIHRvIHRoZSBXRywgaXRzIGNoYWlycywgYW5kIEJlbm9pdCB0byBj b25maXJtIHRoaXMgcmVjb21tZW5kYXRpb24gYmVmb3JlIHdlIGFkanVzdCBjdXJyZW50IGRvY3Vt ZW50YXRpb24NCkNoYW5nZXMgdG8gdGhlIGRvY3VtZW50cyBkaXNjdXNzZWQgdG9kYXkNCls1Mjc3 YmlzXQ0KDQogICogICBTY3J1YiBmb3IgZXJyb3IgdHlwZXMgaW4gdmFyaW91cyBzdWJzY3JpcHRp b24gc3RhdGVzLiBBdXRob3JpemF0aW9uIGFuZCBvdGhlciBlcnJvcnMgc2hvdWxkIGJlIHJlcG9y dGVkIHVzaW5nIHRoZSBwcm90b2NvbC1zcGVjaWZpYyBlcnJvciBjb2Rlczsgbm90IHNwZWNpYWxp emVkIGVycm9ycyBwZXIgdGhlc2UgbmV3IFJQQ3MuIFRoZXkgc3RpbGwgbmVlZCB0byBiZSBpZGVu dGlmaWVkIHRob3VnaC4gRGlzdGluZ3Vpc2ggZXJyb3IgdHlwZXMgZnJvbSBzdWJzY3JpcHRpb24g c3RhdGUgc28gdGhhdCB5b3Uga25vdyB0aGUgc3RhdGUgYSBwYXJ0aWN1bGFyIGVycm9yIGhhcHBl bmVkIGR1cmluZy4NCiAgKiAgIEV4cG9zZSBvcGVyYXRpb25hbCBzdGF0ZSBvZiBzdWJzY3JpcHRp b25zIGluIGEgc2VwYXJhdGUgWUFORyBtb2RlbCBvciBjb250YWluZXIuIChpLmUuLCBhZGQg4oCc LXN0YXRl4oCdIGludG8gbmFtaW5nIGNvbnZlbnRpb24gZm9yIHRoZSBybyBwYXJ0KQ0KICAqICAg U2hvdWxkIHN1YnNjcmlwdGlvbi1pZCBhbmQgZmlsdGVyLWlkIGJvdGggYmUgaWQ/IChkb3VibGUt Y2hlY2ssIGJ1dCB3ZSBjYW4gZG8gdG8gdGhlIHNob3J0ZXIgZGVzY3JpcHRpb24g4oCcaWRlbnRp ZmllcuKAnSkNCiAgKiAgIERvIHdlIHJlbmFtZSBwdXNoLXNvdXJjZSB0byDigJxvcmlnaW5hdGVz IGZyb23igJ0gdG8gYmUgbW9yZSBleHBsaWNpdC9hY2N1cmF0ZT8gKGJldHRlciBuYW1lIGlzIG5l ZWRlZC4gSW5jbHVkZSBpdCBpbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbi4pDQogICogICBTZWN0 aW9uIDIuMyBoYXMgU0hPVUxEIGZvciA1Mjc3IGZpbHRlcnMuIE5vdCBzdXJlIHdoeSB0aGlzIGlz buKAmXQgYSBNVVNULiBBbHNvIHdlIG5lZWQgYSBiZXR0ZXIgbmFtZSBmb3IgNTI3NyBmaWx0ZXJz LiBUaGlzIG5hbWUgZG9lc27igJl0IGV4cG9zZSB3aGF0IGlzIHBvc3NpYmxlLCBhbmQgd2hhdCBp cyBub3QuIEVzcGVjaWFsbHkgaWYgd2UgamV0dGlzb24gNTI3NyBjb21wYXRpYmlsaXR5LCB3ZSBu ZWVkIGEgYmV0dGVyIG5hbWUgZm9yIDYyNDEsIGFuZCB3ZSBuZWVkIHRvIGRlZmluZSB0aGUgYm91 bmRhcmllcyBvZiBmaWx0ZXIgc29sdXRpb24uIEFuZHkgaGFzIGEgc3RyYXdtYW4gcHJvcG9zYWwu DQogICogICBEZWxldGUgY3JlYXRlLXN1YnNjcmlwdGlvbiBSUEMgYW5kIGxlZ2FjeSBuYW1lc3Bh Y2Ugc2hvdWxkIFdHIGFncmVlLg0KICAqICAgRG8gd2UgZG8gYSB0ZXN0LW9ubHkgb3BlcmF0aW9u PyAoTGV04oCZcyBub3QgZG8gdGhpcyB3b3JrIHdpdGhvdXQgYW4gYWR2b2NhdGUpDQogICogICBX ZSBuZWVkIGEgd2F5IHRvIHRlc3QgaWYgdGhlIGZpbHRlcnMgYXJlIGRvaW5nIHdoYXQgd2UgZXhw ZWN0IHRoZXkgYXJlIGRvaW5nLiAoUGVyaGFwcyBjb3VudGVycy9jYXB0dXJlcyBvbiBhbiBhY3Rp dmUgc3Vic2NyaXB0aW9uPykNCiAgKiAgIEZvciBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMsIG1h a2UgcmVjZWl2ZXIga2V5IGlwIGFkZHJlc3MgYW5kIHBvcnQuIEF0IHRoaXMgcG9pbnQgd2UgZG9u 4oCZdCB3YW50IFZSRg0KICAqICAgQ2hhbmdlIHNvdXJjZS12cmYgZGVzY3JpcHRpb24gdG8gaW5k aWNhdGUgdGhhdCB3ZSBzaG91bGQgYWxpZ24gd2l0aCBuYW1lcyBmcm9tIGRyYWZ0LWlldGYtcnRn d2ctbmktbW9kZWwtMDEgc2hvdWxkIGl0IGNvbXBsZXRlIGluIHRpbWUuDQogICogICBzdGFydC10 aW1lIGluIHRoZSBZQU5HIG1vZGVsIGZyb20gc3RhcnRUaW1lIGFzIHdlIGRvbuKAmXQgaGF2ZSB0 byB3b3JyeSBhYm91dCBiYWNrd2FyZHMgY29tcGF0aWJsZSBSUEMuDQogICogICBNYWtlIHN0cmVh bSB0eXBlIHN0cmluZyByYXRoZXIgdGhhbiBpZGVudGl0eSAocHJlZmVyZW5jZSBmb3IgaWRlbnRp dHksIGJ1dCBub3Qgd2lsbGluZyB0byBmaWdodC4gTm90ZTogdGhpcyBjb3VsZCBjaGFuZ2UgYmFz ZWQgb24gd2hhdCBoYXBwZW5zIHdpdGggZmlsdGVycykNCltZYW5nLXB1c2hdDQoNCiAgKiAgIE5l ZWQgdG8gZGVmaW5lIGVycm9yIHR5cGUgZm9yIGVhY2ggc3Vic2NyaXB0aW9uIHBhcmFtZXRlciBz dWNoIGFzIOKAnGVuY29kaW5nIG5vdCBkZWZpbmVk4oCdLCDigJxGaWx0ZXIgc3ludGF4IG5vdCBz dXBwb3J0ZWTigJ0gb3Ig4oCcZmlsdGVyIGNvbXBsZXhpdHkgbm90IHN1cHBvcnRhYmxlIGJ5IHBs YXRmb3Jt4oCdLg0KICAqICAgU2VjdGlvbiAzLjEg4oCTIERpc2N1c3Npb24gb24gdGhlIEVkaXRv cnMgbm90ZSAtIHRoZSBhZGRpdGlvbiBvZiBhIOKAnGNoYW5nZXMtb25seeKAnSBmbGFnIGZvciBh IHBlcmlvZGljIHN1YnNjcmlwdGlvbi4gKFNvbWUgc3VwcG9ydCBmb3IgdGhpcywgYnV0IG1vcmUg ZGlzY3Vzc2lvbiBpcyBuZWVkZWQgYXMgdGhlIHdvcmsgaXMgbm9uLXRyaXZpYWwuKQ0KICAqICAg U2VjdGlvbiAzLjguNCDigJMgcmVjb21tZW5kIHJlbW92YWwgKG9rKQ0KICAqICAgU2VjdGlvbiA0 LjQ6IHJlZHVjZSB0aGlzIGp1c3QgdG8gdGhlIG5ldyBwYXJhbWV0ZXJzIChjYW4gd2UgcmVtb3Zl IHRoaXMgZW50aXJlbHkgY29uc2lkZXJpbmcgc2VjdGlvbiAzLjE/IE9yIGRvIHdlIG1lcmdlIDMu MSBpbnRvIGhlcmU/KSAoRXJpYyB0YWxrIHRvIEFsZXgsIGxpa2VseSBvaykNCiAgKiAgIFNlY3Rp b24gNC42LjIgSXMgdGhlcmUgYW55IHJlYXNvbiB3aHkgd2UgY2Fu4oCZdCBoYXZlIHRoZSB0aW1l c3RhbXAgb24gdGhlIHlhbmcgcHVzaCBpbmNsdWRlIHRoZSBudW1iZXIgb2Ygc2lnbmlmaWNhbnQg ZGlnaXRzIGFzIGV4cHJlc3NlZCBieSB0cmFpbGluZyB6ZXJvcyBpZiBuZWNlc3Nhcnkgb24gdGhl IOKAnHRpbWUtb2YtdXBkYXRl4oCdLiBUaGlzIHdvdWxkIGxldCBwbGF0Zm9ybXMgZXhwcmVzcyB3 aGF0IHRoZXkgYXJlIGNhcGFibGUgb2YgZG9pbmcuIChOb3RlOiBzZWNvbmRzIHdvdWxkIGJlIGEg bWluaW11bSBncmFudWxhcml0eSkuICh3ZSBzaG91bGQgZ28gd2l0aCB0aGlzIGlmIHBvc3NpYmxl LiBTdXNhbiBILiBpcyBnb2luZyB0byBjaGVjayBvbiBiaW5hcnkgcmVwcmVzZW50YXRpb25zIGhl cmUgdG8gc2VlIGlmIHZhcmlhYmxlIGZpZWxkIGxlbmd0aHMgbWlnaHQgcG9zZSBhIHByb2JsZW0g Zm9yIGFuIHVwZGF0ZS4pDQogICogICBTZWN0aW9uIDQuNi4yIERvIHdlIGRvIHNvbWV0aGluZyBv biBZQU5HLVB1c2ggc3RhdGlzdGljcyAoZS5nLiBjb3VudGVycyBvZiBvYmplY3QgY2hhbmdlcywg b2YgdXBkYXRlIG1lc3NhZ2VzKT8gKEJvdGjigKYgVGVzdCBhbmQgbm9ybWFsIG9wZXJhdGlvbnMg bmVlZCB0byBiZSBjb3ZlcmVkLi4gTWF0Y2ggdG8gZmlsdGVycyB3b3JraW5nIG9wZXJhdGlvbiBx dWVzdGlvbikNCkRhbXBlbmluZzoNCg0KICAqICAgRGFtcGVuIGNhbiBtZWFuIGxlc3Nlbi4gV2Ug c2hvdWxkIGNob29zZSBEYW1wIG9yIERhbXBlbiBiYXNlZCBvbiB1c2FnZSB0aGVyZWZvcmUuDQoN CiAgICAgKiAgIEdvb2dsZSBzZWFyY2ggZm9yIOKAnHJvdXRlIGRhbXBpbmfigJ0gPSA0LDg1MCBo aXRzLg0KICAgICAqICAgR29vZ2xlIHNlYXJjaCBmb3Ig4oCccm91dGUgZGFtcGVuaW5n4oCdID0g MTEsNjAwIGhpdHMNCg0KICAqICAgVGhlIG1vcmUgY29tbW9uIHVzYWdlIGlzIGRhbXBlbmluZywg c28gd2Ugc2hvdWxkIHN0aWNrIHdpdGggdGhhdC4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZA aWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KDQoNCi0tDQpDaGVlcnMsDQpNZWhtZXQNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxp bmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQpNYWhlc2ggSmV0aGFu YW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFp bC5jb20+DQoNCg0KDQo= --_000_d554e8e5e8f24d528965163de8f02ef1XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRl ZC1zcGFjZTt9DQpwLm02NTM0MTk4NDY1NDMyNjk3NDEwbXNvbGlzdHBhcmFncmFwaCwgbGkubTY1 MzQxOTg0NjU0MzI2OTc0MTBtc29saXN0cGFyYWdyYXBoLCBkaXYubTY1MzQxOTg0NjU0MzI2OTc0 MTBtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fNjUzNDE5ODQ2NTQzMjY5NzQx MG1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjM4NjQ5NTk1OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6OTA3MTk2MjMyO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MQ0KCXttc28tbGlzdC1pZDo0NDY4NTQyODU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjgwODIy NTE0ODt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjk1OTE0MjAxMzsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTMxNzg4NDQ2O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxp c3QtaWQ6MjAxNjQ5MTM0NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4NjczNDE1MjI7fQ0K QGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNYWhlc2ggSmV0aGFu YW5kYW5pLCBEZWNlbWJlciAyLCAyMDE2IDY6MjAgUE08YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQ2hhaXIgaGF0IG9mZl08bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVyaWMsJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgd291bGQg aGVscCBpcyB0byB1bmRlcnN0YW5kIHdoYXQgdGhlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgc2Vj dGlvbiB3b3VsZCBsb29rIGxpa2Ugd2l0aCB5b3VyIHByb3Bvc2FsLiBDdXJyZW50bHkgaXQgc2F5 cyB0aGF0IDUyNzdiaXMgd2lsbCBhZHZlcnRpc2UmbmJzcDsmcXVvdDt1cm46aWV0ZjpwYXJhbXM6 bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjoxLjDigJ0gYW5kJm5ic3A7JnF1b3Q7dXJu OmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4x4oCdLg0KIENs aWVudHMgY2FuIHRoZW4gY2hvb3NlIHdoaWNoIGNhcGFiaWxpdHkgdGhleSBhcmUgY2FwYWJsZSBv ZiBhbmQgd2FudCB0byBzdXBwb3J0LiBXaXRoIHRoZSBuZXcgcHJvcG9zYWwsIGFyZSB3ZSBkcm9w cGluZyBhZHZlcnRpc2VtZW50IG9mJm5ic3A7JnF1b3Q7dXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6 Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4w4oCdPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5ZZXMuJm5ic3A7IEFueW9uZSB3aG8gd2FudHMgdG8gdXNlIGV4aXN0aW5nIDUy Nzcgd291bGQganVzdCBsZXZlcmFnZSB0byB0aGUgb2xkIG5hbWVzcGFjZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBu YW1lc3BhY2VzIGFyZSB0cnVseSBkaWZmZXJlbnQsIGFuZCB0aGUgc2VydmVyIGFscmVhZHkgc3Vw cG9ydHMgNTI3Nywgd2hhdCB3b3VsZCBiZSB0aGUgaW1wbGljYXRpb24gb2YgaGF2aW5nIHR3byAm bHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDssIGluIHR3byBkaWZmZXJlbnQgbmFtZXNwYWNlcz88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlcmUgd291bGQgYmUgbm8gJmx0 O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IGluIDEuMS4mbmJzcDsmbmJzcDsgV2l0aCA1Mjc3Ymlz IHRoZSByZWNvbW1lbmRlZCBSUEMgZ29pbmcgZm9yd2FyZCBpcyAmbHQ7ZXN0YWJsaXNoLXN1YnNj cmlwdGlvbiZndDsuJm5ic3A7IEluIHRoaXMgd2F5IGV2ZXJ5dGhpbmcgc3RheXMgaW5kZXBlbmRl bnQuJm5ic3A7DQogQnV0IGEgc2VydmVyIGNvdWxkIGNob3NlIHRvIHN1cHBvcnQgYm90aCAxLjAg JmFtcDsgMS4xLiZuYnNwOyZuYnNwOyBUaGlzIGdpdmVzIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5 IGluIGEgc2luZ2xlIGRlcGxveW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQ2hhaXIgaGF0IG9uXTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FY2hvaW5nIHdoYXQgTWVo bWV0IGhhcyBhbHJlYWR5IHNhaWQuIFRoaXMgaXMgZXNzZW50aWFsbHkgYSBXRyBjYWxsLiBJZiB5 b3UgbGlrZS9kbyBub3QgbGlrZSB0aGlzIHByb3Bvc2FsLCBvciBoYXZlIHF1ZXN0aW9ucyBhYm91 dCBpdCwgdGhpcyB3b3VsZCBiZSB0aGUgdGltZSB0byBzcGVhayB1cC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbSBhYnNvbHV0ZWx5IGdvb2QgdG8gZ28gd2l0aCB3aGF0 ZXZlciB0aGUgV0cgZGVjaWRlcy4mbmJzcDsmbmJzcDsgSSBkbyBiZWxpZXZlIHRoYXQgb2Jzb2xl dGluZyA1Mjc3IG1ha2VzIHNwZWNpZmljYXRpb24gYW5kIGltcGxlbWVudGF0aW9uIHNpbXBsZXIs IHdpdGggbm8gbWVhbmluZ2Z1bA0KIGxvc3Mgb2YgZnVuY3Rpb25hbGl0eS4gPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FcmljPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBEZWMgMiwgMjAxNiwgYXQgMTI6NDMgUE0sIE1laG1ldEVyc3VlICZsdDs8YSBocmVm PSJtYWlsdG86bWVyc3VlQGdtYWlsLmNvbSI+bWVyc3VlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEVy aWMsIEFsbCw8YnI+DQo8YnI+DQp5ZXMsIHdlIG5lZWQgYSBjaGFydGVyIGNoYW5nZSBzaW5jZSB0 aGVyZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBlbmhhbmNpbmcgYW5kIHJlcGxhY2luZy48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KQXMgSSBy ZW1lbWJlciB0aGUgY2hhcnRlciBkaXNjdXNzaW9uIHBlb3BsZSB3ZXJlIGtlZW4gb2YgaGF2aW5n IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGJlY2F1c2Ugb2YgZGVwbG95ZWQgaW1wbGVtZW50YXRp b25zLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+ DQo8YnI+DQpJIGJlbGlldmUgd2UgbmVlZCB0byB1bmRlcnN0YW5kIGJldHRlciB0aGUgaW1wbGlj YXRpb25zIGFuZCB3aGF0IGtpbmQgb2YgJnF1b3Q7cmVwbGFjaW5nJnF1b3Q7IHdlIHdvdWxkIHN0 cml2ZSBmb3IuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjxicj4NCkRvZXMgcmVwbGFjaW5nIG1lYW4gZnVsbCBkZXByZWNhdGlvbiBvZiA1Mjc3IG9yIHdp bGwgdGhlIGNvbXBhdGliaWxpdHkgYmV0d2VlbiBlLmcuIG9sZCBjbGllbnQgYW5kIG5ldyBzZXJ2 ZXIgYmUgcG9zc2libGU/PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCjxicj4NCkkgYmVsaWV2ZSB3ZSBuZWVkIGEgZGlzY3Vzc2lvbiBvbiB0aGlz IG9uIHRoZSBtYWlsbGlzdCBhbmQgZ2V0IHRoZSBvcGluaW9uIG9mIGFsbCBwYXJ0aWVzLjxicj4N CkF0IHRoZSBlbmQgdGhlIFdHIHdpbGwgZGVjaWRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QEFsbDo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KUGxlYXNlIGNv bW1lbnQgb24gcmVwbGFjaW5nIGluc3RlYWQgb2YgZW5oYW5jaW5nIDUyNzcuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5QbGVhc2UgZXhwbGFpbiB3aHkgeW91IGFyZSBpbiBmYXZvciBvZiByZXBsYWNpbmcgb3IgYWdh aW5zdC48YnI+DQpJZiB5b3UgYXJlIGluIGZhdm9yIHBsZWFzZSBleHBsYWluIHdoYXQga2luZCBv ZiByZXBsYWNpbmcgKGkuZS4gY29tcGF0aWJpbGl0eSBsZXZlbCkgeW91IHdvdWxkIGxpa2UgdG8g aGF2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JZiB5b3UgYXJl IGluIGZhdm9yIG9mIGtlZXBpbmcgNTI3NyBhcyBzdGFuZGFyZCBhbmQgZGV2ZWxvcGluZyBhbiBh ZGRpdGlvbmFsIGluZGVwZW5kZW50IG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gcGxlYXNlIG1ha2Ug aXRzIGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+VGhhbmtzLDxicj4NCk1laG1ldDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPk9uIFRodSwgRGVjIDEsIDIwMTYgYXQgMjoyNyBBTSwgRXJpYyBW b2l0IChldm9pdCk8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+Jmx0OzxhIGhyZWY9Im1haWx0bzpldm9pdEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5l dm9pdEBjaXNjby5jb208L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj53cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5IaSBNZWhtZXQsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkhpIE1haGVzaCw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SGkgQmVub2l0LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SXRlbSAjNiBpbiB0aGUgTkVUQ09ORiBjaGFydGVyIGlzOiDigJxFbmhhbmNlIFJGQyA1Mjc3 IHdpdGggdGhlIGFiaWxpdHkgdG8gZGVsZXRlIHN1YnNjcmlwdGlvbnMgd2l0aG91dCZuYnNwO2Ns b3NpbmcNCiB0aGUgY2xpZW50IHNlc3Npb24sIHRvIG1vZGlmeSBleGlzdGluZyBzdWJzY3JpcHRp b25zLCBhbmQgdG8mbmJzcDtoYXZlIG11bHRpcGxlIHN1YnNjcmlwdGlvbnMgb24gYW4gZXN0YWJs aXNoZWQgY2xpZW50IHNlc3Npb24uIFRoZXNlJm5ic3A7Y2hhbmdlcyBzaG91bGQgbm90IGFmZmVj dCBvbGRlciBjbGllbnRzIHRoYXQgZG8gbm90IHN1cHBvcnQgdGhlc2UmbmJzcDtwYXJ0aWN1bGFy IHN1YnNjcmlwdGlvbiByZXF1aXJlbWVudHMuIFRoZSBSUENzIGFuZCB0aGUgZGF0YSBtb2RlbHMN CiBpbiZuYnNwO1JGQyA1Mjc3IHNob3VsZCBiZSBjb252ZXJ0ZWQgdG8gWUFORy7igJ08L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRob3NlIGF0dGVuZGluZyB0aGUgRXZl bnQgTm90aWZpY2F0aW9uIERlemlnbiBUZWFtIHRvZGF5IGJlbGlldmUgdGhhdCBpdCBpcyBiZXR0 ZXIgdG8gT2Jzb2xldGUgNTI3Nw0KIGl0IHJhdGhlciB0aGFuIEVuaGFuY2UgaXQuJm5ic3A7Jm5i c3A7IFRoZSBtYWluIHJlYXNvbnMgYXJlOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTY1MzQxOTg0NjU0MzI2OTc0MTBtc29saXN0cGFy YWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7 Y29sb3I6IzFGNDk3RCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUNCiBleGlzdGluZyA1Mjc3ICZsdDtjcmVhdGUgc3Vic2Ny aXB0aW9uJmd0OyBycGMgYW5kIHRoZSBuZXcgcnBjcyBuZWVkIHRvIGJlIGluIGluZGVwZW5kZW50 IG5hbWVzcGFjZXMuIE5vdCBzdXBwb3J0aW5nIDUyNzcgJmx0O2NyZWF0ZSBzdWJzY3JpcHRpb24m Z3Q7IGFuZCBhIHNlcGFyYXRlIG5hbWVzcGFjZSAvIG1vZGVsIHdpbGwgc2lnbmlmaWNhbnRseSBz aW1wbGlmeSB0aGUgbmV3IHNwZWNpZmljYXRpb24uJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTY1MzQxOTg0NjU0MzI2OTc0MTBtc29saXN0 cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1i b2w7Y29sb3I6IzFGNDk3RCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XZQ0KIGNhbuKAmXQgdGhpbmsgb2YgYSByZWFzb24gd2h5 IGFueSBZQU5HIG1vZGVsIGRldmVsb3BlZCBmb3IgbGVnYWN5IDUyNzcgbmFtZXNwYWNlIHNob3Vs ZCBiZSBkZXZlbG9wZWQuJm5ic3A7IE5ldyBkZXZlbG9wbWVudCBpcyBtb3JlIGxpa2VseSB0byBm b2N1cyBvbiB0aGUgbmV3IG1vZGVsIGFuZCBpdHMgbmV3IGNhcGFiaWxpdGllczwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTY1MzQxOTg0 NjU0MzI2OTc0MTBtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbnkNCiBjbGllbnRzICZh bXA7IHNlcnZlcnMgZGVzaXJpbmcgdG8gc3VwcG9ydCB0aGUgb2xkIGNhcGFiaWxpdGllcyBjYW4g Y2VydGFpbmx5IGRvIHRoaXMuJm5ic3A7IEluZGVwZW5kZW50IGNhcGFiaWxpdHkgc2V0cyBjYW4g YmUgYWR2ZXJ0aXNlZC4mbmJzcDsgQmFja3dhcmRzIGNvbXBhdGliaWxpdHkgaXMgbm90IGNvbXBy b21pc2VkLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0ibTY1MzQxOTg0NjU0MzI2OTc0MTBtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+wrc8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5MZWF2aW5nDQogYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgdG8gZW1iZWRkZWQgc2VydmVyIGNv ZGUgc2lnbmlmaWNhbnRseSByZWR1Y2VzIG5ldyBkZXZlbG9wbWVudCBuZWVkcy48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFzIG9ic29sZXRpbmcgNTI3NyB3aXRoIHRo aXMgbmV3IHNwZWMgaXMgYSBzaWduaWZpY2FudCBzdGVwLCB3ZSB3YW50ZWQgdG8gZ2V0IHlvdXIg YW5kIHRoZSBjb21tdW5pdHnigJlzDQogZmVlZGJhY2sgYW5kIGJ1eS1pbiBiZWZvcmUgd2UgbW9k aWZ5IGFueSBvZiB0aGUgZG9jdW1lbnRzIGluIHRoaXMgZGlyZWN0aW9uLjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V291bGQgc3VjaCBhIG1vdmUgbWVhbiBhIGNoYXJ0 ZXIgY2hhbmdlPyZuYnNwOyZuYnNwOyBNeSBzdXNwaWNpb24gaXMgbm8gYXMgd2UgYXJlIGVuaGFu Y2luZyB0aGUgZnVuY3Rpb25zIHN1cHBvcnRlZA0KIGJ5IDUyNzcgKGJ1dCB3aXRob3V0IGJyaW5n aW5nIGFsb25nIHRoZSBSUEMpLiZuYnNwOyBEbyB5b3UgaGF2ZSBhbnkgZ3VpZGFuY2UgaGVyZT8m bmJzcDsmbmJzcDsgSXMgdGhpcyB3b3J0aCBoYXZpbmcgYW4gaW50ZXJpbSBtZWV0aW5nIHRvIGRp c2N1c3MgYW5kIGZpbmFsaXplPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGhhbmtzLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5F cmljPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QLlMuOiBBZGRpdGlv bmFsIGRpc2N1c3Npb24gb24gdGhpcyBpcyBjb250YWluZWQgaW4gbWludXRlcyAyIHRvMTUgbWlu dXRlcyBvZiB0aGUgV2ViRXggYXVkaW8gcmVjb3JkaW5nDQogYmVsb3cuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMS4w cHQgMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RXJpYw0KIFZvaXQsIE5v dmVtYmVyIDMwLCAyMDE2IDU6NTggUE08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+TWludXRlcyBwb3N0ZWQgYXQ6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cveWFuZy1wdXNoL3dpa2kv TWludXRlcy0yMDE2LTExLTMwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRj b25mLXdnL3lhbmctcHVzaC93aWtpL01pbnV0ZXMtMjAxNi0xMS0zMDwvc3Bhbj48L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im02NTM0MTk4NDY1NDMyNjk3NDEwbXNvbGlzdHBh cmFncmFwaCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0 aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5BcyBhbHdheXMsIG91ciBEZXppZ248c3VwPlRNPC9zdXA+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRlYW0NCiBp cyBhIGdhdGhlcmluZyBvZiBpbmRpdmlkdWFscyBwcm92aWRpbmcgaW5mb3JtYWwgaW5wdXQgdG8g TkVUQ09ORi4gV2UgYXNrIE5FVENPTkYgV0cgdG8gY29tbWVudCBvbiBvdXIgZGlzY3Vzc2lvbiBy ZXN1bHRzIGFzIGEgcHJlcGFyYXRpb24gZm9yIHRoZSBXRyBjb25zZW5zdXMuIFBsZWFzZSBhcHBy b2FjaCBFcmljIFZvaXQgaWYgeW91IHdhbnQgdG8gYmUgaW5jbHVkZWQgZGlyZWN0bHkgaW4gdGhl c2UgbWVldGluZ3MuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxs cGFkZGluZz0iMCIgd2lkdGg9IjE0MDAiIHN0eWxlPSJ3aWR0aDo1MjUuMHB0O2JhY2tncm91bmQ6 d2hpdGU7Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlh bCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQo8dGhlYWQ+DQo8 dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpzb2xpZCAjREREREREIDEuMHB0O3BhZGRpbmc6NC41cHQg OS43NXB0IDQuNXB0IDkuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4 dC1hbGlnbjpjZW50ZXIiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+TWVldGluZyBNYXRlcmlhbHM8L3NwYW4+ PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0iYm9yZGVyOnNvbGlkICNERERE REQgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjQuNXB0IDkuNzVwdCA0LjVwdCA5Ljc1 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyIj4N CjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMzMzMzMzMiPkF0dGVuZGluZzwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3Rk Pg0KPC90cj4NCjwvdGhlYWQ+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpzb2xp ZCAjREREREREIDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjQuNXB0IDkuNzVwdCA0LjVw dCA5Ljc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4 LmNvbS9jaXNjb3NhbGVzL2xzci5waHA/UkNJRD04N2NkZTI0NTI5M2M0N2RkOGNmZjM3NzI3Mzlm NjZjNCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0MDc4QzAiPldlYkV4IFJlY29yZGluZzwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPnBhc3N3b3Jk OiBiWGV2ZUZWNTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9ImJvcmRl ci10b3A6bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgI0RERERERCAx LjBwdDtib3JkZXItcmlnaHQ6c29saWQgI0RERERERCAxLjBwdDtwYWRkaW5nOjQuNXB0IDkuNzVw dCA0LjVwdCA5Ljc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5BbmR5IEJpZXJt YW4sIEFsZXhhbmRlciBDbGVtbSwgQW1iaWthIFRyaXBhdGh5LCBFaW5hciBOaWxzZW4tTnlnYWFy ZCwgRXJpYyBWb2l0LCBUaW0gSmVua2lucywgQmFsYXpzIExlbmd5ZWwsIFN1c2FuIEhhcmVzIEFt YmlrYQ0KIFRyaXBhdGh5LCBTaGFyb24gQ2hpc2hvbG08L3NwYW4+PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWJvdHRvbTpzb2xpZCAjRUVFRUVFIDEuMHB0O3BhZGRpbmc6MGluIDBpbiA0LjBwdCAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlv bjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+T2Jzb2xldGUgUkZDNTI3NyBvciA1Mjc3Ymlz Pzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9y OiMzMzMzMzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBv c2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5JZiB5b3UgYXJlIGdvaW5nIHRvIHN1cHBvcnQgYm90aCBvbGQgYW5k IG5ldyBjYXBhYmlsaXRpZXMsIHlvdSB3aWxsIGhhdmUgeW91ciBvbGQgNTI3NyBjb2RlLCBhbmQg eW91IHdpbGwgaGF2ZSB5b3VyIG5ldyBjb2RlLiBXaHkgZGV2ZWxvcCBhIGJhY2t3YXJkcyBjb21w YXRpYmxlIHBhcnQgb2YgdGhlIHNwZWMgd2hpY2ggbm8gb25lIHdvdWxkDQogb3Igc2hvdWxkIGlt cGxlbWVudC4gUGVvcGxlIHNob3VsZCBkZXZlbG9wIHRvIHRoZSBuZXcgY2FwYWJpbGl0eS48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHVsIHR5 cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwyIGxmbzE7YmFja2dyb3VuZDp3aGl0ZTtiYWNr Z3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFs IGluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj41Mjc3IGFscmVhZHkgaGFzIGVub3VnaCBjaGFuZ2Vz IHRvIGl0IChlLmcuLCBkYXRhcGxhbmUgaGFzIG1vdmVkIHRvIDYyNDEgZmlsdGVyZWQgbm90aWZp Y2F0aW9ucyk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9saT48 L3VsPg0KPC91bD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzE7YmFja2dy b3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5k LXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5SZWNvbW1lbmRhdGlvbiBm b3IgcGVvcGxlIG9uIHRvZGF5J3MgY2FsbCBpcyB0byBPYnNvbGV0ZSA1Mjc3PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjb2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3Jv dW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGlu aXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5NdXN0IGdvIHRvIHRoZSBXRywgaXRzIGNoYWlycywgYW5k IEJlbm9pdCB0byBjb25maXJtIHRoaXMgcmVjb21tZW5kYXRpb24gYmVmb3JlIHdlIGFkanVzdCBj dXJyZW50IGRvY3VtZW50YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9saT48L3VsPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpz b2xpZCAjRUVFRUVFIDEuMHB0O3BhZGRpbmc6MGluIDBpbiA0LjBwdCAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0O2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRp YWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzMzMzMzMyI+Q2hhbmdlcyB0byB0aGUgZG9jdW1lbnRzIGRpc2N1c3NlZCB0b2RheTwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmlu aXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5bNTI3N2Jpc108L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMjtiYWNr Z3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91 bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNjcnViIGZvciBlcnJv ciB0eXBlcyBpbiB2YXJpb3VzIHN1YnNjcmlwdGlvbiBzdGF0ZXMuIEF1dGhvcml6YXRpb24gYW5k IG90aGVyIGVycm9ycyBzaG91bGQgYmUgcmVwb3J0ZWQgdXNpbmcgdGhlIHByb3RvY29sLXNwZWNp ZmljIGVycm9yIGNvZGVzOyBub3Qgc3BlY2lhbGl6ZWQgZXJyb3JzIHBlciB0aGVzZSBuZXcgUlBD cy4gVGhleSBzdGlsbA0KIG5lZWQgdG8gYmUgaWRlbnRpZmllZCB0aG91Z2guIERpc3Rpbmd1aXNo IGVycm9yIHR5cGVzIGZyb20gc3Vic2NyaXB0aW9uIHN0YXRlIHNvIHRoYXQgeW91IGtub3cgdGhl IHN0YXRlIGEgcGFydGljdWxhciBlcnJvciBoYXBwZW5lZCBkdXJpbmcuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5k LXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRp YWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj5FeHBvc2Ugb3BlcmF0aW9uYWwgc3RhdGUgb2Ygc3Vic2NyaXB0 aW9ucyBpbiBhIHNlcGFyYXRlIFlBTkcgbW9kZWwgb3IgY29udGFpbmVyLiAoaS5lLiwgYWRkIOKA nC1zdGF0ZeKAnSBpbnRvIG5hbWluZyBjb252ZW50aW9uIGZvciB0aGUgcm8gcGFydCk8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMjtiYWNrZ3JvdW5kOndoaXRlO2Jh Y2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRp YWwgaW5pdGlhbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNob3VsZCBzdWJzY3JpcHRpb24taWQgYW5kIGZp bHRlci1pZCBib3RoIGJlIGlkPyAoZG91YmxlLWNoZWNrLCBidXQgd2UgY2FuIGRvIHRvIHRoZSBz aG9ydGVyIGRlc2NyaXB0aW9uIOKAnGlkZW50aWZpZXLigJ0pPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj b2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0 aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5EbyB3ZSByZW5hbWUgcHVzaC1zb3VyY2UgdG8g4oCcb3JpZ2luYXRlcyBm cm9t4oCdIHRvIGJlIG1vcmUgZXhwbGljaXQvYWNjdXJhdGU/IChiZXR0ZXIgbmFtZSBpcyBuZWVk ZWQuIEluY2x1ZGUgaXQgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24uKTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8yO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3Vu ZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0 aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+U2VjdGlvbiAyLjMgaGFzIFNIT1VMRCBmb3IgNTI3NyBmaWx0 ZXJzLiBOb3Qgc3VyZSB3aHkgdGhpcyBpc27igJl0IGEgTVVTVC4gQWxzbyB3ZSBuZWVkIGEgYmV0 dGVyIG5hbWUgZm9yIDUyNzcgZmlsdGVycy4gVGhpcyBuYW1lIGRvZXNu4oCZdCBleHBvc2Ugd2hh dCBpcyBwb3NzaWJsZSwgYW5kIHdoYXQgaXMgbm90LiBFc3BlY2lhbGx5IGlmIHdlIGpldHRpc29u DQogNTI3NyBjb21wYXRpYmlsaXR5LCB3ZSBuZWVkIGEgYmV0dGVyIG5hbWUgZm9yIDYyNDEsIGFu ZCB3ZSBuZWVkIHRvIGRlZmluZSB0aGUgYm91bmRhcmllcyBvZiBmaWx0ZXIgc29sdXRpb24uIEFu ZHkgaGFzIGEgc3RyYXdtYW4gcHJvcG9zYWwuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMz MzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRp YWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5EZWxldGUgY3JlYXRlLXN1YnNjcmlwdGlvbiBSUEMgYW5kIGxlZ2FjeSBuYW1lc3BhY2Ug c2hvdWxkIFdHIGFncmVlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4t dG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBs Zm8yO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7 YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+RG8gd2Ug ZG8gYSB0ZXN0LW9ubHkgb3BlcmF0aW9uPyAoTGV04oCZcyBub3QgZG8gdGhpcyB3b3JrIHdpdGhv dXQgYW4gYWR2b2NhdGUpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21hcmdpbi10 b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxm bzI7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDti YWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XZSBuZWVk IGEgd2F5IHRvIHRlc3QgaWYgdGhlIGZpbHRlcnMgYXJlIGRvaW5nIHdoYXQgd2UgZXhwZWN0IHRo ZXkgYXJlIGRvaW5nLiAoUGVyaGFwcyBjb3VudGVycy9jYXB0dXJlcyBvbiBhbiBhY3RpdmUgc3Vi c2NyaXB0aW9uPyk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDoz LjBwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMjti YWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tn cm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkZvciBjb25maWd1 cmVkIHN1YnNjcmlwdGlvbnMsIG1ha2UgcmVjZWl2ZXIga2V5IGlwIGFkZHJlc3MgYW5kIHBvcnQu IEF0IHRoaXMgcG9pbnQgd2UgZG9u4oCZdCB3YW50IFZSRjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwyIGxldmVsMSBsZm8yO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlv bjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+Q2hhbmdlIHNvdXJjZS12cmYgZGVzY3JpcHRpb24gdG8gaW5kaWNhdGUgdGhh dCB3ZSBzaG91bGQgYWxpZ24gd2l0aCBuYW1lcyBmcm9tIGRyYWZ0LWlldGYtcnRnd2ctbmktbW9k ZWwtMDEgc2hvdWxkIGl0IGNvbXBsZXRlIGluIHRpbWUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xv cjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDIgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9u OmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5zdGFydC10aW1lIGluIHRoZSBZQU5HIG1vZGVsIGZyb20gc3RhcnRUaW1lIGFz IHdlIGRvbuKAmXQgaGF2ZSB0byB3b3JyeSBhYm91dCBiYWNrd2FyZHMgY29tcGF0aWJsZSBSUEMu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3 aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVh dDppbml0aWFsIGluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5NYWtlIHN0cmVhbSB0eXBlIHN0cmlu ZyByYXRoZXIgdGhhbiBpZGVudGl0eSAocHJlZmVyZW5jZSBmb3IgaWRlbnRpdHksIGJ1dCBub3Qg d2lsbGluZyB0byBmaWdodC4gTm90ZTogdGhpcyBjb3VsZCBjaGFuZ2UgYmFzZWQgb24gd2hhdCBo YXBwZW5zIHdpdGggZmlsdGVycyk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGU7YmFja2dy b3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBp bml0aWFsIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+W1lhbmctcHVzaF08L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps MSBsZXZlbDEgbGZvMztiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlh bCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPk5lZWQgdG8gZGVmaW5lIGVycm9yIHR5cGUgZm9yIGVhY2ggc3Vic2NyaXB0aW9uIHBhcmFt ZXRlciBzdWNoIGFzIOKAnGVuY29kaW5nIG5vdCBkZWZpbmVk4oCdLCDigJxGaWx0ZXIgc3ludGF4 IG5vdCBzdXBwb3J0ZWTigJ0gb3Ig4oCcZmlsdGVyIGNvbXBsZXhpdHkgbm90IHN1cHBvcnRhYmxl IGJ5IHBsYXRmb3Jt4oCdLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4t dG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBs Zm8zO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7 YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+U2VjdGlv biAzLjEg4oCTIERpc2N1c3Npb24gb24gdGhlIEVkaXRvcnMgbm90ZSAtIHRoZSBhZGRpdGlvbiBv ZiBhIOKAnGNoYW5nZXMtb25seeKAnSBmbGFnIGZvciBhIHBlcmlvZGljIHN1YnNjcmlwdGlvbi4g KFNvbWUgc3VwcG9ydCBmb3IgdGhpcywgYnV0IG1vcmUgZGlzY3Vzc2lvbiBpcyBuZWVkZWQgYXMg dGhlIHdvcmsgaXMgbm9uLXRyaXZpYWwuKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMz MzttYXJnaW4tdG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omwx IGxldmVsMSBsZm8zO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFs IGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+U2VjdGlvbiAzLjguNCDigJMgcmVjb21tZW5kIHJlbW92YWwgKG9rKTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3Vu ZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0 aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+U2VjdGlvbiA0LjQ6IHJlZHVjZSB0aGlzIGp1c3QgdG8gdGhl IG5ldyBwYXJhbWV0ZXJzIChjYW4gd2UgcmVtb3ZlIHRoaXMgZW50aXJlbHkgY29uc2lkZXJpbmcg c2VjdGlvbiAzLjE/IE9yIGRvIHdlIG1lcmdlIDMuMSBpbnRvIGhlcmU/KSAoRXJpYyB0YWxrIHRv IEFsZXgsIGxpa2VseSBvayk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw YW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2lu LXRvcDozLjBwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEg bGZvMztiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFs O2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNlY3Rp b24gNC42LjIgSXMgdGhlcmUgYW55IHJlYXNvbiB3aHkgd2UgY2Fu4oCZdCBoYXZlIHRoZSB0aW1l c3RhbXAgb24gdGhlIHlhbmcgcHVzaCBpbmNsdWRlIHRoZSBudW1iZXIgb2Ygc2lnbmlmaWNhbnQg ZGlnaXRzIGFzIGV4cHJlc3NlZCBieSB0cmFpbGluZyB6ZXJvcyBpZiBuZWNlc3Nhcnkgb24gdGhl IOKAnHRpbWUtb2YtdXBkYXRl4oCdLiBUaGlzDQogd291bGQgbGV0IHBsYXRmb3JtcyBleHByZXNz IHdoYXQgdGhleSBhcmUgY2FwYWJsZSBvZiBkb2luZy4gKE5vdGU6IHNlY29uZHMgd291bGQgYmUg YSBtaW5pbXVtIGdyYW51bGFyaXR5KS4gKHdlIHNob3VsZCBnbyB3aXRoIHRoaXMgaWYgcG9zc2li bGUuIFN1c2FuIEguIGlzIGdvaW5nIHRvIGNoZWNrIG9uIGJpbmFyeSByZXByZXNlbnRhdGlvbnMg aGVyZSB0byBzZWUgaWYgdmFyaWFibGUgZmllbGQgbGVuZ3RocyBtaWdodCBwb3NlIGEgcHJvYmxl bQ0KIGZvciBhbiB1cGRhdGUuKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJn aW4tdG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVs MSBsZm8zO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRp YWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+U2Vj dGlvbiA0LjYuMiBEbyB3ZSBkbyBzb21ldGhpbmcgb24gWUFORy1QdXNoIHN0YXRpc3RpY3MgKGUu Zy4gY291bnRlcnMgb2Ygb2JqZWN0IGNoYW5nZXMsIG9mIHVwZGF0ZSBtZXNzYWdlcyk/IChCb3Ro 4oCmIFRlc3QgYW5kIG5vcm1hbCBvcGVyYXRpb25zIG5lZWQgdG8gYmUgY292ZXJlZC4uIE1hdGNo IHRvIGZpbHRlcnMgd29ya2luZyBvcGVyYXRpb24NCiBxdWVzdGlvbik8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjRUVFRUVFIDEuMHB0O3BhZGRpbmc6MGluIDBpbiA0 LjBwdCAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1w b3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFs Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+RGFtcGVuaW5nOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzQ7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRp YWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5EYW1wZW4gY2FuIG1lYW4gbGVzc2VuLiBXZSBzaG91bGQgY2hvb3NlIERhbXAgb3IgRGFt cGVuIGJhc2VkIG9uIHVzYWdlIHRoZXJlZm9yZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNp cmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg bGV2ZWwyIGxmbzQ7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwg aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5Hb29nbGUgc2VhcmNoIGZvciDigJxyb3V0ZSBkYW1waW5n4oCdID0gNCw4NTAgaGl0cy48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDIgbGZvNDtiYWNrZ3JvdW5kOndoaXRl O2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0Omlu aXRpYWwgaW5pdGlhbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkdvb2dsZSBzZWFyY2ggZm9yIOKAnHJvdXRl IGRhbXBlbmluZ+KAnSA9IDExLDYwMCBoaXRzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMz MzttYXJnaW4tdG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm80O2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFs IGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+VGhlIG1vcmUgY29tbW9uIHVzYWdlIGlzIGRhbXBlbmluZywgc28gd2Ugc2hvdWxkIHN0aWNr IHdpdGggdGhhdC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9s aT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Ok5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPGJyPg0KLS08 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPkNoZWVycyw8YnI+DQpNZWhtZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5OZXRjb25mQGlldGYu b3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86bWpldGhhbmFu ZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_d554e8e5e8f24d528965163de8f02ef1XCHRTP013ciscocom_-- From nobody Sat Dec 3 00:50:16 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967E6129631 for ; Sat, 3 Dec 2016 00:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 ECI48AoL95Y5 for ; Sat, 3 Dec 2016 00:50:12 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC685129571 for ; Sat, 3 Dec 2016 00:50:11 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 557E815E6; Sat, 3 Dec 2016 09:50:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id o1UTRATbiJK3; Sat, 3 Dec 2016 09:50:08 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 3 Dec 2016 09:50:09 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE0A62005F; Sat, 3 Dec 2016 09:50:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jqeiSp6QvInY; Sat, 3 Dec 2016 09:50:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89E7F2005E; Sat, 3 Dec 2016 09:50:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 373863D9B20D; Sat, 3 Dec 2016 09:50:06 +0100 (CET) Date: Sat, 3 Dec 2016 09:50:06 +0100 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Message-ID: <20161203085006.GA91185@elstar.local> Mail-Followup-To: "Eric Voit (evoit)" , Mahesh Jethanandani , Mehmet Ersue , "netconf@ietf.org" References: <9573F76E-A55D-40AA-8FB2-53E207EA1FCF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 08:50:15 -0000 Hi, I can't follow discussions if people use email clients that do not do proper quotations. https://en.wikipedia.org/wiki/Posting_style /js On Fri, Dec 02, 2016 at 11:49:11PM +0000, Eric Voit (evoit) wrote: > From: Mahesh Jethanandani, December 2, 2016 6:20 PM > > [Chair hat off] > > Eric, > > What would help is to understand what the backward compatibility section would look like with your proposal. Currently it says that 5277bis will advertise "urn:ietf:params:netconf:capability:notification:1.0†and "urn:ietf:params:netconf:capability:notification:1.1â€. Clients can then choose which capability they are capable of and want to support. With the new proposal, are we dropping advertisement of "urn:ietf:params:netconf:capability:notification:1.0â€? > > Yes. Anyone who wants to use existing 5277 would just leverage to the old namespace. > > If the namespaces are truly different, and the server already supports 5277, what would be the implication of having two , in two different namespaces? > > There would be no in 1.1. With 5277bis the recommended RPC going forward is . In this way everything stays independent. But a server could chose to support both 1.0 & 1.1. This gives backwards compatibility in a single deployment. > > [Chair hat on] > > Echoing what Mehmet has already said. This is essentially a WG call. If you like/do not like this proposal, or have questions about it, this would be the time to speak up. > > I am absolutely good to go with whatever the WG decides. I do believe that obsoleting 5277 makes specification and implementation simpler, with no meaningful loss of functionality. > > Eric > > Cheers. > > On Dec 2, 2016, at 12:43 PM, MehmetErsue > wrote: > > Hi Eric, All, > > yes, we need a charter change since there is a difference between enhancing and replacing. > As I remember the charter discussion people were keen of having backwards compatibility because of deployed implementations. > > I believe we need to understand better the implications and what kind of "replacing" we would strive for. > Does replacing mean full deprecation of 5277 or will the compatibility between e.g. old client and new server be possible? > > I believe we need a discussion on this on the maillist and get the opinion of all parties. > At the end the WG will decide. > @All: > Please comment on replacing instead of enhancing 5277. > Please explain why you are in favor of replacing or against. > If you are in favor please explain what kind of replacing (i.e. compatibility level) you would like to have. > If you are in favor of keeping 5277 as standard and developing an additional independent notification mechanism please make its case. > Thanks, > Mehmet > > On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit) > wrote: > Hi Mehmet, > Hi Mahesh, > Hi Benoit, > > Item #6 in the NETCONF charter is: “Enhance RFC 5277 with the ability to delete subscriptions without closing the client session, to modify existing subscriptions, and to have multiple subscriptions on an established client session. These changes should not affect older clients that do not support these particular subscription requirements. The RPCs and the data models in RFC 5277 should be converted to YANG.†> > Those attending the Event Notification Dezign Team today believe that it is better to Obsolete 5277 it rather than Enhance it. The main reasons are: > > • The existing 5277 rpc and the new rpcs need to be in independent namespaces. Not supporting 5277 and a separate namespace / model will significantly simplify the new specification. > > • We can’t think of a reason why any YANG model developed for legacy 5277 namespace should be developed. New development is more likely to focus on the new model and its new capabilities > > • Any clients & servers desiring to support the old capabilities can certainly do this. Independent capability sets can be advertised. Backwards compatibility is not compromised. > > • Leaving backwards compatibility to embedded server code significantly reduces new development needs. > > As obsoleting 5277 with this new spec is a significant step, we wanted to get your and the community’s feedback and buy-in before we modify any of the documents in this direction. > > Would such a move mean a charter change? My suspicion is no as we are enhancing the functions supported by 5277 (but without bringing along the RPC). Do you have any guidance here? Is this worth having an interim meeting to discuss and finalize? > > Thanks, > Eric > > P.S.: Additional discussion on this is contained in minutes 2 to15 minutes of the WebEx audio recording below. > > From: Eric Voit, November 30, 2016 5:58 PM > Minutes posted at: > https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-11-30 > > • As always, our DezignTM Team is a gathering of individuals providing informal input to NETCONF. We ask NETCONF WG to comment on our discussion results as a preparation for the WG consensus. Please approach Eric Voit if you want to be included directly in these meetings. > > Meeting Materials > > Attending > > WebEx Recording > password: bXeveFV5 > > Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika Tripathy, Sharon Chisholm > > Obsolete RFC5277 or 5277bis? > > * If you are going to support both old and new capabilities, you will have your old 5277 code, and you will have your new code. Why develop a backwards compatible part of the spec which no one would or should implement. People should develop to the new capability. > > * 5277 already has enough changes to it (e.g., dataplane has moved to 6241 filtered notifications) > > * Recommendation for people on today's call is to Obsolete 5277 > * Must go to the WG, its chairs, and Benoit to confirm this recommendation before we adjust current documentation > Changes to the documents discussed today > [5277bis] > > * Scrub for error types in various subscription states. Authorization and other errors should be reported using the protocol-specific error codes; not specialized errors per these new RPCs. They still need to be identified though. Distinguish error types from subscription state so that you know the state a particular error happened during. > * Expose operational state of subscriptions in a separate YANG model or container. (i.e., add “-state†into naming convention for the ro part) > * Should subscription-id and filter-id both be id? (double-check, but we can do to the shorter description “identifierâ€) > * Do we rename push-source to “originates from†to be more explicit/accurate? (better name is needed. Include it in the terminology section.) > * Section 2.3 has SHOULD for 5277 filters. Not sure why this isn’t a MUST. Also we need a better name for 5277 filters. This name doesn’t expose what is possible, and what is not. Especially if we jettison 5277 compatibility, we need a better name for 6241, and we need to define the boundaries of filter solution. Andy has a strawman proposal. > * Delete create-subscription RPC and legacy namespace should WG agree. > * Do we do a test-only operation? (Let’s not do this work without an advocate) > * We need a way to test if the filters are doing what we expect they are doing. (Perhaps counters/captures on an active subscription?) > * For configured subscriptions, make receiver key ip address and port. At this point we don’t want VRF > * Change source-vrf description to indicate that we should align with names from draft-ietf-rtgwg-ni-model-01 should it complete in time. > * start-time in the YANG model from startTime as we don’t have to worry about backwards compatible RPC. > * Make stream type string rather than identity (preference for identity, but not willing to fight. Note: this could change based on what happens with filters) > [Yang-push] > > * Need to define error type for each subscription parameter such as “encoding not definedâ€, “Filter syntax not supported†or “filter complexity not supportable by platformâ€. > * Section 3.1 – Discussion on the Editors note - the addition of a “changes-only†flag for a periodic subscription. (Some support for this, but more discussion is needed as the work is non-trivial.) > * Section 3.8.4 – recommend removal (ok) > * Section 4.4: reduce this just to the new parameters (can we remove this entirely considering section 3.1? Or do we merge 3.1 into here?) (Eric talk to Alex, likely ok) > * Section 4.6.2 Is there any reason why we can’t have the timestamp on the yang push include the number of significant digits as expressed by trailing zeros if necessary on the “time-of-updateâ€. This would let platforms express what they are capable of doing. (Note: seconds would be a minimum granularity). (we should go with this if possible. Susan H. is going to check on binary representations here to see if variable field lengths might pose a problem for an update.) > * Section 4.6.2 Do we do something on YANG-Push statistics (e.g. counters of object changes, of update messages)? (Both… Test and normal operations need to be covered.. Match to filters working operation question) > Dampening: > > * Dampen can mean lessen. We should choose Damp or Dampen based on usage therefore. > > * Google search for “route damping†= 4,850 hits. > * Google search for “route dampening†= 11,600 hits > > * The more common usage is dampening, so we should stick with that. > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > Cheers, > Mehmet > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Dec 3 01:01:30 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBBF12963A; Sat, 3 Dec 2016 01:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 8kxv2ARa2CTA; Sat, 3 Dec 2016 01:01:28 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C96129635; Sat, 3 Dec 2016 01:01:27 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 85E38103A; Sat, 3 Dec 2016 10:01:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kl8ad5zDwa8q; Sat, 3 Dec 2016 10:01:26 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 3 Dec 2016 10:01:26 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C1A62005E; Sat, 3 Dec 2016 10:01:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12nbU9Rgu4pK; Sat, 3 Dec 2016 10:01:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1D652005F; Sat, 3 Dec 2016 10:01:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B865D3D9B2AF; Sat, 3 Dec 2016 10:01:25 +0100 (CET) Date: Sat, 3 Dec 2016 10:01:25 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20161203090125.GB91185@elstar.local> Mail-Followup-To: Andy Bierman , NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs Subject: Re: [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 09:01:30 -0000 On Fri, Dec 02, 2016 at 01:44:34PM -0800, Andy Bierman wrote: > > I have concerns about impact of this work on all YANG-based protocols. > I have asked several times "how do you decide which servers need to > implement the intended and applied datastores?" and never got an answer. > I do not think people proposed to make the implementation of intended and applied datastores mandatory to implement. What this proposal is trying to achieve is to provide an architectural framework that allows to provide access to additional datastores without having to write data models in certain ways. Keeping the specific datastore semantics out of data models (and thereby simplifying data models) is what I see as the main value of this work. > I think an Applicability Statement is needed for this work because some > systems > converge so fast that the difference between intended and applied > (for real edits, forget cards not plugged in) will be insignificant. The current I-D says in section 6.1: o Support for , , and should be optional to implement. /js PS: Do we have to run the discussion via cross-posts on two lists or can the chairs agree to just use one list, assuming that those who care can manage to follow this one list? -- 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 Dec 3 02:18:07 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B25412967C for ; Sat, 3 Dec 2016 02:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zl14ZeeKaFq for ; Sat, 3 Dec 2016 02:18:01 -0800 (PST) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273EE129665 for ; Sat, 3 Dec 2016 02:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References: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=SyU46YaU3fDK4M2oOPIvI6gWHCa5cIGjCuVnt+azLIc=; b=dss1C+Vd9f8IHKcIIHVNYyK0TV IOHuggydt21Zf1XZK9lq7rAylncm+zZZDTMS4NntyHdA1LOY9mBELXo38tXxja0vGJbpRf8fJFHzH JGhuvJue50jUoUkzWD3Tt2fSCDU91iO2S6jKZ1ZCyUfFbnQeMa7euIKfb6SJRKUkWJHCa1GdtdUr7 xT0EV+6HkGVXr+tKE50Uqvx+/BJDO10J66TCFxlBsIFHopkPvBk3xtnIOu9IQ2kaMkMKF+sui3oUb 6W7NPPSgvjBkDf2VtQTrnwLmUe3FwfrptmwnJvGg/UUd16HuuJxFGouxLtslyGRPsBKmzqSyCiJOa jvkVO5WA==; Received: from hansfords.plus.com ([84.92.116.209]:36261 helo=Vanguard) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cD7OH-003ZaP-PI; Sat, 03 Dec 2016 10:17:57 +0000 From: "Jonathan Hansford" To: "'Juergen Schoenwaelder'" , "'Eric Voit \(evoit\)'" References: <9573F76E-A55D-40AA-8FB2-53E207EA1FCF@gmail.com> <20161203085006.GA91185@elstar.local> In-Reply-To: <20161203085006.GA91185@elstar.local> Date: Sat, 3 Dec 2016 10:17:58 -0000 Message-ID: <001801d24d4e$85a58210$90f08630$@hansfords.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 thread-index: AQIZ1qZbahVmA0Zvp1e4F2NiMeIGpgIbNIy1Akk/bOAB+iRf6gJLJ6PboCGhY2A= Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 10:18:04 -0000 Are you proposing a specific style of quoting, or are any of those = listed acceptable? The Wikipedia page doesn't identify what "proper = quotations" are. Jonathan > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: 03 December 2016 08:50 > To: Eric Voit (evoit) > Cc: netconf@ietf.org > Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver >=20 > Hi, >=20 > I can't follow discussions if people use email clients that do not do = proper > quotations. https://en.wikipedia.org/wiki/Posting_style >=20 > /js >=20 > On Fri, Dec 02, 2016 at 11:49:11PM +0000, Eric Voit (evoit) wrote: > > From: Mahesh Jethanandani, December 2, 2016 6:20 PM > > > > [Chair hat off] > > > > Eric, > > > > What would help is to understand what the backward compatibility = section > would look like with your proposal. Currently it says that 5277bis = will > advertise = "urn:ietf:params:netconf:capability:notification:1.0=E2=80=9D and > "urn:ietf:params:netconf:capability:notification:1.1=E2=80=9D. Clients = can then choose > which capability they are capable of and want to support. With the new > proposal, are we dropping advertisement of > "urn:ietf:params:netconf:capability:notification:1.0=E2=80=9D? > > > > Yes. Anyone who wants to use existing 5277 would just leverage to = the old > namespace. > > > > If the namespaces are truly different, and the server already = supports > 5277, what would be the implication of having two = , in > two different namespaces? > > > > There would be no in 1.1. With 5277bis the > recommended RPC going forward is . In this = way > everything stays independent. But a server could chose to support = both 1.0 > & 1.1. This gives backwards compatibility in a single deployment. > > > > [Chair hat on] > > > > Echoing what Mehmet has already said. This is essentially a WG call. = If you > like/do not like this proposal, or have questions about it, this would = be the > time to speak up. > > > > I am absolutely good to go with whatever the WG decides. I do = believe > that obsoleting 5277 makes specification and implementation simpler, = with > no meaningful loss of functionality. > > > > Eric > > > > Cheers. > > > > On Dec 2, 2016, at 12:43 PM, MehmetErsue > > wrote: > > > > Hi Eric, All, > > > > yes, we need a charter change since there is a difference between > enhancing and replacing. > > As I remember the charter discussion people were keen of having > backwards compatibility because of deployed implementations. > > > > I believe we need to understand better the implications and what = kind of > "replacing" we would strive for. > > Does replacing mean full deprecation of 5277 or will the = compatibility > between e.g. old client and new server be possible? > > > > I believe we need a discussion on this on the maillist and get the = opinion of > all parties. > > At the end the WG will decide. > > @All: > > Please comment on replacing instead of enhancing 5277. > > Please explain why you are in favor of replacing or against. > > If you are in favor please explain what kind of replacing (i.e. = compatibility > level) you would like to have. > > If you are in favor of keeping 5277 as standard and developing an = additional > independent notification mechanism please make its case. > > Thanks, > > Mehmet > > > > On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit) > > wrote: > > Hi Mehmet, > > Hi Mahesh, > > Hi Benoit, > > > > Item #6 in the NETCONF charter is: =E2=80=9CEnhance RFC 5277 with = the ability to > delete subscriptions without closing the client session, to modify = existing > subscriptions, and to have multiple subscriptions on an established = client > session. These changes should not affect older clients that do not = support > these particular subscription requirements. The RPCs and the data = models in > RFC 5277 should be converted to YANG.=E2=80=9D > > > > Those attending the Event Notification Dezign Team today believe = that it is > better to Obsolete 5277 it rather than Enhance it. The main reasons = are: > > > > =E2=80=A2 The existing 5277 rpc and the = new rpcs need to > be in independent namespaces. Not supporting 5277 > and a separate namespace / model will significantly simplify the new > specification. > > > > =E2=80=A2 We can=E2=80=99t think of a reason why any YANG = model developed for legacy > 5277 namespace should be developed. New development is more likely to > focus on the new model and its new capabilities > > > > =E2=80=A2 Any clients & servers desiring to support the old = capabilities can > certainly do this. Independent capability sets can be advertised. = Backwards > compatibility is not compromised. > > > > =E2=80=A2 Leaving backwards compatibility to embedded server = code > significantly reduces new development needs. > > > > As obsoleting 5277 with this new spec is a significant step, we = wanted to > get your and the community=E2=80=99s feedback and buy-in before we = modify any of > the documents in this direction. > > > > Would such a move mean a charter change? My suspicion is no as we = are > enhancing the functions supported by 5277 (but without bringing along = the > RPC). Do you have any guidance here? Is this worth having an = interim > meeting to discuss and finalize? > > > > Thanks, > > Eric > > > > P.S.: Additional discussion on this is contained in minutes 2 to15 = minutes of > the WebEx audio recording below. > > > > From: Eric Voit, November 30, 2016 5:58 PM Minutes posted at: > > https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-11-30 > > > > =E2=80=A2 As always, our DezignTM Team is a gathering of = individuals providing > informal input to NETCONF. We ask NETCONF WG to comment on our > discussion results as a preparation for the WG consensus. Please = approach > Eric Voit if you want to be included directly in these meetings. > > > > Meeting Materials > > > > Attending > > > > WebEx > > > = Recording > 47dd8cff3772739f66c4> > > password: bXeveFV5 > > > > Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar = Nilsen-Nygaard, > > Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika Tripathy, > > Sharon Chisholm > > > > Obsolete RFC5277 or 5277bis? > > > > * If you are going to support both old and new capabilities, you = will have > your old 5277 code, and you will have your new code. Why develop a > backwards compatible part of the spec which no one would or should > implement. People should develop to the new capability. > > > > * 5277 already has enough changes to it (e.g., dataplane has = moved to > 6241 filtered notifications) > > > > * Recommendation for people on today's call is to Obsolete 5277 > > * Must go to the WG, its chairs, and Benoit to confirm this > recommendation before we adjust current documentation > > Changes to the documents discussed today [5277bis] > > > > * Scrub for error types in various subscription states. = Authorization and > other errors should be reported using the protocol-specific error = codes; not > specialized errors per these new RPCs. They still need to be = identified > though. Distinguish error types from subscription state so that you = know the > state a particular error happened during. > > * Expose operational state of subscriptions in a separate YANG = model or > container. (i.e., add =E2=80=9C-state=E2=80=9D into naming convention = for the ro part) > > * Should subscription-id and filter-id both be id? = (double-check, but we > can do to the shorter description =E2=80=9Cidentifier=E2=80=9D) > > * Do we rename push-source to =E2=80=9Coriginates from=E2=80=9D = to be more > explicit/accurate? (better name is needed. Include it in the = terminology > section.) > > * Section 2.3 has SHOULD for 5277 filters. Not sure why this = isn=E2=80=99t a MUST. > Also we need a better name for 5277 filters. This name doesn=E2=80=99t = expose what > is possible, and what is not. Especially if we jettison 5277 = compatibility, we > need a better name for 6241, and we need to define the boundaries of = filter > solution. Andy has a strawman proposal. > > * Delete create-subscription RPC and legacy namespace should WG > agree. > > * Do we do a test-only operation? (Let=E2=80=99s not do this = work without an > advocate) > > * We need a way to test if the filters are doing what we expect = they are > doing. (Perhaps counters/captures on an active subscription?) > > * For configured subscriptions, make receiver key ip address and = port. At > this point we don=E2=80=99t want VRF > > * Change source-vrf description to indicate that we should align = with > names from draft-ietf-rtgwg-ni-model-01 should it complete in time. > > * start-time in the YANG model from startTime as we = don=E2=80=99t have to worry > about backwards compatible RPC. > > * Make stream type string rather than identity (preference for = identity, > but not willing to fight. Note: this could change based on what = happens with > filters) > > [Yang-push] > > > > * Need to define error type for each subscription parameter such = as > =E2=80=9Cencoding not defined=E2=80=9D, =E2=80=9CFilter syntax not = supported=E2=80=9D or =E2=80=9Cfilter complexity > not supportable by platform=E2=80=9D. > > * Section 3.1 =E2=80=93 Discussion on the Editors note - the = addition of a > =E2=80=9Cchanges-only=E2=80=9D flag for a periodic subscription. (Some = support for this, but > more discussion is needed as the work is non-trivial.) > > * Section 3.8.4 =E2=80=93 recommend removal (ok) > > * Section 4.4: reduce this just to the new parameters (can we = remove > this entirely considering section 3.1? Or do we merge 3.1 into here?) = (Eric talk > to Alex, likely ok) > > * Section 4.6.2 Is there any reason why we can=E2=80=99t have = the timestamp on > the yang push include the number of significant digits as expressed by = trailing > zeros if necessary on the =E2=80=9Ctime-of-update=E2=80=9D. This would = let platforms express > what they are capable of doing. (Note: seconds would be a minimum > granularity). (we should go with this if possible. Susan H. is going = to check on > binary representations here to see if variable field lengths might = pose a > problem for an update.) > > * Section 4.6.2 Do we do something on YANG-Push statistics (e.g. > counters of object changes, of update messages)? (Both=E2=80=A6 Test = and normal > operations need to be covered.. Match to filters working operation = question) > > Dampening: > > > > * Dampen can mean lessen. We should choose Damp or Dampen based > on usage therefore. > > > > * Google search for =E2=80=9Croute damping=E2=80=9D =3D 4,850 = hits. > > * Google search for =E2=80=9Croute dampening=E2=80=9D =3D = 11,600 hits > > > > * The more common usage is dampening, so we should stick with = that. > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > -- > > Cheers, > > Mehmet > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > >=20 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Sat Dec 3 03:25:00 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04E21296C8 for ; Sat, 3 Dec 2016 03:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 iytlaxj1GQGa for ; Sat, 3 Dec 2016 03:24:55 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78CC01296C6 for ; Sat, 3 Dec 2016 03:24:55 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4FBA21571; Sat, 3 Dec 2016 12:24:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id viHu7b0NwM0E; Sat, 3 Dec 2016 12:24:52 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 3 Dec 2016 12:24:52 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8EB812005F; Sat, 3 Dec 2016 12:24:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id V9lND-h7fHIX; Sat, 3 Dec 2016 12:24:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BFFD2005E; Sat, 3 Dec 2016 12:24:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 579363D9B5DA; Sat, 3 Dec 2016 12:24:49 +0100 (CET) Date: Sat, 3 Dec 2016 12:24:49 +0100 From: Juergen Schoenwaelder To: Jonathan Hansford Message-ID: <20161203112449.GA91431@elstar.local> Mail-Followup-To: Jonathan Hansford , netconf@ietf.org References: <9573F76E-A55D-40AA-8FB2-53E207EA1FCF@gmail.com> <20161203085006.GA91185@elstar.local> <001801d24d4e$85a58210$90f08630$@hansfords.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <001801d24d4e$85a58210$90f08630$@hansfords.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 11:24:59 -0000 I just note that reading email discussion is becoming increasingly difficult since I often can't find where the statement is that is being made. I do not want to start a discussion here. Perhaps some people are willing to spent some time to see whether they can improve their email client configuration - or they don't (but then I might not read their email correctly). Peronally, I believe quoted line prefixes style (aka Usenet quoting) has the longest tradition and is likely the most unambiguous style since it allows nesting. /js On Sat, Dec 03, 2016 at 10:17:58AM +0000, Jonathan Hansford wrote: > Are you proposing a specific style of quoting, or are any of those listed acceptable? The Wikipedia page doesn't identify what "proper quotations" are. > > Jonathan > > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: 03 December 2016 08:50 > > To: Eric Voit (evoit) > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver > > > > Hi, > > > > I can't follow discussions if people use email clients that do not do proper > > quotations. https://en.wikipedia.org/wiki/Posting_style > > > > /js > > > > On Fri, Dec 02, 2016 at 11:49:11PM +0000, Eric Voit (evoit) wrote: > > > From: Mahesh Jethanandani, December 2, 2016 6:20 PM > > > > > > [Chair hat off] > > > > > > Eric, > > > > > > What would help is to understand what the backward compatibility section > > would look like with your proposal. Currently it says that 5277bis will > > advertise "urn:ietf:params:netconf:capability:notification:1.0†and > > "urn:ietf:params:netconf:capability:notification:1.1â€. Clients can then choose > > which capability they are capable of and want to support. With the new > > proposal, are we dropping advertisement of > > "urn:ietf:params:netconf:capability:notification:1.0â€? > > > > > > Yes. Anyone who wants to use existing 5277 would just leverage to the old > > namespace. > > > > > > If the namespaces are truly different, and the server already supports > > 5277, what would be the implication of having two , in > > two different namespaces? > > > > > > There would be no in 1.1. With 5277bis the > > recommended RPC going forward is . In this way > > everything stays independent. But a server could chose to support both 1.0 > > & 1.1. This gives backwards compatibility in a single deployment. > > > > > > [Chair hat on] > > > > > > Echoing what Mehmet has already said. This is essentially a WG call. If you > > like/do not like this proposal, or have questions about it, this would be the > > time to speak up. > > > > > > I am absolutely good to go with whatever the WG decides. I do believe > > that obsoleting 5277 makes specification and implementation simpler, with > > no meaningful loss of functionality. > > > > > > Eric > > > > > > Cheers. > > > > > > On Dec 2, 2016, at 12:43 PM, MehmetErsue > > > wrote: > > > > > > Hi Eric, All, > > > > > > yes, we need a charter change since there is a difference between > > enhancing and replacing. > > > As I remember the charter discussion people were keen of having > > backwards compatibility because of deployed implementations. > > > > > > I believe we need to understand better the implications and what kind of > > "replacing" we would strive for. > > > Does replacing mean full deprecation of 5277 or will the compatibility > > between e.g. old client and new server be possible? > > > > > > I believe we need a discussion on this on the maillist and get the opinion of > > all parties. > > > At the end the WG will decide. > > > @All: > > > Please comment on replacing instead of enhancing 5277. > > > Please explain why you are in favor of replacing or against. > > > If you are in favor please explain what kind of replacing (i.e. compatibility > > level) you would like to have. > > > If you are in favor of keeping 5277 as standard and developing an additional > > independent notification mechanism please make its case. > > > Thanks, > > > Mehmet > > > > > > On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit) > > > wrote: > > > Hi Mehmet, > > > Hi Mahesh, > > > Hi Benoit, > > > > > > Item #6 in the NETCONF charter is: “Enhance RFC 5277 with the ability to > > delete subscriptions without closing the client session, to modify existing > > subscriptions, and to have multiple subscriptions on an established client > > session. These changes should not affect older clients that do not support > > these particular subscription requirements. The RPCs and the data models in > > RFC 5277 should be converted to YANG.†> > > > > > Those attending the Event Notification Dezign Team today believe that it is > > better to Obsolete 5277 it rather than Enhance it. The main reasons are: > > > > > > • The existing 5277 rpc and the new rpcs need to > > be in independent namespaces. Not supporting 5277 > > and a separate namespace / model will significantly simplify the new > > specification. > > > > > > • We can’t think of a reason why any YANG model developed for legacy > > 5277 namespace should be developed. New development is more likely to > > focus on the new model and its new capabilities > > > > > > • Any clients & servers desiring to support the old capabilities can > > certainly do this. Independent capability sets can be advertised. Backwards > > compatibility is not compromised. > > > > > > • Leaving backwards compatibility to embedded server code > > significantly reduces new development needs. > > > > > > As obsoleting 5277 with this new spec is a significant step, we wanted to > > get your and the community’s feedback and buy-in before we modify any of > > the documents in this direction. > > > > > > Would such a move mean a charter change? My suspicion is no as we are > > enhancing the functions supported by 5277 (but without bringing along the > > RPC). Do you have any guidance here? Is this worth having an interim > > meeting to discuss and finalize? > > > > > > Thanks, > > > Eric > > > > > > P.S.: Additional discussion on this is contained in minutes 2 to15 minutes of > > the WebEx audio recording below. > > > > > > From: Eric Voit, November 30, 2016 5:58 PM Minutes posted at: > > > https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-11-30 > > > > > > • As always, our DezignTM Team is a gathering of individuals providing > > informal input to NETCONF. We ask NETCONF WG to comment on our > > discussion results as a preparation for the WG consensus. Please approach > > Eric Voit if you want to be included directly in these meetings. > > > > > > Meeting Materials > > > > > > Attending > > > > > > WebEx > > > > > Recording > > 47dd8cff3772739f66c4> > > > password: bXeveFV5 > > > > > > Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, > > > Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika Tripathy, > > > Sharon Chisholm > > > > > > Obsolete RFC5277 or 5277bis? > > > > > > * If you are going to support both old and new capabilities, you will have > > your old 5277 code, and you will have your new code. Why develop a > > backwards compatible part of the spec which no one would or should > > implement. People should develop to the new capability. > > > > > > * 5277 already has enough changes to it (e.g., dataplane has moved to > > 6241 filtered notifications) > > > > > > * Recommendation for people on today's call is to Obsolete 5277 > > > * Must go to the WG, its chairs, and Benoit to confirm this > > recommendation before we adjust current documentation > > > Changes to the documents discussed today [5277bis] > > > > > > * Scrub for error types in various subscription states. Authorization and > > other errors should be reported using the protocol-specific error codes; not > > specialized errors per these new RPCs. They still need to be identified > > though. Distinguish error types from subscription state so that you know the > > state a particular error happened during. > > > * Expose operational state of subscriptions in a separate YANG model or > > container. (i.e., add “-state†into naming convention for the ro part) > > > * Should subscription-id and filter-id both be id? (double-check, but we > > can do to the shorter description “identifierâ€) > > > * Do we rename push-source to “originates from†to be more > > explicit/accurate? (better name is needed. Include it in the terminology > > section.) > > > * Section 2.3 has SHOULD for 5277 filters. Not sure why this isn’t a MUST. > > Also we need a better name for 5277 filters. This name doesn’t expose what > > is possible, and what is not. Especially if we jettison 5277 compatibility, we > > need a better name for 6241, and we need to define the boundaries of filter > > solution. Andy has a strawman proposal. > > > * Delete create-subscription RPC and legacy namespace should WG > > agree. > > > * Do we do a test-only operation? (Let’s not do this work without an > > advocate) > > > * We need a way to test if the filters are doing what we expect they are > > doing. (Perhaps counters/captures on an active subscription?) > > > * For configured subscriptions, make receiver key ip address and port. At > > this point we don’t want VRF > > > * Change source-vrf description to indicate that we should align with > > names from draft-ietf-rtgwg-ni-model-01 should it complete in time. > > > * start-time in the YANG model from startTime as we don’t have to worry > > about backwards compatible RPC. > > > * Make stream type string rather than identity (preference for identity, > > but not willing to fight. Note: this could change based on what happens with > > filters) > > > [Yang-push] > > > > > > * Need to define error type for each subscription parameter such as > > “encoding not definedâ€, “Filter syntax not supported†or “filter complexity > > not supportable by platformâ€. > > > * Section 3.1 – Discussion on the Editors note - the addition of a > > “changes-only†flag for a periodic subscription. (Some support for this, but > > more discussion is needed as the work is non-trivial.) > > > * Section 3.8.4 – recommend removal (ok) > > > * Section 4.4: reduce this just to the new parameters (can we remove > > this entirely considering section 3.1? Or do we merge 3.1 into here?) (Eric talk > > to Alex, likely ok) > > > * Section 4.6.2 Is there any reason why we can’t have the timestamp on > > the yang push include the number of significant digits as expressed by trailing > > zeros if necessary on the “time-of-updateâ€. This would let platforms express > > what they are capable of doing. (Note: seconds would be a minimum > > granularity). (we should go with this if possible. Susan H. is going to check on > > binary representations here to see if variable field lengths might pose a > > problem for an update.) > > > * Section 4.6.2 Do we do something on YANG-Push statistics (e.g. > > counters of object changes, of update messages)? (Both… Test and normal > > operations need to be covered.. Match to filters working operation question) > > > Dampening: > > > > > > * Dampen can mean lessen. We should choose Damp or Dampen based > > on usage therefore. > > > > > > * Google search for “route damping†= 4,850 hits. > > > * Google search for “route dampening†= 11,600 hits > > > > > > * The more common usage is dampening, so we should stick with that. > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > -- > > > Cheers, > > > Mehmet > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > Mahesh Jethanandani > > > mjethanandani@gmail.com > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Dec 3 11:02:46 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBF41299B4 for ; Sat, 3 Dec 2016 11:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6Yy0JLEyBLC for ; Sat, 3 Dec 2016 11:02:43 -0800 (PST) Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com [209.85.192.182]) (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 4F265129980 for ; Sat, 3 Dec 2016 11:02:43 -0800 (PST) Received: by mail-pf0-f182.google.com with SMTP id 189so57433771pfz.3 for ; Sat, 03 Dec 2016 11:02:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ufac/NL/HkimRi2QgaHZ10XNBQV8Bk8qL7g259vHbF4=; b=lZHapdY7NpcfNjTyqZHSbeqn4bL3eq42BWzQsOOG+2vXyvNsP5fSRSYD2N8eyKjwP/ bjrK9yV6H4EiMI+P1nhiv7nYHqFOmb57cXQcmtIgjZNYTAKV0yFQ1raN9akpEzvb5DAV CUaVoV+Jsqx9U/TRsLIFleLhXSKAKp2orF7uguCx6jZSolWUoFkYm7cB10tc05nUtdWD Hya1zzfIGQ9JbQExswb7/3nLRzYhl29bfNYLNZkhwjK+a1HDoUklxq/CPnYDgz60IaDF 5tYq0YRwQoHt3akVWqmoAVnwgd3NUISwNpXvy+Fy5eisqQiyhieiAMZEMkd0mL5DHj4J aheQ== X-Gm-Message-State: AKaTC02ugzTlXcBQXUH/AGaMWUN5ymoHHodhPrfi0c2GQ+vDlhyYod7zv6wb8VBfNnzajxu1 X-Received: by 10.99.136.194 with SMTP id l185mr90041495pgd.106.1480791762297; Sat, 03 Dec 2016 11:02:42 -0800 (PST) Received: from [192.168.1.114] (c-50-168-48-150.hsd1.ca.comcast.net. [50.168.48.150]) by smtp.gmail.com with ESMTPSA id m5sm16484435pgn.42.2016.12.03.11.02.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Dec 2016 11:02:41 -0800 (PST) To: netconf@ietf.org References: <9573F76E-A55D-40AA-8FB2-53E207EA1FCF@gmail.com> <20161203085006.GA91185@elstar.local> <001801d24d4e$85a58210$90f08630$@hansfords.net> <20161203112449.GA91431@elstar.local> From: Randy Presuhn Message-ID: Date: Sat, 3 Dec 2016 11:02:40 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161203112449.GA91431@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] Quoting [Was: Re: 5277 Backwards Compatibility: how to deliver] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 19:02:45 -0000 Hi - On 12/3/2016 3:24 AM, Juergen Schoenwaelder wrote: ... > Peronally, I believe quoted line prefixes style (aka Usenet quoting) > has the longest tradition and is likely the most unambiguous style > since it allows nesting. Agreed. In addition to that style preference, I'd also like to see more selectively trimmed quotations, rather than each message containing the entire thread of preceding messages. Randy From nobody Sun Dec 4 07:53:01 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA6A129546 for ; Sun, 4 Dec 2016 07:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78yJhV95_YBH for ; Sun, 4 Dec 2016 07:52:57 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14108129543 for ; Sun, 4 Dec 2016 07:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17720; q=dns/txt; s=iport; t=1480866776; x=1482076376; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SU0gIuMRWpEeqYCJX2XCrK6PdF+JKbEBC8D0oqDqu+g=; b=P0vF3h6n9KwgTKq4PManaqOxzZeL2+e9XTwLf9Ae13GOjPEaK45PT3SA 4ZktyPlueMeoTNUz7mGd2dgS3mkEAdfMoUVcNnHlpToiIieTMA3Toh8Vo ILNskDEIbsB3+tAXEg9/lUycuWjK9vhc1YiqqFYz+MdxKqyiLhdowI8PJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQCOOkRY/4kNJK1DEAEGAxkBAQEBA?= =?us-ascii?q?QEBAQEBAQcBAQEBAYM4AQEBAQEfWoEGB41AlwmHdI0JgggeC4UvSgIaggM/FAE?= =?us-ascii?q?CAQEBAQEBAWIohGgBAQEDAQEBIRE6CwUHAgICAQgQAQQBAQECAgkLDAMDAgICG?= =?us-ascii?q?QYGCxQBCAgCBAENAwIIDAeIOgMPCA4urQSCKYNYg1ANg3YBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEcBYEGhTOEW4JIQ4EPBgEKAQYtCiYHgjaCXQWOf4syNQGGSoMJD?= =?us-ascii?q?YNVg1iBe4R9iU6HYIFthDUQIINcAR83PSQ4I4M5HIFdQTEBhjiBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,299,1477958400"; d="scan'208";a="182832796" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Dec 2016 15:52:55 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB4Fqt80028064 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 4 Dec 2016 15:52:55 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 4 Dec 2016 10:52:54 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Sun, 4 Dec 2016 10:52:54 -0500 From: "Eric Voit (evoit)" To: Jonathan Hansford , "'Juergen Schoenwaelder'" Thread-Topic: [Netconf] 5277 Backwards Compatibility: how to deliver Thread-Index: AQHSTPKpMbSMFOERPEaUZemTbQCTuKD1UOxAgADtfQCAAClQAIABigXw Date: Sun, 4 Dec 2016 15:52:54 +0000 Message-ID: <6c30460433f84b2e9860594a07f5865a@XCH-RTP-013.cisco.com> References: <9573F76E-A55D-40AA-8FB2-53E207EA1FCF@gmail.com> <20161203085006.GA91185@elstar.local> <001801d24d4e$85a58210$90f08630$@hansfords.net> In-Reply-To: <001801d24d4e$85a58210$90f08630$@hansfords.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 15:53:00 -0000 PiBGcm9tOiBKb25hdGhhbiBIYW5zZm9yZCwgRGVjZW1iZXIgMywgMjAxNiA1OjE4IEFNDQo+IA0K PiBBcmUgeW91IHByb3Bvc2luZyBhIHNwZWNpZmljIHN0eWxlIG9mIHF1b3RpbmcsIG9yIGFyZSBh bnkgb2YgdGhvc2UgbGlzdGVkDQo+IGFjY2VwdGFibGU/IFRoZSBXaWtpcGVkaWEgcGFnZSBkb2Vz bid0IGlkZW50aWZ5IHdoYXQgInByb3BlciBxdW90YXRpb25zIiBhcmUuDQo+IA0KPiBKb25hdGhh bg0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBOZXRj b25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVlcmdl bg0KPiA+IFNjaG9lbndhZWxkZXINCj4gPiBTZW50OiAwMyBEZWNlbWJlciAyMDE2IDA4OjUwDQo+ ID4gVG86IEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb20+DQo+ID4gQ2M6IG5ldGNv bmZAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIDUyNzcgQmFja3dhcmRzIENv bXBhdGliaWxpdHk6IGhvdyB0byBkZWxpdmVyDQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IEkgY2Fu J3QgZm9sbG93IGRpc2N1c3Npb25zIGlmIHBlb3BsZSB1c2UgZW1haWwgY2xpZW50cyB0aGF0IGRv IG5vdCBkbw0KPiA+IHByb3BlciBxdW90YXRpb25zLiBodHRwczovL2VuLndpa2lwZWRpYS5vcmcv d2lraS9Qb3N0aW5nX3N0eWxlDQoNCk15IHN0eWxlIHVudGlsIG5vdyBoYXMgYmVlbiB0byByZXBs eSB0byBwZW9wbGUgdXNpbmcgdGhlIHN0eWxlIHdoaWNoIEkgcmVjZWl2ZWQuICBJIHdpbGwgZW5k ZWF2b3IgdG8gc2hpZnQgdG8gdGV4dC1vbmx5IHdoZW4gY2MnaW5nIE5FVENPTkYuIA0KDQpFcmlj DQoNCj4gPiAvanMNCj4gPg0KPiA+IE9uIEZyaSwgRGVjIDAyLCAyMDE2IGF0IDExOjQ5OjExUE0g KzAwMDAsIEVyaWMgVm9pdCAoZXZvaXQpIHdyb3RlOg0KPiA+ID4gRnJvbTogTWFoZXNoIEpldGhh bmFuZGFuaSwgRGVjZW1iZXIgMiwgMjAxNiA2OjIwIFBNDQo+ID4gPg0KPiA+ID4gW0NoYWlyIGhh dCBvZmZdDQo+ID4gPg0KPiA+ID4gRXJpYywNCj4gPiA+DQo+ID4gPiBXaGF0IHdvdWxkIGhlbHAg aXMgdG8gdW5kZXJzdGFuZCB3aGF0IHRoZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5DQo+ID4gPiBz ZWN0aW9uDQo+ID4gd291bGQgbG9vayBsaWtlIHdpdGggeW91ciBwcm9wb3NhbC4gQ3VycmVudGx5 IGl0IHNheXMgdGhhdCA1Mjc3YmlzDQo+ID4gd2lsbCBhZHZlcnRpc2UgInVybjppZXRmOnBhcmFt czpuZXRjb25mOmNhcGFiaWxpdHk6bm90aWZpY2F0aW9uOjEuMOKAnQ0KPiA+IGFuZCAidXJuOmll dGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4x4oCdLiBDbGllbnRz IGNhbg0KPiA+IHRoZW4gY2hvb3NlIHdoaWNoIGNhcGFiaWxpdHkgdGhleSBhcmUgY2FwYWJsZSBv ZiBhbmQgd2FudCB0byBzdXBwb3J0Lg0KPiA+IFdpdGggdGhlIG5ldyBwcm9wb3NhbCwgYXJlIHdl IGRyb3BwaW5nIGFkdmVydGlzZW1lbnQgb2YNCj4gPiAidXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6 Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4w4oCdPw0KPiA+ID4NCj4gPiA+IFllcy4gIEFueW9u ZSB3aG8gd2FudHMgdG8gdXNlIGV4aXN0aW5nIDUyNzcgd291bGQganVzdCBsZXZlcmFnZSB0bw0K PiA+ID4gdGhlIG9sZA0KPiA+IG5hbWVzcGFjZS4NCj4gPiA+DQo+ID4gPiBJZiB0aGUgbmFtZXNw YWNlcyBhcmUgdHJ1bHkgZGlmZmVyZW50LCBhbmQgdGhlIHNlcnZlciBhbHJlYWR5DQo+ID4gPiBz dXBwb3J0cw0KPiA+IDUyNzcsIHdoYXQgd291bGQgYmUgdGhlIGltcGxpY2F0aW9uIG9mIGhhdmlu ZyB0d28NCj4gPiA8Y3JlYXRlLXN1YnNjcmlwdGlvbj4sIGluIHR3byBkaWZmZXJlbnQgbmFtZXNw YWNlcz8NCj4gPiA+DQo+ID4gPiBUaGVyZSB3b3VsZCBiZSBubyA8Y3JlYXRlLXN1YnNjcmlwdGlv bj4gaW4gMS4xLiAgIFdpdGggNTI3N2JpcyB0aGUNCj4gPiByZWNvbW1lbmRlZCBSUEMgZ29pbmcg Zm9yd2FyZCBpcyA8ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbj4uICBJbiB0aGlzDQo+ID4gd2F5IGV2 ZXJ5dGhpbmcgc3RheXMgaW5kZXBlbmRlbnQuICBCdXQgYSBzZXJ2ZXIgY291bGQgY2hvc2UgdG8g c3VwcG9ydCBib3RoDQo+IDEuMA0KPiA+ICYgMS4xLiAgIFRoaXMgZ2l2ZXMgYmFja3dhcmRzIGNv bXBhdGliaWxpdHkgaW4gYSBzaW5nbGUgZGVwbG95bWVudC4NCj4gPiA+DQo+ID4gPiBbQ2hhaXIg aGF0IG9uXQ0KPiA+ID4NCj4gPiA+IEVjaG9pbmcgd2hhdCBNZWhtZXQgaGFzIGFscmVhZHkgc2Fp ZC4gVGhpcyBpcyBlc3NlbnRpYWxseSBhIFdHIGNhbGwuDQo+ID4gPiBJZiB5b3UNCj4gPiBsaWtl L2RvIG5vdCBsaWtlIHRoaXMgcHJvcG9zYWwsIG9yIGhhdmUgcXVlc3Rpb25zIGFib3V0IGl0LCB0 aGlzIHdvdWxkDQo+ID4gYmUgdGhlIHRpbWUgdG8gc3BlYWsgdXAuDQo+ID4gPg0KPiA+ID4gSSBh bSBhYnNvbHV0ZWx5IGdvb2QgdG8gZ28gd2l0aCB3aGF0ZXZlciB0aGUgV0cgZGVjaWRlcy4gICBJ IGRvIGJlbGlldmUNCj4gPiB0aGF0IG9ic29sZXRpbmcgNTI3NyBtYWtlcyBzcGVjaWZpY2F0aW9u IGFuZCBpbXBsZW1lbnRhdGlvbiBzaW1wbGVyLA0KPiA+IHdpdGggbm8gbWVhbmluZ2Z1bCBsb3Nz IG9mIGZ1bmN0aW9uYWxpdHkuDQo+ID4gPg0KPiA+ID4gRXJpYw0KPiA+ID4NCj4gPiA+IENoZWVy cy4NCj4gPiA+DQo+ID4gPiBPbiBEZWMgMiwgMjAxNiwgYXQgMTI6NDMgUE0sIE1laG1ldEVyc3Vl DQo+ID4gPG1lcnN1ZUBnbWFpbC5jb208bWFpbHRvOm1lcnN1ZUBnbWFpbC5jb20+PiB3cm90ZToN Cj4gPiA+DQo+ID4gPiBIaSBFcmljLCBBbGwsDQo+ID4gPg0KPiA+ID4geWVzLCB3ZSBuZWVkIGEg Y2hhcnRlciBjaGFuZ2Ugc2luY2UgdGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4NCj4gPiBl bmhhbmNpbmcgYW5kIHJlcGxhY2luZy4NCj4gPiA+IEFzIEkgcmVtZW1iZXIgdGhlIGNoYXJ0ZXIg ZGlzY3Vzc2lvbiBwZW9wbGUgd2VyZSBrZWVuIG9mIGhhdmluZw0KPiA+IGJhY2t3YXJkcyBjb21w YXRpYmlsaXR5IGJlY2F1c2Ugb2YgZGVwbG95ZWQgaW1wbGVtZW50YXRpb25zLg0KPiA+ID4NCj4g PiA+IEkgYmVsaWV2ZSB3ZSBuZWVkIHRvIHVuZGVyc3RhbmQgYmV0dGVyIHRoZSBpbXBsaWNhdGlv bnMgYW5kIHdoYXQNCj4gPiA+IGtpbmQgb2YNCj4gPiAicmVwbGFjaW5nIiB3ZSB3b3VsZCBzdHJp dmUgZm9yLg0KPiA+ID4gRG9lcyByZXBsYWNpbmcgbWVhbiBmdWxsIGRlcHJlY2F0aW9uIG9mIDUy Nzcgb3Igd2lsbCB0aGUNCj4gPiA+IGNvbXBhdGliaWxpdHkNCj4gPiBiZXR3ZWVuIGUuZy4gb2xk IGNsaWVudCBhbmQgbmV3IHNlcnZlciBiZSBwb3NzaWJsZT8NCj4gPiA+DQo+ID4gPiBJIGJlbGll dmUgd2UgbmVlZCBhIGRpc2N1c3Npb24gb24gdGhpcyBvbiB0aGUgbWFpbGxpc3QgYW5kIGdldCB0 aGUNCj4gPiA+IG9waW5pb24gb2YNCj4gPiBhbGwgcGFydGllcy4NCj4gPiA+IEF0IHRoZSBlbmQg dGhlIFdHIHdpbGwgZGVjaWRlLg0KPiA+ID4gQEFsbDoNCj4gPiA+IFBsZWFzZSBjb21tZW50IG9u IHJlcGxhY2luZyBpbnN0ZWFkIG9mIGVuaGFuY2luZyA1Mjc3Lg0KPiA+ID4gUGxlYXNlIGV4cGxh aW4gd2h5IHlvdSBhcmUgaW4gZmF2b3Igb2YgcmVwbGFjaW5nIG9yIGFnYWluc3QuDQo+ID4gPiBJ ZiB5b3UgYXJlIGluIGZhdm9yIHBsZWFzZSBleHBsYWluIHdoYXQga2luZCBvZiByZXBsYWNpbmcg KGkuZS4NCj4gPiA+IGNvbXBhdGliaWxpdHkNCj4gPiBsZXZlbCkgeW91IHdvdWxkIGxpa2UgdG8g aGF2ZS4NCj4gPiA+IElmIHlvdSBhcmUgaW4gZmF2b3Igb2Yga2VlcGluZyA1Mjc3IGFzIHN0YW5k YXJkIGFuZCBkZXZlbG9waW5nIGFuDQo+ID4gPiBhZGRpdGlvbmFsDQo+ID4gaW5kZXBlbmRlbnQg bm90aWZpY2F0aW9uIG1lY2hhbmlzbSBwbGVhc2UgbWFrZSBpdHMgY2FzZS4NCj4gPiA+IFRoYW5r cywNCj4gPiA+IE1laG1ldA0KPiA+ID4NCj4gPiA+IE9uIFRodSwgRGVjIDEsIDIwMTYgYXQgMjoy NyBBTSwgRXJpYyBWb2l0IChldm9pdCkNCj4gPiA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9p dEBjaXNjby5jb20+PiB3cm90ZToNCj4gPiA+IEhpIE1laG1ldCwNCj4gPiA+IEhpIE1haGVzaCwN Cj4gPiA+IEhpIEJlbm9pdCwNCj4gPiA+DQo+ID4gPiBJdGVtICM2IGluIHRoZSBORVRDT05GIGNo YXJ0ZXIgaXM6IOKAnEVuaGFuY2UgUkZDIDUyNzcgd2l0aCB0aGUNCj4gPiA+IGFiaWxpdHkgdG8N Cj4gPiBkZWxldGUgc3Vic2NyaXB0aW9ucyB3aXRob3V0IGNsb3NpbmcgdGhlIGNsaWVudCBzZXNz aW9uLCB0byBtb2RpZnkNCj4gPiBleGlzdGluZyBzdWJzY3JpcHRpb25zLCBhbmQgdG8gaGF2ZSBt dWx0aXBsZSBzdWJzY3JpcHRpb25zIG9uIGFuDQo+ID4gZXN0YWJsaXNoZWQgY2xpZW50IHNlc3Np b24uIFRoZXNlIGNoYW5nZXMgc2hvdWxkIG5vdCBhZmZlY3Qgb2xkZXINCj4gPiBjbGllbnRzIHRo YXQgZG8gbm90IHN1cHBvcnQgdGhlc2UgcGFydGljdWxhciBzdWJzY3JpcHRpb24NCj4gPiByZXF1 aXJlbWVudHMuIFRoZSBSUENzIGFuZCB0aGUgZGF0YSBtb2RlbHMgaW4gUkZDIDUyNzcgc2hvdWxk IGJlDQo+IGNvbnZlcnRlZCB0byBZQU5HLuKAnQ0KPiA+ID4NCj4gPiA+IFRob3NlIGF0dGVuZGlu ZyB0aGUgRXZlbnQgTm90aWZpY2F0aW9uIERlemlnbiBUZWFtIHRvZGF5IGJlbGlldmUNCj4gPiA+ IHRoYXQgaXQgaXMNCj4gPiBiZXR0ZXIgdG8gT2Jzb2xldGUgNTI3NyBpdCByYXRoZXIgdGhhbiBF bmhhbmNlIGl0LiAgIFRoZSBtYWluIHJlYXNvbnMgYXJlOg0KPiA+ID4NCj4gPiA+IOKAoiAgICAg ICBUaGUgZXhpc3RpbmcgNTI3NyA8Y3JlYXRlIHN1YnNjcmlwdGlvbj4gcnBjIGFuZCB0aGUgbmV3 IHJwY3MgbmVlZCB0bw0KPiA+IGJlIGluIGluZGVwZW5kZW50IG5hbWVzcGFjZXMuIE5vdCBzdXBw b3J0aW5nIDUyNzcgPGNyZWF0ZQ0KPiA+IHN1YnNjcmlwdGlvbj4gYW5kIGEgc2VwYXJhdGUgbmFt ZXNwYWNlIC8gbW9kZWwgd2lsbCBzaWduaWZpY2FudGx5DQo+ID4gc2ltcGxpZnkgdGhlIG5ldyBz cGVjaWZpY2F0aW9uLg0KPiA+ID4NCj4gPiA+IOKAoiAgICAgICBXZSBjYW7igJl0IHRoaW5rIG9m IGEgcmVhc29uIHdoeSBhbnkgWUFORyBtb2RlbCBkZXZlbG9wZWQgZm9yIGxlZ2FjeQ0KPiA+IDUy NzcgbmFtZXNwYWNlIHNob3VsZCBiZSBkZXZlbG9wZWQuICBOZXcgZGV2ZWxvcG1lbnQgaXMgbW9y ZSBsaWtlbHkgdG8NCj4gPiBmb2N1cyBvbiB0aGUgbmV3IG1vZGVsIGFuZCBpdHMgbmV3IGNhcGFi aWxpdGllcw0KPiA+ID4NCj4gPiA+IOKAoiAgICAgICBBbnkgY2xpZW50cyAmIHNlcnZlcnMgZGVz aXJpbmcgdG8gc3VwcG9ydCB0aGUgb2xkIGNhcGFiaWxpdGllcyBjYW4NCj4gPiBjZXJ0YWlubHkg ZG8gdGhpcy4gIEluZGVwZW5kZW50IGNhcGFiaWxpdHkgc2V0cyBjYW4gYmUgYWR2ZXJ0aXNlZC4N Cj4gPiBCYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBpcyBub3QgY29tcHJvbWlzZWQuDQo+ID4gPg0K PiA+ID4g4oCiICAgICAgIExlYXZpbmcgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgdG8gZW1iZWRk ZWQgc2VydmVyIGNvZGUNCj4gPiBzaWduaWZpY2FudGx5IHJlZHVjZXMgbmV3IGRldmVsb3BtZW50 IG5lZWRzLg0KPiA+ID4NCj4gPiA+IEFzIG9ic29sZXRpbmcgNTI3NyB3aXRoIHRoaXMgbmV3IHNw ZWMgaXMgYSBzaWduaWZpY2FudCBzdGVwLCB3ZQ0KPiA+ID4gd2FudGVkIHRvDQo+ID4gZ2V0IHlv dXIgYW5kIHRoZSBjb21tdW5pdHnigJlzIGZlZWRiYWNrIGFuZCBidXktaW4gYmVmb3JlIHdlIG1v ZGlmeSBhbnkNCj4gPiBvZiB0aGUgZG9jdW1lbnRzIGluIHRoaXMgZGlyZWN0aW9uLg0KPiA+ID4N Cj4gPiA+IFdvdWxkIHN1Y2ggYSBtb3ZlIG1lYW4gYSBjaGFydGVyIGNoYW5nZT8gICBNeSBzdXNw aWNpb24gaXMgbm8gYXMgd2UgYXJlDQo+ID4gZW5oYW5jaW5nIHRoZSBmdW5jdGlvbnMgc3VwcG9y dGVkIGJ5IDUyNzcgKGJ1dCB3aXRob3V0IGJyaW5naW5nIGFsb25nIHRoZQ0KPiA+IFJQQykuICBE byB5b3UgaGF2ZSBhbnkgZ3VpZGFuY2UgaGVyZT8gICBJcyB0aGlzIHdvcnRoIGhhdmluZyBhbiBp bnRlcmltDQo+ID4gbWVldGluZyB0byBkaXNjdXNzIGFuZCBmaW5hbGl6ZT8NCj4gPiA+DQo+ID4g PiBUaGFua3MsDQo+ID4gPiBFcmljDQo+ID4gPg0KPiA+ID4gUC5TLjogQWRkaXRpb25hbCBkaXNj dXNzaW9uIG9uIHRoaXMgaXMgY29udGFpbmVkIGluIG1pbnV0ZXMgMiB0bzE1DQo+ID4gPiBtaW51 dGVzIG9mDQo+ID4gdGhlIFdlYkV4IGF1ZGlvIHJlY29yZGluZyBiZWxvdy4NCj4gPiA+DQo+ID4g PiBGcm9tOiBFcmljIFZvaXQsIE5vdmVtYmVyIDMwLCAyMDE2IDU6NTggUE0gTWludXRlcyBwb3N0 ZWQgYXQ6DQo+ID4gPiBodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy95YW5nLXB1c2gvd2lr aS9NaW51dGVzLTIwMTYtMTEtMzANCj4gPiA+DQo+ID4gPiDigKIgICAgICAgIEFzIGFsd2F5cywg b3VyIERlemlnblRNIFRlYW0gaXMgYSBnYXRoZXJpbmcgb2YgaW5kaXZpZHVhbHMgcHJvdmlkaW5n DQo+ID4gaW5mb3JtYWwgaW5wdXQgdG8gTkVUQ09ORi4gV2UgYXNrIE5FVENPTkYgV0cgdG8gY29t bWVudCBvbiBvdXINCj4gPiBkaXNjdXNzaW9uIHJlc3VsdHMgYXMgYSBwcmVwYXJhdGlvbiBmb3Ig dGhlIFdHIGNvbnNlbnN1cy4gUGxlYXNlDQo+ID4gYXBwcm9hY2ggRXJpYyBWb2l0IGlmIHlvdSB3 YW50IHRvIGJlIGluY2x1ZGVkIGRpcmVjdGx5IGluIHRoZXNlIG1lZXRpbmdzLg0KPiA+ID4NCj4g PiA+IE1lZXRpbmcgTWF0ZXJpYWxzDQo+ID4gPg0KPiA+ID4gQXR0ZW5kaW5nDQo+ID4gPg0KPiA+ ID4gV2ViRXgNCj4gPiA+DQo+ID4gUmVjb3JkaW5nPGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Np c2Nvc2FsZXMvbHNyLnBocD9SQ0lEPTg3Y2RlMjQ1MjkzYw0KPiA+ID4gNDdkZDhjZmYzNzcyNzM5 ZjY2YzQ+DQo+ID4gPiBwYXNzd29yZDogYlhldmVGVjUNCj4gPiA+DQo+ID4gPiBBbmR5IEJpZXJt YW4sIEFsZXhhbmRlciBDbGVtbSwgQW1iaWthIFRyaXBhdGh5LCBFaW5hcg0KPiA+ID4gTmlsc2Vu LU55Z2FhcmQsIEVyaWMgVm9pdCwgVGltIEplbmtpbnMsIEJhbGF6cyBMZW5neWVsLCBTdXNhbiBI YXJlcw0KPiA+ID4gQW1iaWthIFRyaXBhdGh5LCBTaGFyb24gQ2hpc2hvbG0NCj4gPiA+DQo+ID4g PiBPYnNvbGV0ZSBSRkM1Mjc3IG9yIDUyNzdiaXM/DQo+ID4gPg0KPiA+ID4gICAqICAgSWYgeW91 IGFyZSBnb2luZyB0byBzdXBwb3J0IGJvdGggb2xkIGFuZCBuZXcgY2FwYWJpbGl0aWVzLCB5b3Ug d2lsbCBoYXZlDQo+ID4geW91ciBvbGQgNTI3NyBjb2RlLCBhbmQgeW91IHdpbGwgaGF2ZSB5b3Vy IG5ldyBjb2RlLiBXaHkgZGV2ZWxvcCBhDQo+ID4gYmFja3dhcmRzIGNvbXBhdGlibGUgcGFydCBv ZiB0aGUgc3BlYyB3aGljaCBubyBvbmUgd291bGQgb3Igc2hvdWxkDQo+ID4gaW1wbGVtZW50LiBQ ZW9wbGUgc2hvdWxkIGRldmVsb3AgdG8gdGhlIG5ldyBjYXBhYmlsaXR5Lg0KPiA+ID4NCj4gPiA+ ICAgICAgKiAgIDUyNzcgYWxyZWFkeSBoYXMgZW5vdWdoIGNoYW5nZXMgdG8gaXQgKGUuZy4sIGRh dGFwbGFuZSBoYXMgbW92ZWQgdG8NCj4gPiA2MjQxIGZpbHRlcmVkIG5vdGlmaWNhdGlvbnMpDQo+ ID4gPg0KPiA+ID4gICAqICAgUmVjb21tZW5kYXRpb24gZm9yIHBlb3BsZSBvbiB0b2RheSdzIGNh bGwgaXMgdG8gT2Jzb2xldGUgNTI3Nw0KPiA+ID4gICAqICAgTXVzdCBnbyB0byB0aGUgV0csIGl0 cyBjaGFpcnMsIGFuZCBCZW5vaXQgdG8gY29uZmlybSB0aGlzDQo+ID4gcmVjb21tZW5kYXRpb24g YmVmb3JlIHdlIGFkanVzdCBjdXJyZW50IGRvY3VtZW50YXRpb24NCj4gPiA+IENoYW5nZXMgdG8g dGhlIGRvY3VtZW50cyBkaXNjdXNzZWQgdG9kYXkgWzUyNzdiaXNdDQo+ID4gPg0KPiA+ID4gICAq ICAgU2NydWIgZm9yIGVycm9yIHR5cGVzIGluIHZhcmlvdXMgc3Vic2NyaXB0aW9uIHN0YXRlcy4g QXV0aG9yaXphdGlvbiBhbmQNCj4gPiBvdGhlciBlcnJvcnMgc2hvdWxkIGJlIHJlcG9ydGVkIHVz aW5nIHRoZSBwcm90b2NvbC1zcGVjaWZpYyBlcnJvcg0KPiA+IGNvZGVzOyBub3Qgc3BlY2lhbGl6 ZWQgZXJyb3JzIHBlciB0aGVzZSBuZXcgUlBDcy4gVGhleSBzdGlsbCBuZWVkIHRvDQo+ID4gYmUg aWRlbnRpZmllZCB0aG91Z2guIERpc3Rpbmd1aXNoIGVycm9yIHR5cGVzIGZyb20gc3Vic2NyaXB0 aW9uIHN0YXRlDQo+ID4gc28gdGhhdCB5b3Uga25vdyB0aGUgc3RhdGUgYSBwYXJ0aWN1bGFyIGVy cm9yIGhhcHBlbmVkIGR1cmluZy4NCj4gPiA+ICAgKiAgIEV4cG9zZSBvcGVyYXRpb25hbCBzdGF0 ZSBvZiBzdWJzY3JpcHRpb25zIGluIGEgc2VwYXJhdGUgWUFORyBtb2RlbCBvcg0KPiA+IGNvbnRh aW5lci4gKGkuZS4sIGFkZCDigJwtc3RhdGXigJ0gaW50byBuYW1pbmcgY29udmVudGlvbiBmb3Ig dGhlIHJvIHBhcnQpDQo+ID4gPiAgICogICBTaG91bGQgc3Vic2NyaXB0aW9uLWlkIGFuZCBmaWx0 ZXItaWQgYm90aCBiZSBpZD8gKGRvdWJsZS1jaGVjaywgYnV0IHdlDQo+ID4gY2FuIGRvIHRvIHRo ZSBzaG9ydGVyIGRlc2NyaXB0aW9uIOKAnGlkZW50aWZpZXLigJ0pDQo+ID4gPiAgICogICBEbyB3 ZSByZW5hbWUgcHVzaC1zb3VyY2UgdG8g4oCcb3JpZ2luYXRlcyBmcm9t4oCdIHRvIGJlIG1vcmUN Cj4gPiBleHBsaWNpdC9hY2N1cmF0ZT8gKGJldHRlciBuYW1lIGlzIG5lZWRlZC4gSW5jbHVkZSBp dCBpbiB0aGUNCj4gPiB0ZXJtaW5vbG9neQ0KPiA+IHNlY3Rpb24uKQ0KPiA+ID4gICAqICAgU2Vj dGlvbiAyLjMgaGFzIFNIT1VMRCBmb3IgNTI3NyBmaWx0ZXJzLiBOb3Qgc3VyZSB3aHkgdGhpcyBp c27igJl0IGENCj4gTVVTVC4NCj4gPiBBbHNvIHdlIG5lZWQgYSBiZXR0ZXIgbmFtZSBmb3IgNTI3 NyBmaWx0ZXJzLiBUaGlzIG5hbWUgZG9lc27igJl0IGV4cG9zZQ0KPiA+IHdoYXQgaXMgcG9zc2li bGUsIGFuZCB3aGF0IGlzIG5vdC4gRXNwZWNpYWxseSBpZiB3ZSBqZXR0aXNvbiA1Mjc3DQo+ID4g Y29tcGF0aWJpbGl0eSwgd2UgbmVlZCBhIGJldHRlciBuYW1lIGZvciA2MjQxLCBhbmQgd2UgbmVl ZCB0byBkZWZpbmUNCj4gPiB0aGUgYm91bmRhcmllcyBvZiBmaWx0ZXIgc29sdXRpb24uIEFuZHkg aGFzIGEgc3RyYXdtYW4gcHJvcG9zYWwuDQo+ID4gPiAgICogICBEZWxldGUgY3JlYXRlLXN1YnNj cmlwdGlvbiBSUEMgYW5kIGxlZ2FjeSBuYW1lc3BhY2Ugc2hvdWxkIFdHDQo+ID4gYWdyZWUuDQo+ ID4gPiAgICogICBEbyB3ZSBkbyBhIHRlc3Qtb25seSBvcGVyYXRpb24/IChMZXTigJlzIG5vdCBk byB0aGlzIHdvcmsgd2l0aG91dCBhbg0KPiA+IGFkdm9jYXRlKQ0KPiA+ID4gICAqICAgV2UgbmVl ZCBhIHdheSB0byB0ZXN0IGlmIHRoZSBmaWx0ZXJzIGFyZSBkb2luZyB3aGF0IHdlIGV4cGVjdCB0 aGV5IGFyZQ0KPiA+IGRvaW5nLiAoUGVyaGFwcyBjb3VudGVycy9jYXB0dXJlcyBvbiBhbiBhY3Rp dmUgc3Vic2NyaXB0aW9uPykNCj4gPiA+ICAgKiAgIEZvciBjb25maWd1cmVkIHN1YnNjcmlwdGlv bnMsIG1ha2UgcmVjZWl2ZXIga2V5IGlwIGFkZHJlc3MgYW5kIHBvcnQuIEF0DQo+ID4gdGhpcyBw b2ludCB3ZSBkb27igJl0IHdhbnQgVlJGDQo+ID4gPiAgICogICBDaGFuZ2Ugc291cmNlLXZyZiBk ZXNjcmlwdGlvbiB0byBpbmRpY2F0ZSB0aGF0IHdlIHNob3VsZCBhbGlnbiB3aXRoDQo+ID4gbmFt ZXMgZnJvbSBkcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVsLTAxIHNob3VsZCBpdCBjb21wbGV0ZSBp biB0aW1lLg0KPiA+ID4gICAqICAgc3RhcnQtdGltZSBpbiB0aGUgWUFORyBtb2RlbCBmcm9tIHN0 YXJ0VGltZSBhcyB3ZSBkb27igJl0IGhhdmUgdG8gd29ycnkNCj4gPiBhYm91dCBiYWNrd2FyZHMg Y29tcGF0aWJsZSBSUEMuDQo+ID4gPiAgICogICBNYWtlIHN0cmVhbSB0eXBlIHN0cmluZyByYXRo ZXIgdGhhbiBpZGVudGl0eSAocHJlZmVyZW5jZSBmb3IgaWRlbnRpdHksDQo+ID4gYnV0IG5vdCB3 aWxsaW5nIHRvIGZpZ2h0LiBOb3RlOiB0aGlzIGNvdWxkIGNoYW5nZSBiYXNlZCBvbiB3aGF0DQo+ ID4gaGFwcGVucyB3aXRoDQo+ID4gZmlsdGVycykNCj4gPiA+IFtZYW5nLXB1c2hdDQo+ID4gPg0K PiA+ID4gICAqICAgTmVlZCB0byBkZWZpbmUgZXJyb3IgdHlwZSBmb3IgZWFjaCBzdWJzY3JpcHRp b24gcGFyYW1ldGVyIHN1Y2ggYXMNCj4gPiDigJxlbmNvZGluZyBub3QgZGVmaW5lZOKAnSwg4oCc RmlsdGVyIHN5bnRheCBub3Qgc3VwcG9ydGVk4oCdIG9yIOKAnGZpbHRlcg0KPiA+IGNvbXBsZXhp dHkgbm90IHN1cHBvcnRhYmxlIGJ5IHBsYXRmb3Jt4oCdLg0KPiA+ID4gICAqICAgU2VjdGlvbiAz LjEg4oCTIERpc2N1c3Npb24gb24gdGhlIEVkaXRvcnMgbm90ZSAtIHRoZSBhZGRpdGlvbiBvZiBh DQo+ID4g4oCcY2hhbmdlcy1vbmx54oCdIGZsYWcgZm9yIGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9u LiAoU29tZSBzdXBwb3J0IGZvcg0KPiA+IHRoaXMsIGJ1dCBtb3JlIGRpc2N1c3Npb24gaXMgbmVl ZGVkIGFzIHRoZSB3b3JrIGlzIG5vbi10cml2aWFsLikNCj4gPiA+ICAgKiAgIFNlY3Rpb24gMy44 LjQg4oCTIHJlY29tbWVuZCByZW1vdmFsIChvaykNCj4gPiA+ICAgKiAgIFNlY3Rpb24gNC40OiBy ZWR1Y2UgdGhpcyBqdXN0IHRvIHRoZSBuZXcgcGFyYW1ldGVycyAoY2FuIHdlIHJlbW92ZQ0KPiA+ IHRoaXMgZW50aXJlbHkgY29uc2lkZXJpbmcgc2VjdGlvbiAzLjE/IE9yIGRvIHdlIG1lcmdlIDMu MSBpbnRvIGhlcmU/KQ0KPiA+IChFcmljIHRhbGsgdG8gQWxleCwgbGlrZWx5IG9rKQ0KPiA+ID4g ICAqICAgU2VjdGlvbiA0LjYuMiBJcyB0aGVyZSBhbnkgcmVhc29uIHdoeSB3ZSBjYW7igJl0IGhh dmUgdGhlIHRpbWVzdGFtcCBvbg0KPiA+IHRoZSB5YW5nIHB1c2ggaW5jbHVkZSB0aGUgbnVtYmVy IG9mIHNpZ25pZmljYW50IGRpZ2l0cyBhcyBleHByZXNzZWQgYnkNCj4gPiB0cmFpbGluZyB6ZXJv cyBpZiBuZWNlc3Nhcnkgb24gdGhlIOKAnHRpbWUtb2YtdXBkYXRl4oCdLiBUaGlzIHdvdWxkIGxl dA0KPiA+IHBsYXRmb3JtcyBleHByZXNzIHdoYXQgdGhleSBhcmUgY2FwYWJsZSBvZiBkb2luZy4g KE5vdGU6IHNlY29uZHMgd291bGQNCj4gPiBiZSBhIG1pbmltdW0gZ3JhbnVsYXJpdHkpLiAod2Ug c2hvdWxkIGdvIHdpdGggdGhpcyBpZiBwb3NzaWJsZS4gU3VzYW4NCj4gPiBILiBpcyBnb2luZyB0 byBjaGVjayBvbiBiaW5hcnkgcmVwcmVzZW50YXRpb25zIGhlcmUgdG8gc2VlIGlmIHZhcmlhYmxl DQo+ID4gZmllbGQgbGVuZ3RocyBtaWdodCBwb3NlIGEgcHJvYmxlbSBmb3IgYW4gdXBkYXRlLikN Cj4gPiA+ICAgKiAgIFNlY3Rpb24gNC42LjIgRG8gd2UgZG8gc29tZXRoaW5nIG9uIFlBTkctUHVz aCBzdGF0aXN0aWNzIChlLmcuDQo+ID4gY291bnRlcnMgb2Ygb2JqZWN0IGNoYW5nZXMsIG9mIHVw ZGF0ZSBtZXNzYWdlcyk/IChCb3Ro4oCmIFRlc3QgYW5kDQo+ID4gbm9ybWFsIG9wZXJhdGlvbnMg bmVlZCB0byBiZSBjb3ZlcmVkLi4gTWF0Y2ggdG8gZmlsdGVycyB3b3JraW5nDQo+ID4gb3BlcmF0 aW9uIHF1ZXN0aW9uKQ0KPiA+ID4gRGFtcGVuaW5nOg0KPiA+ID4NCj4gPiA+ICAgKiAgIERhbXBl biBjYW4gbWVhbiBsZXNzZW4uIFdlIHNob3VsZCBjaG9vc2UgRGFtcCBvciBEYW1wZW4gYmFzZWQN Cj4gPiBvbiB1c2FnZSB0aGVyZWZvcmUuDQo+ID4gPg0KPiA+ID4gICAgICAqICAgR29vZ2xlIHNl YXJjaCBmb3Ig4oCccm91dGUgZGFtcGluZ+KAnSA9IDQsODUwIGhpdHMuDQo+ID4gPiAgICAgICog ICBHb29nbGUgc2VhcmNoIGZvciDigJxyb3V0ZSBkYW1wZW5pbmfigJ0gPSAxMSw2MDAgaGl0cw0K PiA+ID4NCj4gPiA+ICAgKiAgIFRoZSBtb3JlIGNvbW1vbiB1c2FnZSBpcyBkYW1wZW5pbmcsIHNv IHdlIHNob3VsZCBzdGljayB3aXRoIHRoYXQuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBOZXRjb25mIG1h aWxpbmcgbGlzdA0KPiA+ID4gTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9y Zz4NCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K PiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gLS0NCj4gPiA+IENoZWVycywNCj4gPiA+IE1laG1l dA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gPiBOZXRjb25mQGlldGYub3JnPG1haWx0 bzpOZXRjb25mQGlldGYub3JnPg0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRjb25mDQo+ID4gPg0KPiA+ID4gTWFoZXNoIEpldGhhbmFuZGFuaQ0KPiA+ID4g bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0K PiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+ IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZg0KPiA+DQo+ID4NCj4gPiAtLQ0KPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4gUGhvbmU6ICs0 OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2Vy bWFueQ0KPiA+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFj b2JzLXVuaXZlcnNpdHkuZGUvPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IE5ldGNv bmZAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYNCg0K From nobody Mon Dec 5 01:18:41 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC8F129410; Mon, 5 Dec 2016 01:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 sXGrpyO9gpjB; Mon, 5 Dec 2016 01:18:35 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56457129849; Mon, 5 Dec 2016 01:18:34 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967] (unknown [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967]) by mail.nic.cz (Postfix) with ESMTPSA id C0A7B62434; Mon, 5 Dec 2016 10:18:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1480929512; bh=UHx8ukW22D7DEMtClWtZ/Qj40Ih+59BENQXFYY9g9t0=; h=From:Date:To; b=j1FzB5CTLviMyFKzrD19u2GQ3MOhOWouZwpVaL2LSktUKUL+ad4rVbZiCET21nKVS MQVoYOSCFCGCQmioUQs84jbq/SfhJP4PWGR6Nr2j5/MdRHpFijPzYnG0T4OLpoeN01 Mn9TKj7EiVNZo+iFSp/BvJTcoPW4wHi5NmsELhdY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 5 Dec 2016 10:18:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lou Berger X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Subject: Re: [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 09:18:37 -0000 > On 2 Dec 2016, at 22:26, Lou Berger wrote: >=20 > All, >=20 > This is start of a two week poll on making > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > document. This document is unusual in that WG last call will be = jointly > held in both the NetConf and NetMod WGs, while adoption and day-to-day = processing > will take place in NetMod. There seems to be no impact on YANG syntax or semantics - the one = mentioned in sec. 6.3 is in fact protocol stuff that doesn't belong to = the definition of YANG the language. Therefore, this work has nothing to = do with data modelling and in fact belongs to the NETCONF WG. This would = also solve the indicated WG schizophrenia that should IMO be avoided in = any case. A useful thing to do in the NETMOD WG would be to remove all = NETCONF-specific text from the YANG spec because whenever YANG is used = outside the NETCONF context (I2RS, CORE), that text is mostly ignored = anyway. Lada=20 >=20 > 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 December 16. >=20 > Thank you, > NetConf and NetMod WG Chairs >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 5 01:39:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D52F129855; Mon, 5 Dec 2016 01:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 oYUWC6g7qQFQ; Mon, 5 Dec 2016 01:39:01 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F643129410; Mon, 5 Dec 2016 01:39:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 42DCD74C; Mon, 5 Dec 2016 10:38:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9nlEIrjCTLiv; Mon, 5 Dec 2016 10:38:58 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 5 Dec 2016 10:38:58 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2B912005F; Mon, 5 Dec 2016 10:38:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mSUSC_FTWkWC; Mon, 5 Dec 2016 10:38:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2925B2005E; Mon, 5 Dec 2016 10:38:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1F26B3D9D805; Mon, 5 Dec 2016 10:38:58 +0100 (CET) Date: Mon, 5 Dec 2016 10:38:58 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161205093858.GA97253@elstar.local> Mail-Followup-To: Ladislav Lhotka , Lou Berger , NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 09:39:04 -0000 On Mon, Dec 05, 2016 at 10:18:32AM +0100, Ladislav Lhotka wrote: > > > On 2 Dec 2016, at 22:26, Lou Berger wrote: > > > > All, > > > > This is start of a two week poll on making > > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > > document. This document is unusual in that WG last call will be jointly > > held in both the NetConf and NetMod WGs, while adoption and day-to-day processing > > will take place in NetMod. > > There seems to be no impact on YANG syntax or semantics - the one mentioned in sec. 6.3 is in fact protocol stuff that doesn't belong to the definition of YANG the language. Therefore, this work has nothing to do with data modelling and in fact belongs to the NETCONF WG. This would also solve the indicated WG sch izophrenia that should IMO be avoided in any case. I disagree that the datastore model is a protocol specific aspect. I consider datastores an architectural component binding data models and protocols together. In fact, the 'traditional' datastore model together with the semantics of the operation caused us to write data models in a very specific way. Since the number of protocols transporting YANG defined data is growing, it is crucial that architectural aspects are more clearly spelled out as such. (And the only architectural document we have so far was done in NETMOD. But at the end, I find the discussion which WG is responsible somewhat pointless, it is the same set of active technical contributors anyway.) > A useful thing to do in the NETMOD WG would be to remove all > NETCONF-specific text from the YANG spec because whenever YANG is > used outside the NETCONF context (I2RS, CORE), that text is mostly > ignored anyway. If there is an opportunity to update all core documents together, we may clean up some of this; so far, we never had such an opportunity. /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 Dec 5 02:07:34 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C84129860 for ; Mon, 5 Dec 2016 02:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 b3nNF7a6GISs for ; Mon, 5 Dec 2016 02:07:30 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4C56612941A for ; Mon, 5 Dec 2016 02:07:30 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 9210F1AE0118; Mon, 5 Dec 2016 11:07:28 +0100 (CET) Date: Mon, 05 Dec 2016 11:07:28 +0100 (CET) Message-Id: <20161205.110728.1542519534982540528.mbj@tail-f.com> To: evoit@cisco.com From: Martin Bjorklund In-Reply-To: References: <20161129.124026.151848156249802222.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 10:07:32 -0000 "Eric Voit (evoit)" wrote: > Thanks Martin, > > More in line. Also I extracted areas where we already agree to make > this easier to follow. > > > From: Martin Bjorklund, November 29, 2016 6:40 AM > > > >If I understand the intention correctly, this document is supposed to > > > >*define* how notifications are sent over NETCONF. But there is no > > > >such definition in this document. Instead it simply repeats > > > >information already defined in draft-ietf-netconf-rfc5277bis-01.txt, > > > >and provides lots of examples of how the YANG operations defined in > > > >rfc5277bis are encoded in XML and sent over NETCONF. > > > > > > > >I suggest that this document is rewritten. Since the idea is to > > > >replace RFC 5277, it needs to focus on how notifications are sent > > > >over NETCONF, and not how RPCs are encoded in XML. > > > I agree -- maybe get rid of it and just have rfc5277bis contain this > > > text > > > > > > 5277bis is supposed to allow transports other than NETCONF. If > > > we put > > the NETCONF specific stuff in here we lose that separation. > > > > We need *some* document that defines how notifications are sent over > > NETCONF. This document needs to have the specification for the > > > > element. > > > > Then we need a protocol-independent document that defines the concept > > of > > streams and subscriptions, stream discovery, etc. > > > > I *think* that your intention is that new clients really should be > > using > > instead of , since it is > > protocol- > > independent and support modification and deletion. > > > > If we also want to be fully backwards compatible with 5277, I think we > > should > > create a document that is much closer to the current 5277 - > > essentially just > > creating a YANG model for the config false data and for the "old" > > > subscription>. > > We absolutely want to have a full backwards compatible capability. > The question is how to best frame this in documents. It is possible > to rebuild RFC-5277 with a YANG model. But then you can't just layer > on new capabilities driving this work. I think this in fact can be done. I'll get back to this in a separate email. > (And this is why we need > separate namespaces.) I also don't think separate namespaces are necessary. [...] > > > > You have made the stream name an identity. In RFC 5277 it was a > > > > string. By using an identity, you severly limit how it can be used; > > > > with a string new streams can be dynamically created at run-time, > > > > but with an identity stream names must be known at design-time. > > > > I think the stream name should be changed back to a string. > > > > > > as the majority of the people in the informal design team were > > > against > > the expansion of streams, this is likely a moot point. > > > > I don't know what "expansion of streams" means, and I don't understand > > what > > "this" refers to in "this is likely a moot point". > > > > But if we keep the stream name as an identity we're no longer > > backwards > > compatible with RFC 5277, and we severly limit the functionality. I > > strongly > > object to such a change. > > I am fine with string, especially as: > (a) we are moving away from strings in favor of filters I do not understand what this mean. The string I am talking about is the stream name. I don't think a filter can replace that? > (b) custom streams are likely to be the dominant use. > Anyone have an objection to this change? > > > > >o Section 4.1 > > > > > > > > The text says: > > > > > > > > If the > > > > request is rejected because the publisher is not able to serve it, > > > > the publisher SHOULD include in the returned error what subscription > > > > parameters would have been accepted for the request when it was > > > > processed. > > > > > > > > I think this is a pretty weird idea. It seems extremely difficult > > > > to implement, and the use case is not clear at all. In an > > > > automation deployment, do we expect that the client application code > > > > contains logic to rewrite itself to send proper requests the next > > > > time? If it is for debugging purposes I think this should be up to > > > > implementations to figure out. We shouldn't add such things to > > > > standard RPCs. > > > > > > there has been lots of discussion on this one. The biggest issue > > > has been > > that there are enough variations of parameters where the guidance on > > what > > might be acceptable is the only way to make some scenarios work. (Was > > it the > > period which was a problem? Was it the complexity of the filter?) > > Obviously > > we do need to bound what could be provided back to the subscriber. > > > > So then the text should encourage implementations to provide good > > error > > messages. > > yes > > > > The good news is that if a publisher cannot support negotiation, it > > > can just > > send back a failure. Which is why the requirement is only a SHOULD. > > > > SHOULD is too strong. And even so, this just adds complexity to the > > specification. I think this should be removed. > > RFC7923 has it as a MUST (see section 4.2.2.) Going to SHOULD is > already easing off the requirement. Well, in the Informational RFC 7923, section 4.2.2 I find a SHOULD, not a MUST: In cases where a subscription request cannot be fulfilled due to insufficient platform resources, the Subscription Service SHOULD include within its decline hints on criteria that would have been acceptable when the subscription request was made. But this doesn't change my original concern - it adds complexity to the spec, server implementations, and client implementations. I can't see how this would be implemented and utilized in real-world code. /martin From nobody Mon Dec 5 02:10:47 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDF212986C for ; Mon, 5 Dec 2016 02:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 GgbqIEEDFn2Z for ; Mon, 5 Dec 2016 02:10:42 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0119.outbound.protection.outlook.com [104.47.1.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 92FE7129866 for ; Mon, 5 Dec 2016 02:10:41 -0800 (PST) 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=wh9Q/VVswc+YbxJQsfj/3rMjP2CnIWXlZ6JcdX7Dhg8=; b=FPaHhvDQclefX5yd7ODkZZbHzm74RGv87dGnufnfLRKba/tGJ/ApTscC2AbI4R7J1hMQSZnjBqkhcpaoElUwXqx58opXZzNlJEXg2IdmDLqNgD5kV8uzKVL6bIke52esixUNhAfkK0pI4ONL+hW+abVpbHHfuX+owLMVwgp+nq8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by AM5PR0701MB2995.eurprd07.prod.outlook.com (10.168.156.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Mon, 5 Dec 2016 10:10:36 +0000 Message-ID: <01cb01d24edf$52b91320$4001a8c0@gateway.2wire.net> From: t.petch To: Jonathan Hansford , 'Juergen Schoenwaelder' , "'Eric Voit (evoit)'" References: <9573F76E-A55D-40AA-8FB2-53E207EA1FCF@gmail.com> <20161203085006.GA91185@elstar.local> <001801d24d4e$85a58210$90f08630$@hansfords.net> Date: Mon, 5 Dec 2016 10:06:54 +0000 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: [81.135.210.62] X-ClientProxiedBy: AM4PR0101CA0012.eurprd01.prod.exchangelabs.com (10.167.254.22) To AM5PR0701MB2995.eurprd07.prod.outlook.com (10.168.156.145) X-MS-Office365-Filtering-Correlation-Id: b84c66f4-7173-4542-0dc1-08d41cf6f590 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 3:Frh5sHxBDVcLYWPkOgesbQt3+0o5qq6/8d2NRfyL8WH3Rzz5U4OSoBy0w39VJi8wi7d0adKBQhl/scLq6j52o0nyMW3q1Cpw8MRhYKxa/Br32JKRyzUevIT87Sdtcwnecx6gmKHs2JOqBeoAHeWxma5QPLrfkW3VAYLNuEMzns66a8zth08LNwI479bwZ5EkoU+ZJCFBpM4jZZ/PFDDde2k8KTtWHUrBxSYCJG3D65c6kpYXf3LgTCruYsOE2OeaUNWXXZUSSna9/yboAugvmA== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 25:/L8+hW+FSRRVp7V1EpDPyYVdZUBh+YAUPmXwBKMLzZpnjl9BrsRCGpi6UhIhhNsC0y0p6tHSG1WSjvuPDfxpNGoKCvtVRWBfb5A891bKB3XYnns7nSo5Ke0s2SWgCoY9yJVnnB/tRlIBNsCnCz28As3FFNh+r7k7qddZOpGTCfh5cR4wKdKFs94KMjMMfU5i6FGdsdDH2pUQpFJ7OdcmzWJh00ylEKsV1TCf6lcyn5relimhOGU5AO5RPKs2IzufTq5nLupHNdh5ykDk8ED3REB8sMMnS/NYwTxuwtr06RdsXYn7Za/puiHLD2fD0GNeJ/Nr4QYH7CG2iGL3nr9d4WYckdZM431ZeFx50o7ijWi2xK/L8aY0lh6DSB8LWAq0oJ5Hd3mzTPo2cqUb2MyfEDCBxaMsaw0pDkXcqwGYGK3/zO/ALy/mweEq4q6kEZ4lVLl8KpyGTftgZMpKTPn8slyHl+EeGFAcgSFY5ZzX/sHp7S/rw55U9MrCFOo5d1eGi31tiJLEa69MTAu60mOx67VRSBxaxUbep8AJPdjgZ2xNs2iIRoDND4eU5p9nX28/r4XJGHIMT44WMTGBzkQtb6hquSGIFzxtCAe5lAYjexcF3eD7nKsQdmDQVO6mTgdGQJDWkwnKS4DsQD4wm1FpsnlknFLl+VwtdreMKhaQYR72xpiD14SYlXICgA8kWeCZvIUPLoLtI+dq6QfXijM4g++UCC+AoMm8BHf9J1cyaKiS0Q2t30uvDRIN1bCLZPYbVpA1A58amEjQbNjJRfBXXQmB5qXv9KMcn7WcB6aCcUWssl5xYi0xW7B5qbTT1pHtDUGqId7VhbX0VReo5iI5vHplvmifizyyxxDkhLNmXkpTIYIC1fB4iWQ9UJJ7vejzi6PXTFKKgL3YGNSQSdQCoA== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 31:Z/OsHX4qhw6Ni+Dk1Uulrd4rOBbwtDSwyttPmv7BXJQ1hUQysqq/kuRKKWC38iSerNigxUKFsPNnTZy4Hdd46cG/H9omlP6vkZA+PK+BoMakpeMawSlfyQ0YSOFWIqXST+f6znEXIDnmuRaPZSLC1UtexZ2ho+cPXVYqDKDPK+Dqgx9fTD+dLrufjLxp+AsSMLZriCaR8V7ph4mqu0V0R+1bKvb9ZtsiBaN+IFoguhUdmN1y12tphNxAXNxjQVIgUJuckMTruI48iOIH5V55GOJ041/YsqbHl2NM1BIEqcQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(166708455590820)(94707916325470)(95692535739014)(198313997877955); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:AM5PR0701MB2995; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 4:2opnK1v8dL/XI2Y6ilNkRbHuJG7KtmT/aE1BrDQr3Fy8U+qeyG8wAjo5YyjfgZrRUf1Xt6vYjxmXVFExj1HWCVZyrrMbPPbKVWTd/FEfCt/GTWuxHl7URM6xR4Id12+hjSqpAsmDV3Wwk8+RW+0fEDscSEQ7K12hPuzCFnkdfSUhWGbw3OXncp5I7R5yewsfZKifBTYT9kok7PdJKSTPIlLoszF4IYXOlWJsE88aHjDHw8p+WMykOFmkOZ/bRgCEZXNzu5JWjE9Bf/HfGigLroV6HrwGVIxq4l7ujECGqJsjhCqZHsG0HXDLze/bHS/ovsbMUP9eraI5FWna9FKUTAQwqF+czPMwJagjodiTsyZch0KA77M95nuBurlZko6BTFUyONuuMRtLHDimQd8MCXrMRRmU3hDWSh9aiCQdV/8QlhSa4zY5rs/lrgOfc631l2vtaXyCm7joLHGNRSc75pGyQYRD+1xMIctgN0g2R89gHKhXmph+5RtO2lD7WPF9dMwW1atmTPCk9g9GI4f4Vxa3tWqz832IXvds0MTPBuOQNfRcoLoo4Yh7LzqXfuFdvBBVtFWnQDcthxJG949km1AWXfi6maFT2V0LDAygvGHmfdboWMoteaNktw8xyAErfb3HUhtyhA1JT0y5/k+CmGxDTQ6dNut7SlCAwz2Nu/tl/3cVIraBl9tBZ0N0fy73QEFO0gOtcmjUwSkYJOGUyiyW5BoNymSoOT4ngl0ve534TUN48ZQffvj/cMlATw53 X-Forefront-PRVS: 0147E151B5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(199003)(189002)(377454003)(13464003)(15650500001)(86362001)(7736002)(5001770100001)(61296003)(105586002)(42186005)(97736004)(44736005)(9686002)(6486002)(6496003)(39410400001)(39450400002)(733004)(305945005)(6666003)(4720700003)(39840400001)(93886004)(1456003)(39860400001)(1556002)(7846002)(50226002)(33646002)(92566002)(81686999)(551544002)(5660300001)(7110500001)(81816999)(76176999)(101416001)(50986999)(561944003)(3846002)(6116002)(116806002)(23676002)(14496001)(2420400007)(16799955002)(68736007)(4001150100001)(66066001)(2906002)(39850400001)(44716002)(50466002)(106356001)(189998001)(8676002)(4326007)(81166006)(81156014)(47776003)(2870700001)(62236002)(38730400001)(84392002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2995; 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?MTtBTTVQUjA3MDFNQjI5OTU7MjM6M3kvQ2ExWDhka1F1Zk1yTzRpMXlaOWU4?= =?utf-8?B?OEdZSTVoaWZJTC9SVktHWVpUWFowQ0dSVWkzeWt6NndhR20vQjNFZjllekJT?= =?utf-8?B?YnVpSTR2YjBSTWlkOGZpN3d3QXBjQ285UEVCNzllUVc5ZkxiKzVWbmlaQmZp?= =?utf-8?B?QzBrcEk4ZzRVblNnSEFrZDlPaGtyeTlMcHhBZXZkRlY5NURHbkpzVmVydi9o?= =?utf-8?B?TnlNMGxMWTVSYXZNZys1MWU5OFh4RVFUUXpTM1BLUnZodHZZR2QyWVhXbCsv?= =?utf-8?B?WXdPVG1qR1dEek43VHlNc1NQMDBOSDVaamJFdjNBN0xiR0tlT0o0K1hDSzRW?= =?utf-8?B?dE9pUy9BYWRLNk5OVGduZkYwMjNTTUQ5WEYxNnhHSTBGeUhqR2d6UXI4M29x?= =?utf-8?B?SEVHdzZYQ1VzZ1VtZFNOdlYyeW9UbGpuVWIvY0MzeHFzQTcySGp2cFFmUVRQ?= =?utf-8?B?R1duSGo4VFlPZ3BjWHZOdjRuUVEvRmRQVG0wTndNQnBGdUo2Vm44aml4alBB?= =?utf-8?B?UHlvZms5b09sMDdxQmFwczFQdjc0RVh5RFZJM1VjWHJSQjd2T3FKMjB0R3dj?= =?utf-8?B?L2dlRzh0SjBkQ0xBd0dEVVZhNkVNNSs2SGNUSjVhWGJJS1REblN3SWFocWVU?= =?utf-8?B?OWxoaWZnNENaUm02bVNEb1pLMi80eE11am4yalJFL2lMY2pvWXk0NTBwRXNs?= =?utf-8?B?Yit0Ujc4c0V6NDA0ckZ3dktBNis4V1BHRllTemFENWFHazFFa2tsU2Rob0U1?= =?utf-8?B?RVRudWp5bkYxRmJid1ZoR1B0U1grT2tpOFRhemJOajlmTE0yTlFQc3hvdy9H?= =?utf-8?B?aGcyL1ZFWWdhazUyV2diK3FKSW1WZm9tZWZ4T2FSaUx1M2J5MGhKbURNYUts?= =?utf-8?B?QVhwejBHVUdNVUhZUEpoL0o2TG5yaGxOYk1vN2VHMmxWcW5iaUwrZS80STlL?= =?utf-8?B?M0JvVzRhY2tiZk8rWmRWQ0s0aCt2amE0UlkxNVJVblZlSmRoUERVZDdJQmdL?= =?utf-8?B?R0ZzL0htenVCL0VLVEtqVjQxemVjcjkxQnpyc0ZuWUlSSXFObUQ4eDdPNGFI?= =?utf-8?B?cXZlR0czRDlVemt0WmhuZVBsWDNFUEQwUGVCb1FoODlCN2ZXWUdQZ1pLYU1X?= =?utf-8?B?RmxDUDllVWlldU8vQ1RncmlJTVFKQk90cFZYVWVkL3lCTXdKMGV4NmlzeTJT?= =?utf-8?B?Sjh4dGpkOUs0OEJQVCsxRkozdHJFeEJLczhuemRBZllFYWViVS9CSDNnMkVl?= =?utf-8?B?ejJHVHF6bHo0K2cvU2doMk82TFgvQzVaVTBHdEV6OFEyV0NSKzA1M2kvV2Vl?= =?utf-8?B?bjJ6YmFtWVlwcEJ4d0ZiblF6aGJ3d3VBSUZBUXN4SDd2OFVJSUVWQVRnSm05?= =?utf-8?B?ZzVoRDc4V3RYTEFhOHd3WnMwUHJwUnhSRWhFVlRxam1CTDNpd3BzMkZVTlN3?= =?utf-8?B?b2NDK2J2MjhhN1B3OFNKQmtaNVdGOWRvTE5sQUpxNzBwNTc0RSs1bXhkRFV3?= =?utf-8?B?dUlYMERoVDhSYW1GUTJLbFc0cWFCUDRxMDNUOVFaVUlPZWdVNkMrWk10anBF?= =?utf-8?B?K3RoaFdldlVqWjVaQUxFbmR5bmphdyt0R0RmZXFxeFZEVThIRGlqaGJ5em96?= =?utf-8?B?RjVmVDgwNzBpaVhjZ09XZVRxSmV2N0RvZXFtVUNkWkFlZnl4cmtpS0FhTm9M?= =?utf-8?B?ZWdMbzdTQmxNbWFSSy9VeFNqTmgzT2xuWEdZUjlqZ3ZZZlhGQVdwU1YzQ2tM?= =?utf-8?B?dmcrL1ZpM2pYbk5jT21zRHEvazI0cXZ2dlN1L1U0WVJvYWV2YzA3Smc1d0Qz?= =?utf-8?B?ekt4d0ZIM25qZjRrUmsvSzhudjBZMEVXS2NRWGdWMGlRdk5oTkZkR2hBRE44?= =?utf-8?B?d1pFNkVJZ1BRYWMxMkp2bndIWEhtVGpTWU5Ya1ZBZ1BrWVJVZzkwRjBXZ1ZO?= =?utf-8?B?c0lKd0tjampQMXhYdERzMVplUWFlY21XRS8xSTVOaEdYOFRCMFB0OU16R1Na?= =?utf-8?B?TU9wcmwrcGxoSkV2cGxQVmdDQTVUQ3pJSTh0NzliTXJtR3R5R0tKRGlwMDVP?= =?utf-8?B?U3Y2K09yb3ZJcTZCN1FJOVRDTU82OWRiTWN0Skd6ZE1ETUV4cHR5RkRpNXhT?= =?utf-8?B?WWRCZm5Lb1UzVVRGMUF4REZMVkdITXJ5Nng5ZmlISUhQdlhvZzdOZkduVWdI?= =?utf-8?B?L1FIY0xwWWJZeGcranpmbWhTTDJHNlhrdGRORks1NXVxZjVFdUY4bWhLS2JM?= =?utf-8?B?K1kvaFQwRGw1dnB0Umt2UkFZdXJWRHQyMXMvRGwydHQ3V2FqcXRmaEFmaGQ2?= =?utf-8?Q?3ZHtLv4aTXY8MuHMVo=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 6:SqI8XWs40GTlynf9aBO6I1eK6WfHf+uXSDwLHp0V+lwXQZwhH3ra75CbfKIoaHYbzuloZ18XKI05iRqEmpCwIylKiJKRwcXePERkZJRfDGADwmo4TIzRHaijIcpxAG9j+Vab6Eu0x53QKXvZZkTNnTvDcVUIHJ2RT7Ltc482nF8gWpTox3t2cy0pl+O7NjMOPTgueOYSfUY7Li/sR8FQyMp2S8aRbVUoRFluqhXMesmpKq26j3EdbLa+37YE1nf1R3pSk2QuBRIOL8YLlBnrmiuNklWql2JE0h7mFTwjpSHiMg5z1rBlwDAUiCY0QK5DfirF1HczYjwLTRHnNUOsWJ0ajrWpu2P3V1CND1YLjaKodL/DmJPGR+JFDRCtg32G71vIlEdSnx+73FpR0Zl7dEziUHmVk6+VuUU9uxiaD2E=; 5:u7UntDT1SfOiRV3F+tVNpKg84G6yJx2XODbKBAzNrLzWE6rEA91I/tOGEJWbXtyxWxJZc7BLpwrEnQaUoeiHs01xJSJ0R6ld3M96XEX29ZFOwodmHj5H2qRUlbVFuY46hU+wXYbpPkL/V0qyvMBbAXyoR6LsFwzXqOxwbJ9Mvys=; 24:yqGs9xcB7cgXQK3fRwtN9v453H+732Ssd5IVMBa568s2wbxBHNJAb7wHHGUgEnIrukbnDNhYvx5GEDqC6roxjWBkg4TgLCJqIr8GqyET4BU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 7:5jXWWkJDqQEiwIlKnCfIrIura61S/zvjealZpA//tKkEeaWUGUasw2kPDkCoQIZgxqR6fSSnUZv8xPzFtBtlY2nU0gwQY8+YHmT8QKSEIwKBJPQrKwWpslpLOd/vMmxzgezS7uhJdmsS9dyLUBv1b28hiqEne4JUna00pk9UefjVW2S9ipEsG6ywSizgU34vsDqjyqzJSfwEUin/5nMBl7i7Jg80/cB1H6zxwN4uAn3gWSrzjLWJWbXCJU655SToJvb2jxNuO6bHxo1547+jKIsJQyr7rtIlT681e9ATZTNyiz7TY17dw3S1r5A13+YVFbHicEyM+iZKhVkww9x1v4MuMRYRMvGYN4h46hoj0IeayI2y0SRkBOBI+J7hyAupjweUkynCpGJr5/bf2XhheKc9Gnw3G0MHM5gHLzZ87uZLq40KrIHEVvP0dAwPR06ZmubY8XGf8JyQhXai64ybAA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2016 10:10:36.9340 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2995 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] proper quotations was Re: 5277 Backwards Compatibility: how to deliver X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 10:10:45 -0000 ----- Original Message ----- From: "Jonathan Hansford" To: "'Juergen Schoenwaelder'" ; "'Eric Voit (evoit)'" Cc: Sent: Saturday, December 03, 2016 10:17 AM > Are you proposing a specific style of quoting, or are any of those listed acceptable? The Wikipedia page doesn't identify what "proper quotations" are. For me, proper quotations are anything that I can readily see via my MUA which enables me to distinguish what the sender of the e-mail has written, as opposed to what was already there when the sender received the e-mail to which they are responding. In Eric's response to Mahesh, there is nothing, zilch, zero as in "Yes. Anyone who wants to use existing 5277 would just leverage to the old namespace. If the namespaces are truly different, and the server already supports 5277, what would be the implication of having two , in two different namespaces? There would be no in 1.1. With 5277bis the recommended RPC going forward is . " The original text and the new text are separated by a blank line as are, when appropriate, the paragraphs of the original text and inserted text making it hard work, sometimes impossible, to tell who is saying what. The commonest (and so best) way is the use of one or more of > > > on every line although once per paragraph is usable. Other characters will do as long as they display - I get an increasing level of open boxes these days, especially in the minutes of WGs, which are a fancy Unicode variant of a quote, double quote, dash, period and such like. Anything that starts as Microsoft Word is likely to be unintelligible. Tom Petch > Jonathan > > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: 03 December 2016 08:50 > > To: Eric Voit (evoit) > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver > > > > Hi, > > > > I can't follow discussions if people use email clients that do not do proper > > quotations. https://en.wikipedia.org/wiki/Posting_style > > > > /js > > > > On Fri, Dec 02, 2016 at 11:49:11PM +0000, Eric Voit (evoit) wrote: > > > From: Mahesh Jethanandani, December 2, 2016 6:20 PM > > > > > > [Chair hat off] > > > > > > Eric, > > > > > > What would help is to understand what the backward compatibility section > > would look like with your proposal. Currently it says that 5277bis will > > advertise "urn:ietf:params:netconf:capability:notification:1.0†and > > "urn:ietf:params:netconf:capability:notification:1.1â€. Clients can then choose > > which capability they are capable of and want to support. With the new > > proposal, are we dropping advertisement of > > "urn:ietf:params:netconf:capability:notification:1.0â€? > > > > > > Yes. Anyone who wants to use existing 5277 would just leverage to the old > > namespace. > > > > > > If the namespaces are truly different, and the server already supports > > 5277, what would be the implication of having two , in > > two different namespaces? > > > > > > There would be no in 1.1. With 5277bis the > > recommended RPC going forward is . In this way > > everything stays independent. But a server could chose to support both 1.0 > > & 1.1. This gives backwards compatibility in a single deployment. > > > > > > [Chair hat on] > > > > > > Echoing what Mehmet has already said. This is essentially a WG call. If you > > like/do not like this proposal, or have questions about it, this would be the > > time to speak up. > > > > > > I am absolutely good to go with whatever the WG decides. I do believe > > that obsoleting 5277 makes specification and implementation simpler, with > > no meaningful loss of functionality. > > > > > > Eric > > > > > > Cheers. > > > > > > On Dec 2, 2016, at 12:43 PM, MehmetErsue > > > wrote: > > > > > > Hi Eric, All, > > > > > > yes, we need a charter change since there is a difference between > > enhancing and replacing. > > > As I remember the charter discussion people were keen of having > > backwards compatibility because of deployed implementations. > > > > > > I believe we need to understand better the implications and what kind of > > "replacing" we would strive for. > > > Does replacing mean full deprecation of 5277 or will the compatibility > > between e.g. old client and new server be possible? > > > > > > I believe we need a discussion on this on the maillist and get the opinion of > > all parties. > > > At the end the WG will decide. > > > @All: > > > Please comment on replacing instead of enhancing 5277. > > > Please explain why you are in favor of replacing or against. > > > If you are in favor please explain what kind of replacing (i.e. compatibility > > level) you would like to have. > > > If you are in favor of keeping 5277 as standard and developing an additional > > independent notification mechanism please make its case. > > > Thanks, > > > Mehmet > > > > > > On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit) > > > wrote: > > > Hi Mehmet, > > > Hi Mahesh, > > > Hi Benoit, > > > > > > Item #6 in the NETCONF charter is: “Enhance RFC 5277 with the ability to > > delete subscriptions without closing the client session, to modify existing > > subscriptions, and to have multiple subscriptions on an established client > > session. These changes should not affect older clients that do not support > > these particular subscription requirements. The RPCs and the data models in > > RFC 5277 should be converted to YANG.†> > > > > > Those attending the Event Notification Dezign Team today believe that it is > > better to Obsolete 5277 it rather than Enhance it. The main reasons are: > > > > > > • The existing 5277 rpc and the new rpcs need to > > be in independent namespaces. Not supporting 5277 > > and a separate namespace / model will significantly simplify the new > > specification. > > > > > > • We can’t think of a reason why any YANG model developed for legacy > > 5277 namespace should be developed. New development is more likely to > > focus on the new model and its new capabilities > > > > > > • Any clients & servers desiring to support the old capabilities can > > certainly do this. Independent capability sets can be advertised. Backwards > > compatibility is not compromised. > > > > > > • Leaving backwards compatibility to embedded server code > > significantly reduces new development needs. > > > > > > As obsoleting 5277 with this new spec is a significant step, we wanted to > > get your and the community’s feedback and buy-in before we modify any of > > the documents in this direction. > > > > > > Would such a move mean a charter change? My suspicion is no as we are > > enhancing the functions supported by 5277 (but without bringing along the > > RPC). Do you have any guidance here? Is this worth having an interim > > meeting to discuss and finalize? > > > > > > Thanks, > > > Eric > > > > > > P.S.: Additional discussion on this is contained in minutes 2 to15 minutes of > > the WebEx audio recording below. > > > > > > From: Eric Voit, November 30, 2016 5:58 PM Minutes posted at: > > > https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-11-30 > > > > > > • As always, our DezignTM Team is a gathering of individuals providing > > informal input to NETCONF. We ask NETCONF WG to comment on our > > discussion results as a preparation for the WG consensus. Please approach > > Eric Voit if you want to be included directly in these meetings. > > > > > > Meeting Materials > > > > > > Attending > > > > > > WebEx > > > > > Recording > > 47dd8cff3772739f66c4> > > > password: bXeveFV5 > > > > > > Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, > > > Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika Tripathy, > > > Sharon Chisholm > > > > > > Obsolete RFC5277 or 5277bis? > > > > > > * If you are going to support both old and new capabilities, you will have > > your old 5277 code, and you will have your new code. Why develop a > > backwards compatible part of the spec which no one would or should > > implement. People should develop to the new capability. > > > > > > * 5277 already has enough changes to it (e.g., dataplane has moved to > > 6241 filtered notifications) > > > > > > * Recommendation for people on today's call is to Obsolete 5277 > > > * Must go to the WG, its chairs, and Benoit to confirm this > > recommendation before we adjust current documentation > > > Changes to the documents discussed today [5277bis] > > > > > > * Scrub for error types in various subscription states. Authorization and > > other errors should be reported using the protocol-specific error codes; not > > specialized errors per these new RPCs. They still need to be identified > > though. Distinguish error types from subscription state so that you know the > > state a particular error happened during. > > > * Expose operational state of subscriptions in a separate YANG model or > > container. (i.e., add “-state†into naming convention for the ro part) > > > * Should subscription-id and filter-id both be id? (double-check, but we > > can do to the shorter description “identifierâ€) > > > * Do we rename push-source to “originates from†to be more > > explicit/accurate? (better name is needed. Include it in the terminology > > section.) > > > * Section 2.3 has SHOULD for 5277 filters. Not sure why this isn’t a MUST. > > Also we need a better name for 5277 filters. This name doesn’t expose what > > is possible, and what is not. Especially if we jettison 5277 compatibility, we > > need a better name for 6241, and we need to define the boundaries of filter > > solution. Andy has a strawman proposal. > > > * Delete create-subscription RPC and legacy namespace should WG > > agree. > > > * Do we do a test-only operation? (Let’s not do this work without an > > advocate) > > > * We need a way to test if the filters are doing what we expect they are > > doing. (Perhaps counters/captures on an active subscription?) > > > * For configured subscriptions, make receiver key ip address and port. At > > this point we don’t want VRF > > > * Change source-vrf description to indicate that we should align with > > names from draft-ietf-rtgwg-ni-model-01 should it complete in time. > > > * start-time in the YANG model from startTime as we don’t have to worry > > about backwards compatible RPC. > > > * Make stream type string rather than identity (preference for identity, > > but not willing to fight. Note: this could change based on what happens with > > filters) > > > [Yang-push] > > > > > > * Need to define error type for each subscription parameter such as > > “encoding not definedâ€, “Filter syntax not supported†or “filter complexity > > not supportable by platformâ€. > > > * Section 3.1 – Discussion on the Editors note - the addition of a > > “changes-only†flag for a periodic subscription. (Some support for this, but > > more discussion is needed as the work is non-trivial.) > > > * Section 3.8.4 – recommend removal (ok) > > > * Section 4.4: reduce this just to the new parameters (can we remove > > this entirely considering section 3.1? Or do we merge 3.1 into here?) (Eric talk > > to Alex, likely ok) > > > * Section 4.6.2 Is there any reason why we can’t have the timestamp on > > the yang push include the number of significant digits as expressed by trailing > > zeros if necessary on the “time-of-updateâ€. This would let platforms express > > what they are capable of doing. (Note: seconds would be a minimum > > granularity). (we should go with this if possible. Susan H. is going to check on > > binary representations here to see if variable field lengths might pose a > > problem for an update.) > > > * Section 4.6.2 Do we do something on YANG-Push statistics (e.g. > > counters of object changes, of update messages)? (Both… Test and normal > > operations need to be covered.. Match to filters working operation question) > > > Dampening: > > > > > > * Dampen can mean lessen. We should choose Damp or Dampen based > > on usage therefore. > > > > > > * Google search for “route damping†= 4,850 hits. > > > * Google search for “route dampening†= 11,600 hits > > > > > > * The more common usage is dampening, so we should stick with that. > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > -- > > > Cheers, > > > Mehmet > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > Mahesh Jethanandani > > > mjethanandani@gmail.com > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Dec 5 02:37:30 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AB412995B; Mon, 5 Dec 2016 02:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 umjIknFlKkjp; Mon, 5 Dec 2016 02:37:27 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15CD129427; Mon, 5 Dec 2016 02:36:12 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967] (unknown [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967]) by mail.nic.cz (Postfix) with ESMTPSA id B0E0E62183; Mon, 5 Dec 2016 11:36:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1480934171; bh=YHmJ5CSG4pDC92qjX7TVjzQ4VXJsH7Rxt923z+Xp3zk=; h=From:Date:To; b=Jp0AP8eB8rzSXVlAw4b9Tl8LxgXyiFtY1hsDcuLJL1clcdPGXayu7JTqXMIAT3qSB j99ShBorT9L2ZYrFLH00uTIZnNKzXpd3DTLzINQPR6Ppsi4j15Ott/5mejvoLN/u6v iGXQwDHYo63yuPZ4qybc6y3ikuBT9Tx0UjuFVI34= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: <20161205093858.GA97253@elstar.local> Date: Mon, 5 Dec 2016 11:36:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> References: <20161205093858.GA97253@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 10:37:29 -0000 > On 5 Dec 2016, at 10:38, Juergen Schoenwaelder = wrote: >=20 > On Mon, Dec 05, 2016 at 10:18:32AM +0100, Ladislav Lhotka wrote: >>=20 >>> On 2 Dec 2016, at 22:26, Lou Berger wrote: >>>=20 >>> All, >>>=20 >>> This is start of a two week poll on making >>> draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group >>> document. This document is unusual in that WG last call will be = jointly >>> held in both the NetConf and NetMod WGs, while adoption and = day-to-day processing >>> will take place in NetMod. >>=20 >> There seems to be no impact on YANG syntax or semantics - the one = mentioned in sec. 6.3 is in fact protocol stuff that doesn't belong to = the definition of YANG the language. Therefore, this work has nothing to = do with data modelling and in fact belongs to the NETCONF WG. This would = also solve the indicated WG sch > izophrenia that should IMO be avoided in any case. >=20 > I disagree that the datastore model is a protocol specific aspect. I > consider datastores an architectural component binding data models and > protocols together. In fact, the 'traditional' datastore model I would agree with this if datastores were a general concept in YANG, = but the revised-datastores draft explicitly introduces the "intended" = and "applied" datastores that may be irrelevant to other protocols using = YANG, and even needn't be used in all NETCONF implementations. I = wouldn't call this "an architectural component" of YANG. If you are saying that it will have nontrivial impact on YANG, I would = like to see it explained in sec. 6.3. Without this information I am = quite reluctant to agree with the adoption. > together with the semantics of the operation caused us to write > data models in a very specific way. Since the number of protocols Yes, to work around a flaw in the NETCONF protocol. > transporting YANG defined data is growing, it is crucial that > architectural aspects are more clearly spelled out as such. (And the See above - architectural aspects need to be relevant to all protocols. > only architectural document we have so far was done in NETMOD. But at > the end, I find the discussion which WG is responsible somewhat > pointless, it is the same set of active technical contributors > anyway.) Mehmet rightly argued in Seoul that this work should be done in NETMOD = WG because it will certainly have implications for the NETCONF protocol. = It is thus understandable that NETCONF chairs want to exercise some = control. >=20 >> A useful thing to do in the NETMOD WG would be to remove all >> NETCONF-specific text from the YANG spec because whenever YANG is >> used outside the NETCONF context (I2RS, CORE), that text is mostly >> ignored anyway. >=20 > If there is an opportunity to update all core documents together, we > may clean up some of this; so far, we never had such an opportunity. I don't know what you mean by all core documents. In my view, it would = be sufficient to split RFC 7950 into two documents - the other one could = be something like "Adapting NETCONF for use with YANG". If we don't do this, it is difficult to propose YANG for use with other = protocols (as we did for I2RS) because we have to say: "You know, some = parts of the YANG spec appear mandatory but they are irrelevant for you, = so just ignore them". This was actually the case already for RESTCONF. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 5 02:42:01 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E0F129976; Mon, 5 Dec 2016 02:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 zaImqIRtwnmO; Mon, 5 Dec 2016 02:41:58 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C605129995; Mon, 5 Dec 2016 02:40:16 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967] (unknown [IPv6:2001:718:1a02:1:40e6:f180:9f62:2967]) by mail.nic.cz (Postfix) with ESMTPSA id DBBC462467; Mon, 5 Dec 2016 11:40:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1480934414; bh=y4uKPDTuV2SN7GbYK1QJFpDGJvMQ8uUxyj7IJU4+PcQ=; h=From:Date:To; b=GulTGAbJ9Y1d7XrsGWm1tSethfTY1MX1eq3r5F6V0AsDbo+r/A6yM2HbZD6D6+m1X wMKLvwsbS2HgaeQWjduBJGGJwZME3C9hsZQG0UkgOZICdOVpVBS5k78sBi+UHYQG6Z ogEnz6Cd7TGq2pEyrYyuW9ktOyhd+2iu4TKEPE4A= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> Date: Mon, 5 Dec 2016 11:40:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2CAE4795-EE6A-4754-AF18-FBB7139C6B99@nic.cz> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 10:42:00 -0000 > On 5 Dec 2016, at 11:36, Ladislav Lhotka wrote: >=20 >>=20 >> On 5 Dec 2016, at 10:38, Juergen Schoenwaelder = wrote: >>=20 >> On Mon, Dec 05, 2016 at 10:18:32AM +0100, Ladislav Lhotka wrote: >>>=20 >>>> On 2 Dec 2016, at 22:26, Lou Berger wrote: >>>>=20 >>>> All, >>>>=20 >>>> This is start of a two week poll on making >>>> draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group >>>> document. This document is unusual in that WG last call will be = jointly >>>> held in both the NetConf and NetMod WGs, while adoption and = day-to-day processing >>>> will take place in NetMod. >>>=20 >>> There seems to be no impact on YANG syntax or semantics - the one = mentioned in sec. 6.3 is in fact protocol stuff that doesn't belong to = the definition of YANG the language. Therefore, this work has nothing to = do with data modelling and in fact belongs to the NETCONF WG. This would = also solve the indicated WG sch >> izophrenia that should IMO be avoided in any case. >>=20 >> I disagree that the datastore model is a protocol specific aspect. I >> consider datastores an architectural component binding data models = and >> protocols together. In fact, the 'traditional' datastore model >=20 > I would agree with this if datastores were a general concept in YANG, = but the revised-datastores draft explicitly introduces the "intended" = and "applied" datastores that may be irrelevant to other protocols using = YANG, and even needn't be used in all NETCONF implementations. I = wouldn't call this "an architectural component" of YANG. >=20 > If you are saying that it will have nontrivial impact on YANG, I would = like to see it explained in sec. 6.3. Without this information I am = quite reluctant to agree with the adoption. >=20 >> together with the semantics of the operation caused us to = write >> data models in a very specific way. Since the number of protocols >=20 > Yes, to work around a flaw in the NETCONF protocol. >=20 >> transporting YANG defined data is growing, it is crucial that >> architectural aspects are more clearly spelled out as such. (And the >=20 > See above - architectural aspects need to be relevant to all = protocols. >=20 >> only architectural document we have so far was done in NETMOD. But at >> the end, I find the discussion which WG is responsible somewhat >> pointless, it is the same set of active technical contributors >> anyway.) >=20 > Mehmet rightly argued in Seoul that this work should be done in NETMOD = WG because it will certainly have implications for the NETCONF Sorry, of course I meant NETCONF WG. Lada > protocol. It is thus understandable that NETCONF chairs want to = exercise some control. >=20 >>=20 >>> A useful thing to do in the NETMOD WG would be to remove all >>> NETCONF-specific text from the YANG spec because whenever YANG is >>> used outside the NETCONF context (I2RS, CORE), that text is mostly >>> ignored anyway. >>=20 >> If there is an opportunity to update all core documents together, we >> may clean up some of this; so far, we never had such an opportunity. >=20 > I don't know what you mean by all core documents. In my view, it would = be sufficient to split RFC 7950 into two documents - the other one could = be something like "Adapting NETCONF for use with YANG". >=20 > If we don't do this, it is difficult to propose YANG for use with = other protocols (as we did for I2RS) because we have to say: "You know, = some parts of the YANG spec appear mandatory but they are irrelevant for = you, so just ignore them". This was actually the case already for = RESTCONF. >=20 > Lada >=20 >>=20 >> /js >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 5 04:03:14 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B054129A27; Mon, 5 Dec 2016 04:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 jQ8t6pYAxOGm; Mon, 5 Dec 2016 04:03:08 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B16F129A31; Mon, 5 Dec 2016 04:02:12 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 20D5AA99; Mon, 5 Dec 2016 13:02:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jt78GQwea0BG; Mon, 5 Dec 2016 13:02:10 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 5 Dec 2016 13:02:10 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C31512005F; Mon, 5 Dec 2016 13:02:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9Aw6UPDe_AcK; Mon, 5 Dec 2016 13:02:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64A4E2005E; Mon, 5 Dec 2016 13:02:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 43C263D9DD89; Mon, 5 Dec 2016 13:02:10 +0100 (CET) Date: Mon, 5 Dec 2016 13:02:10 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161205120210.GA97559@elstar.local> Mail-Followup-To: Ladislav Lhotka , Lou Berger , NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 12:03:10 -0000 On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > I disagree that the datastore model is a protocol specific aspect. I > > consider datastores an architectural component binding data models and > > protocols together. In fact, the 'traditional' datastore model > > I would agree with this if datastores were a general concept in YANG, but the revised-datastores draft explicitly introduces the "intended" and "applied" datastores that may be irrelevant to other protocols using YANG, and even needn't be used in all NETCONF implementations. I wouldn't call this "an architectural component" of YANG. > An architectural component of this new management framework (that does not have a name). The fact that not all protocols may expose all datastores is IMHO not a reason that the datastore model is not an architectural framework. > If you are saying that it will have nontrivial impact on YANG, I would like to see it explained in sec. 6.3. Without this information I am quite reluctant to agree with the adoption. An operational state datastore has implications how one writes data models. It may not directly affect YANG itself but surely the usage of YANG. > See above - architectural aspects need to be relevant to all protocols. Yes, but relevant to all protocols does not mean every protocol needs to expose say all datastores. But every protocol should be clear about how what it exposes relates to the architectural framework. /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 Dec 5 04:40:47 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EAE129488 for ; Mon, 5 Dec 2016 04:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 WbqwuHdWUhLt for ; Mon, 5 Dec 2016 04:40:46 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id C7C9E129481 for ; Mon, 5 Dec 2016 04:40:45 -0800 (PST) Received: (qmail 18383 invoked by uid 0); 5 Dec 2016 12:40:40 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 5 Dec 2016 12:40:40 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id GCgd1u0072SSUrH01CggxX; Mon, 05 Dec 2016 05:40:40 -0700 X-Authority-Analysis: v=2.1 cv=K/+xQUmI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=Tx2h5zIgdRmTOk5BwFAA:9 a=pILNOxqGKmIA: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:Cc:References:To:Subject:From; bh=DCqBbXC8ee0gDJuBC7Mtxb9wcU2g3kY3J3tyBJG31T8=; b=cD89zE7b5p1xv72bJ/U0nuT6r3 LuFOLGH0iLJt9T4R9ppKt3/NU1nh5M7UNuNTsCv0pVzYSyW0TyKU1fvgZhIKV1qdkH9GJho6uIhPD 1+lQ18U/Spg3lbQA2L3Yc+M9M; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:34670 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cDsZR-0007qn-1f; Mon, 05 Dec 2016 05:40:37 -0700 From: Lou Berger To: Juergen Schoenwaelder , Andy Bierman References: <20161203090125.GB91185@elstar.local> Message-ID: <85303135-e96d-873e-8a79-07db261cae6c@labn.net> Date: Mon, 5 Dec 2016 07:40:31 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20161203090125.GB91185@elstar.local> Content-Type: text/plain; charset=windows-1252 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.85.191 X-Exim-ID: 1cDsZR-0007qn-1f X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:34670 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod WG Chairs , NetConf WG , NetMod WG , NetConf WG Chairs Subject: [Netconf] Which list/WG? (Re: WG adoption poll draft-nmdsdt-netmod-revised-datastores-00) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 12:40:47 -0000 On December 3, 2016 4:02:02 AM Juergen Schoenwaelder wrote: > ... > > PS: Do we have to run the discussion via cross-posts on two lists or > can the chairs agree to just use one list, assuming that those who > care can manage to follow this one list? > I agree that this adoption call is not the usual. The reason for this is basically due to the "which WG" issue that Lada is raising. The agreement between the chairs and the AD is that this work would be run in NetMod and that any resulting netconf/restconf protocol work would be done in netconf (i.e., the group that owns the protocol). To ensure all are in sync on this activity, the agreement between the chairs is to do the adoption discussion in both groups, and then once the normal process has been run in NetMod to do a joint WG last call. We know this makes for some duplicate messages, but it ensures the WGs are in sync. Lou From nobody Mon Dec 5 04:44:57 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20610129484 for ; Mon, 5 Dec 2016 04:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS6YVbfJdJAa for ; Mon, 5 Dec 2016 04:44:51 -0800 (PST) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (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 A1915129472 for ; Mon, 5 Dec 2016 04:44:50 -0800 (PST) Received: by mail-qt0-x243.google.com with SMTP id m48so35599287qta.2 for ; Mon, 05 Dec 2016 04:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fCy+GKunaJLUs4CyAM1ByvuvGJ7sU9uA6AHsKpk0CNs=; b=oTrCmpvFUXOBakMkIhvS+FNnT6i2XtxyddUfxFLGWvw57vw9ixUj/EvRT2Qz74W9L8 GICgxoAciK02oEhurodYXJr3mlo/+jk4POs5gTH549P5/FUsP+l3/dPAcjOfdc6wLXgt Zl43YyMp1u+I8DWLbbzYCT9w/vAdBeA7uU24zVmfdw4oakPvbIdScMVuRSJpBF467wB9 CVZofy+jEIXKMZuWyHpMp2F1i66nCwxQCKUz/opmML76mtbiNKutlpgwp9r6udDpId7Q Z5yYAoPD4TBlN7m3F0BptsQTf9pJ8NwHjV8gooLYJ6XiEqTrcN0uTehB7sH4lGBy4yhS Cmvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fCy+GKunaJLUs4CyAM1ByvuvGJ7sU9uA6AHsKpk0CNs=; b=fyPSqiTIMhFEduViYlWQrBj2Yvv+qzIq6KX6ngb5g+8FixlzVYDqi6o6UaIVJQQXVF 3yqFGZiMcT33+MW+sk4f4CQyJTHHsP4IS1fpsqxxZN4nuBmnCwSdJbbd0+0t0EGX0EPx YIkrX3yRFImBjUGecB2q5NrzNoIU2RmS0cgCdOfonIHVeQFsoILgaXFVje4ki27W0AVH y3cEUzbNMsVf9yUWi8PaSGES32WRCqzYNQ8q++NifHmMiJrLplKh1zu2uCZW6dAzBs8o V/ZCK9o6vbnaMMOBQbi+Iwb1ivUpMlveGC5VsSJdgrvEAPLJKOiuuXzX2b60E33bHICB Q4jg== X-Gm-Message-State: AKaTC02mKYA+ZSQtFjMnzPV+SEwQfFpHewUJui6sWZAefeTCC/nR4Dn44xzc5CHKMddm6mJFnfIuZumd/0G6Wg== X-Received: by 10.25.5.215 with SMTP id 206mr21139738lff.119.1480941889426; Mon, 05 Dec 2016 04:44:49 -0800 (PST) MIME-Version: 1.0 References: <9573F76E-A55D-40AA-8FB2-53E207EA1FCF@gmail.com> <20161203085006.GA91185@elstar.local> <001801d24d4e$85a58210$90f08630$@hansfords.net> <01cb01d24edf$52b91320$4001a8c0@gateway.2wire.net> In-Reply-To: <01cb01d24edf$52b91320$4001a8c0@gateway.2wire.net> From: MehmetErsue Date: Mon, 05 Dec 2016 12:44:38 +0000 Message-ID: To: "t.petch" , Jonathan Hansford , Juergen Schoenwaelder , "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a113ec332409aec0542e8a762 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] proper quotations was Re: 5277 Backwards Compatibility: how to deliver X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 12:44:56 -0000 --001a113ec332409aec0542e8a762 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It would be indeed nice if people would use quotations and show the mail history in a readable fashion. However there are so many mail clients around which use HTML and even don't provide automatic quotation. I sometimes edit HTML mails and add quotation manually to show to which comment I'm responding. I think it is difficult to force people to send only text-based mails or use a particular mail client. Mehmet On Mon, Dec 5, 2016 at 11:10 AM t.petch wrote: > ----- Original Message ----- > From: "Jonathan Hansford" > To: "'Juergen Schoenwaelder'" ; > "'Eric Voit (evoit)'" > Cc: > Sent: Saturday, December 03, 2016 10:17 AM > > > Are you proposing a specific style of quoting, or are any of those > listed acceptable? The Wikipedia page doesn't identify what "proper > quotations" are. > > For me, proper quotations are anything that I can readily see via my MUA > which enables me to distinguish what the sender of the e-mail has > written, as opposed to what was already there when the sender received > the e-mail to which they are responding. > > In Eric's response to Mahesh, there is nothing, zilch, zero as in > > "Yes. Anyone who wants to use existing 5277 would just leverage to the > old namespace. > > If the namespaces are truly different, and the server already supports > 5277, what would be the implication of having two , > in two different namespaces? > > There would be no in 1.1. With 5277bis the > recommended RPC going forward is . " > > The original text and the new text are separated by a blank line as are, > when appropriate, the paragraphs of the original text and inserted text > making it hard work, sometimes impossible, to tell who is saying what. > > The commonest (and so best) way is the use of one or more of > > > on > every line although once per paragraph is usable. Other characters will > do as long as they display - I get an increasing level of open boxes > these days, especially in the minutes of WGs, which are a fancy Unicode > variant of a quote, double quote, dash, period and such like. > > Anything that starts as Microsoft Word is likely to be unintelligible. > > Tom Petch > > > Jonathan > > > > > > > -----Original Message----- > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: 03 December 2016 08:50 > > > To: Eric Voit (evoit) > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliver > > > > > > Hi, > > > > > > I can't follow discussions if people use email clients that do not > do proper > > > quotations. https://en.wikipedia.org/wiki/Posting_style > > > > > > /js > > > > > > On Fri, Dec 02, 2016 at 11:49:11PM +0000, Eric Voit (evoit) wrote: > > > > From: Mahesh Jethanandani, December 2, 2016 6:20 PM > > > > > > > > [Chair hat off] > > > > > > > > Eric, > > > > > > > > What would help is to understand what the backward compatibility > section > > > would look like with your proposal. Currently it says that 5277bis > will > > > advertise "urn:ietf:params:netconf:capability:notification:1.0=E2=80= =9D and > > > "urn:ietf:params:netconf:capability:notification:1.1=E2=80=9D. Client= s can > then choose > > > which capability they are capable of and want to support. With the > new > > > proposal, are we dropping advertisement of > > > "urn:ietf:params:netconf:capability:notification:1.0=E2=80=9D? > > > > > > > > Yes. Anyone who wants to use existing 5277 would just leverage to > the old > > > namespace. > > > > > > > > If the namespaces are truly different, and the server already > supports > > > 5277, what would be the implication of having two > , in > > > two different namespaces? > > > > > > > > There would be no in 1.1. With 5277bis the > > > recommended RPC going forward is . In this > way > > > everything stays independent. But a server could chose to support > both 1.0 > > > & 1.1. This gives backwards compatibility in a single deployment. > > > > > > > > [Chair hat on] > > > > > > > > Echoing what Mehmet has already said. This is essentially a WG > call. If you > > > like/do not like this proposal, or have questions about it, this > would be the > > > time to speak up. > > > > > > > > I am absolutely good to go with whatever the WG decides. I do > believe > > > that obsoleting 5277 makes specification and implementation simpler, > with > > > no meaningful loss of functionality. > > > > > > > > Eric > > > > > > > > Cheers. > > > > > > > > On Dec 2, 2016, at 12:43 PM, MehmetErsue > > > > wrote: > > > > > > > > Hi Eric, All, > > > > > > > > yes, we need a charter change since there is a difference between > > > enhancing and replacing. > > > > As I remember the charter discussion people were keen of having > > > backwards compatibility because of deployed implementations. > > > > > > > > I believe we need to understand better the implications and what > kind of > > > "replacing" we would strive for. > > > > Does replacing mean full deprecation of 5277 or will the > compatibility > > > between e.g. old client and new server be possible? > > > > > > > > I believe we need a discussion on this on the maillist and get the > opinion of > > > all parties. > > > > At the end the WG will decide. > > > > @All: > > > > Please comment on replacing instead of enhancing 5277. > > > > Please explain why you are in favor of replacing or against. > > > > If you are in favor please explain what kind of replacing (i.e. > compatibility > > > level) you would like to have. > > > > If you are in favor of keeping 5277 as standard and developing an > additional > > > independent notification mechanism please make its case. > > > > Thanks, > > > > Mehmet > > > > > > > > On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit) > > > > wrote: > > > > Hi Mehmet, > > > > Hi Mahesh, > > > > Hi Benoit, > > > > > > > > Item #6 in the NETCONF charter is: =E2=80=9CEnhance RFC 5277 with t= he > ability to > > > delete subscriptions without closing the client session, to modify > existing > > > subscriptions, and to have multiple subscriptions on an established > client > > > session. These changes should not affect older clients that do not > support > > > these particular subscription requirements. The RPCs and the data > models in > > > RFC 5277 should be converted to YANG.=E2=80=9D > > > > > > > > Those attending the Event Notification Dezign Team today believe > that it is > > > better to Obsolete 5277 it rather than Enhance it. The main > reasons are: > > > > > > > > =E2=80=A2 The existing 5277 rpc and the= new > rpcs need to > > > be in independent namespaces. Not supporting 5277 subscription> > > > and a separate namespace / model will significantly simplify the new > > > specification. > > > > > > > > =E2=80=A2 We can=E2=80=99t think of a reason why any YANG mod= el developed > for legacy > > > 5277 namespace should be developed. New development is more likely > to > > > focus on the new model and its new capabilities > > > > > > > > =E2=80=A2 Any clients & servers desiring to support the old > capabilities can > > > certainly do this. Independent capability sets can be advertised. > Backwards > > > compatibility is not compromised. > > > > > > > > =E2=80=A2 Leaving backwards compatibility to embedded server = code > > > significantly reduces new development needs. > > > > > > > > As obsoleting 5277 with this new spec is a significant step, we > wanted to > > > get your and the community=E2=80=99s feedback and buy-in before we mo= dify > any of > > > the documents in this direction. > > > > > > > > Would such a move mean a charter change? My suspicion is no as > we are > > > enhancing the functions supported by 5277 (but without bringing > along the > > > RPC). Do you have any guidance here? Is this worth having an > interim > > > meeting to discuss and finalize? > > > > > > > > Thanks, > > > > Eric > > > > > > > > P.S.: Additional discussion on this is contained in minutes 2 to15 > minutes of > > > the WebEx audio recording below. > > > > > > > > From: Eric Voit, November 30, 2016 5:58 PM Minutes posted at: > > > > https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-11-30 > > > > > > > > =E2=80=A2 As always, our DezignTM Team is a gathering of > individuals providing > > > informal input to NETCONF. We ask NETCONF WG to comment on our > > > discussion results as a preparation for the WG consensus. Please > approach > > > Eric Voit if you want to be included directly in these meetings. > > > > > > > > Meeting Materials > > > > > > > > Attending > > > > > > > > WebEx > > > > > > > > Recording > > > 47dd8cff3772739f66c4> > > > > password: bXeveFV5 > > > > > > > > Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar > Nilsen-Nygaard, > > > > Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika > Tripathy, > > > > Sharon Chisholm > > > > > > > > Obsolete RFC5277 or 5277bis? > > > > > > > > * If you are going to support both old and new capabilities, > you will have > > > your old 5277 code, and you will have your new code. Why develop a > > > backwards compatible part of the spec which no one would or should > > > implement. People should develop to the new capability. > > > > > > > > * 5277 already has enough changes to it (e.g., dataplane > has moved to > > > 6241 filtered notifications) > > > > > > > > * Recommendation for people on today's call is to Obsolete > 5277 > > > > * Must go to the WG, its chairs, and Benoit to confirm this > > > recommendation before we adjust current documentation > > > > Changes to the documents discussed today [5277bis] > > > > > > > > * Scrub for error types in various subscription states. > Authorization and > > > other errors should be reported using the protocol-specific error > codes; not > > > specialized errors per these new RPCs. They still need to be > identified > > > though. Distinguish error types from subscription state so that you > know the > > > state a particular error happened during. > > > > * Expose operational state of subscriptions in a separate YANG > model or > > > container. (i.e., add =E2=80=9C-state=E2=80=9D into naming convention= for the ro > part) > > > > * Should subscription-id and filter-id both be id? > (double-check, but we > > > can do to the shorter description =E2=80=9Cidentifier=E2=80=9D) > > > > * Do we rename push-source to =E2=80=9Coriginates from=E2=80=9D= to be more > > > explicit/accurate? (better name is needed. Include it in the > terminology > > > section.) > > > > * Section 2.3 has SHOULD for 5277 filters. Not sure why this > isn=E2=80=99t a MUST. > > > Also we need a better name for 5277 filters. This name doesn=E2=80=99= t > expose what > > > is possible, and what is not. Especially if we jettison 5277 > compatibility, we > > > need a better name for 6241, and we need to define the boundaries of > filter > > > solution. Andy has a strawman proposal. > > > > * Delete create-subscription RPC and legacy namespace should > WG > > > agree. > > > > * Do we do a test-only operation? (Let=E2=80=99s not do this wo= rk > without an > > > advocate) > > > > * We need a way to test if the filters are doing what we > expect they are > > > doing. (Perhaps counters/captures on an active subscription?) > > > > * For configured subscriptions, make receiver key ip address > and port. At > > > this point we don=E2=80=99t want VRF > > > > * Change source-vrf description to indicate that we should > align with > > > names from draft-ietf-rtgwg-ni-model-01 should it complete in time. > > > > * start-time in the YANG model from startTime as we don=E2=80= =99t have > to worry > > > about backwards compatible RPC. > > > > * Make stream type string rather than identity (preference for > identity, > > > but not willing to fight. Note: this could change based on what > happens with > > > filters) > > > > [Yang-push] > > > > > > > > * Need to define error type for each subscription parameter > such as > > > =E2=80=9Cencoding not defined=E2=80=9D, =E2=80=9CFilter syntax not su= pported=E2=80=9D or =E2=80=9Cfilter > complexity > > > not supportable by platform=E2=80=9D. > > > > * Section 3.1 =E2=80=93 Discussion on the Editors note - the ad= dition > of a > > > =E2=80=9Cchanges-only=E2=80=9D flag for a periodic subscription. (Som= e support for > this, but > > > more discussion is needed as the work is non-trivial.) > > > > * Section 3.8.4 =E2=80=93 recommend removal (ok) > > > > * Section 4.4: reduce this just to the new parameters (can we > remove > > > this entirely considering section 3.1? Or do we merge 3.1 into > here?) (Eric talk > > > to Alex, likely ok) > > > > * Section 4.6.2 Is there any reason why we can=E2=80=99t have t= he > timestamp on > > > the yang push include the number of significant digits as expressed > by trailing > > > zeros if necessary on the =E2=80=9Ctime-of-update=E2=80=9D. This woul= d let platforms > express > > > what they are capable of doing. (Note: seconds would be a minimum > > > granularity). (we should go with this if possible. Susan H. is going > to check on > > > binary representations here to see if variable field lengths might > pose a > > > problem for an update.) > > > > * Section 4.6.2 Do we do something on YANG-Push statistics > (e.g. > > > counters of object changes, of update messages)? (Both=E2=80=A6 Test = and > normal > > > operations need to be covered.. Match to filters working operation > question) > > > > Dampening: > > > > > > > > * Dampen can mean lessen. We should choose Damp or Dampen > based > > > on usage therefore. > > > > > > > > * Google search for =E2=80=9Croute damping=E2=80=9D =3D 4,85= 0 hits. > > > > * Google search for =E2=80=9Croute dampening=E2=80=9D =3D 11= ,600 hits > > > > > > > > * The more common usage is dampening, so we should stick with > that. > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > > > > > -- > > > > Cheers, > > > > Mehmet > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > Mahesh Jethanandani > > > > mjethanandani@gmail.com > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 <0421%202003587> Campus Ring 1 | > 28759 Bremen | > Germany > > > Fax: +49 421 200 3103 <0421%202003103> < > http://www.jacobs-university.de/> > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --=20 Cheers, Mehmet --001a113ec332409aec0542e8a762 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It would be indeed nice if people would use= quotations and show the mail history in a readable fashion.
Howev= er there are so many mail clients around which use HTML and even don't = provide automatic quotation.

I sometimes edit HTML mails=20 and add quotation manually to show to which comment I'm responding.
= I think it is difficult to force people to send only text-based mails or us= e a particular mail client.

Mehmet

On Mon, Dec 5, 2016 at 11:10 AM t.petch <<= a href=3D"mailto:ietfc@btconnect.com">ietfc@btconnect.com> wrote:
----- Original Message -----
From: "Jonathan Hansford" <jonathan@hansfords.net>=
To: "'Juergen Schoenwaelder'" <j.sc= hoenwaelder@jacobs-university.de>;
"'Eric Voit (evoit)'" <evoit@cisco.com>
Cc: <netconf@ietf.org>
Sent: Saturday, December 03, 2016 10:17 AM

> Are you proposing a specific style of quoting, or are any of those
listed acceptable? The Wikipedia page doesn't identify what "prope= r
quotations" are.

For me, proper quotations are anything that I can readily see via my MUA which enables me to distinguish what the sender of the e-mail has
written, as opposed to what was already there when the sender received
the e-mail to which they are responding.

In Eric's response to Mahesh, there is nothing, zilch, zero as in

"Yes.=C2=A0 Anyone who wants to use existing 5277 would just leverage = to the
old namespace.

If the namespaces are truly different, and the server already supports
5277, what would be the implication of having two <create-subscription&g= t;,
in two different namespaces?

There would be no <create-subscription> in 1.1.=C2=A0 =C2=A0With 5277= bis the
recommended RPC going forward is <establish-subscription>.=C2=A0 &quo= t;

The original text and the new text are separated by a blank line as are, when appropriate, the paragraphs of the original text and inserted text
making it hard work, sometimes impossible, to tell who is saying what.

The commonest (and so best) way is the use of one or more of > > >= on
every line although once per paragraph is usable.=C2=A0 Other characters wi= ll
do as long as they display - I get an increasing level of open boxes
these days, especially in the minutes of WGs, which are a fancy Unicode
variant of a quote, double quote, dash, period and such like.

Anything that starts as Microsoft Word is likely to be unintelligible.

Tom Petch

> Jonathan
>
>
> > -----Original Message-----
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Beh= alf Of Juergen
> > Schoenwaelder
> > Sent: 03 December 2016 08:50
> > To: Eric Voit (evoit) <evoit@cisco.com>
> > Cc: netconf@ietf.org
> > Subject: Re: [Netconf] 5277 Backwards Compatibility: how to deliv= er
> >
> > Hi,
> >
> > I can't follow discussions if people use email clients that d= o not
do proper
> > quotations. https://en.wiki= pedia.org/wiki/Posting_style
> >
> > /js
> >
> > On Fri, Dec 02, 2016 at 11:49:11PM +0000, Eric Voit (evoit) wrote= :
> > > From: Mahesh Jethanandani, December 2, 2016 6:20 PM
> > >
> > > [Chair hat off]
> > >
> > > Eric,
> > >
> > > What would help is to understand what the backward compatibi= lity
section
> > would look like with your proposal. Currently it says that 5277bi= s
will
> > advertise "urn:ietf:params:netconf:capability:notification:1= .0=E2=80=9D and
> > "urn:ietf:params:netconf:capability:notification:1.1=E2=80= =9D. Clients can
then choose
> > which capability they are capable of and want to support. With th= e
new
> > proposal, are we dropping advertisement of
> > "urn:ietf:params:netconf:capability:notification:1.0=E2=80= =9D?
> > >
> > > Yes.=C2=A0 Anyone who wants to use existing 5277 would just = leverage to
the old
> > namespace.
> > >
> > > If the namespaces are truly different, and the server alread= y
supports
> > 5277, what would be the implication of having two
<create-subscription>, in
> > two different namespaces?
> > >
> > > There would be no <create-subscription> in 1.1.=C2=A0 = =C2=A0With 5277bis the
> > recommended RPC going forward is <establish-subscription>.= =C2=A0 In this
way
> > everything stays independent.=C2=A0 But a server could chose to s= upport
both 1.0
> > & 1.1.=C2=A0 =C2=A0This gives backwards compatibility in a si= ngle deployment.
> > >
> > > [Chair hat on]
> > >
> > > Echoing what Mehmet has already said. This is essentially a = WG
call. If you
> > like/do not like this proposal, or have questions about it, this<= br class=3D"gmail_msg"> would be the
> > time to speak up.
> > >
> > > I am absolutely good to go with whatever the WG decides.=C2= =A0 =C2=A0I do
believe
> > that obsoleting 5277 makes specification and implementation simpl= er,
with
> > no meaningful loss of functionality.
> > >
> > > Eric
> > >
> > > Cheers.
> > >
> > > On Dec 2, 2016, at 12:43 PM, MehmetErsue
> > <mersue@gmail.com<mailto:mersue@gmail.com>> wro= te:
> > >
> > > Hi Eric, All,
> > >
> > > yes, we need a charter change since there is a difference be= tween
> > enhancing and replacing.
> > > As I remember the charter discussion people were keen of hav= ing
> > backwards compatibility because of deployed implementations.
> > >
> > > I believe we need to understand better the implications and = what
kind of
> > "replacing" we would strive for.
> > > Does replacing mean full deprecation of 5277 or will the
compatibility
> > between e.g. old client and new server be possible?
> > >
> > > I believe we need a discussion on this on the maillist and g= et the
opinion of
> > all parties.
> > > At the end the WG will decide.
> > > @All:
> > > Please comment on replacing instead of enhancing 5277.
> > > Please explain why you are in favor of replacing or against.=
> > > If you are in favor please explain what kind of replacing (i= .e.
compatibility
> > level) you would like to have.
> > > If you are in favor of keeping 5277 as standard and developi= ng an
additional
> > independent notification mechanism please make its case.
> > > Thanks,
> > > Mehmet
> > >
> > > On Thu, Dec 1, 2016 at 2:27 AM, Eric Voit (evoit)
> > <evoit@cisco.com<mailto:evoit@cisco.com>> wrote:<= br class=3D"gmail_msg"> > > > Hi Mehmet,
> > > Hi Mahesh,
> > > Hi Benoit,
> > >
> > > Item #6 in the NETCONF charter is: =E2=80=9CEnhance RFC 5277= with the
ability to
> > delete subscriptions without closing the client session, to modif= y
existing
> > subscriptions, and to have multiple subscriptions on an establish= ed
client
> > session. These changes should not affect older clients that do no= t
support
> > these particular subscription requirements. The RPCs and the data=
models in
> > RFC 5277 should be converted to YANG.=E2=80=9D
> > >
> > > Those attending the Event Notification Dezign Team today bel= ieve
that it is
> > better to Obsolete 5277 it rather than Enhance it.=C2=A0 =C2=A0Th= e main
reasons are:
> > >
> > > =E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A0The existing 5277 <cr= eate subscription> rpc and the new
rpcs need to
> > be in independent namespaces. Not supporting 5277 <create
subscription>
> > and a separate namespace / model will significantly simplify the = new
> > specification.
> > >
> > > =E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A0We can=E2=80=99t think o= f a reason why any YANG model developed
for legacy
> > 5277 namespace should be developed.=C2=A0 New development is more= likely
to
> > focus on the new model and its new capabilities
> > >
> > > =E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A0Any clients & server= s desiring to support the old
capabilities can
> > certainly do this.=C2=A0 Independent capability sets can be adver= tised.
Backwards
> > compatibility is not compromised.
> > >
> > > =E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A0Leaving backwards compat= ibility to embedded server code
> > significantly reduces new development needs.
> > >
> > > As obsoleting 5277 with this new spec is a significant step,= we
wanted to
> > get your and the community=E2=80=99s feedback and buy-in before w= e modify
any of
> > the documents in this direction.
> > >
> > > Would such a move mean a charter change?=C2=A0 =C2=A0My susp= icion is no as
we are
> > enhancing the functions supported by 5277 (but without bringing along the
> > RPC).=C2=A0 Do you have any guidance here?=C2=A0 =C2=A0Is this wo= rth having an
interim
> > meeting to discuss and finalize?
> > >
> > > Thanks,
> > > Eric
> > >
> > > P.S.: Additional discussion on this is contained in minutes = 2 to15
minutes of
> > the WebEx audio recording below.
> > >
> > > From: Eric Voit, November 30, 2016 5:58 PM Minutes posted at= :
> > > ht= tps://github.com/netconf-wg/yang-push/wiki/Minutes-2016-11-30
> > >
> > > =E2=80=A2=C2=A0 =C2=A0 =C2=A0 =C2=A0 As always, our DezignTM= Team is a gathering of
individuals providing
> > informal input to NETCONF. We ask NETCONF WG to comment on our > > discussion results as a preparation for the WG consensus. Please<= br class=3D"gmail_msg"> approach
> > Eric Voit if you want to be included directly in these meetings.<= br class=3D"gmail_msg"> > > >
> > > Meeting Materials
> > >
> > > Attending
> > >
> > > WebEx
> > >
> >
Recording<https= ://cisco.webex.com/ciscosales/lsr.php?RCID=3D87cde245293c
> > > 47dd8cff3772739f66c4>
> > > password: bXeveFV5
> > >
> > > Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar
Nilsen-Nygaard,
> > > Eric Voit, Tim Jenkins, Balazs Lengyel, Susan Hares Ambika Tripathy,
> > > Sharon Chisholm
> > >
> > > Obsolete RFC5277 or 5277bis?
> > >
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0If you are going to support both o= ld and new capabilities,
you will have
> > your old 5277 code, and you will have your new code. Why develop = a
> > backwards compatible part of the spec which no one would or shoul= d
> > implement. People should develop to the new capability.
> > >
> > >=C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A05277 already has enough ch= anges to it (e.g., dataplane
has moved to
> > 6241 filtered notifications)
> > >
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Recommendation for people on today= 's call is to Obsolete
5277
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Must go to the WG, its chairs, and= Benoit to confirm this
> > recommendation before we adjust current documentation
> > > Changes to the documents discussed today [5277bis]
> > >
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Scrub for error types in various s= ubscription states.
Authorization and
> > other errors should be reported using the protocol-specific error=
codes; not
> > specialized errors per these new RPCs. They still need to be
identified
> > though. Distinguish error types from subscription state so that y= ou
know the
> > state a particular error happened during.
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Expose operational state of subscr= iptions in a separate YANG
model or
> > container. (i.e., add =E2=80=9C-state=E2=80=9D into naming conven= tion for the ro
part)
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Should subscription-id and filter-= id both be id?
(double-check, but we
> > can do to the shorter description =E2=80=9Cidentifier=E2=80=9D) > > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Do we rename push-source to =E2=80= =9Coriginates from=E2=80=9D to be more
> > explicit/accurate? (better name is needed. Include it in the
terminology
> > section.)
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Section 2.3 has SHOULD for 5277 fi= lters. Not sure why this
isn=E2=80=99t a MUST.
> > Also we need a better name for 5277 filters. This name doesn=E2= =80=99t
expose what
> > is possible, and what is not. Especially if we jettison 5277
compatibility, we
> > need a better name for 6241, and we need to define the boundaries= of
filter
> > solution. Andy has a strawman proposal.
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Delete create-subscription RPC and= legacy namespace should
WG
> > agree.
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Do we do a test-only operation? (L= et=E2=80=99s not do this work
without an
> > advocate)
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0We need a way to test if the filte= rs are doing what we
expect they are
> > doing. (Perhaps counters/captures on an active subscription?)
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0For configured subscriptions, make= receiver key ip address
and port. At
> > this point we don=E2=80=99t want VRF
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Change source-vrf description to i= ndicate that we should
align with
> > names from draft-ietf-rtgwg-ni-model-01 should it complete in tim= e.
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0start-time in the YANG model from = startTime as we don=E2=80=99t have
to worry
> > about backwards compatible RPC.
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Make stream type string rather tha= n identity (preference for
identity,
> > but not willing to fight. Note: this could change based on what happens with
> > filters)
> > > [Yang-push]
> > >
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Need to define error type for each= subscription parameter
such as
> > =E2=80=9Cencoding not defined=E2=80=9D, =E2=80=9CFilter syntax no= t supported=E2=80=9D or =E2=80=9Cfilter
complexity
> > not supportable by platform=E2=80=9D.
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Section 3.1 =E2=80=93 Discussion o= n the Editors note - the addition
of a
> > =E2=80=9Cchanges-only=E2=80=9D flag for a periodic subscription. = (Some support for
this, but
> > more discussion is needed as the work is non-trivial.)
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Section 3.8.4 =E2=80=93 recommend = removal (ok)
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Section 4.4: reduce this just to t= he new parameters (can we
remove
> > this entirely considering section 3.1? Or do we merge 3.1 into here?) (Eric talk
> > to Alex, likely ok)
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Section 4.6.2 Is there any reason = why we can=E2=80=99t have the
timestamp on
> > the yang push include the number of significant digits as express= ed
by trailing
> > zeros if necessary on the =E2=80=9Ctime-of-update=E2=80=9D. This = would let platforms
express
> > what they are capable of doing. (Note: seconds would be a minimum=
> > granularity). (we should go with this if possible. Susan H. is go= ing
to check on
> > binary representations here to see if variable field lengths migh= t
pose a
> > problem for an update.)
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Section 4.6.2 Do we do something o= n YANG-Push statistics
(e.g.
> > counters of object changes, of update messages)? (Both=E2=80=A6 T= est and
normal
> > operations need to be covered.. Match to filters working operatio= n
question)
> > > Dampening:
> > >
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0Dampen can mean lessen. We should = choose Damp or Dampen
based
> > on usage therefore.
> > >
> > >=C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0Google search for =E2=80= =9Croute damping=E2=80=9D =3D 4,850 hits.
> > >=C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0Google search for =E2=80= =9Croute dampening=E2=80=9D =3D 11,600 hits
> > >
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0The more common usage is dampening= , so we should stick with
that.
> > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org<mailto:Netconf@ietf.org>
> > > https://www.ietf.org= /mailman/listinfo/netconf
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Mehmet
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org<mailto:Netconf@ietf.org>
> > > https://www.ietf.org= /mailman/listinfo/netconf
> > >
> > > Mahesh Jethanandani
> > > mjethanandani@gmail.com<mailto:mjethanand= ani@gmail.com>
> > >
> > >
> > >
> >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org= /mailman/listinfo/netconf
> >
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs 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-un= iversity.de/>
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mail= man/listinfo/netconf
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/l= istinfo/netconf
>

_______________________________________________
Netconf mailing list
N= etconf@ietf.org
https://www.ietf.org/mailman/listin= fo/netconf
--
Cheers,
Mehmet
--001a113ec332409aec0542e8a762-- From nobody Mon Dec 5 04:54:43 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793B9129494 for ; Mon, 5 Dec 2016 04:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 daCqqwu0RM7Y for ; Mon, 5 Dec 2016 04:54:34 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9200512949F for ; Mon, 5 Dec 2016 04:54:31 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id B24091AE0118; Mon, 5 Dec 2016 13:54:30 +0100 (CET) Date: Mon, 05 Dec 2016 13:54:30 +0100 (CET) Message-Id: <20161205.135430.2199901518863792848.mbj@tail-f.com> To: mersue@gmail.com From: Martin Bjorklund In-Reply-To: References: <001801d24d4e$85a58210$90f08630$@hansfords.net> <01cb01d24edf$52b91320$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] proper quotations was Re: 5277 Backwards Compatibility: how to deliver X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 12:54:41 -0000 TWVobWV0RXJzdWUgPG1lcnN1ZUBnbWFpbC5jb20+IHdyb3RlOg0KPiBJdCB3b3VsZCBiZSBpbmRl ZWQgbmljZSBpZiBwZW9wbGUgd291bGQgdXNlIHF1b3RhdGlvbnMgYW5kIHNob3cgdGhlIG1haWwN Cj4gaGlzdG9yeSBpbiBhIHJlYWRhYmxlIGZhc2hpb24uDQo+IEhvd2V2ZXIgdGhlcmUgYXJlIHNv IG1hbnkgbWFpbCBjbGllbnRzIGFyb3VuZCB3aGljaCB1c2UgSFRNTCBhbmQgZXZlbiBkb24ndA0K PiBwcm92aWRlIGF1dG9tYXRpYyBxdW90YXRpb24uDQo+IA0KPiBJIHNvbWV0aW1lcyBlZGl0IEhU TUwgbWFpbHMgYW5kIGFkZCBxdW90YXRpb24gbWFudWFsbHkgdG8gc2hvdyB0byB3aGljaA0KPiBj b21tZW50IEknbSByZXNwb25kaW5nLg0KDQpTYW1lIGhlcmUuDQoNCi4uLiBhbmQgc29tZXRpbWVz IEkgYWN0dWFsbHkgZ2l2ZSB1cCBvbiBzb21lIHRocmVhZHMgYW5kIGRvbid0IGJvdGhlcg0KdG8g cmVwbHkuDQoNCj4gSSB0aGluayBpdCBpcyBkaWZmaWN1bHQgdG8gZm9yY2UgcGVvcGxlIHRvIHNl bmQgb25seSB0ZXh0LWJhc2VkIG1haWxzIG9yDQo+IHVzZSBhIHBhcnRpY3VsYXIgbWFpbCBjbGll bnQuDQoNClJpZ2h0LCBidXQgaG9wZWZ1bGx5IGl0IGRvZXNuJ3QgaHVydCB0byBhc2sgcG9saXRl bHkuICBJdCBkb2Vzbid0IG1ha2UNCm11Y2ggc2Vuc2UgdGhhdCBwZW9wbGUgbGlrZSB5b3Vyc2Vs ZiBzaG91bGQgaGF2ZSB0byBtYW51YWxseSBmaXggb3RoZXINCnBlb3BsZSdzIHBvb3IgZm9ybWF0 dGluZyBpZiBpdCBjYW4gYmUgYXZvaWRlZCBpbiB0aGUgY2FzZXMgd2hlcmUgdGhlcmUNCmlzIGEg c2ltcGxlIHNldHRpbmcgaW4gdGhlIGVtYWlsIGNsaWVudC4NCg0KDQoNCi9tYXJ0aW4NCg0KDQo+ IA0KPiBNZWhtZXQNCj4gDQo+IE9uIE1vbiwgRGVjIDUsIDIwMTYgYXQgMTE6MTAgQU0gdC5wZXRj aCA8aWV0ZmNAYnRjb25uZWN0LmNvbT4gd3JvdGU6DQo+IA0KPiA+IC0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCj4gPiBGcm9tOiAiSm9uYXRoYW4gSGFuc2ZvcmQiIDxqb25hdGhhbkBoYW5z Zm9yZHMubmV0Pg0KPiA+IFRvOiAiJ0p1ZXJnZW4gU2Nob2Vud2FlbGRlciciIDxqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+Ow0KPiA+ICInRXJpYyBWb2l0IChldm9pdCknIiA8 ZXZvaXRAY2lzY28uY29tPg0KPiA+IENjOiA8bmV0Y29uZkBpZXRmLm9yZz4NCj4gPiBTZW50OiBT YXR1cmRheSwgRGVjZW1iZXIgMDMsIDIwMTYgMTA6MTcgQU0NCj4gPg0KPiA+ID4gQXJlIHlvdSBw cm9wb3NpbmcgYSBzcGVjaWZpYyBzdHlsZSBvZiBxdW90aW5nLCBvciBhcmUgYW55IG9mIHRob3Nl DQo+ID4gbGlzdGVkIGFjY2VwdGFibGU/IFRoZSBXaWtpcGVkaWEgcGFnZSBkb2Vzbid0IGlkZW50 aWZ5IHdoYXQgInByb3Blcg0KPiA+IHF1b3RhdGlvbnMiIGFyZS4NCj4gPg0KPiA+IEZvciBtZSwg cHJvcGVyIHF1b3RhdGlvbnMgYXJlIGFueXRoaW5nIHRoYXQgSSBjYW4gcmVhZGlseSBzZWUgdmlh IG15IE1VQQ0KPiA+IHdoaWNoIGVuYWJsZXMgbWUgdG8gZGlzdGluZ3Vpc2ggd2hhdCB0aGUgc2Vu ZGVyIG9mIHRoZSBlLW1haWwgaGFzDQo+ID4gd3JpdHRlbiwgYXMgb3Bwb3NlZCB0byB3aGF0IHdh cyBhbHJlYWR5IHRoZXJlIHdoZW4gdGhlIHNlbmRlciByZWNlaXZlZA0KPiA+IHRoZSBlLW1haWwg dG8gd2hpY2ggdGhleSBhcmUgcmVzcG9uZGluZy4NCj4gPg0KPiA+IEluIEVyaWMncyByZXNwb25z ZSB0byBNYWhlc2gsIHRoZXJlIGlzIG5vdGhpbmcsIHppbGNoLCB6ZXJvIGFzIGluDQo+ID4NCj4g PiAiWWVzLiAgQW55b25lIHdobyB3YW50cyB0byB1c2UgZXhpc3RpbmcgNTI3NyB3b3VsZCBqdXN0 IGxldmVyYWdlIHRvIHRoZQ0KPiA+IG9sZCBuYW1lc3BhY2UuDQo+ID4NCj4gPiBJZiB0aGUgbmFt ZXNwYWNlcyBhcmUgdHJ1bHkgZGlmZmVyZW50LCBhbmQgdGhlIHNlcnZlciBhbHJlYWR5IHN1cHBv cnRzDQo+ID4gNTI3Nywgd2hhdCB3b3VsZCBiZSB0aGUgaW1wbGljYXRpb24gb2YgaGF2aW5nIHR3 byA8Y3JlYXRlLXN1YnNjcmlwdGlvbj4sDQo+ID4gaW4gdHdvIGRpZmZlcmVudCBuYW1lc3BhY2Vz Pw0KPiA+DQo+ID4gVGhlcmUgd291bGQgYmUgbm8gPGNyZWF0ZS1zdWJzY3JpcHRpb24+IGluIDEu MS4gICBXaXRoIDUyNzdiaXMgdGhlDQo+ID4gcmVjb21tZW5kZWQgUlBDIGdvaW5nIGZvcndhcmQg aXMgPGVzdGFibGlzaC1zdWJzY3JpcHRpb24+LiAgIg0KPiA+DQo+ID4gVGhlIG9yaWdpbmFsIHRl eHQgYW5kIHRoZSBuZXcgdGV4dCBhcmUgc2VwYXJhdGVkIGJ5IGEgYmxhbmsgbGluZSBhcyBhcmUs DQo+ID4gd2hlbiBhcHByb3ByaWF0ZSwgdGhlIHBhcmFncmFwaHMgb2YgdGhlIG9yaWdpbmFsIHRl eHQgYW5kIGluc2VydGVkIHRleHQNCj4gPiBtYWtpbmcgaXQgaGFyZCB3b3JrLCBzb21ldGltZXMg aW1wb3NzaWJsZSwgdG8gdGVsbCB3aG8gaXMgc2F5aW5nIHdoYXQuDQo+ID4NCj4gPiBUaGUgY29t bW9uZXN0IChhbmQgc28gYmVzdCkgd2F5IGlzIHRoZSB1c2Ugb2Ygb25lIG9yIG1vcmUgb2YgPiA+ ID4gb24NCj4gPiBldmVyeSBsaW5lIGFsdGhvdWdoIG9uY2UgcGVyIHBhcmFncmFwaCBpcyB1c2Fi bGUuICBPdGhlciBjaGFyYWN0ZXJzIHdpbGwNCj4gPiBkbyBhcyBsb25nIGFzIHRoZXkgZGlzcGxh eSAtIEkgZ2V0IGFuIGluY3JlYXNpbmcgbGV2ZWwgb2Ygb3BlbiBib3hlcw0KPiA+IHRoZXNlIGRh eXMsIGVzcGVjaWFsbHkgaW4gdGhlIG1pbnV0ZXMgb2YgV0dzLCB3aGljaCBhcmUgYSBmYW5jeSBV bmljb2RlDQo+ID4gdmFyaWFudCBvZiBhIHF1b3RlLCBkb3VibGUgcXVvdGUsIGRhc2gsIHBlcmlv ZCBhbmQgc3VjaCBsaWtlLg0KPiA+DQo+ID4gQW55dGhpbmcgdGhhdCBzdGFydHMgYXMgTWljcm9z b2Z0IFdvcmQgaXMgbGlrZWx5IHRvIGJlIHVuaW50ZWxsaWdpYmxlLg0KPiA+DQo+ID4gVG9tIFBl dGNoDQo+ID4NCj4gPiA+IEpvbmF0aGFuDQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1ZXJnZW4NCj4gPiA+ID4gU2Nob2Vud2Fl bGRlcg0KPiA+ID4gPiBTZW50OiAwMyBEZWNlbWJlciAyMDE2IDA4OjUwDQo+ID4gPiA+IFRvOiBF cmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPg0KPiA+ID4gPiBDYzogbmV0Y29uZkBp ZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIDUyNzcgQmFja3dhcmRzIENv bXBhdGliaWxpdHk6IGhvdyB0byBkZWxpdmVyDQo+ID4gPiA+DQo+ID4gPiA+IEhpLA0KPiA+ID4g Pg0KPiA+ID4gPiBJIGNhbid0IGZvbGxvdyBkaXNjdXNzaW9ucyBpZiBwZW9wbGUgdXNlIGVtYWls IGNsaWVudHMgdGhhdCBkbyBub3QNCj4gPiBkbyBwcm9wZXINCj4gPiA+ID4gcXVvdGF0aW9ucy4g aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUG9zdGluZ19zdHlsZQ0KPiA+ID4gPg0KPiA+ ID4gPiAvanMNCj4gPiA+ID4NCj4gPiA+ID4gT24gRnJpLCBEZWMgMDIsIDIwMTYgYXQgMTE6NDk6 MTFQTSArMDAwMCwgRXJpYyBWb2l0IChldm9pdCkgd3JvdGU6DQo+ID4gPiA+ID4gRnJvbTogTWFo ZXNoIEpldGhhbmFuZGFuaSwgRGVjZW1iZXIgMiwgMjAxNiA2OjIwIFBNDQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBbQ2hhaXIgaGF0IG9mZl0NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEVyaWMsDQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBXaGF0IHdvdWxkIGhlbHAgaXMgdG8gdW5kZXJzdGFuZCB3aGF0IHRo ZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5DQo+ID4gc2VjdGlvbg0KPiA+ID4gPiB3b3VsZCBsb29r IGxpa2Ugd2l0aCB5b3VyIHByb3Bvc2FsLiBDdXJyZW50bHkgaXQgc2F5cyB0aGF0IDUyNzdiaXMN Cj4gPiB3aWxsDQo+ID4gPiA+IGFkdmVydGlzZSAidXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2Fw YWJpbGl0eTpub3RpZmljYXRpb246MS4w4oCdIGFuZA0KPiA+ID4gPiAidXJuOmlldGY6cGFyYW1z Om5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4x4oCdLiBDbGllbnRzIGNhbg0KPiA+ IHRoZW4gY2hvb3NlDQo+ID4gPiA+IHdoaWNoIGNhcGFiaWxpdHkgdGhleSBhcmUgY2FwYWJsZSBv ZiBhbmQgd2FudCB0byBzdXBwb3J0LiBXaXRoIHRoZQ0KPiA+IG5ldw0KPiA+ID4gPiBwcm9wb3Nh bCwgYXJlIHdlIGRyb3BwaW5nIGFkdmVydGlzZW1lbnQgb2YNCj4gPiA+ID4gInVybjppZXRmOnBh cmFtczpuZXRjb25mOmNhcGFiaWxpdHk6bm90aWZpY2F0aW9uOjEuMOKAnT8NCj4gPiA+ID4gPg0K PiA+ID4gPiA+IFllcy4gIEFueW9uZSB3aG8gd2FudHMgdG8gdXNlIGV4aXN0aW5nIDUyNzcgd291 bGQganVzdCBsZXZlcmFnZSB0bw0KPiA+IHRoZSBvbGQNCj4gPiA+ID4gbmFtZXNwYWNlLg0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gSWYgdGhlIG5hbWVzcGFjZXMgYXJlIHRydWx5IGRpZmZlcmVudCwg YW5kIHRoZSBzZXJ2ZXIgYWxyZWFkeQ0KPiA+IHN1cHBvcnRzDQo+ID4gPiA+IDUyNzcsIHdoYXQg d291bGQgYmUgdGhlIGltcGxpY2F0aW9uIG9mIGhhdmluZyB0d28NCj4gPiA8Y3JlYXRlLXN1YnNj cmlwdGlvbj4sIGluDQo+ID4gPiA+IHR3byBkaWZmZXJlbnQgbmFtZXNwYWNlcz8NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IFRoZXJlIHdvdWxkIGJlIG5vIDxjcmVhdGUtc3Vic2NyaXB0aW9uPiBpbiAx LjEuICAgV2l0aCA1Mjc3YmlzIHRoZQ0KPiA+ID4gPiByZWNvbW1lbmRlZCBSUEMgZ29pbmcgZm9y d2FyZCBpcyA8ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbj4uICBJbiB0aGlzDQo+ID4gd2F5DQo+ID4g PiA+IGV2ZXJ5dGhpbmcgc3RheXMgaW5kZXBlbmRlbnQuICBCdXQgYSBzZXJ2ZXIgY291bGQgY2hv c2UgdG8gc3VwcG9ydA0KPiA+IGJvdGggMS4wDQo+ID4gPiA+ICYgMS4xLiAgIFRoaXMgZ2l2ZXMg YmFja3dhcmRzIGNvbXBhdGliaWxpdHkgaW4gYSBzaW5nbGUgZGVwbG95bWVudC4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IFtDaGFpciBoYXQgb25dDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBFY2hvaW5n IHdoYXQgTWVobWV0IGhhcyBhbHJlYWR5IHNhaWQuIFRoaXMgaXMgZXNzZW50aWFsbHkgYSBXRw0K PiA+IGNhbGwuIElmIHlvdQ0KPiA+ID4gPiBsaWtlL2RvIG5vdCBsaWtlIHRoaXMgcHJvcG9zYWws IG9yIGhhdmUgcXVlc3Rpb25zIGFib3V0IGl0LCB0aGlzDQo+ID4gd291bGQgYmUgdGhlDQo+ID4g PiA+IHRpbWUgdG8gc3BlYWsgdXAuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIGFtIGFic29sdXRl bHkgZ29vZCB0byBnbyB3aXRoIHdoYXRldmVyIHRoZSBXRyBkZWNpZGVzLiAgIEkgZG8NCj4gPiBi ZWxpZXZlDQo+ID4gPiA+IHRoYXQgb2Jzb2xldGluZyA1Mjc3IG1ha2VzIHNwZWNpZmljYXRpb24g YW5kIGltcGxlbWVudGF0aW9uIHNpbXBsZXIsDQo+ID4gd2l0aA0KPiA+ID4gPiBubyBtZWFuaW5n ZnVsIGxvc3Mgb2YgZnVuY3Rpb25hbGl0eS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEVyaWMNCj4g PiA+ID4gPg0KPiA+ID4gPiA+IENoZWVycy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9uIERlYyAy LCAyMDE2LCBhdCAxMjo0MyBQTSwgTWVobWV0RXJzdWUNCj4gPiA+ID4gPG1lcnN1ZUBnbWFpbC5j b208bWFpbHRvOm1lcnN1ZUBnbWFpbC5jb20+PiB3cm90ZToNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IEhpIEVyaWMsIEFsbCwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IHllcywgd2UgbmVlZCBhIGNoYXJ0 ZXIgY2hhbmdlIHNpbmNlIHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuDQo+ID4gPiA+IGVu aGFuY2luZyBhbmQgcmVwbGFjaW5nLg0KPiA+ID4gPiA+IEFzIEkgcmVtZW1iZXIgdGhlIGNoYXJ0 ZXIgZGlzY3Vzc2lvbiBwZW9wbGUgd2VyZSBrZWVuIG9mIGhhdmluZw0KPiA+ID4gPiBiYWNrd2Fy ZHMgY29tcGF0aWJpbGl0eSBiZWNhdXNlIG9mIGRlcGxveWVkIGltcGxlbWVudGF0aW9ucy4NCj4g PiA+ID4gPg0KPiA+ID4gPiA+IEkgYmVsaWV2ZSB3ZSBuZWVkIHRvIHVuZGVyc3RhbmQgYmV0dGVy IHRoZSBpbXBsaWNhdGlvbnMgYW5kIHdoYXQNCj4gPiBraW5kIG9mDQo+ID4gPiA+ICJyZXBsYWNp bmciIHdlIHdvdWxkIHN0cml2ZSBmb3IuDQo+ID4gPiA+ID4gRG9lcyByZXBsYWNpbmcgbWVhbiBm dWxsIGRlcHJlY2F0aW9uIG9mIDUyNzcgb3Igd2lsbCB0aGUNCj4gPiBjb21wYXRpYmlsaXR5DQo+ ID4gPiA+IGJldHdlZW4gZS5nLiBvbGQgY2xpZW50IGFuZCBuZXcgc2VydmVyIGJlIHBvc3NpYmxl Pw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBiZWxpZXZlIHdlIG5lZWQgYSBkaXNjdXNzaW9uIG9u IHRoaXMgb24gdGhlIG1haWxsaXN0IGFuZCBnZXQgdGhlDQo+ID4gb3BpbmlvbiBvZg0KPiA+ID4g PiBhbGwgcGFydGllcy4NCj4gPiA+ID4gPiBBdCB0aGUgZW5kIHRoZSBXRyB3aWxsIGRlY2lkZS4N Cj4gPiA+ID4gPiBAQWxsOg0KPiA+ID4gPiA+IFBsZWFzZSBjb21tZW50IG9uIHJlcGxhY2luZyBp bnN0ZWFkIG9mIGVuaGFuY2luZyA1Mjc3Lg0KPiA+ID4gPiA+IFBsZWFzZSBleHBsYWluIHdoeSB5 b3UgYXJlIGluIGZhdm9yIG9mIHJlcGxhY2luZyBvciBhZ2FpbnN0Lg0KPiA+ID4gPiA+IElmIHlv dSBhcmUgaW4gZmF2b3IgcGxlYXNlIGV4cGxhaW4gd2hhdCBraW5kIG9mIHJlcGxhY2luZyAoaS5l Lg0KPiA+IGNvbXBhdGliaWxpdHkNCj4gPiA+ID4gbGV2ZWwpIHlvdSB3b3VsZCBsaWtlIHRvIGhh dmUuDQo+ID4gPiA+ID4gSWYgeW91IGFyZSBpbiBmYXZvciBvZiBrZWVwaW5nIDUyNzcgYXMgc3Rh bmRhcmQgYW5kIGRldmVsb3BpbmcgYW4NCj4gPiBhZGRpdGlvbmFsDQo+ID4gPiA+IGluZGVwZW5k ZW50IG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gcGxlYXNlIG1ha2UgaXRzIGNhc2UuDQo+ID4gPiA+ ID4gVGhhbmtzLA0KPiA+ID4gPiA+IE1laG1ldA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24gVGh1 LCBEZWMgMSwgMjAxNiBhdCAyOjI3IEFNLCBFcmljIFZvaXQgKGV2b2l0KQ0KPiA+ID4gPiA8ZXZv aXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5jb20+PiB3cm90ZToNCj4gPiA+ID4gPiBI aSBNZWhtZXQsDQo+ID4gPiA+ID4gSGkgTWFoZXNoLA0KPiA+ID4gPiA+IEhpIEJlbm9pdCwNCj4g PiA+ID4gPg0KPiA+ID4gPiA+IEl0ZW0gIzYgaW4gdGhlIE5FVENPTkYgY2hhcnRlciBpczog4oCc RW5oYW5jZSBSRkMgNTI3NyB3aXRoIHRoZQ0KPiA+IGFiaWxpdHkgdG8NCj4gPiA+ID4gZGVsZXRl IHN1YnNjcmlwdGlvbnMgd2l0aG91dCBjbG9zaW5nIHRoZSBjbGllbnQgc2Vzc2lvbiwgdG8gbW9k aWZ5DQo+ID4gZXhpc3RpbmcNCj4gPiA+ID4gc3Vic2NyaXB0aW9ucywgYW5kIHRvIGhhdmUgbXVs dGlwbGUgc3Vic2NyaXB0aW9ucyBvbiBhbiBlc3RhYmxpc2hlZA0KPiA+IGNsaWVudA0KPiA+ID4g PiBzZXNzaW9uLiBUaGVzZSBjaGFuZ2VzIHNob3VsZCBub3QgYWZmZWN0IG9sZGVyIGNsaWVudHMg dGhhdCBkbyBub3QNCj4gPiBzdXBwb3J0DQo+ID4gPiA+IHRoZXNlIHBhcnRpY3VsYXIgc3Vic2Ny aXB0aW9uIHJlcXVpcmVtZW50cy4gVGhlIFJQQ3MgYW5kIHRoZSBkYXRhDQo+ID4gbW9kZWxzIGlu DQo+ID4gPiA+IFJGQyA1Mjc3IHNob3VsZCBiZSBjb252ZXJ0ZWQgdG8gWUFORy7igJ0NCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IFRob3NlIGF0dGVuZGluZyB0aGUgRXZlbnQgTm90aWZpY2F0aW9uIERl emlnbiBUZWFtIHRvZGF5IGJlbGlldmUNCj4gPiB0aGF0IGl0IGlzDQo+ID4gPiA+IGJldHRlciB0 byBPYnNvbGV0ZSA1Mjc3IGl0IHJhdGhlciB0aGFuIEVuaGFuY2UgaXQuICAgVGhlIG1haW4NCj4g PiByZWFzb25zIGFyZToNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IOKAoiAgICAgICBUaGUgZXhpc3Rp bmcgNTI3NyA8Y3JlYXRlIHN1YnNjcmlwdGlvbj4gcnBjIGFuZCB0aGUgbmV3DQo+ID4gcnBjcyBu ZWVkIHRvDQo+ID4gPiA+IGJlIGluIGluZGVwZW5kZW50IG5hbWVzcGFjZXMuIE5vdCBzdXBwb3J0 aW5nIDUyNzcgPGNyZWF0ZQ0KPiA+IHN1YnNjcmlwdGlvbj4NCj4gPiA+ID4gYW5kIGEgc2VwYXJh dGUgbmFtZXNwYWNlIC8gbW9kZWwgd2lsbCBzaWduaWZpY2FudGx5IHNpbXBsaWZ5IHRoZSBuZXcN Cj4gPiA+ID4gc3BlY2lmaWNhdGlvbi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IOKAoiAgICAgICBX ZSBjYW7igJl0IHRoaW5rIG9mIGEgcmVhc29uIHdoeSBhbnkgWUFORyBtb2RlbCBkZXZlbG9wZWQN Cj4gPiBmb3IgbGVnYWN5DQo+ID4gPiA+IDUyNzcgbmFtZXNwYWNlIHNob3VsZCBiZSBkZXZlbG9w ZWQuICBOZXcgZGV2ZWxvcG1lbnQgaXMgbW9yZSBsaWtlbHkNCj4gPiB0bw0KPiA+ID4gPiBmb2N1 cyBvbiB0aGUgbmV3IG1vZGVsIGFuZCBpdHMgbmV3IGNhcGFiaWxpdGllcw0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4g4oCiICAgICAgIEFueSBjbGllbnRzICYgc2VydmVycyBkZXNpcmluZyB0byBzdXBw b3J0IHRoZSBvbGQNCj4gPiBjYXBhYmlsaXRpZXMgY2FuDQo+ID4gPiA+IGNlcnRhaW5seSBkbyB0 aGlzLiAgSW5kZXBlbmRlbnQgY2FwYWJpbGl0eSBzZXRzIGNhbiBiZSBhZHZlcnRpc2VkLg0KPiA+ IEJhY2t3YXJkcw0KPiA+ID4gPiBjb21wYXRpYmlsaXR5IGlzIG5vdCBjb21wcm9taXNlZC4NCj4g PiA+ID4gPg0KPiA+ID4gPiA+IOKAoiAgICAgICBMZWF2aW5nIGJhY2t3YXJkcyBjb21wYXRpYmls aXR5IHRvIGVtYmVkZGVkIHNlcnZlciBjb2RlDQo+ID4gPiA+IHNpZ25pZmljYW50bHkgcmVkdWNl cyBuZXcgZGV2ZWxvcG1lbnQgbmVlZHMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBBcyBvYnNvbGV0 aW5nIDUyNzcgd2l0aCB0aGlzIG5ldyBzcGVjIGlzIGEgc2lnbmlmaWNhbnQgc3RlcCwgd2UNCj4g PiB3YW50ZWQgdG8NCj4gPiA+ID4gZ2V0IHlvdXIgYW5kIHRoZSBjb21tdW5pdHnigJlzIGZlZWRi YWNrIGFuZCBidXktaW4gYmVmb3JlIHdlIG1vZGlmeQ0KPiA+IGFueSBvZg0KPiA+ID4gPiB0aGUg ZG9jdW1lbnRzIGluIHRoaXMgZGlyZWN0aW9uLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gV291bGQg c3VjaCBhIG1vdmUgbWVhbiBhIGNoYXJ0ZXIgY2hhbmdlPyAgIE15IHN1c3BpY2lvbiBpcyBubyBh cw0KPiA+IHdlIGFyZQ0KPiA+ID4gPiBlbmhhbmNpbmcgdGhlIGZ1bmN0aW9ucyBzdXBwb3J0ZWQg YnkgNTI3NyAoYnV0IHdpdGhvdXQgYnJpbmdpbmcNCj4gPiBhbG9uZyB0aGUNCj4gPiA+ID4gUlBD KS4gIERvIHlvdSBoYXZlIGFueSBndWlkYW5jZSBoZXJlPyAgIElzIHRoaXMgd29ydGggaGF2aW5n IGFuDQo+ID4gaW50ZXJpbQ0KPiA+ID4gPiBtZWV0aW5nIHRvIGRpc2N1c3MgYW5kIGZpbmFsaXpl Pw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhhbmtzLA0KPiA+ID4gPiA+IEVyaWMNCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IFAuUy46IEFkZGl0aW9uYWwgZGlzY3Vzc2lvbiBvbiB0aGlzIGlzIGNvbnRh aW5lZCBpbiBtaW51dGVzIDIgdG8xNQ0KPiA+IG1pbnV0ZXMgb2YNCj4gPiA+ID4gdGhlIFdlYkV4 IGF1ZGlvIHJlY29yZGluZyBiZWxvdy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEZyb206IEVyaWMg Vm9pdCwgTm92ZW1iZXIgMzAsIDIwMTYgNTo1OCBQTSBNaW51dGVzIHBvc3RlZCBhdDoNCj4gPiA+ ID4gPiBodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy95YW5nLXB1c2gvd2lraS9NaW51dGVz LTIwMTYtMTEtMzANCj4gPiA+ID4gPg0KPiA+ID4gPiA+IOKAoiAgICAgICAgQXMgYWx3YXlzLCBv dXIgRGV6aWduVE0gVGVhbSBpcyBhIGdhdGhlcmluZyBvZg0KPiA+IGluZGl2aWR1YWxzIHByb3Zp ZGluZw0KPiA+ID4gPiBpbmZvcm1hbCBpbnB1dCB0byBORVRDT05GLiBXZSBhc2sgTkVUQ09ORiBX RyB0byBjb21tZW50IG9uIG91cg0KPiA+ID4gPiBkaXNjdXNzaW9uIHJlc3VsdHMgYXMgYSBwcmVw YXJhdGlvbiBmb3IgdGhlIFdHIGNvbnNlbnN1cy4gUGxlYXNlDQo+ID4gYXBwcm9hY2gNCj4gPiA+ ID4gRXJpYyBWb2l0IGlmIHlvdSB3YW50IHRvIGJlIGluY2x1ZGVkIGRpcmVjdGx5IGluIHRoZXNl IG1lZXRpbmdzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gTWVldGluZyBNYXRlcmlhbHMNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IEF0dGVuZGluZw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gV2ViRXgNCj4g PiA+ID4gPg0KPiA+ID4gPg0KPiA+IFJlY29yZGluZzxodHRwczovL2Npc2NvLndlYmV4LmNvbS9j aXNjb3NhbGVzL2xzci5waHA/UkNJRD04N2NkZTI0NTI5M2MNCj4gPiA+ID4gPiA0N2RkOGNmZjM3 NzI3MzlmNjZjND4NCj4gPiA+ID4gPiBwYXNzd29yZDogYlhldmVGVjUNCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IEFuZHkgQmllcm1hbiwgQWxleGFuZGVyIENsZW1tLCBBbWJpa2EgVHJpcGF0aHksIEVp bmFyDQo+ID4gTmlsc2VuLU55Z2FhcmQsDQo+ID4gPiA+ID4gRXJpYyBWb2l0LCBUaW0gSmVua2lu cywgQmFsYXpzIExlbmd5ZWwsIFN1c2FuIEhhcmVzIEFtYmlrYQ0KPiA+IFRyaXBhdGh5LA0KPiA+ ID4gPiA+IFNoYXJvbiBDaGlzaG9sbQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT2Jzb2xldGUgUkZD NTI3NyBvciA1Mjc3YmlzPw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAqICAgSWYgeW91IGFyZSBn b2luZyB0byBzdXBwb3J0IGJvdGggb2xkIGFuZCBuZXcgY2FwYWJpbGl0aWVzLA0KPiA+IHlvdSB3 aWxsIGhhdmUNCj4gPiA+ID4geW91ciBvbGQgNTI3NyBjb2RlLCBhbmQgeW91IHdpbGwgaGF2ZSB5 b3VyIG5ldyBjb2RlLiBXaHkgZGV2ZWxvcCBhDQo+ID4gPiA+IGJhY2t3YXJkcyBjb21wYXRpYmxl IHBhcnQgb2YgdGhlIHNwZWMgd2hpY2ggbm8gb25lIHdvdWxkIG9yIHNob3VsZA0KPiA+ID4gPiBp bXBsZW1lbnQuIFBlb3BsZSBzaG91bGQgZGV2ZWxvcCB0byB0aGUgbmV3IGNhcGFiaWxpdHkuDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiAgICAgICogICA1Mjc3IGFscmVhZHkgaGFzIGVub3VnaCBjaGFu Z2VzIHRvIGl0IChlLmcuLCBkYXRhcGxhbmUNCj4gPiBoYXMgbW92ZWQgdG8NCj4gPiA+ID4gNjI0 MSBmaWx0ZXJlZCBub3RpZmljYXRpb25zKQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAqICAgUmVj b21tZW5kYXRpb24gZm9yIHBlb3BsZSBvbiB0b2RheSdzIGNhbGwgaXMgdG8gT2Jzb2xldGUNCj4g PiA1Mjc3DQo+ID4gPiA+ID4gICAqICAgTXVzdCBnbyB0byB0aGUgV0csIGl0cyBjaGFpcnMsIGFu ZCBCZW5vaXQgdG8gY29uZmlybSB0aGlzDQo+ID4gPiA+IHJlY29tbWVuZGF0aW9uIGJlZm9yZSB3 ZSBhZGp1c3QgY3VycmVudCBkb2N1bWVudGF0aW9uDQo+ID4gPiA+ID4gQ2hhbmdlcyB0byB0aGUg ZG9jdW1lbnRzIGRpc2N1c3NlZCB0b2RheSBbNTI3N2Jpc10NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ ICAgKiAgIFNjcnViIGZvciBlcnJvciB0eXBlcyBpbiB2YXJpb3VzIHN1YnNjcmlwdGlvbiBzdGF0 ZXMuDQo+ID4gQXV0aG9yaXphdGlvbiBhbmQNCj4gPiA+ID4gb3RoZXIgZXJyb3JzIHNob3VsZCBi ZSByZXBvcnRlZCB1c2luZyB0aGUgcHJvdG9jb2wtc3BlY2lmaWMgZXJyb3INCj4gPiBjb2Rlczsg bm90DQo+ID4gPiA+IHNwZWNpYWxpemVkIGVycm9ycyBwZXIgdGhlc2UgbmV3IFJQQ3MuIFRoZXkg c3RpbGwgbmVlZCB0byBiZQ0KPiA+IGlkZW50aWZpZWQNCj4gPiA+ID4gdGhvdWdoLiBEaXN0aW5n dWlzaCBlcnJvciB0eXBlcyBmcm9tIHN1YnNjcmlwdGlvbiBzdGF0ZSBzbyB0aGF0IHlvdQ0KPiA+ IGtub3cgdGhlDQo+ID4gPiA+IHN0YXRlIGEgcGFydGljdWxhciBlcnJvciBoYXBwZW5lZCBkdXJp bmcuDQo+ID4gPiA+ID4gICAqICAgRXhwb3NlIG9wZXJhdGlvbmFsIHN0YXRlIG9mIHN1YnNjcmlw dGlvbnMgaW4gYSBzZXBhcmF0ZSBZQU5HDQo+ID4gbW9kZWwgb3INCj4gPiA+ID4gY29udGFpbmVy LiAoaS5lLiwgYWRkIOKAnC1zdGF0ZeKAnSBpbnRvIG5hbWluZyBjb252ZW50aW9uIGZvciB0aGUg cm8NCj4gPiBwYXJ0KQ0KPiA+ID4gPiA+ICAgKiAgIFNob3VsZCBzdWJzY3JpcHRpb24taWQgYW5k IGZpbHRlci1pZCBib3RoIGJlIGlkPw0KPiA+IChkb3VibGUtY2hlY2ssIGJ1dCB3ZQ0KPiA+ID4g PiBjYW4gZG8gdG8gdGhlIHNob3J0ZXIgZGVzY3JpcHRpb24g4oCcaWRlbnRpZmllcuKAnSkNCj4g PiA+ID4gPiAgICogICBEbyB3ZSByZW5hbWUgcHVzaC1zb3VyY2UgdG8g4oCcb3JpZ2luYXRlcyBm cm9t4oCdIHRvIGJlIG1vcmUNCj4gPiA+ID4gZXhwbGljaXQvYWNjdXJhdGU/IChiZXR0ZXIgbmFt ZSBpcyBuZWVkZWQuIEluY2x1ZGUgaXQgaW4gdGhlDQo+ID4gdGVybWlub2xvZ3kNCj4gPiA+ID4g c2VjdGlvbi4pDQo+ID4gPiA+ID4gICAqICAgU2VjdGlvbiAyLjMgaGFzIFNIT1VMRCBmb3IgNTI3 NyBmaWx0ZXJzLiBOb3Qgc3VyZSB3aHkgdGhpcw0KPiA+IGlzbuKAmXQgYSBNVVNULg0KPiA+ID4g PiBBbHNvIHdlIG5lZWQgYSBiZXR0ZXIgbmFtZSBmb3IgNTI3NyBmaWx0ZXJzLiBUaGlzIG5hbWUg ZG9lc27igJl0DQo+ID4gZXhwb3NlIHdoYXQNCj4gPiA+ID4gaXMgcG9zc2libGUsIGFuZCB3aGF0 IGlzIG5vdC4gRXNwZWNpYWxseSBpZiB3ZSBqZXR0aXNvbiA1Mjc3DQo+ID4gY29tcGF0aWJpbGl0 eSwgd2UNCj4gPiA+ID4gbmVlZCBhIGJldHRlciBuYW1lIGZvciA2MjQxLCBhbmQgd2UgbmVlZCB0 byBkZWZpbmUgdGhlIGJvdW5kYXJpZXMgb2YNCj4gPiBmaWx0ZXINCj4gPiA+ID4gc29sdXRpb24u IEFuZHkgaGFzIGEgc3RyYXdtYW4gcHJvcG9zYWwuDQo+ID4gPiA+ID4gICAqICAgRGVsZXRlIGNy ZWF0ZS1zdWJzY3JpcHRpb24gUlBDIGFuZCBsZWdhY3kgbmFtZXNwYWNlIHNob3VsZA0KPiA+IFdH DQo+ID4gPiA+IGFncmVlLg0KPiA+ID4gPiA+ICAgKiAgIERvIHdlIGRvIGEgdGVzdC1vbmx5IG9w ZXJhdGlvbj8gKExldOKAmXMgbm90IGRvIHRoaXMgd29yaw0KPiA+IHdpdGhvdXQgYW4NCj4gPiA+ ID4gYWR2b2NhdGUpDQo+ID4gPiA+ID4gICAqICAgV2UgbmVlZCBhIHdheSB0byB0ZXN0IGlmIHRo ZSBmaWx0ZXJzIGFyZSBkb2luZyB3aGF0IHdlDQo+ID4gZXhwZWN0IHRoZXkgYXJlDQo+ID4gPiA+ IGRvaW5nLiAoUGVyaGFwcyBjb3VudGVycy9jYXB0dXJlcyBvbiBhbiBhY3RpdmUgc3Vic2NyaXB0 aW9uPykNCj4gPiA+ID4gPiAgICogICBGb3IgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zLCBtYWtl IHJlY2VpdmVyIGtleSBpcCBhZGRyZXNzDQo+ID4gYW5kIHBvcnQuIEF0DQo+ID4gPiA+IHRoaXMg cG9pbnQgd2UgZG9u4oCZdCB3YW50IFZSRg0KPiA+ID4gPiA+ICAgKiAgIENoYW5nZSBzb3VyY2Ut dnJmIGRlc2NyaXB0aW9uIHRvIGluZGljYXRlIHRoYXQgd2Ugc2hvdWxkDQo+ID4gYWxpZ24gd2l0 aA0KPiA+ID4gPiBuYW1lcyBmcm9tIGRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwtMDEgc2hvdWxk IGl0IGNvbXBsZXRlIGluIHRpbWUuDQo+ID4gPiA+ID4gICAqICAgc3RhcnQtdGltZSBpbiB0aGUg WUFORyBtb2RlbCBmcm9tIHN0YXJ0VGltZSBhcyB3ZSBkb27igJl0IGhhdmUNCj4gPiB0byB3b3Jy eQ0KPiA+ID4gPiBhYm91dCBiYWNrd2FyZHMgY29tcGF0aWJsZSBSUEMuDQo+ID4gPiA+ID4gICAq ICAgTWFrZSBzdHJlYW0gdHlwZSBzdHJpbmcgcmF0aGVyIHRoYW4gaWRlbnRpdHkgKHByZWZlcmVu Y2UgZm9yDQo+ID4gaWRlbnRpdHksDQo+ID4gPiA+IGJ1dCBub3Qgd2lsbGluZyB0byBmaWdodC4g Tm90ZTogdGhpcyBjb3VsZCBjaGFuZ2UgYmFzZWQgb24gd2hhdA0KPiA+IGhhcHBlbnMgd2l0aA0K PiA+ID4gPiBmaWx0ZXJzKQ0KPiA+ID4gPiA+IFtZYW5nLXB1c2hdDQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiAgICogICBOZWVkIHRvIGRlZmluZSBlcnJvciB0eXBlIGZvciBlYWNoIHN1YnNjcmlwdGlv biBwYXJhbWV0ZXINCj4gPiBzdWNoIGFzDQo+ID4gPiA+IOKAnGVuY29kaW5nIG5vdCBkZWZpbmVk 4oCdLCDigJxGaWx0ZXIgc3ludGF4IG5vdCBzdXBwb3J0ZWTigJ0gb3Ig4oCcZmlsdGVyDQo+ID4g Y29tcGxleGl0eQ0KPiA+ID4gPiBub3Qgc3VwcG9ydGFibGUgYnkgcGxhdGZvcm3igJ0uDQo+ID4g PiA+ID4gICAqICAgU2VjdGlvbiAzLjEg4oCTIERpc2N1c3Npb24gb24gdGhlIEVkaXRvcnMgbm90 ZSAtIHRoZSBhZGRpdGlvbg0KPiA+IG9mIGENCj4gPiA+ID4g4oCcY2hhbmdlcy1vbmx54oCdIGZs YWcgZm9yIGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uLiAoU29tZSBzdXBwb3J0IGZvcg0KPiA+IHRo aXMsIGJ1dA0KPiA+ID4gPiBtb3JlIGRpc2N1c3Npb24gaXMgbmVlZGVkIGFzIHRoZSB3b3JrIGlz IG5vbi10cml2aWFsLikNCj4gPiA+ID4gPiAgICogICBTZWN0aW9uIDMuOC40IOKAkyByZWNvbW1l bmQgcmVtb3ZhbCAob2spDQo+ID4gPiA+ID4gICAqICAgU2VjdGlvbiA0LjQ6IHJlZHVjZSB0aGlz IGp1c3QgdG8gdGhlIG5ldyBwYXJhbWV0ZXJzIChjYW4gd2UNCj4gPiByZW1vdmUNCj4gPiA+ID4g dGhpcyBlbnRpcmVseSBjb25zaWRlcmluZyBzZWN0aW9uIDMuMT8gT3IgZG8gd2UgbWVyZ2UgMy4x IGludG8NCj4gPiBoZXJlPykgKEVyaWMgdGFsaw0KPiA+ID4gPiB0byBBbGV4LCBsaWtlbHkgb2sp DQo+ID4gPiA+ID4gICAqICAgU2VjdGlvbiA0LjYuMiBJcyB0aGVyZSBhbnkgcmVhc29uIHdoeSB3 ZSBjYW7igJl0IGhhdmUgdGhlDQo+ID4gdGltZXN0YW1wIG9uDQo+ID4gPiA+IHRoZSB5YW5nIHB1 c2ggaW5jbHVkZSB0aGUgbnVtYmVyIG9mIHNpZ25pZmljYW50IGRpZ2l0cyBhcyBleHByZXNzZWQN Cj4gPiBieSB0cmFpbGluZw0KPiA+ID4gPiB6ZXJvcyBpZiBuZWNlc3Nhcnkgb24gdGhlIOKAnHRp bWUtb2YtdXBkYXRl4oCdLiBUaGlzIHdvdWxkIGxldCBwbGF0Zm9ybXMNCj4gPiBleHByZXNzDQo+ ID4gPiA+IHdoYXQgdGhleSBhcmUgY2FwYWJsZSBvZiBkb2luZy4gKE5vdGU6IHNlY29uZHMgd291 bGQgYmUgYSBtaW5pbXVtDQo+ID4gPiA+IGdyYW51bGFyaXR5KS4gKHdlIHNob3VsZCBnbyB3aXRo IHRoaXMgaWYgcG9zc2libGUuIFN1c2FuIEguIGlzIGdvaW5nDQo+ID4gdG8gY2hlY2sgb24NCj4g PiA+ID4gYmluYXJ5IHJlcHJlc2VudGF0aW9ucyBoZXJlIHRvIHNlZSBpZiB2YXJpYWJsZSBmaWVs ZCBsZW5ndGhzIG1pZ2h0DQo+ID4gcG9zZSBhDQo+ID4gPiA+IHByb2JsZW0gZm9yIGFuIHVwZGF0 ZS4pDQo+ID4gPiA+ID4gICAqICAgU2VjdGlvbiA0LjYuMiBEbyB3ZSBkbyBzb21ldGhpbmcgb24g WUFORy1QdXNoIHN0YXRpc3RpY3MNCj4gPiAoZS5nLg0KPiA+ID4gPiBjb3VudGVycyBvZiBvYmpl Y3QgY2hhbmdlcywgb2YgdXBkYXRlIG1lc3NhZ2VzKT8gKEJvdGjigKYgVGVzdCBhbmQNCj4gPiBu b3JtYWwNCj4gPiA+ID4gb3BlcmF0aW9ucyBuZWVkIHRvIGJlIGNvdmVyZWQuLiBNYXRjaCB0byBm aWx0ZXJzIHdvcmtpbmcgb3BlcmF0aW9uDQo+ID4gcXVlc3Rpb24pDQo+ID4gPiA+ID4gRGFtcGVu aW5nOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAqICAgRGFtcGVuIGNhbiBtZWFuIGxlc3Nlbi4g V2Ugc2hvdWxkIGNob29zZSBEYW1wIG9yIERhbXBlbg0KPiA+IGJhc2VkDQo+ID4gPiA+IG9uIHVz YWdlIHRoZXJlZm9yZS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgICAgKiAgIEdvb2dsZSBzZWFy Y2ggZm9yIOKAnHJvdXRlIGRhbXBpbmfigJ0gPSA0LDg1MCBoaXRzLg0KPiA+ID4gPiA+ICAgICAg KiAgIEdvb2dsZSBzZWFyY2ggZm9yIOKAnHJvdXRlIGRhbXBlbmluZ+KAnSA9IDExLDYwMCBoaXRz DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAgICogICBUaGUgbW9yZSBjb21tb24gdXNhZ2UgaXMgZGFt cGVuaW5nLCBzbyB3ZSBzaG91bGQgc3RpY2sgd2l0aA0KPiA+IHRoYXQuDQo+ID4gPiA+ID4NCj4g PiA+ID4gPg0KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gPiA+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBOZXRj b25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiA+ID4gPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IC0tDQo+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+ IE1laG1ldA0KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gPiA+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBOZXRj b25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiA+ID4gPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gTWFoZXNoIEpldGhhbmFuZGFuaQ0KPiA+ID4gPiA+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29t PG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4g PiA+ID4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAtLQ0KPiA+ ID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJy ZW1lbiBnR21iSA0KPiA+ID4gPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyA8MDQyMSUyMDIwMDM1 ODc+ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8DQo+ID4gMjg3NTkgQnJlbWVuIHwNCj4gPiBHZXJt YW55DQo+ID4gPiA+IEZheDogICArNDkgNDIxIDIwMCAzMTAzIDwwNDIxJTIwMjAwMzEwMz4gICAg ICAgICA8DQo+ID4gaHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+ID4gPiA+DQo+ ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gPiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4g PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4g Pg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gPiBOZXRjb25mQGlldGYub3JnDQo+ID4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPiA+DQo+ ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+DQo+IC0tIA0KPiBD aGVlcnMsDQo+IE1laG1ldA0K From nobody Mon Dec 5 09:19:13 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23577129BBD for ; Mon, 5 Dec 2016 09:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBgA18EHnh_h for ; Mon, 5 Dec 2016 09:19:08 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99641129B66 for ; Mon, 5 Dec 2016 09:19:01 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id p16so319737977qta.0 for ; Mon, 05 Dec 2016 09:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=GrlVtn64V+KfhvGzWcUmZb7R9WHd7OuHs8FTvWf+r0Y=; b=0uxG01vcL0NEqk2uqYUI/ItthuC7RBC5hYlNaT+iomGQD81WfjweH4u9Pa8VnfUGRT q0GGAs9H5LyOL4k5y6VmvST8BgZY/+3ptUlcld5HIpBhWUZeFdtQVh5nTMZYHfxh+pg3 b6WPuenhvey75o+FuREV796zseoEXOcZ+wDXMSuLY1LsamlxlsNASMZNQyevSqXn0t3Q UE9xGXzylqSRP/7NsaspUvdhlbvywsZT1dI44Pq8b9aJYdErnElQtujdFcclKhPEDeHH ARMVre+EmIpFMSPJN92j9D7J+vdg0CiMUTnvGCZTD8ULoZfdD4z9ClcPLterjv0TX9TP m3BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=GrlVtn64V+KfhvGzWcUmZb7R9WHd7OuHs8FTvWf+r0Y=; b=h2ww/zEA8tDPEIvtGaRgHIXln7U3Tx2GATQ5RD5ZmBdZEo9EcjdZNimrqwgT8K+fDa iBVLCSd6KYDOxkpiyYy2tthJ3caXuyse0IQDQBguFi1BdWuxupwbDdzPkakH1YbVqQJf vQnpoVOSgi3myTEDonAGQ9KFKf8UdQ6mQqMvY0Wn+o3HPlkC/Q5Prj3c5fhzzzQibeK7 7zerVbgZqAhG9RUS6fc/rT3tBZoB0KCCxs7UjnbCDPEA07HKMOtAVkB56W8ZD9LjI2te Z1hepJKGgB34+nlaOkzOjUPtwaSUkRr8HuZtc4cUTQqOBUwxij06JO0ZxVCu7sWJ3ba4 p17g== X-Gm-Message-State: AKaTC02DNxVGzv9sQTz0WMIgACpx47q7goHERX373ZH3NhUPVasqPQPwidLaQTDawGaX6kTVK3Cjsnsw2IGN/A== X-Received: by 10.200.41.171 with SMTP id 40mr56571735qts.235.1480958340658; Mon, 05 Dec 2016 09:19:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Mon, 5 Dec 2016 09:18:59 -0800 (PST) In-Reply-To: <20161205120210.GA97559@elstar.local> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> From: Andy Bierman Date: Mon, 5 Dec 2016 09:18:59 -0800 Message-ID: To: Juergen Schoenwaelder , Ladislav Lhotka , Lou Berger , NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Content-Type: multipart/alternative; boundary=001a11406578d2c1310542ec7b0d Archived-At: Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 17:19:10 -0000 --001a11406578d2c1310542ec7b0d Content-Type: text/plain; charset=UTF-8 On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > I disagree that the datastore model is a protocol specific aspect. I > > > consider datastores an architectural component binding data models and > > > protocols together. In fact, the 'traditional' datastore model > > > > I would agree with this if datastores were a general concept in YANG, > but the revised-datastores draft explicitly introduces the "intended" and > "applied" datastores that may be irrelevant to other protocols using YANG, > and even needn't be used in all NETCONF implementations. I wouldn't call > this "an architectural component" of YANG. > > > > An architectural component of this new management framework (that does > not have a name). The fact that not all protocols may expose all > datastores is IMHO not a reason that the datastore model is not an > architectural framework. > > > If you are saying that it will have nontrivial impact on YANG, I would > like to see it explained in sec. 6.3. Without this information I am quite > reluctant to agree with the adoption. > > An operational state datastore has implications how one writes data > models. It may not directly affect YANG itself but surely the usage of > YANG. > > > See above - architectural aspects need to be relevant to all protocols. > > Yes, but relevant to all protocols does not mean every protocol needs > to expose say all datastores. But every protocol should be clear about > how what it exposes relates to the architectural framework. > > There is a "current solution" consisting of hard-wired object semantics (e.g., ifAdminStatus and ifOperStatus). This solution does not require special protocols or datastores, but it is being replaced by a generic solution. If the "generic" solution requires special procedures which differ on each protocol, then it might end up be worse than the hard-wired solution that works on every protocol. So I agree with Juergen that this is primarily an architectural issue. /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 > --001a11406578d2c1310542ec7b0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lh= otka wrote:
>
> >
> > I disagree that the datastore model is a protocol specific aspect= . I
> > consider datastores an architectural component binding data model= s and
> > protocols together. In fact, the 'traditional' datastore = model
>
> I would agree with this if datastores were a general concept in YANG, = but the revised-datastores draft explicitly introduces the "intended&q= uot; and "applied" datastores that may be irrelevant to other pro= tocols using YANG, and even needn't be used in all NETCONF implementati= ons. I wouldn't call this "an architectural component" of YAN= G.
>

An architectural component of this new management framework (that does
not have a name). The fact that not all protocols may expose all
datastores is IMHO not a reason that the datastore model is not an
architectural framework.

> If you are saying that it will have nontrivial impact on YANG, I would= like to see it explained in sec. 6.3. Without this information I am quite = reluctant to agree with the adoption.

An operational state datastore has implications how one writes data
models. It may not directly affect YANG itself but surely the usage of
YANG.

> See above - architectural aspects need to be relevant to all protocols= .

Yes, but relevant to all protocols does not mean every protocol needs
to expose say all datastores. But every protocol should be clear about
how what it exposes relates to the architectural framework.



There is a "current solution&quo= t; consisting of hard-wired object semantics
(e.g., ifAdminStatus= and ifOperStatus).=C2=A0 This solution does not require
special = protocols or datastores, but it is being replaced by a generic solution.

If the "generic" solution requires special= procedures which differ on each protocol,
then it might end up b= e worse than the hard-wired solution that works on every protocol.
So I agree with Juergen that this is primarily an architectural issue.


/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

--001a11406578d2c1310542ec7b0d-- From nobody Mon Dec 5 10:55:31 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64875129C5B for ; Mon, 5 Dec 2016 10:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 uGv7wzrBDfie for ; Mon, 5 Dec 2016 10:55:28 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A937F129C8B for ; Mon, 5 Dec 2016 10:55:28 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id D1E951AE0118; Mon, 5 Dec 2016 19:55:25 +0100 (CET) Date: Mon, 05 Dec 2016 19:55:25 +0100 (CET) Message-Id: <20161205.195525.2175530549353134501.mbj@tail-f.com> To: evoit@cisco.com From: Martin Bjorklund In-Reply-To: <20161205.110728.1542519534982540528.mbj@tail-f.com> References: <20161129.124026.151848156249802222.mbj@tail-f.com> <20161205.110728.1542519534982540528.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 18:55:30 -0000 Martin Bjorklund wrote: > "Eric Voit (evoit)" wrote: [...] > > We absolutely want to have a full backwards compatible capability. > > The question is how to best frame this in documents. It is possible > > to rebuild RFC-5277 with a YANG model. But then you can't just layer > > on new capabilities driving this work. > > I think this in fact can be done. I'll get back to this in a separate > email. Here's an example of how we can define a YANG module that is backwards compatible in the sense that an old client can talk to a new server, and new clients can use the new features when talking to new servers. With this approach, we can build on the existing , and we don't have to add a new . We also don't have to change the current charter. module ietf-event-notification { namespace "urn:ietf:params:xml:ns:netconf:notification:1.0"; prefix ev; rpc create-subscription { input { leaf stream { type string; } choice filter-type { case netconf-style { anyxml filter; } case andy-style { // see Andy's proposal to the list container filters { list filter { ... } } } case by-reference { leaf filter-ref { ... } } } leaf startTime { ... } leaf stopTime { ... } leaf return-subscription-id { type empty; description "New leaf that old RFC5277 clients will never send. A new client that wants to use the new delete/modify rpcs need to set this in order to learn the id."; } } output { leaf subscription-id { type uint32; description "Only present if the client passed 'return-subscription-id' in the rpc input params."; } } } rpc delete-subscription { input { leaf subscription-id { type uint32; } } } rpc modify-subscription { ... } } In order to be fully backwards compatible, we also need to define a YANG model with the streams: module ietf-netconf-notification-streams { namespace "urn:ietf:params:xml:ns:netmod:notification"; prefix ncstreams; container netconf { config false; container streams { list stream { ... } } } } /martin From nobody Mon Dec 5 12:19:07 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F61D129CCF for ; Mon, 5 Dec 2016 12:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAaQ9h81P-uW for ; Mon, 5 Dec 2016 12:19:04 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4755129CCD for ; Mon, 5 Dec 2016 12:19:03 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id p16so325152606qta.0 for ; Mon, 05 Dec 2016 12:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fAReZOKN8bSa6CF7q8BFlZllT8Uw6NFwhmysb1kfbkY=; b=zg9ys4ynGrPy/A1KTFM446XKXfjF8ApUSNx1WH+tN4nOnT2peuJdey3AAKU3XgaES5 Z5g9RpACHf67Ojuw9wdkogASMvLGQyOfqMuszHgYDs7Pl7jJl+TfvzqX4234tEocB6Jw AZK/QJwFLUc8MuHkmoMM7y7P7JSwzJLCyJcczYTXOhxT+O47MG9+Sfs4lxxjEBxvIA8j IBSJj8dFBQ/c24A7FsVK2fxpNq9MW4BZ+fUqR/lTYY/yQd2AfOWbpzdouFZ7P7xYt3QB zdGQal34T4/GCvG0u6p5jBUJd7Txd0eicok9nAG2VuSZYNpDABQ5KM8b53O70EKLte8S 5lqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fAReZOKN8bSa6CF7q8BFlZllT8Uw6NFwhmysb1kfbkY=; b=BE+f2aAW5++j1FW+fRVViEK/+4fUMF5UFqOifEKVwaQEqNGaiBTjxaiLfqgi5yj7EE OeyLaqO54Wu1pR7UDq0HmXLLb5fTzpVX7dNvhpuoPmCJEFG+9THfwfyUPTmpQdyVIQnq WcRwAdsZFBUqyHRo5GDBgLA9poi4D+7891++13FnaVvMAX65ERVbROE7wo3+iL4rOejR Rkm2ksyxQ7vL/uxykWx6bwneUxWdvqlR+aqgo2b+/zIXV3apPBMv4/u+dZ6RchgIrtOL VV2p31FmQy4fdcoj1yNd1cqPH/CHvIDJuPDgVhmQ25Px4rZHUZwXbpaz/uKykW5+hiqu 7Cew== X-Gm-Message-State: AKaTC02YYT1FDpoyZTHhZKaEagJRzN78RBlSP9QtHo+pMWKrP751yn0+ZaGBohSbI0jiefJNCsmObyJMFxBDFQ== X-Received: by 10.200.50.97 with SMTP id y30mr53142871qta.203.1480969142717; Mon, 05 Dec 2016 12:19:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Mon, 5 Dec 2016 12:19:01 -0800 (PST) In-Reply-To: <20161205.195525.2175530549353134501.mbj@tail-f.com> References: <20161129.124026.151848156249802222.mbj@tail-f.com> <20161205.110728.1542519534982540528.mbj@tail-f.com> <20161205.195525.2175530549353134501.mbj@tail-f.com> From: Andy Bierman Date: Mon, 5 Dec 2016 12:19:01 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11406074ad407f0542eeff56 Archived-At: Cc: Netconf Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 20:19:06 -0000 --001a11406074ad407f0542eeff56 Content-Type: text/plain; charset=UTF-8 Hi, I prefer the current solution approach, which is to use 'establish-subscription'. There is no shortage of RPC names and no value in reusing create-subscription. Andy On Mon, Dec 5, 2016 at 10:55 AM, Martin Bjorklund wrote: > Martin Bjorklund wrote: > > "Eric Voit (evoit)" wrote: > > [...] > > > > We absolutely want to have a full backwards compatible capability. > > > The question is how to best frame this in documents. It is possible > > > to rebuild RFC-5277 with a YANG model. But then you can't just layer > > > on new capabilities driving this work. > > > > I think this in fact can be done. I'll get back to this in a separate > > email. > > Here's an example of how we can define a YANG module that is backwards > compatible in the sense that an old client can talk to a new server, > and new clients can use the new features when talking to new servers. > > With this approach, we can build on the existing > , and we don't have to add a new > . > > We also don't have to change the current charter. > > > module ietf-event-notification { > namespace "urn:ietf:params:xml:ns:netconf:notification:1.0"; > prefix ev; > > rpc create-subscription { > input { > leaf stream { > type string; > } > choice filter-type { > case netconf-style { > anyxml filter; > } > case andy-style { // see Andy's proposal to the list > container filters { > list filter { ... } > } > } > case by-reference { > leaf filter-ref { ... } > } > } > leaf startTime { ... } > leaf stopTime { ... } > leaf return-subscription-id { > type empty; > description > "New leaf that old RFC5277 clients will never send. > > A new client that wants to use the new delete/modify rpcs > need to set this in order to learn the id."; > } > } > output { > leaf subscription-id { > type uint32; > description > "Only present if the client passed 'return-subscription-id' in > the rpc input params."; > } > } > } > > rpc delete-subscription { > input { > leaf subscription-id { > type uint32; > } > } > } > > rpc modify-subscription { > ... > } > } > > > In order to be fully backwards compatible, we also need to define a > YANG model with the streams: > > module ietf-netconf-notification-streams { > namespace "urn:ietf:params:xml:ns:netmod:notification"; > prefix ncstreams; > > container netconf { > config false; > container streams { > list stream { ... } > } > } > } > > > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11406074ad407f0542eeff56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I prefer the current solution appro= ach, which is to use 'establish-subscription'.

=
There is no shortage of RPC names and no value in reusing create-subsc= ription.


Andy

<= /div>

On Mon, Dec = 5, 2016 at 10:55 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Martin Bjorklund <mbj@tail-f.com> wrote:
> "Eric Voit (evoit)" <e= voit@cisco.com> wrote:

[...]

> > We absolutely want to have a full backwards compatible capability= .
> > The question is how to best frame this in documents.=C2=A0 It is = possible
> > to rebuild RFC-5277 with a YANG model.=C2=A0 But then you can'= ;t just layer
> > on new capabilities driving this work.
>
> I think this in fact can be done.=C2=A0 I'll get back to this in a= separate
> email.

Here's an example of how we can define a YANG module that is backwards<= br> compatible in the sense that an old client can talk to a new server,
and new clients can use the new features when talking to new servers.

With this approach, we can build on the existing
<create-subscription>, and we don't have to add a new
<establish-subscription>.

We also don't have to change the current charter.


=C2=A0 module ietf-event-notification {
=C2=A0 =C2=A0 namespace "urn:ietf:params:xml:ns:netconf:notificat= ion:1.0";
=C2=A0 =C2=A0 prefix ev;

=C2=A0 =C2=A0 rpc create-subscription {
=C2=A0 =C2=A0 =C2=A0 input {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf stream {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 choice filter-type {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case netconf-style {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 anyxml filter;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case andy-style { // see Andy's prop= osal to the list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container filters {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list filter { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case by-reference {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf filter-ref { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf startTime { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf stopTime { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf return-subscription-id {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type empty;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "New leaf that old RFC5277 c= lients will never send.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new client that wants to = use the new delete/modify rpcs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need to set this in order t= o learn the id.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 output {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf subscription-id {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Only present if the client = passed 'return-subscription-id' in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the rpc input params."= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 rpc delete-subscription {
=C2=A0 =C2=A0 =C2=A0 input {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf subscription-id {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 rpc modify-subscription {
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 }
=C2=A0 }


In order to be fully backwards compatible, we also need to define a
YANG model with the streams:

=C2=A0 module ietf-netconf-notification-streams {
=C2=A0 =C2=A0 namespace "urn:ietf:params:xml:ns:netmod:notificati= on";
=C2=A0 =C2=A0 prefix ncstreams;

=C2=A0 =C2=A0 container netconf {
=C2=A0 =C2=A0 =C2=A0 config false;
=C2=A0 =C2=A0 =C2=A0 container streams {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 list stream { ... }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }




/martin

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

--001a11406074ad407f0542eeff56-- From nobody Mon Dec 5 12:28:32 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33091295C3 for ; Mon, 5 Dec 2016 12:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzYZpj1ZaoXQ for ; Mon, 5 Dec 2016 12:28:29 -0800 (PST) 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 E1C9F12954B for ; Mon, 5 Dec 2016 12:28:28 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id c13so230462505lfg.0 for ; Mon, 05 Dec 2016 12:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wWavX9Vn9m6Zz0/jhxT1r2XEhzeLkG/lEL6MHC6YU/w=; b=IXOM0uQmMkE3P9pesESea0DxMGew4A8kV8lrmBHnSxTxTuFaFCwRpx6WJjpdRSwfU/ zPaeiI7vhfge+VmNV1ZunlvUHXW68voZoo9KB2ERam1ApN6g7nSjx1GmHDXZYP5QEFcH ilR/LOIpXywuBkCCH8oB5uSQZr/d04dIOgYlai7lKpom8dvgLIrqlp84CxMzl2F2yn7h gsr5H9CMr3pQEACOQVHVIs6vCUravuMT4SD71r0m5iLhBddiIsN5F+1yR+heCfZWXQw+ n3kuxU0c8mtD0U9qrHsuO48udYVlP/4omzUHFii2zjsxfGAduSfX2q1uFoLP37TnTOht MD+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wWavX9Vn9m6Zz0/jhxT1r2XEhzeLkG/lEL6MHC6YU/w=; b=X8ZG7ub7qrFzNPom7QNkQgw7LcP/+Q4J1rxjqUkCCSkPZO3jWfsEZzkjqYfPQ3CysA 7H0Sa8BEIklPvKcdB417aOXROqhXRtm+YRAUinvnD21FQQOrm7mc1nAg6tP9TauZdBYp vuxQhHxqmLUf1r84OqbRC2klJsjY0KKq2C3Ysnibximx+zZm6GEml4/xMhY3Ss4V85Zy iL7FBg/csNVhu1iwgTww4hqaI8BwTa9/d5A6GLKk1ANOkdUZiaaqX5AjOUFkZEWDNeOT XbkCAFMO+sUuaEvTAQfxqY5hPlrxKixA1xhCzG/p5OVAMuZWivobsT5qTKT1n2+kKi64 uGpQ== X-Gm-Message-State: AKaTC03mNAtzdn9Ex/qNwbo9mLuAcJAoq+nsvhay4CSuGiIfGPY8IbaLqFthZfnowyhGVdExaRZc8h6+Bs95Xw== X-Received: by 10.25.24.165 with SMTP id 37mr23372606lfy.168.1480969707027; Mon, 05 Dec 2016 12:28:27 -0800 (PST) MIME-Version: 1.0 References: <20161129.124026.151848156249802222.mbj@tail-f.com> <20161205.110728.1542519534982540528.mbj@tail-f.com> <20161205.195525.2175530549353134501.mbj@tail-f.com> In-Reply-To: From: MehmetErsue Date: Mon, 05 Dec 2016 20:28:16 +0000 Message-ID: To: Andy Bierman , Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11406a824f83dc0542ef2156 Archived-At: Cc: Netconf Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 20:28:31 -0000 --001a11406a824f83dc0542ef2156 Content-Type: text/plain; charset=UTF-8 Technically spoken I think supporting backwards compatibility in the sense that an old client can talk to a new server, and new clients can use the new features when talking to new servers is valuable. Mehmet On Mon, Dec 5, 2016 at 9:19 PM Andy Bierman wrote: > Hi, > > I prefer the current solution approach, which is to use > 'establish-subscription'. > > There is no shortage of RPC names and no value in reusing > create-subscription. > > > Andy > > > On Mon, Dec 5, 2016 at 10:55 AM, Martin Bjorklund wrote: > > Martin Bjorklund wrote: > > "Eric Voit (evoit)" wrote: > > [...] > > > > We absolutely want to have a full backwards compatible capability. > > > The question is how to best frame this in documents. It is possible > > > to rebuild RFC-5277 with a YANG model. But then you can't just layer > > > on new capabilities driving this work. > > > > I think this in fact can be done. I'll get back to this in a separate > > email. > > Here's an example of how we can define a YANG module that is backwards > compatible in the sense that an old client can talk to a new server, > and new clients can use the new features when talking to new servers. > > With this approach, we can build on the existing > , and we don't have to add a new > . > > We also don't have to change the current charter. > > > module ietf-event-notification { > namespace "urn:ietf:params:xml:ns:netconf:notification:1.0"; > prefix ev; > > rpc create-subscription { > input { > leaf stream { > type string; > } > choice filter-type { > case netconf-style { > anyxml filter; > } > case andy-style { // see Andy's proposal to the list > container filters { > list filter { ... } > } > } > case by-reference { > leaf filter-ref { ... } > } > } > leaf startTime { ... } > leaf stopTime { ... } > leaf return-subscription-id { > type empty; > description > "New leaf that old RFC5277 clients will never send. > > A new client that wants to use the new delete/modify rpcs > need to set this in order to learn the id."; > } > } > output { > leaf subscription-id { > type uint32; > description > "Only present if the client passed 'return-subscription-id' in > the rpc input params."; > } > } > } > > rpc delete-subscription { > input { > leaf subscription-id { > type uint32; > } > } > } > > rpc modify-subscription { > ... > } > } > > > In order to be fully backwards compatible, we also need to define a > YANG model with the streams: > > module ietf-netconf-notification-streams { > namespace "urn:ietf:params:xml:ns:netmod:notification"; > prefix ncstreams; > > container netconf { > config false; > container streams { > list stream { ... } > } > } > } > > > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Cheers, Mehmet --001a11406a824f83dc0542ef2156 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Technically spoken I think supporting backwards compa= tibility
in the sense that an old client can talk to a new server, and = new clients can use the new features when talking to new servers
is valu= able.

Mehmet

On Mon, Dec 5, 2016 at 9:19 PM Andy Bierman <andy@yumaworks.com> wrote:
Hi,

I prefer th= e current solution approach, which is to use 'establish-subscription= 9;.

There is no shortage of RPC names and no value in reusing cr= eate-subscription.

Andy


On M= on, Dec 5, 2016 at 10:55 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Martin Bjorklund <mbj@tail-f.com&= gt; wrote:
> "Eric Voit (evoit)" <evoit@cisco.com> wrote:

[...]

> > We absolutely want to have a full backwards compatible capability= .
> > The question is how to best frame this in documents.=C2=A0 It is = possible
> > to rebuild RFC-5277 with a YANG model.=C2=A0 But then you can'= ;t just layer
> > on new capabilities driving this work.
>
> I think this in fact can be done.=C2=A0 I'll get back to this in a= separate
> email.

Here's an example of how we can define a YANG module that is backwards<= br class=3D"gmail_msg"> compatible in the sense that an old client can talk to a new server,
and new clients can use the new features when talking to new servers.

With this approach, we can build on the existing
<create-subscription>, and we don't have to add a new
<establish-subscription>.

We also don't have to change the current charter.


=C2=A0 module ietf-event-notification {
=C2=A0 =C2=A0 namespace "urn:ietf:params:xml:ns:netconf:notification:1= .0";
=C2=A0 =C2=A0 prefix ev;

=C2=A0 =C2=A0 rpc create-subscription {
=C2=A0 =C2=A0 =C2=A0 input {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf stream {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 choice filter-type {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case netconf-style {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 anyxml filter;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case andy-style { // see Andy's prop= osal to the list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container filters {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list filter { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case by-reference {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf filter-ref { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf startTime { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf stopTime { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf return-subscription-id {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type empty;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "New leaf that old RFC5277 c= lients will never send.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new client that wants to = use the new delete/modify rpcs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need to set this in order t= o learn the id.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 output {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf subscription-id {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Only present if the client = passed 'return-subscription-id' in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the rpc input params."= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 rpc delete-subscription {
=C2=A0 =C2=A0 =C2=A0 input {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf subscription-id {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 rpc modify-subscription {
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 }
=C2=A0 }


In order to be fully backwards compatible, we also need to define a
YANG model with the streams:

=C2=A0 module ietf-netconf-notification-streams {
=C2=A0 =C2=A0 namespace "urn:ietf:params:xml:ns:netmod:notification&qu= ot;;
=C2=A0 =C2=A0 prefix ncstreams;

=C2=A0 =C2=A0 container netconf {
=C2=A0 =C2=A0 =C2=A0 config false;
=C2=A0 =C2=A0 =C2=A0 container streams {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 list stream { ... }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }




/martin

_______________________________________________
Netconf mailing list
N= etconf@ietf.org
https://www.ietf.org/mailman/listin= fo/netconf

_______________________________________________
Netconf mailing list
N= etconf@ietf.org
https://www.ietf.org/mailman/listin= fo/netconf
--
Cheers,
Mehmet
--001a11406a824f83dc0542ef2156-- From nobody Mon Dec 5 12:31:37 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7B8129CE7 for ; Mon, 5 Dec 2016 12:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AB1-0u7lq-Vg for ; Mon, 5 Dec 2016 12:31:33 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 17309129CCD for ; Mon, 5 Dec 2016 12:31:33 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id p16so325493758qta.0 for ; Mon, 05 Dec 2016 12:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Db/fhDZvmrozpklp8h0Drns8AswsNLXywRertNYeXU4=; b=Ju6QeEV1cMZoy17yThNXX88RQSZUU+U0Ml5HXjSsmygRXPRJIinVfMgpS7ktRdB2mU Lzud46D7ccCoTPoNhA7zI9JjI2rEGxAWnt6VzRGmSYE0c2WjN4jjtIjPPyDfazGVXVnv y9ajwHfDiyZkwZDBSdtHiWFRqxcLqK7T5e9QlQUJaxpcz3MXjQQTaG/DaaDenFSy7ldk foObJcRoWLjc+tt6At8kdgJkDzR6DDc6K/ZhppeLMb8R9Ldz4OrVmx0K+k5TpVR4ScRN QGdCVs2DkDR+1ILCvVwQ7Mkn5mWxMwPD17EQ4Zkajwg67oi0vVL2OVyEUxuqcmxKG6ha AJGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Db/fhDZvmrozpklp8h0Drns8AswsNLXywRertNYeXU4=; b=BlputLjx+vh8++WUc/UhaGFVzVtQOMTBeaKUBBYlFixxgxwCIYRm7WXe+dXUZcCcnY FrE1Wl5mtSfDX8Urgvm053inF6KHAUpJUdPO3E+NV8zqYiUpDhBPzHITgv27sbNTm49d JSlsJVA2OeonzMy9sQwjbT71RA4uJsmFUGZgLhHaVxRc4+U1NTuzAeyipgX/JZZ5NO2r g4JjmfpFffZm+viNTkH9stUwZSDEwFpMXVt9tRcaAV5sfGeLTDhdkn4JmYIi3rBlLytB VseZkiOytKsDuHClbLzED0uRPKM5/iiNS3nxkkFqdDS93KNabUNxqX+TL12B1hEqZnh2 EbIw== X-Gm-Message-State: AKaTC02bt6MPVnKgByank6XG4xiHq2ehy8i1TdpwYbO6myXBSR96UnmD2+PL++kS/x7RR5I8KXp11LrCx5kbeQ== X-Received: by 10.200.50.97 with SMTP id y30mr53194384qta.203.1480969892192; Mon, 05 Dec 2016 12:31:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Mon, 5 Dec 2016 12:31:31 -0800 (PST) In-Reply-To: References: <20161129.124026.151848156249802222.mbj@tail-f.com> <20161205.110728.1542519534982540528.mbj@tail-f.com> <20161205.195525.2175530549353134501.mbj@tail-f.com> From: Andy Bierman Date: Mon, 5 Dec 2016 12:31:31 -0800 Message-ID: To: MehmetErsue Content-Type: multipart/alternative; boundary=001a114060745924d90542ef2c29 Archived-At: Cc: Netconf Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 20:31:36 -0000 --001a114060745924d90542ef2c29 Content-Type: text/plain; charset=UTF-8 Hi, There is nothing preventing a new server from keeping its code that supports . IMO it is better if continues to work exactly as expected so there is no chance an old client using RFC 5277 will break. Andy On Mon, Dec 5, 2016 at 12:28 PM, MehmetErsue wrote: > Technically spoken I think supporting backwards compatibility > in the sense that an old client can talk to a new server, and new clients > can use the new features when talking to new servers > is valuable. > > Mehmet > > On Mon, Dec 5, 2016 at 9:19 PM Andy Bierman wrote: > >> Hi, >> >> I prefer the current solution approach, which is to use >> 'establish-subscription'. >> >> There is no shortage of RPC names and no value in reusing >> create-subscription. >> >> >> Andy >> >> >> On Mon, Dec 5, 2016 at 10:55 AM, Martin Bjorklund wrote: >> >> Martin Bjorklund wrote: >> > "Eric Voit (evoit)" wrote: >> >> [...] >> >> > > We absolutely want to have a full backwards compatible capability. >> > > The question is how to best frame this in documents. It is possible >> > > to rebuild RFC-5277 with a YANG model. But then you can't just layer >> > > on new capabilities driving this work. >> > >> > I think this in fact can be done. I'll get back to this in a separate >> > email. >> >> Here's an example of how we can define a YANG module that is backwards >> compatible in the sense that an old client can talk to a new server, >> and new clients can use the new features when talking to new servers. >> >> With this approach, we can build on the existing >> , and we don't have to add a new >> . >> >> We also don't have to change the current charter. >> >> >> module ietf-event-notification { >> namespace "urn:ietf:params:xml:ns:netconf:notification:1.0"; >> prefix ev; >> >> rpc create-subscription { >> input { >> leaf stream { >> type string; >> } >> choice filter-type { >> case netconf-style { >> anyxml filter; >> } >> case andy-style { // see Andy's proposal to the list >> container filters { >> list filter { ... } >> } >> } >> case by-reference { >> leaf filter-ref { ... } >> } >> } >> leaf startTime { ... } >> leaf stopTime { ... } >> leaf return-subscription-id { >> type empty; >> description >> "New leaf that old RFC5277 clients will never send. >> >> A new client that wants to use the new delete/modify rpcs >> need to set this in order to learn the id."; >> } >> } >> output { >> leaf subscription-id { >> type uint32; >> description >> "Only present if the client passed 'return-subscription-id' in >> the rpc input params."; >> } >> } >> } >> >> rpc delete-subscription { >> input { >> leaf subscription-id { >> type uint32; >> } >> } >> } >> >> rpc modify-subscription { >> ... >> } >> } >> >> >> In order to be fully backwards compatible, we also need to define a >> YANG model with the streams: >> >> module ietf-netconf-notification-streams { >> namespace "urn:ietf:params:xml:ns:netmod:notification"; >> prefix ncstreams; >> >> container netconf { >> config false; >> container streams { >> list stream { ... } >> } >> } >> } >> >> >> >> >> /martin >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > -- > Cheers, > Mehmet > --001a114060745924d90542ef2c29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

There is nothing preventing a new s= erver from keeping its code that supports <create-subscription>.
IMO it is better if <create-subscription> continues to work exa= ctly as expected
so there is no chance an old client using RFC 52= 77 will break.


Andy

<= /div>

On Mon,= Dec 5, 2016 at 12:28 PM, MehmetErsue <mersue@gmail.com> wrot= e:
Technically spok= en I think supporting backwards compatibility
in the sense that an old = client can talk to a new server, and new clients can use the new features w= hen talking to new servers
is valuable.

Mehmet
On Mon, Dec 5, 2016 at 9:19 PM= Andy Bierman <a= ndy@yumaworks.com> wrote:
Hi,

=
I prefer the current so= lution approach, which is to use 'establish-subscription'.

There is n= o shortage of RPC names and no value in reusing create-subscription.
<= /div>


Andy


On Mon, Dec 5, 2016 a= t 10:55 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Martin Bjorklund <mbj@tail= -f.com> wrote:
> "Eric Voit (evoit)" <evoit@cisco.com> wrote:

[...]

> > We absolutely want to have a full backwards compatible capability= .
> > The question is how to best frame this in documents.=C2=A0 It is = possible
> > to rebuild RFC-5277 with a YANG model.=C2=A0 But then you can'= ;t just layer
> > on new capabilities driving this work.
>
> I think this in fact can be done.=C2=A0 I'll get back to this in a= separate
> email.

Here's an example of how we can define a YANG module that is backwards<= br class=3D"m_7957566144747272904gmail_msg"> compatible in the sense that an old client can talk to a new server,
and new clients can use the new features when talking to new servers.

With this approach, we can build on the existing
<create-subscription>, and we don't have to add a new
<establish-subscription>.

We also don't have to change the current charter.


=C2=A0 module ietf-event-notification {
=C2=A0 =C2=A0 namespace "urn:ietf:params:xml:ns:netconf:notificat= ion:1.0";
=C2=A0 =C2=A0 prefix ev;

=C2=A0 =C2=A0 rpc create-subscription {
=C2=A0 =C2=A0 =C2=A0 input {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf stream {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 choice filter-type {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case netconf-style {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 anyxml filter;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case andy-style { // see Andy's prop= osal to the list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container filters {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list filter { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case by-reference {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf filter-ref { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf startTime { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf stopTime { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf return-subscription-id {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type empty;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "New leaf that old RFC5277 c= lients will never send.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new client that wants to = use the new delete/modify rpcs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need to set this in order t= o learn the id.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 output {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf subscription-id {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Only present if the client = passed 'return-subscription-id' in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the rpc input params."= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 rpc delete-subscription {
=C2=A0 =C2=A0 =C2=A0 input {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf subscription-id {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 rpc modify-subscription {
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 }
=C2=A0 }


In order to be fully backwards compatible, we also need to define a
YANG model with the streams:

=C2=A0 module ietf-netconf-notification-streams {
=C2=A0 =C2=A0 namespace "urn:ietf:params:xml:ns:netmod:notificati= on";
=C2=A0 =C2=A0 prefix ncstreams;

=C2=A0 =C2=A0 container netconf {
=C2=A0 =C2=A0 =C2=A0 config false;
=C2=A0 =C2=A0 =C2=A0 container streams {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 list stream { ... }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }




/martin

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

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ie= tf.org/mailman/listinfo/netconf
--
=
Cheers,
Mehmet

--001a114060745924d90542ef2c29-- From nobody Mon Dec 5 12:37:32 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EED129CE9 for ; Mon, 5 Dec 2016 12:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 0-NzoJDu1wUk for ; Mon, 5 Dec 2016 12:37:28 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C4F381295AB for ; Mon, 5 Dec 2016 12:37:22 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 758DD1AE0118; Mon, 5 Dec 2016 21:37:20 +0100 (CET) Date: Mon, 05 Dec 2016 21:37:20 +0100 (CET) Message-Id: <20161205.213720.750636116959128575.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20161205.110728.1542519534982540528.mbj@tail-f.com> <20161205.195525.2175530549353134501.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 20:37:30 -0000 Andy Bierman wrote: > Hi, > > I prefer the current solution approach, which is to use > 'establish-subscription'. Can you elaborate on why you prefer two operations instead of one, when they do the same thing? > There is no shortage of RPC names and no value in reusing > create-subscription. I think it is confusing to have two so similar operations with different names. /martin > > > Andy > > > On Mon, Dec 5, 2016 at 10:55 AM, Martin Bjorklund wrote: > > > Martin Bjorklund wrote: > > > "Eric Voit (evoit)" wrote: > > > > [...] > > > > > > We absolutely want to have a full backwards compatible capability. > > > > The question is how to best frame this in documents. It is possible > > > > to rebuild RFC-5277 with a YANG model. But then you can't just layer > > > > on new capabilities driving this work. > > > > > > I think this in fact can be done. I'll get back to this in a separate > > > email. > > > > Here's an example of how we can define a YANG module that is backwards > > compatible in the sense that an old client can talk to a new server, > > and new clients can use the new features when talking to new servers. > > > > With this approach, we can build on the existing > > , and we don't have to add a new > > . > > > > We also don't have to change the current charter. > > > > > > module ietf-event-notification { > > namespace "urn:ietf:params:xml:ns:netconf:notification:1.0"; > > prefix ev; > > > > rpc create-subscription { > > input { > > leaf stream { > > type string; > > } > > choice filter-type { > > case netconf-style { > > anyxml filter; > > } > > case andy-style { // see Andy's proposal to the list > > container filters { > > list filter { ... } > > } > > } > > case by-reference { > > leaf filter-ref { ... } > > } > > } > > leaf startTime { ... } > > leaf stopTime { ... } > > leaf return-subscription-id { > > type empty; > > description > > "New leaf that old RFC5277 clients will never send. > > > > A new client that wants to use the new delete/modify rpcs > > need to set this in order to learn the id."; > > } > > } > > output { > > leaf subscription-id { > > type uint32; > > description > > "Only present if the client passed 'return-subscription-id' in > > the rpc input params."; > > } > > } > > } > > > > rpc delete-subscription { > > input { > > leaf subscription-id { > > type uint32; > > } > > } > > } > > > > rpc modify-subscription { > > ... > > } > > } > > > > > > In order to be fully backwards compatible, we also need to define a > > YANG model with the streams: > > > > module ietf-netconf-notification-streams { > > namespace "urn:ietf:params:xml:ns:netmod:notification"; > > prefix ncstreams; > > > > container netconf { > > config false; > > container streams { > > list stream { ... } > > } > > } > > } > > > > > > > > > > /martin > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > From nobody Mon Dec 5 12:43:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA751295BE for ; Mon, 5 Dec 2016 12:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv-PIB_rG79L for ; Mon, 5 Dec 2016 12:43:20 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 886F0129D0C for ; Mon, 5 Dec 2016 12:43:20 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id c47so326737021qtc.2 for ; Mon, 05 Dec 2016 12:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tn77J/ylCecSmu672+9F8mtMYv9NL3+v8hJcZuQOt6k=; b=Xrv19AZu8EMxqQQWH6eGdOivE5T/r8t6eq1UhbzBMnOaqIL8cEpG/xgUvTI3fAKCP7 2vOv0bHa1DHOnPbRdl/012o48z8XrGvSIX5WogaCgJoMffAmw1odlHtBtejNdBOmnzD7 WfFBvBTTaUM4fm19TJ0EUG04gzlCpEyccJaTLmBtys5RjjUdDwfH0AIWoZOpP+1ljuUg np0QJMMabZafpq+dDJNafDbNmhqz5BI/JDgEyupZdIfryNM+Zr9+2SknMZ02aGBgyE+j aYzOf/aJghZX+gERzWzW3v5qqOqjxW6pWwozVrHSr+z/X7EX4pTAT1ELU2rgvSoi6XgS ulyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tn77J/ylCecSmu672+9F8mtMYv9NL3+v8hJcZuQOt6k=; b=VsVG4BdG7U3LWBovuhz8J9besuA/SaLruZqb00SnjX8rI70uNoFPLSdrkEQlZKNPsk zIzWLljFQwikbzXU5o34wQnmV3UYv7PhlFECGjXjFgqVi3ITwRu1enx3sOmZmxBSgM9R eXCnBqxTqQCpVwxfXRsqK32YqGLZt1Rp6sesbxKpDVNu1uSbBbbD4lxbbCs5Cs2dV/n5 vPb7ceWcBXko3v5szvvB6uH32PAcc6ak03pK9gw554PCItq86agykIg0xeB4TXtLrgKj bz4hNZVWX+lqT10aUnCp7Cn9+ioaIdCWuDz+6fQVvrYLEgwjdKBJZnQ7ji6B11AWS7IP puBQ== X-Gm-Message-State: AKaTC01KFQFUiR5fOT3bCpDGAi5lzMyvtGuIzrbe0gAqpu+pEQ5r4bSWJd51rnODHjx0yQBXqGwTaf8sa/i2ZA== X-Received: by 10.237.48.139 with SMTP id 11mr51778838qtf.219.1480970599697; Mon, 05 Dec 2016 12:43:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Mon, 5 Dec 2016 12:43:18 -0800 (PST) In-Reply-To: <20161205.213720.750636116959128575.mbj@tail-f.com> References: <20161205.110728.1542519534982540528.mbj@tail-f.com> <20161205.195525.2175530549353134501.mbj@tail-f.com> <20161205.213720.750636116959128575.mbj@tail-f.com> From: Andy Bierman Date: Mon, 5 Dec 2016 12:43:18 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=94eb2c0c865a84b19d0542ef5645 Archived-At: Cc: Netconf Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 20:43:23 -0000 --94eb2c0c865a84b19d0542ef5645 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I prefer the current solution approach, which is to use > > 'establish-subscription'. > > Can you elaborate on why you prefer two operations instead of one, > when they do the same thing? > because they don't do the same thing. The new solution has configured filters, subscription-id, suspend and cancel operations and should not need streams. The old solution can be deprecated and replaced. IMO this is much less confusing than trying to use create-subscription. Andy > > There is no shortage of RPC names and no value in reusing > > create-subscription. > > I think it is confusing to have two so similar operations with > different names. > > > /martin > > > > > > > > Andy > > > > > > On Mon, Dec 5, 2016 at 10:55 AM, Martin Bjorklund > wrote: > > > > > Martin Bjorklund wrote: > > > > "Eric Voit (evoit)" wrote: > > > > > > [...] > > > > > > > > We absolutely want to have a full backwards compatible capability. > > > > > The question is how to best frame this in documents. It is > possible > > > > > to rebuild RFC-5277 with a YANG model. But then you can't just > layer > > > > > on new capabilities driving this work. > > > > > > > > I think this in fact can be done. I'll get back to this in a > separate > > > > email. > > > > > > Here's an example of how we can define a YANG module that is backwards > > > compatible in the sense that an old client can talk to a new server, > > > and new clients can use the new features when talking to new servers. > > > > > > With this approach, we can build on the existing > > > , and we don't have to add a new > > > . > > > > > > We also don't have to change the current charter. > > > > > > > > > module ietf-event-notification { > > > namespace "urn:ietf:params:xml:ns:netconf:notification:1.0"; > > > prefix ev; > > > > > > rpc create-subscription { > > > input { > > > leaf stream { > > > type string; > > > } > > > choice filter-type { > > > case netconf-style { > > > anyxml filter; > > > } > > > case andy-style { // see Andy's proposal to the list > > > container filters { > > > list filter { ... } > > > } > > > } > > > case by-reference { > > > leaf filter-ref { ... } > > > } > > > } > > > leaf startTime { ... } > > > leaf stopTime { ... } > > > leaf return-subscription-id { > > > type empty; > > > description > > > "New leaf that old RFC5277 clients will never send. > > > > > > A new client that wants to use the new delete/modify rpcs > > > need to set this in order to learn the id."; > > > } > > > } > > > output { > > > leaf subscription-id { > > > type uint32; > > > description > > > "Only present if the client passed > 'return-subscription-id' in > > > the rpc input params."; > > > } > > > } > > > } > > > > > > rpc delete-subscription { > > > input { > > > leaf subscription-id { > > > type uint32; > > > } > > > } > > > } > > > > > > rpc modify-subscription { > > > ... > > > } > > > } > > > > > > > > > In order to be fully backwards compatible, we also need to define a > > > YANG model with the streams: > > > > > > module ietf-netconf-notification-streams { > > > namespace "urn:ietf:params:xml:ns:netmod:notification"; > > > prefix ncstreams; > > > > > > container netconf { > > > config false; > > > container streams { > > > list stream { ... } > > > } > > > } > > > } > > > > > > > > > > > > > > > /martin > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > --94eb2c0c865a84b19d0542ef5645 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> I prefer the current solution approach, which is to use
> 'establish-subscription'.

Can you elaborate on why you prefer two operations instead of one,
when they do the same thing?

because th= ey don't do the same thing.
The new solution has configured f= ilters, subscription-id, suspend and cancel operations
and should= not need streams.

The old solution can be depreca= ted and replaced.
IMO this is much less confusing than trying to = use create-subscription.


Andy
=
=C2=A0
> There is no shortage of RPC names and no value in reusing
> create-subscription.

I think it is confusing to have two so similar operations with
different names.


/martin


>
>
> Andy
>
>
> On Mon, Dec 5, 2016 at 10:55 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Martin Bjorklund <mbj@tail-f= .com> wrote:
> > > "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> >
> > [...]
> >
> > > > We absolutely want to have a full backwards compatible = capability.
> > > > The question is how to best frame this in documents.=C2= =A0 It is possible
> > > > to rebuild RFC-5277 with a YANG model.=C2=A0 But then y= ou can't just layer
> > > > on new capabilities driving this work.
> > >
> > > I think this in fact can be done.=C2=A0 I'll get back to= this in a separate
> > > email.
> >
> > Here's an example of how we can define a YANG module that is = backwards
> > compatible in the sense that an old client can talk to a new serv= er,
> > and new clients can use the new features when talking to new serv= ers.
> >
> > With this approach, we can build on the existing
> > <create-subscription>, and we don't have to add a new > > <establish-subscription>.
> >
> > We also don't have to change the current charter.
> >
> >
> >=C2=A0 =C2=A0module ietf-event-notification {
> >=C2=A0 =C2=A0 =C2=A0namespace "urn:ietf:params:xml:ns:ne= tconf:notification:1.0";
> >=C2=A0 =C2=A0 =C2=A0prefix ev;
> >
> >=C2=A0 =C2=A0 =C2=A0rpc create-subscription {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0input {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf stream {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choice filter-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case netconf-style {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anyxml filter;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case andy-style { // see = Andy's proposal to the list
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container filters = {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list filter= { ... }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case by-reference {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf filter-ref { = ... }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf startTime { ... }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf stopTime { ... }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf return-subscription-id { > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type empty;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"New leaf tha= t old RFC5277 clients will never send.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A new client that= wants to use the new delete/modify rpcs
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 need to set this = in order to learn the id.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0output {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf subscription-id {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Only present= if the client passed 'return-subscription-id' in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the rpc input par= ams.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0rpc delete-subscription {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0input {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf subscription-id {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0rpc modify-subscription {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >
> > In order to be fully backwards compatible, we also need to define= a
> > YANG model with the streams:
> >
> >=C2=A0 =C2=A0module ietf-netconf-notification-streams {
> >=C2=A0 =C2=A0 =C2=A0namespace "urn:ietf:params:xml:ns:ne= tmod:notification";
> >=C2=A0 =C2=A0 =C2=A0prefix ncstreams;
> >
> >=C2=A0 =C2=A0 =C2=A0container netconf {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0config false;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0container streams {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list stream { ... }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >
> >
> >
> > /martin
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ne= tconf
> >

--94eb2c0c865a84b19d0542ef5645-- From nobody Mon Dec 5 12:48:34 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E022129549 for ; Mon, 5 Dec 2016 12:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 bp6VQCL1ScFb for ; Mon, 5 Dec 2016 12:48:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 07AE9129D0E for ; Mon, 5 Dec 2016 12:48:32 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 451A31AE0118; Mon, 5 Dec 2016 21:48:31 +0100 (CET) Date: Mon, 05 Dec 2016 21:48:31 +0100 (CET) Message-Id: <20161205.214831.712192266937344872.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20161205.213720.750636116959128575.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 20:48:33 -0000 Andy Bierman wrote: > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > Hi, > > > > > > I prefer the current solution approach, which is to use > > > 'establish-subscription'. > > > > Can you elaborate on why you prefer two operations instead of one, > > when they do the same thing? > > > > because they don't do the same thing. > The new solution has configured filters, subscription-id, suspend and > cancel operations These are trivial extensions to the current solution. If they are truly different the names should not be so similar. > and should not need streams. What do you mean "should not need streams"? > The old solution can be deprecated and replaced. Sure, if it is broken. But I don't think it is broken in any way. /martin > IMO this is much less confusing than trying to use create-subscription. > > > Andy > > > > > There is no shortage of RPC names and no value in reusing > > > create-subscription. > > > > I think it is confusing to have two so similar operations with > > different names. > > > > > > /martin > > > > > > > > > > > > > Andy > > > > > > > > > On Mon, Dec 5, 2016 at 10:55 AM, Martin Bjorklund > > wrote: > > > > > > > Martin Bjorklund wrote: > > > > > "Eric Voit (evoit)" wrote: > > > > > > > > [...] > > > > > > > > > > We absolutely want to have a full backwards compatible capability. > > > > > > The question is how to best frame this in documents. It is > > possible > > > > > > to rebuild RFC-5277 with a YANG model. But then you can't just > > layer > > > > > > on new capabilities driving this work. > > > > > > > > > > I think this in fact can be done. I'll get back to this in a > > separate > > > > > email. > > > > > > > > Here's an example of how we can define a YANG module that is backwards > > > > compatible in the sense that an old client can talk to a new server, > > > > and new clients can use the new features when talking to new servers. > > > > > > > > With this approach, we can build on the existing > > > > , and we don't have to add a new > > > > . > > > > > > > > We also don't have to change the current charter. > > > > > > > > > > > > module ietf-event-notification { > > > > namespace "urn:ietf:params:xml:ns:netconf:notification:1.0"; > > > > prefix ev; > > > > > > > > rpc create-subscription { > > > > input { > > > > leaf stream { > > > > type string; > > > > } > > > > choice filter-type { > > > > case netconf-style { > > > > anyxml filter; > > > > } > > > > case andy-style { // see Andy's proposal to the list > > > > container filters { > > > > list filter { ... } > > > > } > > > > } > > > > case by-reference { > > > > leaf filter-ref { ... } > > > > } > > > > } > > > > leaf startTime { ... } > > > > leaf stopTime { ... } > > > > leaf return-subscription-id { > > > > type empty; > > > > description > > > > "New leaf that old RFC5277 clients will never send. > > > > > > > > A new client that wants to use the new delete/modify rpcs > > > > need to set this in order to learn the id."; > > > > } > > > > } > > > > output { > > > > leaf subscription-id { > > > > type uint32; > > > > description > > > > "Only present if the client passed > > 'return-subscription-id' in > > > > the rpc input params."; > > > > } > > > > } > > > > } > > > > > > > > rpc delete-subscription { > > > > input { > > > > leaf subscription-id { > > > > type uint32; > > > > } > > > > } > > > > } > > > > > > > > rpc modify-subscription { > > > > ... > > > > } > > > > } > > > > > > > > > > > > In order to be fully backwards compatible, we also need to define a > > > > YANG model with the streams: > > > > > > > > module ietf-netconf-notification-streams { > > > > namespace "urn:ietf:params:xml:ns:netmod:notification"; > > > > prefix ncstreams; > > > > > > > > container netconf { > > > > config false; > > > > container streams { > > > > list stream { ... } > > > > } > > > > } > > > > } > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > From nobody Mon Dec 5 13:02:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3DE129DA8 for ; Mon, 5 Dec 2016 13:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3a3cQF-SNKm for ; Mon, 5 Dec 2016 13:02:51 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D95129D7A for ; Mon, 5 Dec 2016 13:02:03 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id n21so359876643qka.3 for ; Mon, 05 Dec 2016 13:02:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4D9FZ5j/PHJrt15/YyCZzhVYNy90WZuFbnJlj57UIn4=; b=b3Og6/ipFEgqD/qwEB/b0SaB6E8UZ/ZswO3DtXIIx8Qg3mB9GEsiCl2/5kk/jCFLuF S49ZNQALATdTgGuGbtKJ6P14cbb0kFv8kxEnJSyZduUfVJSkIENq9esas99xmDr4XtBU in4Fc547p3vnyEfKGgwGTImouVd9fXF7H4EECzli1H4I59BD7nfYvDbFkedqTIOgryTd wgOVxQPZx3Y/eKQ6AeYVY1hA3NNvzFY6EXNY0EwO5eIxy12xKOkY13BWNW9DEt7jTDEY LOC3J/Lxyuf1j3b59FMi+6HdL7cQVNqa9mXFctvNhPQm6hDcZqpfkJbCqIrmNmuQySRy EIfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4D9FZ5j/PHJrt15/YyCZzhVYNy90WZuFbnJlj57UIn4=; b=Oh59sV5w+32k+/sltId4rQxG+zH0y87zk4MbmQiK4eP4ITz1cQweIuqUqmxNiLPM8F 72OaBHECBYqT8Pda8Fi+gF1lZHCJZnvvpqg4KQ1MZSR6Xnp4ZQN61uACNraQl1gXvxOo 4/uddEUujoMCCqG1nTvKdiWrdl8Qb87MwBd+HDURAUPvhgGWYsOIUkrHyjkHqGg5YtGK j7BgX7CDAYRviEGgcPCIpTPJBlNufph4sjkRZH0N/2oMlfCA7G9mBWygHq7c+XkiqLxp 4ZxHQ/vMUptlzo9VR4pj9OCKvyK4QQPmUqSzozXTPAd0hAodQk7oLaihAKE7K1WEFUKL GRKQ== X-Gm-Message-State: AKaTC01b99qSZyiIFWyHaOV8ts+Bd7JA0ejgiFR50++Be/iN1j3TNdBsqGtveLN7eMASPZ+w3WNWaTpR0d6h+A== X-Received: by 10.55.46.5 with SMTP id u5mr57918589qkh.302.1480971722264; Mon, 05 Dec 2016 13:02:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Mon, 5 Dec 2016 13:02:01 -0800 (PST) In-Reply-To: <20161205.214831.712192266937344872.mbj@tail-f.com> References: <20161205.213720.750636116959128575.mbj@tail-f.com> <20161205.214831.712192266937344872.mbj@tail-f.com> From: Andy Bierman Date: Mon, 5 Dec 2016 13:02:01 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a114f14e06e308f0542ef9930 Archived-At: Cc: Netconf Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 21:02:53 -0000 --001a114f14e06e308f0542ef9930 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > Hi, > > > > > > > > I prefer the current solution approach, which is to use > > > > 'establish-subscription'. > > > > > > Can you elaborate on why you prefer two operations instead of one, > > > when they do the same thing? > > > > > > > because they don't do the same thing. > > The new solution has configured filters, subscription-id, suspend and > > cancel operations > > These are trivial extensions to the current solution. > > If they are truly different the names should not be so similar. > > > and should not need streams. > > What do you mean "should not need streams"? > > The streams concept is half-baked and not useful. We have 1 stream, NETCONF, which MUST contain everything and MUST be encoded in XML. Every other stream is purely ad-hoc and proprietary, with no chance at interoperability. > > The old solution can be deprecated and replaced. > > Sure, if it is broken. But I don't think it is broken in any way. > > > The element is changing so old clients cannot get the new version that contains a subscription-id and other fields. IMO it is simpler and clearer if the new solution is separate. /martin > > Andy > > > IMO this is much less confusing than trying to use create-subscription. > > > > > > Andy > > > > > > > > There is no shortage of RPC names and no value in reusing > > > > create-subscription. > > > > > > I think it is confusing to have two so similar operations with > > > different names. > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > On Mon, Dec 5, 2016 at 10:55 AM, Martin Bjorklund > > > wrote: > > > > > > > > > Martin Bjorklund wrote: > > > > > > "Eric Voit (evoit)" wrote: > > > > > > > > > > [...] > > > > > > > > > > > > We absolutely want to have a full backwards compatible > capability. > > > > > > > The question is how to best frame this in documents. It is > > > possible > > > > > > > to rebuild RFC-5277 with a YANG model. But then you can't just > > > layer > > > > > > > on new capabilities driving this work. > > > > > > > > > > > > I think this in fact can be done. I'll get back to this in a > > > separate > > > > > > email. > > > > > > > > > > Here's an example of how we can define a YANG module that is > backwards > > > > > compatible in the sense that an old client can talk to a new > server, > > > > > and new clients can use the new features when talking to new > servers. > > > > > > > > > > With this approach, we can build on the existing > > > > > , and we don't have to add a new > > > > > . > > > > > > > > > > We also don't have to change the current charter. > > > > > > > > > > > > > > > module ietf-event-notification { > > > > > namespace "urn:ietf:params:xml:ns:netconf:notification:1.0"; > > > > > prefix ev; > > > > > > > > > > rpc create-subscription { > > > > > input { > > > > > leaf stream { > > > > > type string; > > > > > } > > > > > choice filter-type { > > > > > case netconf-style { > > > > > anyxml filter; > > > > > } > > > > > case andy-style { // see Andy's proposal to the list > > > > > container filters { > > > > > list filter { ... } > > > > > } > > > > > } > > > > > case by-reference { > > > > > leaf filter-ref { ... } > > > > > } > > > > > } > > > > > leaf startTime { ... } > > > > > leaf stopTime { ... } > > > > > leaf return-subscription-id { > > > > > type empty; > > > > > description > > > > > "New leaf that old RFC5277 clients will never send. > > > > > > > > > > A new client that wants to use the new delete/modify > rpcs > > > > > need to set this in order to learn the id."; > > > > > } > > > > > } > > > > > output { > > > > > leaf subscription-id { > > > > > type uint32; > > > > > description > > > > > "Only present if the client passed > > > 'return-subscription-id' in > > > > > the rpc input params."; > > > > > } > > > > > } > > > > > } > > > > > > > > > > rpc delete-subscription { > > > > > input { > > > > > leaf subscription-id { > > > > > type uint32; > > > > > } > > > > > } > > > > > } > > > > > > > > > > rpc modify-subscription { > > > > > ... > > > > > } > > > > > } > > > > > > > > > > > > > > > In order to be fully backwards compatible, we also need to define a > > > > > YANG model with the streams: > > > > > > > > > > module ietf-netconf-notification-streams { > > > > > namespace "urn:ietf:params:xml:ns:netmod:notification"; > > > > > prefix ncstreams; > > > > > > > > > > container netconf { > > > > > config false; > > > > > container streams { > > > > > list stream { ... } > > > > > } > > > > > } > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > _______________________________________________ > > > > > Netconf mailing list > > > > > Netconf@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > --001a114f14e06e308f0542ef9930 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > Hi,
> > >
> > > I prefer the current solution approach, which is to use
> > > 'establish-subscription'.
> >
> > Can you elaborate on why you prefer two operations instead of one= ,
> > when they do the same thing?
> >
>
> because they don't do the same thing.
> The new solution has configured filters, subscription-id, suspend and<= br> > cancel operations

These are trivial extensions to the current solution.

If they are truly different the names should not be so similar.

> and should not need streams.

What do you mean "should not need streams"?



The streams concept is = half-baked and not useful.
We have 1 stream, NETCONF, which MUST = contain everything and
MUST be encoded in XML.=C2=A0 Every other = stream is purely ad-hoc and
proprietary, with no chance at intero= perability.

=C2=A0
> The old solution can be deprecated and replaced.

Sure, if it is broken.=C2=A0 But I don't think it is broken in any way.=



The <nofitication> element is ch= anging so old clients cannot
get the new version that contains a = subscription-id and other fields.
IMO it is simpler and clearer i= f the new solution is separate.


/martin


Andy
=C2=A0

> IMO this is much less confusing than trying to use create-subscription= .
>
>
> Andy
>
>
> > > There is no shortage of RPC names and no value in reusing > > > create-subscription.
> >
> > I think it is confusing to have two so similar operations with > > different names.
> >
> >
> > /martin
> >
> >
> > >
> > >
> > > Andy
> > >
> > >
> > > On Mon, Dec 5, 2016 at 10:55 AM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Martin Bjorklund <= mbj@tail-f.com> wrote:
> > > > > "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > >
> > > > [...]
> > > >
> > > > > > We absolutely want to have a full backwards c= ompatible capability.
> > > > > > The question is how to best frame this in doc= uments.=C2=A0 It is
> > possible
> > > > > > to rebuild RFC-5277 with a YANG model.=C2=A0 = But then you can't just
> > layer
> > > > > > on new capabilities driving this work.
> > > > >
> > > > > I think this in fact can be done.=C2=A0 I'll g= et back to this in a
> > separate
> > > > > email.
> > > >
> > > > Here's an example of how we can define a YANG modul= e that is backwards
> > > > compatible in the sense that an old client can talk to = a new server,
> > > > and new clients can use the new features when talking t= o new servers.
> > > >
> > > > With this approach, we can build on the existing
> > > > <create-subscription>, and we don't have to a= dd a new
> > > > <establish-subscription>.
> > > >
> > > > We also don't have to change the current charter. > > > >
> > > >
> > > >=C2=A0 =C2=A0module ietf-event-notification {
> > > >=C2=A0 =C2=A0 =C2=A0namespace "urn:ietf:params:xml:= ns:netconf:notification:1.0";
> > > >=C2=A0 =C2=A0 =C2=A0prefix ev;
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0rpc create-subscription {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0input {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf stream {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choice filter-type { > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case netconf-st= yle {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anyxml f= ilter;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case andy-style= { // see Andy's proposal to the list
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0containe= r filters {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0l= ist filter { ... }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case by-referen= ce {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf fil= ter-ref { ... }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf startTime { ... }=
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf stopTime { ... }<= br> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf return-subscripti= on-id {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type empty;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Ne= w leaf that old RFC5277 clients will never send.
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A new c= lient that wants to use the new delete/modify rpcs
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 need to= set this in order to learn the id.";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0output {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf subscription-id {=
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"On= ly present if the client passed
> > 'return-subscription-id' in
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the rpc= input params.";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0rpc delete-subscription {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0input {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf subscription-id {=
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0rpc modify-subscription {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0...
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > >
> > > > In order to be fully backwards compatible, we also need= to define a
> > > > YANG model with the streams:
> > > >
> > > >=C2=A0 =C2=A0module ietf-netconf-notification-strea= ms {
> > > >=C2=A0 =C2=A0 =C2=A0namespace "urn:ietf:params:xml:= ns:netmod:notification";
> > > >=C2=A0 =C2=A0 =C2=A0prefix ncstreams;
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0container netconf {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0config false;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0container streams {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list stream { ... } > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > >
> > > >
> > > >
> > > > /martin
> > > >
> > > > _______________________________________________ > > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/l= istinfo/netconf
> > > >
> >

--001a114f14e06e308f0542ef9930-- From nobody Mon Dec 5 13:34:58 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9E9129D95 for ; Mon, 5 Dec 2016 13:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 xM-nXGivZZR4 for ; Mon, 5 Dec 2016 13:34:56 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C9A21129D8A for ; Mon, 5 Dec 2016 13:34:44 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 5D22D1AE0118; Mon, 5 Dec 2016 22:34:43 +0100 (CET) Date: Mon, 05 Dec 2016 22:34:43 +0100 (CET) Message-Id: <20161205.223443.1094826795624770286.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20161205.214831.712192266937344872.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 21:34:58 -0000 Andy Bierman wrote: > On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund > > wrote: > > > > > > > Andy Bierman wrote: > > > > > Hi, > > > > > > > > > > I prefer the current solution approach, which is to use > > > > > 'establish-subscription'. > > > > > > > > Can you elaborate on why you prefer two operations instead of one, > > > > when they do the same thing? > > > > > > > > > > because they don't do the same thing. > > > The new solution has configured filters, subscription-id, suspend and > > > cancel operations > > > > These are trivial extensions to the current solution. > > > > If they are truly different the names should not be so similar. > > > > > and should not need streams. > > > > What do you mean "should not need streams"? > > > > > > The streams concept is half-baked and not useful. I strongly disagree. The stream concept including replay is very powerful. If you think it should be deprecated and replaced with something else, I think that requires some careful discussion first. (such as a description of its problems, and a description of a new solution). > We have 1 stream, NETCONF, which MUST contain everything No it doesn't. This was dicussed recently. The text says: This stream contains all NETCONF XML event notifications supported by the NETCONF server. Note it says "all NETCONF XML event notifications", not "all [XML] event notifications". > and > MUST be encoded in XML. Well, NETCONF is encoded in XML so this should not come as a surprise... > Every other stream is purely ad-hoc and > proprietary Not really. All streams supported can be discovered by any client (with proper access rights). > with no chance at interoperability. This is a false statement. We have defined several different streams that third party clients use w/o any problems. If a stream doesn't interoperate b/c of its name, some implementation is buggy. > > > The old solution can be deprecated and replaced. > > > > Sure, if it is broken. But I don't think it is broken in any way. > > > > > > > The element is changing so old clients cannot > get the new version that contains a subscription-id and other > fields. I haven't seen any proposal for doing this on the ML. > IMO it is simpler and clearer if the new solution is separate. Maybe. Anyway, my post was really in reply to Eric's statement that these new features could not be built on top of what we have and still be backwards compatible. One way of making streams even more useful is to make them configurable, e.g. instead of creating configurable filters, an idea is to create a new stream together with a filter, and replay definition. Being able to do this dynamically would actually be quite useful. /martin From nobody Mon Dec 5 15:16:41 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C1712960F for ; Mon, 5 Dec 2016 15:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 154x_Ws8GPYk for ; Mon, 5 Dec 2016 15:16:38 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2A812956A for ; Mon, 5 Dec 2016 15:16:38 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id c47so330429481qtc.2 for ; Mon, 05 Dec 2016 15:16:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CYwW8XJAJqK0r9Y2qnvITSl8gR4GrPIdimcaed/AWYQ=; b=Mmdndfi7RozDm5udpCJcFSXnN0I+iZKJD2RX/myXlMuefCyrutAM+EAyg2zdRwtKgU NJpC0pzGeuRMOONg3yBXFSzHE42kfuLnD2nN2HekKnfQmTjEPmRQKIYPPDnqXi7u5jN1 Wzb/FLShlspYLhXwyDr+hTf7150sy2xNTSAneiKMPh/aV3v0fZHEmgJTc1Vj7Y1Nh9yS mg62utpFECseL7nYVx+w7p3hqJMuh49U7iNHksgBXOZTWwEt/Tua2c9MfEQKdlWdyfJn 1Vzc64wMUlivfb048uwFO3ZneyuSxZOt3Pjsp21SIFkb8MI5/YhklR15wPsM42Mm8VDi qxAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CYwW8XJAJqK0r9Y2qnvITSl8gR4GrPIdimcaed/AWYQ=; b=beGJNxxIl0tqJqfpBWo7Pnzh9irQ0DcSjW+WUAUmSxYM6CjpTS2czamx6Mf26jzzEz fcqfm/EBaJ6g7VepuA64wsGmCZxGleoHHs13WY6aJ3eUzLCHsVRe4PbELUpXcPJaKdCM Q5HLvEzGjtwamFZc7Bz/kBTEROWxIlKgxWLu8fl2GNu3oFZhPFzY2S1PU3dI17GkcDlm wQP+I24tRcGeuxW5UonCQxgwScwBGFp8/+F3I5TKNISQhtZBiszl0Yd837OjQ9Hoz2Gc 0MTKfQTJl2cky0/JLj+/bPaLysTBpLPVfBnFvNvSyJGsOMv8KYCCRbNxbZI6q4EMqpo5 5apw== X-Gm-Message-State: AKaTC01khPys1oilDsjPVHY5uGAKnAgY4DLFWxbfTJr+0KJa7xiJq4QslQrr4kQ7kI21j4I9QpVh/agSZHu8WQ== X-Received: by 10.200.47.140 with SMTP id l12mr58101729qta.51.1480979797241; Mon, 05 Dec 2016 15:16:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Mon, 5 Dec 2016 15:16:36 -0800 (PST) In-Reply-To: <20161205.223443.1094826795624770286.mbj@tail-f.com> References: <20161205.214831.712192266937344872.mbj@tail-f.com> <20161205.223443.1094826795624770286.mbj@tail-f.com> From: Andy Bierman Date: Mon, 5 Dec 2016 15:16:36 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113572d8bc15500542f17a2d Archived-At: Cc: Netconf Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 23:16:40 -0000 --001a113572d8bc15500542f17a2d Content-Type: text/plain; charset=UTF-8 On Mon, Dec 5, 2016 at 1:34 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund > > > wrote: > > > > > > > > > Andy Bierman wrote: > > > > > > Hi, > > > > > > > > > > > > I prefer the current solution approach, which is to use > > > > > > 'establish-subscription'. > > > > > > > > > > Can you elaborate on why you prefer two operations instead of one, > > > > > when they do the same thing? > > > > > > > > > > > > > because they don't do the same thing. > > > > The new solution has configured filters, subscription-id, suspend and > > > > cancel operations > > > > > > These are trivial extensions to the current solution. > > > > > > If they are truly different the names should not be so similar. > > > > > > > and should not need streams. > > > > > > What do you mean "should not need streams"? > > > > > > > > > > The streams concept is half-baked and not useful. > > I strongly disagree. The stream concept including replay is very > powerful. > > If you think it should be deprecated and replaced with something else, > I think that requires some careful discussion first. (such as a > description of its problems, and a description of a new solution). > > > We have 1 stream, NETCONF, which MUST contain everything > > No it doesn't. This was dicussed recently. The text says: > > This stream contains all NETCONF XML event notifications supported by > the NETCONF server. > > Note it says "all NETCONF XML event notifications", not "all > [XML] event notifications". > > > and > > MUST be encoded in XML. > > Well, NETCONF is encoded in XML so this should not come as a > surprise... > One reason the new solution is needed is to properly separate the architectural layers, so it is not so NETCONF-specific. > > > Every other stream is purely ad-hoc and > > proprietary > > Not really. All streams supported can be discovered by any client > (with proper access rights). > > IMO a proper capability-driven framework is needed. A standard way to discover proprietary extensions is not the same thing. > > with no chance at interoperability. > > This is a false statement. We have defined several different streams > that third party clients use w/o any problems. If a stream doesn't > interoperate b/c of its name, some implementation is buggy. > > > > The old solution can be deprecated and replaced. > > > > > > Sure, if it is broken. But I don't think it is broken in any way. > > > > > > > > > > > The element is changing so old clients cannot > > get the new version that contains a subscription-id and other > > fields. > > I haven't seen any proposal for doing this on the ML. > It is in the drafts. The new element is changed. There will be a subscription-id field and maybe other fields added. Parsers will not be able to tell them apart without some hacks. > > > IMO it is simpler and clearer if the new solution is separate. > > Maybe. Anyway, my post was really in reply to Eric's statement that > these new features could not be built on top of what we have and still > be backwards compatible. > > One way of making streams even more useful is to make them > configurable, e.g. instead of creating configurable filters, an idea > is to create a new stream together with a filter, and replay > definition. Being able to do this dynamically would actually be quite > useful. > > I prefer to get rid of streams and just have filters. I don't see the value in both kinds of filters. The new solution tries to separate filtering, subscription management, transport protocol, and message encoding. IMO this is a much better architecture than the 'everything-is-hard-wired' approach in RFC 5277. It's not that 5277 is broken. It's just not a modern solution approach. A black & white TV doesn't need to be broken to get replaced by a color TV. I do not know if it is really important to allow YANG push and other new applications to work with 5277 subscriptions. They is a valid concern that the WG should decide. > > /martin > Andy --001a113572d8bc15500542f17a2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 5, 2016 at 1:34 PM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Andy Bierman <= andy@yumaworks.com> wrote:
> > > > > Hi,
> > > > >
> > > > > I prefer the current solution approach, which is t= o use
> > > > > 'establish-subscription'.
> > > >
> > > > Can you elaborate on why you prefer two operations inst= ead of one,
> > > > when they do the same thing?
> > > >
> > >
> > > because they don't do the same thing.
> > > The new solution has configured filters, subscription-id, su= spend and
> > > cancel operations
> >
> > These are trivial extensions to the current solution.
> >
> > If they are truly different the names should not be so similar. > >
> > > and should not need streams.
> >
> > What do you mean "should not need streams"?
> >
> >
>
> The streams concept is half-baked and not useful.

I strongly disagree.=C2=A0 The stream concept including replay is very
powerful.

If you think it should be deprecated and replaced with something else,
I think that requires some careful discussion first.=C2=A0 (such as a
description of its problems, and a description of a new solution).

> We have 1 stream, NETCONF, which MUST contain everything

No it doesn't.=C2=A0 This was dicussed recently.=C2=A0 The text says:
=C2=A0 =C2=A0This stream contains all NETCONF XML event notifications suppo= rted by
=C2=A0 =C2=A0the NETCONF server.

Note it says "all NETCONF XML event notifications", not "all=
[XML] event notifications".

> and
> MUST be encoded in XML.

Well, NETCONF is encoded in XML so this should not come as a
surprise...


One reason t= he new solution is needed is to properly separate the architectural layers,=
so it is not so NETCONF-specific.

=C2= =A0

> Every other stream is purely ad-hoc and
> proprietary

Not really.=C2=A0 All streams supported can be discovered by any client
(with proper access rights).



IMO a proper capability= -driven framework is needed.
A standard way to discover proprieta= ry extensions is not the same thing.

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

This is a false statement.=C2=A0 We have defined several different streams<= br> that third party clients use w/o any problems.=C2=A0 If a stream doesn'= t
interoperate b/c of its name, some implementation is buggy.=C2=A0
> > > The old solution can be deprecated and replaced.
> >
> > Sure, if it is broken.=C2=A0 But I don't think it is broken i= n any way.
> >
> >
> >
> The <nofitication> element is changing so old clients cannot
> get the new version that contains a subscription-id and other
> fields.

I haven't seen any proposal for doing this on the ML.
<= div>

It is in the drafts.
The new &l= t;notification> element is changed.
There will be a subscripti= on-id field and maybe other fields added.
Parsers will not be abl= e to tell them apart without some hacks.

=C2=A0

> IMO it is simpler and clearer if the new solution is separate.

Maybe.=C2=A0 Anyway, my post was really in reply to Eric's statement th= at
these new features could not be built on top of what we have and still
be backwards compatible.

One way of making streams even more useful is to make them
configurable, e.g. instead of creating configurable filters, an idea
is to create a new stream together with a filter, and replay
definition.=C2=A0 Being able to do this dynamically would actually be quite=
useful.


I prefer to get rid of streams and just have filters= .
I don't see the value in both kinds of filters.
<= br>
The new solution tries to separate filtering, subscription ma= nagement,
transport protocol, and message encoding.=C2=A0 IMO thi= s is a much better architecture
than the 'everything-is-hard-= wired' approach in RFC 5277.

It's not that= 5277 is broken. It's just not a modern solution approach.
A = black & white TV doesn't need to be broken to get replaced by a col= or TV.

I do not know if it is really important to = allow YANG push and other
new applications to work with 5277 subs= criptions.=C2=A0 They is a valid concern
that the WG should decid= e.


=C2=A0

/martin

Andy<= /div>

--001a113572d8bc15500542f17a2d-- From nobody Mon Dec 5 19:51:42 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B061294FD for ; Mon, 5 Dec 2016 19:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9ZeN7DrVqBhr for ; Mon, 5 Dec 2016 19:51:38 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3133129477 for ; Mon, 5 Dec 2016 19:51:37 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id n204so368174208qke.2 for ; Mon, 05 Dec 2016 19:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BIl5f730v7oAS1ett5YfXM9dyU+66Az0dIVx7IpkU9c=; b=b6SRELFqMRruM58hXWvjB9QjcypqNi6v/n6RHeirP+riq0nofl4PaCBFOdbX7YZ6z3 NBnx1QGny2dK1r/3JPqMYkvgul9uKLyqG3TjyOQZ9glua+GNn9sMgGbdq5hQ12bb7lcT UeJb2LM5ODegDg1oJBZpoeLaSIWAmih1bOYWe2y/iK96QWQa0b1ybf94FC9WdhN58Yyq hDqa4Ykl9w+dk3e7Tfb+bseCK94qPrO8Ubk8ymbJt0G6jLUHhVC13OYINAKADgXQCo60 b3VrlJFVetlK7sO8GRLww3oTXR3/rwNNeK+2g2Z4ygEaXhY6o5ql/B6+9RXGJ5yDLMSY sdXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BIl5f730v7oAS1ett5YfXM9dyU+66Az0dIVx7IpkU9c=; b=ZOJssrY+0eJstyyIL1XeJprYmUgD/Iftf+gv5i08ioEnxRfNGL5anDx82c/wOxo96u t9tds3IezVxhtxH6wBbe0uc9iGIQVJouCAiUPGqIhz5LxgJ2Xvfj0Pp0gSA3qMXoZAey c/O2l8HUBmS5oQMkI7L5w2KpbMmO+8No+dlJ5FBhzGDu5dZb6O01h39dsd6dRCdmUxv4 18iXr5/kHVI49OV8MPoGFXJkaxukJBr5gg6rq0WxVHmcLw3U9UhrWl8YrjoJD25dCFjd aCP9AxBTxnpJYvHLLvOhathjYKVzxaIowMR/cP5+bYOg2O2bbafg8m8IsEYI3GYIatwL iisQ== X-Gm-Message-State: AKaTC02kUTBNd/TcnaVzYykmxR0FrHx5aT98owlGcQCZ7R2p97nHRHXpTczGpw7shYsatC1KQ45wKJic40XaFw== X-Received: by 10.55.107.71 with SMTP id g68mr50353185qkc.259.1480996297036; Mon, 05 Dec 2016 19:51:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Mon, 5 Dec 2016 19:51:35 -0800 (PST) In-Reply-To: <20161205.223443.1094826795624770286.mbj@tail-f.com> References: <20161205.214831.712192266937344872.mbj@tail-f.com> <20161205.223443.1094826795624770286.mbj@tail-f.com> From: Andy Bierman Date: Mon, 5 Dec 2016 19:51:35 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a114ff8e832f34c0542f552d3 Archived-At: Cc: Netconf Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 03:51:40 -0000 --001a114ff8e832f34c0542f552d3 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 5, 2016 at 1:34 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund > > > wrote: > > > > > > > > > Andy Bierman wrote: > > > > > > Hi, > > > > > > > > > > > > I prefer the current solution approach, which is to use > > > > > > 'establish-subscription'. > > > > > > > > > > Can you elaborate on why you prefer two operations instead of one, > > > > > when they do the same thing? > > > > > > > > > > > > > because they don't do the same thing. > > > > The new solution has configured filters, subscription-id, suspend and > > > > cancel operations > > > > > > These are trivial extensions to the current solution. > > > > > > If they are truly different the names should not be so similar. > > > > > > > and should not need streams. > > > > > > What do you mean "should not need streams"? > > > > > > > > > > The streams concept is half-baked and not useful. > > I strongly disagree. The stream concept including replay is very > powerful. > > If you think it should be deprecated and replaced with something else, > I think that requires some careful discussion first. (such as a > description of its problems, and a description of a new solution). > > > We have 1 stream, NETCONF, which MUST contain everything > > No it doesn't. This was dicussed recently. The text says: > > This stream contains all NETCONF XML event notifications supported by > the NETCONF server. > > Note it says "all NETCONF XML event notifications", not "all > [XML] event notifications". > > > and > > MUST be encoded in XML. > > Well, NETCONF is encoded in XML so this should not come as a > surprise... > > > Every other stream is purely ad-hoc and > > proprietary > > Not really. All streams supported can be discovered by any client > (with proper access rights). > > > with no chance at interoperability. > > This is a false statement. We have defined several different streams > that third party clients use w/o any problems. If a stream doesn't > interoperate b/c of its name, some implementation is buggy. > > > > > The old solution can be deprecated and replaced. > > > > > > Sure, if it is broken. But I don't think it is broken in any way. > > > > > > > > > > > The element is changing so old clients cannot > > get the new version that contains a subscription-id and other > > fields. > > I haven't seen any proposal for doing this on the ML. > I was wrong -- the 5277bis-01 draft and yang-push-04 draft both reuse the notification element, instead of making a new notification element. Every single notification-stmt has to define a subscription-id leaf (yuch!). Every notification, like replay-complete, is redefined with a subscription-id leaf added to it. This really breaks the layering separation I thought was there. Perhaps the WG needs to agree on the 5277 reuse requirements before diving working on solution details. Andy > > IMO it is simpler and clearer if the new solution is separate. > > Maybe. Anyway, my post was really in reply to Eric's statement that > these new features could not be built on top of what we have and still > be backwards compatible. > > One way of making streams even more useful is to make them > configurable, e.g. instead of creating configurable filters, an idea > is to create a new stream together with a filter, and replay > definition. Being able to do this dynamically would actually be quite > useful. > > > /martin > --001a114ff8e832f34c0542f552d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 5, 2016 at 1:34 PM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Andy Bierman <= andy@yumaworks.com> wrote:
> > > > > Hi,
> > > > >
> > > > > I prefer the current solution approach, which is t= o use
> > > > > 'establish-subscription'.
> > > >
> > > > Can you elaborate on why you prefer two operations inst= ead of one,
> > > > when they do the same thing?
> > > >
> > >
> > > because they don't do the same thing.
> > > The new solution has configured filters, subscription-id, su= spend and
> > > cancel operations
> >
> > These are trivial extensions to the current solution.
> >
> > If they are truly different the names should not be so similar. > >
> > > and should not need streams.
> >
> > What do you mean "should not need streams"?
> >
> >
>
> The streams concept is half-baked and not useful.

I strongly disagree.=C2=A0 The stream concept including replay is very
powerful.

If you think it should be deprecated and replaced with something else,
I think that requires some careful discussion first.=C2=A0 (such as a
description of its problems, and a description of a new solution).

> We have 1 stream, NETCONF, which MUST contain everything

No it doesn't.=C2=A0 This was dicussed recently.=C2=A0 The text says:
=C2=A0 =C2=A0This stream contains all NETCONF XML event notifications suppo= rted by
=C2=A0 =C2=A0the NETCONF server.

Note it says "all NETCONF XML event notifications", not "all=
[XML] event notifications".

> and
> MUST be encoded in XML.

Well, NETCONF is encoded in XML so this should not come as a
surprise...

> Every other stream is purely ad-hoc and
> proprietary

Not really.=C2=A0 All streams supported can be discovered by any client
(with proper access rights).

> with no chance at interoperability.

This is a false statement.=C2=A0 We have defined several different streams<= br> that third party clients use w/o any problems.=C2=A0 If a stream doesn'= t
interoperate b/c of its name, some implementation is buggy.

> > > The old solution can be deprecated and replaced.
> >
> > Sure, if it is broken.=C2=A0 But I don't think it is broken i= n any way.
> >
> >
> >
> The <nofitication> element is changing so old clients cannot
> get the new version that contains a subscription-id and other
> fields.

I haven't seen any proposal for doing this on the ML.
<= div>


I was wrong -- the 5277bis= -01 draft and yang-push-04 draft both reuse the
notification elem= ent, instead of making a new notification element.
Every single n= otification-stmt has to define a subscription-id leaf (yuch!).
Ev= ery notification, like replay-complete, is redefined with a subscription-id= leaf
added to it. This really breaks the layering separation I t= hought was there.


Perhaps the WG ne= eds to agree on the 5277 reuse requirements
before diving working= on solution details.


Andy


> IMO it is simpler and clearer if the new solution is separate.

Maybe.=C2=A0 Anyway, my post was really in reply to Eric's statement th= at
these new features could not be built on top of what we have and still
be backwards compatible.

One way of making streams even more useful is to make them
configurable, e.g. instead of creating configurable filters, an idea
is to create a new stream together with a filter, and replay
definition.=C2=A0 Being able to do this dynamically would actually be quite=
useful.


/martin

--001a114ff8e832f34c0542f552d3-- From nobody Mon Dec 5 21:38:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA121296C4 for ; Mon, 5 Dec 2016 21:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.687 X-Spam-Level: X-Spam-Status: No, score=-6.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 GPleqcbLEn9L for ; Mon, 5 Dec 2016 21:38:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296861296C3 for ; Mon, 5 Dec 2016 21:38:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCA08602; Tue, 06 Dec 2016 05:38:50 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 6 Dec 2016 05:38:49 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 6 Dec 2016 13:38:44 +0800 From: Sureshbr To: "Netconf@ietf.org" Thread-Topic: unsubscribe Thread-Index: AdJPgi8NyH6kR8HaSvqqdQ0edyzbyA== Date: Tue, 6 Dec 2016 05:38:44 +0000 Message-ID: <14A81F29DC91904A8FBB7B3BE4CFF64E702C0394@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.231] Content-Type: multipart/alternative; boundary="_000_14A81F29DC91904A8FBB7B3BE4CFF64E702C0394NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58464EEB.0040, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ae1ec246257e6e403861e636fe652ca6 Archived-At: Subject: [Netconf] unsubscribe X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 05:38:58 -0000 --_000_14A81F29DC91904A8FBB7B3BE4CFF64E702C0394NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_14A81F29DC91904A8FBB7B3BE4CFF64E702C0394NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

--_000_14A81F29DC91904A8FBB7B3BE4CFF64E702C0394NKGEML515MBXchi_-- From nobody Mon Dec 5 22:33:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED25D1296D0 for ; Mon, 5 Dec 2016 22:33:23 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] 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 F8l7YMc1ob3n for ; Mon, 5 Dec 2016 22:33:21 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746F11296C2 for ; Mon, 5 Dec 2016 22:33:21 -0800 (PST) Received: from LAPTOPR7T053C2 ([47.143.86.36]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MfpSM-1bzljK1QSi-00NAXT; Tue, 06 Dec 2016 07:33:14 +0100 From: To: "'Andy Bierman'" , "'Martin Bjorklund'" References: <20161205.214831.712192266937344872.mbj@tail-f.com> <20161205.223443.1094826795624770286.mbj@tail-f.com> In-Reply-To: Date: Mon, 5 Dec 2016 22:33:09 -0800 Message-ID: <03b801d24f8a$9e2e20b0$da8a6210$@clemm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B9_01D24F47.900C8E60" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKQ3ybV2lGDD+YcROqElb7mJijkigIZPAadAYY5M/kCd7yuSQIUObR+nzv0k9A= Content-Language: en-us X-Provags-ID: V03:K0:4gOXkeeRdT+u+C0apWQDvsJQdI95ds/mkL87vyuY5XIKQy93e/j 3f/OAjZ5xPgIHJNnigcp0WCeBzoVEY/Dif6/BtumdEAGtiaWfRQ+WrFlyCqRombFr5yTeU1 IS8dsdYEJIc+kQTVmgwmvp1xvWt34DFbgkLjz1Q5vXdLYkc+xF7nqH6w1eAmpxkti9nbDt/ tSVBb23PzNDJQ1DNMb/yQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:EkZ82Dik3q4=:7+wA+QGFas4WUAFfjNoKyq RT7a+brWBqTHngpdlGzSGLJWzqlfL76MGlFHEgh0dWtRtSnFJ7ss9jEEBgNahAgzdWhLg0NwQ RPCzG0FlcdkWrCeu9vn73wkq4Dt1lb7OBCGduPS0mOENmfL0OlRJN0JSAFLpKnFU/CNlvJiRR 5cpuIwzZ2bifE/eLHCD6ZXB6fDM9+LaYHAS/EgjWBtJMMpTzKJVx2nYNU838ej8azy83WQSAD Pbs68eE4b9Kw5BjEZS8s6lLMl2HlrBNakeJcnm41jWm/BJ/sWPRxt79FYICRicVuaQwvudnfm hkaGiiP9/LpEe7KlCgc+kXCeZmC08wBvSZmikifgHsJpi5vvYNHE2Esxb7NEQNUjOm9QSDq8E uO0tM/5xvPXy1CQsiJR9NDwCw7qtb/iNVCHUcQ/8yG4VmfCyVoJA0y7T4+j9GoEbsfoJemS37 aifZW4l8GFGXmc69ijMWnrRqsWHcz60zStKdGsdicwnmT9gLh78HL4xY16ORX9P5iCObp17ga 2UlhNXiekxF/IaIyoMkclOgYjjyPrqO/7JHG1lnbtawbB4f27CTOn8VkUK3cgaEb8Fin1ITMD H4y0r3hfXzJjDUlJ7+qA+Vk2/w/0CP6LbS+zfuK+IHO+zkHXreCxna6eGVNu489PT/59ShK8S dQ3B7ZaT00WeIRnPKyw8vv33Gw5JYKdLHHQyEL19opOTyCiUWOnc3v4uZmS8VfzC4j6j/tSzf 2wTHBIkgOuviwtcT Archived-At: Cc: 'Netconf' Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 06:33:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03B9_01D24F47.900C8E60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 I have a couple of comments: =20 - I prefer a clear separation between and = . The differences seem clear enough. It is not = just parameters. It is also that and = are counterparts to (but = not create-subscription>. Trying to extend = introduces a lot of context dependencies. Also, there is still the = namespace problem that extensions and =E2=80=9Coriginal=E2=80=9D RPC = have to be in different namespaces (and are thus clearly distinguished) = anyway. I find cleaner that way. =20 - The YANG-push draft makes use of the notification statement. = Why wouldn=E2=80=99t it? This is part of the YANG language. As far as = RFC 5277bis and general event subscriptions are concerned, I do not = think that there is any implication that any notification needs to be = redefined with a subscription ID for it. Why? YANG-Push is a special = case in that notification contents can be highly customized per the = terms of the subscription, so including the subscription ID seems = reasonably, but in general you would not have to do that. =20 - I do think the stream metaphor is useful. However, I think = we really need to distinguish two concepts: The stream (that is being = subscribed to), and the stream (of messages actually delivered to the = client, with filtering, subscription policies etc all applied). =20 - The proposed set of =E2=80=9Cfilters=E2=80=9D (a term I find = confusing in that context IMHO, in particular as there is a secondary = set of filters of the subscription itself that would still be applied on = top) and existing concept of stream types appear fairly equivalent. = Both are used to simply refer to a sequence of messages/updates being = sent by the server, including content per a set of criteria = (preestablished for ease of use, but potentially also configurable). =20 =20 Thanks --- Alex =20 From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman Sent: Monday, December 5, 2016 7:52 PM To: Martin Bjorklund Cc: Netconf Subject: Re: [Netconf] review of "event-notification" documents =20 =20 =20 On Mon, Dec 5, 2016 at 1:34 PM, Martin Bjorklund > wrote: Andy Bierman > wrote: > On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund > wrote: > > > Andy Bierman > = wrote: > > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund > > > wrote: > > > > > > > Andy Bierman > = wrote: > > > > > Hi, > > > > > > > > > > I prefer the current solution approach, which is to use > > > > > 'establish-subscription'. > > > > > > > > Can you elaborate on why you prefer two operations instead of = one, > > > > when they do the same thing? > > > > > > > > > > because they don't do the same thing. > > > The new solution has configured filters, subscription-id, suspend = and > > > cancel operations > > > > These are trivial extensions to the current solution. > > > > If they are truly different the names should not be so similar. > > > > > and should not need streams. > > > > What do you mean "should not need streams"? > > > > > > The streams concept is half-baked and not useful. I strongly disagree. The stream concept including replay is very powerful. If you think it should be deprecated and replaced with something else, I think that requires some careful discussion first. (such as a description of its problems, and a description of a new solution). > We have 1 stream, NETCONF, which MUST contain everything No it doesn't. This was dicussed recently. The text says: This stream contains all NETCONF XML event notifications supported by the NETCONF server. Note it says "all NETCONF XML event notifications", not "all [XML] event notifications". > and > MUST be encoded in XML. Well, NETCONF is encoded in XML so this should not come as a surprise... > Every other stream is purely ad-hoc and > proprietary Not really. All streams supported can be discovered by any client (with proper access rights). > with no chance at interoperability. This is a false statement. We have defined several different streams that third party clients use w/o any problems. If a stream doesn't interoperate b/c of its name, some implementation is buggy. > > > The old solution can be deprecated and replaced. > > > > Sure, if it is broken. But I don't think it is broken in any way. > > > > > > > The element is changing so old clients cannot > get the new version that contains a subscription-id and other > fields. I haven't seen any proposal for doing this on the ML. =20 =20 =20 I was wrong -- the 5277bis-01 draft and yang-push-04 draft both reuse = the notification element, instead of making a new notification element. Every single notification-stmt has to define a subscription-id leaf = (yuch!). Every notification, like replay-complete, is redefined with a = subscription-id leaf added to it. This really breaks the layering separation I thought was = there. =20 =20 Perhaps the WG needs to agree on the 5277 reuse requirements before diving working on solution details. =20 =20 Andy =20 > IMO it is simpler and clearer if the new solution is separate. Maybe. Anyway, my post was really in reply to Eric's statement that these new features could not be built on top of what we have and still be backwards compatible. One way of making streams even more useful is to make them configurable, e.g. instead of creating configurable filters, an idea is to create a new stream together with a filter, and replay definition. Being able to do this dynamically would actually be quite useful. /martin =20 ------=_NextPart_000_03B9_01D24F47.900C8E60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, =

 

I have a = couple of comments:

 

-          = I prefer a = clear separation between <create-subscription> and = <establish-subscription>. =C2=A0The differences seem clear = enough.=C2=A0 It is not just parameters.=C2=A0 It is also that = <delete-subscription> and <modify-subscription> are = counterparts to <establish-subscription> (but not = create-subscription>.=C2=A0 Trying to extend = <create-subscription> introduces a lot of context = dependencies.=C2=A0 Also, there is still the namespace problem that = extensions and =E2=80=9Coriginal=E2=80=9D RPC have to be in different = namespaces (and are thus clearly distinguished) anyway.=C2=A0 I find = <establish-subscription> cleaner that way.=C2=A0 =

-          = The = YANG-push draft makes use of the notification statement.=C2=A0 Why = wouldn=E2=80=99t it?=C2=A0 This is part of the YANG language.=C2=A0 As = far as RFC 5277bis and general event subscriptions are concerned, I do = not think that there is any implication that any notification needs to = be redefined with a subscription ID for it. =C2=A0Why?=C2=A0 YANG-Push = is a special case in that notification contents can be highly customized = per the terms of the subscription, so including the subscription ID = seems reasonably, but in general you would not have to do that.=C2=A0 =

-          = I do think = the stream metaphor is useful. =C2=A0However, I think we really need to = distinguish two concepts:=C2=A0 The stream (that is being subscribed = to), and the stream (of messages actually delivered to the client, with = filtering, subscription policies etc all applied).=C2=A0 =

-          = The proposed = set of =E2=80=9Cfilters=E2=80=9D (a term I find confusing in that = context IMHO, in particular as there is a secondary set of filters of = the subscription itself that would still be applied on top) and existing = concept of stream types appear fairly equivalent. =C2=A0Both are used to = simply refer to a sequence of messages/updates being sent by the server, = including content per a set of criteria (preestablished for ease of use, = but potentially also configurable).=C2=A0 =C2=A0

 

Thanks

--- = Alex

 

From:<= /b> = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Monday, December 5, 2016 7:52 PM
To: = Martin Bjorklund <mbj@tail-f.com>
Cc: Netconf = <netconf@ietf.org>
Subject: Re: [Netconf] review of = "event-notification" documents

 

 

 

On Mon, = Dec 5, 2016 at 1:34 PM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Andy = Bierman <andy@yumaworks.com> = wrote:
> On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com> = wrote:
>
> > Andy Bierman <andy@yumaworks.com> = wrote:
> > > On Mon, Dec 5, 2016 at 12:37 PM, Martin = Bjorklund <mbj@tail-f.com>
> > = wrote:
> > >
> > > > Andy Bierman <andy@yumaworks.com> = wrote:
> > > > > Hi,
> > > > = >
> > > > > I prefer the current solution approach, = which is to use
> > > > > = 'establish-subscription'.
> > > >
> > > > = Can you elaborate on why you prefer two operations instead of = one,
> > > > when they do the same thing?
> > = > >
> > >
> > > because they don't do the = same thing.
> > > The new solution has configured filters, = subscription-id, suspend and
> > > cancel operations
> = >
> > These are trivial extensions to the current = solution.
> >
> > If they are truly different the = names should not be so similar.
> >
> > > and = should not need streams.
> >
> > What do you mean = "should not need streams"?
> >
> = >
>
> The streams concept is half-baked and not = useful.

I strongly disagree.  The stream concept including = replay is very
powerful.

If you think it should be deprecated = and replaced with something else,
I think that requires some careful = discussion first.  (such as a
description of its problems, and a = description of a new solution).

> We have 1 stream, NETCONF, = which MUST contain everything

No it doesn't.  This was = dicussed recently.  The text says:

   This stream = contains all NETCONF XML event notifications supported by
  =  the NETCONF server.

Note it says "all NETCONF XML = event notifications", not "all
[XML] event = notifications".

> and
> MUST be encoded in = XML.

Well, NETCONF is encoded in XML so this should not come as = a
surprise...

> Every other stream is purely ad-hoc = and
> proprietary

Not really.  All streams supported = can be discovered by any client
(with proper access = rights).

> with no chance at interoperability.

This is = a false statement.  We have defined several different = streams
that third party clients use w/o any problems.  If a = stream doesn't
interoperate b/c of its name, some implementation is = buggy.

> > > The old solution can be deprecated and = replaced.
> >
> > Sure, if it is broken.  But I = don't think it is broken in any way.
> >
> >
> = >
> The <nofitication> element is changing so old clients = cannot
> get the new version that contains a subscription-id and = other
> fields.

I haven't seen any proposal for doing this = on the ML.

 

 

 

I = was wrong -- the 5277bis-01 draft and yang-push-04 draft both reuse = the

notification element, = instead of making a new notification = element.

Every single = notification-stmt has to define a subscription-id leaf = (yuch!).

Every = notification, like replay-complete, is redefined with a subscription-id = leaf

added to it. This = really breaks the layering separation I thought was = there.

 

 

Perhaps the WG needs to agree on the 5277 reuse = requirements

before diving = working on solution details.

 

 

Andy

 


> = IMO it is simpler and clearer if the new solution is = separate.

Maybe.  Anyway, my post was really in reply to = Eric's statement that
these new features could not be built on top of = what we have and still
be backwards compatible.

One way of = making streams even more useful is to make them
configurable, e.g. = instead of creating configurable filters, an idea
is to create a new = stream together with a filter, and replay
definition.  Being = able to do this dynamically would actually be quite
useful.


/martin

 

------=_NextPart_000_03B9_01D24F47.900C8E60-- From nobody Tue Dec 6 02:23:17 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC5E129FA9 for ; Tue, 6 Dec 2016 02:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 ToNEsIJbLtzr for ; Tue, 6 Dec 2016 02:23:14 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C765129F8E for ; Tue, 6 Dec 2016 02:23:11 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E4481AE02BC; Tue, 6 Dec 2016 11:23:09 +0100 (CET) Date: Tue, 06 Dec 2016 11:23:09 +0100 (CET) Message-Id: <20161206.112309.670345130123099005.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20161205.223443.1094826795624770286.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 10:23:16 -0000 Andy Bierman wrote: > Perhaps the WG needs to agree on the 5277 reuse requirements > before diving working on solution details. +1 /martin From nobody Tue Dec 6 06:11:26 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081691294DC for ; Tue, 6 Dec 2016 06:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj7A84LnuHtc for ; Tue, 6 Dec 2016 06:11:21 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7801F1294D5 for ; Tue, 6 Dec 2016 06:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1445; q=dns/txt; s=iport; t=1481033481; x=1482243081; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nXjLK+PNBs4oRvTrZbKy4AstQKY2inWCmNZPymdriHk=; b=HiJCK5KlM4b1lZ2tStwD4vYrxIIWjSmbfvwBzR6U5Xm+JNmf1O/zFr0f 71F22lXE8/E3CkwojdHh2Bx+fBEcRy/WZDQY8aOSxD3NoP6+MRlKJqML5 itWrD6R7bBRcn8M4dZYbdMt8njfiGdWTzrcg3TKagebzONB0tErSaCWMj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBmxkZY/4YNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR+BYAeNQJcNlH6CB4YiAoIfPxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?oAQEBAwE6PQIFCwIBCA4HAw0REDIlAgQBDQUIE4hMCKwVi0MBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEchj6EW4oLHgEEiGKSBAGRDoF8hH2JT44DhA0BHzeBGYVVcog?= =?us-ascii?q?BgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208";a="178187086" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2016 14:11:20 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uB6EBKXR026880 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Dec 2016 14:11:20 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Dec 2016 09:11:19 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Tue, 6 Dec 2016 09:11:19 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund , "andy@yumaworks.com" Thread-Topic: [Netconf] review of "event-notification" documents Thread-Index: AQHSSbPRFuomS98NjUWN0bJG7+k/sKDu2loggAFQ0QD//9QRMIAJf/IAgACTgoCAABdbgIAABR8AgAABqgCAAAF1gIAAA8aAgAAJI4CAAGlMgIAAbWeA///ZesA= Date: Tue, 6 Dec 2016 14:11:19 +0000 Message-ID: References: <20161205.223443.1094826795624770286.mbj@tail-f.com> <20161206.112309.670345130123099005.mbj@tail-f.com> In-Reply-To: <20161206.112309.670345130123099005.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 14:11:24 -0000 > From: Martin Bjorklund December 6, 2016 5:23 AM >=20 > Andy Bierman wrote: > > Perhaps the WG needs to agree on the 5277 reuse requirements before > > diving working on solution details. >=20 > +1 Yes. We have been assuming reuse until now. This is what is in the WG ch= arter. And this is what we have been building to in the current draft set. There are no plans to change this direction unless the WG selects 'obsolete= ' over 'enhance'. There are benefits to each. Below is my summary for be= nefits of each path. Please add any that I might have missed... Benefits of 'enhance' ---------------------------- - Backwards compatibility through single integrated spec - Single codebase handles all subscription requests if legacy and new will = be running concurrently Benefits of 'obsolete' ---------------------------- - Simpler, smaller specification - Backwards compatibility through parallel implementation and capabilities = exchange - Subscriptions decoupled from NETCONF namespace - Fewer error conditions (e.g., what if you get two f= rom what you thought was a legacy client.) Worthy of discussion ---------------------------- - Interplay of streams and filters. Will/must obsolete vs enhance impact t= his decision? - How many RPCs, and how complex should they be? What are the impacts of o= verloading. Eric >=20 > /martin From nobody Tue Dec 6 06:32:06 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A4E1294EB for ; Tue, 6 Dec 2016 06:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_-Z6eQ-MEOg for ; Tue, 6 Dec 2016 06:32:03 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31EE912A132 for ; Tue, 6 Dec 2016 06:31:38 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id c47so347573792qtc.2 for ; Tue, 06 Dec 2016 06:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V6vWD5W1xmRJm31g0xIOYlTzSCfNvjb8hMEtcUvwBUU=; b=GHKCXeHOTVIACakoOTTEof6p9d1pzYBN5+iJzQCr8w4sSZHcgBEzpJa/56IRVzD9Fe 1p6Sq+o1eObbDalWadPWq8Qi37oM5quckm7ypo3xbityDvYIBdkC+AB+gQKYY/v3Ku9w +qkVsvnFPBbq1DH8t7CdEe+M7/L37rajQxjYIMUURmOnKb9Wr7XBZeP6DCoCpTexm/RB 1w+p+TFqasxzG/oD2GiKgIGCOeIxNjACPVUT7V1hqlrk6pLs4ndOOOYvPiLa178v5aoU LvnEQzJxKNy2JVju7JXyyHWMthxMxDBeU6rtwYK/qgtE9rJEOMmvvcPa9aMfq0QlC2Ov n5SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V6vWD5W1xmRJm31g0xIOYlTzSCfNvjb8hMEtcUvwBUU=; b=j9g6kap2b8z7wLapNdUaQIDTa2lfQm4lqdtAzkrJYK1cMfXVQmyQXE9bB+AtdBJAzA wit3cyuG7V9XJRLkM4ZPMRhewGAo+bjGU6bZ/g097KcgXtGB9mA0D7V3eYEdDjj8Rx2v Sfv0h+de4acYwJcuzadGXWGo7YertQ34PM+TcRgVZ38awa/yfufEFsIjrpD/pD6hvjZr Y4IHpxyJ6cZVJvguGxdh8RT/2vfsOW9pUWsST35OGo47BMsiY8iUl+1YVtDO74/hgIXG DQuEd/qj9yhMbJf0BzwX1SReaVXaAM6KEkNIQ7/So7Zeh17fEwxMKOVo8q5enn2NkaAF YsWA== X-Gm-Message-State: AKaTC01CqEujPLOiJOu24IfpQpktRp8Nx60Fsk1CY1K8MkdIS+umtg45H8nQvjDn25Dgcvr7+V1GuFDAMBnYMA== X-Received: by 10.200.43.5 with SMTP id 5mr55363222qtu.279.1481034697131; Tue, 06 Dec 2016 06:31:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Tue, 6 Dec 2016 06:31:35 -0800 (PST) In-Reply-To: References: <20161205.223443.1094826795624770286.mbj@tail-f.com> <20161206.112309.670345130123099005.mbj@tail-f.com> From: Andy Bierman Date: Tue, 6 Dec 2016 06:31:35 -0800 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a1147596a061a1d0542fe4371 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 14:32:05 -0000 --001a1147596a061a1d0542fe4371 Content-Type: text/plain; charset=UTF-8 Hi, The new solution design is completely broken unless a new notification wrapper is used or the subscription-id is removed from the design. There is no way this field can be defined as part of the event payload. Every notification has to define a field name 'subscription-id'? The identifier 'subscription-id' becomes reserved so it cannot be used anywhere list foo { key subscription-id; leaf subscription-id { type string; } notification bar; } How would a YANG 1.1 nested notification be supported? How would any existing notification-stmt that does not define this leaf be supported? How will multiple subscriptions be sent over the same connection? If 5277 support is so important then make it work by eliminating everything related to subscription IDs from the solution. IMO it would be better to design a new solution that is properly layered. Andy On Tue, Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) wrote: > > From: Martin Bjorklund December 6, 2016 5:23 AM > > > > Andy Bierman wrote: > > > Perhaps the WG needs to agree on the 5277 reuse requirements before > > > diving working on solution details. > > > > +1 > > Yes. We have been assuming reuse until now. This is what is in the WG > charter. And this is what we have been building to in the current draft > set. > > There are no plans to change this direction unless the WG selects > 'obsolete' over 'enhance'. There are benefits to each. Below is my > summary for benefits of each path. Please add any that I might have > missed... > > > Benefits of 'enhance' > ---------------------------- > - Backwards compatibility through single integrated spec > - Single codebase handles all subscription requests if legacy and new will > be running concurrently > > Benefits of 'obsolete' > ---------------------------- > - Simpler, smaller specification > - Backwards compatibility through parallel implementation and capabilities > exchange > - Subscriptions decoupled from NETCONF namespace > - Fewer error conditions (e.g., what if you get two > from what you thought was a legacy client.) > > Worthy of discussion > ---------------------------- > - Interplay of streams and filters. Will/must obsolete vs enhance impact > this decision? > - How many RPCs, and how complex should they be? What are the impacts of > overloading. > > > Eric > > > > > > /martin > --001a1147596a061a1d0542fe4371 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The new solution design is complete= ly broken unless a new notification wrapper is used
or the subscr= iption-id is removed from the design.=C2=A0 There is no way this field can = be defined
as part of the event payload.=C2=A0 Every notification= has to define a field name 'subscription-id'?
The identi= fier 'subscription-id' becomes reserved so it cannot be used anywhe= re

=C2=A0 list foo {
=C2=A0 =C2=A0 =C2= =A0key subscription-id;
=C2=A0 =C2=A0 =C2=A0leaf subscription-id = { type string; }
=C2=A0 =C2=A0 =C2=A0notification bar;
= =C2=A0 }

How would a YANG 1.1 nested notification = be supported?
How would any existing notification-stmt that d= oes not define this leaf be supported?
How will multiple subscrip= tions be sent over the same connection?

If 5277 su= pport is so important then make it work by eliminating everything
related to subscription IDs from the solution.=C2=A0 IMO it would be bette= r to
design a new solution that is properly layered.

Andy



On = Tue, Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:
> From: Martin Bjorklund Dec= ember 6, 2016 5:23 AM
>
> Andy Bierman <andy@yumaworks.= com> wrote:
> > Perhaps the WG needs to agree on the 5277 reuse requirements befo= re
> > diving working on solution details.
>
> +1

Yes.=C2=A0 =C2=A0We have been assuming reuse until now.=C2=A0 This is what = is in the WG charter.=C2=A0 And this is what we have been building to in th= e current draft set.

There are no plans to change this direction unless the WG selects 'obso= lete' over 'enhance'.=C2=A0 =C2=A0There are benefits to each.= =C2=A0 Below is my summary for benefits of each path.=C2=A0 Please add any = that I might have missed...


Benefits of 'enhance'
----------------------------
- Backwards compatibility through single integrated spec
- Single codebase handles all subscription requests if legacy and new will = be running concurrently

Benefits of 'obsolete'
----------------------------
- Simpler, smaller specification
- Backwards compatibility through parallel implementation and capabilities = exchange
- Subscriptions decoupled from NETCONF namespace
- Fewer error conditions (e.g., what if you get two <create-subscription= > from what you thought was a legacy client.)

Worthy of discussion
----------------------------
- Interplay of streams and filters.=C2=A0 Will/must obsolete vs enhance imp= act this decision?
- How many RPCs, and how complex should they be?=C2=A0 What are the impacts= of overloading.


Eric


>
> /martin

--001a1147596a061a1d0542fe4371-- From nobody Tue Dec 6 07:29:28 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5CB129853 for ; Tue, 6 Dec 2016 07:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 oOXMBHVItsAO for ; Tue, 6 Dec 2016 07:29:15 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 06E3712984F for ; Tue, 6 Dec 2016 07:29:14 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 983291AE02BC; Tue, 6 Dec 2016 16:29:12 +0100 (CET) Date: Tue, 06 Dec 2016 16:29:12 +0100 (CET) Message-Id: <20161206.162912.565827667614626853.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20161206.112309.670345130123099005.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 15:29:17 -0000 Andy Bierman wrote: > Hi, > > The new solution design is completely broken unless a new notification > wrapper is used I agree. The current XSD in 5277 is very inflexible; it would be useful with a structure that allows some flexibility, specifically allows new "header" fields to be added w/o having to modify the protocol. I.e., allow elements from other namespaces after the built-in elements (event-time, subscription-id). If we want to do this protocol-agnostic, we should define XML and JSON encoding of notifications in one document; the general concepts of streams and filters etc in one docuement; protocol-specific mechanisms to retrieve data from streams in another (unfortunately, we can't define protocol-agnostic rpc operations for this, since these operations only work for session-based protocols) /martin > or the subscription-id is removed from the design. There is no way this > field can be defined > as part of the event payload. Every notification has to define a field > name 'subscription-id'? > The identifier 'subscription-id' becomes reserved so it cannot be used > anywhere > > list foo { > key subscription-id; > leaf subscription-id { type string; } > notification bar; > } > > How would a YANG 1.1 nested notification be supported? > How would any existing notification-stmt that does not define this leaf be > supported? > How will multiple subscriptions be sent over the same connection? > > If 5277 support is so important then make it work by eliminating everything > related to subscription IDs from the solution. IMO it would be better to > design a new solution that is properly layered. > > > Andy > > > > > On Tue, Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) wrote: > > > > From: Martin Bjorklund December 6, 2016 5:23 AM > > > > > > Andy Bierman wrote: > > > > Perhaps the WG needs to agree on the 5277 reuse requirements before > > > > diving working on solution details. > > > > > > +1 > > > > Yes. We have been assuming reuse until now. This is what is in the WG > > charter. And this is what we have been building to in the current draft > > set. > > > > There are no plans to change this direction unless the WG selects > > 'obsolete' over 'enhance'. There are benefits to each. Below is my > > summary for benefits of each path. Please add any that I might have > > missed... > > > > > > Benefits of 'enhance' > > ---------------------------- > > - Backwards compatibility through single integrated spec > > - Single codebase handles all subscription requests if legacy and new will > > be running concurrently > > > > Benefits of 'obsolete' > > ---------------------------- > > - Simpler, smaller specification > > - Backwards compatibility through parallel implementation and capabilities > > exchange > > - Subscriptions decoupled from NETCONF namespace > > - Fewer error conditions (e.g., what if you get two > > from what you thought was a legacy client.) > > > > Worthy of discussion > > ---------------------------- > > - Interplay of streams and filters. Will/must obsolete vs enhance impact > > this decision? > > - How many RPCs, and how complex should they be? What are the impacts of > > overloading. > > > > > > Eric > > > > > > > > > > /martin > > From nobody Tue Dec 6 07:30:41 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497D4129865 for ; Tue, 6 Dec 2016 07:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQQwPlammJ4C for ; Tue, 6 Dec 2016 07:30:30 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB8B1296B8 for ; Tue, 6 Dec 2016 07:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19286; q=dns/txt; s=iport; t=1481038230; x=1482247830; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qiV4S66SYsonJJZoTCW9TPNFq7MEFIsDuyejQR9A9IQ=; b=A21C7GENncXAFr7/BMHSAQJhHfsxmnvgUSn1liHBBr7GPe2j6l185NFq FSrWqgFV72utlx2sesbpjxZg7to8zJwJkgpxDsl0ZIAWieRXKdYOd7D53 gfWrXEwuiGv1q7PwqzKy+u0kQe+HY+fQ5ojnCLFm7Vkhw2kBSChrRAW3/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQBS2UZY/5NdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnNGAQEBAQEfWoEGB41Alw2PXIUiggeGIgIaggY/FAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEDASMKSgIFCwIBCBUDDRoDAgICMBQRAgQBDQUIE4hMCKk2gimLQ?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBARyGPoRbhH6CToI/HgWIYoYdhWiFfwGRDoF?= =?us-ascii?q?8hH2EU4R8jgOEDQEfNzBpI4UycogBgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208,217";a="178225920" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2016 15:30:08 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uB6FU76B030882 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Dec 2016 15:30:08 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Dec 2016 10:30:01 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Tue, 6 Dec 2016 10:30:01 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , "alex@clemm.org" , "Alberto Gonzalez Prieto (albertgo)" Thread-Topic: [Netconf] review of "event-notification" documents Thread-Index: AQHSSbPRFuomS98NjUWN0bJG7+k/sKDu2loggAFQ0QD//9QRMIAJf/IAgACTgoCAABdbgIAABR8AgAABqgCAAAF1gIAAA8aAgAAJI4CAAGlMgIAAbWeA///ZesCAAGvvgP//rn7Q Date: Tue, 6 Dec 2016 15:30:01 +0000 Message-ID: References: <20161205.223443.1094826795624770286.mbj@tail-f.com> <20161206.112309.670345130123099005.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_de4da7c7370240e1a4fa2568f105cd3aXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 15:30:39 -0000 --_000_de4da7c7370240e1a4fa2568f105cd3aXCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhlIHdheSB3ZSB3ZXJlIGFwcHJvYWNoaW5nIGl0IHdhcyB0byBoYXZlIHRo ZSA1Mjc3IG5vdGlmaWNhdGlvbiBlbGVtZW50IGJlIHVzZWQgd2hlbiA8Y3JlYXRlLXN1YnNjcmlw dGlvbj4gUlBDIHN0YXJ0ZWQgdGhlIHN1YnNjcmlwdGlvbiwgYW5kIGEgbm90aWZpY2F0aW9uIGVs ZW1lbnQgd2hpY2ggaW5jbHVkZXMg4oCcc3Vic2NyaXB0aW9uLWlk4oCdIGJlIHVzZWQgd2l0aCB0 aGUgPGVzdGFibGlzaC1zdWJzY3JpcHRpb24+IFJQQy4gIFdlIG5ldmVyIGV4cGVjdGVkIHRoZSB0 d28gbWl4ZWQgb24gdGhlIHNhbWUgdHJhbnNwb3J0LiAgIFRoaXMgc2Vjb25kIHdheSBpcyB3aGF0 IHdhcyB1c2VkIGluIHRoZSBpbXBsZW1lbnRhdGlvbnMgd2l0aCBPcGVuRGF5bGlnaHQuDQoNCkhh dmluZyB0d28gZGlmZmVyZW50IG5vdGlmaWNhdGlvbiB0eXBlIHJlc3VsdCBmcm9tIHRoZSBzYW1l IDxjcmVhdGUtc3Vic2NyaXB0aW9uPiBSUEMgaXMgc29tZXRoaW5nIHdlIHNob3VsZCB0cnkgdG8g YXZvaWQuICBJdCBpcyB3aGF0IEkgd2FzIHRyeWluZyB0byBjYXB0dXJlIGJlbG93IHdpdGggdGhl IGJ1bGxldHMg4oCYZmV3ZXIgZXJyb3IgY29uZGl0aW9uc+KAmSBhbmQgUlBDIG92ZXJsb2FkaW5n Lg0KDQpUaGUgY3VycmVudCA1Mjc3YmlzIFNlY3Rpb24gNiBleGFtcGxlcyBkbyBub3QgY3VycmVu dGx5IHNob3cgdGhlIHN1YnNjcmlwdGlvbi1pZCBicmVha2Rvd24gZm9yIG5vdGlmaWNhdGlvbnMu ICBUaGlzIHdhcyBhbiBvdmVyc2lnaHQgb2Ygd2UgYXV0aG9ycy4gIEkgb25seSByZWNvZ25pemVk IHRoaXMgYSBmZXcgd2Vla3MgYWdvIChzZWUgYWdlbmRhIGZvciBsYXN0IFdlYkV4KS4gIEkgYWdy ZWUgdGhlIHVsdGltYXRlIHNvbHV0aW9uIG11c3QgcHJvcGVybHkgcGFyc2Ugb3V0IHN1YnNjcmlw dGlvbi1pZC4NCg0KQWxzbyBvbiB5b3VyIG5vdGVzIGJlbG93IEkgd291bGQgbG92ZSB0byBiZXR0 ZXIgdW5kZXJzdGFuZCB0aGUgbmVzdGVkIG5vdGlmaWNhdGlvbiBpdGVtLCBiZWNhdXNlIHRoYXQg aXMgc29tZXRoaW5nIEkgaGF2ZW7igJl0IHRob3VnaHQgYWJvdXQuDQoNClVsdGltYXRlbHksIEkg YmVsaWV2ZSB0aGVzZSBub3RpZmljYXRpb24gY29tcGxleGl0aWVzIHByb3ZpZGUgYW5vdGhlciBl eGFtcGxlIHdoeSDigJhvYnNvbGV0ZeKAmSBpcyBzaW1wbGVyIHRoYW4g4oCYZW5oYW5jZeKAmS4N Cg0KRXJpYw0KDQpGcm9tOiBBbmR5IEJpZXJtYW4sIERlY2VtYmVyIDYsIDIwMTYgOTozMiBBTQ0K DQpIaSwNCg0KVGhlIG5ldyBzb2x1dGlvbiBkZXNpZ24gaXMgY29tcGxldGVseSBicm9rZW4gdW5s ZXNzIGEgbmV3IG5vdGlmaWNhdGlvbiB3cmFwcGVyIGlzIHVzZWQNCm9yIHRoZSBzdWJzY3JpcHRp b24taWQgaXMgcmVtb3ZlZCBmcm9tIHRoZSBkZXNpZ24uICBUaGVyZSBpcyBubyB3YXkgdGhpcyBm aWVsZCBjYW4gYmUgZGVmaW5lZA0KYXMgcGFydCBvZiB0aGUgZXZlbnQgcGF5bG9hZC4gIEV2ZXJ5 IG5vdGlmaWNhdGlvbiBoYXMgdG8gZGVmaW5lIGEgZmllbGQgbmFtZSAnc3Vic2NyaXB0aW9uLWlk Jz8NClRoZSBpZGVudGlmaWVyICdzdWJzY3JpcHRpb24taWQnIGJlY29tZXMgcmVzZXJ2ZWQgc28g aXQgY2Fubm90IGJlIHVzZWQgYW55d2hlcmUNCg0KICBsaXN0IGZvbyB7DQogICAgIGtleSBzdWJz Y3JpcHRpb24taWQ7DQogICAgIGxlYWYgc3Vic2NyaXB0aW9uLWlkIHsgdHlwZSBzdHJpbmc7IH0N CiAgICAgbm90aWZpY2F0aW9uIGJhcjsNCiAgfQ0KDQpIb3cgd291bGQgYSBZQU5HIDEuMSBuZXN0 ZWQgbm90aWZpY2F0aW9uIGJlIHN1cHBvcnRlZD8NCkhvdyB3b3VsZCBhbnkgZXhpc3Rpbmcgbm90 aWZpY2F0aW9uLXN0bXQgdGhhdCBkb2VzIG5vdCBkZWZpbmUgdGhpcyBsZWFmIGJlIHN1cHBvcnRl ZD8NCkhvdyB3aWxsIG11bHRpcGxlIHN1YnNjcmlwdGlvbnMgYmUgc2VudCBvdmVyIHRoZSBzYW1l IGNvbm5lY3Rpb24/DQoNCklmIDUyNzcgc3VwcG9ydCBpcyBzbyBpbXBvcnRhbnQgdGhlbiBtYWtl IGl0IHdvcmsgYnkgZWxpbWluYXRpbmcgZXZlcnl0aGluZw0KcmVsYXRlZCB0byBzdWJzY3JpcHRp b24gSURzIGZyb20gdGhlIHNvbHV0aW9uLiAgSU1PIGl0IHdvdWxkIGJlIGJldHRlciB0bw0KZGVz aWduIGEgbmV3IHNvbHV0aW9uIHRoYXQgaXMgcHJvcGVybHkgbGF5ZXJlZC4NCg0KDQpBbmR5DQoN Cg0KDQoNCk9uIFR1ZSwgRGVjIDYsIDIwMTYgYXQgNjoxMSBBTSwgRXJpYyBWb2l0IChldm9pdCkg PGV2b2l0QGNpc2NvLmNvbTxtYWlsdG86ZXZvaXRAY2lzY28uY29tPj4gd3JvdGU6DQo+IEZyb206 IE1hcnRpbiBCam9ya2x1bmQgRGVjZW1iZXIgNiwgMjAxNiA1OjIzIEFNDQo+DQo+IEFuZHkgQmll cm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PiB3cm90 ZToNCj4gPiBQZXJoYXBzIHRoZSBXRyBuZWVkcyB0byBhZ3JlZSBvbiB0aGUgNTI3NyByZXVzZSBy ZXF1aXJlbWVudHMgYmVmb3JlDQo+ID4gZGl2aW5nIHdvcmtpbmcgb24gc29sdXRpb24gZGV0YWls cy4NCj4NCj4gKzENCg0KWWVzLiAgIFdlIGhhdmUgYmVlbiBhc3N1bWluZyByZXVzZSB1bnRpbCBu b3cuICBUaGlzIGlzIHdoYXQgaXMgaW4gdGhlIFdHIGNoYXJ0ZXIuICBBbmQgdGhpcyBpcyB3aGF0 IHdlIGhhdmUgYmVlbiBidWlsZGluZyB0byBpbiB0aGUgY3VycmVudCBkcmFmdCBzZXQuDQoNClRo ZXJlIGFyZSBubyBwbGFucyB0byBjaGFuZ2UgdGhpcyBkaXJlY3Rpb24gdW5sZXNzIHRoZSBXRyBz ZWxlY3RzICdvYnNvbGV0ZScgb3ZlciAnZW5oYW5jZScuICAgVGhlcmUgYXJlIGJlbmVmaXRzIHRv IGVhY2guICBCZWxvdyBpcyBteSBzdW1tYXJ5IGZvciBiZW5lZml0cyBvZiBlYWNoIHBhdGguICBQ bGVhc2UgYWRkIGFueSB0aGF0IEkgbWlnaHQgaGF2ZSBtaXNzZWQuLi4NCg0KDQpCZW5lZml0cyBv ZiAnZW5oYW5jZScNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0gQmFja3dhcmRzIGNv bXBhdGliaWxpdHkgdGhyb3VnaCBzaW5nbGUgaW50ZWdyYXRlZCBzcGVjDQotIFNpbmdsZSBjb2Rl YmFzZSBoYW5kbGVzIGFsbCBzdWJzY3JpcHRpb24gcmVxdWVzdHMgaWYgbGVnYWN5IGFuZCBuZXcg d2lsbCBiZSBydW5uaW5nIGNvbmN1cnJlbnRseQ0KDQpCZW5lZml0cyBvZiAnb2Jzb2xldGUnDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotIFNpbXBsZXIsIHNtYWxsZXIgc3BlY2lmaWNh dGlvbg0KLSBCYWNrd2FyZHMgY29tcGF0aWJpbGl0eSB0aHJvdWdoIHBhcmFsbGVsIGltcGxlbWVu dGF0aW9uIGFuZCBjYXBhYmlsaXRpZXMgZXhjaGFuZ2UNCi0gU3Vic2NyaXB0aW9ucyBkZWNvdXBs ZWQgZnJvbSBORVRDT05GIG5hbWVzcGFjZQ0KLSBGZXdlciBlcnJvciBjb25kaXRpb25zIChlLmcu LCB3aGF0IGlmIHlvdSBnZXQgdHdvIDxjcmVhdGUtc3Vic2NyaXB0aW9uPiBmcm9tIHdoYXQgeW91 IHRob3VnaHQgd2FzIGEgbGVnYWN5IGNsaWVudC4pDQoNCldvcnRoeSBvZiBkaXNjdXNzaW9uDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotIEludGVycGxheSBvZiBzdHJlYW1zIGFuZCBm aWx0ZXJzLiAgV2lsbC9tdXN0IG9ic29sZXRlIHZzIGVuaGFuY2UgaW1wYWN0IHRoaXMgZGVjaXNp b24/DQotIEhvdyBtYW55IFJQQ3MsIGFuZCBob3cgY29tcGxleCBzaG91bGQgdGhleSBiZT8gIFdo YXQgYXJlIHRoZSBpbXBhY3RzIG9mIG92ZXJsb2FkaW5nLg0KDQoNCkVyaWMNCg0KDQo+DQo+IC9t YXJ0aW4NCg0K --_000_de4da7c7370240e1a4fa2568f105cd3aXCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQW5keSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSB3YXkgd2Ugd2VyZSBh cHByb2FjaGluZyBpdCB3YXMgdG8gaGF2ZSB0aGUgNTI3NyBub3RpZmljYXRpb24gZWxlbWVudCBi ZSB1c2VkIHdoZW4gJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IFJQQyBzdGFydGVkIHRoZSBz dWJzY3JpcHRpb24sIGFuZCBhIG5vdGlmaWNhdGlvbiBlbGVtZW50DQogd2hpY2ggaW5jbHVkZXMg 4oCcc3Vic2NyaXB0aW9uLWlk4oCdIGJlIHVzZWQgd2l0aCB0aGUgJmx0O2VzdGFibGlzaC1zdWJz Y3JpcHRpb24mZ3Q7IFJQQy4mbmJzcDsgV2UgbmV2ZXIgZXhwZWN0ZWQgdGhlIHR3byBtaXhlZCBv biB0aGUgc2FtZSB0cmFuc3BvcnQuJm5ic3A7ICZuYnNwO1RoaXMgc2Vjb25kIHdheSBpcyB3aGF0 IHdhcyB1c2VkIGluIHRoZSBpbXBsZW1lbnRhdGlvbnMgd2l0aCBPcGVuRGF5bGlnaHQuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhhdmluZyB0d28gZGlmZmVy ZW50IG5vdGlmaWNhdGlvbiB0eXBlIHJlc3VsdCBmcm9tIHRoZSBzYW1lICZsdDtjcmVhdGUtc3Vi c2NyaXB0aW9uJmd0OyBSUEMgaXMgc29tZXRoaW5nIHdlIHNob3VsZCB0cnkgdG8gYXZvaWQuJm5i c3A7IEl0IGlzIHdoYXQgSSB3YXMgdHJ5aW5nIHRvIGNhcHR1cmUNCiBiZWxvdyB3aXRoIHRoZSBi dWxsZXRzIOKAmGZld2VyIGVycm9yIGNvbmRpdGlvbnPigJkgYW5kIFJQQyBvdmVybG9hZGluZy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBjdXJyZW50IDUy NzdiaXMgU2VjdGlvbiA2IGV4YW1wbGVzIGRvIG5vdCBjdXJyZW50bHkgc2hvdyB0aGUgc3Vic2Ny aXB0aW9uLWlkIGJyZWFrZG93biBmb3Igbm90aWZpY2F0aW9ucy4gJm5ic3A7VGhpcyB3YXMgYW4g b3ZlcnNpZ2h0IG9mIHdlIGF1dGhvcnMuJm5ic3A7IEkgb25seSByZWNvZ25pemVkDQogdGhpcyBh IGZldyB3ZWVrcyBhZ28gKHNlZSBhZ2VuZGEgZm9yIGxhc3QgV2ViRXgpLiZuYnNwOyBJIGFncmVl IHRoZSB1bHRpbWF0ZSBzb2x1dGlvbiBtdXN0IHByb3Blcmx5IHBhcnNlIG91dCBzdWJzY3JpcHRp b24taWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbHNvIG9u IHlvdXIgbm90ZXMgYmVsb3cgSSB3b3VsZCBsb3ZlIHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSBu ZXN0ZWQgbm90aWZpY2F0aW9uIGl0ZW0sIGJlY2F1c2UgdGhhdCBpcyBzb21ldGhpbmcgSSBoYXZl buKAmXQgdGhvdWdodCBhYm91dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlVsdGltYXRlbHksIEkgYmVsaWV2ZSB0aGVzZSBub3RpZmljYXRpb24gY29tcGxleGl0 aWVzIHByb3ZpZGUgYW5vdGhlciBleGFtcGxlIHdoeSDigJhvYnNvbGV0ZeKAmSBpcyBzaW1wbGVy IHRoYW4g4oCYZW5oYW5jZeKAmS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+RXJpYw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5keSBCaWVybWFuLCBEZWNlbWJlciA2LCAyMDE2 IDk6MzIgQU08YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG5ldyBzb2x1dGlvbiBkZXNpZ24gaXMgY29tcGxl dGVseSBicm9rZW4gdW5sZXNzIGEgbmV3IG5vdGlmaWNhdGlvbiB3cmFwcGVyIGlzIHVzZWQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9yIHRoZSBz dWJzY3JpcHRpb24taWQgaXMgcmVtb3ZlZCBmcm9tIHRoZSBkZXNpZ24uJm5ic3A7IFRoZXJlIGlz IG5vIHdheSB0aGlzIGZpZWxkIGNhbiBiZSBkZWZpbmVkPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hcyBwYXJ0IG9mIHRoZSBldmVudCBwYXlsb2Fk LiZuYnNwOyBFdmVyeSBub3RpZmljYXRpb24gaGFzIHRvIGRlZmluZSBhIGZpZWxkIG5hbWUgJ3N1 YnNjcmlwdGlvbi1pZCc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgaWRlbnRpZmllciAnc3Vic2NyaXB0aW9uLWlkJyBiZWNvbWVzIHJlc2Vy dmVkIHNvIGl0IGNhbm5vdCBiZSB1c2VkIGFueXdoZXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBsaXN0IGZvbyB7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 ICZuYnNwO2tleSBzdWJzY3JpcHRpb24taWQ7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2xlYWYgc3Vic2NyaXB0 aW9uLWlkIHsgdHlwZSBzdHJpbmc7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7bm90aWZpY2F0aW9uIGJhcjs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhvdyB3b3VsZCBhIFlBTkcgMS4xIG5lc3RlZCBub3RpZmljYXRpb24gYmUgc3VwcG9ydGVkPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IHdv dWxkIGFueSBleGlzdGluZyBub3RpZmljYXRpb24tc3RtdCB0aGF0IGRvZXMgbm90IGRlZmluZSB0 aGlzIGxlYWYgYmUgc3VwcG9ydGVkPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SG93IHdpbGwgbXVsdGlwbGUgc3Vic2NyaXB0aW9ucyBiZSBzZW50 IG92ZXIgdGhlIHNhbWUgY29ubmVjdGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgNTI3NyBzdXBwb3J0IGlzIHNvIGltcG9ydGFudCB0 aGVuIG1ha2UgaXQgd29yayBieSBlbGltaW5hdGluZyBldmVyeXRoaW5nPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWxhdGVkIHRvIHN1YnNjcmlw dGlvbiBJRHMgZnJvbSB0aGUgc29sdXRpb24uJm5ic3A7IElNTyBpdCB3b3VsZCBiZSBiZXR0ZXIg dG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRl c2lnbiBhIG5ldyBzb2x1dGlvbiB0aGF0IGlzIHByb3Blcmx5IGxheWVyZWQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU dWUsIERlYyA2LCAyMDE2IGF0IDY6MTEgQU0sIEVyaWMgVm9pdCAoZXZvaXQpICZsdDs8YSBocmVm PSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXZvaXRAY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgRnJvbTog TWFydGluIEJqb3JrbHVuZCBEZWNlbWJlciA2LCAyMDE2IDU6MjMgQU08YnI+DQomZ3Q7PGJyPg0K Jmd0OyBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20i PmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyBQZXJoYXBz IHRoZSBXRyBuZWVkcyB0byBhZ3JlZSBvbiB0aGUgNTI3NyByZXVzZSByZXF1aXJlbWVudHMgYmVm b3JlPGJyPg0KJmd0OyAmZ3Q7IGRpdmluZyB3b3JraW5nIG9uIHNvbHV0aW9uIGRldGFpbHMuPGJy Pg0KJmd0Ozxicj4NCiZndDsgJiM0MzsxPGJyPg0KPGJyPg0KWWVzLiZuYnNwOyAmbmJzcDtXZSBo YXZlIGJlZW4gYXNzdW1pbmcgcmV1c2UgdW50aWwgbm93LiZuYnNwOyBUaGlzIGlzIHdoYXQgaXMg aW4gdGhlIFdHIGNoYXJ0ZXIuJm5ic3A7IEFuZCB0aGlzIGlzIHdoYXQgd2UgaGF2ZSBiZWVuIGJ1 aWxkaW5nIHRvIGluIHRoZSBjdXJyZW50IGRyYWZ0IHNldC48YnI+DQo8YnI+DQpUaGVyZSBhcmUg bm8gcGxhbnMgdG8gY2hhbmdlIHRoaXMgZGlyZWN0aW9uIHVubGVzcyB0aGUgV0cgc2VsZWN0cyAn b2Jzb2xldGUnIG92ZXIgJ2VuaGFuY2UnLiZuYnNwOyAmbmJzcDtUaGVyZSBhcmUgYmVuZWZpdHMg dG8gZWFjaC4mbmJzcDsgQmVsb3cgaXMgbXkgc3VtbWFyeSBmb3IgYmVuZWZpdHMgb2YgZWFjaCBw YXRoLiZuYnNwOyBQbGVhc2UgYWRkIGFueSB0aGF0IEkgbWlnaHQgaGF2ZSBtaXNzZWQuLi48YnI+ DQo8YnI+DQo8YnI+DQpCZW5lZml0cyBvZiAnZW5oYW5jZSc8YnI+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KLSBCYWNrd2FyZHMgY29tcGF0aWJpbGl0eSB0aHJvdWdoIHNpbmds ZSBpbnRlZ3JhdGVkIHNwZWM8YnI+DQotIFNpbmdsZSBjb2RlYmFzZSBoYW5kbGVzIGFsbCBzdWJz Y3JpcHRpb24gcmVxdWVzdHMgaWYgbGVnYWN5IGFuZCBuZXcgd2lsbCBiZSBydW5uaW5nIGNvbmN1 cnJlbnRseTxicj4NCjxicj4NCkJlbmVmaXRzIG9mICdvYnNvbGV0ZSc8YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KLSBTaW1wbGVyLCBzbWFsbGVyIHNwZWNpZmljYXRpb248 YnI+DQotIEJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHRocm91Z2ggcGFyYWxsZWwgaW1wbGVtZW50 YXRpb24gYW5kIGNhcGFiaWxpdGllcyBleGNoYW5nZTxicj4NCi0gU3Vic2NyaXB0aW9ucyBkZWNv dXBsZWQgZnJvbSBORVRDT05GIG5hbWVzcGFjZTxicj4NCi0gRmV3ZXIgZXJyb3IgY29uZGl0aW9u cyAoZS5nLiwgd2hhdCBpZiB5b3UgZ2V0IHR3byAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsg ZnJvbSB3aGF0IHlvdSB0aG91Z2h0IHdhcyBhIGxlZ2FjeSBjbGllbnQuKTxicj4NCjxicj4NCldv cnRoeSBvZiBkaXNjdXNzaW9uPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N Ci0gSW50ZXJwbGF5IG9mIHN0cmVhbXMgYW5kIGZpbHRlcnMuJm5ic3A7IFdpbGwvbXVzdCBvYnNv bGV0ZSB2cyBlbmhhbmNlIGltcGFjdCB0aGlzIGRlY2lzaW9uPzxicj4NCi0gSG93IG1hbnkgUlBD cywgYW5kIGhvdyBjb21wbGV4IHNob3VsZCB0aGV5IGJlPyZuYnNwOyBXaGF0IGFyZSB0aGUgaW1w YWN0cyBvZiBvdmVybG9hZGluZy48YnI+DQo8YnI+DQo8YnI+DQpFcmljPGJyPg0KPGJyPg0KPGJy Pg0KJmd0Ozxicj4NCiZndDsgL21hcnRpbjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_de4da7c7370240e1a4fa2568f105cd3aXCHRTP013ciscocom_-- From nobody Tue Dec 6 07:52:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2021299F7 for ; Tue, 6 Dec 2016 07:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 ayk8Xsz2DSNF for ; Tue, 6 Dec 2016 07:52:44 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A408129853 for ; Tue, 6 Dec 2016 07:52:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 855D3750; Tue, 6 Dec 2016 16:52:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dKqTcUk8rQkH; Tue, 6 Dec 2016 16:52:39 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 6 Dec 2016 16:52:41 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 149F220067; Tue, 6 Dec 2016 16:52:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id leY887NYen11; Tue, 6 Dec 2016 16:52:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1EC2E20063; Tue, 6 Dec 2016 16:52:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C31E53D9FC9A; Tue, 6 Dec 2016 16:52:39 +0100 (CET) Date: Tue, 6 Dec 2016 16:52:39 +0100 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Message-ID: <20161206155239.GA98983@elstar.local> Mail-Followup-To: "Eric Voit (evoit)" , Martin Bjorklund , "andy@yumaworks.com" , "netconf@ietf.org" References: <20161205.223443.1094826795624770286.mbj@tail-f.com> <20161206.112309.670345130123099005.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 15:52:54 -0000 On Tue, Dec 06, 2016 at 02:11:19PM +0000, Eric Voit (evoit) wrote: > > From: Martin Bjorklund December 6, 2016 5:23 AM > > > > Andy Bierman wrote: > > > Perhaps the WG needs to agree on the 5277 reuse requirements before > > > diving working on solution details. > > > > +1 > > Yes. We have been assuming reuse until now. This is what is in the WG charter. And this is what we have been building to in the current draft set. > > There are no plans to change this direction unless the WG selects 'obsolete' over 'enhance'. There are benefits to each. Below is my summary for benefits of each path. Please add any that I might have missed... > I do not have a strong opinion on this but I think it is worth commenting on some of your benefits - and to perhaps provide an opinion of someone who is just observing things. > Benefits of 'enhance' > ---------------------------- > - Backwards compatibility through single integrated spec Backwards compatibility is a property of a design, it does not matter how many specs are used to write the design down. > - Single codebase handles all subscription requests if legacy and new will be running concurrently This is a pure implementation issue. A single codebase can be used to support N subscription interfaces equally well. > Benefits of 'obsolete' > ---------------------------- > - Simpler, smaller specification > - Backwards compatibility through parallel implementation and capabilities exchange Again, backwards compatibility is a property of a design. Apparently, it can't be used as an argument to both 'enhance' and 'obsolete'. > - Subscriptions decoupled from NETCONF namespace > - Fewer error conditions (e.g., what if you get two from what you thought was a legacy client.) So these seem to be some arguments here (not sure how strong they are). > Worthy of discussion > ---------------------------- > - Interplay of streams and filters. Will/must obsolete vs enhance impact this decision? > - How many RPCs, and how complex should they be? What are the impacts of overloading. It seems to me that RFC 5277 is pretty much tied to NETCONF/SSH and that having a much more flexible subscription mechanism as suggested goes pretty far beyond what RFC 5277 did, both in functionality but also in trying to support different protocols carrying notifications. Given that the changes relative to RFC 5277 are significant, it makes sense to me to view the proposal as a new event subscription interface and not as an extension of RFC 5277. Concerning RFC 5277, it may be desirable to make a minor update (e.g., to get rid of the XSD and to use YANG) but whether this is worth the effort I do not know. Perhaps RFC 5277 is good enough to let it rest in peace. /js PS: Note that I have not implemented any of this, hence my opinion should likely not count too much. -- 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 Dec 6 08:14:20 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4D0129508 for ; Tue, 6 Dec 2016 08:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 lNLTvlRFiS2s for ; Tue, 6 Dec 2016 08:14:17 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BEA129476 for ; Tue, 6 Dec 2016 08:14:16 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id n6so351150084qtd.1 for ; Tue, 06 Dec 2016 08:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jsaumyXHs6hcbFQutI9Ql1uJURhQel6yP0gYFUFBNLY=; b=BzVTV9vZ9N9H39XBug8BDB5CHbdd3A1DxWH2pZFDDHDCxWF9z8JBiDQ8un4DZl+UhJ zXwxk2GXfpYne7GVj6QgGu3g2neGR1fPF1CDFISEZyAP/AZ5Mju8PQhZ4NCw78vNXeIE PZfMSpqX+Qg2H7IWB0a8H1nZgoG9eJXAlBYBljsNeSojzxTdkyx35cj+RyZwxYyhk9LU +64gBpz/iol/2fzbxeD8F8Xwe3tTEzk4ousZ6oqsjGN1i5fihnRoRUdGkj18X449r46f F3oWpyByruLulT8flmWQ8uDnz2qvdmGWrb+E4mCewLnMfmKqIs02cTBv92enXVbwtr3G QjeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jsaumyXHs6hcbFQutI9Ql1uJURhQel6yP0gYFUFBNLY=; b=lISSPZk7lQV+7WeWAW2SRO0jjByV6X7RojFTsWz5G9C95LWyu17i7oplKXPkYSDnZ4 ScFpBeHedWSXvo2/oxNpz7xgRvd2L7WIiHJHTAWGcFQC+vC9XlzEfhyjCzg0KpAjucDv xY2tsM7QJzJJAJ4pSkl+T6wCnA7RU4/3sPEJhFPzTR8DQxtUUnWhzta+9/8fESzx2PXP oKxfX3Gz+n2ZzIM77KtwC1RSdXv0tP0Ja4mayRMKV5c83BJo0PlZRLmdcEoMwYoGSPHd JaQOqiPbsw0T7E6xeD04eSFHPNWA3YsFQivlZ1tooSSLE9HSZrGsZSIAr4pGvLOUfk/v 9MtQ== X-Gm-Message-State: AKaTC02kVF3Rry3ZG6CzTYCFeiKnxw1Q3wbb9b98ZN3oEaW0qLhvRnNd4v0Q4X0mncezPtSqo+QiFKaKHwCNgw== X-Received: by 10.200.47.140 with SMTP id l12mr61496623qta.51.1481040855752; Tue, 06 Dec 2016 08:14:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Tue, 6 Dec 2016 08:14:14 -0800 (PST) In-Reply-To: <20161206155239.GA98983@elstar.local> References: <20161205.223443.1094826795624770286.mbj@tail-f.com> <20161206.112309.670345130123099005.mbj@tail-f.com> <20161206155239.GA98983@elstar.local> From: Andy Bierman Date: Tue, 6 Dec 2016 08:14:14 -0800 Message-ID: To: Juergen Schoenwaelder , "Eric Voit (evoit)" , Martin Bjorklund , "andy@yumaworks.com" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=001a113572d81af9340542ffb2ca Archived-At: Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 16:14:19 -0000 --001a113572d81af9340542ffb2ca Content-Type: text/plain; charset=UTF-8 On Tue, Dec 6, 2016 at 7:52 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Dec 06, 2016 at 02:11:19PM +0000, Eric Voit (evoit) wrote: > > > From: Martin Bjorklund December 6, 2016 5:23 AM > > > > > > Andy Bierman wrote: > > > > Perhaps the WG needs to agree on the 5277 reuse requirements before > > > > diving working on solution details. > > > > > > +1 > > > > Yes. We have been assuming reuse until now. This is what is in the WG > charter. And this is what we have been building to in the current draft > set. > > > > There are no plans to change this direction unless the WG selects > 'obsolete' over 'enhance'. There are benefits to each. Below is my > summary for benefits of each path. Please add any that I might have > missed... > > > > I do not have a strong opinion on this but I think it is worth > commenting on some of your benefits - and to perhaps provide an > opinion of someone who is just observing things. > > > Benefits of 'enhance' > > ---------------------------- > > - Backwards compatibility through single integrated spec > > Backwards compatibility is a property of a design, it does not matter > how many specs are used to write the design down. > > > - Single codebase handles all subscription requests if legacy and new > will be running concurrently > > This is a pure implementation issue. A single codebase can be used > to support N subscription interfaces equally well. > > > Benefits of 'obsolete' > > ---------------------------- > > - Simpler, smaller specification > > - Backwards compatibility through parallel implementation and > capabilities exchange > > Again, backwards compatibility is a property of a design. Apparently, > it can't be used as an argument to both 'enhance' and 'obsolete'. > > > - Subscriptions decoupled from NETCONF namespace > > - Fewer error conditions (e.g., what if you get two > from what you thought was a legacy client.) > > So these seem to be some arguments here (not sure how strong they are). > Actually this is another area that the new solution is really broken. The RPCs ignore and instead invent their own error system using identities. This does not scale well because it requires clients to write special error handling code for each RPC, instead of 1 system that handles all messages. Andy > > > Worthy of discussion > > ---------------------------- > > - Interplay of streams and filters. Will/must obsolete vs enhance > impact this decision? > > - How many RPCs, and how complex should they be? What are the impacts > of overloading. > > It seems to me that RFC 5277 is pretty much tied to NETCONF/SSH and > that having a much more flexible subscription mechanism as suggested > goes pretty far beyond what RFC 5277 did, both in functionality but > also in trying to support different protocols carrying notifications. > Given that the changes relative to RFC 5277 are significant, it makes > sense to me to view the proposal as a new event subscription interface > and not as an extension of RFC 5277. > > Concerning RFC 5277, it may be desirable to make a minor update (e.g., > to get rid of the XSD and to use YANG) but whether this is worth the > effort I do not know. Perhaps RFC 5277 is good enough to let it rest > in peace. > > /js > > PS: Note that I have not implemented any of this, hence my opinion > should likely not count too much. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a113572d81af9340542ffb2ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 6, 2016 at 7:52 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Dec 06, 2016 at 02:11:19PM +0000, Eric Voit (= evoit) wrote:
> > From: Martin Bjorklund December 6, 2016 5:23 AM
> >
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > Perhaps the WG needs to agree on the 5277 reuse requirements= before
> > > diving working on solution details.
> >
> > +1
>
> Yes.=C2=A0 =C2=A0We have been assuming reuse until now.=C2=A0 This is = what is in the WG charter.=C2=A0 And this is what we have been building to = in the current draft set.
>
> There are no plans to change this direction unless the WG selects '= ;obsolete' over 'enhance'.=C2=A0 =C2=A0There are benefits to ea= ch.=C2=A0 Below is my summary for benefits of each path.=C2=A0 Please add a= ny that I might have missed...
>

I do not have a strong opinion on this but I think it is worth
commenting on some of your benefits - and to perhaps provide an
opinion of someone who is just observing things.

> Benefits of 'enhance'
> ----------------------------
> - Backwards compatibility through single integrated spec

Backwards compatibility is a property of a design, it does not matter
how many specs are used to write the design down.

> - Single codebase handles all subscription requests if legacy and new = will be running concurrently

This is a pure implementation issue. A single codebase can be used
to support N subscription interfaces equally well.

> Benefits of 'obsolete'
> ----------------------------
> - Simpler, smaller specification
> - Backwards compatibility through parallel implementation and capabili= ties exchange

Again, backwards compatibility is a property of a design. Apparently,
it can't be used as an argument to both 'enhance' and 'obso= lete'.

> - Subscriptions decoupled from NETCONF namespace
> - Fewer error conditions (e.g., what if you get two <create-subscri= ption> from what you thought was a legacy client.)

So these seem to be some arguments here (not sure how strong they are).
=


Actually this is another ar= ea that the new solution is really broken.
The RPCs ignore <rp= c-error> and instead invent their own error system
using ident= ities.=C2=A0 This does not scale well because it requires clients =C2=A0to<= /div>
write special error handling code for each RPC, instead of 1 syst= em that
handles all <rpc-error> messages.



Andy
=C2=A0

> Worthy of discussion
> ----------------------------
> - Interplay of streams and filters.=C2=A0 Will/must obsolete vs enhanc= e impact this decision?
> - How many RPCs, and how complex should they be?=C2=A0 What are the im= pacts of overloading.

It seems to me that RFC 5277 is pretty much tied to NETCONF/SSH and
that having a much more flexible subscription mechanism as suggested
goes pretty far beyond what RFC 5277 did, both in functionality but
also in trying to support different protocols carrying notifications.
Given that the changes relative to RFC 5277 are significant, it makes
sense to me to view the proposal as a new event subscription interface
and not as an extension of RFC 5277.

Concerning RFC 5277, it may be desirable to make a minor update (e.g.,
to get rid of the XSD and to use YANG) but whether this is worth the
effort I do not know. Perhaps RFC 5277 is good enough to let it rest
in peace.

/js

PS: Note that I have not implemented any of this, hence my opinion
=C2=A0 =C2=A0 should likely not count too much.

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

--001a113572d81af9340542ffb2ca-- From nobody Tue Dec 6 10:07:42 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F7A129544 for ; Tue, 6 Dec 2016 10:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyomT9rFmB1G for ; Tue, 6 Dec 2016 10:07:39 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B73129543 for ; Tue, 6 Dec 2016 10:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3933; q=dns/txt; s=iport; t=1481047659; x=1482257259; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WxN4Z4euLtZtHZK3u7dqedHvz6Jh6gubw+JWxO8GYvo=; b=VBwn1kChCkSbRuYDyningzTC3/tJKVu2qmx/NrIGWMSosgfev994n4d7 sWezeTxpo1TNoxohu9VRw4qWejCtMS/8+9wqr7da1LtBkRZzBByA26rNm VOTIqAa9c4ymjF4LGcRl80XzKjnNi1lmwTyDZ8iUL4Qls/ch7fdrtDlLe M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQDK/EZY/40NJK1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM5AQEBAQEfWoEGB41Alw2UfoIHJYV9AoIjPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBAwE6PQIFCQICAQgOAgUDDREQGxclAgQOBQgTiEwIrBSLQwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARwFhjmEW4RpJoR8HgWIYpIEAZEOgXyEfYlPh2GGIoQ?= =?us-ascii?q?NAR83gRmDXByBXXKIAYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208";a="183753142" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2016 18:07:38 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uB6I7ckM014676 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Dec 2016 18:07:38 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Dec 2016 13:07:37 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Tue, 6 Dec 2016 13:07:37 -0500 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder Thread-Topic: [Netconf] review of "event-notification" documents Thread-Index: AQHSSbPRFuomS98NjUWN0bJG7+k/sKDu2loggAFQ0QD//9QRMIAJf/IAgACTgoCAABdbgIAABR8AgAABqgCAAAF1gIAAA8aAgAAJI4CAAGlMgIAAbWeA///ZesCAAIKVgP//zRjQ Date: Tue, 6 Dec 2016 18:07:37 +0000 Message-ID: References: <20161205.223443.1094826795624770286.mbj@tail-f.com> <20161206.112309.670345130123099005.mbj@tail-f.com> <20161206155239.GA98983@elstar.local> In-Reply-To: <20161206155239.GA98983@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 18:07:41 -0000 > From: Juergen Schoenwaelder, December 6, 2016 10:53 AM >=20 > On Tue, Dec 06, 2016 at 02:11:19PM +0000, Eric Voit (evoit) wrote: > > > From: Martin Bjorklund December 6, 2016 5:23 AM > > > > > > Andy Bierman wrote: > > > > Perhaps the WG needs to agree on the 5277 reuse requirements > > > > before diving working on solution details. > > > > > > +1 > > > > Yes. We have been assuming reuse until now. This is what is in the W= G > charter. And this is what we have been building to in the current draft = set. > > > > There are no plans to change this direction unless the WG selects 'obso= lete' > over 'enhance'. There are benefits to each. Below is my summary for be= nefits > of each path. Please add any that I might have missed... > > >=20 > I do not have a strong opinion on this but I think it is worth commenting= on > some of your benefits - and to perhaps provide an opinion of someone who = is > just observing things. >=20 > > Benefits of 'enhance' > > ---------------------------- > > - Backwards compatibility through single integrated spec >=20 > Backwards compatibility is a property of a design, it does not matter how= many > specs are used to write the design down. >=20 > > - Single codebase handles all subscription requests if legacy and new > > will be running concurrently >=20 > This is a pure implementation issue. A single codebase can be used to sup= port N > subscription interfaces equally well. Agree on your two points above. Note that I am simply doing my best to ref= lect arguments in favor of 'enhance'. I don't actually believe that 'enhan= ce' is the right path.=20 > > Benefits of 'obsolete' > > ---------------------------- > > - Simpler, smaller specification > > - Backwards compatibility through parallel implementation and > > capabilities exchange >=20 > Again, backwards compatibility is a property of a design. Apparently, it = can't be > used as an argument to both 'enhance' and 'obsolete'. >=20 > > - Subscriptions decoupled from NETCONF namespace > > - Fewer error conditions (e.g., what if you get two > > from what you thought was a legacy client.) >=20 > So these seem to be some arguments here (not sure how strong they are). >=20 > > Worthy of discussion > > ---------------------------- > > - Interplay of streams and filters. Will/must obsolete vs enhance impa= ct this > decision? > > - How many RPCs, and how complex should they be? What are the impacts > of overloading. >=20 > It seems to me that RFC 5277 is pretty much tied to NETCONF/SSH and that > having a much more flexible subscription mechanism as suggested goes pret= ty > far beyond what RFC 5277 did, both in functionality but also in trying to > support different protocols carrying notifications. > Given that the changes relative to RFC 5277 are significant, it makes sen= se to > me to view the proposal as a new event subscription interface and not as = an > extension of RFC 5277. >=20 > Concerning RFC 5277, it may be desirable to make a minor update (e.g., to= get > rid of the XSD and to use YANG) but whether this is worth the effort I do= not > know. Perhaps RFC 5277 is good enough to let it rest in peace. Rest-in-peace was the conclusion of a number of us in the Dezign team. I = am not sure if there is anyone actively advocating for 'enhance'. Martin h= as made some reasonable proposals on how elements might be approached shoul= d the WG want to continue down this path. Eric =20 > /js >=20 > PS: Note that I have not implemented any of this, hence my opinion > should likely not count too much. >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue Dec 6 10:27:53 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF20A129567 for ; Tue, 6 Dec 2016 10:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwyvP0WynFO6 for ; Tue, 6 Dec 2016 10:27:49 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08CC2129569 for ; Tue, 6 Dec 2016 10:27:46 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id p16so353851867qta.0 for ; Tue, 06 Dec 2016 10:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nJpW2vunrzfT47Ojtck8DLfHWTJG8HmikmOaQu2ylug=; b=Uii13SLeWzffeFwz5yUKDsACXhrjRY5jOEeEbsxUN4r28QLXCvECeM+nUpt46NiJno Jq2MUSkR0i2+i5jzd6KyYMtSO66Zb/bSaEBBjMDdKaN637G+dhqxXG7QzqnNkTBbF6DQ 3LfzlgNTlmX/ELytA4kiIAEzin1xkUQEDED5xKIPfu8KQG3To578VDHTDUuF57S1t75l av+ci5MAhOvVLwgYck6s4T/AAOnyAfDEEi3Erlya/kqDJZl1GhZ5nN2DsX0kjLVQpdNt y4/vhwQgmUaHd+JD7fA8Uqt1N60IH6Dqk5EhWU4x55m/LGAc2AQAxkubqg7UWkLrPH8S DwJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nJpW2vunrzfT47Ojtck8DLfHWTJG8HmikmOaQu2ylug=; b=Zp2kdyhencBje3jeScfHUfgD2IJRQm6kaMb868urZkKMn/ZFjxJ9pjh6by1hnX4OqC y5Ww8IPbuzRa66FH4B7DtheAA8IGU48evi3hAkxy6bA1g/zLCQIaULoQJUpr5bMuRduL zgaOQnE3zT91U3XbwLU4FDdA4HnGLSctVL/xlzTe5Odl85vFZM7gbbPT6wwLgbzzlrpN DZ9MxyY8e80K4UYh4D5MmNsCwl24GyGevCjIF2sSacGYnOOcJThtZiVAlksk08aZ1mxc JYhsAJEGiYwGTLR/AhimBnwWewuND1N604yLGkDMexN4+pHRHD10hQOAGRD0Dre0axp4 2j0A== X-Gm-Message-State: AKaTC022Aa0VnQuNGx7ICaAB2i9g2gbXTdGdiO4L31VpCnE4bLhIbjnUMroHSpRqDVDpMuo4RpcEHCKd/ZTltg== X-Received: by 10.200.35.110 with SMTP id b43mr64680458qtb.265.1481048865109; Tue, 06 Dec 2016 10:27:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Tue, 6 Dec 2016 10:27:43 -0800 (PST) In-Reply-To: <20161206.162912.565827667614626853.mbj@tail-f.com> References: <20161206.112309.670345130123099005.mbj@tail-f.com> <20161206.162912.565827667614626853.mbj@tail-f.com> From: Andy Bierman Date: Tue, 6 Dec 2016 10:27:43 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1147ec808042780543018ff4 Archived-At: Cc: Netconf Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 18:27:52 -0000 --001a1147ec808042780543018ff4 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 6, 2016 at 7:29 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > The new solution design is completely broken unless a new notification > > wrapper is used > > I agree. The current XSD in 5277 is very inflexible; it would be > useful with a structure that allows some flexibility, specifically > allows new "header" fields to be added w/o having to modify the > protocol. I.e., allow elements from other namespaces after the > built-in elements (event-time, subscription-id). > > This inflexibility has been a problem. I think a new element in a different namespace would be better. Clients that use the new header MUST accept and ignore unknown header fields. (Examples have namespaces omitted) 1 4242 // ... maybe more fields here // normal notification contents or YANG 1.1 nested: 1 4242 // ... maybe more fields here eth0 // normal notification contents If we want to do this protocol-agnostic, we should define XML and JSON > encoding of notifications in one document; the general concepts of > streams and filters etc in one docuement; protocol-specific mechanisms > to retrieve data from streams in another (unfortunately, we can't > define protocol-agnostic rpc operations for this, since these > operations only work for session-based protocols) > > It would be better if the element could be modeled in YANG so it can be augmented and also it would be encoding-independent. (e.g. YANG to CBOR could be used) > > > /martin > > > Andy > > > or the subscription-id is removed from the design. There is no way this > > field can be defined > > as part of the event payload. Every notification has to define a field > > name 'subscription-id'? > > The identifier 'subscription-id' becomes reserved so it cannot be used > > anywhere > > > > list foo { > > key subscription-id; > > leaf subscription-id { type string; } > > notification bar; > > } > > > > How would a YANG 1.1 nested notification be supported? > > How would any existing notification-stmt that does not define this leaf > be > > supported? > > How will multiple subscriptions be sent over the same connection? > > > > If 5277 support is so important then make it work by eliminating > everything > > related to subscription IDs from the solution. IMO it would be better to > > design a new solution that is properly layered. > > > > > > Andy > > > > > > > > > > On Tue, Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) > wrote: > > > > > > From: Martin Bjorklund December 6, 2016 5:23 AM > > > > > > > > Andy Bierman wrote: > > > > > Perhaps the WG needs to agree on the 5277 reuse requirements before > > > > > diving working on solution details. > > > > > > > > +1 > > > > > > Yes. We have been assuming reuse until now. This is what is in the > WG > > > charter. And this is what we have been building to in the current > draft > > > set. > > > > > > There are no plans to change this direction unless the WG selects > > > 'obsolete' over 'enhance'. There are benefits to each. Below is my > > > summary for benefits of each path. Please add any that I might have > > > missed... > > > > > > > > > Benefits of 'enhance' > > > ---------------------------- > > > - Backwards compatibility through single integrated spec > > > - Single codebase handles all subscription requests if legacy and new > will > > > be running concurrently > > > > > > Benefits of 'obsolete' > > > ---------------------------- > > > - Simpler, smaller specification > > > - Backwards compatibility through parallel implementation and > capabilities > > > exchange > > > - Subscriptions decoupled from NETCONF namespace > > > - Fewer error conditions (e.g., what if you get two > > > > from what you thought was a legacy client.) > > > > > > Worthy of discussion > > > ---------------------------- > > > - Interplay of streams and filters. Will/must obsolete vs enhance > impact > > > this decision? > > > - How many RPCs, and how complex should they be? What are the impacts > of > > > overloading. > > > > > > > > > Eric > > > > > > > > > > > > > > /martin > > > > --001a1147ec808042780543018ff4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 6, 2016 at 7:29 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> The new solution design is completely broken unless a new notification=
> wrapper is used

I agree.=C2=A0 The current XSD in 5277 is very inflexible; it would be
useful with a structure that allows some flexibility, specifically
allows new "header" fields to be added w/o having to modify the protocol.=C2=A0 =C2=A0I.e., allow elements from other namespaces after the<= br> built-in elements (event-time, subscription-id).



This inflexibility has = been a problem.
I think a new element in a different namespace wo= uld be better.
Clients that use the new header MUST accept and ig= nore unknown header fields.

(Examples have namespa= ces omitted)

=C2=A0<notification>
= =C2=A0 =C2=A0 <hdr>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<subscrip= tion-id>1</subscription-id>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0<sequence-id>4242</sequence-id>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0// ... maybe more fields here=C2=A0
=C2=A0 =C2=A0</h= dr>
=C2=A0 =C2=A0<foo-event>
=C2=A0 =C2=A0 =C2= =A0 // normal notification contents
=C2=A0 =C2=A0</foo-event&g= t;
=C2=A0</notification>

or YANG 1= .1 nested:


=C2=A0<notification>
=C2=A0 =C2=A0 <hdr><= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<subscription-id>1</subscript= ion-id>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<sequence-id>4242= </sequence-id>
=C2=A0 =C2=A0 =C2=A0 =C2=A0// ... maybe more= fields here=C2=A0
=C2=A0 =C2=A0</hdr>
=C2=A0 =C2= =A0<interfaces>
=C2=A0 =C2=A0 =C2=A0 <interface>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth0</name>
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<foo-event>
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// normal notification contents
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</foo-event>
=C2= =A0 =C2=A0 =C2=A0 </interface>
=C2=A0 =C2=A0 </interface= s>
=C2=A0</notification>

=
If we want to do this protocol-agnostic, we should define XML and JSON
encoding of notifications in one document; the general concepts of
streams and filters etc in one docuement; protocol-specific mechanisms
to retrieve data from streams in another (unfortunately, we can't
define protocol-agnostic rpc operations for this, since these
operations only work for session-based protocols)


It would be better if the <notifica= tion> element could be modeled in YANG
so it can be augmented = and also it would be encoding-independent.
(e.g. YANG to CBOR cou= ld be used)
=C2=A0


/martin




Andy

=C2=A0

> or the subscription-id is removed from the design.=C2=A0 There is no w= ay this
> field can be defined
> as part of the event payload.=C2=A0 Every notification has to define a= field
> name 'subscription-id'?
> The identifier 'subscription-id' becomes reserved so it cannot= be used
> anywhere
>
>=C2=A0 =C2=A0list foo {
>=C2=A0 =C2=A0 =C2=A0 key subscription-id;
>=C2=A0 =C2=A0 =C2=A0 leaf subscription-id { type string; }
>=C2=A0 =C2=A0 =C2=A0 notification bar;
>=C2=A0 =C2=A0}
>
> How would a YANG 1.1 nested notification be supported?
> How would any existing notification-stmt that does not define this lea= f be
> supported?
> How will multiple subscriptions be sent over the same connection?
>
> If 5277 support is so important then make it work by eliminating every= thing
> related to subscription IDs from the solution.=C2=A0 IMO it would be b= etter to
> design a new solution that is properly layered.
>
>
> Andy
>
>
>
>
> On Tue, Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:
>
> > > From: Martin Bjorklund December 6, 2016 5:23 AM
> > >
> > > Andy Bierman <andy@= yumaworks.com> wrote:
> > > > Perhaps the WG needs to agree on the 5277 reuse require= ments before
> > > > diving working on solution details.
> > >
> > > +1
> >
> > Yes.=C2=A0 =C2=A0We have been assuming reuse until now.=C2=A0 Thi= s is what is in the WG
> > charter.=C2=A0 And this is what we have been building to in the c= urrent draft
> > set.
> >
> > There are no plans to change this direction unless the WG selects=
> > 'obsolete' over 'enhance'.=C2=A0 =C2=A0There are = benefits to each.=C2=A0 Below is my
> > summary for benefits of each path.=C2=A0 Please add any that I mi= ght have
> > missed...
> >
> >
> > Benefits of 'enhance'
> > ----------------------------
> > - Backwards compatibility through single integrated spec
> > - Single codebase handles all subscription requests if legacy and= new will
> > be running concurrently
> >
> > Benefits of 'obsolete'
> > ----------------------------
> > - Simpler, smaller specification
> > - Backwards compatibility through parallel implementation and cap= abilities
> > exchange
> > - Subscriptions decoupled from NETCONF namespace
> > - Fewer error conditions (e.g., what if you get two <create-su= bscription>
> > from what you thought was a legacy client.)
> >
> > Worthy of discussion
> > ----------------------------
> > - Interplay of streams and filters.=C2=A0 Will/must obsolete vs e= nhance impact
> > this decision?
> > - How many RPCs, and how complex should they be?=C2=A0 What are t= he impacts of
> > overloading.
> >
> >
> > Eric
> >
> >
> > >
> > > /martin
> >

--001a1147ec808042780543018ff4-- From alex@clemm.org Tue Dec 6 10:56:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660C9129A81 for ; Tue, 6 Dec 2016 10:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahvE99VUUcPV for ; Tue, 6 Dec 2016 10:56:08 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF683129575 for ; Tue, 6 Dec 2016 10:56:04 -0800 (PST) Received: from LAPTOPR7T053C2 ([47.143.86.36]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0M5fUk-1cckVR00zI-00xcGo; Tue, 06 Dec 2016 19:55:57 +0100 From: To: "'Eric Voit \(evoit\)'" , "'Andy Bierman'" , "'Alberto Gonzalez Prieto \(albertgo\)'" References: <20161205.223443.1094826795624770286.mbj@tail-f.com> <20161206.112309.670345130123099005.mbj@tail-f.com> In-Reply-To: Date: Tue, 6 Dec 2016 10:55:53 -0800 Message-ID: <04ab01d24ff2$6001b410$20051c30$@clemm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04AC_01D24FAF.51E048D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGGOTP5zykRz5/iPb3bS94wbTZ0SAJ3vK5JAhQ5tH4A3WEtDwKevHyXAgS9hLMB4YHcFKEz/A5Q Content-Language: en-us X-Provags-ID: V03:K0:rrqMp6gD7sZUM4nY6w0ANt2WaJ5TZw0blR0/fKTd//kPgafKafI ykqGl5CuB29oD/MFpSl6leqIbFW2QdxEzePRG4X4eQ6vyb62f2x4rKq+JJHh4NBJcVgF/Gc x/lV05//RDTr1ueRjy2MRWgV/YYzyP9k4t0YW+GDHpxDhcaEUyWhnENGd8R+7pIP32aVbnl /pWsyllpQIrJlJjdLQ07A== X-UI-Out-Filterresults: notjunk:1;V01:K0:2xvBHOBDCA0=:79QHxx63iDobdoVdRzKnQj stwAPnWMSqNWZuodRFluEyZgOksKSZurPJUO6v9OMIZ39ypj/OYuP58gRW10Q9k6KMEqujoGf /ZnUt86G9JZrvBOojAVmZZl1EnY6FESC7z+0K9uyX2+WGMLUNE00PfwJQB+VUp0JT8KwgUXYh izkmp+UNcMmy0neJ2taWVBUCbVDQcKSVphnajjS57Euy0HY2v+rlNxXBuNPVgItvAOSfFYgRY +7XJzV0f/5ndj8oOmcs93/ArXmQNooPnetuf3jeaD7HXHAb0LzMrKKIE3jCCRlhLBU/PWsV9U jvDUuALbWEGE8uarfNP022E7nOOmvOWJfhfYkxyShGti3zBQfTZhlU6vEp9Lkow50r6J5RyBQ ZC2BjacnY0uhN2UefMwydacrSm4Z4jg/cBrULdlSGzsRZ76Qva7WdhzbCIs43M+murjNIKAXz 7wey/7z37uBohJkR7GOukAZr6fcC/1RGjJN6f1uX+DcXRePUfp6URKNxrh2YExDa9pMQkyAm7 QYng+evrtZ5PPfJtL6g5K/4/vlUs0sDwvhmJzcCvXPX2rg4TQUaojqpkh2zMWrV8h6s9O0oEX USnvWtQdNlfY04ioAHnN7c5lwBsyaoJsF+VZfk3g0undw8bGptb2M3U5zsu62C1dxKDC4cjrE p1Ln3n5X8twSADmyGvpXrGUdn9HWPM43Wef4yTtoplooU0CjKA7T6fghaDdH7uIU5V2oF3AnT bldzlNbgfYnYHUWN Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 19:04:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04AC_01D24FAF.51E048D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, =20 There is no subscription ID in the notification element. I = don=E2=80=99t think this is a bug. It is by design choice, but of = course we can question if this is the right choice and if it should be = changed. =20 =20 In the current design, the subscription ID is used to refer to a = subscription, but it does not need to be included with every = notification. In other words, when you subscribe to messages, and = receive messages, it is transparent which specific subscription the = message is related to. That is, unless we choose to =E2=80=93 like we = did in YANG-Push. =20 =20 It is possible to devise a transport mapping in which subscription IDs = are added to individual messages. However, then there are more corner = cases =E2=80=93 such as what to do when there are multiple subscriptions = with separate filters, and one message is covered by both. In that = case, would the same message be transmitted redundantly? Would it be = transmitted once, but with multiple subscription IDs in the message? = Would it be a single subscription ID of the subscription with highest = priority =E2=80=93 which is applied first =E2=80=9Cas a filter=E2=80=9D? = None of these sound appealing to me, but if we want to include = subscription IDs with every message, then we have to get a solution for = this. =20 =20 This is one of the areas where I think we need to have a discussion on = requirements before we finalize on a solution. =20 --- Alex =20 From: Eric Voit (evoit) [mailto:evoit@cisco.com]=20 Sent: Tuesday, December 6, 2016 7:30 AM To: Andy Bierman ; alex@clemm.org; Alberto Gonzalez = Prieto (albertgo) Cc: Martin Bjorklund ; netconf@ietf.org Subject: RE: [Netconf] review of "event-notification" documents =20 Hi Andy, =20 The way we were approaching it was to have the 5277 notification element = be used when RPC started the subscription, and a = notification element which includes =E2=80=9Csubscription-id=E2=80=9D be = used with the RPC. We never expected the two = mixed on the same transport. This second way is what was used in the = implementations with OpenDaylight.=20 =20 Having two different notification type result from the same = RPC is something we should try to avoid. It is = what I was trying to capture below with the bullets =E2=80=98fewer error = conditions=E2=80=99 and RPC overloading. =20 The current 5277bis Section 6 examples do not currently show the = subscription-id breakdown for notifications. This was an oversight of = we authors. I only recognized this a few weeks ago (see agenda for last = WebEx). I agree the ultimate solution must properly parse out = subscription-id. =20 Also on your notes below I would love to better understand the nested = notification item, because that is something I haven=E2=80=99t thought = about. =20 Ultimately, I believe these notification complexities provide another = example why =E2=80=98obsolete=E2=80=99 is simpler than = =E2=80=98enhance=E2=80=99.=20 =20 Eric=20 =20 From: Andy Bierman, December 6, 2016 9:32 AM Hi, =20 The new solution design is completely broken unless a new notification = wrapper is used or the subscription-id is removed from the design. There is no way this = field can be defined as part of the event payload. Every notification has to define a field = name 'subscription-id'? The identifier 'subscription-id' becomes reserved so it cannot be used = anywhere =20 list foo { key subscription-id; leaf subscription-id { type string; } notification bar; } =20 How would a YANG 1.1 nested notification be supported? How would any existing notification-stmt that does not define this leaf = be supported? How will multiple subscriptions be sent over the same connection? =20 If 5277 support is so important then make it work by eliminating = everything related to subscription IDs from the solution. IMO it would be better = to design a new solution that is properly layered. =20 =20 Andy =20 =20 =20 =20 On Tue, Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) > wrote: > From: Martin Bjorklund December 6, 2016 5:23 AM > > Andy Bierman > wrote: > > Perhaps the WG needs to agree on the 5277 reuse requirements before > > diving working on solution details. > > +1 Yes. We have been assuming reuse until now. This is what is in the WG = charter. And this is what we have been building to in the current draft = set. There are no plans to change this direction unless the WG selects = 'obsolete' over 'enhance'. There are benefits to each. Below is my = summary for benefits of each path. Please add any that I might have = missed... Benefits of 'enhance' ---------------------------- - Backwards compatibility through single integrated spec - Single codebase handles all subscription requests if legacy and new = will be running concurrently Benefits of 'obsolete' ---------------------------- - Simpler, smaller specification - Backwards compatibility through parallel implementation and = capabilities exchange - Subscriptions decoupled from NETCONF namespace - Fewer error conditions (e.g., what if you get two = from what you thought was a legacy client.) Worthy of discussion ---------------------------- - Interplay of streams and filters. Will/must obsolete vs enhance = impact this decision? - How many RPCs, and how complex should they be? What are the impacts = of overloading. Eric > > /martin =20 ------=_NextPart_000_04AC_01D24FAF.51E048D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = all,

 

There is no = subscription ID in the notification element.=C2=A0 I don=E2=80=99t think = this is a bug.=C2=A0 It is by design choice, but of course we can = question if this is the right choice and if it should be changed.=C2=A0 =

 

In the = current design, the subscription ID is used to refer to a subscription, = but it does not need to be included with every notification. =C2=A0In = other words, when you subscribe to messages, and receive messages, it is = transparent which specific subscription the message is related to.=C2=A0 = That=C2=A0 is, unless we choose to =E2=80=93 like we did in = YANG-Push.=C2=A0

 

It is = possible to devise a transport mapping in which subscription IDs are = added to individual messages.=C2=A0 However, then there are more corner = cases =E2=80=93 such as what to do when there are multiple subscriptions = with separate filters, and one message is covered by both.=C2=A0 In that = case, would the same message be transmitted redundantly?=C2=A0 Would it = be transmitted once, but with multiple subscription IDs in the message? = =C2=A0=C2=A0Would it be a single subscription ID of the subscription = with highest priority =E2=80=93 which is applied first =E2=80=9Cas a = filter=E2=80=9D?=C2=A0 None of these sound appealing to me, but if we = want to include subscription IDs with every message, then we have to get = a solution for this.=C2=A0

 

This is one = of the areas where I think we need to have a discussion on requirements = before we finalize on a solution. =C2=A0

--- = Alex

 

From:<= /b> = Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Tuesday, = December 6, 2016 7:30 AM
To: Andy Bierman = <andy@yumaworks.com>; alex@clemm.org; Alberto Gonzalez Prieto = (albertgo) <albertgo@cisco.com>
Cc: Martin Bjorklund = <mbj@tail-f.com>; netconf@ietf.org
Subject: RE: = [Netconf] review of "event-notification" = documents

 

Hi Andy,

 

The way we were approaching it was to have the 5277 notification = element be used when <create-subscription> RPC started the = subscription, and a notification element which includes = =E2=80=9Csubscription-id=E2=80=9D be used with the = <establish-subscription> RPC.  We never expected the two = mixed on the same transport.   This second way is what was = used in the implementations with OpenDaylight.

 

Having two different notification type result from the same = <create-subscription> RPC is something we should try to = avoid.  It is what I was trying to capture below with the bullets = =E2=80=98fewer error conditions=E2=80=99 and RPC = overloading.

 

The current 5277bis Section 6 examples do not currently show the = subscription-id breakdown for notifications.  This was an oversight = of we authors.  I only recognized this a few weeks ago (see agenda = for last WebEx).  I agree the ultimate solution must properly parse = out subscription-id.

 

Also on your notes below I would love to better understand the nested = notification item, because that is something I haven=E2=80=99t thought = about.

 

Ultimately, I believe these notification complexities provide another = example why =E2=80=98obsolete=E2=80=99 is simpler than = =E2=80=98enhance=E2=80=99.

 

Eric

 

From:<= /b> = Andy Bierman, December 6, 2016 9:32 = AM

Hi,

 

The new solution design is completely broken unless a = new notification wrapper is used

or the subscription-id is removed from the = design.  There is no way this field can be = defined

as part of the = event payload.  Every notification has to define a field name = 'subscription-id'?

The = identifier 'subscription-id' becomes reserved so it cannot be used = anywhere

 

  list foo {

     key = subscription-id;

  =    leaf subscription-id { type string; = }

    =  notification bar;

  }

 

How would a YANG 1.1 nested notification be = supported?

How would any = existing notification-stmt that does not define this leaf be = supported?

How will = multiple subscriptions be sent over the same = connection?

 

If 5277 support is so important then make it work by = eliminating everything

related to subscription IDs from the solution.  = IMO it would be better to

design a new solution that is properly = layered.

 

 

Andy

 

 

 

 

On Tue, = Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

> From: Martin Bjorklund December 6, 2016 = 5:23 AM
>
> Andy Bierman <andy@yumaworks.com> = wrote:
> > Perhaps the WG needs to agree on the 5277 reuse = requirements before
> > diving working on solution = details.
>
> +1

Yes.   We have been = assuming reuse until now.  This is what is in the WG charter.  = And this is what we have been building to in the current draft = set.

There are no plans to change this direction unless the WG = selects 'obsolete' over 'enhance'.   There are benefits to = each.  Below is my summary for benefits of each path.  Please = add any that I might have missed...


Benefits of = 'enhance'
----------------------------
- Backwards compatibility = through single integrated spec
- Single codebase handles all = subscription requests if legacy and new will be running = concurrently

Benefits of = 'obsolete'
----------------------------
- Simpler, smaller = specification
- Backwards compatibility through parallel = implementation and capabilities exchange
- Subscriptions decoupled = from NETCONF namespace
- Fewer error conditions (e.g., what if you = get two <create-subscription> from what you thought was a legacy = client.)

Worthy of = discussion
----------------------------
- Interplay of streams and = filters.  Will/must obsolete vs enhance impact this decision?
- = How many RPCs, and how complex should they be?  What are the = impacts of overloading.


Eric


>
> = /martin

 

------=_NextPart_000_04AC_01D24FAF.51E048D0-- From nobody Tue Dec 6 11:11:43 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4A9129AA0 for ; Tue, 6 Dec 2016 11:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y5YobflX9LH for ; Tue, 6 Dec 2016 11:11:39 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 2320C129B27 for ; Tue, 6 Dec 2016 11:10:40 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id n21so390270878qka.3 for ; Tue, 06 Dec 2016 11:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eIs8pQMs9s4DqFpBx09drJoLuborYEXZlqUPoU9Z1j8=; b=0abwPFtgtxghUQ1FoZ/kmkpOMXhgp6tYj0tlJv2MDY6aEH082El/RACIEKLhwtk5I2 SvROwtzcCwuoOQoGBsLfQ3bhfHU6j25oC/sCHXoTlMIk6Cda5pRtROicvhsCwsvJURay T80ZVOgnuQvSThXOACRyFHYK86sup/AHuea1h7WuPjj2KQeAZDzj5NkDi4W6pk1aIrgf wr+7puBvOdZ+TfteVkqFZsdmve5qe/9pc6ye4RE6iH6VIJvJiiCjdJPf7pby6+fdgn49 iMpOEPogOajUzDHFALdxgiVG30dga0namSwd0bknEf8n/f84avcRzMaXjzXTFpD5pxTd RHaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eIs8pQMs9s4DqFpBx09drJoLuborYEXZlqUPoU9Z1j8=; b=g53VkE3vlUQ8sh/RTX511fBiZKFT2bUvPn0CxLDPWCV6JUgdRIvgP3BpvcU2hXJp08 9E83YFfFeHBKVuLDcm0RWmpsi/Eg+6AlBmxsDK3PqOMQZicsIw0zmCHP2maCD5PxP3KF Rr2nCjXnv2+Fa8Ei40f7cOOtA8YK3oVaCBOa7NndoYOW8McRJ5CGalILgfoL5exf0zY/ Ree647FBxb66hyx0Yt4dSE/TzRYtC4aOnYSMZqgi8xyrObJbfrw2gA7xkTPw+5qXZ+Pr rXK2EOsE/du5+G2wlQdBca0CuubHFQEIIQkGr4MEiVjsrivlQCz52Zw/2SR9/k/13Myp sQfQ== X-Gm-Message-State: AKaTC03lHDqJUY3flVe8R0OGeCen6mUPqC8pc66zNDAMkCb5Entj9FMaWMM+QFZmdrFss255mhHJe+AUKoNzKQ== X-Received: by 10.55.107.71 with SMTP id g68mr53316934qkc.259.1481051439260; Tue, 06 Dec 2016 11:10:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Tue, 6 Dec 2016 11:10:38 -0800 (PST) In-Reply-To: <04ab01d24ff2$6001b410$20051c30$@clemm.org> References: <20161205.223443.1094826795624770286.mbj@tail-f.com> <20161206.112309.670345130123099005.mbj@tail-f.com> <04ab01d24ff2$6001b410$20051c30$@clemm.org> From: Andy Bierman Date: Tue, 6 Dec 2016 11:10:38 -0800 Message-ID: To: Alexander Clemm Content-Type: multipart/alternative; boundary=001a114ff8e8ee87f205430228bc Archived-At: Cc: Netconf Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 19:11:41 -0000 --001a114ff8e8ee87f205430228bc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 6, 2016 at 10:55 AM, wrote: > Hi all, > > > > There is no subscription ID in the notification element. I don=E2=80=99t= think > this is a bug. It is by design choice, but of course we can question if > this is the right choice and if it should be changed. > > > I think ity is a bug that there are subscription-id leafs in the application notifications, such as YANG Push. Only properties of the event should be modeled in the notification-stmt. The properties of the notification delivery system should not be modeled in events. The current 5277 solution is simple -- 1 subscription per session so no need for subscription-id. The server will send the same notification to every client using 5277. This is not a problem. I am not sure if multiple subscriptions per session and multiple receivers per subscription are really important or not. They add lots of complex new problems to solve= . Andy In the current design, the subscription ID is used to refer to a > subscription, but it does not need to be included with every notification= . > In other words, when you subscribe to messages, and receive messages, it = is > transparent which specific subscription the message is related to. That > is, unless we choose to =E2=80=93 like we did in YANG-Push. > > > > It is possible to devise a transport mapping in which subscription IDs ar= e > added to individual messages. However, then there are more corner cases = =E2=80=93 > such as what to do when there are multiple subscriptions with separate > filters, and one message is covered by both. In that case, would the sam= e > message be transmitted redundantly? Would it be transmitted once, but wi= th > multiple subscription IDs in the message? Would it be a single > subscription ID of the subscription with highest priority =E2=80=93 which= is > applied first =E2=80=9Cas a filter=E2=80=9D? None of these sound appeali= ng to me, but if > we want to include subscription IDs with every message, then we have to g= et > a solution for this. > > > > This is one of the areas where I think we need to have a discussion on > requirements before we finalize on a solution. > > --- Alex > > > > *From:* Eric Voit (evoit) [mailto:evoit@cisco.com] > *Sent:* Tuesday, December 6, 2016 7:30 AM > *To:* Andy Bierman ; alex@clemm.org; Alberto Gonzalez > Prieto (albertgo) > *Cc:* Martin Bjorklund ; netconf@ietf.org > *Subject:* RE: [Netconf] review of "event-notification" documents > > > > Hi Andy, > > > > The way we were approaching it was to have the 5277 notification element > be used when RPC started the subscription, and a > notification element which includes =E2=80=9Csubscription-id=E2=80=9D be = used with the > RPC. We never expected the two mixed on the sam= e > transport. This second way is what was used in the implementations with > OpenDaylight. > > > > Having two different notification type result from the same > RPC is something we should try to avoid. It is wha= t > I was trying to capture below with the bullets =E2=80=98fewer error condi= tions=E2=80=99 and > RPC overloading. > > > > The current 5277bis Section 6 examples do not currently show the > subscription-id breakdown for notifications. This was an oversight of we > authors. I only recognized this a few weeks ago (see agenda for last > WebEx). I agree the ultimate solution must properly parse out > subscription-id. > > > > Also on your notes below I would love to better understand the nested > notification item, because that is something I haven=E2=80=99t thought ab= out. > > > > Ultimately, I believe these notification complexities provide another > example why =E2=80=98obsolete=E2=80=99 is simpler than =E2=80=98enhance= =E2=80=99. > > > > Eric > > > > *From:* Andy Bierman, December 6, 2016 9:32 AM > > Hi, > > > > The new solution design is completely broken unless a new notification > wrapper is used > > or the subscription-id is removed from the design. There is no way this > field can be defined > > as part of the event payload. Every notification has to define a field > name 'subscription-id'? > > The identifier 'subscription-id' becomes reserved so it cannot be used > anywhere > > > > list foo { > > key subscription-id; > > leaf subscription-id { type string; } > > notification bar; > > } > > > > How would a YANG 1.1 nested notification be supported? > > How would any existing notification-stmt that does not define this leaf b= e > supported? > > How will multiple subscriptions be sent over the same connection? > > > > If 5277 support is so important then make it work by eliminating everythi= ng > > related to subscription IDs from the solution. IMO it would be better to > > design a new solution that is properly layered. > > > > > > Andy > > > > > > > > > > On Tue, Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) wrote= : > > > From: Martin Bjorklund December 6, 2016 5:23 AM > > > > Andy Bierman wrote: > > > Perhaps the WG needs to agree on the 5277 reuse requirements before > > > diving working on solution details. > > > > +1 > > Yes. We have been assuming reuse until now. This is what is in the WG > charter. And this is what we have been building to in the current draft > set. > > There are no plans to change this direction unless the WG selects > 'obsolete' over 'enhance'. There are benefits to each. Below is my > summary for benefits of each path. Please add any that I might have > missed... > > > Benefits of 'enhance' > ---------------------------- > - Backwards compatibility through single integrated spec > - Single codebase handles all subscription requests if legacy and new wil= l > be running concurrently > > Benefits of 'obsolete' > ---------------------------- > - Simpler, smaller specification > - Backwards compatibility through parallel implementation and capabilitie= s > exchange > - Subscriptions decoupled from NETCONF namespace > - Fewer error conditions (e.g., what if you get two > from what you thought was a legacy client.) > > Worthy of discussion > ---------------------------- > - Interplay of streams and filters. Will/must obsolete vs enhance impact > this decision? > - How many RPCs, and how complex should they be? What are the impacts of > overloading. > > > Eric > > > > > > /martin > > > --001a114ff8e8ee87f205430228bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 6, 2016 at 10:55 AM, <alex@clemm.org> wrote:

Hi all,

=C2= =A0

There is no subscription ID in= the notification element.=C2=A0 I don=E2=80=99t think this is a bug.=C2=A0= It is by design choice, but of course we can question if this is the right= choice and if it should be changed.=C2=A0

=C2=A0


=
I think ity is a bug that there are subscription-id leafs in the= application notifications,
such as YANG Push.

Only properties of the event should be modeled in the notification-s= tmt.
The properties of the notification delivery system should no= t be modeled in events.

The current 5277 solution = is simple -- 1 subscription per session so no need for subscription-id.
The server will send the same notification to every client using 527= 7.=C2=A0 This is not a problem.

I am not sure if m= ultiple subscriptions per session and multiple receivers per subscription
are really important or not. They add lots of complex new problems= to solve.


Andy




In the current design, the subscription ID is used to re= fer to a subscription, but it does not need to be included with every notif= ication.=C2=A0 In other words, when you subscribe to messages, and receive = messages, it is transparent which specific subscription the message is rela= ted to.=C2=A0 That=C2=A0 is, unless we choose to =E2=80=93 like we did in Y= ANG-Push.=C2=A0

=C2= =A0

It is possible to devise a tra= nsport mapping in which subscription IDs are added to individual messages.= =C2=A0 However, then there are more corner cases =E2=80=93 such as what to = do when there are multiple subscriptions with separate filters, and one mes= sage is covered by both.=C2=A0 In that case, would the same message be tran= smitted redundantly?=C2=A0 Would it be transmitted once, but with multiple = subscription IDs in the message? =C2=A0=C2=A0Would it be a single subscript= ion ID of the subscription with highest priority =E2=80=93 which is applied= first =E2=80=9Cas a filter=E2=80=9D?=C2=A0 None of these sound appealing t= o me, but if we want to include subscription IDs with every message, then w= e have to get a solution for this.=C2=A0

=C2=A0

This= is one of the areas where I think we need to have a discussion on requirem= ents before we finalize on a solution. =C2=A0

--- Alex

= =C2=A0

Fr= om: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Tuesday, December= 6, 2016 7:30 AM
To: Andy Bierman <andy@yumaworks.com>; alex@clemm.org; Alberto Gonzalez Prie= to (albertgo) <a= lbertgo@cisco.com>
Cc: Martin Bjorklund <mbj@tail-f.com>; netconf@ietf.org
Subject= : RE: [Netconf] review of "event-notification" documents

=C2=A0=

Hi Andy,

=

=C2=A0

The way we were approaching it was to have = the 5277 notification element be used when <create-subscription> RPC = started the subscription, and a notification element which includes =E2=80= =9Csubscription-id=E2=80=9D be used with the <establish-subscription>= RPC.=C2=A0 We never expected the two mixed on the same transport.=C2=A0 = =C2=A0This second way is what was used in the implementations with OpenDayl= ight.

=C2=A0

Having two d= ifferent notification type result from the same <create-subscription>= RPC is something we should try to avoid.=C2=A0 It is what I was trying to = capture below with the bullets =E2=80=98fewer error conditions=E2=80=99 and= RPC overloading.

=C2=A0

T= he current 5277bis Section 6 examples do not currently show the subscriptio= n-id breakdown for notifications.=C2=A0 This was an oversight of we authors= .=C2=A0 I only recognized this a few weeks ago (see agenda for last WebEx).= =C2=A0 I agree the ultimate solution must properly parse out subscription-i= d.

=C2= =A0

Also on your not= es below I would love to better understand the nested notification item, be= cause that is something I haven=E2=80=99t thought about.

=C2=A0

=

Ultimately, I believe these notificat= ion complexities provide another example why =E2=80=98obsolete=E2=80=99 is = simpler than =E2=80=98enhance=E2=80=99.

=C2=A0

Eric

=C2=A0

From: Andy = Bierman, December 6, 2016 9:32 AM

=

Hi,

= =C2=A0

The new solution des= ign is completely broken unless a new notification wrapper is used

or the subscription-id is remove= d from the design.=C2=A0 There is no way this field can be defined

as part of the event payload.=C2= =A0 Every notification has to define a field name 'subscription-id'= ?

The identifier 'su= bscription-id' becomes reserved so it cannot be used anywhere=

=C2=A0

=C2=A0 list foo {

=C2=A0 =C2=A0 =C2=A0key subscription-id;

=C2=A0 =C2=A0 =C2=A0leaf subscription-i= d { type string; }

=C2= =A0 =C2=A0 =C2=A0notification bar;

=C2=A0 }

<= /u>=C2=A0

How would a YANG 1.1 = nested notification be supported?

How would any existing notification-stmt that does not define thi= s leaf be supported?

How= will multiple subscriptions be sent over the same connection?

=C2=A0

<= p class=3D"MsoNormal">If 5277 support is so important then make it work by = eliminating everything

r= elated to subscription IDs from the solution.=C2=A0 IMO it would be better = to

design a new solution= that is properly layered.

=C2=A0

=C2=A0<= u>

Andy

=C2=A0

=C2=A0

= =C2=A0

=C2=A0

On Tue, Dec 6, 2016 at 6:11 AM, Eric Voit= (evoit) <evoit@cis= co.com> wrote:

> From: Martin Bjorklund December 6, 2016 5:23 AM
>
> Andy = Bierman <andy@yu= maworks.com> wrote:
> > Perhaps the WG needs to agree on th= e 5277 reuse requirements before
> > diving working on solution de= tails.
>
> +1

Yes.=C2=A0 =C2=A0We have been assuming reu= se until now.=C2=A0 This is what is in the WG charter.=C2=A0 And this is wh= at we have been building to in the current draft set.

There are no p= lans to change this direction unless the WG selects 'obsolete' over= 'enhance'.=C2=A0 =C2=A0There are benefits to each.=C2=A0 Below is = my summary for benefits of each path.=C2=A0 Please add any that I might hav= e missed...


Benefits of 'enhance'
-------------------= ---------
- Backwards compatibility through single integrated spec
- = Single codebase handles all subscription requests if legacy and new will be= running concurrently

Benefits of 'obsolete'
------------= ----------------
- Simpler, smaller specification
- Backwards compati= bility through parallel implementation and capabilities exchange
- Subsc= riptions decoupled from NETCONF namespace
- Fewer error conditions (e.g.= , what if you get two <create-subscription> from what you thought was= a legacy client.)

Worthy of discussion
-------------------------= ---
- Interplay of streams and filters.=C2=A0 Will/must obsolete vs enha= nce impact this decision?
- How many RPCs, and how complex should they b= e?=C2=A0 What are the impacts of overloading.


Eric


&g= t;
> /martin

=C2=A0


<= /div>
--001a114ff8e8ee87f205430228bc-- From nobody Tue Dec 6 11:26:38 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB20C129ABE for ; Tue, 6 Dec 2016 11:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmZj8ijdkndh for ; Tue, 6 Dec 2016 11:26:34 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC56129B1F for ; Tue, 6 Dec 2016 11:22:44 -0800 (PST) Received: from LAPTOPR7T053C2 ([47.143.86.36]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MJlT8-1cDFOZ06rM-0017Ts; Tue, 06 Dec 2016 20:22:43 +0100 From: To: "'Andy Bierman'" References: <20161205.223443.1094826795624770286.mbj@tail-f.com> <20161206.112309.670345130123099005.mbj@tail-f.com> <04ab01d24ff2$6001b410$20051c30$@clemm.org> In-Reply-To: Date: Tue, 6 Dec 2016 11:22:40 -0800 Message-ID: <04ca01d24ff6$1d450f60$57cf2e20$@clemm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04CB_01D24FB3.0F23F240" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGGOTP5zykRz5/iPb3bS94wbTZ0SAJ3vK5JAhQ5tH4A3WEtDwKevHyXAgS9hLMB4YHcFAKd5aTGAq4HLRyhCaTiQA== Content-Language: en-us X-Provags-ID: V03:K0:oJPnEgVJMvXEnUdNnGxksmuigRVZI2JVJHoXAOTVfZ3GWfiHRtR YPxVx/7+Ct0az+Cza1rrP6423NbGWwNQuR4BudhxbDDsnOmn9iuiH5yFkXJ4T+n5B1+vaeP dminWSNnnEdj7h1MpniYJUyDwtDnhQunt17gfycEg6Mv6hlX+NvhnxIOcaIH+guXjNUBd4S ygKVkS1FDkdPOkIUdNB2w== X-UI-Out-Filterresults: notjunk:1;V01:K0:eBo9eW1flzQ=:5faKyFpVH2rcPowVHmKTE5 4d0DMJAn5Ur0nTCwIQwjpBP64ZWP3x75geVOmAwdk+XVWZguBOSQnCrSZZaDkMnXSwi7usNOk 3OlQ2cG6Hw0GkzEUhUs6jZqNRzkMNrw0rQSvM/ey5CAhvtAAmJ0oldRwOD8I+rRj559dsAM/j g3pA6NeQMHNtXEhrA4KTqa2PgU3c/ybFxfsTKz0IXPmfTpwGgN2dEhlpYJmooAstycG6PC3tl BPq2jyhwU4rF5tHzc2GttdHfU4iYAmwffTryWJxOXTwT7VejfxT3+EnUYe4jcZDoxf+Eyn1HU dVVuOq+VbJ+OUJMF0IssxeJ25fmq5+2CCHX5+bqG5lK93WXVBUtjgB0gWLCWq9ICXpr0yG6hK BWzwstsNTCUUmr2ixd+mbWDDJV+M1aJ/T06VXQW9vV+kqhM6BW/LPF0qoOHVbLnUhQzcaQvUu q38fzZUVZtkD6FjpbwcNCYriudysUBZuSoGREQ+2GbIas4AxzbAMAR2fdXWoL/65syJZwaBAJ /1m2ec7Hz53b1O6PdhJoaAPz96vzGPDlnnDBd5MsRCELI1PGRWkXkLXvA9di7LslYBsQd3kXB nAFUl3pre+LExYRJwfyHnNWyBiGCmGiD0vdIJBVRgnTjJ4XmOPc4wJKS7ewHk5FP/UnnogOk2 SQ6QL3ft3lw50zh28OJOQv3STjmLoQXyeJL7ygLna454X/BXAO69h5Hh2u8B97eoXkWlKnI0+ 83cVyTudU94JYz+R Archived-At: Cc: 'Netconf' Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 19:26:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04CB_01D24FB3.0F23F240 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, having a subscription ID in messages will facilitate handling of = different message streams, each tied to a specific subscription. I can = see how this would be useful, but it does mean a change of an underlying = assumption in our design. In that case, the subscription ID would = indeed need to be included in the way we map messages. I do think this = would also imply that if one client subscribes to the same notification = multiple times (respectively, a notification passes the filter criteria = of multiple subscriptions), the notification needs effectively to be = replicated across message streams. (A simple way to avoid that in an = implementation would be to limit a server to support only a single = subscription per receiver.)=20 =20 As mentioned earlier, another thing we need to fix is the stream = terminology. We need to have a different term for what it is that a = client subscribes to (to which it may apply filters, encoding choices, = etc) , and for what the server sends to the client as part of a = subscription. One is the =E2=80=9Csource=E2=80=9D (or = =E2=80=9Cwell=E2=80=9D?), the other the =E2=80=9Cstream=E2=80=9D. =20 =20 --- Alex =20 =20 From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman Sent: Tuesday, December 6, 2016 11:11 AM To: Alexander Clemm Cc: Netconf Subject: Re: [Netconf] review of "event-notification" documents =20 =20 =20 On Tue, Dec 6, 2016 at 10:55 AM, = > wrote: Hi all, =20 There is no subscription ID in the notification element. I = don=E2=80=99t think this is a bug. It is by design choice, but of = course we can question if this is the right choice and if it should be = changed. =20 =20 =20 I think ity is a bug that there are subscription-id leafs in the = application notifications, such as YANG Push. =20 Only properties of the event should be modeled in the notification-stmt. The properties of the notification delivery system should not be modeled = in events. =20 The current 5277 solution is simple -- 1 subscription per session so no = need for subscription-id. The server will send the same notification to every client using 5277. = This is not a problem. =20 I am not sure if multiple subscriptions per session and multiple = receivers per subscription are really important or not. They add lots of complex new problems to = solve. =20 =20 Andy =20 =20 =20 =20 In the current design, the subscription ID is used to refer to a = subscription, but it does not need to be included with every = notification. In other words, when you subscribe to messages, and = receive messages, it is transparent which specific subscription the = message is related to. That is, unless we choose to =E2=80=93 like we = did in YANG-Push. =20 =20 It is possible to devise a transport mapping in which subscription IDs = are added to individual messages. However, then there are more corner = cases =E2=80=93 such as what to do when there are multiple subscriptions = with separate filters, and one message is covered by both. In that = case, would the same message be transmitted redundantly? Would it be = transmitted once, but with multiple subscription IDs in the message? = Would it be a single subscription ID of the subscription with highest = priority =E2=80=93 which is applied first =E2=80=9Cas a filter=E2=80=9D? = None of these sound appealing to me, but if we want to include = subscription IDs with every message, then we have to get a solution for = this. =20 =20 This is one of the areas where I think we need to have a discussion on = requirements before we finalize on a solution. =20 --- Alex =20 From: Eric Voit (evoit) [mailto:evoit@cisco.com = ]=20 Sent: Tuesday, December 6, 2016 7:30 AM To: Andy Bierman >; = alex@clemm.org ; Alberto Gonzalez Prieto = (albertgo) > Cc: Martin Bjorklund >; = netconf@ietf.org =20 Subject: RE: [Netconf] review of "event-notification" documents =20 Hi Andy, =20 The way we were approaching it was to have the 5277 notification element = be used when RPC started the subscription, and a = notification element which includes =E2=80=9Csubscription-id=E2=80=9D be = used with the RPC. We never expected the two = mixed on the same transport. This second way is what was used in the = implementations with OpenDaylight.=20 =20 Having two different notification type result from the same = RPC is something we should try to avoid. It is = what I was trying to capture below with the bullets =E2=80=98fewer error = conditions=E2=80=99 and RPC overloading. =20 The current 5277bis Section 6 examples do not currently show the = subscription-id breakdown for notifications. This was an oversight of = we authors. I only recognized this a few weeks ago (see agenda for last = WebEx). I agree the ultimate solution must properly parse out = subscription-id. =20 Also on your notes below I would love to better understand the nested = notification item, because that is something I haven=E2=80=99t thought = about. =20 Ultimately, I believe these notification complexities provide another = example why =E2=80=98obsolete=E2=80=99 is simpler than = =E2=80=98enhance=E2=80=99.=20 =20 Eric=20 =20 From: Andy Bierman, December 6, 2016 9:32 AM Hi, =20 The new solution design is completely broken unless a new notification = wrapper is used or the subscription-id is removed from the design. There is no way this = field can be defined as part of the event payload. Every notification has to define a field = name 'subscription-id'? The identifier 'subscription-id' becomes reserved so it cannot be used = anywhere =20 list foo { key subscription-id; leaf subscription-id { type string; } notification bar; } =20 How would a YANG 1.1 nested notification be supported? How would any existing notification-stmt that does not define this leaf = be supported? How will multiple subscriptions be sent over the same connection? =20 If 5277 support is so important then make it work by eliminating = everything related to subscription IDs from the solution. IMO it would be better = to design a new solution that is properly layered. =20 =20 Andy =20 =20 =20 =20 On Tue, Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) > wrote: > From: Martin Bjorklund December 6, 2016 5:23 AM > > Andy Bierman > wrote: > > Perhaps the WG needs to agree on the 5277 reuse requirements before > > diving working on solution details. > > +1 Yes. We have been assuming reuse until now. This is what is in the WG = charter. And this is what we have been building to in the current draft = set. There are no plans to change this direction unless the WG selects = 'obsolete' over 'enhance'. There are benefits to each. Below is my = summary for benefits of each path. Please add any that I might have = missed... Benefits of 'enhance' ---------------------------- - Backwards compatibility through single integrated spec - Single codebase handles all subscription requests if legacy and new = will be running concurrently Benefits of 'obsolete' ---------------------------- - Simpler, smaller specification - Backwards compatibility through parallel implementation and = capabilities exchange - Subscriptions decoupled from NETCONF namespace - Fewer error conditions (e.g., what if you get two = from what you thought was a legacy client.) Worthy of discussion ---------------------------- - Interplay of streams and filters. Will/must obsolete vs enhance = impact this decision? - How many RPCs, and how complex should they be? What are the impacts = of overloading. Eric > > /martin =20 =20 ------=_NextPart_000_04CB_01D24FB3.0F23F240 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Well, having = a subscription ID in messages will facilitate handling of different = message streams, each tied to a specific subscription.=C2=A0 I can see = how this would be useful, but it does mean a change of an underlying = assumption in our design. =C2=A0In that case, the subscription ID would = indeed need to be included in the way we map messages.=C2=A0 I do think = this would also imply that if one client subscribes to the same = notification multiple times (respectively, a notification passes the = filter criteria of multiple subscriptions), the notification needs = effectively to be replicated across message streams.=C2=A0 (A simple way = to avoid that in an implementation would be to limit a server to support = only a single subscription per receiver.)

 

As mentioned = earlier, another thing we need to fix is the stream terminology.=C2=A0 = We need to have a different term for what it is that a client subscribes = to (to which it may apply filters, encoding choices, etc) , and for what = the server sends to the client as part of a subscription. =C2=A0One is = the =E2=80=9Csource=E2=80=9D (or =E2=80=9Cwell=E2=80=9D?), the other the = =E2=80=9Cstream=E2=80=9D.=C2=A0

 

--- = Alex

 

 

From:<= /b> = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Tuesday, December 6, 2016 11:11 AM
To: = Alexander Clemm <alex@clemm.org>
Cc: Netconf = <netconf@ietf.org>
Subject: Re: [Netconf] review of = "event-notification" documents

 

 

 

On Tue, = Dec 6, 2016 at 10:55 AM, <alex@clemm.org> = wrote:

Hi = all,

 =

There is no = subscription ID in the notification element.  I don=E2=80=99t think = this is a bug.  It is by design choice, but of course we can = question if this is the right choice and if it should be changed.  =

 =

 

I = think ity is a bug that there are subscription-id leafs in the = application notifications,

such as YANG Push.

 

Only properties of the event should be modeled in the = notification-stmt.

The = properties of the notification delivery system should not be modeled in = events.

 

The current 5277 solution is simple -- 1 subscription = per session so no need for subscription-id.

The server will send the same notification to every = client using 5277.  This is not a = problem.

 

I = am not sure if multiple subscriptions per session and multiple receivers = per subscription

are = really important or not. They add lots of complex new problems to = solve.

 

 

Andy

 

 

 

 

In the = current design, the subscription ID is used to refer to a subscription, = but it does not need to be included with every notification.  In = other words, when you subscribe to messages, and receive messages, it is = transparent which specific subscription the message is related to.  = That  is, unless we choose to =E2=80=93 like we did in = YANG-Push. 

 =

It is = possible to devise a transport mapping in which subscription IDs are = added to individual messages.  However, then there are more corner = cases =E2=80=93 such as what to do when there are multiple subscriptions = with separate filters, and one message is covered by both.  In that = case, would the same message be transmitted redundantly?  Would it = be transmitted once, but with multiple subscription IDs in the message? =   Would it be a single subscription ID of the subscription = with highest priority =E2=80=93 which is applied first =E2=80=9Cas a = filter=E2=80=9D?  None of these sound appealing to me, but if we = want to include subscription IDs with every message, then we have to get = a solution for this. 

 =

This is one = of the areas where I think we need to have a discussion on requirements = before we finalize on a solution.  

--- = Alex

 =

From:<= /b> = Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Tuesday, = December 6, 2016 7:30 AM
To: Andy Bierman <andy@yumaworks.com>; alex@clemm.org; = Alberto Gonzalez Prieto (albertgo) <albertgo@cisco.com>
Cc: Martin = Bjorklund <mbj@tail-f.com>; netconf@ietf.org
Subject: RE: [Netconf] = review of "event-notification" = documents

 <= /o:p>

Hi Andy,

 

The way we were approaching it was to have the 5277 notification = element be used when <create-subscription> RPC started the = subscription, and a notification element which includes = =E2=80=9Csubscription-id=E2=80=9D be used with the = <establish-subscription> RPC.  We never expected the two = mixed on the same transport.   This second way is what was = used in the implementations with OpenDaylight.

 

Having two different notification type result from the same = <create-subscription> RPC is something we should try to = avoid.  It is what I was trying to capture below with the bullets = =E2=80=98fewer error conditions=E2=80=99 and RPC = overloading.

 

The current 5277bis Section 6 examples do not currently show the = subscription-id breakdown for notifications.  This was an oversight = of we authors.  I only recognized this a few weeks ago (see agenda = for last WebEx).  I agree the ultimate solution must properly parse = out subscription-id.

 

Also on your notes below I would love to better understand the nested = notification item, because that is something I haven=E2=80=99t thought = about.

 

Ultimately, I believe these notification complexities provide another = example why =E2=80=98obsolete=E2=80=99 is simpler than = =E2=80=98enhance=E2=80=99.

 

Eric

 

From:<= /b> = Andy Bierman, December 6, 2016 9:32 = AM

Hi,

 <= /o:p>

The new = solution design is completely broken unless a new notification wrapper = is used

or the = subscription-id is removed from the design.  There is no way this = field can be defined

as part of = the event payload.  Every notification has to define a field name = 'subscription-id'?

The = identifier 'subscription-id' becomes reserved so it cannot be used = anywhere

 <= /o:p>

  list = foo {

  =    key subscription-id;

  =    leaf subscription-id { type string; = }

  =    notification bar;

  = }

 <= /o:p>

How would a = YANG 1.1 nested notification be supported?

How would = any existing notification-stmt that does not define this leaf be = supported?

How will = multiple subscriptions be sent over the same = connection?

 <= /o:p>

If 5277 = support is so important then make it work by eliminating = everything

related to = subscription IDs from the solution.  IMO it would be better = to

design a = new solution that is properly layered.

 <= /o:p>

 <= /o:p>

Andy

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Tue, Dec = 6, 2016 at 6:11 AM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

> From: = Martin Bjorklund December 6, 2016 5:23 AM
>
> Andy Bierman = <andy@yumaworks.com> wrote:
> > Perhaps = the WG needs to agree on the 5277 reuse requirements before
> > = diving working on solution details.
>
> +1

Yes.  =  We have been assuming reuse until now.  This is what is in = the WG charter.  And this is what we have been building to in the = current draft set.

There are no plans to change this direction = unless the WG selects 'obsolete' over 'enhance'.   There are = benefits to each.  Below is my summary for benefits of each = path.  Please add any that I might have = missed...


Benefits of = 'enhance'
----------------------------
- Backwards compatibility = through single integrated spec
- Single codebase handles all = subscription requests if legacy and new will be running = concurrently

Benefits of = 'obsolete'
----------------------------
- Simpler, smaller = specification
- Backwards compatibility through parallel = implementation and capabilities exchange
- Subscriptions decoupled = from NETCONF namespace
- Fewer error conditions (e.g., what if you = get two <create-subscription> from what you thought was a legacy = client.)

Worthy of = discussion
----------------------------
- Interplay of streams and = filters.  Will/must obsolete vs enhance impact this decision?
- = How many RPCs, and how complex should they be?  What are the = impacts of overloading.


Eric


>
> = /martin

 <= /o:p>

 

------=_NextPart_000_04CB_01D24FB3.0F23F240-- From nobody Tue Dec 6 11:42:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9992D129585 for ; Tue, 6 Dec 2016 11:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 DD5ZKG9ZkUNh for ; Tue, 6 Dec 2016 11:42:50 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 389A8129A57 for ; Tue, 6 Dec 2016 11:42:46 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 431471AE02BC; Tue, 6 Dec 2016 20:42:44 +0100 (CET) Date: Tue, 06 Dec 2016 20:42:44 +0100 (CET) Message-Id: <20161206.204244.778854096051701845.mbj@tail-f.com> To: ludwig@clemm.org From: Martin Bjorklund In-Reply-To: <04ca01d24ff6$1d450f60$57cf2e20$@clemm.org> References: <04ab01d24ff2$6001b410$20051c30$@clemm.org> <04ca01d24ff6$1d450f60$57cf2e20$@clemm.org> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 19:42:51 -0000 PGx1ZHdpZ0BjbGVtbS5vcmc+IHdyb3RlOg0KPiBXZWxsLCBoYXZpbmcgYSBzdWJzY3JpcHRpb24g SUQgaW4gbWVzc2FnZXMgd2lsbCBmYWNpbGl0YXRlIGhhbmRsaW5nIG9mDQo+IGRpZmZlcmVudCBt ZXNzYWdlIHN0cmVhbXMsIGVhY2ggdGllZCB0byBhIHNwZWNpZmljIHN1YnNjcmlwdGlvbi4gIEkN Cj4gY2FuIHNlZSBob3cgdGhpcyB3b3VsZCBiZSB1c2VmdWwsIGJ1dCBpdCBkb2VzIG1lYW4gYSBj aGFuZ2Ugb2YgYW4NCj4gdW5kZXJseWluZyBhc3N1bXB0aW9uIGluIG91ciBkZXNpZ24uICBJbiB0 aGF0IGNhc2UsIHRoZSBzdWJzY3JpcHRpb24NCj4gSUQgd291bGQgaW5kZWVkIG5lZWQgdG8gYmUg aW5jbHVkZWQgaW4gdGhlIHdheSB3ZSBtYXAgbWVzc2FnZXMuICBJIGRvDQo+IHRoaW5rIHRoaXMg d291bGQgYWxzbyBpbXBseSB0aGF0IGlmIG9uZSBjbGllbnQgc3Vic2NyaWJlcyB0byB0aGUgc2Ft ZQ0KPiBub3RpZmljYXRpb24gbXVsdGlwbGUgdGltZXMgKHJlc3BlY3RpdmVseSwgYSBub3RpZmlj YXRpb24gcGFzc2VzIHRoZQ0KPiBmaWx0ZXIgY3JpdGVyaWEgb2YgbXVsdGlwbGUgc3Vic2NyaXB0 aW9ucyksIHRoZSBub3RpZmljYXRpb24gbmVlZHMNCj4gZWZmZWN0aXZlbHkgdG8gYmUgcmVwbGlj YXRlZCBhY3Jvc3MgbWVzc2FnZSBzdHJlYW1zLiAgKEEgc2ltcGxlIHdheSB0bw0KPiBhdm9pZCB0 aGF0IGluIGFuIGltcGxlbWVudGF0aW9uIHdvdWxkIGJlIHRvIGxpbWl0IGEgc2VydmVyIHRvIHN1 cHBvcnQNCj4gb25seSBhIHNpbmdsZSBzdWJzY3JpcHRpb24gcGVyIHJlY2VpdmVyLikNCg0KSSB0 aGluayBpdCdzIGZpbmUgaWYgYSBjbGllbnQgcmVjZWl2ZXMgdGhlIHNhbWUgbm90aWZpY2F0aW9u IHR3aWNlIGlmDQppdCBoYXMgdHdvIHN1YnNjcmlwdGlvbnMgYW5kIGEgbm90aWZpY2F0aW9uIGlz IGdlbmVyYXRlZCB0aGF0IG1hdGNoZXMNCmJvdGggc3Vic2NyaXB0aW9ucy4NCg0KPiBBcyBtZW50 aW9uZWQgZWFybGllciwgYW5vdGhlciB0aGluZyB3ZSBuZWVkIHRvIGZpeCBpcyB0aGUgc3RyZWFt DQo+IHRlcm1pbm9sb2d5LiAgV2UgbmVlZCB0byBoYXZlIGEgZGlmZmVyZW50IHRlcm0gZm9yIHdo YXQgaXQgaXMgdGhhdCBhDQo+IGNsaWVudCBzdWJzY3JpYmVzIHRvICh0byB3aGljaCBpdCBtYXkg YXBwbHkgZmlsdGVycywgZW5jb2RpbmcgY2hvaWNlcywNCj4gZXRjKSAsIGFuZCBmb3Igd2hhdCB0 aGUgc2VydmVyIHNlbmRzIHRvIHRoZSBjbGllbnQgYXMgcGFydCBvZiBhDQo+IHN1YnNjcmlwdGlv bi4gIE9uZSBpcyB0aGUg4oCcc291cmNl4oCdIChvciDigJx3ZWxs4oCdPyksIHRoZSBvdGhlciB0 aGUNCj4g4oCcc3RyZWFt4oCdLg0KDQpDYW4geW91IGVsYWJvcmF0ZSBhIGJpdD8gIEFyZSB5b3Ug dGFsa2luZyBhYm91dCBzb21lIG5ldyBjb25jZXB0IHRoYXQNCmlzIG5vdCB0aGUgc2FtZSBhcyA1 Mjc3ICJzdHJlYW0iPw0KDQoNCi9tYXJ0aW4NCg== From nobody Tue Dec 6 12:05:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AFB12954A for ; Tue, 6 Dec 2016 12:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSyN3XIuW40I for ; Tue, 6 Dec 2016 12:05:51 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A66129B43 for ; Tue, 6 Dec 2016 12:04:42 -0800 (PST) Received: from LAPTOPR7T053C2 ([47.143.86.36]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MHqjD-1cFAnG1htN-003ayH; Tue, 06 Dec 2016 21:04:35 +0100 From: To: "'Martin Bjorklund'" References: <04ab01d24ff2$6001b410$20051c30$@clemm.org> <04ca01d24ff6$1d450f60$57cf2e20$@clemm.org> <20161206.204244.778854096051701845.mbj@tail-f.com> In-Reply-To: <20161206.204244.778854096051701845.mbj@tail-f.com> Date: Tue, 6 Dec 2016 12:04:32 -0800 Message-ID: <04dc01d24ffb$f6c3d320$e44b7960$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKd5aTG0y5Fyk+X8/0hiMtRRIfuhAKuBy0cA1WYXocCZTbcA58g5LmQ Content-Language: en-us X-Provags-ID: V03:K0:BDPiCc3TCpKoh2b7NwS4LqYZD3EliB62t0pzhD0cMShR6GBdG5s I2B5R5epJqoTBXoMqajd+OsmO1aNUWGKzU/zLjHuNvNMYTCR0JkY+JjIivZtztRLa+nrC5i tlMiQlu0mdjxOaTmGDSVXwqqoMM8Gtf9x+4dmiW4fkn8LXcMovKuYmLEM/uMVtSXr7zvERG dzoswt2zXh1LEAXl/vttQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:XTgpSx62dyo=:GbrvfvewqClU1xLecyhkVG ynBoZ1LMVjwm84f9FzYsso5TDr3kpdnoq/Z6cYd4VXrUrdw34jAq6u9UiHNJPClncP1xeWsUN Jort7JrTRpvk7eT3MWaSGF/0fSQnBHNBzXE8qL6NuCGe5Wmy9rPsP1/fprQpPuao4qvxDHjVb IWbchwS68sFaYnN20GIb+n7Wn2R868R5ooksIyO+o9MKMd346YwL4yg/XLfUARMezicObo3z3 wbR6ibC9KBR9lG7AxFwECt21vMWxLV07TmrBvbb/BFjHS7BCtsrEMdM2WmcJ4m/IPORx7wS9q 7J+voPIfimH7hCBFuIA2gttqBiy6eUlvmWN/TlF92Ya6pAkQ3z/pm8G+BKtt6CTsiga4uMOle jmgwmoOA/KI2ANfkYIOSntnxHw4WddZXRXhh4SoxDpH7vVpnXdggorubI88nfNJ+c64HhBnf4 E6BzZQn9RGzpJqEASjNISmLeNQ8Vep2pJq82Zw7wdRNlcsKkG7+4tbAvE2zD6/JHIN1KPlVbm dGLXMvzUPGQDH9nu7aEDAixVJ90w/Qn4n6F9ik2X5AJQaukIz5Fzr9VSZFJRjdvbt7iiFaovS Wevrg12hgWbtoMUdYj7/cT+cF1Qm98E7hPExh6G6U+mM2VGsrLarIb+REfaxYaxC5/DGsUmEM 5ElRNfagP7iwwQTpvxK85TaGYPspb+uHHjWGLvHwA/B19I5zXSxWy/RGX777HmiAFw1UyTB8e 2gqhlkgQxDPdYExb Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 20:05:53 -0000 Hi Martin, Re item 1, agreed. I think this is the model to go with if we want to = be able to associate messages with subscriptions.=20 Re item 2, no new concepts, but updates to the terminology of existing = concepts. Currently, the term "stream" is used to refer to the = notifications that a client subscribes to. The stream is still subject = to filtering etc, so this is not the same as the sequence of messages = that the client actually receives. We do not have a term for that. It = is easy to see the term "stream" getting overloaded, but arguable the = two concepts need to be clearly distinguished. =20 --- Alex=20 -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Tuesday, December 6, 2016 11:43 AM To: ludwig@clemm.org Cc: andy@yumaworks.com; netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents wrote: > Well, having a subscription ID in messages will facilitate handling of = > different message streams, each tied to a specific subscription. I=20 > can see how this would be useful, but it does mean a change of an=20 > underlying assumption in our design. In that case, the subscription=20 > ID would indeed need to be included in the way we map messages. I do=20 > think this would also imply that if one client subscribes to the same=20 > notification multiple times (respectively, a notification passes the=20 > filter criteria of multiple subscriptions), the notification needs=20 > effectively to be replicated across message streams. (A simple way to = > avoid that in an implementation would be to limit a server to support=20 > only a single subscription per receiver.) I think it's fine if a client receives the same notification twice if it = has two subscriptions and a notification is generated that matches both = subscriptions. > As mentioned earlier, another thing we need to fix is the stream=20 > terminology. We need to have a different term for what it is that a=20 > client subscribes to (to which it may apply filters, encoding choices, > etc) , and for what the server sends to the client as part of a=20 > subscription. One is the =E2=80=9Csource=E2=80=9D (or = =E2=80=9Cwell=E2=80=9D?), the other the=20 > =E2=80=9Cstream=E2=80=9D. Can you elaborate a bit? Are you talking about some new concept that is = not the same as 5277 "stream"? /martin From nobody Tue Dec 6 12:32:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF3B129594 for ; Tue, 6 Dec 2016 12:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 86SJzxZG581U for ; Tue, 6 Dec 2016 12:32:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DE9E6129A5B for ; Tue, 6 Dec 2016 12:32:42 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 67C7B1AE02BC; Tue, 6 Dec 2016 21:32:41 +0100 (CET) Date: Tue, 06 Dec 2016 21:32:41 +0100 (CET) Message-Id: <20161206.213241.1013629339002900541.mbj@tail-f.com> To: ludwig@clemm.org From: Martin Bjorklund In-Reply-To: <04dc01d24ffb$f6c3d320$e44b7960$@clemm.org> References: <04ca01d24ff6$1d450f60$57cf2e20$@clemm.org> <20161206.204244.778854096051701845.mbj@tail-f.com> <04dc01d24ffb$f6c3d320$e44b7960$@clemm.org> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 20:32:52 -0000 PGx1ZHdpZ0BjbGVtbS5vcmc+IHdyb3RlOg0KPiBIaSBNYXJ0aW4sDQo+IA0KPiBSZSBpdGVtIDEs IGFncmVlZC4gIEkgdGhpbmsgdGhpcyBpcyB0aGUgbW9kZWwgdG8gZ28gd2l0aCBpZiB3ZSB3YW50 IHRvDQo+IGJlIGFibGUgdG8gYXNzb2NpYXRlIG1lc3NhZ2VzIHdpdGggc3Vic2NyaXB0aW9ucy4N Cg0KT2suDQoNCj4gUmUgaXRlbSAyLCBubyBuZXcgY29uY2VwdHMsIGJ1dCB1cGRhdGVzIHRvIHRo ZSB0ZXJtaW5vbG9neSBvZiBleGlzdGluZw0KPiBjb25jZXB0cy4gIEN1cnJlbnRseSwgdGhlIHRl cm0gInN0cmVhbSIgaXMgdXNlZCB0byByZWZlciB0byB0aGUNCj4gbm90aWZpY2F0aW9ucyB0aGF0 IGEgY2xpZW50IHN1YnNjcmliZXMgdG8uDQoNCldoZW4geW91IHNheSAiY3VycmVudGx5IiBJIGFz c3VtZSB5b3UgbWVhbiB5b3VyIGRyYWZ0cz8NCg0KSSB0aGluayB0aGUgdGVybSBpcyB3ZWxsLWRl ZmluZWQgaW4gUkZDIDUyNzcgKCJldmVudCBzdHJlYW0iIG9yDQoic3RyZWFtIiksIGFuZCBJIHRo aW5rIHdlIHNob3VsZCBzdGljayB0byB0aGF0IGRlZmluaXRpb24uDQoNCg0KL21hcnRpbg0KDQo+ IFRoZSBzdHJlYW0gaXMgc3RpbGwNCj4gc3ViamVjdCB0byBmaWx0ZXJpbmcgZXRjLCBzbyB0aGlz IGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUgc2VxdWVuY2Ugb2YNCj4gbWVzc2FnZXMgdGhhdCB0aGUg Y2xpZW50IGFjdHVhbGx5IHJlY2VpdmVzLiBXZSBkbyBub3QgaGF2ZSBhIHRlcm0gZm9yDQo+IHRo YXQuICBJdCBpcyBlYXN5IHRvIHNlZSB0aGUgdGVybSAic3RyZWFtIiBnZXR0aW5nIG92ZXJsb2Fk ZWQsIGJ1dA0KPiBhcmd1YWJsZSB0aGUgdHdvIGNvbmNlcHRzIG5lZWQgdG8gYmUgY2xlYXJseSBk aXN0aW5ndWlzaGVkLg0KPiANCj4gLS0tIEFsZXggDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIFttYWlsdG86bWJqQHRhaWwtZi5jb21d IA0KPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciA2LCAyMDE2IDExOjQzIEFNDQo+IFRvOiBsdWR3 aWdAY2xlbW0ub3JnDQo+IENjOiBhbmR5QHl1bWF3b3Jrcy5jb207IG5ldGNvbmZAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtOZXRjb25mXSByZXZpZXcgb2YgImV2ZW50LW5vdGlmaWNhdGlvbiIg ZG9jdW1lbnRzDQo+IA0KPiA8bHVkd2lnQGNsZW1tLm9yZz4gd3JvdGU6DQo+ID4gV2VsbCwgaGF2 aW5nIGEgc3Vic2NyaXB0aW9uIElEIGluIG1lc3NhZ2VzIHdpbGwgZmFjaWxpdGF0ZSBoYW5kbGlu ZyBvZg0KPiA+IGRpZmZlcmVudCBtZXNzYWdlIHN0cmVhbXMsIGVhY2ggdGllZCB0byBhIHNwZWNp ZmljIHN1YnNjcmlwdGlvbi4gIEkgDQo+ID4gY2FuIHNlZSBob3cgdGhpcyB3b3VsZCBiZSB1c2Vm dWwsIGJ1dCBpdCBkb2VzIG1lYW4gYSBjaGFuZ2Ugb2YgYW4gDQo+ID4gdW5kZXJseWluZyBhc3N1 bXB0aW9uIGluIG91ciBkZXNpZ24uICBJbiB0aGF0IGNhc2UsIHRoZSBzdWJzY3JpcHRpb24gDQo+ ID4gSUQgd291bGQgaW5kZWVkIG5lZWQgdG8gYmUgaW5jbHVkZWQgaW4gdGhlIHdheSB3ZSBtYXAg bWVzc2FnZXMuICBJIGRvIA0KPiA+IHRoaW5rIHRoaXMgd291bGQgYWxzbyBpbXBseSB0aGF0IGlm IG9uZSBjbGllbnQgc3Vic2NyaWJlcyB0byB0aGUgc2FtZSANCj4gPiBub3RpZmljYXRpb24gbXVs dGlwbGUgdGltZXMgKHJlc3BlY3RpdmVseSwgYSBub3RpZmljYXRpb24gcGFzc2VzIHRoZSANCj4g PiBmaWx0ZXIgY3JpdGVyaWEgb2YgbXVsdGlwbGUgc3Vic2NyaXB0aW9ucyksIHRoZSBub3RpZmlj YXRpb24gbmVlZHMgDQo+ID4gZWZmZWN0aXZlbHkgdG8gYmUgcmVwbGljYXRlZCBhY3Jvc3MgbWVz c2FnZSBzdHJlYW1zLiAgKEEgc2ltcGxlIHdheSB0bw0KPiA+IGF2b2lkIHRoYXQgaW4gYW4gaW1w bGVtZW50YXRpb24gd291bGQgYmUgdG8gbGltaXQgYSBzZXJ2ZXIgdG8gc3VwcG9ydCANCj4gPiBv bmx5IGEgc2luZ2xlIHN1YnNjcmlwdGlvbiBwZXIgcmVjZWl2ZXIuKQ0KPiANCj4gSSB0aGluayBp dCdzIGZpbmUgaWYgYSBjbGllbnQgcmVjZWl2ZXMgdGhlIHNhbWUgbm90aWZpY2F0aW9uIHR3aWNl IGlmDQo+IGl0IGhhcyB0d28gc3Vic2NyaXB0aW9ucyBhbmQgYSBub3RpZmljYXRpb24gaXMgZ2Vu ZXJhdGVkIHRoYXQgbWF0Y2hlcw0KPiBib3RoIHN1YnNjcmlwdGlvbnMuDQo+IA0KPiA+IEFzIG1l bnRpb25lZCBlYXJsaWVyLCBhbm90aGVyIHRoaW5nIHdlIG5lZWQgdG8gZml4IGlzIHRoZSBzdHJl YW0gDQo+ID4gdGVybWlub2xvZ3kuICBXZSBuZWVkIHRvIGhhdmUgYSBkaWZmZXJlbnQgdGVybSBm b3Igd2hhdCBpdCBpcyB0aGF0IGEgDQo+ID4gY2xpZW50IHN1YnNjcmliZXMgdG8gKHRvIHdoaWNo IGl0IG1heSBhcHBseSBmaWx0ZXJzLCBlbmNvZGluZyBjaG9pY2VzLA0KPiA+IGV0YykgLCBhbmQg Zm9yIHdoYXQgdGhlIHNlcnZlciBzZW5kcyB0byB0aGUgY2xpZW50IGFzIHBhcnQgb2YgYSANCj4g PiBzdWJzY3JpcHRpb24uICBPbmUgaXMgdGhlIOKAnHNvdXJjZeKAnSAob3Ig4oCcd2VsbOKAnT8p LCB0aGUgb3RoZXIgdGhlIA0KPiA+IOKAnHN0cmVhbeKAnS4NCj4gDQo+IENhbiB5b3UgZWxhYm9y YXRlIGEgYml0PyAgQXJlIHlvdSB0YWxraW5nIGFib3V0IHNvbWUgbmV3IGNvbmNlcHQgdGhhdA0K PiBpcyBub3QgdGhlIHNhbWUgYXMgNTI3NyAic3RyZWFtIj8NCj4gDQo+IA0KPiAvbWFydGluDQo+ IA0K From nobody Tue Dec 6 14:19:26 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEBA129CBF for ; Tue, 6 Dec 2016 14:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzWFfNz0TUgM for ; Tue, 6 Dec 2016 14:19:23 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41896129CA9 for ; Tue, 6 Dec 2016 14:19:23 -0800 (PST) Received: from LAPTOPR7T053C2 ([47.143.86.36]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0M4pkR-1cbOYA4Bif-00yzAM; Tue, 06 Dec 2016 23:19:16 +0100 From: To: "'Martin Bjorklund'" References: <04ca01d24ff6$1d450f60$57cf2e20$@clemm.org> <20161206.204244.778854096051701845.mbj@tail-f.com> <04dc01d24ffb$f6c3d320$e44b7960$@clemm.org> <20161206.213241.1013629339002900541.mbj@tail-f.com> In-Reply-To: <20161206.213241.1013629339002900541.mbj@tail-f.com> Date: Tue, 6 Dec 2016 14:19:12 -0800 Message-ID: <05a001d2500e$c72c7730$55856590$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQNVmF6H0XyEC5Qiw5fGctDklNOz2wJlNtwDAd/9Hf8Bkrd0Rp3GK0xw Content-Language: en-us X-Provags-ID: V03:K0:14mBSeE0lspFkkEuVJwSoF3UnzMFXDPqalMrcibE6jagIm7rb7m zLLbNDdnqoLmDp3e+aMdj6sf/YZfm9/adDELh1NJo6h/NIdQWoEF4MMHeAK18oCcBfvzsME +gqtD8EpHIg3rbwc5XieTIDmkUgU4SRpHP4cN/9C6sT9ww8Zel4QKeviTts/ondNCePmTau nPV3KP4hB5Qqg1bK5P6Iw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Ul5OoYLuVqA=:D+dqXZTc3fRGx1bMqrDDr1 2YtO6NsCeF5k9nwIYy3gdEv/RgZkI2RJUPFY5YVVH5AvCegIATgujY1hMauzTu4/LHMjyfu1C /HbqdOCSbDZ7R1UB2li11PNrK90kQBi1LTPKJybexlnI8+d7OTpeaHiq3lX6S+z93p2N36jiy s4C+ZKojXIGYFQ96hsgUx2/TArpSGr/7mZzba5KQ70bxTJp9FsvpuwlRggVmFgzVT5mL+LZMQ 325e4M2DKjPHEOXGwGrlNiNpcDkgeJ7bDXjaawu43eekI6CbqBb8o5SjvzlX8HDLXU16L3dBN 58pgDQHbdreFrVPsINZFH6Z8bcFkVicVlnBmuV07Uo79aL9pYPSyPnAaSPDJJCznMl2JqwM0U NfF1fO2jaX5vSVQaTrhhjIWRmmM4qf1KpMB9ZH5WUZBINuM9nyNBgfidDdzquSYpogzm8hQOY 2KPZ8YF/BkgWfdNWQvglLpvUYcOjXwEH+ZhYpJSCRXQYQhQigvm45Bo/d8Yy+kpZlCarYAt8p e9cua2/fLJ+fEeqS56vIT7oO6vHppZkj+O+FLXmn9mQDYZ8Sw6iQ6zv6MbnduC93TR/lTLv+F vQgivOPE3yHtDPBpM7eA4MTYKa+toTbYjOyKeEbWKltlGyRe2xTvRet4A9EMWM9EktxtdLkne V1V1HAKvDr2owcF02mAV/DpHKkH5Ow8gF7cmcyel8df0QMsgyR0y/JhO/V5fuZxb0eHAHUbQJ zKq/qbJ8MyTVyXOF Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 22:19:25 -0000 Yes. I do think we need to revisit the definitions. I don't think the = definition of RFC 5277 is sufficient for our purposes. At least it = does not seem to cover all the concepts that we need to cover. =20 The definition in RFC 5277 states: =20 Stream: An event stream is a set of event notifications matching some forwarding criteria and available to NETCONF clients for subscription.=20 What are the forwarding criteria and when are they applied - a = subscription can specify its own filters - what would we call the = filtered stream that results? We do need to distinguish the "raw" = stream that is being subscribed to, from the stream of messages that are = actually delivered to a receiver as part of a subscription.=20 --- Alex -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Tuesday, December 6, 2016 12:33 PM To: ludwig@clemm.org Cc: andy@yumaworks.com; netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents wrote: > Hi Martin, >=20 > Re item 1, agreed. I think this is the model to go with if we want to = > be able to associate messages with subscriptions. Ok. > Re item 2, no new concepts, but updates to the terminology of existing = > concepts. Currently, the term "stream" is used to refer to the=20 > notifications that a client subscribes to. When you say "currently" I assume you mean your drafts? I think the term is well-defined in RFC 5277 ("event stream" or = "stream"), and I think we should stick to that definition. /martin > The stream is still > subject to filtering etc, so this is not the same as the sequence of=20 > messages that the client actually receives. We do not have a term for=20 > that. It is easy to see the term "stream" getting overloaded, but=20 > arguable the two concepts need to be clearly distinguished. >=20 > --- Alex >=20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, December 6, 2016 11:43 AM > To: ludwig@clemm.org > Cc: andy@yumaworks.com; netconf@ietf.org > Subject: Re: [Netconf] review of "event-notification" documents >=20 > wrote: > > Well, having a subscription ID in messages will facilitate handling=20 > > of different message streams, each tied to a specific subscription. = > > I can see how this would be useful, but it does mean a change of an=20 > > underlying assumption in our design. In that case, the subscription = > > ID would indeed need to be included in the way we map messages. I=20 > > do think this would also imply that if one client subscribes to the=20 > > same notification multiple times (respectively, a notification=20 > > passes the filter criteria of multiple subscriptions), the=20 > > notification needs effectively to be replicated across message=20 > > streams. (A simple way to avoid that in an implementation would be=20 > > to limit a server to support only a single subscription per=20 > > receiver.) >=20 > I think it's fine if a client receives the same notification twice if=20 > it has two subscriptions and a notification is generated that matches=20 > both subscriptions. >=20 > > As mentioned earlier, another thing we need to fix is the stream=20 > > terminology. We need to have a different term for what it is that a = > > client subscribes to (to which it may apply filters, encoding=20 > > choices, > > etc) , and for what the server sends to the client as part of a=20 > > subscription. One is the =E2=80=9Csource=E2=80=9D (or = =E2=80=9Cwell=E2=80=9D?), the other the=20 > > =E2=80=9Cstream=E2=80=9D. >=20 > Can you elaborate a bit? Are you talking about some new concept that=20 > is not the same as 5277 "stream"? >=20 >=20 > /martin >=20 From nobody Tue Dec 6 14:37:28 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34609126D74 for ; Tue, 6 Dec 2016 14:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 uutfsN7Mla1B for ; Tue, 6 Dec 2016 14:37:25 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 458751295B4 for ; Tue, 6 Dec 2016 14:37:25 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 356CC1AE02BC; Tue, 6 Dec 2016 23:37:24 +0100 (CET) Date: Tue, 06 Dec 2016 23:37:23 +0100 (CET) Message-Id: <20161206.233723.996789263578837425.mbj@tail-f.com> To: ludwig@clemm.org From: Martin Bjorklund In-Reply-To: <05a001d2500e$c72c7730$55856590$@clemm.org> References: <04dc01d24ffb$f6c3d320$e44b7960$@clemm.org> <20161206.213241.1013629339002900541.mbj@tail-f.com> <05a001d2500e$c72c7730$55856590$@clemm.org> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 22:37:27 -0000 PGx1ZHdpZ0BjbGVtbS5vcmc+IHdyb3RlOg0KPiBZZXMuICBJIGRvIHRoaW5rIHdlIG5lZWQgdG8g cmV2aXNpdCB0aGUgZGVmaW5pdGlvbnMuICBJIGRvbid0IHRoaW5rDQo+IHRoZSBkZWZpbml0aW9u IG9mIFJGQyA1Mjc3IGlzIHN1ZmZpY2llbnQgZm9yIG91ciBwdXJwb3Nlcy4gIEF0IGxlYXN0DQo+ IGl0IGRvZXMgbm90IHNlZW0gdG8gY292ZXIgYWxsIHRoZSBjb25jZXB0cyB0aGF0IHdlIG5lZWQg dG8gY292ZXIuDQo+IA0KPiBUaGUgZGVmaW5pdGlvbiBpbiBSRkMgNTI3NyBzdGF0ZXM6ICAgIA0K PiANCj4gU3RyZWFtOiAgQW4gZXZlbnQgc3RyZWFtIGlzIGEgc2V0IG9mIGV2ZW50IG5vdGlmaWNh dGlvbnMgbWF0Y2hpbmcNCj4gICAgICAgc29tZSBmb3J3YXJkaW5nIGNyaXRlcmlhIGFuZCBhdmFp bGFibGUgdG8gTkVUQ09ORiBjbGllbnRzIGZvcg0KPiAgICAgICBzdWJzY3JpcHRpb24uIA0KPiAN Cj4gV2hhdCBhcmUgdGhlIGZvcndhcmRpbmcgY3JpdGVyaWEgYW5kIHdoZW4gYXJlIHRoZXkgYXBw bGllZCAtIGENCj4gc3Vic2NyaXB0aW9uIGNhbiBzcGVjaWZ5IGl0cyBvd24gZmlsdGVycyAtIHdo YXQgd291bGQgd2UgY2FsbCB0aGUNCj4gZmlsdGVyZWQgc3RyZWFtIHRoYXQgcmVzdWx0cz8gIFdl IGRvIG5lZWQgdG8gZGlzdGluZ3Vpc2ggdGhlICJyYXciDQo+IHN0cmVhbSB0aGF0IGlzIGJlaW5n IHN1YnNjcmliZWQgdG8sDQoNClRoaXMgaXMgdGhlICJldmVudCBzdHJlYW0iLg0KDQo+IGZyb20g dGhlIHN0cmVhbSBvZiBtZXNzYWdlcyB0aGF0DQo+IGFyZSBhY3R1YWxseSBkZWxpdmVyZWQgdG8g YSByZWNlaXZlciBhcyBwYXJ0IG9mIGEgc3Vic2NyaXB0aW9uLg0KDQpJcyBhIHRlcm0gbmVlZGVk IGZvciB0aGlzPyAgImRlbGl2ZXJlZCBub3RpZmljYXRpb25zIiBtYXliZT8NCg0KDQoNCi9tYXJ0 aW4NCg0KDQoNCj4gDQo+IC0tLSBBbGV4DQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29tXSAN Cj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgNiwgMjAxNiAxMjozMyBQTQ0KPiBUbzogbHVkd2ln QGNsZW1tLm9yZw0KPiBDYzogYW5keUB5dW1hd29ya3MuY29tOyBuZXRjb25mQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gcmV2aWV3IG9mICJldmVudC1ub3RpZmljYXRpb24iIGRv Y3VtZW50cw0KPiANCj4gPGx1ZHdpZ0BjbGVtbS5vcmc+IHdyb3RlOg0KPiA+IEhpIE1hcnRpbiwN Cj4gPiANCj4gPiBSZSBpdGVtIDEsIGFncmVlZC4gIEkgdGhpbmsgdGhpcyBpcyB0aGUgbW9kZWwg dG8gZ28gd2l0aCBpZiB3ZSB3YW50IHRvDQo+ID4gYmUgYWJsZSB0byBhc3NvY2lhdGUgbWVzc2Fn ZXMgd2l0aCBzdWJzY3JpcHRpb25zLg0KPiANCj4gT2suDQo+IA0KPiA+IFJlIGl0ZW0gMiwgbm8g bmV3IGNvbmNlcHRzLCBidXQgdXBkYXRlcyB0byB0aGUgdGVybWlub2xvZ3kgb2YgZXhpc3RpbmcN Cj4gPiBjb25jZXB0cy4gIEN1cnJlbnRseSwgdGhlIHRlcm0gInN0cmVhbSIgaXMgdXNlZCB0byBy ZWZlciB0byB0aGUgDQo+ID4gbm90aWZpY2F0aW9ucyB0aGF0IGEgY2xpZW50IHN1YnNjcmliZXMg dG8uDQo+IA0KPiBXaGVuIHlvdSBzYXkgImN1cnJlbnRseSIgSSBhc3N1bWUgeW91IG1lYW4geW91 ciBkcmFmdHM/DQo+IA0KPiBJIHRoaW5rIHRoZSB0ZXJtIGlzIHdlbGwtZGVmaW5lZCBpbiBSRkMg NTI3NyAoImV2ZW50IHN0cmVhbSIgb3INCj4gInN0cmVhbSIpLCBhbmQgSSB0aGluayB3ZSBzaG91 bGQgc3RpY2sgdG8gdGhhdCBkZWZpbml0aW9uLg0KPiANCj4gDQo+IC9tYXJ0aW4NCj4gDQo+ID4g VGhlIHN0cmVhbSBpcyBzdGlsbA0KPiA+IHN1YmplY3QgdG8gZmlsdGVyaW5nIGV0Yywgc28gdGhp cyBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIHNlcXVlbmNlIG9mIA0KPiA+IG1lc3NhZ2VzIHRoYXQg dGhlIGNsaWVudCBhY3R1YWxseSByZWNlaXZlcy4gV2UgZG8gbm90IGhhdmUgYSB0ZXJtIGZvciAN Cj4gPiB0aGF0LiAgSXQgaXMgZWFzeSB0byBzZWUgdGhlIHRlcm0gInN0cmVhbSIgZ2V0dGluZyBv dmVybG9hZGVkLCBidXQgDQo+ID4gYXJndWFibGUgdGhlIHR3byBjb25jZXB0cyBuZWVkIHRvIGJl IGNsZWFybHkgZGlzdGluZ3Vpc2hlZC4NCj4gPiANCj4gPiAtLS0gQWxleA0KPiA+IA0KPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZCBbbWFp bHRvOm1iakB0YWlsLWYuY29tXQ0KPiA+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDYsIDIwMTYg MTE6NDMgQU0NCj4gPiBUbzogbHVkd2lnQGNsZW1tLm9yZw0KPiA+IENjOiBhbmR5QHl1bWF3b3Jr cy5jb207IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIHJldmll dyBvZiAiZXZlbnQtbm90aWZpY2F0aW9uIiBkb2N1bWVudHMNCj4gPiANCj4gPiA8bHVkd2lnQGNs ZW1tLm9yZz4gd3JvdGU6DQo+ID4gPiBXZWxsLCBoYXZpbmcgYSBzdWJzY3JpcHRpb24gSUQgaW4g bWVzc2FnZXMgd2lsbCBmYWNpbGl0YXRlIGhhbmRsaW5nIA0KPiA+ID4gb2YgZGlmZmVyZW50IG1l c3NhZ2Ugc3RyZWFtcywgZWFjaCB0aWVkIHRvIGEgc3BlY2lmaWMgc3Vic2NyaXB0aW9uLiAgDQo+ ID4gPiBJIGNhbiBzZWUgaG93IHRoaXMgd291bGQgYmUgdXNlZnVsLCBidXQgaXQgZG9lcyBtZWFu IGEgY2hhbmdlIG9mIGFuIA0KPiA+ID4gdW5kZXJseWluZyBhc3N1bXB0aW9uIGluIG91ciBkZXNp Z24uICBJbiB0aGF0IGNhc2UsIHRoZSBzdWJzY3JpcHRpb24gDQo+ID4gPiBJRCB3b3VsZCBpbmRl ZWQgbmVlZCB0byBiZSBpbmNsdWRlZCBpbiB0aGUgd2F5IHdlIG1hcCBtZXNzYWdlcy4gIEkgDQo+ ID4gPiBkbyB0aGluayB0aGlzIHdvdWxkIGFsc28gaW1wbHkgdGhhdCBpZiBvbmUgY2xpZW50IHN1 YnNjcmliZXMgdG8gdGhlIA0KPiA+ID4gc2FtZSBub3RpZmljYXRpb24gbXVsdGlwbGUgdGltZXMg KHJlc3BlY3RpdmVseSwgYSBub3RpZmljYXRpb24gDQo+ID4gPiBwYXNzZXMgdGhlIGZpbHRlciBj cml0ZXJpYSBvZiBtdWx0aXBsZSBzdWJzY3JpcHRpb25zKSwgdGhlIA0KPiA+ID4gbm90aWZpY2F0 aW9uIG5lZWRzIGVmZmVjdGl2ZWx5IHRvIGJlIHJlcGxpY2F0ZWQgYWNyb3NzIG1lc3NhZ2UgDQo+ ID4gPiBzdHJlYW1zLiAgKEEgc2ltcGxlIHdheSB0byBhdm9pZCB0aGF0IGluIGFuIGltcGxlbWVu dGF0aW9uIHdvdWxkIGJlIA0KPiA+ID4gdG8gbGltaXQgYSBzZXJ2ZXIgdG8gc3VwcG9ydCBvbmx5 IGEgc2luZ2xlIHN1YnNjcmlwdGlvbiBwZXIgDQo+ID4gPiByZWNlaXZlci4pDQo+ID4gDQo+ID4g SSB0aGluayBpdCdzIGZpbmUgaWYgYSBjbGllbnQgcmVjZWl2ZXMgdGhlIHNhbWUgbm90aWZpY2F0 aW9uIHR3aWNlIGlmIA0KPiA+IGl0IGhhcyB0d28gc3Vic2NyaXB0aW9ucyBhbmQgYSBub3RpZmlj YXRpb24gaXMgZ2VuZXJhdGVkIHRoYXQgbWF0Y2hlcyANCj4gPiBib3RoIHN1YnNjcmlwdGlvbnMu DQo+ID4gDQo+ID4gPiBBcyBtZW50aW9uZWQgZWFybGllciwgYW5vdGhlciB0aGluZyB3ZSBuZWVk IHRvIGZpeCBpcyB0aGUgc3RyZWFtIA0KPiA+ID4gdGVybWlub2xvZ3kuICBXZSBuZWVkIHRvIGhh dmUgYSBkaWZmZXJlbnQgdGVybSBmb3Igd2hhdCBpdCBpcyB0aGF0IGEgDQo+ID4gPiBjbGllbnQg c3Vic2NyaWJlcyB0byAodG8gd2hpY2ggaXQgbWF5IGFwcGx5IGZpbHRlcnMsIGVuY29kaW5nIA0K PiA+ID4gY2hvaWNlcywNCj4gPiA+IGV0YykgLCBhbmQgZm9yIHdoYXQgdGhlIHNlcnZlciBzZW5k cyB0byB0aGUgY2xpZW50IGFzIHBhcnQgb2YgYSANCj4gPiA+IHN1YnNjcmlwdGlvbi4gIE9uZSBp cyB0aGUg4oCcc291cmNl4oCdIChvciDigJx3ZWxs4oCdPyksIHRoZSBvdGhlciB0aGUgDQo+ID4g PiDigJxzdHJlYW3igJ0uDQo+ID4gDQo+ID4gQ2FuIHlvdSBlbGFib3JhdGUgYSBiaXQ/ICBBcmUg eW91IHRhbGtpbmcgYWJvdXQgc29tZSBuZXcgY29uY2VwdCB0aGF0IA0KPiA+IGlzIG5vdCB0aGUg c2FtZSBhcyA1Mjc3ICJzdHJlYW0iPw0KPiA+IA0KPiA+IA0KPiA+IC9tYXJ0aW4NCj4gPiANCj4g DQo= From nobody Tue Dec 6 16:53:00 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE10129628 for ; Tue, 6 Dec 2016 16:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUVaDRXAGJFa for ; Tue, 6 Dec 2016 16:52:56 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706A7129617 for ; Tue, 6 Dec 2016 16:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8498; q=dns/txt; s=iport; t=1481071976; x=1482281576; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SRXQHHhGvxSLdI2RnlVRdfPbo0+5ZKfhs1W4yH9Exrg=; b=GVo9OLinfA/ivvXCoTm10zBSbI1VY9EBwdaTxxGoDAF4v/hr+UoIUZEA Oym101YM0ayWDvdLoEz+Pz6645J7MxPwPviQKPwKkf1zGxjAOP28dgSkI HCVvFFrZigxmYsrrcUmcnOV00FLN3q9yDppTYaQBMazgTmVzxiSlwd/TK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBWXEdY/4sNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR+BYAeNQJcOlH6CB4YiAhqCDD8UAQIBAQEBAQEBYii?= =?us-ascii?q?EaAEBAQMBIxFDAgULAgEGAhUDAgIJGgMCAgIwFAEQAgQBDQUIE4hMCIshnUeCK?= =?us-ascii?q?Ys/AQEBAQEBAQEBAQEBAQEBAQEBAQEBHIELhTODU4EIh0yCPx4BBIhihh2FaBW?= =?us-ascii?q?FagGRDoF8hH2EU4R8h2GGIoQNAR83gRkjhTJyiAGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208";a="356672832" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Dec 2016 00:52:55 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uB70qsC9012978 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Dec 2016 00:52:55 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Dec 2016 19:52:54 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Tue, 6 Dec 2016 19:52:54 -0500 From: "Eric Voit (evoit)" To: "Andy Bierman (andy@yumaworks.com)" , "alex@clemm.org" , Martin Bjorklund Thread-Topic: [Netconf] review of "event-notification" documents Thread-Index: AQHSSbPRFuomS98NjUWN0bJG7+k/sKDu2loggAFQ0QD//9QRMIAJf/IAgACTgoCAABdbgIAABR8AgAABqgCAAAF1gIAAA8aAgAAJI4CAAGlMgIAAbWeA///ZesCAAGvvgIAAEBkAgAAx4YCAAAK0cIAABGug Date: Wed, 7 Dec 2016 00:52:54 +0000 Message-ID: References: <20161206.112309.670345130123099005.mbj@tail-f.com> <20161206.162912.565827667614626853.mbj@tail-f.com> <199c40e8fd77402f9aa78c7783f8605a@XCH-RTP-013.cisco.com> In-Reply-To: <199c40e8fd77402f9aa78c7783f8605a@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 00:52:59 -0000 PiBGcm9tOiBBbmR5IEJpZXJtYW4sIERlY2VtYmVyIDYsIDIwMTYgMToyOCBQTQ0KPiANCj4gDQo+ IE9uIFR1ZSwgRGVjIDYsIDIwMTYgYXQgNzoyOSBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWFpbHRv Om1iakB0YWlsLWYuY29tPg0KPiB3cm90ZToNCj4gQW5keSBCaWVybWFuIDxtYWlsdG86YW5keUB5 dW1hd29ya3MuY29tPiB3cm90ZToNCj4gPiBIaSwNCj4gPg0KPiA+IFRoZSBuZXcgc29sdXRpb24g ZGVzaWduIGlzIGNvbXBsZXRlbHkgYnJva2VuIHVubGVzcyBhIG5ldyBub3RpZmljYXRpb24NCj4g PiB3cmFwcGVyIGlzIHVzZWQNCj4gDQo+IEkgYWdyZWUuwqAgVGhlIGN1cnJlbnQgWFNEIGluIDUy NzcgaXMgdmVyeSBpbmZsZXhpYmxlOyBpdCB3b3VsZCBiZQ0KPiB1c2VmdWwgd2l0aCBhIHN0cnVj dHVyZSB0aGF0IGFsbG93cyBzb21lIGZsZXhpYmlsaXR5LCBzcGVjaWZpY2FsbHkNCj4gYWxsb3dz IG5ldyAiaGVhZGVyIiBmaWVsZHMgdG8gYmUgYWRkZWQgdy9vIGhhdmluZyB0byBtb2RpZnkgdGhl DQo+IHByb3RvY29sLsKgIMKgSS5lLiwgYWxsb3cgZWxlbWVudHMgZnJvbSBvdGhlciBuYW1lc3Bh Y2VzIGFmdGVyIHRoZQ0KPiBidWlsdC1pbiBlbGVtZW50cyAoZXZlbnQtdGltZSwgc3Vic2NyaXB0 aW9uLWlkKS4NCj4gDQo+IA0KPiBUaGlzIGluZmxleGliaWxpdHkgaGFzIGJlZW4gYSBwcm9ibGVt Lg0KPiBJIHRoaW5rIGEgbmV3IGVsZW1lbnQgaW4gYSBkaWZmZXJlbnQgbmFtZXNwYWNlIHdvdWxk IGJlIGJldHRlci4NCj4gQ2xpZW50cyB0aGF0IHVzZSB0aGUgbmV3IGhlYWRlciBNVVNUIGFjY2Vw dCBhbmQgaWdub3JlIHVua25vd24gaGVhZGVyDQo+IGZpZWxkcy4NCg0KSSBzZWUgdXNlIGNhc2Vz IHdoZXJlIGEgY29udHJvbGxlciBhY3RzIGFzIGFuIGFnZ3JlZ2F0b3IvZmFjaWxpdGF0b3IgZm9y IEFwcGxpY2F0aW9uIHN1YnNjcmlwdGlvbnMuICAgSW4gdGhpcyBjYXNlLCBpdCBpcyBnb29kbmVz cyBpZiBlYWNoIHN1YnNjcmlwdGlvbiBjYW4gYmUgZWFzaWx5IGRpcmVjdGVkIHRvIHRoZSBvcmln aW5hdGluZyBhcHBsaWNhdGlvbiBhZnRlciB0cmFuc2l0aW5nIHRocm91Z2ggYSBjb250cm9sbGVy LiAgSGF2aW5nIGEgc3Vic2NyaXB0aW9uIElEIHdpdGhpbiB0aGUgYmFzZSBub3RpZmljYXRpb24g aXMgdXNlZnVsLiAgV29ycnlpbmcgYWJvdXQgZHVwbGljYXRlIG9iamVjdCB1cGRhdGVzIGFjcm9z cyBzdWJzY3JpcHRpb24gSURzIGlzIGEgZnV0dXJlIHByb2JsZW0gd2hpY2ggY2FuIGJlIGZ1bGx5 IGhhbmRsZWQgd2l0aGluIHRoZSBkb21haW4gb2YgdGhlIGNvbnRyb2xsZXIuIA0KDQpJbiBsb29r aW5nIGF0IHlvdXIgZXhwYW5kYWJsZSBoZWFkZXIgYmVsb3cgSSBzZWUgdXNlZnVsbmVzcyBpbiBz ZXBhcmF0aW5nIG91dCB0aGUgaGVhZGVyLiAgVGhpcyB3b3VsZCBiZSBhIGdyZWF0IHBsYWNlIHRv IHB1dCB0aGUgY3VycmVudCBhbmQgcHJldmlvdXMgdXBkYXRlIG51bWJlciBhcyBhIHdheSB0byBh c2NlcnRhaW4gYW55IHVwZGF0ZSBsb3NzLiAgSXQgY291bGQgYWxzbyBiZSBleHRlbmRlZCBieSB0 cmFuc3BvcnRzLg0KDQo+IChFeGFtcGxlcyBoYXZlIG5hbWVzcGFjZXMgb21pdHRlZCkNCj4gDQo+ IMKgPG5vdGlmaWNhdGlvbj4NCj4gwqAgwqAgPGhkcj4NCj4gwqAgwqAgwqAgwqA8c3Vic2NyaXB0 aW9uLWlkPjE8L3N1YnNjcmlwdGlvbi1pZD4NCj4gwqAgwqAgwqAgwqA8c2VxdWVuY2UtaWQ+NDI0 Mjwvc2VxdWVuY2UtaWQ+DQo+IMKgIMKgIMKgIMKgLy8gLi4uIG1heWJlIG1vcmUgZmllbGRzIGhl cmUNCj4gwqAgwqA8L2hkcj4NCj4gwqAgwqA8Zm9vLWV2ZW50Pg0KPiDCoCDCoCDCoCAvLyBub3Jt YWwgbm90aWZpY2F0aW9uIGNvbnRlbnRzDQo+IMKgIMKgPC9mb28tZXZlbnQ+DQo+IMKgPC9ub3Rp ZmljYXRpb24+DQo+IA0KPiBvciBZQU5HIDEuMSBuZXN0ZWQ6DQo+IA0KPiANCj4gwqA8bm90aWZp Y2F0aW9uPg0KPiDCoCDCoCA8aGRyPg0KPiDCoCDCoCDCoCDCoDxzdWJzY3JpcHRpb24taWQ+MTwv c3Vic2NyaXB0aW9uLWlkPg0KPiDCoCDCoCDCoCDCoDxzZXF1ZW5jZS1pZD40MjQyPC9zZXF1ZW5j ZS1pZD4NCj4gwqAgwqAgwqAgwqAvLyAuLi4gbWF5YmUgbW9yZSBmaWVsZHMgaGVyZQ0KPiDCoCDC oDwvaGRyPg0KPiDCoCDCoDxpbnRlcmZhY2VzPg0KPiDCoCDCoCDCoCA8aW50ZXJmYWNlPg0KPiDC oCDCoCDCoCDCoCDCoDxuYW1lPmV0aDA8L25hbWU+DQo+IMKgIMKgIMKgIMKgIMKgPGZvby1ldmVu dD4NCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAvLyBub3JtYWwgbm90aWZpY2F0aW9uIGNvbnRlbnRz DQo+IMKgIMKgIMKgIMKgIMKgPC9mb28tZXZlbnQ+DQo+IMKgIMKgIMKgIDwvaW50ZXJmYWNlPg0K PiDCoCDCoCA8L2ludGVyZmFjZXM+DQo+IMKgPC9ub3RpZmljYXRpb24+DQoNCkZvciBZQU5HIDEu MSBuZXN0ZWQsIGlzIHRoZXJlIGRpZmZlcmVuY2UgYmV0d2VlbiBzb21lIDUyNzdiaXMgbm90aWZp Y2F0aW9uIGZvciB0aGUgPGZvby1ldmVudD4sIGFuZCBhIFlBTkcgRGF0YXN0b3JlIHVwZGF0ZSBm b3IgPGZvby1ldmVudD4gYmVpbmcgZW5jYXBzdWxhdGVkIGJ5IGFueXhtbD8gIERvIHlvdSBzZWUg YSByZWFzb24gd2h5IHdlIHdvdWxkbid0IGRvIHRoZSBhYm92ZSB3aXRoIG9uLWNoYW5nZSBZQU5H IFB1c2g/DQoNCj4gSWYgd2Ugd2FudCB0byBkbyB0aGlzIHByb3RvY29sLWFnbm9zdGljLCB3ZSBz aG91bGQgZGVmaW5lIFhNTCBhbmQgSlNPTg0KPiBlbmNvZGluZyBvZiBub3RpZmljYXRpb25zIGlu IG9uZSBkb2N1bWVudDsgdGhlIGdlbmVyYWwgY29uY2VwdHMgb2YNCj4gc3RyZWFtcyBhbmQgZmls dGVycyBldGMgaW4gb25lIGRvY3VlbWVudDsgcHJvdG9jb2wtc3BlY2lmaWMgbWVjaGFuaXNtcw0K PiB0byByZXRyaWV2ZSBkYXRhIGZyb20gc3RyZWFtcyBpbiBhbm90aGVyICh1bmZvcnR1bmF0ZWx5 LCB3ZSBjYW4ndA0KPiBkZWZpbmUgcHJvdG9jb2wtYWdub3N0aWMgcnBjIG9wZXJhdGlvbnMgZm9y IHRoaXMsIHNpbmNlIHRoZXNlDQo+IG9wZXJhdGlvbnMgb25seSB3b3JrIGZvciBzZXNzaW9uLWJh c2VkIHByb3RvY29scykNCg0KSSBjZXJ0YWlubHkgc2VlIGZpbHRlcnMvc3RyZWFtcyBldm9sdmlu ZyBxdWl0ZSBhIGJpdCBvdmVyIHRpbWUuICBIYXZpbmcgYSBwbGFjZSBmb3IgbmV3IHZhcmlhbnRz IG9mIHRoaXMgKGluY2x1ZGluZyBzdXBwb3J0IGZvciBPcFN0YXRlKSB3aWxsIGJlIGNvbWluZy4N Cg0KPiBJdCB3b3VsZCBiZSBiZXR0ZXIgaWYgdGhlIDxub3RpZmljYXRpb24+IGVsZW1lbnQgY291 bGQgYmUgbW9kZWxlZCBpbiBZQU5HDQo+IHNvIGl0IGNhbiBiZSBhdWdtZW50ZWQgYW5kIGFsc28g aXQgd291bGQgYmUgZW5jb2RpbmctaW5kZXBlbmRlbnQuDQo+IChlLmcuIFlBTkcgdG8gQ0JPUiBj b3VsZCBiZSB1c2VkKQ0KDQpNYWtlcyBzZW5zZS4NCg0KRXJpYw0KDQo+IA0KPiA+IC9tYXJ0aW4N Cj4gDQo+IA0KPiANCj4gQW5keQ0KPiANCj4gDQo+IA0KPiA+IG9yIHRoZSBzdWJzY3JpcHRpb24t aWQgaXMgcmVtb3ZlZCBmcm9tIHRoZSBkZXNpZ24uwqAgVGhlcmUgaXMgbm8gd2F5IHRoaXMNCj4g PiBmaWVsZCBjYW4gYmUgZGVmaW5lZA0KPiA+IGFzIHBhcnQgb2YgdGhlIGV2ZW50IHBheWxvYWQu wqAgRXZlcnkgbm90aWZpY2F0aW9uIGhhcyB0byBkZWZpbmUgYSBmaWVsZA0KPiA+IG5hbWUgJ3N1 YnNjcmlwdGlvbi1pZCc/DQo+ID4gVGhlIGlkZW50aWZpZXIgJ3N1YnNjcmlwdGlvbi1pZCcgYmVj b21lcyByZXNlcnZlZCBzbyBpdCBjYW5ub3QgYmUgdXNlZA0KPiA+IGFueXdoZXJlDQo+ID4NCj4g PsKgIMKgbGlzdCBmb28gew0KPiA+wqAgwqAgwqAga2V5IHN1YnNjcmlwdGlvbi1pZDsNCj4gPsKg IMKgIMKgIGxlYWYgc3Vic2NyaXB0aW9uLWlkIHsgdHlwZSBzdHJpbmc7IH0NCj4gPsKgIMKgIMKg IG5vdGlmaWNhdGlvbiBiYXI7DQo+ID7CoCDCoH0NCj4gPg0KPiA+IEhvdyB3b3VsZCBhIFlBTkcg MS4xIG5lc3RlZCBub3RpZmljYXRpb24gYmUgc3VwcG9ydGVkPw0KPiA+IEhvdyB3b3VsZCBhbnkg ZXhpc3Rpbmcgbm90aWZpY2F0aW9uLXN0bXQgdGhhdCBkb2VzIG5vdCBkZWZpbmUgdGhpcyBsZWFm IGJlDQo+ID4gc3VwcG9ydGVkPw0KPiA+IEhvdyB3aWxsIG11bHRpcGxlIHN1YnNjcmlwdGlvbnMg YmUgc2VudCBvdmVyIHRoZSBzYW1lIGNvbm5lY3Rpb24/DQo+ID4NCj4gPiBJZiA1Mjc3IHN1cHBv cnQgaXMgc28gaW1wb3J0YW50IHRoZW4gbWFrZSBpdCB3b3JrIGJ5IGVsaW1pbmF0aW5nIGV2ZXJ5 dGhpbmcNCj4gPiByZWxhdGVkIHRvIHN1YnNjcmlwdGlvbiBJRHMgZnJvbSB0aGUgc29sdXRpb24u wqAgSU1PIGl0IHdvdWxkIGJlIGJldHRlciB0bw0KPiA+IGRlc2lnbiBhIG5ldyBzb2x1dGlvbiB0 aGF0IGlzIHByb3Blcmx5IGxheWVyZWQuDQo+ID4NCj4gPg0KPiA+IEFuZHkNCj4gPg0KPiA+DQo+ ID4NCj4gPg0KPiA+IE9uIFR1ZSwgRGVjIDYsIDIwMTYgYXQgNjoxMSBBTSwgRXJpYyBWb2l0IChl dm9pdCkgPG1haWx0bzpldm9pdEBjaXNjby5jb20+DQo+IHdyb3RlOg0KPiA+DQo+ID4gPiA+IEZy b206IE1hcnRpbiBCam9ya2x1bmQgRGVjZW1iZXIgNiwgMjAxNiA1OjIzIEFNDQo+ID4gPiA+DQo+ ID4gPiA+IEFuZHkgQmllcm1hbiA8bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ ID4gPiA+ID4gUGVyaGFwcyB0aGUgV0cgbmVlZHMgdG8gYWdyZWUgb24gdGhlIDUyNzcgcmV1c2Ug cmVxdWlyZW1lbnRzIGJlZm9yZQ0KPiA+ID4gPiA+IGRpdmluZyB3b3JraW5nIG9uIHNvbHV0aW9u IGRldGFpbHMuDQo+ID4gPiA+DQo+ID4gPiA+ICsxDQo+ID4gPg0KPiA+ID4gWWVzLsKgIMKgV2Ug aGF2ZSBiZWVuIGFzc3VtaW5nIHJldXNlIHVudGlsIG5vdy7CoCBUaGlzIGlzIHdoYXQgaXMgaW4g dGhlIFdHDQo+ID4gPiBjaGFydGVyLsKgIEFuZCB0aGlzIGlzIHdoYXQgd2UgaGF2ZSBiZWVuIGJ1 aWxkaW5nIHRvIGluIHRoZSBjdXJyZW50IGRyYWZ0DQo+ID4gPiBzZXQuDQo+ID4gPg0KPiA+ID4g VGhlcmUgYXJlIG5vIHBsYW5zIHRvIGNoYW5nZSB0aGlzIGRpcmVjdGlvbiB1bmxlc3MgdGhlIFdH IHNlbGVjdHMNCj4gPiA+ICdvYnNvbGV0ZScgb3ZlciAnZW5oYW5jZScuwqAgwqBUaGVyZSBhcmUg YmVuZWZpdHMgdG8gZWFjaC7CoCBCZWxvdyBpcyBteQ0KPiA+ID4gc3VtbWFyeSBmb3IgYmVuZWZp dHMgb2YgZWFjaCBwYXRoLsKgIFBsZWFzZSBhZGQgYW55IHRoYXQgSSBtaWdodCBoYXZlDQo+ID4g PiBtaXNzZWQuLi4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gQmVuZWZpdHMgb2YgJ2VuaGFuY2UnDQo+ ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiAtIEJhY2t3YXJkcyBjb21w YXRpYmlsaXR5IHRocm91Z2ggc2luZ2xlIGludGVncmF0ZWQgc3BlYw0KPiA+ID4gLSBTaW5nbGUg Y29kZWJhc2UgaGFuZGxlcyBhbGwgc3Vic2NyaXB0aW9uIHJlcXVlc3RzIGlmIGxlZ2FjeSBhbmQg bmV3IHdpbGwNCj4gPiA+IGJlIHJ1bm5pbmcgY29uY3VycmVudGx5DQo+ID4gPg0KPiA+ID4gQmVu ZWZpdHMgb2YgJ29ic29sZXRlJw0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+ID4gLSBTaW1wbGVyLCBzbWFsbGVyIHNwZWNpZmljYXRpb24NCj4gPiA+IC0gQmFja3dhcmRz IGNvbXBhdGliaWxpdHkgdGhyb3VnaCBwYXJhbGxlbCBpbXBsZW1lbnRhdGlvbiBhbmQgY2FwYWJp bGl0aWVzDQo+ID4gPiBleGNoYW5nZQ0KPiA+ID4gLSBTdWJzY3JpcHRpb25zIGRlY291cGxlZCBm cm9tIE5FVENPTkYgbmFtZXNwYWNlDQo+ID4gPiAtIEZld2VyIGVycm9yIGNvbmRpdGlvbnMgKGUu Zy4sIHdoYXQgaWYgeW91IGdldCB0d28gPGNyZWF0ZS1zdWJzY3JpcHRpb24+DQo+ID4gPiBmcm9t IHdoYXQgeW91IHRob3VnaHQgd2FzIGEgbGVnYWN5IGNsaWVudC4pDQo+ID4gPg0KPiA+ID4gV29y dGh5IG9mIGRpc2N1c3Npb24NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g PiA+IC0gSW50ZXJwbGF5IG9mIHN0cmVhbXMgYW5kIGZpbHRlcnMuwqAgV2lsbC9tdXN0IG9ic29s ZXRlIHZzIGVuaGFuY2UgaW1wYWN0DQo+ID4gPiB0aGlzIGRlY2lzaW9uPw0KPiA+ID4gLSBIb3cg bWFueSBSUENzLCBhbmQgaG93IGNvbXBsZXggc2hvdWxkIHRoZXkgYmU/wqAgV2hhdCBhcmUgdGhl IGltcGFjdHMNCj4gb2YNCj4gPiA+IG92ZXJsb2FkaW5nLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBF cmljDQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gL21hcnRpbg0KPiA+ID4NCg0K From nobody Wed Dec 7 00:13:15 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3458D1296A0 for ; Wed, 7 Dec 2016 00:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 g6fePN1Jywjv for ; Wed, 7 Dec 2016 00:13:12 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF0B129691 for ; Wed, 7 Dec 2016 00:13:12 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id C76FB1AE028C; Wed, 7 Dec 2016 09:13:09 +0100 (CET) Date: Wed, 07 Dec 2016 09:13:09 +0100 (CET) Message-Id: <20161207.091309.1120006136134788111.mbj@tail-f.com> To: evoit@cisco.com From: Martin Bjorklund In-Reply-To: References: <20161206155239.GA98983@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 08:13:14 -0000 "Eric Voit (evoit)" wrote: > > From: Juergen Schoenwaelder, December 6, 2016 10:53 AM > > Concerning RFC 5277, it may be desirable to make a minor update (e.g., > > to get > > rid of the XSD and to use YANG) but whether this is worth the effort I > > do not > > know. Perhaps RFC 5277 is good enough to let it rest in peace. > > Rest-in-peace was the conclusion of a number of us in the Dezign team. My original point was that the current set of drafts are very incomplete when it comes to RFC 5277. They claim they obsolete it, but they also refer to definitons in it, and they don't talk at all about how to send notifications over NETCONF. Keep it as it is (not obsolete) is certainly one option. /martin From nobody Wed Dec 7 00:19:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB751296A0 for ; Wed, 7 Dec 2016 00:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 tjf4kHXQ0r_f for ; Wed, 7 Dec 2016 00:19:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8D282129442 for ; Wed, 7 Dec 2016 00:19:51 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id CF1CB1AE028C; Wed, 7 Dec 2016 09:19:50 +0100 (CET) Date: Wed, 07 Dec 2016 09:19:50 +0100 (CET) Message-Id: <20161207.091950.293357531482191030.mbj@tail-f.com> To: mersue@gmail.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] new NACM draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 08:19:53 -0000 MehmetErsue wrote: > Hi Andy, Martin, > > thank you for the initial draft. > > We discussed in IETF 97 different issues and the additional sections we > could add. Ok. But do we have to resolve all issues before adopting this document? I think the current document is ready for adoption, and then the WG can work on fixing any open issues. > IIRC the list was: > - schema-mount related text into schema-mount or the NACM draft, I think schema mount needs to discuss how it works with NACM. This should be an open issue in schema mount. > - assigning priorities to clients, I don't believe this is a NACM issue. > - access control on dynamic datastores (e.g. I2RS), The text in 3.2 probably need to be relaxed a bit to allow NACM to be applied to other datastores. > - the issue from RFC 6536 with parent/child relationships which is > important for RESTCONF. Can you elaborate on this? /martin > > I would like to suggest to have a discussion on these issues and understand > whether they should be included. > > Mehmet > > On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman wrote: > > > Hi, > > > > A new version of draft-bierman-netconf-rfc6536bis has been posted: > > https://www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt > > > > > > We would like this draft to be adopted as the starting point for item #5 > > in the current NETCONF charter. > > > > > > > > Andy and Martin > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > -- > Cheers, > Mehmet From nobody Wed Dec 7 06:36:13 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C908C129F56 for ; Wed, 7 Dec 2016 06:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c1WgYQc1e8X for ; Wed, 7 Dec 2016 06:36:11 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BD7129F75 for ; Wed, 7 Dec 2016 06:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1777; q=dns/txt; s=iport; t=1481121184; x=1482330784; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hBdfw74dn18Pk21H0AcZt3oLz41nbg2feO7yAEJvNbc=; b=F5P7C8nZb7u6byr39vUg7cCrtuq3rrJxwqmzHcUuw7WQydWX3+40qzC+ W9bk27F2xwlswBLHoNCfif0v8h9v7mEYIk4uzAvaUhRHLg1EMro2O760N o5Sw21fujrXMf5wL49ulHtI00q9LXzbQAm2wDLg9kmW6pftMm45WOcNpV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQB9HEhY/5FdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR+BYAeNQZcQlH6CB4YiAoF2PxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?oAQEBAwE6PQIFCwIBCA4HAw0REDIlAgQOBQiIXwiqfIs9AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR6GPoRbigseBZpmAZEOgXyOTIdhhiKEDQEfN4EZg1wcgV1yiDmBDQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208";a="178374390" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2016 14:33:03 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uB7EX1fg031746 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Dec 2016 14:33:04 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Dec 2016 09:33:00 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 7 Dec 2016 09:33:00 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund Thread-Topic: [Netconf] review of "event-notification" documents Thread-Index: AQHSSbPRFuomS98NjUWN0bJG7+k/sKDu2loggAFQ0QD//9QRMIAJf/IAgACTgoCAABdbgIAABR8AgAABqgCAAAF1gIAAA8aAgAAJI4CAAGlMgIAAbWeA///ZesCAAIKVgP//zRjQACibc4AAAUVx8A== Date: Wed, 7 Dec 2016 14:33:00 +0000 Message-ID: <2a6331ea7ac54457b8b3cd6f10f12688@XCH-RTP-013.cisco.com> References: <20161206155239.GA98983@elstar.local> <20161207.091309.1120006136134788111.mbj@tail-f.com> In-Reply-To: <20161207.091309.1120006136134788111.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.241.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 14:36:13 -0000 > From: Martin Bjorklund, December 7, 2016 3:13 AM >=20 > "Eric Voit (evoit)" wrote: > > > From: Juergen Schoenwaelder, December 6, 2016 10:53 AM >=20 > > > Concerning RFC 5277, it may be desirable to make a minor update > > > (e.g., to get rid of the XSD and to use YANG) but whether this is > > > worth the effort I do not know. Perhaps RFC 5277 is good enough to > > > let it rest in peace. > > > > Rest-in-peace was the conclusion of a number of us in the Dezign team. >=20 > My original point was that the current set of drafts are very incomplete = when it > comes to RFC 5277. They claim they obsolete it, but they also refer to > definitons in it, and they don't talk at all about how to send notificati= ons over > NETCONF. The intent has been to get the set of drafts in a place where the 5277bis += notif-netconf drafts could act together as a 'bis'. You absolutely are c= orrect that not everything was incorporated & cleaned-up yet. =20 > Keep it as it is (not obsolete) is certainly one option. Are you advocating for this option? =20 The two 'not obsolete' options path I see are: (a) WG advocates parallel IETF notification subscription mechanisms for NET= CONF: 5277 & this newer work. To me this doesn't seem tenable. (b) WG has notification subscription capabilities which are less functional= the datastore subscription capabilities. (I.e., notifications would not s= upport capabilities such as multiple subs/transport, modify, delete, config= ured sub, OAM messages, alternative non-NETCONF transports, etc.) The yang-push work was originally going down path (b) until the WG requeste= d that subscription capabilities of RFC 7923 be supported for notifications= . Eric > /martin From nobody Wed Dec 7 07:54:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF4C129F5C for ; Wed, 7 Dec 2016 07:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JGLHymJV4Xz for ; Wed, 7 Dec 2016 07:54:47 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1218129F66 for ; Wed, 7 Dec 2016 07:54:38 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id f82so173605641wmf.1 for ; Wed, 07 Dec 2016 07:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nwc1jq98t3aHBOYWPa/SkweT4/D4cW2NXKTb0P7rqek=; b=reOKQYciyugzOp2ik1hpzzDP4UuCdrlSm5wQEmSkf/KFhOPxdH8rnTdTd/Yj41olwg dCJx3M/IHOe2O8FG8d8ZcgZDFFPu2zbCmycRG+0j21epEelNi3J6eu/UqmYoj3I04kAt flqQ2RpJXDGFq6trIJNpZzMtPQq7vq91nfwGla7UcNqrAOqApu4CVUTUSuT0gr/5/R3+ NSiaEVX5q5gv2q+o0RyzDPs0QPgvKkhPBz2KKTI6OqzSdsDoAMQONHrs7vPQSQ7f0Hf6 GMIeK0U/65KokDe2yKgT6A1La7J3j/hZsUjqXH77Z7FMRDTSKBWB0sc4ti21i/L626Fu 8rbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nwc1jq98t3aHBOYWPa/SkweT4/D4cW2NXKTb0P7rqek=; b=kscR5/phc7IiVDB96Zl7WYCQEV78iSmLZp2+o8G49rd9kOlYufZS30EeZb+k9N4wAp G7SUlhQmHFpbZxBwYHwMWQ2oqnJJbwUu2/x8/+JBwfmWskOjHSo0vxf8kYnth5aCf+lb xFnDlTpSKubGq66tYSepayYCpSzWZCysCY3rG1Ew3u9Dx5jxqfbJi9RjEbGD1U/8mmem RXtQ/AfaFLjdFZKAEovJplYe/BDV65UF7YJaIwAnOu7aw9KKy8VlgPz+2q3VZWO4F1b8 SMIooETXz1M/lLmOm9mqHBH1C4LR4qZnlQBILqd0C1bqX/1Vap4YbOB24ucpAjbVYC/P ocww== X-Gm-Message-State: AKaTC02Bxcc3bzxcPmNQn6qlwNrRMK4eeeqi/WNeJXa4rTiyxSWdyPWN3HLl5rdNpf3ePEJs4K1DZFqFUm7fvA== X-Received: by 10.25.24.159 with SMTP id 31mr25646778lfy.101.1481126077033; Wed, 07 Dec 2016 07:54:37 -0800 (PST) MIME-Version: 1.0 References: <20161207.091950.293357531482191030.mbj@tail-f.com> In-Reply-To: <20161207.091950.293357531482191030.mbj@tail-f.com> From: MehmetErsue Date: Wed, 07 Dec 2016 15:54:26 +0000 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a114119dab075b80543138973 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] new NACM draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 15:54:49 -0000 --001a114119dab075b80543138973 Content-Type: text/plain; charset=UTF-8 Hi Martin, All, we discussed the listed issues in IETF 97 very roughly. The request from IETF 97 was to have a discussion on the issues and understand better whether they should be included. We don't need to solve them before adoption. > > - the issue from RFC 6536 with parent/child relationships which is > > important for RESTCONF. > > Can you elaborate on this? IIRC the question was on whether a client with read access to a target node also has read access to the ancestor nodes in order to be able to read the target node's data. @All: We would like to get comments/opinions on to whether the listed issues should be covered in 6536bis. > > - schema-mount related text into schema-mount or the NACM draft, > > - assigning priorities to clients, > > - access control on dynamic datastores (e.g. I2RS), > > - the issue from RFC 6536 with parent/child relationships which is important for RESTCONF. BR, Mehmet On Wed, Dec 7, 2016 at 9:19 AM Martin Bjorklund wrote: > MehmetErsue wrote: > > Hi Andy, Martin, > > > > thank you for the initial draft. > > > > We discussed in IETF 97 different issues and the additional sections we > > could add. > > Ok. But do we have to resolve all issues before adopting this > document? I think the current document is ready for adoption, and > then the WG can work on fixing any open issues. > > > IIRC the list was: > > - schema-mount related text into schema-mount or the NACM draft, > > I think schema mount needs to discuss how it works with NACM. This > should be an open issue in schema mount. > > > - assigning priorities to clients, > > I don't believe this is a NACM issue. > > > - access control on dynamic datastores (e.g. I2RS), > > The text in 3.2 probably need to be relaxed a bit to allow NACM to be > applied to other datastores. > > > - the issue from RFC 6536 with parent/child relationships which is > > important for RESTCONF. > > Can you elaborate on this? > > > /martin > > > > > > > I would like to suggest to have a discussion on these issues and > understand > > whether they should be included. > > > > Mehmet > > > > On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman > wrote: > > > > > Hi, > > > > > > A new version of draft-bierman-netconf-rfc6536bis has been posted: > > > https://www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt > > > > > > > > > We would like this draft to be adopted as the starting point for item > #5 > > > in the current NETCONF charter. > > > > > > > > > > > > Andy and Martin > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > -- > > Cheers, > > Mehmet > -- Cheers, Mehmet --001a114119dab075b80543138973 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin, All,

we d= iscussed the listed issues in IETF 97 very roughly. The request from IETF 9= 7 was to have a discussion on the issues and understand better whether they= should be included.
We don't need to solve them before adoption.

> > - the issue from RFC 6536 with parent/child relationships= which is
>=20 > important for RESTCONF.
>=20
>=20 Can you elaborate on this?

IIRC the question was on whether a client with read acc= ess to a target node also has read access to the ancestor nodes in order to= be able to read the target node's data.

= @All: We would like to get comments/opinions on to whether the listed issue= s should be covered in 6536bis.

> >=20 - schema-mount related text into schema-mount or the NACM draft,
> >=20 - assigning priorities to clients,
> >=20 - access control on dynamic datastores (e.g. I2RS),
= > >=20 - the issue from RFC 6536 with parent/child relationships which is importan= t for RESTCONF.

BR,
Mehmet

On Wed, Dec 7, 2016 at = 9:19 AM Martin Bjorklund <mbj@tail-f.c= om> wrote:
MehmetErsue <<= a href=3D"mailto:mersue@gmail.com" class=3D"gmail_msg" target=3D"_blank">me= rsue@gmail.com> wrote:
> Hi Andy, Martin,
>
> thank you for the initial draft.
>
> We discussed in IETF 97 different issues and the additional sections w= e
> could add.

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

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

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

> - assigning priorities to clients,

I don't believe this is a NACM issue.

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

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

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

Can you elaborate on this?


/martin



>
> I would like to suggest to have a discussion on these issues and under= stand
> whether they should be included.
>
> Mehmet
>
> On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman <andy@yumaworks.com<= /a>> wrote:
>
> > Hi,
> >
> > A new version of draft-bierman-netconf-rfc6536bis has been posted= :
> > https:/= /www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt
> >
> >
> > We would like this draft to be adopted as the starting point for = item #5
> > in the current NETCONF charter.
> >
> >
> >
> > Andy and Martin
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mail= man/listinfo/netconf
> >
> >
>
>
> --
> Cheers,
> Mehmet
--
Cheers,
Mehmet
--001a114119dab075b80543138973-- From nobody Wed Dec 7 09:38:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FF2128AB0 for ; Wed, 7 Dec 2016 09:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb87OwKr9cWe for ; Wed, 7 Dec 2016 09:38:14 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CD11289C4 for ; Wed, 7 Dec 2016 09:38:14 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id f82so178487014wmf.1 for ; Wed, 07 Dec 2016 09:38:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QCeUZZfxq66M0dGzG3lkYRArsG7/osiZMQhn4Tz3VWE=; b=Me+3OKnW9JbaN0KSyEzyLqx+VADiJ+nK4G2nF3MohySGeLVnCt3MAEmBGrksvWAMwn k6seB1GdSPlkcExwDJYnVSU7xT7YqyMJ6WO+p49Fnnz80aY58dAHbf93v/gF/z7//62v of/oCA9FoLuRBHWz6ig2r8dlSrpk9njXT9vI9Qb9bgiX1IzZNFmcNEfCT7GwCRtwQ7Cd wQ9dEcUGHZdw9o/6Sfs3OL8egl0zaVeMjrXxBmAMwb9QAUjlEstIIpMM8rqsoX6gZjgk FUiUo2VC2fOKDiNBI5VYmuyL1hxFnHqrXHE2FNGCmDoFBjkN+7gcGxAxkZz7hVtgr1rT a6HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QCeUZZfxq66M0dGzG3lkYRArsG7/osiZMQhn4Tz3VWE=; b=kESpKztjwU0JdQW0z7zMI3qAPia++NOPq/cB8fut6E+MqlOUkPESu0Ajzk0aVXAoNs 7KJF5aI0pMbJQ/tpWayWql1PALl9CCWxyCUk4Opy+63aVavLqy2zu2GNarHLBBqQsPGi eTZA54V4abHk2GfhMmvPLpIRtLCJKwgOV1pv+F4uGF6PEp9YtpET/JW5CD6WyuJbYnre NfxJZtbnjGwEpqOhx87m7u31VjSkUP3zFJp2pNGCLc5fPKQE4WPHoSFT1j79WaHrTAwz N1iCVlr65L4wBtWnYLCGp8Jbp5Nhof6bsZJLcDd4sbArZ0MnvLZz206VcCl8jWausj8s r0kg== X-Gm-Message-State: AKaTC02NDag6+6QTfV/fQI0oIFYYard2DG4sgWLW3VN7avpQtx03gaV9A1Qred8+69J0ZIazYmSBybePOts5PA== X-Received: by 10.46.9.129 with SMTP id 123mr26129591ljj.20.1481132291764; Wed, 07 Dec 2016 09:38:11 -0800 (PST) MIME-Version: 1.0 References: <20161205.214831.712192266937344872.mbj@tail-f.com> <20161205.223443.1094826795624770286.mbj@tail-f.com> In-Reply-To: <20161205.223443.1094826795624770286.mbj@tail-f.com> From: MehmetErsue Date: Wed, 07 Dec 2016 17:38:01 +0000 Message-ID: To: Martin Bjorklund , andy@yumaworks.com Content-Type: multipart/alternative; boundary=001a114b0e681dc7b7054314fcfa Archived-At: Cc: netconf@ietf.org Subject: [Netconf] Still subject to agree on NETCONF ML WAS:Re: review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 17:38:17 -0000 --001a114b0e681dc7b7054314fcfa Content-Type: text/plain; charset=UTF-8 All, > > The element is changing so old clients cannot > > get the new version that contains a subscription-id and other > > fields. > > I haven't seen any proposal for doing this on the ML. Any discussion result from the notification team meetings is still subject to agree on NETCONF ML. Such issues should be raised on the ML, the earlier the better. Mehmet On Mon, Dec 5, 2016 at 10:35 PM Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund > > > wrote: > > > > > > > > > Andy Bierman wrote: > > > > > > Hi, > > > > > > > > > > > > I prefer the current solution approach, which is to use > > > > > > 'establish-subscription'. > > > > > > > > > > Can you elaborate on why you prefer two operations instead of one, > > > > > when they do the same thing? > > > > > > > > > > > > > because they don't do the same thing. > > > > The new solution has configured filters, subscription-id, suspend and > > > > cancel operations > > > > > > These are trivial extensions to the current solution. > > > > > > If they are truly different the names should not be so similar. > > > > > > > and should not need streams. > > > > > > What do you mean "should not need streams"? > > > > > > > > > > The streams concept is half-baked and not useful. > > I strongly disagree. The stream concept including replay is very > powerful. > > If you think it should be deprecated and replaced with something else, > I think that requires some careful discussion first. (such as a > description of its problems, and a description of a new solution). > > > We have 1 stream, NETCONF, which MUST contain everything > > No it doesn't. This was dicussed recently. The text says: > > This stream contains all NETCONF XML event notifications supported by > the NETCONF server. > > Note it says "all NETCONF XML event notifications", not "all > [XML] event notifications". > > > and > > MUST be encoded in XML. > > Well, NETCONF is encoded in XML so this should not come as a > surprise... > > > Every other stream is purely ad-hoc and > > proprietary > > Not really. All streams supported can be discovered by any client > (with proper access rights). > > > with no chance at interoperability. > > This is a false statement. We have defined several different streams > that third party clients use w/o any problems. If a stream doesn't > interoperate b/c of its name, some implementation is buggy. > > > > > The old solution can be deprecated and replaced. > > > > > > Sure, if it is broken. But I don't think it is broken in any way. > > > > > > > > > > > The element is changing so old clients cannot > > get the new version that contains a subscription-id and other > > fields. > > I haven't seen any proposal for doing this on the ML. > > > IMO it is simpler and clearer if the new solution is separate. > > Maybe. Anyway, my post was really in reply to Eric's statement that > these new features could not be built on top of what we have and still > be backwards compatible. > > One way of making streams even more useful is to make them > configurable, e.g. instead of creating configurable filters, an idea > is to create a new stream together with a filter, and replay > definition. Being able to do this dynamically would actually be quite > useful. > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Cheers, Mehmet --001a114b0e681dc7b7054314fcfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

> > The <nofitication> e= lement is changing so old clients cannot
>=20 > get the new version that contains a subscription-id and other
>=20 > fields.
>=20
>=20 I haven't seen any proposal for doing this on the ML.

Any discussion result from the notification team meetings is = still subject to agree on NETCONF ML.
Such issues should be r= aised on the ML, the earlier the better.

Mehmet
<= br>
On Mon, Dec 5, 2016 at 10:35= PM Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <and= y@yumaworks.com> wrote:
> On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com&= gt; wrote:
>
> > Andy Bierman <andy@yumaworks.com> wrote:
> > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <mbj@tail-= f.com>
> > wrote:
> > >
> > > > Andy Bierman <andy@yumaworks.com> wrote:
> > > > > Hi,
> > > > >
> > > > > I prefer the current solution approach, which is t= o use
> > > > > 'establish-subscription'.
> > > >
> > > > Can you elaborate on why you prefer two operations inst= ead of one,
> > > > when they do the same thing?
> > > >
> > >
> > > because they don't do the same thing.
> > > The new solution has configured filters, subscription-id, su= spend and
> > > cancel operations
> >
> > These are trivial extensions to the current solution.
> >
> > If they are truly different the names should not be so similar. > >
> > > and should not need streams.
> >
> > What do you mean "should not need streams"?
> >
> >
>
> The streams concept is half-baked and not useful.

I strongly disagree.=C2=A0 The stream concept including replay is very
powerful.

If you think it should be deprecated and replaced with something else,
I think that requires some careful discussion first.=C2=A0 (such as a
description of its problems, and a description of a new solution).

> We have 1 stream, NETCONF, which MUST contain everything

No it doesn't.=C2=A0 This was dicussed recently.=C2=A0 The text says:
=C2=A0 =C2=A0This stream contains all NETCONF XML event notifications suppo= rted by
=C2=A0 =C2=A0the NETCONF server.

Note it says "all NETCONF XML event notifications", not "all=
[XML] event notifications".

> and
> MUST be encoded in XML.

Well, NETCONF is encoded in XML so this should not come as a
surprise...

> Every other stream is purely ad-hoc and
> proprietary

Not really.=C2=A0 All streams supported can be discovered by any client
(with proper access rights).

> with no chance at interoperability.

This is a false statement.=C2=A0 We have defined several different streams<= br class=3D"gmail_msg"> that third party clients use w/o any problems.=C2=A0 If a stream doesn'= t
interoperate b/c of its name, some implementation is buggy.

> > > The old solution can be deprecated and replaced.
> >
> > Sure, if it is broken.=C2=A0 But I don't think it is broken i= n any way.
> >
> >
> >
> The <nofitication> element is changing so old clients cannot
> get the new version that contains a subscription-id and other
> fields.

I haven't seen any proposal for doing this on the ML.

> IMO it is simpler and clearer if the new solution is separate.

Maybe.=C2=A0 Anyway, my post was really in reply to Eric's statement th= at
these new features could not be built on top of what we have and still
be backwards compatible.

One way of making streams even more useful is to make them
configurable, e.g. instead of creating configurable filters, an idea
is to create a new stream together with a filter, and replay
definition.=C2=A0 Being able to do this dynamically would actually be quite=
useful.


/martin

_______________________________________________
Netconf mailing list
N= etconf@ietf.org
https://www.ietf.org/mailman/listin= fo/netconf
--
Cheers,
Mehm= et
--001a114b0e681dc7b7054314fcfa-- From nobody Wed Dec 7 09:54:08 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F80129530 for ; Wed, 7 Dec 2016 09:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 fhLqcWbFWHPB for ; Wed, 7 Dec 2016 09:54:04 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93236129659 for ; Wed, 7 Dec 2016 09:54:04 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id n21so421672227qka.3 for ; Wed, 07 Dec 2016 09:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z6DZAsLFq6r65ZZS2Ede40gIWYoOMk9iWuXlYvVHzHc=; b=M1eqlonz+t87QPiuCd/hhuNzHNeiWOUEg9VOsqYmVssZaO/LQVZrLm51iMJzHhHe6N KMQ6M14ToZbeUvrqqN3A6oxHm1ue4TqO0lwRcF/U+UwtBLRC/2jcqv1vH9563VzXp4gM ug6+mGqAX8Gz+RYAm+RrXJbj/abgaGijeRB5Zc/VggX9brlrtQiPPNnivnmTNuWJTUAa QFhWlsKe5dnFPgKE3s4vU7qusyqhwqNJ4vK+ozH5XE9inK3V0fCkb/LZOvzPIlr8oRNY mpq72YY7/VRXdjL/ocswKXAUeOUjM15JOKPc8YmKCJ6aGl8MXVutOWrF7WDV5tI5wI+E IpeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z6DZAsLFq6r65ZZS2Ede40gIWYoOMk9iWuXlYvVHzHc=; b=iEa/20uZdxmXnB8t1XR5xlAYIAaa90ICyhpcr7t1Tv91U7Djn5HBpce4bRkkZ0ST3Q EcVTbIlrUgW8z0B7iiHBlc4+OhCTuYGDf4quReMuZIIzSGpkMf0kP98pDo1DGcQ5Jpia zPFnrHaCLS/E/p45H1nANF7fEA4uTtJwuK98aOMvZQ+8FQpHhuLFr/OfzUVWKcmk59hQ VuKBFMfS1kpPwI1Jctd2j2oUeTDzBMePRAzN3ftUmWMXvbIZLEmRSQTgIqJapzg45jbE jDOi1HE59RgltQHinc3Wdy1HGczjmHGo2sjIpfSE1TQsL4G4YhWmUpW55wWQrvORHAkC esRw== X-Gm-Message-State: AKaTC01SPDKdmeTfgVcXYb2LKz1eOj9BrZfx2bQjSCIU9Fx/HzzrqgWAPtGBdS5XUMcf1j2ftkpLec909XEowQ== X-Received: by 10.55.155.206 with SMTP id d197mr7842055qke.127.1481133242451; Wed, 07 Dec 2016 09:54:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Wed, 7 Dec 2016 09:54:01 -0800 (PST) In-Reply-To: References: <20161205.214831.712192266937344872.mbj@tail-f.com> <20161205.223443.1094826795624770286.mbj@tail-f.com> From: Andy Bierman Date: Wed, 7 Dec 2016 09:54:01 -0800 Message-ID: To: MehmetErsue Content-Type: multipart/alternative; boundary=94eb2c075bacc82a48054315343c Archived-At: Cc: Netconf Subject: Re: [Netconf] Still subject to agree on NETCONF ML WAS:Re: review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 17:54:07 -0000 --94eb2c075bacc82a48054315343c Content-Type: text/plain; charset=UTF-8 On Wed, Dec 7, 2016 at 9:38 AM, MehmetErsue wrote: > All, > > > > The element is changing so old clients cannot > > > get the new version that contains a subscription-id and other > > > fields. > > > > I haven't seen any proposal for doing this on the ML. > > Any discussion result from the notification team meetings is still subject > to agree on NETCONF ML. > Such issues should be raised on the ML, the earlier the better. > > I think Martin has raised valid concerns that we do not yet agree on the requirements. The details of a solution do not matter if people do not agree on the problem first. What are the must-have, should-have, and nice-to-have features that are missing from RFC 5277? E.g., if we agree that is is a terrible burden on the client that 1 session be used for each subscription, then multiple subscriptions per session is an important feature. How to do that is the next step, not this step. > Mehmet > Andy > > On Mon, Dec 5, 2016 at 10:35 PM Martin Bjorklund wrote: > >> Andy Bierman wrote: >> > On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund >> wrote: >> > >> > > Andy Bierman wrote: >> > > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund >> > > wrote: >> > > > >> > > > > Andy Bierman wrote: >> > > > > > Hi, >> > > > > > >> > > > > > I prefer the current solution approach, which is to use >> > > > > > 'establish-subscription'. >> > > > > >> > > > > Can you elaborate on why you prefer two operations instead of one, >> > > > > when they do the same thing? >> > > > > >> > > > >> > > > because they don't do the same thing. >> > > > The new solution has configured filters, subscription-id, suspend >> and >> > > > cancel operations >> > > >> > > These are trivial extensions to the current solution. >> > > >> > > If they are truly different the names should not be so similar. >> > > >> > > > and should not need streams. >> > > >> > > What do you mean "should not need streams"? >> > > >> > > >> > >> > The streams concept is half-baked and not useful. >> >> I strongly disagree. The stream concept including replay is very >> powerful. >> >> If you think it should be deprecated and replaced with something else, >> I think that requires some careful discussion first. (such as a >> description of its problems, and a description of a new solution). >> >> > We have 1 stream, NETCONF, which MUST contain everything >> >> No it doesn't. This was dicussed recently. The text says: >> >> This stream contains all NETCONF XML event notifications supported by >> the NETCONF server. >> >> Note it says "all NETCONF XML event notifications", not "all >> [XML] event notifications". >> >> > and >> > MUST be encoded in XML. >> >> Well, NETCONF is encoded in XML so this should not come as a >> surprise... >> >> > Every other stream is purely ad-hoc and >> > proprietary >> >> Not really. All streams supported can be discovered by any client >> (with proper access rights). >> >> > with no chance at interoperability. >> >> This is a false statement. We have defined several different streams >> that third party clients use w/o any problems. If a stream doesn't >> interoperate b/c of its name, some implementation is buggy. >> >> > > > The old solution can be deprecated and replaced. >> > > >> > > Sure, if it is broken. But I don't think it is broken in any way. >> > > >> > > >> > > >> > The element is changing so old clients cannot >> > get the new version that contains a subscription-id and other >> > fields. >> >> I haven't seen any proposal for doing this on the ML. >> >> > IMO it is simpler and clearer if the new solution is separate. >> >> Maybe. Anyway, my post was really in reply to Eric's statement that >> these new features could not be built on top of what we have and still >> be backwards compatible. >> >> One way of making streams even more useful is to make them >> configurable, e.g. instead of creating configurable filters, an idea >> is to create a new stream together with a filter, and replay >> definition. Being able to do this dynamically would actually be quite >> useful. >> >> >> /martin >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > -- > Cheers, > Mehmet > --94eb2c075bacc82a48054315343c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 7, 2016 at 9:38 AM, MehmetErsue <mersue@gmail.com> wrote:
A= ll,

> > The <nofitication> element is changing so old cl= ients cannot
>=20 > get the new version that contains a subscription-id and other
>=20 > fields.
>=20
>=20 I haven't seen any proposal for doing this on the ML.

Any discussion result from the notification team meetings is = still subject to agree on NETCONF ML.
Such issues should be r= aised on the ML, the earlier the better.


I think Martin has raised valid concerns that we do not y= et agree on the requirements.
The details of a solution do not ma= tter if people do not agree on the problem first.

= What are the must-have, should-have, and nice-to-have features that are mis= sing from RFC 5277?

E.g., if we agree that is is a= terrible burden on the client that 1 session be used for each subscription= ,
then multiple subscriptions per session is an important feature= .=C2=A0 How to do that is the next step,
not this step.


=C2=A0
<= div dir=3D"ltr">
Mehmet



Andy
=C2=A0

On Mon, Dec 5, 2016 at 10:35 PM Martin Bjorklund <mbj@tail-f.com> wrote:<= br>
Andy Bierman <andy@yumaworks.com> wrote:
> On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaworks.com>= wrote:
> > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Andy Bierman <andy@yumaworks.c= om> wrote:
> > > > > Hi,
> > > > >
> > > > > I prefer the current solution approach, which is t= o use
> > > > > 'establish-subscription'.
> > > >
> > > > Can you elaborate on why you prefer two operations inst= ead of one,
> > > > when they do the same thing?
> > > >
> > >
> > > because they don't do the same thing.
> > > The new solution has configured filters, subscription-id, su= spend and
> > > cancel operations
> >
> > These are trivial extensions to the current solution.
> >
> > If they are truly different the names should not be so similar. > >
> > > and should not need streams.
> >
> > What do you mean "should not need streams"?
> >
> >
>
> The streams concept is half-baked and not useful.

I strongly disagree.=C2=A0 The stream concept including replay is very
powerful.

If you think it should be deprecated and replaced with something else,
I think that requires some careful discussion first.=C2=A0 (such as a
description of its problems, and a description of a new solution).

> We have 1 stream, NETCONF, which MUST contain everything

No it doesn't.=C2=A0 This was dicussed recently.=C2=A0 The text says:
=C2=A0 =C2=A0This stream contains all NETCONF XML event notifications suppo= rted by
=C2=A0 =C2=A0the NETCONF server.

Note it says "all NETCONF XML event notifications", not "all=
[XML] event notifications".

> and
> MUST be encoded in XML.

Well, NETCONF is encoded in XML so this should not come as a
surprise...

> Every other stream is purely ad-hoc and
> proprietary

Not really.=C2=A0 All streams supported can be discovered by any client
(with proper access rights).

> with no chance at interoperability.

This is a false statement.=C2=A0 We have defined several different streams<= br class=3D"m_5658855994277033756gmail_msg"> that third party clients use w/o any problems.=C2=A0 If a stream doesn'= t
interoperate b/c of its name, some implementation is buggy.

> > > The old solution can be deprecated and replaced.
> >
> > Sure, if it is broken.=C2=A0 But I don't think it is broken i= n any way.
> >
> >
> >
> The <nofitication> element is changing so old clients cannot
> get the new version that contains a subscription-id and other
> fields.

I haven't seen any proposal for doing this on the ML.

> IMO it is simpler and clearer if the new solution is separate.

Maybe.=C2=A0 Anyway, my post was really in reply to Eric's statement th= at
these new features could not be built on top of what we have and still
be backwards compatible.

One way of making streams even more useful is to make them
configurable, e.g. instead of creating configurable filters, an idea
is to create a new stream together with a filter, and replay
definition.=C2=A0 Being able to do this dynamically would actually be quite=
useful.


/martin

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ie= tf.org/mailman/listinfo/netconf
<= font color=3D"#888888">
--
Cheers,
Mehmet

--94eb2c075bacc82a48054315343c-- From nobody Wed Dec 7 11:03:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08EB12954F for ; Wed, 7 Dec 2016 11:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ndmoID7htZm for ; Wed, 7 Dec 2016 11:03:17 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CAA129554 for ; Wed, 7 Dec 2016 11:03:17 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id t79so181869828wmt.0 for ; Wed, 07 Dec 2016 11:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dGnGCJULF5Me4htMDGbiT+C3IP61I4LINSr4YnD+s7k=; b=DAdtcLQKweQuE2FDY68V004Zf00I4aJJoynh0F7zErbl0F4no6ZvwaYCsmyP+JSa6T ULZSPgYHz11Ic5LjYTsARywHy7c1vkUuc+ldsowNT/X/7gSWsDVIbg0bLU79BasaVFA3 mw/3QoamG0zmh0i+/q0H0JqBM4MOO2ZYf36Oo7QnQKMspXhH3HhyfRG4HWoj5Fsm3mK1 8luf9v5YGNwSpBBETEX5QNseL1ciLo1q9KU/b+yKUpa3QKXF/dxsOD2BdJIusH4wdu1O seiuSxO6qJ7hHBBX4q0gIf7imx5wozlbF2qr1x6KRYTdn5rS0agq081ci1xLteDCsH/4 ecQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dGnGCJULF5Me4htMDGbiT+C3IP61I4LINSr4YnD+s7k=; b=DIHjyg2QoVl3iCaiHZyBi4DJCA7SeVsMBlZ7sNy/yVfFuOdTrsrQir/1W0Y+cq1Cs+ VZjAICl+Ae1vJojIBUPIjWPMOIxEpwjfrxCuChPzMDn0m1FYXkCL+4fzHPETU6e+K/3t ZEYHYpl5M1hFKjj179ZV7EOsW9YI0NdsllTYwNN5m7qLOJeCMc4UV5vJD+6jIZEoKIj9 fCH06Z3w9SDI/dUEb8loiiCIkzOwMFbjj6dNVVwGpIQVyPrDgKcXtne1K4JvgmNd9dgR tW2Vk8p9jSVxZ3HC16x7+/ppVsfDtWGgFKiwf0ZM+4tzREuNjhe7kSkn9wPZyM0uqFRP +7eg== X-Gm-Message-State: AKaTC02tds6JYhWxnV0rgEsgYuwgU8dmtXeKJEBElOVT3fFkvWPJ/Dbi4S6g5cYWCP6pg1NYGlcnm4KxZLYMXA== X-Received: by 10.25.23.221 with SMTP id 90mr24946715lfx.34.1481137395473; Wed, 07 Dec 2016 11:03:15 -0800 (PST) MIME-Version: 1.0 References: <20161205.223443.1094826795624770286.mbj@tail-f.com> <20161206.112309.670345130123099005.mbj@tail-f.com> <20161206155239.GA98983@elstar.local> In-Reply-To: <20161206155239.GA98983@elstar.local> From: MehmetErsue Date: Wed, 07 Dec 2016 19:03:04 +0000 Message-ID: To: Juergen Schoenwaelder , "Eric Voit (evoit)" , Martin Bjorklund , "andy@yumaworks.com" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=001a114118a05224480543162cde Archived-At: Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:03:20 -0000 --001a114118a05224480543162cde Content-Type: text/plain; charset=UTF-8 > > Benefits of 'enhance' > > ---------------------------- > > - Backwards compatibility through single integrated spec Technically spoken, I think it would valuable for the industry to support the future use of 5277 and backwards compatibility with it. Though achieving the full backwards compatibility in one document will be very effortful. > Benefits of 'obsolete' > > ---------------------------- > > - Simpler, smaller specification > > - Backwards compatibility through parallel implementation and capabilities exchange > > Again, backwards compatibility is a property of a design. Apparently, > it can't be used as an argument to both 'enhance' and 'obsolete'. IMO it actually should be called "Benefits of enabling two solutions" as I understand there is interest to keep using 5277 instead of obsoleting. And I think we shouldn't use "backwards compatibility" in this case. It is rather enabling the use of two solutions through parallel implementation and capabilities exchange. > Given that the changes relative to RFC 5277 are significant, it makes > sense to me to view the proposal as a new event subscription interface > and not as an extension of RFC 5277. Agree. > Concerning RFC 5277, it may be desirable to make a minor update (e.g., > to get rid of the XSD and to use YANG) but whether this is worth the > effort I do not know. I think updating 5277 to use YANG is nice-to-have. BR, Mehmet On Tue, Dec 6, 2016 at 4:53 PM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Dec 06, 2016 at 02:11:19PM +0000, Eric Voit (evoit) wrote: > > > From: Martin Bjorklund December 6, 2016 5:23 AM > > > > > > Andy Bierman wrote: > > > > Perhaps the WG needs to agree on the 5277 reuse requirements before > > > > diving working on solution details. > > > > > > +1 > > > > Yes. We have been assuming reuse until now. This is what is in the WG > charter. And this is what we have been building to in the current draft > set. > > > > There are no plans to change this direction unless the WG selects > 'obsolete' over 'enhance'. There are benefits to each. Below is my > summary for benefits of each path. Please add any that I might have > missed... > > > > I do not have a strong opinion on this but I think it is worth > commenting on some of your benefits - and to perhaps provide an > opinion of someone who is just observing things. > > > Benefits of 'enhance' > > ---------------------------- > > - Backwards compatibility through single integrated spec > > Backwards compatibility is a property of a design, it does not matter > how many specs are used to write the design down. > > > - Single codebase handles all subscription requests if legacy and new > will be running concurrently > > This is a pure implementation issue. A single codebase can be used > to support N subscription interfaces equally well. > > > Benefits of 'obsolete' > > ---------------------------- > > - Simpler, smaller specification > > - Backwards compatibility through parallel implementation and > capabilities exchange > > Again, backwards compatibility is a property of a design. Apparently, > it can't be used as an argument to both 'enhance' and 'obsolete'. > > > - Subscriptions decoupled from NETCONF namespace > > - Fewer error conditions (e.g., what if you get two > from what you thought was a legacy client.) > > So these seem to be some arguments here (not sure how strong they are). > > > Worthy of discussion > > ---------------------------- > > - Interplay of streams and filters. Will/must obsolete vs enhance > impact this decision? > > - How many RPCs, and how complex should they be? What are the impacts > of overloading. > > It seems to me that RFC 5277 is pretty much tied to NETCONF/SSH and > that having a much more flexible subscription mechanism as suggested > goes pretty far beyond what RFC 5277 did, both in functionality but > also in trying to support different protocols carrying notifications. > Given that the changes relative to RFC 5277 are significant, it makes > sense to me to view the proposal as a new event subscription interface > and not as an extension of RFC 5277. > > Concerning RFC 5277, it may be desirable to make a minor update (e.g., > to get rid of the XSD and to use YANG) but whether this is worth the > effort I do not know. Perhaps RFC 5277 is good enough to let it rest > in peace. > > /js > > PS: Note that I have not implemented any of this, hence my opinion > should likely not count too much. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 <0421%202003587> Campus Ring 1 | 28759 > Bremen | Germany > Fax: +49 421 200 3103 <0421%202003103> < > http://www.jacobs-university.de/> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Cheers, Mehmet --001a114118a05224480543162cde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> > Benefits of 'enhance'= ;
>=20 > ----------------------------
>=20 > - Backwards compatibility through single integrated spec

Technically spoken, I think it would valuable for the in= dustry to support the future use of 5277 and=20 backwards compatibility with it. Though achieving the full backwards compatibility in one document = will be very effortful.

> Benefits of 'obsolete'
>=20 > ----------------------------
>=20 > - Simpler, smaller specification
>=20 > - Backwards compatibility through parallel implementation and capabili= ties exchange
>=20
>=20 Again, backwards compatibility is a property of a design. Apparently,
>=20 it can't be used as an argument to both 'enhance' and 'obso= lete'.

IMO it actually should be called "Benefits of enabling t= wo solutions" as I understand there is interest to keep using 5277 ins= tead of obsoleting.
And I think we shouldn't use "ba= ckwards compatibility" in this case. It is rather enabling the use of = two solutions through parallel implementation and capabilities exchange.

>=20 Given that the changes relative to RFC 5277 are significant, it makes
>=20 sense to me to view the proposal as a new event subscription interface
>=20 and not as an extension of RFC 5277.

Agree.

> Concerning RFC 5277, it may be desirable t= o make a minor update (e.g.,
> to get rid of the = XSD and to use YANG) but whether this is worth the
&= gt; effort I do not know.

I think updating 5277 to use YANG is=20 nice-to-have.

BR,
Mehmet

=
On Tue, Dec 6, 2016 a= t 4:53 PM Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Dec 06, 2016 at 02:11:19PM +0000,= Eric Voit (evoit) wrote:
> > From: Martin Bjorklund December 6, 2016 5:23 AM
> >
> > Andy Bierman <andy@yumaworks.com> wrote:
> > > Perhaps the WG needs to agree on the 5277 reuse requirements= before
> > > diving working on solution details.
> >
> > +1
>
> Yes.=C2=A0 =C2=A0We have been assuming reuse until now.=C2=A0 This is = what is in the WG charter.=C2=A0 And this is what we have been building to = in the current draft set.
>
> There are no plans to change this direction unless the WG selects '= ;obsolete' over 'enhance'.=C2=A0 =C2=A0There are benefits to ea= ch.=C2=A0 Below is my summary for benefits of each path.=C2=A0 Please add a= ny that I might have missed...
>

I do not have a strong opinion on this but I think it is worth
commenting on some of your benefits - and to perhaps provide an
opinion of someone who is just observing things.

> Benefits of 'enhance'
> ----------------------------
> - Backwards compatibility through single integrated spec

Backwards compatibility is a property of a design, it does not matter
how many specs are used to write the design down.

> - Single codebase handles all subscription requests if legacy and new = will be running concurrently

This is a pure implementation issue. A single codebase can be used
to support N subscription interfaces equally well.

> Benefits of 'obsolete'
> ----------------------------
> - Simpler, smaller specification
> - Backwards compatibility through parallel implementation and capabili= ties exchange

Again, backwards compatibility is a property of a design. Apparently,
it can't be used as an argument to both 'enhance' and 'obso= lete'.

> - Subscriptions decoupled from NETCONF namespace
> - Fewer error conditions (e.g., what if you get two <create-subscri= ption> from what you thought was a legacy client.)

So these seem to be some arguments here (not sure how strong they are).

> Worthy of discussion
> ----------------------------
> - Interplay of streams and filters.=C2=A0 Will/must obsolete vs enhanc= e impact this decision?
> - How many RPCs, and how complex should they be?=C2=A0 What are the im= pacts of overloading.

It seems to me that RFC 5277 is pretty much tied to NETCONF/SSH and
that having a much more flexible subscription mechanism as suggested
goes pretty far beyond what RFC 5277 did, both in functionality but
also in trying to support different protocols carrying notifications.
Given that the changes relative to RFC 5277 are significant, it makes
sense to me to view the proposal as a new event subscription interface
and not as an extension of RFC 5277.

Concerning RFC 5277, it may be desirable to make a minor update (e.g.,
to get rid of the XSD and to use YANG) but whether this is worth the
effort I do not know. Perhaps RFC 5277 is good enough to let it rest
in peace.

/js

PS: Note that I have not implemented any of this, hence my opinion
=C2=A0 =C2=A0 should likely not count too much.

--
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 | 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.d= e/>

_______________________________________________
Netconf mailing list
N= etconf@ietf.org
https://www.ietf.org/mailman/listin= fo/netconf
--
Cheers,
Mehmet
--001a114118a05224480543162cde-- From nobody Wed Dec 7 11:03:37 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D1A12956C for ; Wed, 7 Dec 2016 11:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if8q7-yDzQNk for ; Wed, 7 Dec 2016 11:03:22 -0800 (PST) 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 F00E112954F for ; Wed, 7 Dec 2016 11:03:21 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id g23so182945812wme.1 for ; Wed, 07 Dec 2016 11:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8SpoYCkIgS0HOdd4LtOUwRQc3ga+49FciViW9cTzXZM=; b=fYv3Gi1wIt/OBhVjATf4j6gMx0Ai7YA0F+SAKDqyV82a+aPRM2byp4se2jnXhFZMtJ 6UlfdoEOQoAbq+cE0WZb8pbm3XkWTvn0yaSptJy5n26tqG1ZhZnF5G2K76yd7BRLSCLt KGlDmnojqgYGadXMC8/+rAJJxcdzgQNVq9am6t+FYwZmRTzmuru/dZ07eoQTlqPNMXKt fLUNhYOBL2HzP7VjHMWtJK+61Oorr7UgSzX1yuw2bs47yxh+R4AM5mmu2iUOrn88GKGO fwi31JFx5Akl1Il+hkMZP6NApTukdvG+TcJf7+50aCHAHSmrKeqJfFPVs8Y3ODDvF7uX qhIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8SpoYCkIgS0HOdd4LtOUwRQc3ga+49FciViW9cTzXZM=; b=RZm2ZkP/7DsFRPjMw4SEVEkPjEwb8O9DAWnvr56MXCBBekxbVb1ggXePV7F/c1Bp2x KEtqn0D9A/5N2WoljKvzJf6Gz+z2oqBJ6Y921npLTpgwkf6n5UwCzm70htAztKwem8cz NMNVJTL+KZv9KAd0McFsL1PO9rOILVoZW3DgslgTu5RW5T9xOPEVemm3R5p8FYlmlWOu HcHhsjBxk09gIt+L27eqLbY0DFt1BZucxZK+L50B0v8mopngW9z2bcnGyAd1oBcCG7Iv O+b7bWa4Lrm+8jgMtrJWHeoBMAYfU4UNBV/0SOvG2yZKNP3ljVHAqGSL1lu7uaQN3k69 T9fg== X-Gm-Message-State: AKaTC01FXZf+Kr0aQIPEVgPMxFde30pIeGEfmIZLvSNIoyze0/thXujTZ/iBczuWdxUoIXvtTxCgt7HVN9Mzug== X-Received: by 10.46.8.17 with SMTP id 17mr32369804lji.72.1481137400360; Wed, 07 Dec 2016 11:03:20 -0800 (PST) MIME-Version: 1.0 References: <20161206155239.GA98983@elstar.local> <20161207.091309.1120006136134788111.mbj@tail-f.com> <2a6331ea7ac54457b8b3cd6f10f12688@XCH-RTP-013.cisco.com> In-Reply-To: <2a6331ea7ac54457b8b3cd6f10f12688@XCH-RTP-013.cisco.com> From: MehmetErsue Date: Wed, 07 Dec 2016 19:03:09 +0000 Message-ID: To: "Eric Voit (evoit)" , Martin Bjorklund Content-Type: multipart/alternative; boundary=f403045ecf0a9cb6420543162cc8 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:03:24 -0000 --f403045ecf0a9cb6420543162cc8 Content-Type: text/plain; charset=UTF-8 > > Keep it as it is (not obsolete) is certainly one option. > > Are you advocating for this option? > > The two 'not obsolete' options path I see are: > (a) WG advocates parallel IETF notification subscription mechanisms for NETCONF: 5277 & this newer work. To me this doesn't seem tenable. Can you please elaborate why this is not tenable? Technically spoken I think it is the easiest way to enable continuing to use 5277 as it is and at the same to reduce the necessary effort for the new solution. > (b) WG has notification subscription capabilities which are less functional the datastore subscription capabilities. (I.e., notifications would not support capabilities such as multiple subs/transport, modify, > delete, configured sub, OAM messages, alternative non-NETCONF transports, etc.) > > The yang-push work was originally going down path (b) until the WG requested that subscription capabilities of RFC 7923 be supported for notifications. This requires some discussion to understand the impacts. BR, Mehmet On Wed, Dec 7, 2016 at 3:36 PM Eric Voit (evoit) wrote: > > From: Martin Bjorklund, December 7, 2016 3:13 AM > > > > "Eric Voit (evoit)" wrote: > > > > From: Juergen Schoenwaelder, December 6, 2016 10:53 AM > > > > > > Concerning RFC 5277, it may be desirable to make a minor update > > > > (e.g., to get rid of the XSD and to use YANG) but whether this is > > > > worth the effort I do not know. Perhaps RFC 5277 is good enough to > > > > let it rest in peace. > > > > > > Rest-in-peace was the conclusion of a number of us in the Dezign team. > > > > My original point was that the current set of drafts are very incomplete > when it > > comes to RFC 5277. They claim they obsolete it, but they also refer to > > definitons in it, and they don't talk at all about how to send > notifications over > > NETCONF. > > The intent has been to get the set of drafts in a place where the 5277bis > + notif-netconf drafts could act together as a 'bis'. You absolutely are > correct that not everything was incorporated & cleaned-up yet. > > > Keep it as it is (not obsolete) is certainly one option. > > Are you advocating for this option? > > The two 'not obsolete' options path I see are: > (a) WG advocates parallel IETF notification subscription mechanisms for > NETCONF: 5277 & this newer work. To me this doesn't seem tenable. > (b) WG has notification subscription capabilities which are less > functional the datastore subscription capabilities. (I.e., notifications > would not support capabilities such as multiple subs/transport, modify, > delete, configured sub, OAM messages, alternative non-NETCONF transports, > etc.) > > The yang-push work was originally going down path (b) until the WG > requested that subscription capabilities of RFC 7923 be supported for > notifications. > > Eric > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Cheers, Mehmet --f403045ecf0a9cb6420543162cc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> > Keep it as it is (not obsolete) i= s certainly one option.
>=20
>=20 Are=C2=A0 you advocating for this option?
>=20
>=20 The two 'not obsolete' options path I see are:
>=20 (a) WG advocates parallel IETF notification subscription mechanisms for=20 NETCONF: 5277 & this newer work.=C2=A0 To me this doesn't seem tena= ble.

Can you please elaborate why this is not tenable?
Technicall= y spoken I think it is the easiest way to enable continuing to use 5277 as = it is and at the same to reduce the necessary effort for the new solution.<= br>

>=20 (b) WG has notification subscription capabilities which are less=20 functional the datastore subscription capabilities.=C2=A0 (I.e.,=20 notifications would not support capabilities such as multiple=20 subs/transport, modify, >=20 delete, configured sub, OAM messages,=20 alternative non-NETCONF transports, etc.)
>=20
>=20 The yang-push work was originally going down path (b) until the WG=20 requested that subscription capabilities of RFC 7923 be supported for=20 notifications.

This requires some discussion to understand the impacts.

<= /div>BR,
Mehmet

<= div dir=3D"ltr">On Wed, Dec 7, 2016 at 3:36 PM Eric Voit (evoit) <evoit@cisco.com> wrote:
> From: Martin Bjorklund, December 7, 2016 3:13= AM
>
> "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > From: Juergen Schoenwaelder, December 6, 2016 10:53 AM
>
> > > Concerning RFC 5277, it may be desirable to make a minor upd= ate
> > > (e.g., to get rid of the XSD and to use YANG) but whether th= is is
> > > worth the effort I do not know. Perhaps RFC 5277 is good eno= ugh to
> > > let it rest in peace.
> >
> > Rest-in-peace was the conclusion of a number of us in the Dezign = team.
>
> My original point was that the current set of drafts are very incomple= te when it
> comes to RFC 5277.=C2=A0 They claim they obsolete it, but they also re= fer to
> definitons in it, and they don't talk at all about how to send not= ifications over
> NETCONF.

The intent has been to get the set of drafts in a place where the 5277bis += notif-netconf drafts could act together as a 'bis'.=C2=A0 =C2=A0Yo= u absolutely are correct that not everything was incorporated & cleaned= -up yet.

> Keep it as it is (not obsolete) is certainly one option.

Are=C2=A0 you advocating for this option?

The two 'not obsolete' options path I see are:
(a) WG advocates parallel IETF notification subscription mechanisms for NET= CONF: 5277 & this newer work.=C2=A0 To me this doesn't seem tenable= .
(b) WG has notification subscription capabilities which are less functional= the datastore subscription capabilities.=C2=A0 (I.e., notifications would = not support capabilities such as multiple subs/transport, modify, delete, c= onfigured sub, OAM messages, alternative non-NETCONF transports, etc.)

The yang-push work was originally going down path (b) until the WG requeste= d that subscription capabilities of RFC 7923 be supported for notifications= .

Eric

> /martin

_______________________________________________
Netconf mailing list
N= etconf@ietf.org
https://www.ietf.org/mailman/listin= fo/netconf
--
Cheers,
Mehmet
--f403045ecf0a9cb6420543162cc8-- From nobody Wed Dec 7 11:20:48 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A04A129566 for ; Wed, 7 Dec 2016 11:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-1dlp-KuTm1 for ; Wed, 7 Dec 2016 11:20:44 -0800 (PST) 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 56269129841 for ; Wed, 7 Dec 2016 11:20:44 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id g23so183661601wme.1 for ; Wed, 07 Dec 2016 11:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TTj3U60uzGj372Sj5ur/qHMdWnSSkZ+eJOSvugot/4w=; b=BvzSRb439rBA8DGfvXuk5UwcKUsSPWlhwVAMB3xvTBZY7U0PQ3BhQB9pIsC9V3jYtd fxrch/++KCN64pZoewR7CdTZsWPR4KsSEaBChLq8o3gM2vBtCrtFju6jcWfBcTjP7N0g XWjSdh/ysseEtb3AfOjHvIXRVmGbZ7v4he5z5rrRMB75RZEb38d60Zs0+svYPbxsWdiX QaEPG7pf2cEERtD41ffWbeI2mMuyuKbER0uPAtqbJCPI/KWwgWlwRqWWsQK8/2Ql/umL X/T/zE9kHrS+3ES11BzpUuCtWwOb+uGMqltvBhy3K873isS8rSQ0JReNXUszWGSSH1/j ri0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TTj3U60uzGj372Sj5ur/qHMdWnSSkZ+eJOSvugot/4w=; b=bwr/epdKZboGKwAcID+uTMVB8K7PrahKYSgDZ2XhPsPjuzr+GA1q6NUhO4N/CVoM+P MNLO1udQdkqXtclLUJo4DK5+bxB0+kKjm6uYGmx8yBK0sSgj8dA45w3hgUuOJk9IP9DV MX/jxHFrsJyjsXDurl6wM9WIBhvcUdPW1O7q0RG/I4RL/vyi1iMV++jXhizsEuhA4mkF xYKhe3+MQjn30GL/aIHYxo2WBeI02bGkHrJaotHrdtC7tOvziyzffLvr2A9HqjDts2Nd H1zfvjRZPIkvfTrqt3S7e3SgA1squBcdACRIpK58nG4x6+qU3ptgaqdFnWMb/hshY8a9 0xyw== X-Gm-Message-State: AKaTC00dpGcrobRlZ3WftHRWJmdjzPUp3T6Z5XyxXMJNmRK2n3Iv1drUviVVbyHsZ1QW4iekt+nt2UQKSZTYug== X-Received: by 10.46.0.102 with SMTP id 99mr29396883lja.15.1481138442765; Wed, 07 Dec 2016 11:20:42 -0800 (PST) MIME-Version: 1.0 References: <20161205.214831.712192266937344872.mbj@tail-f.com> <20161205.223443.1094826795624770286.mbj@tail-f.com> In-Reply-To: From: MehmetErsue Date: Wed, 07 Dec 2016 19:20:32 +0000 Message-ID: To: Andy Bierman Content-Type: multipart/alternative; boundary=001a1142c5ccbe8b2d0543166a00 Archived-At: Cc: Netconf Subject: Re: [Netconf] Still subject to agree on NETCONF ML WAS:Re: review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:20:47 -0000 --001a1142c5ccbe8b2d0543166a00 Content-Type: text/plain; charset=UTF-8 Hi Andy, All, can anybody draft a list of must-have, should-have, and nice-to-have requirements for discussion on the ML? I think writing a draft for this would be an over-kill but I'm flexible. Mehmet On Wed, Dec 7, 2016 at 6:54 PM Andy Bierman wrote: > On Wed, Dec 7, 2016 at 9:38 AM, MehmetErsue wrote: > > All, > > > > The element is changing so old clients cannot > > > get the new version that contains a subscription-id and other > > > fields. > > > > I haven't seen any proposal for doing this on the ML. > > Any discussion result from the notification team meetings is still subject > to agree on NETCONF ML. > Such issues should be raised on the ML, the earlier the better. > > > I think Martin has raised valid concerns that we do not yet agree on the > requirements. > The details of a solution do not matter if people do not agree on the > problem first. > > What are the must-have, should-have, and nice-to-have features that are > missing from RFC 5277? > > E.g., if we agree that is is a terrible burden on the client that 1 > session be used for each subscription, > then multiple subscriptions per session is an important feature. How to > do that is the next step, > not this step. > > > > > Mehmet > > > > > Andy > > > > On Mon, Dec 5, 2016 at 10:35 PM Martin Bjorklund wrote: > > Andy Bierman wrote: > > On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund > > > wrote: > > > > > > > > > Andy Bierman wrote: > > > > > > Hi, > > > > > > > > > > > > I prefer the current solution approach, which is to use > > > > > > 'establish-subscription'. > > > > > > > > > > Can you elaborate on why you prefer two operations instead of one, > > > > > when they do the same thing? > > > > > > > > > > > > > because they don't do the same thing. > > > > The new solution has configured filters, subscription-id, suspend and > > > > cancel operations > > > > > > These are trivial extensions to the current solution. > > > > > > If they are truly different the names should not be so similar. > > > > > > > and should not need streams. > > > > > > What do you mean "should not need streams"? > > > > > > > > > > The streams concept is half-baked and not useful. > > I strongly disagree. The stream concept including replay is very > powerful. > > If you think it should be deprecated and replaced with something else, > I think that requires some careful discussion first. (such as a > description of its problems, and a description of a new solution). > > > We have 1 stream, NETCONF, which MUST contain everything > > No it doesn't. This was dicussed recently. The text says: > > This stream contains all NETCONF XML event notifications supported by > the NETCONF server. > > Note it says "all NETCONF XML event notifications", not "all > [XML] event notifications". > > > and > > MUST be encoded in XML. > > Well, NETCONF is encoded in XML so this should not come as a > surprise... > > > Every other stream is purely ad-hoc and > > proprietary > > Not really. All streams supported can be discovered by any client > (with proper access rights). > > > with no chance at interoperability. > > This is a false statement. We have defined several different streams > that third party clients use w/o any problems. If a stream doesn't > interoperate b/c of its name, some implementation is buggy. > > > > > The old solution can be deprecated and replaced. > > > > > > Sure, if it is broken. But I don't think it is broken in any way. > > > > > > > > > > > The element is changing so old clients cannot > > get the new version that contains a subscription-id and other > > fields. > > I haven't seen any proposal for doing this on the ML. > > > IMO it is simpler and clearer if the new solution is separate. > > Maybe. Anyway, my post was really in reply to Eric's statement that > these new features could not be built on top of what we have and still > be backwards compatible. > > One way of making streams even more useful is to make them > configurable, e.g. instead of creating configurable filters, an idea > is to create a new stream together with a filter, and replay > definition. Being able to do this dynamically would actually be quite > useful. > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > -- > Cheers, > Mehmet > > -- Cheers, Mehmet --001a1142c5ccbe8b2d0543166a00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andy, All,

can anybody draf= t a list of must-have, should-have, and nice-to-have requirements for discu= ssion on the ML?
I think writing a draft for this would be an over= -kill but I'm flexible.

Mehmet

On Wed, Dec 7, 2016 at 6:54 PM= Andy Bierman <andy@yumaworks.com<= /a>> wrote:
On Wed, Dec 7, 2016 at 9:38 AM, MehmetErsue <mersue@gmail.com> wrote:
All,
> > The <nofitication= > element is changing so old clients cannot
>=20 > get the new version that contains a subscription-id and other
>=20 > fields.
>=20

Any discussion result= from the notification team meetings is still subject to agree on NETCONF M= L.
Such issues should= be raised on the ML, the earlier the better.


I think Martin has raised valid concerns that we= do not yet agree on the requirements.
The de= tails of a solution do not matter if people do not agree on the problem fir= st.

What are the must-have, should-have, and nice-to-have featur= es that are missing from RFC 5277?

E.g., if we agree that is is = a terrible burden on the client that 1 session be used for each subscriptio= n,
then multiple subscriptions per session is= an important feature.=C2=A0 How to do that is the next step,
not this step.


=C2=A0
=
Mehmet<= br class=3D"gmail_msg">



Andy
=C2=A0
<= div dir=3D"ltr" class=3D"gmail_msg">

On Mon, Dec 5, 2016 at 10:35 PM Martin Bj= orklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaworks.com> wrote:
> > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Andy Bierman <andy@yumaworks.com> wrote:
> > > > > Hi,
> > > > >
> > > > > I prefer the current solution approach, which is t= o use
> > > > > 'establish-subscription'.
> > > >
> > > > Can you elaborate on why you prefer two operations inst= ead of one,
> > > > when they do the same thing?
> > > >
> > >
> > > because they don't do the same thing.
> > > The new solution has configured filters, subscription-id, su= spend and
> > > cancel operations
> >
> > These are trivial extensions to the current solution.
> >
> > If they are truly different the names should not be so similar. > >
> > > and should not need streams.
> >
> > What do you mean "should not need streams"?
> >
> >
>
> The streams concept is half-baked and not useful.

powerful.

I think that requires some careful discussion first.=C2=A0 (such as a
description of its problems, and a description of a new solution).



=C2=A0 =C2=A0the NETCONF server.


> MUST be encoded in XML.

surprise...

> proprietary

(with proper access rights).


that third party clients use w/o any problems.=C2=A0 If a stream doesn'= t
interoperate b/c of its name, some implementation is buggy.

> >
> > Sure, if it is broken.=C2=A0 But I don't think it is broken i= n any way.
> >
> >
> >
> The <nofitication> element is changing so old clients cannot
> get the new version that contains a subscription-id and other
> fields.



these new features could not be built on top of what we have and still
be backwards compatible.

configurable, e.g. instead of creating configurable filters, an idea
is to create a new stream together with a filter, and replay
definition.=C2=A0 Being able to do this dynamically would actually be quite=


Netconf mailing list
Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf
=
--
Cheers,
Mehmet
--
Cheers,
Mehmet
--001a1142c5ccbe8b2d0543166a00-- From nobody Wed Dec 7 11:37:01 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAFD129A92 for ; Wed, 7 Dec 2016 11:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iQQJBhqQL9u for ; Wed, 7 Dec 2016 11:36:56 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1379129A74 for ; Wed, 7 Dec 2016 11:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28094; q=dns/txt; s=iport; t=1481139412; x=1482349012; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FXD7X7rurNN4z91mgPYp2Lb8P3weYqEgJx/fbEQfvlI=; b=G3T7d82qvkM5KfDIftyVlHa5vfyyb0RJM7/uZAsqXhBJ/0OTnzJ9NtEE Gu2OE6fXdz2avSKGFZGc8ibca1WuBRraHwW9oRVqQ6nFw1rvVdISJU+MD 9PfNA4z9x29OtW2RZG3I99okOVV6xCZzPUs7ks1V9famrFqQYwSEk0F/d k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQCKY0hY/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnNGAQEBAQEfWoEGB41ClxCHdI0LggceAQyFLUoCGoFhPxQBAgE?= =?us-ascii?q?BAQEBAQFiKIRoAQEBAgEBAQEhCkEJAgULAgEIFQMNFgQDAgICHwYLFBECBAENB?= =?us-ascii?q?QgTiDoDDwgOqDuCKYc/DYNpAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGPoRbgki?= =?us-ascii?q?BakyCToI/HgWOf4V+hTU1AY04g1mQSYlQhDWEDQEfN4EZI4NtgUVyAYZiKYEHg?= =?us-ascii?q?Q0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,315,1477958400"; d="scan'208,217";a="178830908" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2016 19:36:51 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uB7JaoBr031677 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Dec 2016 19:36:51 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Dec 2016 14:36:50 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 7 Dec 2016 14:36:50 -0500 From: "Eric Voit (evoit)" To: MehmetErsue , Andy Bierman Thread-Topic: [Netconf] Still subject to agree on NETCONF ML WAS:Re: review of "event-notification" documents Thread-Index: AQHSUMFBTXI9Na9wT0mLPFVxc549Dw== Date: Wed, 7 Dec 2016 19:36:50 +0000 Message-ID: References: <20161205.214831.712192266937344872.mbj@tail-f.com> <20161205.223443.1094826795624770286.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_c9c84156dc9e44298549c6245bf2fad7XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: Re: [Netconf] Still subject to agree on NETCONF ML WAS:Re: review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:36:59 -0000 --_000_c9c84156dc9e44298549c6245bf2fad7XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5jcmVtZW50YWwgZnVuY3Rpb25hbGl0eSB3ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBzaW5jZSBJ RVRGIDk0LCA5NSwgOTYsIDk3IGluY2x1ZGU6DQoNCi0gY29uZmlndXJlZCBzdWJzY3JpcHRpb25z DQoNCi0gbWFueSBzdWJzY3JpcHRpb25zIHBlciB0cmFuc3BvcnQNCg0KLSBtb2RpZnkgYW5kIGRl bGV0ZSBzdWJzY3JpcHRpb25zDQoNCi0gY29udHJvbCBwbGFuZSBub3RpZmljYXRpb25zDQoNCi0g UmVzdGNvbmYgJiBIVFRQIHN1cHBvcnQNCg0KLSBEYXRhIHBsYW4gbm90aWZpY2F0aW9uIGluY2x1 ZGluZyBzdWJzY3JpcHRpb24taWQNCg0KDQoNCkV4aXN0aW5nIGRvY3VtZW50YXRpb24gZGV0YWls aW5nIHRoZXNlIHJlcXVpcmVtZW50cyBjYW4gYmUgc2VlbiBpbiBwbGFjZXMgbGlrZToNCg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUvc2xpZGVzL3NsaWRlcy05NS1uZXRjb25m LTcucGRmICAgU2xpZGUgNQ0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9z bGlkZXMvc2xpZGVzLTk2LW5ldGNvbmYtNS5wZGYgICBTbGlkZXMgNSwgMjgNCg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05Ny1uZXRjb25mLWRyYWZ0 LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMDEucGRmICBTbGlkZXMgMjAgJiAyMQ0KDQpJMlJTJ3Mg UkZDLTc5MjMgd2hpY2ggZHJvdmUgdGhlIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGZvciB5YW5n IHN1YnNjcmlwdGlvbnMgaXMgd2hhdCB3YXMgcmVxdWVzdGVkIGJ5IHRoZSBXRyB0byBiZSBtYWRl IGF2YWlsYWJsZSBmb3IgZXZlbnQgbm90aWZpY2F0aW9ucy4NCg0KYXMgd2VsbCBhcyB2YXJpb3Vz IFdHIG1lZXRpbmcgbWludXRlcy4NCg0KDQoNCkJhc2VkIG9uIHRoaXMsIHRoZSBhZ2dyZWdhdGUg c2V0IG9mIHJlcXVpcmVtZW50cyBhcmUgc3VmZmljaWVudC4gIElmIHNvbWVvbmUgd2FudHMgdG8g cHJvcG9zZSBhIHJldmlzaW9uIHRvIHRoZSByZXF1aXJlbWVudHMsIHRoZXkgY2FuIHByb3Bvc2Ug ZGVsdGFzIGZyb20gdGhlIGV4aXN0aW5nIGRvY3VtZW50YXRpb24uICBJIHdvdWxkIGJlIHF1aXRl IGhhcHB5IHRvIGNvbW1lbnQuDQoNCg0KDQpFcmljDQoNCkZyb206IE5ldGNvbmYsIERlY2VtYmVy IDcsIDIwMTYgMjoyMSBQTQ0KDQpIaSBBbmR5LCBBbGwsDQpjYW4gYW55Ym9keSBkcmFmdCBhIGxp c3Qgb2YgbXVzdC1oYXZlLCBzaG91bGQtaGF2ZSwgYW5kIG5pY2UtdG8taGF2ZSByZXF1aXJlbWVu dHMgZm9yIGRpc2N1c3Npb24gb24gdGhlIE1MPw0KSSB0aGluayB3cml0aW5nIGEgZHJhZnQgZm9y IHRoaXMgd291bGQgYmUgYW4gb3Zlci1raWxsIGJ1dCBJJ20gZmxleGlibGUuDQpNZWhtZXQNCg0K DQpPbiBXZWQsIERlYyA3LCAyMDE2IGF0IDY6NTQgUE0gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3 b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KT24gV2VkLCBEZWMg NywgMjAxNiBhdCA5OjM4IEFNLCBNZWhtZXRFcnN1ZSA8bWVyc3VlQGdtYWlsLmNvbTxtYWlsdG86 bWVyc3VlQGdtYWlsLmNvbT4+IHdyb3RlOg0KQWxsLA0KDQo+ID4gVGhlIDxub2ZpdGljYXRpb24+ IGVsZW1lbnQgaXMgY2hhbmdpbmcgc28gb2xkIGNsaWVudHMgY2Fubm90DQo+ID4gZ2V0IHRoZSBu ZXcgdmVyc2lvbiB0aGF0IGNvbnRhaW5zIGEgc3Vic2NyaXB0aW9uLWlkIGFuZCBvdGhlcg0KPiA+ IGZpZWxkcy4NCj4NCj4gSSBoYXZlbid0IHNlZW4gYW55IHByb3Bvc2FsIGZvciBkb2luZyB0aGlz IG9uIHRoZSBNTC4NCkFueSBkaXNjdXNzaW9uIHJlc3VsdCBmcm9tIHRoZSBub3RpZmljYXRpb24g dGVhbSBtZWV0aW5ncyBpcyBzdGlsbCBzdWJqZWN0IHRvIGFncmVlIG9uIE5FVENPTkYgTUwuDQpT dWNoIGlzc3VlcyBzaG91bGQgYmUgcmFpc2VkIG9uIHRoZSBNTCwgdGhlIGVhcmxpZXIgdGhlIGJl dHRlci4NCg0KSSB0aGluayBNYXJ0aW4gaGFzIHJhaXNlZCB2YWxpZCBjb25jZXJucyB0aGF0IHdl IGRvIG5vdCB5ZXQgYWdyZWUgb24gdGhlIHJlcXVpcmVtZW50cy4NClRoZSBkZXRhaWxzIG9mIGEg c29sdXRpb24gZG8gbm90IG1hdHRlciBpZiBwZW9wbGUgZG8gbm90IGFncmVlIG9uIHRoZSBwcm9i bGVtIGZpcnN0Lg0KDQpXaGF0IGFyZSB0aGUgbXVzdC1oYXZlLCBzaG91bGQtaGF2ZSwgYW5kIG5p Y2UtdG8taGF2ZSBmZWF0dXJlcyB0aGF0IGFyZSBtaXNzaW5nIGZyb20gUkZDIDUyNzc/DQoNCkUu Zy4sIGlmIHdlIGFncmVlIHRoYXQgaXMgaXMgYSB0ZXJyaWJsZSBidXJkZW4gb24gdGhlIGNsaWVu dCB0aGF0IDEgc2Vzc2lvbiBiZSB1c2VkIGZvciBlYWNoIHN1YnNjcmlwdGlvbiwNCnRoZW4gbXVs dGlwbGUgc3Vic2NyaXB0aW9ucyBwZXIgc2Vzc2lvbiBpcyBhbiBpbXBvcnRhbnQgZmVhdHVyZS4g IEhvdyB0byBkbyB0aGF0IGlzIHRoZSBuZXh0IHN0ZXAsDQpub3QgdGhpcyBzdGVwLg0KDQoNCg0K TWVobWV0DQoNCg0KDQpBbmR5DQoNCg0KT24gTW9uLCBEZWMgNSwgMjAxNiBhdCAxMDozNSBQTSBN YXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiB3 cm90ZToNCkFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3 b3Jrcy5jb20+PiB3cm90ZToNCj4gT24gTW9uLCBEZWMgNSwgMjAxNiBhdCAxMjo0OCBQTSwgTWFy dGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4gd3Jv dGU6DQo+DQo+ID4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlA eXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KPiA+ID4gT24gTW9uLCBEZWMgNSwgMjAxNiBhdCAxMjoz NyBQTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYu Y29tPj4NCj4gPiB3cm90ZToNCj4gPiA+DQo+ID4gPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1h d29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PiB3cm90ZToNCj4gPiA+ID4gPiBI aSwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgcHJlZmVyIHRoZSBjdXJyZW50IHNvbHV0aW9uIGFw cHJvYWNoLCB3aGljaCBpcyB0byB1c2UNCj4gPiA+ID4gPiAnZXN0YWJsaXNoLXN1YnNjcmlwdGlv bicuDQo+ID4gPiA+DQo+ID4gPiA+IENhbiB5b3UgZWxhYm9yYXRlIG9uIHdoeSB5b3UgcHJlZmVy IHR3byBvcGVyYXRpb25zIGluc3RlYWQgb2Ygb25lLA0KPiA+ID4gPiB3aGVuIHRoZXkgZG8gdGhl IHNhbWUgdGhpbmc/DQo+ID4gPiA+DQo+ID4gPg0KPiA+ID4gYmVjYXVzZSB0aGV5IGRvbid0IGRv IHRoZSBzYW1lIHRoaW5nLg0KPiA+ID4gVGhlIG5ldyBzb2x1dGlvbiBoYXMgY29uZmlndXJlZCBm aWx0ZXJzLCBzdWJzY3JpcHRpb24taWQsIHN1c3BlbmQgYW5kDQo+ID4gPiBjYW5jZWwgb3BlcmF0 aW9ucw0KPiA+DQo+ID4gVGhlc2UgYXJlIHRyaXZpYWwgZXh0ZW5zaW9ucyB0byB0aGUgY3VycmVu dCBzb2x1dGlvbi4NCj4gPg0KPiA+IElmIHRoZXkgYXJlIHRydWx5IGRpZmZlcmVudCB0aGUgbmFt ZXMgc2hvdWxkIG5vdCBiZSBzbyBzaW1pbGFyLg0KPiA+DQo+ID4gPiBhbmQgc2hvdWxkIG5vdCBu ZWVkIHN0cmVhbXMuDQo+ID4NCj4gPiBXaGF0IGRvIHlvdSBtZWFuICJzaG91bGQgbm90IG5lZWQg c3RyZWFtcyI/DQo+ID4NCj4gPg0KPg0KPiBUaGUgc3RyZWFtcyBjb25jZXB0IGlzIGhhbGYtYmFr ZWQgYW5kIG5vdCB1c2VmdWwuDQoNCkkgc3Ryb25nbHkgZGlzYWdyZWUuICBUaGUgc3RyZWFtIGNv bmNlcHQgaW5jbHVkaW5nIHJlcGxheSBpcyB2ZXJ5DQpwb3dlcmZ1bC4NCg0KSWYgeW91IHRoaW5r IGl0IHNob3VsZCBiZSBkZXByZWNhdGVkIGFuZCByZXBsYWNlZCB3aXRoIHNvbWV0aGluZyBlbHNl LA0KSSB0aGluayB0aGF0IHJlcXVpcmVzIHNvbWUgY2FyZWZ1bCBkaXNjdXNzaW9uIGZpcnN0LiAg KHN1Y2ggYXMgYQ0KZGVzY3JpcHRpb24gb2YgaXRzIHByb2JsZW1zLCBhbmQgYSBkZXNjcmlwdGlv biBvZiBhIG5ldyBzb2x1dGlvbikuDQoNCj4gV2UgaGF2ZSAxIHN0cmVhbSwgTkVUQ09ORiwgd2hp Y2ggTVVTVCBjb250YWluIGV2ZXJ5dGhpbmcNCg0KTm8gaXQgZG9lc24ndC4gIFRoaXMgd2FzIGRp Y3Vzc2VkIHJlY2VudGx5LiAgVGhlIHRleHQgc2F5czoNCg0KICAgVGhpcyBzdHJlYW0gY29udGFp bnMgYWxsIE5FVENPTkYgWE1MIGV2ZW50IG5vdGlmaWNhdGlvbnMgc3VwcG9ydGVkIGJ5DQogICB0 aGUgTkVUQ09ORiBzZXJ2ZXIuDQoNCk5vdGUgaXQgc2F5cyAiYWxsIE5FVENPTkYgWE1MIGV2ZW50 IG5vdGlmaWNhdGlvbnMiLCBub3QgImFsbA0KW1hNTF0gZXZlbnQgbm90aWZpY2F0aW9ucyIuDQoN Cj4gYW5kDQo+IE1VU1QgYmUgZW5jb2RlZCBpbiBYTUwuDQoNCldlbGwsIE5FVENPTkYgaXMgZW5j b2RlZCBpbiBYTUwgc28gdGhpcyBzaG91bGQgbm90IGNvbWUgYXMgYQ0Kc3VycHJpc2UuLi4NCg0K PiBFdmVyeSBvdGhlciBzdHJlYW0gaXMgcHVyZWx5IGFkLWhvYyBhbmQNCj4gcHJvcHJpZXRhcnkN Cg0KTm90IHJlYWxseS4gIEFsbCBzdHJlYW1zIHN1cHBvcnRlZCBjYW4gYmUgZGlzY292ZXJlZCBi eSBhbnkgY2xpZW50DQood2l0aCBwcm9wZXIgYWNjZXNzIHJpZ2h0cykuDQoNCj4gd2l0aCBubyBj aGFuY2UgYXQgaW50ZXJvcGVyYWJpbGl0eS4NCg0KVGhpcyBpcyBhIGZhbHNlIHN0YXRlbWVudC4g IFdlIGhhdmUgZGVmaW5lZCBzZXZlcmFsIGRpZmZlcmVudCBzdHJlYW1zDQp0aGF0IHRoaXJkIHBh cnR5IGNsaWVudHMgdXNlIHcvbyBhbnkgcHJvYmxlbXMuICBJZiBhIHN0cmVhbSBkb2Vzbid0DQpp bnRlcm9wZXJhdGUgYi9jIG9mIGl0cyBuYW1lLCBzb21lIGltcGxlbWVudGF0aW9uIGlzIGJ1Z2d5 Lg0KDQo+ID4gPiBUaGUgb2xkIHNvbHV0aW9uIGNhbiBiZSBkZXByZWNhdGVkIGFuZCByZXBsYWNl ZC4NCj4gPg0KPiA+IFN1cmUsIGlmIGl0IGlzIGJyb2tlbi4gIEJ1dCBJIGRvbid0IHRoaW5rIGl0 IGlzIGJyb2tlbiBpbiBhbnkgd2F5Lg0KPiA+DQo+ID4NCj4gPg0KPiBUaGUgPG5vZml0aWNhdGlv bj4gZWxlbWVudCBpcyBjaGFuZ2luZyBzbyBvbGQgY2xpZW50cyBjYW5ub3QNCj4gZ2V0IHRoZSBu ZXcgdmVyc2lvbiB0aGF0IGNvbnRhaW5zIGEgc3Vic2NyaXB0aW9uLWlkIGFuZCBvdGhlcg0KPiBm aWVsZHMuDQoNCkkgaGF2ZW4ndCBzZWVuIGFueSBwcm9wb3NhbCBmb3IgZG9pbmcgdGhpcyBvbiB0 aGUgTUwuDQoNCj4gSU1PIGl0IGlzIHNpbXBsZXIgYW5kIGNsZWFyZXIgaWYgdGhlIG5ldyBzb2x1 dGlvbiBpcyBzZXBhcmF0ZS4NCg0KTWF5YmUuICBBbnl3YXksIG15IHBvc3Qgd2FzIHJlYWxseSBp biByZXBseSB0byBFcmljJ3Mgc3RhdGVtZW50IHRoYXQNCnRoZXNlIG5ldyBmZWF0dXJlcyBjb3Vs ZCBub3QgYmUgYnVpbHQgb24gdG9wIG9mIHdoYXQgd2UgaGF2ZSBhbmQgc3RpbGwNCmJlIGJhY2t3 YXJkcyBjb21wYXRpYmxlLg0KDQpPbmUgd2F5IG9mIG1ha2luZyBzdHJlYW1zIGV2ZW4gbW9yZSB1 c2VmdWwgaXMgdG8gbWFrZSB0aGVtDQpjb25maWd1cmFibGUsIGUuZy4gaW5zdGVhZCBvZiBjcmVh dGluZyBjb25maWd1cmFibGUgZmlsdGVycywgYW4gaWRlYQ0KaXMgdG8gY3JlYXRlIGEgbmV3IHN0 cmVhbSB0b2dldGhlciB3aXRoIGEgZmlsdGVyLCBhbmQgcmVwbGF5DQpkZWZpbml0aW9uLiAgQmVp bmcgYWJsZSB0byBkbyB0aGlzIGR5bmFtaWNhbGx5IHdvdWxkIGFjdHVhbGx5IGJlIHF1aXRlDQp1 c2VmdWwuDQoNCg0KL21hcnRpbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFp bHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmYNCi0tDQpDaGVlcnMsDQpNZWhtZXQNCi0tDQpDaGVlcnMsDQpNZWhtZXQNCg== --_000_c9c84156dc9e44298549c6245bf2fad7XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5nbWFpbG1zZw0KCXttc28tc3R5bGUtbmFtZTpnbWFp bF9tc2c7fQ0Kc3Bhbi5tLTYwNjg0NTY4OTM2MDI2NTY1MzZob2VuemINCgl7bXNvLXN0eWxlLW5h bWU6bV8tNjA2ODQ1Njg5MzYwMjY1NjUzNmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluY3JlbWVudGFsIGZ1bmN0aW9uYWxpdHkgd2Ug aGF2ZSBiZWVuIGRpc2N1c3Npbmcgc2luY2UgSUVURiA5NCwgOTUsIDk2LCA5NyBpbmNsdWRlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LSBjb25maWd1cmVkIHN1YnNj cmlwdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0gbWFueSBz dWJzY3JpcHRpb25zIHBlciB0cmFuc3BvcnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPi0gbW9kaWZ5IGFuZCBkZWxldGUgc3Vic2NyaXB0aW9uczxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LSBjb250cm9sIHBsYW5lIG5vdGlmaWNhdGlvbnM8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0gUmVzdGNvbmYgJmFtcDsg SFRUUCBzdXBwb3J0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tIERh dGEgcGxhbiBub3RpZmljYXRpb24gaW5jbHVkaW5nIHN1YnNjcmlwdGlvbi1pZDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5FeGlzdGluZyBkb2N1bWVudGF0aW9uIGRldGFpbGluZyB0aGVz ZSByZXF1aXJlbWVudHMgY2FuIGJlIHNlZW4gaW4gcGxhY2VzIGxpa2U6Jm5ic3A7DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL3Byb2NlZWRpbmdzLzk1L3NsaWRlcy9zbGlkZXMtOTUtbmV0Y29uZi03LnBkZiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUvc2xpZGVzL3NsaWRlcy05NS1uZXRjb25m LTcucGRmPC9hPiZuYnNwOyZuYnNwOyBTbGlkZSA1PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 Ni9zbGlkZXMvc2xpZGVzLTk2LW5ldGNvbmYtNS5wZGYiPmh0dHBzOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtbmV0Y29uZi01LnBkZjwvYT4mbmJzcDsmbmJz cDsgU2xpZGVzIDUsIDI4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVz LTk3LW5ldGNvbmYtZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0wMS5wZGYiPmh0dHBzOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L3NsaWRlcy9zbGlkZXMtOTctbmV0Y29uZi1kcmFm dC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTAxLnBkZjwvYT4gJm5ic3A7U2xpZGVzIDIwICZhbXA7 IDIxPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JMlJTJ3MgUkZDLTc5 MjMgd2hpY2ggZHJvdmUgdGhlIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGZvciB5YW5nIHN1YnNj cmlwdGlvbnMgaXMgd2hhdCB3YXMgcmVxdWVzdGVkIGJ5IHRoZSBXRyB0byBiZSBtYWRlIGF2YWls YWJsZSBmb3IgZXZlbnQgbm90aWZpY2F0aW9ucy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+YXMgd2VsbCBhcyB2YXJpb3VzIFdHIG1lZXRpbmcgbWludXRl cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QmFzZWQgb24gdGhpcywgdGhlIGFnZ3Jl Z2F0ZSBzZXQgb2YgcmVxdWlyZW1lbnRzIGFyZSBzdWZmaWNpZW50LiZuYnNwOyBJZiBzb21lb25l IHdhbnRzIHRvIHByb3Bvc2UgYSByZXZpc2lvbiB0byB0aGUgcmVxdWlyZW1lbnRzLCB0aGV5IGNh biBwcm9wb3NlIGRlbHRhcyBmcm9tIHRoZSBleGlzdGluZyBkb2N1bWVudGF0aW9uLiZuYnNwOyBJ IHdvdWxkIGJlIHF1aXRlIGhhcHB5IHRvIGNvbW1lbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkVyaWM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IE5ldGNvbmYsIERlY2VtYmVyIDcsIDIwMTYgMjoyMSBQTTxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5IaSBBbmR5LCBBbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmNhbiBhbnlib2R5IGRyYWZ0IGEgbGlzdCBvZiBtdXN0LWhhdmUsIHNob3VsZC1o YXZlLCBhbmQgbmljZS10by1oYXZlIHJlcXVpcmVtZW50cyBmb3IgZGlzY3Vzc2lvbiBvbiB0aGUg TUw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+SSB0aGluayB3cml0aW5nIGEgZHJhZnQgZm9yIHRoaXMgd291 bGQgYmUgYW4gb3Zlci1raWxsIGJ1dCBJJ20gZmxleGlibGUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1laG1ldDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIERlYyA3LCAyMDE2IGF0IDY6NTQgUE0gQW5k eSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1 bWF3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwg RGVjIDcsIDIwMTYgYXQgOTozOCBBTSwgTWVobWV0RXJzdWUgPHNwYW4gY2xhc3M9ImdtYWlsbXNn Ij4NCiZsdDs8YSBocmVmPSJtYWlsdG86bWVyc3VlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1lcnN1ZUBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbGwsPGJyPg0KPGJyPg0KJmd0OyAmZ3Q7IFRoZSAm bHQ7bm9maXRpY2F0aW9uJmd0OyBlbGVtZW50IGlzIGNoYW5naW5nIHNvIG9sZCBjbGllbnRzIGNh bm5vdDxicj4NCiZndDsgJmd0OyBnZXQgdGhlIG5ldyB2ZXJzaW9uIHRoYXQgY29udGFpbnMgYSBz dWJzY3JpcHRpb24taWQgYW5kIG90aGVyPGJyPg0KJmd0OyAmZ3Q7IGZpZWxkcy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgSSBoYXZlbid0IHNlZW4gYW55IHByb3Bvc2FsIGZvciBkb2luZyB0aGlzIG9u IHRoZSBNTC4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFu eSBkaXNjdXNzaW9uIHJlc3VsdCBmcm9tIHRoZSBub3RpZmljYXRpb24gdGVhbSBtZWV0aW5ncyBp cyBzdGlsbCBzdWJqZWN0IHRvIGFncmVlIG9uIE5FVENPTkYgTUwuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPlN1Y2ggaXNzdWVzIHNob3VsZCBiZSByYWlzZWQgb24gdGhlIE1MLCB0aGUgZWFybGll ciB0aGUgYmV0dGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgTWFydGluIGhhcyByYWlzZWQgdmFsaWQgY29u Y2VybnMgdGhhdCB3ZSBkbyBub3QgeWV0IGFncmVlIG9uIHRoZSByZXF1aXJlbWVudHMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZGV0YWls cyBvZiBhIHNvbHV0aW9uIGRvIG5vdCBtYXR0ZXIgaWYgcGVvcGxlIGRvIG5vdCBhZ3JlZSBvbiB0 aGUgcHJvYmxlbSBmaXJzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V2hhdCBhcmUgdGhlIG11c3QtaGF2ZSwgc2hvdWxkLWhhdmUsIGFuZCBu aWNlLXRvLWhhdmUgZmVhdHVyZXMgdGhhdCBhcmUgbWlzc2luZyBmcm9tIFJGQyA1Mjc3PzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FLmcuLCBp ZiB3ZSBhZ3JlZSB0aGF0IGlzIGlzIGEgdGVycmlibGUgYnVyZGVuIG9uIHRoZSBjbGllbnQgdGhh dCAxIHNlc3Npb24gYmUgdXNlZCBmb3IgZWFjaCBzdWJzY3JpcHRpb24sPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGVuIG11bHRpcGxlIHN1YnNj cmlwdGlvbnMgcGVyIHNlc3Npb24gaXMgYW4gaW1wb3J0YW50IGZlYXR1cmUuJm5ic3A7IEhvdyB0 byBkbyB0aGF0IGlzIHRoZSBuZXh0IHN0ZXAsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ub3QgdGhpcyBzdGVwLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1laG1l dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBEZWMgNSwgMjAxNiBh dCAxMDozNSBQTSBNYXJ0aW4gQmpvcmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwt Zi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5k eSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIiB0YXJnZXQ9 Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBPbiBN b24sIERlYyA1LCAyMDE2IGF0IDEyOjQ4IFBNLCBNYXJ0aW4gQmpvcmtsdW5kICZsdDs8YSBocmVm PSJtYWlsdG86bWJqQHRhaWwtZi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYmpAdGFpbC1mLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgQW5keSBCaWVybWFuICZsdDs8 YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5 dW1hd29ya3MuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgT24gTW9uLCBE ZWMgNSwgMjAxNiBhdCAxMjozNyBQTSwgTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1iakB0YWlsLWYuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWJqQHRhaWwtZi5jb208L2E+Jmd0 Ozxicj4NCiZndDsgJmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29y a3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDsgd3JvdGU6 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhpLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBJIHByZWZlciB0aGUgY3VycmVu dCBzb2x1dGlvbiBhcHByb2FjaCwgd2hpY2ggaXMgdG8gdXNlPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICdlc3RhYmxpc2gtc3Vic2NyaXB0aW9uJy48YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDYW4geW91IGVsYWJvcmF0ZSBvbiB3aHkgeW91 IHByZWZlciB0d28gb3BlcmF0aW9ucyBpbnN0ZWFkIG9mIG9uZSw8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IHdoZW4gdGhleSBkbyB0aGUgc2FtZSB0aGluZz88YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBiZWNhdXNlIHRoZXkg ZG9uJ3QgZG8gdGhlIHNhbWUgdGhpbmcuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIG5ldyBzb2x1 dGlvbiBoYXMgY29uZmlndXJlZCBmaWx0ZXJzLCBzdWJzY3JpcHRpb24taWQsIHN1c3BlbmQgYW5k PGJyPg0KJmd0OyAmZ3Q7ICZndDsgY2FuY2VsIG9wZXJhdGlvbnM8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgVGhlc2UgYXJlIHRyaXZpYWwgZXh0ZW5zaW9ucyB0byB0aGUgY3VycmVudCBz b2x1dGlvbi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYgdGhleSBhcmUgdHJ1bHkg ZGlmZmVyZW50IHRoZSBuYW1lcyBzaG91bGQgbm90IGJlIHNvIHNpbWlsYXIuPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgYW5kIHNob3VsZCBub3QgbmVlZCBzdHJlYW1zLjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBXaGF0IGRvIHlvdSBtZWFuICZxdW90O3Nob3VsZCBu b3QgbmVlZCBzdHJlYW1zJnF1b3Q7Pzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IFRoZSBzdHJlYW1zIGNvbmNlcHQgaXMgaGFsZi1iYWtlZCBhbmQgbm90 IHVzZWZ1bC48YnI+DQo8YnI+DQpJIHN0cm9uZ2x5IGRpc2FncmVlLiZuYnNwOyBUaGUgc3RyZWFt IGNvbmNlcHQgaW5jbHVkaW5nIHJlcGxheSBpcyB2ZXJ5PGJyPg0KcG93ZXJmdWwuPGJyPg0KPGJy Pg0KSWYgeW91IHRoaW5rIGl0IHNob3VsZCBiZSBkZXByZWNhdGVkIGFuZCByZXBsYWNlZCB3aXRo IHNvbWV0aGluZyBlbHNlLDxicj4NCkkgdGhpbmsgdGhhdCByZXF1aXJlcyBzb21lIGNhcmVmdWwg ZGlzY3Vzc2lvbiBmaXJzdC4mbmJzcDsgKHN1Y2ggYXMgYTxicj4NCmRlc2NyaXB0aW9uIG9mIGl0 cyBwcm9ibGVtcywgYW5kIGEgZGVzY3JpcHRpb24gb2YgYSBuZXcgc29sdXRpb24pLjxicj4NCjxi cj4NCiZndDsgV2UgaGF2ZSAxIHN0cmVhbSwgTkVUQ09ORiwgd2hpY2ggTVVTVCBjb250YWluIGV2 ZXJ5dGhpbmc8YnI+DQo8YnI+DQpObyBpdCBkb2Vzbid0LiZuYnNwOyBUaGlzIHdhcyBkaWN1c3Nl ZCByZWNlbnRseS4mbmJzcDsgVGhlIHRleHQgc2F5czo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 VGhpcyBzdHJlYW0gY29udGFpbnMgYWxsIE5FVENPTkYgWE1MIGV2ZW50IG5vdGlmaWNhdGlvbnMg c3VwcG9ydGVkIGJ5PGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBORVRDT05GIHNlcnZlci48YnI+DQo8 YnI+DQpOb3RlIGl0IHNheXMgJnF1b3Q7YWxsIE5FVENPTkYgWE1MIGV2ZW50IG5vdGlmaWNhdGlv bnMmcXVvdDssIG5vdCAmcXVvdDthbGw8YnI+DQpbWE1MXSBldmVudCBub3RpZmljYXRpb25zJnF1 b3Q7Ljxicj4NCjxicj4NCiZndDsgYW5kPGJyPg0KJmd0OyBNVVNUIGJlIGVuY29kZWQgaW4gWE1M Ljxicj4NCjxicj4NCldlbGwsIE5FVENPTkYgaXMgZW5jb2RlZCBpbiBYTUwgc28gdGhpcyBzaG91 bGQgbm90IGNvbWUgYXMgYTxicj4NCnN1cnByaXNlLi4uPGJyPg0KPGJyPg0KJmd0OyBFdmVyeSBv dGhlciBzdHJlYW0gaXMgcHVyZWx5IGFkLWhvYyBhbmQ8YnI+DQomZ3Q7IHByb3ByaWV0YXJ5PGJy Pg0KPGJyPg0KTm90IHJlYWxseS4mbmJzcDsgQWxsIHN0cmVhbXMgc3VwcG9ydGVkIGNhbiBiZSBk aXNjb3ZlcmVkIGJ5IGFueSBjbGllbnQ8YnI+DQood2l0aCBwcm9wZXIgYWNjZXNzIHJpZ2h0cyku PGJyPg0KPGJyPg0KJmd0OyB3aXRoIG5vIGNoYW5jZSBhdCBpbnRlcm9wZXJhYmlsaXR5Ljxicj4N Cjxicj4NClRoaXMgaXMgYSBmYWxzZSBzdGF0ZW1lbnQuJm5ic3A7IFdlIGhhdmUgZGVmaW5lZCBz ZXZlcmFsIGRpZmZlcmVudCBzdHJlYW1zPGJyPg0KdGhhdCB0aGlyZCBwYXJ0eSBjbGllbnRzIHVz ZSB3L28gYW55IHByb2JsZW1zLiZuYnNwOyBJZiBhIHN0cmVhbSBkb2Vzbid0PGJyPg0KaW50ZXJv cGVyYXRlIGIvYyBvZiBpdHMgbmFtZSwgc29tZSBpbXBsZW1lbnRhdGlvbiBpcyBidWdneS48YnI+ DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgb2xkIHNvbHV0aW9uIGNhbiBiZSBkZXByZWNhdGVk IGFuZCByZXBsYWNlZC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgU3VyZSwgaWYgaXQg aXMgYnJva2VuLiZuYnNwOyBCdXQgSSBkb24ndCB0aGluayBpdCBpcyBicm9rZW4gaW4gYW55IHdh eS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 IFRoZSAmbHQ7bm9maXRpY2F0aW9uJmd0OyBlbGVtZW50IGlzIGNoYW5naW5nIHNvIG9sZCBjbGll bnRzIGNhbm5vdDxicj4NCiZndDsgZ2V0IHRoZSBuZXcgdmVyc2lvbiB0aGF0IGNvbnRhaW5zIGEg c3Vic2NyaXB0aW9uLWlkIGFuZCBvdGhlcjxicj4NCiZndDsgZmllbGRzLjxicj4NCjxicj4NCkkg aGF2ZW4ndCBzZWVuIGFueSBwcm9wb3NhbCBmb3IgZG9pbmcgdGhpcyBvbiB0aGUgTUwuPGJyPg0K PGJyPg0KJmd0OyBJTU8gaXQgaXMgc2ltcGxlciBhbmQgY2xlYXJlciBpZiB0aGUgbmV3IHNvbHV0 aW9uIGlzIHNlcGFyYXRlLjxicj4NCjxicj4NCk1heWJlLiZuYnNwOyBBbnl3YXksIG15IHBvc3Qg d2FzIHJlYWxseSBpbiByZXBseSB0byBFcmljJ3Mgc3RhdGVtZW50IHRoYXQ8YnI+DQp0aGVzZSBu ZXcgZmVhdHVyZXMgY291bGQgbm90IGJlIGJ1aWx0IG9uIHRvcCBvZiB3aGF0IHdlIGhhdmUgYW5k IHN0aWxsPGJyPg0KYmUgYmFja3dhcmRzIGNvbXBhdGlibGUuPGJyPg0KPGJyPg0KT25lIHdheSBv ZiBtYWtpbmcgc3RyZWFtcyBldmVuIG1vcmUgdXNlZnVsIGlzIHRvIG1ha2UgdGhlbTxicj4NCmNv bmZpZ3VyYWJsZSwgZS5nLiBpbnN0ZWFkIG9mIGNyZWF0aW5nIGNvbmZpZ3VyYWJsZSBmaWx0ZXJz LCBhbiBpZGVhPGJyPg0KaXMgdG8gY3JlYXRlIGEgbmV3IHN0cmVhbSB0b2dldGhlciB3aXRoIGEg ZmlsdGVyLCBhbmQgcmVwbGF5PGJyPg0KZGVmaW5pdGlvbi4mbmJzcDsgQmVpbmcgYWJsZSB0byBk byB0aGlzIGR5bmFtaWNhbGx5IHdvdWxkIGFjdHVhbGx5IGJlIHF1aXRlPGJyPg0KdXNlZnVsLjxi cj4NCjxicj4NCjxicj4NCi9tYXJ0aW48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5OZXRjb25m QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+TWVo bWV0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1laG1ldDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_c9c84156dc9e44298549c6245bf2fad7XCHRTP013ciscocom_-- From nobody Wed Dec 7 11:56:39 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1E7129AA4 for ; Wed, 7 Dec 2016 11:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86q0ilMUnsdA for ; Wed, 7 Dec 2016 11:56:35 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06511129FB0 for ; Wed, 7 Dec 2016 11:55:34 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id n204so426215257qke.2 for ; Wed, 07 Dec 2016 11:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OSWqjzh7eDHMENj1AipH38CU5j0LJ7tMBnMXGJuBeHE=; b=Nd+YI4582BvefmymSaR7odgdRNuwn3QuCwmGULVLqTK/4NvVqXhgc7y+QNbq/fs1C+ z/EXh78IhvfkoTFfTHBgSlLIRCWw5HpWCog9+lH9uN9isfE4r4c5hUbHyanSZTDI4KHw EtWgQgmdiea71Chls/W+E8i23RNcw71+UKzbEHoy9NaxcAn1xUtuBXn01Bf2R8ZLR4nT 0DelQEYsuq6bD4asYvOyJsRYE6l7zSPAQF4wKJTLqmhh5QrowHkpU+PVM4SpJji/HzS0 gRx+S4ILME0jEbQtHjWiQeMZTI5Kp5B4Ot027C9F8/3uoCGbiqFgvdHPyMXKAsrDJpNB A8/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OSWqjzh7eDHMENj1AipH38CU5j0LJ7tMBnMXGJuBeHE=; b=ZpqU+sKzjpAAQy+h0YBU7avS4rSn/ZVNsUU3zPGWiC+7g+/Ll28r1KjbaEQGhgtL3Y peqXfS2qcuPA4zy9Y86AZ4d7ZCvtWiDxCWnq6oMapgT1Yt1JxcaqkqnsBNFFMl316i03 5BsC8smEj7viDI4WZcYktaw9kflGWjLWIkPYXaMGYauNsb05HK7fzJ0rlk1cYAUu4kwG 9Ji+J7Tnz+QSFpeJQzlb+aYFhPd1Bo4id+6PhJckOzqjhT81Oe+b8LPQGW4AYpzuwpjM Sn4Ml5j2Pv/APFY9ZiGOvLCpVFCYLZYCWw+DRctl7RZY1CHCcDxyjST69PNXwC63gSIs xBlw== X-Gm-Message-State: AKaTC032dlnHdlUEM71WkbuD+mmH5GVm/UCAjegEa1VVNI+82u3l6CBO7JGUqfko9ssDzZHmRPgmK69/k+wL6A== X-Received: by 10.55.133.199 with SMTP id h190mr9707557qkd.302.1481140533189; Wed, 07 Dec 2016 11:55:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Wed, 7 Dec 2016 11:55:32 -0800 (PST) In-Reply-To: References: <20161205.214831.712192266937344872.mbj@tail-f.com> <20161205.223443.1094826795624770286.mbj@tail-f.com> From: Andy Bierman Date: Wed, 7 Dec 2016 11:55:32 -0800 Message-ID: To: MehmetErsue Content-Type: multipart/alternative; boundary=94eb2c07d31857f553054316e7f9 Archived-At: Cc: Netconf Subject: Re: [Netconf] Still subject to agree on NETCONF ML WAS:Re: review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:56:38 -0000 --94eb2c07d31857f553054316e7f9 Content-Type: text/plain; charset=UTF-8 Hi, IMO every feature mentioned so far is the nice-to-have variety. Given that Call-Home is almost done, configured subscriptions are not that important. cancel-subscription is cleaner than dropping the transport connection, but this (and perhaps other) features are patented so IPR applies. I am not a fan of lots of optional-to-implement complexity. If it not widely supported on servers, then client developers don't want it. Andy On Wed, Dec 7, 2016 at 11:20 AM, MehmetErsue wrote: > Hi Andy, All, > > can anybody draft a list of must-have, should-have, and nice-to-have > requirements for discussion on the ML? > I think writing a draft for this would be an over-kill but I'm flexible. > > Mehmet > > > On Wed, Dec 7, 2016 at 6:54 PM Andy Bierman wrote: > >> On Wed, Dec 7, 2016 at 9:38 AM, MehmetErsue wrote: >> >> All, >> >> > > The element is changing so old clients cannot >> > > get the new version that contains a subscription-id and other >> > > fields. >> > >> > I haven't seen any proposal for doing this on the ML. >> >> Any discussion result from the notification team meetings is still >> subject to agree on NETCONF ML. >> Such issues should be raised on the ML, the earlier the better. >> >> >> I think Martin has raised valid concerns that we do not yet agree on the >> requirements. >> The details of a solution do not matter if people do not agree on the >> problem first. >> >> What are the must-have, should-have, and nice-to-have features that are >> missing from RFC 5277? >> >> E.g., if we agree that is is a terrible burden on the client that 1 >> session be used for each subscription, >> then multiple subscriptions per session is an important feature. How to >> do that is the next step, >> not this step. >> >> >> >> >> Mehmet >> >> >> >> >> Andy >> >> >> >> On Mon, Dec 5, 2016 at 10:35 PM Martin Bjorklund wrote: >> >> Andy Bierman wrote: >> > On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund >> wrote: >> > >> > > Andy Bierman wrote: >> > > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund >> > > wrote: >> > > > >> > > > > Andy Bierman wrote: >> > > > > > Hi, >> > > > > > >> > > > > > I prefer the current solution approach, which is to use >> > > > > > 'establish-subscription'. >> > > > > >> > > > > Can you elaborate on why you prefer two operations instead of one, >> > > > > when they do the same thing? >> > > > > >> > > > >> > > > because they don't do the same thing. >> > > > The new solution has configured filters, subscription-id, suspend >> and >> > > > cancel operations >> > > >> > > These are trivial extensions to the current solution. >> > > >> > > If they are truly different the names should not be so similar. >> > > >> > > > and should not need streams. >> > > >> > > What do you mean "should not need streams"? >> > > >> > > >> > >> > The streams concept is half-baked and not useful. >> >> I strongly disagree. The stream concept including replay is very >> powerful. >> >> If you think it should be deprecated and replaced with something else, >> I think that requires some careful discussion first. (such as a >> description of its problems, and a description of a new solution). >> >> > We have 1 stream, NETCONF, which MUST contain everything >> >> No it doesn't. This was dicussed recently. The text says: >> >> This stream contains all NETCONF XML event notifications supported by >> the NETCONF server. >> >> Note it says "all NETCONF XML event notifications", not "all >> [XML] event notifications". >> >> > and >> > MUST be encoded in XML. >> >> Well, NETCONF is encoded in XML so this should not come as a >> surprise... >> >> > Every other stream is purely ad-hoc and >> > proprietary >> >> Not really. All streams supported can be discovered by any client >> (with proper access rights). >> >> > with no chance at interoperability. >> >> This is a false statement. We have defined several different streams >> that third party clients use w/o any problems. If a stream doesn't >> interoperate b/c of its name, some implementation is buggy. >> >> > > > The old solution can be deprecated and replaced. >> > > >> > > Sure, if it is broken. But I don't think it is broken in any way. >> > > >> > > >> > > >> > The element is changing so old clients cannot >> > get the new version that contains a subscription-id and other >> > fields. >> >> I haven't seen any proposal for doing this on the ML. >> >> > IMO it is simpler and clearer if the new solution is separate. >> >> Maybe. Anyway, my post was really in reply to Eric's statement that >> these new features could not be built on top of what we have and still >> be backwards compatible. >> >> One way of making streams even more useful is to make them >> configurable, e.g. instead of creating configurable filters, an idea >> is to create a new stream together with a filter, and replay >> definition. Being able to do this dynamically would actually be quite >> useful. >> >> >> /martin >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> -- >> Cheers, >> Mehmet >> >> -- > Cheers, > Mehmet > --94eb2c07d31857f553054316e7f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

IMO every feature mentioned so far = is the nice-to-have variety.
Given that Call-Home is almost done,= configured subscriptions are not that important.
cancel-subscrip= tion is cleaner than dropping the transport connection, but this (and perha= ps other)
features are patented so IPR applies.

I am not a fan of lots of optional-to-implement complexity.
If it not widely supported on servers, then client developers don= 9;t want it.


Andy


On Wed, = Dec 7, 2016 at 11:20 AM, MehmetErsue <mersue@gmail.com> wrote= :
Hi Andy= , All,

can anybody draft a list of must-have, should-have, and= nice-to-have requirements for discussion on the ML?
I think writi= ng a draft for this would be an over-kill but I'm flexible.

Mehmet


On Wed, Dec 7, 2016 at 6:54 PM Andy Bierman <andy@yumaworks.com> wrote:
=
On Wed, Dec 7, 20= 16 at 9:38 AM, MehmetErsue <mersue@gmail.com> wrote:
All,

> > The <nofitica= tion> element is changing so old clients cannot
>=20 > get the new version that contains a subscription-id and other
>=20 > fields.
>=20
>=20 I haven't seen any proposal for doing this on the ML.

Any discussion result from the notification team meeti= ngs is still subject to agree on NETCONF ML.
Such issu= es should be raised on the ML, the earlier the better.

=

I think Martin has r= aised valid concerns that we do not yet agree on the requirements.
The details of a solution do not= matter if people do not agree on the problem first.

<= /div>
What are the must-have, = should-have, and nice-to-have features that are missing from RFC 5277?

E.g., = if we agree that is is a terrible burden on the client that 1 session be us= ed for each subscription,
then multiple subscriptions per session is an important feature.=C2=A0 Ho= w to do that is the next step,
not this step.

=C2=A0
Mehmet



Andy
=C2=A0

On Mon= , Dec 5, 2016 at 10:35 PM Martin Bjorklund <mbj@tail-f= .com> wrote:
Andy Bierman <<= a href=3D"mailto:andy@yumaworks.com" class=3D"m_6740213903014448371m_-60684= 56893602656536m_5658855994277033756gmail_msg m_6740213903014448371gmail_msg= " target=3D"_blank">andy@yumaworks.com> wrote:
> On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaworks.com> = wrote:
> > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Andy Bierman <andy@yumaworks.co= m> wrote:
> > > > > Hi,
> > > > >
> > > > > I prefer the current solution approach, which is t= o use
> > > > > 'establish-subscription'.
> > > >
> > > > Can you elaborate on why you prefer two operations inst= ead of one,
> > > > when they do the same thing?
> > > >
> > >
> > > because they don't do the same thing.
> > > The new solution has configured filters, subscription-id, su= spend and
> > > cancel operations
> >
> > These are trivial extensions to the current solution.
> >
> > If they are truly different the names should not be so similar. > >
> > > and should not need streams.
> >
> > What do you mean "should not need streams"?
> >
> >
>
> The streams concept is half-baked and not useful.

I strongly disagree.=C2=A0 The stream concept including replay is very
powerful.

If you think it should be deprecated and replaced with something else,
I think that requires some careful discussion first.=C2=A0 (such as a
description of its problems, and a description of a new solution).

> We have 1 stream, NETCONF, which MUST contain everything

No it doesn't.=C2=A0 This was dicussed recently.=C2=A0 The text says:
=C2=A0 =C2=A0This stream contains all NETCONF XML event notifications suppo= rted by
=C2=A0 =C2=A0the NETCONF server.

Note it says "all NETCONF XML event notifications", not "all=
[XML] event notifications".

> and
> MUST be encoded in XML.

Well, NETCONF is encoded in XML so this should not come as a
surprise...

> Every other stream is purely ad-hoc and
> proprietary

Not really.=C2=A0 All streams supported can be discovered by any client
(with proper access rights).

> with no chance at interoperability.

This is a false statement.=C2=A0 We have defined several different streams<= br class=3D"m_6740213903014448371m_-6068456893602656536m_565885599427703375= 6gmail_msg m_6740213903014448371gmail_msg"> that third party clients use w/o any problems.=C2=A0 If a stream doesn'= t
interoperate b/c of its name, some implementation is buggy.

> > > The old solution can be deprecated and replaced.
> >
> > Sure, if it is broken.=C2=A0 But I don't think it is broken i= n any way.
> >
> >
> >
> The <nofitication> element is changing so old clients cannot
> get the new version that contains a subscription-id and other
> fields.

I haven't seen any proposal for doing this on the ML.

> IMO it is simpler and clearer if the new solution is separate.

Maybe.=C2=A0 Anyway, my post was really in reply to Eric's statement th= at
these new features could not be built on top of what we have and still
be backwards compatible.

One way of making streams even more useful is to make them
configurable, e.g. instead of creating configurable filters, an idea
is to create a new stream together with a filter, and replay
definition.=C2=A0 Being able to do this dynamically would actually be quite=
useful.


/martin

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.iet= f.org/mailman/listinfo/netconf
--
=
Cheers,
Mehmet
--
<= /div>
Cheers,<= br>
Mehmet

--94eb2c07d31857f553054316e7f9-- From nobody Wed Dec 7 12:13:03 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2D3129FEF for ; Wed, 7 Dec 2016 12:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D72Sfl4wvNjU for ; Wed, 7 Dec 2016 12:13:00 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CD41296BD for ; Wed, 7 Dec 2016 12:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2640; q=dns/txt; s=iport; t=1481141342; x=1482350942; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4fej/ddFWm8ccrjprMKkrD+11pi/sL+wcCFrZYh6+DU=; b=iHrNFAq905ETNPFe9VUWU/pTCTaekgt+z2HHYQiJUEkuChBHtrG1Xza+ l766ZAq4HDmqqg4yA8L2RtvWI0W9dLyJY3fR+/BwfQtBnq9XhdDo0cJ9V SBL+B1mRGkweHqtY0nCyA5BNoUObcJ3vcngqIHTgtSeFg2bc6tDgLemYQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAgAQa0hY/5hdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR+BZ6RSknCCD4IHhiICGoFhQBMBAgEBAQEBAQFiKIR?= =?us-ascii?q?oAQEBAwEjEUMCBQsCAQgVBQIJHQICAjAVEAIEDg0TiEwIqDyCKYs1AQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHIELhTOEW4Q2gxaCPx4FmmcBkRGBfIR9iVCOBYQNASE?= =?us-ascii?q?DMoEZhVWJBYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,315,1477958400"; d="scan'208";a="183675321" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2016 20:09:01 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uB7K9144010513 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Dec 2016 20:09:01 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Dec 2016 15:09:00 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 7 Dec 2016 15:09:00 -0500 From: "Eric Voit (evoit)" To: MehmetErsue Thread-Topic: [SUSPICIOUS] Re: [Netconf] review of "event-notification" documents Thread-Index: AQHSSbPRFuomS98NjUWN0bJG7+k/sKDu2loggAFQ0QD//9QRMIAJf/IAgACTgoCAABdbgIAABR8AgAABqgCAAAF1gIAAA8aAgAAJI4CAAGlMgIAAbWeA///ZesCAAIKVgP//zRjQACibc4AAAUVx8AAVbgOAAAkusCAAEkhyoA== Date: Wed, 7 Dec 2016 20:09:00 +0000 Message-ID: <5f6fb39d23f84eee8983e00a36d9209f@XCH-RTP-013.cisco.com> References: <20161206155239.GA98983@elstar.local> <20161207.091309.1120006136134788111.mbj@tail-f.com> <2a6331ea7ac54457b8b3cd6f10f12688@XCH-RTP-013.cisco.com> <480bca2314f04eec8eeacadc88561492@XCH-RTP-013.cisco.com> In-Reply-To: <480bca2314f04eec8eeacadc88561492@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] [SUSPICIOUS] Re: review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 20:13:02 -0000 PiBGcm9tOiBNZWhtZXRFcnN1ZSwgRGVjZW1iZXIgNywgMjAxNiAyOjAzIFBNDQo+DQo+ID4gPiBL ZWVwIGl0IGFzIGl0IGlzIChub3Qgb2Jzb2xldGUpIGlzIGNlcnRhaW5seSBvbmUgb3B0aW9uLg0K PiA+DQo+ID4gQXJlwqAgeW91IGFkdm9jYXRpbmcgZm9yIHRoaXMgb3B0aW9uPw0KPiA+DQo+ID4g VGhlIHR3byAnbm90IG9ic29sZXRlJyBvcHRpb25zIHBhdGggSSBzZWUgYXJlOg0KPiA+IChhKSBX RyBhZHZvY2F0ZXMgcGFyYWxsZWwgSUVURiBub3RpZmljYXRpb24gc3Vic2NyaXB0aW9uIG1lY2hh bmlzbXMgZm9yDQo+IE5FVENPTkY6IDUyNzcgJiB0aGlzIG5ld2VyIHdvcmsuwqAgVG8gbWUgdGhp cyBkb2Vzbid0IHNlZW0gdGVuYWJsZS4NCj4gDQo+IENhbiB5b3UgcGxlYXNlIGVsYWJvcmF0ZSB3 aHkgdGhpcyBpcyBub3QgdGVuYWJsZT8NCj4gVGVjaG5pY2FsbHkgc3Bva2VuIEkgdGhpbmsgaXQg aXMgdGhlIGVhc2llc3Qgd2F5IHRvIGVuYWJsZSBjb250aW51aW5nIHRvIHVzZSA1Mjc3DQo+IGFz IGl0IGlzIGFuZCBhdCB0aGUgc2FtZSB0byByZWR1Y2UgdGhlIG5lY2Vzc2FyeSBlZmZvcnQgZm9y IHRoZSBuZXcgc29sdXRpb24uDQoNCkkgY29tcGxldGVseSBhZ3JlZSBwZW9wbGUgc2hvdWxkIGJl IGdvb2QgdG8gdXNlIFJGQy01Mjc3IGRlcGxveW1lbnRzIGFzIGxvbmcgYXMgdGhleSB3YW50LiAg DQoNClRoZSB3b3JkICd1bnRlbmFibGUnIHJlZmVycyB0byBhbiBJRVRGIHJlY29tbWVuZGVkIGFw cHJvYWNoIGZvciBuZXcgZGVwbG95bWVudHMuICBEb2VzIHRoZSBJRVRGIHJlYWxseSB3YW50IHRv IGFkdm9jYXRlIHR3byBwYXJhbGxlbCBzb2x1dGlvbnMgZm9yIE5FVENPTkYgZXZlbnQgc3Vic2Ny aXB0aW9ucyAoNTI3NyBhbmQgd2hhdCBpcyBjdXJyZW50bHkgNTI3N2Jpcyk/ICAgSSBzdXNwZWN0 IHRoaXMgaXNuJ3QgYWxsb3dlZCwgaGVuY2UgJ29ic29sZXRlJyBhcyBteSBwcmVmZXJlbmNlLiAg IA0KDQo+ID4gKGIpIFdHIGhhcyBub3RpZmljYXRpb24gc3Vic2NyaXB0aW9uIGNhcGFiaWxpdGll cyB3aGljaCBhcmUgbGVzcw0KPiA+IGZ1bmN0aW9uYWwgdGhlIGRhdGFzdG9yZSBzdWJzY3JpcHRp b24gY2FwYWJpbGl0aWVzLsKgIChJLmUuLA0KPiA+IG5vdGlmaWNhdGlvbnMgd291bGQgbm90IHN1 cHBvcnQgY2FwYWJpbGl0aWVzIHN1Y2ggYXMgbXVsdGlwbGUNCj4gPiBzdWJzL3RyYW5zcG9ydCwg bW9kaWZ5LCA+IGRlbGV0ZSwgY29uZmlndXJlZCBzdWIsIE9BTSBtZXNzYWdlcywNCj4gPiBhbHRl cm5hdGl2ZSBub24tTkVUQ09ORiB0cmFuc3BvcnRzLCBldGMuKQ0KPiA+DQo+ID4gVGhlIHlhbmct cHVzaCB3b3JrIHdhcyBvcmlnaW5hbGx5IGdvaW5nIGRvd24gcGF0aCAoYikgdW50aWwgdGhlIFdH DQo+IHJlcXVlc3RlZCB0aGF0IHN1YnNjcmlwdGlvbiBjYXBhYmlsaXRpZXMgb2YgUkZDIDc5MjMg YmUgc3VwcG9ydGVkIGZvcg0KPiBub3RpZmljYXRpb25zLg0KPiBUaGlzIHJlcXVpcmVzIHNvbWUg ZGlzY3Vzc2lvbiB0byB1bmRlcnN0YW5kIHRoZSBpbXBhY3RzLg0KDQo/ICAgIE1heWJlIEkgYW0g Y29uZnVzZWQuICAgVGhlIE5FVENPTkYgV0cgY2hhbmdlZCBvdXIgZGlyZWN0aW9uIGEgY291cGxl IElFVEZzIGFnbyBoZXJlLiAgVGhlIHJlcXVlc3Qgd2FzIHRvIHN1cHBvcnQgdGhlIG5ldyBjYXBh YmlsaXRpZXMgd2l0aCBFdmVudCBOb3RpZmljYXRpb25zLiAgQXJlIHlvdSBzdWdnZXN0aW5nIHdl IGNoYW5nZSB0aGF0PyAgICANCg0KVGhlIG9ubHkgcXVlc3Rpb24gb24gdGhlIHRhYmxlIHdoaWNo IEkgYmVsaWV2ZSBuZWVkcyB0byBiZSBhZGRyZXNzZWQgaXMgZW5oYW5jZSB2cyBvYnNvbGV0ZS4g ICBXaGF0IGRyaXZlci9xdWVzdGlvbiBpcyByYWlzaW5nIGEgZ2VuZXJhbCByZXZpc2l0aW5nIG9m IHJlcXVpcmVtZW50cz8NCg0KRXJpYyANCg0KPiBCUiwNCj4gTWVobWV0DQoNCg== From nobody Wed Dec 7 14:42:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2AD129A00 for ; Wed, 7 Dec 2016 14:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxOmbBcb6PCo for ; Wed, 7 Dec 2016 14:42:17 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA0F129C2C for ; Wed, 7 Dec 2016 14:42:17 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id c47so395687252qtc.2 for ; Wed, 07 Dec 2016 14:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k1/9MslOWCtaRjXLP1JaPjXAQHIQcp2ZoISciCAGdL4=; b=PesYqcZ8+qeWPrKs/oi3OWIoqGOX/V32uBo+3Q9IeNRbEP6TlNv5iAQ0LWmg1ptIBJ 0DRYnCVFWRiIs/psf6wGAz9/T2rZOK2EJAbrNZy3AlrS6MCxnkwjLzJEvCCW28FZSwR6 ixvYIDVfrFO9UI7dB2qaoZp5RHSE1Y2LZGhe2OXH/XMJC+C5WgUpGNf/MSQ7+/SZsj8H phz4YGOAIcW7l3Cl9htroADsO1F68c5zTqC2O6m/E9VX5S0cSMTH30pgEV+hiWUjiXEO uLx5HUFLnHFeChwMp99vtAtT91mA4+gT1icKFmZ8/oXrjrs2tQYCAgeOyWGAmlXUEjLW +Diw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k1/9MslOWCtaRjXLP1JaPjXAQHIQcp2ZoISciCAGdL4=; b=g2AI8Sl63zQpoqDIA6KU7UPH1VDpmxP8dZM5yDrYbuQYvXSUfUun2rB5LIu6pSjSDG 8OVfzlONTyXcC+EjN6L41duvU2LL+PvojKQ+DRD08vBYGsRU80L77AMxiGMokyU7C57A 0CJsgNAwPW/XmIZ3BwjDecZnfX/4XFf6RmGoOHmA9k0R1IehkICPlRIJ3ZdEZJYuBjYf RVPwiXXA0hopI5uZPfSPGgy+ILmWYAxgXqKmqaIZ1842BZoe0HvpuuD2iWGLtkJPGDWf Fq6UW4CrAojCMevOaYqjZexUowfOY5GeXYpU/vlM5X4TsHh+mXGIxofmbVq6s39EyJGB UbyA== X-Gm-Message-State: AKaTC02pI3RjLKIj2VqezIE50/5X+ek0NFVtDwIDMiimfPh3z4/RquklGd/UtMs2r/uIeeWhhF5PssgKIUMmUQ== X-Received: by 10.200.47.140 with SMTP id l12mr68715441qta.51.1481150536370; Wed, 07 Dec 2016 14:42:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Wed, 7 Dec 2016 14:42:15 -0800 (PST) In-Reply-To: References: <20161205.214831.712192266937344872.mbj@tail-f.com> <20161205.223443.1094826795624770286.mbj@tail-f.com> From: Andy Bierman Date: Wed, 7 Dec 2016 14:42:15 -0800 Message-ID: To: MehmetErsue Content-Type: multipart/alternative; boundary=001a113572d8945fe70543193b35 Archived-At: Cc: Netconf Subject: Re: [Netconf] Still subject to agree on NETCONF ML WAS:Re: review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 22:42:19 -0000 --001a113572d8945fe70543193b35 Content-Type: text/plain; charset=UTF-8 Hi, The real question is what use-cases do we agree need to be supported which are not currently supported that well. Here are 3, where the 5277 solution may not scale well enough in implementation - notification collector: If subscriptions are provided as a service then multiple subscriptions per session may provide some opportunities for optimization on the collector and the server. e.g., send a notification just once, tagged with all the subscription-ids that are supposed to get this notification - telemetry: need high-performance and efficient use of the network; consider binary encoding and non-secure transports; relying on YANG Push so that draft has to clearly identify lower layer requirements - datastore replication: need reliable delivery and high performance; YANG Push is also the solution for this use-case IMO we will not make progress on solution details without a better understanding of the use-cases. Andy On Wed, Dec 7, 2016 at 11:20 AM, MehmetErsue wrote: > Hi Andy, All, > > can anybody draft a list of must-have, should-have, and nice-to-have > requirements for discussion on the ML? > I think writing a draft for this would be an over-kill but I'm flexible. > > Mehmet > > > On Wed, Dec 7, 2016 at 6:54 PM Andy Bierman wrote: > >> On Wed, Dec 7, 2016 at 9:38 AM, MehmetErsue wrote: >> >> All, >> >> > > The element is changing so old clients cannot >> > > get the new version that contains a subscription-id and other >> > > fields. >> > >> > I haven't seen any proposal for doing this on the ML. >> >> Any discussion result from the notification team meetings is still >> subject to agree on NETCONF ML. >> Such issues should be raised on the ML, the earlier the better. >> >> >> I think Martin has raised valid concerns that we do not yet agree on the >> requirements. >> The details of a solution do not matter if people do not agree on the >> problem first. >> >> What are the must-have, should-have, and nice-to-have features that are >> missing from RFC 5277? >> >> E.g., if we agree that is is a terrible burden on the client that 1 >> session be used for each subscription, >> then multiple subscriptions per session is an important feature. How to >> do that is the next step, >> not this step. >> >> >> >> >> Mehmet >> >> >> >> >> Andy >> >> >> >> On Mon, Dec 5, 2016 at 10:35 PM Martin Bjorklund wrote: >> >> Andy Bierman wrote: >> > On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund >> wrote: >> > >> > > Andy Bierman wrote: >> > > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund >> > > wrote: >> > > > >> > > > > Andy Bierman wrote: >> > > > > > Hi, >> > > > > > >> > > > > > I prefer the current solution approach, which is to use >> > > > > > 'establish-subscription'. >> > > > > >> > > > > Can you elaborate on why you prefer two operations instead of one, >> > > > > when they do the same thing? >> > > > > >> > > > >> > > > because they don't do the same thing. >> > > > The new solution has configured filters, subscription-id, suspend >> and >> > > > cancel operations >> > > >> > > These are trivial extensions to the current solution. >> > > >> > > If they are truly different the names should not be so similar. >> > > >> > > > and should not need streams. >> > > >> > > What do you mean "should not need streams"? >> > > >> > > >> > >> > The streams concept is half-baked and not useful. >> >> I strongly disagree. The stream concept including replay is very >> powerful. >> >> If you think it should be deprecated and replaced with something else, >> I think that requires some careful discussion first. (such as a >> description of its problems, and a description of a new solution). >> >> > We have 1 stream, NETCONF, which MUST contain everything >> >> No it doesn't. This was dicussed recently. The text says: >> >> This stream contains all NETCONF XML event notifications supported by >> the NETCONF server. >> >> Note it says "all NETCONF XML event notifications", not "all >> [XML] event notifications". >> >> > and >> > MUST be encoded in XML. >> >> Well, NETCONF is encoded in XML so this should not come as a >> surprise... >> >> > Every other stream is purely ad-hoc and >> > proprietary >> >> Not really. All streams supported can be discovered by any client >> (with proper access rights). >> >> > with no chance at interoperability. >> >> This is a false statement. We have defined several different streams >> that third party clients use w/o any problems. If a stream doesn't >> interoperate b/c of its name, some implementation is buggy. >> >> > > > The old solution can be deprecated and replaced. >> > > >> > > Sure, if it is broken. But I don't think it is broken in any way. >> > > >> > > >> > > >> > The element is changing so old clients cannot >> > get the new version that contains a subscription-id and other >> > fields. >> >> I haven't seen any proposal for doing this on the ML. >> >> > IMO it is simpler and clearer if the new solution is separate. >> >> Maybe. Anyway, my post was really in reply to Eric's statement that >> these new features could not be built on top of what we have and still >> be backwards compatible. >> >> One way of making streams even more useful is to make them >> configurable, e.g. instead of creating configurable filters, an idea >> is to create a new stream together with a filter, and replay >> definition. Being able to do this dynamically would actually be quite >> useful. >> >> >> /martin >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> -- >> Cheers, >> Mehmet >> >> -- > Cheers, > Mehmet > --001a113572d8945fe70543193b35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


The real question is= what use-cases do we agree need to be supported which
are not cu= rrently supported that well. Here are 3, where the 5277 solution
= may not scale well enough in implementation

=C2=A0= =C2=A0- notification collector: If subscriptions are provided as a service= then multiple subscriptions
=C2=A0 =C2=A0 =C2=A0per session may = provide some opportunities for optimization on the collector and the server= .
=C2=A0 =C2=A0 =C2=A0e.g., send a notification just once, tagged= with all the subscription-ids that are supposed to
=C2=A0 =C2=A0= get this notification

=C2=A0 - telemetry: need hi= gh-performance and efficient use of the network; consider binary encoding
=C2=A0 =C2=A0 and non-secure transports; relying on YANG Push so t= hat draft has to clearly identify lower
=C2=A0 =C2=A0 layer requi= rements

=C2=A0- datastore replication: need reliab= le delivery and high performance; YANG Push is also
=C2=A0 =C2=A0= the solution for this use-case

IMO we will not mak= e progress on solution details without a better understanding of the use-ca= ses.


Andy


On Wed, Dec 7, 2= 016 at 11:20 AM, MehmetErsue <mersue@gmail.com> wrote:
Hi Andy, All,
can anybody draft a list of must-have, should-have, and nice-to= -have requirements for discussion on the ML?
I think writing a dra= ft for this would be an over-kill but I'm flexible.

Mehmet=


On= Wed, Dec 7, 2016 at 6:54 PM Andy Bierman <andy@yumaworks.com> wrote:
On Wed, Dec 7, 2016 at= 9:38 AM, MehmetErsue <mersue@gmail.com> wrote:
All,

> > The <nofi= tication> element is changing so old clients cannot
>=20 > get the new version that contains a subscription-id and other
>=20 > fields.
>=20
>=20 I haven't seen any proposal for doing this on the ML.

Any discussion result from the notification team mee= tings is still subject to agree on NETCONF ML.
Such = issues should be raised on the ML, the earlier the better.

=
I think M= artin has raised valid concerns that we do not yet agree on the requirement= s.
The details of a sol= ution do not matter if people do not agree on the problem first.

What are = the must-have, should-have, and nice-to-have features that are missing from= RFC 5277?

E.g., if we agree that is is a terrible burden on the client th= at 1 session be used for each subscription,
then multiple subscriptions per session is an importan= t feature.=C2=A0 How to do that is the next step,
not this step.


=C2=A0
Mehmet


Andy
=C2=A0

On Mon, Dec 5, 2016 at 10:35 PM Marti= n Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy= @yumaworks.com> wrote:
> On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaworks.com>= ; wrote:
> > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Andy Bierman <andy@yumaworks.= com> wrote:
> > > > > Hi,
> > > > >
> > > > > I prefer the current solution approach, which is t= o use
> > > > > 'establish-subscription'.
> > > >
> > > > Can you elaborate on why you prefer two operations inst= ead of one,
> > > > when they do the same thing?
> > > >
> > >
> > > because they don't do the same thing.
> > > The new solution has configured filters, subscription-id, su= spend and
> > > cancel operations
> >
> > These are trivial extensions to the current solution.
> >
> > If they are truly different the names should not be so similar. > >
> > > and should not need streams.
> >
> > What do you mean "should not need streams"?
> >
> >
>
> The streams concept is half-baked and not useful.

I strongly disagree.=C2=A0 The stream concept including replay is very
powerful.

If you think it should be deprecated and replaced with something else,
I think that requires some careful discussion first.=C2=A0 (such as a
description of its problems, and a description of a new solution).

> We have 1 stream, NETCONF, which MUST contain everything

No it doesn't.=C2=A0 This was dicussed recently.=C2=A0 The text says:
=C2=A0 =C2=A0This stream contains all NETCONF XML event notifications suppo= rted by
=C2=A0 =C2=A0the NETCONF server.

Note it says "all NETCONF XML event notifications", not "all=
[XML] event notifications".

> and
> MUST be encoded in XML.

Well, NETCONF is encoded in XML so this should not come as a
surprise...

> Every other stream is purely ad-hoc and
> proprietary

Not really.=C2=A0 All streams supported can be discovered by any client
(with proper access rights).

> with no chance at interoperability.

This is a false statement.=C2=A0 We have defined several different streams<= br class=3D"m_-7272235856259106593m_-6068456893602656536m_56588559942770337= 56gmail_msg m_-7272235856259106593gmail_msg"> that third party clients use w/o any problems.=C2=A0 If a stream doesn'= t
interoperate b/c of its name, some implementation is buggy.

> > > The old solution can be deprecated and replaced.
> >
> > Sure, if it is broken.=C2=A0 But I don't think it is broken i= n any way.
> >
> >
> >
> The <nofitication> element is changing so old clients cannot
> get the new version that contains a subscription-id and other
> fields.

I haven't seen any proposal for doing this on the ML.

> IMO it is simpler and clearer if the new solution is separate.

Maybe.=C2=A0 Anyway, my post was really in reply to Eric's statement th= at
these new features could not be built on top of what we have and still
be backwards compatible.

One way of making streams even more useful is to make them
configurable, e.g. instead of creating configurable filters, an idea
is to create a new stream together with a filter, and replay
definition.=C2=A0 Being able to do this dynamically would actually be quite=
useful.


/martin

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.i= etf.org/mailman/listinfo/netconf
--
Cheers,
Mehmet
--
<= /div>
Cheers,<= br>
Mehmet

--001a113572d8945fe70543193b35-- From nobody Wed Dec 7 14:47:15 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CEA1295E5 for ; Wed, 7 Dec 2016 14:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK8no7zAxRjM for ; Wed, 7 Dec 2016 14:47:11 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342DC1295C5 for ; Wed, 7 Dec 2016 14:47:11 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id g23so191153608wme.1 for ; Wed, 07 Dec 2016 14:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qjYbUwINgLjxb+5I2A2mNN4fSWG0772IjeyQioCQ5Sk=; b=aMbXr5aEefG0Y6H+Dnt07a8Ucor8rRb35bqYc/73WQnAyiCizRKdX8Jk5Ar/QaCfu9 rswoVucgLWsPsvO9ftF1hTi6TT4x6zOoiLMkx3lxjv01T98UyzsItjz09PqbEAkfSFyM sviYUyirHrPXykSiFl0M7dbYhYxZHdd1eUoQNhR/IEx9v48paE4FEVT/9t4y7S00whVy nEzaRA9cHqXAJOHYN9/QQMoO7QwK4rhb4O6ugzORXL+wxyvoHHBZnZNjbgQgQkh+4Bza r054W+bBWWhgaGVCH1qnQY6B8NK+1AFzK5ofwGkZMB3oiRo8oIoi4j9IsI3+RHlcAXUj z+dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qjYbUwINgLjxb+5I2A2mNN4fSWG0772IjeyQioCQ5Sk=; b=EGwRHNcS0xteGIL/2RlOlO5PAZNXqC5vEzrs5JfwUkriSyql+iuxEJ9RXFNOI8hbhO yvMcA2cI/bgcVDwu0iOPGcDZ2a6K1jUqJVex8EZkvZNLx5YcamtBJRSnawW3MrLwRDRm zKksM1P+Ulx2TAVnmOeBiVhSFA9ExFcRd9wFsGVug5Q7eRNcvIuQ20tN+TAiUt/sv/Iu WIn/oiRKkxDEHuQNohFPGNP6GC91eZkeQ64byL24zIEEm5JzijLkJi1V+j2q3MaTM/83 q4cn02v3l+cvQv1JUaXIaTbft1O5geCPPl7JpLiT1L3UNzmJstNmUuDOiPy43POVQkuk aqOg== X-Gm-Message-State: AKaTC02zUn3fPOJORLwALIT+tazL0FcrxqxLXpQqs+xI/dXwwdKrGl1n2hj76/FoZplyMoczTQZyjI8N+FY5BQ== X-Received: by 10.25.23.221 with SMTP id 90mr25115658lfx.34.1481150829553; Wed, 07 Dec 2016 14:47:09 -0800 (PST) MIME-Version: 1.0 References: <20161206155239.GA98983@elstar.local> <20161207.091309.1120006136134788111.mbj@tail-f.com> <2a6331ea7ac54457b8b3cd6f10f12688@XCH-RTP-013.cisco.com> <480bca2314f04eec8eeacadc88561492@XCH-RTP-013.cisco.com> <5f6fb39d23f84eee8983e00a36d9209f@XCH-RTP-013.cisco.com> In-Reply-To: <5f6fb39d23f84eee8983e00a36d9209f@XCH-RTP-013.cisco.com> From: MehmetErsue Date: Wed, 07 Dec 2016 22:46:58 +0000 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a114118a00def520543194d34 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] [SUSPICIOUS] Re: review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 22:47:14 -0000 --001a114118a00def520543194d34 Content-Type: text/plain; charset=UTF-8 Hi Eric, > > > (a) WG advocates parallel IETF notification subscription mechanisms for > > > NETCONF: 5277 & this newer work. To me this doesn't seem tenable. > > Can you please elaborate why this is not tenable? > > Technically spoken I think it is the easiest way to enable continuing to use 5277 > > as it is and at the same to reduce the necessary effort for the new solution. > > I completely agree people should be good to use RFC-5277 deployments as long as they want. > The word 'untenable' refers to an IETF recommended approach for new deployments. Does the IETF really want to advocate two parallel solutions for NETCONF event subscriptions (5277 and what is > currently 5277bis)? I suspect this isn't allowed, hence 'obsolete' as my preference. IETF for sure is interested to have one solution. Though there is no rule written into stone. Whatever the WG and AD agree and the IESG approves can be published. > > This requires some discussion to understand the impacts. > ? Maybe I am confused. The NETCONF WG changed our direction a couple IETFs ago here. The request was to support the new capabilities with Event Notifications. Are you suggesting we change that? > The only question on the table which I believe needs to be addressed is enhance vs obsolete. What driver/question is raising a general revisiting of requirements? You actually did what I asked for with listing the requirements. I think we don't need to re-discuss all requirements. Though looking at the recent discussion it seems to be useful to revisit one or the other requirement just to get a certain basis. Thanks, Mehmet On Wed, Dec 7, 2016 at 9:09 PM Eric Voit (evoit) wrote: > > From: MehmetErsue, December 7, 2016 2:03 PM > > > > > > Keep it as it is (not obsolete) is certainly one option. > > > > > > Are you advocating for this option? > > > > > > The two 'not obsolete' options path I see are: > > > (a) WG advocates parallel IETF notification subscription mechanisms for > > NETCONF: 5277 & this newer work. To me this doesn't seem tenable. > > > > Can you please elaborate why this is not tenable? > > Technically spoken I think it is the easiest way to enable continuing to > use 5277 > > as it is and at the same to reduce the necessary effort for the new > solution. > > I completely agree people should be good to use RFC-5277 deployments as > long as they want. > > The word 'untenable' refers to an IETF recommended approach for new > deployments. Does the IETF really want to advocate two parallel solutions > for NETCONF event subscriptions (5277 and what is currently 5277bis)? I > suspect this isn't allowed, hence 'obsolete' as my preference. > > > > (b) WG has notification subscription capabilities which are less > > > functional the datastore subscription capabilities. (I.e., > > > notifications would not support capabilities such as multiple > > > subs/transport, modify, > delete, configured sub, OAM messages, > > > alternative non-NETCONF transports, etc.) > > > > > > The yang-push work was originally going down path (b) until the WG > > requested that subscription capabilities of RFC 7923 be supported for > > notifications. > > This requires some discussion to understand the impacts. > > ? Maybe I am confused. The NETCONF WG changed our direction a couple > IETFs ago here. The request was to support the new capabilities with Event > Notifications. Are you suggesting we change that? > > The only question on the table which I believe needs to be addressed is > enhance vs obsolete. What driver/question is raising a general revisiting > of requirements? > > Eric > > > BR, > > Mehmet > > -- Cheers, Mehmet --001a114118a00def520543194d34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Eric,

> > > (a) WG = advocates parallel IETF notification subscription mechanisms for
>=20 > > NETCONF: 5277 & this newer work.=C2=A0 To me this doesn't= seem tenable.
>=20 > Can you please elaborate why this is not tenable?
>=20 > Technically spoken I think it is the easiest way to enable continuing = to use 5277
>=20 > as it is and at the same to reduce the necessary effort for the new so= lution.
>
>=20 I completely agree people should be good to use RFC-5277 deployments as lon= g as they want.
> The word 'untenable' refers to an IETF recommended approac= h for new=20 deployments.=C2=A0 Does the IETF really want to advocate two parallel=20 solutions for NETCONF event subscriptions (5277 and what is
> curren= tly=20 5277bis)?=C2=A0 =C2=A0I suspect this isn't allowed, hence 'obsolete= ' as my=20 preference.

IETF for sure is interested to have one solution. Though there is n= o rule written into stone.
Whatever the WG and AD agree and the IESG app= roves can be published.

>=20 > This requires some discussion to understand the impacts.
> ?=C2=A0 =C2=A0 Maybe I am confused.=C2=A0 =C2=A0The NETCONF = WG changed our direction a=20 couple IETFs ago here.=C2=A0 The request was to support the new capabilitie= s=20 with Event Notifications.=C2=A0 Are you suggesting we change that?
>=20 The only question on the table which I believe needs to be addressed is=20 enhance vs obsolete.=C2=A0 =C2=A0What driver/question is raising a general= =20 revisiting of requirements?

You actually did what I asked for with listing the requirements.
I think we don't need to re-discuss all requirements.
T= hough looking at the recent discussion it seems to be useful to revisit one=20 or the other requirement just to get a certain basis.

Thanks,
Mehmet

On Wed, Dec 7, 2016 at 9:09 PM Eric Voit (evoit) &l= t;evoit@cisco.com> wrote:
> From: MehmetErsue, December 7, 2016 2= :03 PM
>
> > > Keep it as it is (not obsolete) is certainly one option.
> >
> > Are=C2=A0 you advocating for this option?
> >
> > The two 'not obsolete' options path I see are:
> > (a) WG advocates parallel IETF notification subscription mechanis= ms for
> NETCONF: 5277 & this newer work.=C2=A0 To me this doesn't seem= tenable.
>
> Can you please elaborate why this is not tenable?
> Technically spoken I think it is the easiest way to enable continuing = to use 5277
> as it is and at the same to reduce the necessary effort for the new so= lution.

I completely agree people should be good to use RFC-5277 deployments as lon= g as they want.

The word 'untenable' refers to an IETF recommended approach for new= deployments.=C2=A0 Does the IETF really want to advocate two parallel solu= tions for NETCONF event subscriptions (5277 and what is currently 5277bis)?= =C2=A0 =C2=A0I suspect this isn't allowed, hence 'obsolete' as = my preference.

> > (b) WG has notification subscription capabilities which are less<= br class=3D"gmail_msg"> > > functional the datastore subscription capabilities.=C2=A0 (I.e.,<= br class=3D"gmail_msg"> > > notifications would not support capabilities such as multiple
> > subs/transport, modify, > delete, configured sub, OAM messages= ,
> > alternative non-NETCONF transports, etc.)
> >
> > The yang-push work was originally going down path (b) until the W= G
> requested that subscription capabilities of RFC 7923 be supported for<= br class=3D"gmail_msg"> > notifications.
> This requires some discussion to understand the impacts.

?=C2=A0 =C2=A0 Maybe I am confused.=C2=A0 =C2=A0The NETCONF WG changed our = direction a couple IETFs ago here.=C2=A0 The request was to support the new= capabilities with Event Notifications.=C2=A0 Are you suggesting we change = that?

The only question on the table which I believe needs to be addressed is enh= ance vs obsolete.=C2=A0 =C2=A0What driver/question is raising a general rev= isiting of requirements?

Eric

> BR,
> Mehmet

--
Cheers,
Mehm= et
--001a114118a00def520543194d34-- From nobody Wed Dec 7 16:42:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E6C1295CC for ; Wed, 7 Dec 2016 16:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIkLY5uMaGzu for ; Wed, 7 Dec 2016 16:42:14 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C75C1295CF for ; Wed, 7 Dec 2016 16:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36930; q=dns/txt; s=iport; t=1481157734; x=1482367334; h=from:to:cc:subject:date:message-id:mime-version; bh=/Go881Qz9E41wnDAtSxJK4RlKmSj61hYdRNg2fuMApU=; b=bbNM7/jeQFVvMUDbe06Yu/kwcXb7SeLC/LBXQb+JBugFdov6eM6x+MNt WT2xlyYBhjcoUYJPkpEKr01hxy1aHGJcS22zfvt9Lgf/Qyr24ISzF9Vie Q7/JwBseYimKbnAkaGJc2K6LiNIFo1HtWBASzn1WdeE8hm9FxhLP2PDFb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCHq0hY/4gNJK1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJzRgEBAQEBH1qBBgeNQ5cQh3SNC4IHHgEKgkOCbEocgWM/FAE?= =?us-ascii?q?CAQEBAQEBAWIohGgBAQEDAQEBIQpBCwUNAR0PARMHAwIEHwYLFBIBBAENBQgTi?= =?us-ascii?q?DoDDwgOp16CKYc4DYN1AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGPocjgVgSgxq?= =?us-ascii?q?CXQWOf4V+hTU1AY04g1mQSYlQhDWEDQEfNzBpI4M4HRiBRXKGYwIkAwEDgQOBD?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,316,1477958400"; d="scan'208,217";a="184397609" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2016 00:42:13 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uB80gCJj019804 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Dec 2016 00:42:13 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Dec 2016 19:42:12 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 7 Dec 2016 19:42:12 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , MehmetErsue Thread-Topic: Subscription Use Cases (was RE: [Netconf] Still subject to agree on NETCONF ML) Thread-Index: AdJQ6+UKJidjpmIMS9+gFVyAmKGyPQ== Date: Thu, 8 Dec 2016 00:42:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_e9128f79b8bc4923815e40510678c026XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: [Netconf] Subscription Use Cases (was RE: Still subject to agree on NETCONF ML) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 00:42:18 -0000 --_000_e9128f79b8bc4923815e40510678c026XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZSBhcmUgc29tZSBtb3JlIGNhc2VzLiAgSGFwcHkgdG8gdGFsayBtb3JlIG9yIGRlbW8gaWYg cGVvcGxlIGFyZSBpbnRlcmVzdGVkLg0KDQoNCg0KKENhdGVnb3J5IDEpIFN0cmVhbWluZyBUZWxl bWV0cnkNCg0KSGlnaCB2b2x1bWUgc2V0IG9mIG9iamVjdHMgcHVzaGVkIG9uIGEgcHJlZGljdGFi bGUgc2NoZWR1bGUuDQoNCigxYSkgVGVsZW1ldHJ5OiBGYXN0IHJlcGxpY2F0aW9uIG9mIFlBTkcg b3BlcmF0aW9uYWwvY29uZmlnIGRhdGEgb2ZmLWJveCBmb3IgdHJhZmZpYyBvciBjb25maWd1cmF0 aW9uIGFuYWx5c2lzDQoNCigxYikgTXVsdGkgb3BlcmF0aW9ucyByZXBvcnRpbmc6IFNlbmQgYSB0 YXJnZXRlZCBzdWJzZXQgb3BlcmF0aW9uYWwvY29uZmlnIGRhdGEgdG8gYW4gT3BlcmF0aW9ucyBn cm91cCBub3QgZGlyZWN0bHkgbWFuYWdpbmcgZGV2aWNlDQoNCihDYXRlZ29yeSAyKSBEaXN0cmli dXRlZCBFdmVudGluZw0KDQpObyBuZWVkIHRvIHJlcGVhdGVkbHkgcG9sbCB0byBzZWUgaWYgdGFy Z2V0ZWQgc3Vic2V0cyBvZiBOZXR3b3JrIEVsZW1lbnQgY29uZmlnIGhhdmUgY2hhbmdlZC4gVGhl IGxhdGVzdCBpcyBwdXNoZWQgYXMgaXQgaGFwcGVucy4NCg0KKDJhKSBJbnRlZ3JpdHkgVmVyaWZp Y2F0aW9uOiBQdXNoIGRpc2NvdmVyZWQgY2hhbmdlcyBpbiBrZXlzLCBjb25maWcsIHNvZnR3YXJl IGhhc2ggYXMgdGhleSBoYXBwZW4uICBBcHBsaWNhdGlvbiB2YWxpZGF0ZXMgdGhhdCBjaGFuZ2Ug aXMgYXV0aG9yaXplZC4NCg0KKDJiKSBFbGltaW5hdGUgUG9sbGluZzogTk1TL2NvbnRyb2xsZXJz IHB1c2hlZCBjb25maWcgY2hhbmdlcyBhcyB0aGV5IG9jY3VyIGluIE5ldHdvcmsgRWxlbWVudHMg KGVuYWJsaW5nIHJlYWwtdGltZSBzdGF0ZSBzeW5jaHJvbml6YXRpb24pLg0KDQooMmMpIElXQU46 IENoYW5nZXMgaW4gT3BlcmF0aW9uYWwgRGF0YSBkcml2ZSBuZXR3b3JrIHJlYmFsYW5jaW5nIGZv ciBvcHRpbWl6ZWQgZW50ZXJwcmlzZSBmYWNpbGl0aWVzIHVzYWdlDQoNCigyZCkgRG9tYWluIFBv bGljZXI6IHByb3ZpZGUgYSBzaW5nbGUgcG9saWNlZCBkYXRhIHJhdGUgYWNyb3NzIG11bHRpcGxl IGRhdGEgY2VudGVycyBvciBicmFuY2ggb2ZmaWNlcw0KDQooMmUpIEREb1MgUHJvdGVjdGlvbjog c2VuZCBzdXNwZWN0IHNwaWtlcyBvZiB0cmFmZmljIGFjcm9zcyBhIHNldCBkZXZpY2VzIHRvIGEg c2NydWJiZXINCg0KDQoNCihDYXRlZ29yeSAzKSBOZXR3b3JrIGFzIHRoZSBTdWJzY3JpYmVyDQoN CkRpc3RyaWJ1dGVkIENQRSwgVk1zLCByb3V0ZXJzIGNhbiBzdWJzY3JpYmUgdG8gYSBmYXN0IGNo YW5naW5nIGNlbnRyYWxpemVkIGNvbmZpZ3VyYXRpb24gcmVwb3NpdG9yeQ0KDQooM2EpIFBlcmlt ZXRlciAmIEludGVybmFsIEJsb2NraW5nOiBXaGVuIHZ1bG5lcmFiaWxpdGllcyBhcmUgZGV0ZWN0 ZWQsIGVwaGVtZXJhbCByZW1lZGlhdGlvbiBwb2xpY2llcyBhcmUgdGVtcG9yYXJpbHkgaW5zdGFs bGVkIGFjcm9zcyBhIGRvbWFpbiBvZiBkZXZpY2VzLg0KDQooM2IpIFR1bm5lbCBFbmRwb2ludCBT eW5jaDogRmlsdGVyZWQgc3Vic2V0cyBvZiBjZW50cmFsbHkgbWFuYWdlZCB0dW5uZWwgRXRoZXJu ZXQgZW5kcG9pbnRzIGNhbiBiZSBkb3dubG9hZGVkIGFuZCBjb29yZGluYXRlZCBhY3Jvc3MgZWRn ZSBkZXZpY2VzIHRvIG1pbmltaXplIGVmZm9ydCBpbiBtYWludGFpbmluZyBkeW5hbWljIG1lc2gN Cg0KKDNjKSBQb2xpY3kgbWlycm9yaW5nOiBFbmFibGVzIHRydXN0ZWQgb3IgcGFydGlhbGx5LXRy dXN0ZWQgZWRnZSBkZXZpY2VzIHRvIG1pcnJvciB0aGUgc3RhdGUgb2YgYSBjZW50cmFsIGNvbmZp Z3VyYXRpb24gcmVwb3NpdG9yeQ0KDQpFcmljDQoNCg0KDQpGcm9tOiBOZXRjb25mLCBEZWNlbWJl ciA3LCAyMDE2IDU6NDIgUE0NCg0KDQoNCkhpLA0KDQoNCg0KDQoNClRoZSByZWFsIHF1ZXN0aW9u IGlzIHdoYXQgdXNlLWNhc2VzIGRvIHdlIGFncmVlIG5lZWQgdG8gYmUgc3VwcG9ydGVkIHdoaWNo DQoNCmFyZSBub3QgY3VycmVudGx5IHN1cHBvcnRlZCB0aGF0IHdlbGwuIEhlcmUgYXJlIDMsIHdo ZXJlIHRoZSA1Mjc3IHNvbHV0aW9uDQoNCm1heSBub3Qgc2NhbGUgd2VsbCBlbm91Z2ggaW4gaW1w bGVtZW50YXRpb24NCg0KDQoNCiAgIC0gbm90aWZpY2F0aW9uIGNvbGxlY3RvcjogSWYgc3Vic2Ny aXB0aW9ucyBhcmUgcHJvdmlkZWQgYXMgYSBzZXJ2aWNlIHRoZW4gbXVsdGlwbGUgc3Vic2NyaXB0 aW9ucw0KDQogICAgIHBlciBzZXNzaW9uIG1heSBwcm92aWRlIHNvbWUgb3Bwb3J0dW5pdGllcyBm b3Igb3B0aW1pemF0aW9uIG9uIHRoZSBjb2xsZWN0b3IgYW5kIHRoZSBzZXJ2ZXIuDQoNCiAgICAg ZS5nLiwgc2VuZCBhIG5vdGlmaWNhdGlvbiBqdXN0IG9uY2UsIHRhZ2dlZCB3aXRoIGFsbCB0aGUg c3Vic2NyaXB0aW9uLWlkcyB0aGF0IGFyZSBzdXBwb3NlZCB0bw0KDQogICAgZ2V0IHRoaXMgbm90 aWZpY2F0aW9uDQoNCg0KDQogIC0gdGVsZW1ldHJ5OiBuZWVkIGhpZ2gtcGVyZm9ybWFuY2UgYW5k IGVmZmljaWVudCB1c2Ugb2YgdGhlIG5ldHdvcms7IGNvbnNpZGVyIGJpbmFyeSBlbmNvZGluZw0K DQogICAgYW5kIG5vbi1zZWN1cmUgdHJhbnNwb3J0czsgcmVseWluZyBvbiBZQU5HIFB1c2ggc28g dGhhdCBkcmFmdCBoYXMgdG8gY2xlYXJseSBpZGVudGlmeSBsb3dlcg0KDQogICAgbGF5ZXIgcmVx dWlyZW1lbnRzDQoNCg0KDQogLSBkYXRhc3RvcmUgcmVwbGljYXRpb246IG5lZWQgcmVsaWFibGUg ZGVsaXZlcnkgYW5kIGhpZ2ggcGVyZm9ybWFuY2U7IFlBTkcgUHVzaCBpcyBhbHNvDQoNCiAgIHRo ZSBzb2x1dGlvbiBmb3IgdGhpcyB1c2UtY2FzZQ0KDQoNCg0KSU1PIHdlIHdpbGwgbm90IG1ha2Ug cHJvZ3Jlc3Mgb24gc29sdXRpb24gZGV0YWlscyB3aXRob3V0IGEgYmV0dGVyIHVuZGVyc3RhbmRp bmcgb2YgdGhlIHVzZS1jYXNlcy4NCg0KDQoNCg0KDQpBbmR5DQoNCg0KDQoNCg0KT24gV2VkLCBE ZWMgNywgMjAxNiBhdCAxMToyMCBBTSwgTWVobWV0RXJzdWUgPG1haWx0bzptZXJzdWVAZ21haWwu Y29tPiB3cm90ZToNCg0KSGkgQW5keSwgQWxsLA0KDQpjYW4gYW55Ym9keSBkcmFmdCBhIGxpc3Qg b2YgbXVzdC1oYXZlLCBzaG91bGQtaGF2ZSwgYW5kIG5pY2UtdG8taGF2ZSByZXF1aXJlbWVudHMg Zm9yIGRpc2N1c3Npb24gb24gdGhlIE1MPw0KDQpJIHRoaW5rIHdyaXRpbmcgYSBkcmFmdCBmb3Ig dGhpcyB3b3VsZCBiZSBhbiBvdmVyLWtpbGwgYnV0IEknbSBmbGV4aWJsZS4NCg0KTWVobWV0DQoN Cg0KDQoNCg0KT24gV2VkLCBEZWMgNywgMjAxNiBhdCA2OjU0IFBNIEFuZHkgQmllcm1hbiA8bWFp bHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQoNCk9uIFdlZCwgRGVjIDcsIDIwMTYgYXQg OTozOCBBTSwgTWVobWV0RXJzdWUgPG1haWx0bzptZXJzdWVAZ21haWwuY29tPiB3cm90ZToNCg0K QWxsLA0KDQoNCg0KPiA+IFRoZSA8bm9maXRpY2F0aW9uPiBlbGVtZW50IGlzIGNoYW5naW5nIHNv IG9sZCBjbGllbnRzIGNhbm5vdA0KDQo+ID4gZ2V0IHRoZSBuZXcgdmVyc2lvbiB0aGF0IGNvbnRh aW5zIGEgc3Vic2NyaXB0aW9uLWlkIGFuZCBvdGhlcg0KDQo+ID4gZmllbGRzLg0KDQo+DQoNCj4g SSBoYXZlbid0IHNlZW4gYW55IHByb3Bvc2FsIGZvciBkb2luZyB0aGlzIG9uIHRoZSBNTC4NCg0K QW55IGRpc2N1c3Npb24gcmVzdWx0IGZyb20gdGhlIG5vdGlmaWNhdGlvbiB0ZWFtIG1lZXRpbmdz IGlzIHN0aWxsIHN1YmplY3QgdG8gYWdyZWUgb24gTkVUQ09ORiBNTC4NCg0KU3VjaCBpc3N1ZXMg c2hvdWxkIGJlIHJhaXNlZCBvbiB0aGUgTUwsIHRoZSBlYXJsaWVyIHRoZSBiZXR0ZXIuDQoNCg0K DQpJIHRoaW5rIE1hcnRpbiBoYXMgcmFpc2VkIHZhbGlkIGNvbmNlcm5zIHRoYXQgd2UgZG8gbm90 IHlldCBhZ3JlZSBvbiB0aGUgcmVxdWlyZW1lbnRzLg0KDQpUaGUgZGV0YWlscyBvZiBhIHNvbHV0 aW9uIGRvIG5vdCBtYXR0ZXIgaWYgcGVvcGxlIGRvIG5vdCBhZ3JlZSBvbiB0aGUgcHJvYmxlbSBm aXJzdC4NCg0KDQoNCldoYXQgYXJlIHRoZSBtdXN0LWhhdmUsIHNob3VsZC1oYXZlLCBhbmQgbmlj ZS10by1oYXZlIGZlYXR1cmVzIHRoYXQgYXJlIG1pc3NpbmcgZnJvbSBSRkMgNTI3Nz8NCg0KDQoN CkUuZy4sIGlmIHdlIGFncmVlIHRoYXQgaXMgaXMgYSB0ZXJyaWJsZSBidXJkZW4gb24gdGhlIGNs aWVudCB0aGF0IDEgc2Vzc2lvbiBiZSB1c2VkIGZvciBlYWNoIHN1YnNjcmlwdGlvbiwNCg0KdGhl biBtdWx0aXBsZSBzdWJzY3JpcHRpb25zIHBlciBzZXNzaW9uIGlzIGFuIGltcG9ydGFudCBmZWF0 dXJlLiAgSG93IHRvIGRvIHRoYXQgaXMgdGhlIG5leHQgc3RlcCwNCg0Kbm90IHRoaXMgc3RlcC4N Cg0KDQoNCg0KDQoNCg0KTWVobWV0DQoNCg0KDQoNCg0KDQoNCkFuZHkNCg0KDQoNCg0KDQpPbiBN b24sIERlYyA1LCAyMDE2IGF0IDEwOjM1IFBNIE1hcnRpbiBCam9ya2x1bmQgPG1haWx0bzptYmpA dGFpbC1mLmNvbT4gd3JvdGU6DQoNCkFuZHkgQmllcm1hbiA8bWFpbHRvOmFuZHlAeXVtYXdvcmtz LmNvbT4gd3JvdGU6DQoNCj4gT24gTW9uLCBEZWMgNSwgMjAxNiBhdCAxMjo0OCBQTSwgTWFydGlu IEJqb3JrbHVuZCA8bWFpbHRvOm1iakB0YWlsLWYuY29tPiB3cm90ZToNCg0KPg0KDQo+ID4gQW5k eSBCaWVybWFuIDxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCg0KPiA+ID4gT24g TW9uLCBEZWMgNSwgMjAxNiBhdCAxMjozNyBQTSwgTWFydGluIEJqb3JrbHVuZCA8bWFpbHRvOm1i akB0YWlsLWYuY29tPg0KDQo+ID4gd3JvdGU6DQoNCj4gPiA+DQoNCj4gPiA+ID4gQW5keSBCaWVy bWFuIDxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCg0KPiA+ID4gPiA+IEhpLA0K DQo+ID4gPiA+ID4NCg0KPiA+ID4gPiA+IEkgcHJlZmVyIHRoZSBjdXJyZW50IHNvbHV0aW9uIGFw cHJvYWNoLCB3aGljaCBpcyB0byB1c2UNCg0KPiA+ID4gPiA+ICdlc3RhYmxpc2gtc3Vic2NyaXB0 aW9uJy4NCg0KPiA+ID4gPg0KDQo+ID4gPiA+IENhbiB5b3UgZWxhYm9yYXRlIG9uIHdoeSB5b3Ug cHJlZmVyIHR3byBvcGVyYXRpb25zIGluc3RlYWQgb2Ygb25lLA0KDQo+ID4gPiA+IHdoZW4gdGhl eSBkbyB0aGUgc2FtZSB0aGluZz8NCg0KPiA+ID4gPg0KDQo+ID4gPg0KDQo+ID4gPiBiZWNhdXNl IHRoZXkgZG9uJ3QgZG8gdGhlIHNhbWUgdGhpbmcuDQoNCj4gPiA+IFRoZSBuZXcgc29sdXRpb24g aGFzIGNvbmZpZ3VyZWQgZmlsdGVycywgc3Vic2NyaXB0aW9uLWlkLCBzdXNwZW5kIGFuZA0KDQo+ ID4gPiBjYW5jZWwgb3BlcmF0aW9ucw0KDQo+ID4NCg0KPiA+IFRoZXNlIGFyZSB0cml2aWFsIGV4 dGVuc2lvbnMgdG8gdGhlIGN1cnJlbnQgc29sdXRpb24uDQoNCj4gPg0KDQo+ID4gSWYgdGhleSBh cmUgdHJ1bHkgZGlmZmVyZW50IHRoZSBuYW1lcyBzaG91bGQgbm90IGJlIHNvIHNpbWlsYXIuDQoN Cj4gPg0KDQo+ID4gPiBhbmQgc2hvdWxkIG5vdCBuZWVkIHN0cmVhbXMuDQoNCj4gPg0KDQo+ID4g V2hhdCBkbyB5b3UgbWVhbiAic2hvdWxkIG5vdCBuZWVkIHN0cmVhbXMiPw0KDQo+ID4NCg0KPiA+ DQoNCj4NCg0KPiBUaGUgc3RyZWFtcyBjb25jZXB0IGlzIGhhbGYtYmFrZWQgYW5kIG5vdCB1c2Vm dWwuDQoNCg0KDQpJIHN0cm9uZ2x5IGRpc2FncmVlLiAgVGhlIHN0cmVhbSBjb25jZXB0IGluY2x1 ZGluZyByZXBsYXkgaXMgdmVyeQ0KDQpwb3dlcmZ1bC4NCg0KDQoNCklmIHlvdSB0aGluayBpdCBz aG91bGQgYmUgZGVwcmVjYXRlZCBhbmQgcmVwbGFjZWQgd2l0aCBzb21ldGhpbmcgZWxzZSwNCg0K SSB0aGluayB0aGF0IHJlcXVpcmVzIHNvbWUgY2FyZWZ1bCBkaXNjdXNzaW9uIGZpcnN0LiAgKHN1 Y2ggYXMgYQ0KDQpkZXNjcmlwdGlvbiBvZiBpdHMgcHJvYmxlbXMsIGFuZCBhIGRlc2NyaXB0aW9u IG9mIGEgbmV3IHNvbHV0aW9uKS4NCg0KDQoNCj4gV2UgaGF2ZSAxIHN0cmVhbSwgTkVUQ09ORiwg d2hpY2ggTVVTVCBjb250YWluIGV2ZXJ5dGhpbmcNCg0KDQoNCk5vIGl0IGRvZXNuJ3QuICBUaGlz IHdhcyBkaWN1c3NlZCByZWNlbnRseS4gIFRoZSB0ZXh0IHNheXM6DQoNCg0KDQogICBUaGlzIHN0 cmVhbSBjb250YWlucyBhbGwgTkVUQ09ORiBYTUwgZXZlbnQgbm90aWZpY2F0aW9ucyBzdXBwb3J0 ZWQgYnkNCg0KICAgdGhlIE5FVENPTkYgc2VydmVyLg0KDQoNCg0KTm90ZSBpdCBzYXlzICJhbGwg TkVUQ09ORiBYTUwgZXZlbnQgbm90aWZpY2F0aW9ucyIsIG5vdCAiYWxsDQoNCltYTUxdIGV2ZW50 IG5vdGlmaWNhdGlvbnMiLg0KDQoNCg0KPiBhbmQNCg0KPiBNVVNUIGJlIGVuY29kZWQgaW4gWE1M Lg0KDQoNCg0KV2VsbCwgTkVUQ09ORiBpcyBlbmNvZGVkIGluIFhNTCBzbyB0aGlzIHNob3VsZCBu b3QgY29tZSBhcyBhDQoNCnN1cnByaXNlLi4uDQoNCg0KDQo+IEV2ZXJ5IG90aGVyIHN0cmVhbSBp cyBwdXJlbHkgYWQtaG9jIGFuZA0KDQo+IHByb3ByaWV0YXJ5DQoNCg0KDQpOb3QgcmVhbGx5LiAg QWxsIHN0cmVhbXMgc3VwcG9ydGVkIGNhbiBiZSBkaXNjb3ZlcmVkIGJ5IGFueSBjbGllbnQNCg0K KHdpdGggcHJvcGVyIGFjY2VzcyByaWdodHMpLg0KDQoNCg0KPiB3aXRoIG5vIGNoYW5jZSBhdCBp bnRlcm9wZXJhYmlsaXR5Lg0KDQoNCg0KVGhpcyBpcyBhIGZhbHNlIHN0YXRlbWVudC4gIFdlIGhh dmUgZGVmaW5lZCBzZXZlcmFsIGRpZmZlcmVudCBzdHJlYW1zDQoNCnRoYXQgdGhpcmQgcGFydHkg Y2xpZW50cyB1c2Ugdy9vIGFueSBwcm9ibGVtcy4gIElmIGEgc3RyZWFtIGRvZXNuJ3QNCg0KaW50 ZXJvcGVyYXRlIGIvYyBvZiBpdHMgbmFtZSwgc29tZSBpbXBsZW1lbnRhdGlvbiBpcyBidWdneS4N Cg0KDQoNCj4gPiA+IFRoZSBvbGQgc29sdXRpb24gY2FuIGJlIGRlcHJlY2F0ZWQgYW5kIHJlcGxh Y2VkLg0KDQo+ID4NCg0KPiA+IFN1cmUsIGlmIGl0IGlzIGJyb2tlbi4gIEJ1dCBJIGRvbid0IHRo aW5rIGl0IGlzIGJyb2tlbiBpbiBhbnkgd2F5Lg0KDQo+ID4NCg0KPiA+DQoNCj4gPg0KDQo+IFRo ZSA8bm9maXRpY2F0aW9uPiBlbGVtZW50IGlzIGNoYW5naW5nIHNvIG9sZCBjbGllbnRzIGNhbm5v dA0KDQo+IGdldCB0aGUgbmV3IHZlcnNpb24gdGhhdCBjb250YWlucyBhIHN1YnNjcmlwdGlvbi1p ZCBhbmQgb3RoZXINCg0KPiBmaWVsZHMuDQoNCg0KDQpJIGhhdmVuJ3Qgc2VlbiBhbnkgcHJvcG9z YWwgZm9yIGRvaW5nIHRoaXMgb24gdGhlIE1MLg0KDQoNCg0KPiBJTU8gaXQgaXMgc2ltcGxlciBh bmQgY2xlYXJlciBpZiB0aGUgbmV3IHNvbHV0aW9uIGlzIHNlcGFyYXRlLg0KDQoNCg0KTWF5YmUu ICBBbnl3YXksIG15IHBvc3Qgd2FzIHJlYWxseSBpbiByZXBseSB0byBFcmljJ3Mgc3RhdGVtZW50 IHRoYXQNCg0KdGhlc2UgbmV3IGZlYXR1cmVzIGNvdWxkIG5vdCBiZSBidWlsdCBvbiB0b3Agb2Yg d2hhdCB3ZSBoYXZlIGFuZCBzdGlsbA0KDQpiZSBiYWNrd2FyZHMgY29tcGF0aWJsZS4NCg0KDQoN Ck9uZSB3YXkgb2YgbWFraW5nIHN0cmVhbXMgZXZlbiBtb3JlIHVzZWZ1bCBpcyB0byBtYWtlIHRo ZW0NCg0KY29uZmlndXJhYmxlLCBlLmcuIGluc3RlYWQgb2YgY3JlYXRpbmcgY29uZmlndXJhYmxl IGZpbHRlcnMsIGFuIGlkZWENCg0KaXMgdG8gY3JlYXRlIGEgbmV3IHN0cmVhbSB0b2dldGhlciB3 aXRoIGEgZmlsdGVyLCBhbmQgcmVwbGF5DQoNCmRlZmluaXRpb24uICBCZWluZyBhYmxlIHRvIGRv IHRoaXMgZHluYW1pY2FsbHkgd291bGQgYWN0dWFsbHkgYmUgcXVpdGUNCg0KdXNlZnVsLg0KDQoN Cg0KDQoNCi9tYXJ0aW4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCk5ldGNvbmYgbWFpbGluZyBsaXN0DQoNCm1haWx0bzpOZXRjb25mQGll dGYub3JnDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K DQotLQ0KDQpDaGVlcnMsDQoNCk1laG1ldA0KDQotLQ0KDQpDaGVlcnMsDQoNCk1laG1ldA0KDQoN Cg== --_000_e9128f79b8bc4923815e40510678c026XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLm0tNzI3MjIzNTg1NjI1OTEw NjU5M2dtYWlsbXNnDQoJe21zby1zdHlsZS1uYW1lOm1fLTcyNzIyMzU4NTYyNTkxMDY1OTNnbWFp bF9tc2c7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4ubS03 MjcyMjM1ODU2MjU5MTA2NTkzbS02MDY4NDU2ODkzNjAyNjU2NTM2aG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOm1fLTcyNzIyMzU4NTYyNTkxMDY1OTNtXy02MDY4NDU2ODkzNjAyNjU2NTM2aG9lbnpi O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhlcmUgYXJlIHNv bWUgbW9yZSBjYXNlcy4mbmJzcDsgSGFwcHkgdG8gdGFsayBtb3JlIG9yIGRlbW8gaWYgcGVvcGxl IGFyZSBpbnRlcmVzdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48dT4oQ2F0ZWdv cnkgMSkgU3RyZWFtaW5nIFRlbGVtZXRyeTwvdT4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5IaWdoIHZvbHVtZSBzZXQgb2Ygb2JqZWN0cyBwdXNoZWQgb24gYSBwcmVk aWN0YWJsZSBzY2hlZHVsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PigxYSkgVGVsZW1ldHJ5OiBGYXN0IHJlcGxpY2F0aW9uIG9mIFlBTkcgb3BlcmF0aW9uYWwvY29u ZmlnIGRhdGEgb2ZmLWJveCBmb3IgdHJhZmZpYyBvciBjb25maWd1cmF0aW9uIGFuYWx5c2lzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4oMWIpIE11bHRpIG9wZXJhdGlv bnMgcmVwb3J0aW5nOiBTZW5kIGEgdGFyZ2V0ZWQgc3Vic2V0IG9wZXJhdGlvbmFsL2NvbmZpZyBk YXRhIHRvIGFuIE9wZXJhdGlvbnMgZ3JvdXAgbm90IGRpcmVjdGx5IG1hbmFnaW5nIGRldmljZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48dT4oQ2F0ZWdvcnkgMikgRGlzdHJpYnV0ZWQgRXZlbnRp bmc8L3U+IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Tm8gbmVlZCB0 byByZXBlYXRlZGx5IHBvbGwgdG8gc2VlIGlmIHRhcmdldGVkIHN1YnNldHMgb2YgTmV0d29yayBF bGVtZW50IGNvbmZpZyBoYXZlIGNoYW5nZWQuJm5ic3A7VGhlIGxhdGVzdCBpcyBwdXNoZWQgYXMg aXQgaGFwcGVucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPigyYSkg SW50ZWdyaXR5IFZlcmlmaWNhdGlvbjogUHVzaCBkaXNjb3ZlcmVkIGNoYW5nZXMgaW4ga2V5cywg Y29uZmlnLCBzb2Z0d2FyZSBoYXNoIGFzIHRoZXkgaGFwcGVuLiZuYnNwOyBBcHBsaWNhdGlvbiB2 YWxpZGF0ZXMgdGhhdCBjaGFuZ2UgaXMgYXV0aG9yaXplZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPigyYikgRWxpbWluYXRlIFBvbGxpbmc6IE5NUy9jb250cm9sbGVy cyBwdXNoZWQgY29uZmlnIGNoYW5nZXMgYXMgdGhleSBvY2N1ciBpbiBOZXR3b3JrIEVsZW1lbnRz IChlbmFibGluZyByZWFsLXRpbWUgc3RhdGUgc3luY2hyb25pemF0aW9uKS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPigyYykgSVdBTjogQ2hhbmdlcyBpbiBPcGVyYXRp b25hbCBEYXRhIGRyaXZlIG5ldHdvcmsgcmViYWxhbmNpbmcgZm9yIG9wdGltaXplZCBlbnRlcnBy aXNlIGZhY2lsaXRpZXMgdXNhZ2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPigyZCkgRG9tYWluIFBvbGljZXI6IHByb3ZpZGUgYSBzaW5nbGUgcG9saWNlZCBkYXRhIHJh dGUgYWNyb3NzIG11bHRpcGxlIGRhdGEgY2VudGVycyBvciBicmFuY2ggb2ZmaWNlczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KDJlKSBERG9TIFByb3RlY3Rpb246IHNl bmQgc3VzcGVjdCBzcGlrZXMgb2YgdHJhZmZpYyBhY3Jvc3MgYSBzZXQgZGV2aWNlcyB0byBhIHNj cnViYmVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjx1PihDYXRlZ29yeSAzKSBOZXR3 b3JrIGFzIHRoZSBTdWJzY3JpYmVyPC91PiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkRpc3RyaWJ1dGVkIENQRSwgVk1zLCByb3V0ZXJzIGNhbiBzdWJzY3JpYmUgdG8g YSBmYXN0IGNoYW5naW5nIGNlbnRyYWxpemVkIGNvbmZpZ3VyYXRpb24gcmVwb3NpdG9yeTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KDNhKSBQZXJpbWV0ZXIgJmFtcDsg SW50ZXJuYWwgQmxvY2tpbmc6IFdoZW4gdnVsbmVyYWJpbGl0aWVzIGFyZSBkZXRlY3RlZCwgZXBo ZW1lcmFsIHJlbWVkaWF0aW9uIHBvbGljaWVzIGFyZSB0ZW1wb3JhcmlseSBpbnN0YWxsZWQgYWNy b3NzIGEgZG9tYWluIG9mIGRldmljZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4oM2IpIFR1bm5lbCBFbmRwb2ludCBTeW5jaDogRmlsdGVyZWQgc3Vic2V0cyBvZiBj ZW50cmFsbHkgbWFuYWdlZCB0dW5uZWwgRXRoZXJuZXQgZW5kcG9pbnRzIGNhbiBiZSBkb3dubG9h ZGVkIGFuZCBjb29yZGluYXRlZCBhY3Jvc3MgZWRnZSBkZXZpY2VzIHRvIG1pbmltaXplIGVmZm9y dCBpbiBtYWludGFpbmluZyBkeW5hbWljIG1lc2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPigzYykgUG9saWN5IG1pcnJvcmluZzogRW5hYmxlcyB0cnVzdGVkIG9yIHBh cnRpYWxseS10cnVzdGVkIGVkZ2UgZGV2aWNlcyB0byBtaXJyb3IgdGhlIHN0YXRlIG9mIGEgY2Vu dHJhbCBjb25maWd1cmF0aW9uIHJlcG9zaXRvcnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RXJp YzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Gcm9tOiBOZXRjb25mLCBEZWNlbWJlciA3 LCAyMDE2IDU6NDIgUE08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGksPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+VGhlIHJlYWwgcXVlc3Rpb24gaXMgd2hhdCB1c2UtY2FzZXMgZG8gd2UgYWdy ZWUgbmVlZCB0byBiZSBzdXBwb3J0ZWQgd2hpY2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPmFyZSBub3QgY3VycmVudGx5IHN1cHBvcnRlZCB0aGF0IHdlbGwuIEhlcmUg YXJlIDMsIHdoZXJlIHRoZSA1Mjc3IHNvbHV0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5tYXkgbm90IHNjYWxlIHdlbGwgZW5vdWdoIGluIGltcGxlbWVudGF0aW9u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyAmbmJzcDstIG5vdGlmaWNhdGlv biBjb2xsZWN0b3I6IElmIHN1YnNjcmlwdGlvbnMgYXJlIHByb3ZpZGVkIGFzIGEgc2VydmljZSB0 aGVuIG11bHRpcGxlIHN1YnNjcmlwdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyAmbmJzcDsgJm5ic3A7cGVyIHNlc3Npb24gbWF5IHByb3ZpZGUgc29t ZSBvcHBvcnR1bml0aWVzIGZvciBvcHRpbWl6YXRpb24gb24gdGhlIGNvbGxlY3RvciBhbmQgdGhl IHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ZS5nLiwgc2VuZCBhIG5vdGlmaWNhdGlvbiBqdXN0IG9uY2UsIHRhZ2dlZCB3 aXRoIGFsbCB0aGUgc3Vic2NyaXB0aW9uLWlkcyB0aGF0IGFyZSBzdXBwb3NlZCB0bzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7ICZuYnNwOyBnZXQgdGhpcyBu b3RpZmljYXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7IC0gdGVsZW1l dHJ5OiBuZWVkIGhpZ2gtcGVyZm9ybWFuY2UgYW5kIGVmZmljaWVudCB1c2Ugb2YgdGhlIG5ldHdv cms7IGNvbnNpZGVyIGJpbmFyeSBlbmNvZGluZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7ICZuYnNwOyBhbmQgbm9uLXNlY3VyZSB0cmFuc3BvcnRzOyByZWx5 aW5nIG9uIFlBTkcgUHVzaCBzbyB0aGF0IGRyYWZ0IGhhcyB0byBjbGVhcmx5IGlkZW50aWZ5IGxv d2VyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgJm5ic3A7 IGxheWVyIHJlcXVpcmVtZW50czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDst IGRhdGFzdG9yZSByZXBsaWNhdGlvbjogbmVlZCByZWxpYWJsZSBkZWxpdmVyeSBhbmQgaGlnaCBw ZXJmb3JtYW5jZTsgWUFORyBQdXNoIGlzIGFsc288bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyAmbmJzcDt0aGUgc29sdXRpb24gZm9yIHRoaXMgdXNlLWNhc2U8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SU1PIHdlIHdpbGwgbm90IG1ha2UgcHJvZ3Jl c3Mgb24gc29sdXRpb24gZGV0YWlscyB3aXRob3V0IGEgYmV0dGVyIHVuZGVyc3RhbmRpbmcgb2Yg dGhlIHVzZS1jYXNlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BbmR5PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+T24gV2VkLCBEZWMgNywgMjAxNiBhdCAxMToyMCBBTSwgTWVobWV0RXJzdWUgJmx0O21haWx0 bzptZXJzdWVAZ21haWwuY29tJmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkhpIEFuZHksIEFsbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPmNhbiBhbnlib2R5IGRyYWZ0IGEgbGlzdCBvZiBtdXN0LWhhdmUsIHNob3VsZC1o YXZlLCBhbmQgbmljZS10by1oYXZlIHJlcXVpcmVtZW50cyBmb3IgZGlzY3Vzc2lvbiBvbiB0aGUg TUw/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIHRoaW5rIHdyaXRp bmcgYSBkcmFmdCBmb3IgdGhpcyB3b3VsZCBiZSBhbiBvdmVyLWtpbGwgYnV0IEknbSBmbGV4aWJs ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1laG1ldDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPk9uIFdlZCwgRGVjIDcsIDIwMTYgYXQgNjo1NCBQTSBBbmR5IEJpZXJtYW4g Jmx0O21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T24gV2VkLCBEZWMgNywgMjAxNiBhdCA5OjM4IEFNLCBN ZWhtZXRFcnN1ZSAmbHQ7bWFpbHRvOm1lcnN1ZUBnbWFpbC5jb20mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgVGhlICZsdDtub2ZpdGljYXRpb24mZ3Q7IGVsZW1lbnQgaXMg Y2hhbmdpbmcgc28gb2xkIGNsaWVudHMgY2Fubm90PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgZ2V0IHRoZSBuZXcgdmVyc2lvbiB0aGF0IGNvbnRhaW5z IGEgc3Vic2NyaXB0aW9uLWlkIGFuZCBvdGhlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGZpZWxkcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IEkgaGF2ZW4ndCBzZWVuIGFueSBwcm9wb3NhbCBmb3IgZG9pbmcgdGhpcyBvbiB0aGUg TUwuIDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BbnkgZGlzY3Vz c2lvbiByZXN1bHQgZnJvbSB0aGUgbm90aWZpY2F0aW9uIHRlYW0gbWVldGluZ3MgaXMgc3RpbGwg c3ViamVjdCB0byBhZ3JlZSBvbiBORVRDT05GIE1MLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+U3VjaCBpc3N1ZXMgc2hvdWxkIGJlIHJhaXNlZCBvbiB0aGUgTUwsIHRo ZSBlYXJsaWVyIHRoZSBiZXR0ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgdGhp bmsgTWFydGluIGhhcyByYWlzZWQgdmFsaWQgY29uY2VybnMgdGhhdCB3ZSBkbyBub3QgeWV0IGFn cmVlIG9uIHRoZSByZXF1aXJlbWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5UaGUgZGV0YWlscyBvZiBhIHNvbHV0aW9uIGRvIG5vdCBtYXR0ZXIgaWYgcGVvcGxl IGRvIG5vdCBhZ3JlZSBvbiB0aGUgcHJvYmxlbSBmaXJzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+V2hhdCBhcmUgdGhlIG11c3QtaGF2ZSwgc2hvdWxkLWhhdmUsIGFuZCBuaWNlLXRv LWhhdmUgZmVhdHVyZXMgdGhhdCBhcmUgbWlzc2luZyBmcm9tIFJGQyA1Mjc3PzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5FLmcuLCBpZiB3ZSBhZ3JlZSB0aGF0IGlzIGlzIGEgdGVycmli bGUgYnVyZGVuIG9uIHRoZSBjbGllbnQgdGhhdCAxIHNlc3Npb24gYmUgdXNlZCBmb3IgZWFjaCBz dWJzY3JpcHRpb24sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij50aGVu IG11bHRpcGxlIHN1YnNjcmlwdGlvbnMgcGVyIHNlc3Npb24gaXMgYW4gaW1wb3J0YW50IGZlYXR1 cmUuJm5ic3A7IEhvdyB0byBkbyB0aGF0IGlzIHRoZSBuZXh0IHN0ZXAsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5ub3QgdGhpcyBzdGVwLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TWVobWV0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5BbmR5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T24gTW9uLCBEZWMgNSwgMjAxNiBh dCAxMDozNSBQTSBNYXJ0aW4gQmpvcmtsdW5kICZsdDttYWlsdG86bWJqQHRhaWwtZi5jb20mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QW5keSBCaWVy bWFuICZsdDttYWlsdG86YW5keUB5dW1hd29ya3MuY29tJmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgT24gTW9uLCBEZWMgNSwgMjAxNiBhdCAx Mjo0OCBQTSwgTWFydGluIEJqb3JrbHVuZCAmbHQ7bWFpbHRvOm1iakB0YWlsLWYuY29tJmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBBbmR5IEJp ZXJtYW4gJmx0O21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgT24gTW9uLCBEZWMg NSwgMjAxNiBhdCAxMjozNyBQTSwgTWFydGluIEJqb3JrbHVuZCAmbHQ7bWFpbHRvOm1iakB0YWls LWYuY29tJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyAmZ3Q7ICZndDsgQW5keSBCaWVybWFuICZsdDttYWlsdG86YW5keUB5dW1hd29ya3MuY29tJmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyBIaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgcHJlZmVyIHRoZSBjdXJyZW50 IHNvbHV0aW9uIGFwcHJvYWNoLCB3aGljaCBpcyB0byB1c2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAnZXN0YWJsaXNoLXN1 YnNjcmlwdGlvbicuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IENhbiB5b3UgZWxhYm9yYXRlIG9uIHdoeSB5b3UgcHJlZmVyIHR3 byBvcGVyYXRpb25zIGluc3RlYWQgb2Ygb25lLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyB3aGVuIHRoZXkgZG8gdGhlIHNhbWUgdGhp bmc/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZn dDsgYmVjYXVzZSB0aGV5IGRvbid0IGRvIHRoZSBzYW1lIHRoaW5nLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgVGhlIG5ldyBzb2x1dGlvbiBo YXMgY29uZmlndXJlZCBmaWx0ZXJzLCBzdWJzY3JpcHRpb24taWQsIHN1c3BlbmQgYW5kPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyBjYW5jZWwg b3BlcmF0aW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgVGhl c2UgYXJlIHRyaXZpYWwgZXh0ZW5zaW9ucyB0byB0aGUgY3VycmVudCBzb2x1dGlvbi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IElmIHRoZXkgYXJlIHRydWx5IGRp ZmZlcmVudCB0aGUgbmFtZXMgc2hvdWxkIG5vdCBiZSBzbyBzaW1pbGFyLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyBhbmQgc2hvdWxkIG5vdCBuZWVkIHN0 cmVhbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBXaGF0IGRv IHlvdSBtZWFuICZxdW90O3Nob3VsZCBub3QgbmVlZCBzdHJlYW1zJnF1b3Q7PzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgVGhlIHN0cmVhbXMgY29uY2VwdCBpcyBoYWxmLWJha2VkIGFuZCBub3Qg dXNlZnVsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIHN0cm9uZ2x5IGRpc2FncmVl LiZuYnNwOyBUaGUgc3RyZWFtIGNvbmNlcHQgaW5jbHVkaW5nIHJlcGxheSBpcyB2ZXJ5PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5wb3dlcmZ1bC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+SWYgeW91IHRoaW5rIGl0IHNob3VsZCBiZSBkZXByZWNhdGVkIGFu ZCByZXBsYWNlZCB3aXRoIHNvbWV0aGluZyBlbHNlLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+SSB0aGluayB0aGF0IHJlcXVpcmVzIHNvbWUgY2FyZWZ1bCBkaXNjdXNz aW9uIGZpcnN0LiZuYnNwOyAoc3VjaCBhcyBhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5kZXNjcmlwdGlvbiBvZiBpdHMgcHJvYmxlbXMsIGFuZCBhIGRlc2NyaXB0aW9u IG9mIGEgbmV3IHNvbHV0aW9uKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBX ZSBoYXZlIDEgc3RyZWFtLCBORVRDT05GLCB3aGljaCBNVVNUIGNvbnRhaW4gZXZlcnl0aGluZzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5ObyBpdCBkb2Vzbid0LiZuYnNwOyBUaGlzIHdh cyBkaWN1c3NlZCByZWNlbnRseS4mbmJzcDsgVGhlIHRleHQgc2F5czo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7ICZuYnNwO1RoaXMgc3RyZWFtIGNvbnRhaW5zIGFsbCBORVRD T05GIFhNTCBldmVudCBub3RpZmljYXRpb25zIHN1cHBvcnRlZCBieTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7ICZuYnNwO3RoZSBORVRDT05GIHNlcnZlci48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Tm90ZSBpdCBzYXlzICZxdW90O2FsbCBORVRD T05GIFhNTCBldmVudCBub3RpZmljYXRpb25zJnF1b3Q7LCBub3QgJnF1b3Q7YWxsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5bWE1MXSBldmVudCBub3RpZmljYXRpb25z JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFuZDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBNVVNUIGJlIGVuY29kZWQgaW4gWE1M LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XZWxsLCBORVRDT05GIGlzIGVuY29kZWQg aW4gWE1MIHNvIHRoaXMgc2hvdWxkIG5vdCBjb21lIGFzIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPnN1cnByaXNlLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgRXZlcnkgb3RoZXIgc3RyZWFtIGlzIHB1cmVseSBhZC1ob2MgYW5kPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHByb3ByaWV0YXJ5PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPk5vdCByZWFsbHkuJm5ic3A7IEFsbCBzdHJlYW1zIHN1cHBv cnRlZCBjYW4gYmUgZGlzY292ZXJlZCBieSBhbnkgY2xpZW50PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4od2l0aCBwcm9wZXIgYWNjZXNzIHJpZ2h0cykuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgd2l0aCBubyBjaGFuY2UgYXQgaW50ZXJvcGVyYWJp bGl0eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBpcyBhIGZhbHNlIHN0YXRl bWVudC4mbmJzcDsgV2UgaGF2ZSBkZWZpbmVkIHNldmVyYWwgZGlmZmVyZW50IHN0cmVhbXM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnRoYXQgdGhpcmQgcGFydHkgY2xp ZW50cyB1c2Ugdy9vIGFueSBwcm9ibGVtcy4mbmJzcDsgSWYgYSBzdHJlYW0gZG9lc24ndDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+aW50ZXJvcGVyYXRlIGIvYyBvZiBp dHMgbmFtZSwgc29tZSBpbXBsZW1lbnRhdGlvbiBpcyBidWdneS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgVGhlIG9sZCBzb2x1dGlvbiBjYW4gYmUgZGVwcmVj YXRlZCBhbmQgcmVwbGFjZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyBTdXJlLCBpZiBpdCBpcyBicm9rZW4uJm5ic3A7IEJ1dCBJIGRvbid0IHRoaW5rIGl0IGlz IGJyb2tlbiBpbiBhbnkgd2F5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgJmx0O25vZml0 aWNhdGlvbiZndDsgZWxlbWVudCBpcyBjaGFuZ2luZyBzbyBvbGQgY2xpZW50cyBjYW5ub3Q8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZ2V0IHRoZSBuZXcgdmVy c2lvbiB0aGF0IGNvbnRhaW5zIGEgc3Vic2NyaXB0aW9uLWlkIGFuZCBvdGhlcjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBmaWVsZHMuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkkgaGF2ZW4ndCBzZWVuIGFueSBwcm9wb3NhbCBmb3IgZG9pbmcgdGhp cyBvbiB0aGUgTUwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSU1PIGl0IGlz IHNpbXBsZXIgYW5kIGNsZWFyZXIgaWYgdGhlIG5ldyBzb2x1dGlvbiBpcyBzZXBhcmF0ZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TWF5YmUuJm5ic3A7IEFueXdheSwgbXkgcG9zdCB3 YXMgcmVhbGx5IGluIHJlcGx5IHRvIEVyaWMncyBzdGF0ZW1lbnQgdGhhdDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+dGhlc2UgbmV3IGZlYXR1cmVzIGNvdWxkIG5vdCBi ZSBidWlsdCBvbiB0b3Agb2Ygd2hhdCB3ZSBoYXZlIGFuZCBzdGlsbDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+YmUgYmFja3dhcmRzIGNvbXBhdGlibGUuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPk9uZSB3YXkgb2YgbWFraW5nIHN0cmVhbXMgZXZlbiBtb3Jl IHVzZWZ1bCBpcyB0byBtYWtlIHRoZW08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPmNvbmZpZ3VyYWJsZSwgZS5nLiBpbnN0ZWFkIG9mIGNyZWF0aW5nIGNvbmZpZ3VyYWJs ZSBmaWx0ZXJzLCBhbiBpZGVhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5pcyB0byBjcmVhdGUgYSBuZXcgc3RyZWFtIHRvZ2V0aGVyIHdpdGggYSBmaWx0ZXIsIGFuZCBy ZXBsYXk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmRlZmluaXRpb24u Jm5ic3A7IEJlaW5nIGFibGUgdG8gZG8gdGhpcyBkeW5hbWljYWxseSB3b3VsZCBhY3R1YWxseSBi ZSBxdWl0ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+dXNlZnVsLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPi9tYXJ0aW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk5ldGNvbmYgbWFpbGluZyBsaXN0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5tYWlsdG86TmV0Y29uZkBpZXRmLm9y ZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4tLSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1laG1ldDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0gPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DaGVlcnMsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5NZWhtZXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_e9128f79b8bc4923815e40510678c026XCHRTP013ciscocom_-- From nobody Thu Dec 8 01:07:53 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E9D129692 for ; Thu, 8 Dec 2016 01:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 xQs_5fm1VHas for ; Thu, 8 Dec 2016 01:07:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C24C9124281 for ; Thu, 8 Dec 2016 01:07:49 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id B504B1AE0118; Thu, 8 Dec 2016 10:07:45 +0100 (CET) Date: Thu, 08 Dec 2016 10:07:45 +0100 (CET) Message-Id: <20161208.100745.1423954834248283961.mbj@tail-f.com> To: evoit@cisco.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 09:07:52 -0000 Hi, "Eric Voit (evoit)" wrote: > Here are some more cases. Happy to talk more or demo if people are interested. I think Andy summarized the issue nicely earlier in this thread: What are the must-have, should-have, and nice-to-have features that are missing from RFC 5277? I think your requirements below are more like driving forces for YANG push, right? Is there any of these that affects the solution in RFC 5277? > (Category 1) Streaming Telemetry > > High volume set of objects pushed on a predictable schedule. > > (1a) Telemetry: Fast replication of YANG operational/config data > off-box for traffic or configuration analysis > > (1b) Multi operations reporting: Send a targeted subset > operational/config data to an Operations group not directly managing > device > > (Category 2) Distributed Eventing > > No need to repeatedly poll to see if targeted subsets of Network > Element config have changed. The latest is pushed as it happens. > > (2a) Integrity Verification: Push discovered changes in keys, > config, software hash as they happen. Application validates that > change is authorized. > > (2b) Eliminate Polling: NMS/controllers pushed config changes as > they occur in Network Elements (enabling real-time state > synchronization). > > (2c) IWAN: Changes in Operational Data drive network rebalancing for > optimized enterprise facilities usage > > (2d) Domain Policer: provide a single policed data rate across > multiple data centers or branch offices > > (2e) DDoS Protection: send suspect spikes of traffic across a set > devices to a scrubber > > > > (Category 3) Network as the Subscriber > > Distributed CPE, VMs, routers can subscribe to a fast changing > centralized configuration repository > > (3a) Perimeter & Internal Blocking: When vulnerabilities are > detected, ephemeral remediation policies are temporarily installed > across a domain of devices. > > (3b) Tunnel Endpoint Synch: Filtered subsets of centrally managed > tunnel Ethernet endpoints can be downloaded and coordinated across > edge devices to minimize effort in maintaining dynamic mesh > > (3c) Policy mirroring: Enables trusted or partially-trusted edge > devices to mirror the state of a central configuration repository /martin From nobody Thu Dec 8 01:16:46 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883D4129695 for ; Thu, 8 Dec 2016 01:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 TVEXIIw-hVG7 for ; Thu, 8 Dec 2016 01:16:43 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 989B91293E4 for ; Thu, 8 Dec 2016 01:16:43 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id D7BF11AE0118; Thu, 8 Dec 2016 10:16:42 +0100 (CET) Date: Thu, 08 Dec 2016 10:16:42 +0100 (CET) Message-Id: <20161208.101642.116190273525034135.mbj@tail-f.com> To: mersue@gmail.com From: Martin Bjorklund In-Reply-To: References: <20161207.091950.293357531482191030.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] new NACM draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 09:16:45 -0000 MehmetErsue wrote: > Hi Martin, All, > > we discussed the listed issues in IETF 97 very roughly. The request from > IETF 97 was to have a discussion on the issues and understand better > whether they should be included. > We don't need to solve them before adoption. Ok. > > > - the issue from RFC 6536 with parent/child relationships which is > > > important for RESTCONF. > > > > Can you elaborate on this? > > IIRC the question was on whether a client with read access to a target node > also has read access to the ancestor nodes in order to be able to read the > target node's data. Ok. This issue is already fixed in the recently published draft-bierman-netconf-rfc6536bis-01. > @All: We would like to get comments/opinions on to whether the listed > issues should be covered in 6536bis. > > > > - schema-mount related text into schema-mount or the NACM draft, > > > - assigning priorities to clients, > > > - access control on dynamic datastores (e.g. I2RS), > > > - the issue from RFC 6536 with parent/child relationships which is > important for RESTCONF. /martin > > BR, > Mehmet > > On Wed, Dec 7, 2016 at 9:19 AM Martin Bjorklund wrote: > > > MehmetErsue wrote: > > > Hi Andy, Martin, > > > > > > thank you for the initial draft. > > > > > > We discussed in IETF 97 different issues and the additional sections we > > > could add. > > > > Ok. But do we have to resolve all issues before adopting this > > document? I think the current document is ready for adoption, and > > then the WG can work on fixing any open issues. > > > > > IIRC the list was: > > > - schema-mount related text into schema-mount or the NACM draft, > > > > I think schema mount needs to discuss how it works with NACM. This > > should be an open issue in schema mount. > > > > > - assigning priorities to clients, > > > > I don't believe this is a NACM issue. > > > > > - access control on dynamic datastores (e.g. I2RS), > > > > The text in 3.2 probably need to be relaxed a bit to allow NACM to be > > applied to other datastores. > > > > > - the issue from RFC 6536 with parent/child relationships which is > > > important for RESTCONF. > > > > Can you elaborate on this? > > > > > > /martin > > > > > > > > > > > > I would like to suggest to have a discussion on these issues and > > understand > > > whether they should be included. > > > > > > Mehmet > > > > > > On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman > > wrote: > > > > > > > Hi, > > > > > > > > A new version of draft-bierman-netconf-rfc6536bis has been posted: > > > > https://www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt > > > > > > > > > > > > We would like this draft to be adopted as the starting point for item > > #5 > > > > in the current NETCONF charter. > > > > > > > > > > > > > > > > Andy and Martin > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > > > > > > -- > > > Cheers, > > > Mehmet > > > -- > Cheers, > Mehmet From nobody Thu Dec 8 07:01:16 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB393129A35 for ; Thu, 8 Dec 2016 07:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 cayUwXs4Gbsq for ; Thu, 8 Dec 2016 07:01:08 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17ED1299CB for ; Thu, 8 Dec 2016 06:52:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3475; q=dns/txt; s=iport; t=1481208724; x=1482418324; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AN/UV7laPLYQumQbrgfrQvfmVxLa90dMd5VRx8p7r6c=; b=Fihv2IxNM7+J6iS+vym5ZL6LtST7sFy+dwnaMZVP8mv3uws4g7qUI+jz ZjIhw05mRCsa1LK88T4ifHzE/YWYoWIgWUNwRQWV0CFUlwOZwk+2jPW+Z HjgWHEmOS0Oxmpu1KJvpTFdymsjP322Kke0HWkqZNC4PhdD9Y7HzMdWeS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQAic0lY/4wNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAR+BZ41DlxOVAYIIgmuDNgKBcz8UAQIBAQEBAQEBYiiEaAE?= =?us-ascii?q?BAQMBOj8FCwIBCA4HDwEREDIlAgQODRECiEgIqleLPgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GPoRbiikFmmoBkRWQSo4IhA0BHzeBGYNcHYFdhmcCJAQDgQOBDQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.33,320,1477958400"; d="scan'208";a="358342869" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2016 14:52:04 +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 uB8Eq3iu018261 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Dec 2016 14:52:04 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 8 Dec 2016 09:52:03 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 8 Dec 2016 09:52:03 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund Thread-Topic: [Netconf] Subscription Use Cases Thread-Index: AQHSUTKNz0LSmZX5b0GYyl1Cgj0Ou6D+G3xg Date: Thu, 8 Dec 2016 14:52:02 +0000 Message-ID: References: <20161208.100745.1423954834248283961.mbj@tail-f.com> In-Reply-To: <20161208.100745.1423954834248283961.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 15:01:15 -0000 Hi Martin, > From: Martin Bjorklund, December 8, 2016 4:08 AM >=20 > I think your requirements below are more like driving forces for YANG pus= h, > right? Is there any of these that affects the solution in RFC 5277? The majority of these cases need yang-push. But yang push is only possibl= e when the information is yang modeled. And in some of these cases, not al= l the information is yang modeled on a platform. (As much as I wish it wer= e.) I have indicated a few places where this is the case in-line. Beyond the original cases I sent, there are other use cases where there are= notifications will not be YANG modeled.=20 (Category 4) Control Plane Notifications (4a) First-sign-of-life on new CPE. In this case you need to figure out w= hat to do when a new CPE appears on an access link. For example, a policy = determination needs to be made on what security treatment it needs. This n= otification could be done via NETCONF. And the request could come from the= same controller subscribing to traditional NETCONF notifications. In the end, more and more stuff will be yang modeled on the device. That i= s one reason I like your alarm-yang-module. Approaches like the alarm will= allow more robust yang-push mechanisms to be used over event notifications= . But we won't be there for a while. > > (Category 1) Streaming Telemetry > > > > High volume set of objects pushed on a predictable schedule. > > > > (1a) Telemetry: Fast replication of YANG operational/config data > > off-box for traffic or configuration analysis > > > > (1b) Multi operations reporting: Send a targeted subset > > operational/config data to an Operations group not directly managing > > device > > > > (Category 2) Distributed Eventing > > > > No need to repeatedly poll to see if targeted subsets of Network > > Element config have changed. The latest is pushed as it happens. > > > > (2a) Integrity Verification: Push discovered changes in keys, config, > > software hash as they happen. Application validates that change is > > authorized. Not all the needed info here is yang modeled. > > (2b) Eliminate Polling: NMS/controllers pushed config changes as they > > occur in Network Elements (enabling real-time state synchronization). > > > > (2c) IWAN: Changes in Operational Data drive network rebalancing for > > optimized enterprise facilities usage > > > > (2d) Domain Policer: provide a single policed data rate across > > multiple data centers or branch offices > > > > (2e) DDoS Protection: send suspect spikes of traffic across a set > > devices to a scrubber Not all the needed info here is yang modeled. > > > > (Category 3) Network as the Subscriber > > > > Distributed CPE, VMs, routers can subscribe to a fast changing > > centralized configuration repository > > > > (3a) Perimeter & Internal Blocking: When vulnerabilities are detected, > > ephemeral remediation policies are temporarily installed across a > > domain of devices. > > > > (3b) Tunnel Endpoint Synch: Filtered subsets of centrally managed > > tunnel Ethernet endpoints can be downloaded and coordinated across > > edge devices to minimize effort in maintaining dynamic mesh Not all the needed info here is yang modeled. Eric > > (3c) Policy mirroring: Enables trusted or partially-trusted edge > > devices to mirror the state of a central configuration repository >=20 >=20 > /martin From nobody Thu Dec 8 08:48:37 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8821294F4 for ; Thu, 8 Dec 2016 08:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 G5DpnL8saQDP for ; Thu, 8 Dec 2016 08:48:33 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D2F1293D9 for ; Thu, 8 Dec 2016 08:48:33 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 98F4711C1 for ; Thu, 8 Dec 2016 17:48:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Mx9v-FhYW5v3 for ; Thu, 8 Dec 2016 17:48:28 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 8 Dec 2016 17:48:31 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2382E20069 for ; Thu, 8 Dec 2016 17:48:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lpKaMWezyW2N; Thu, 8 Dec 2016 17:48:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC23320067; Thu, 8 Dec 2016 17:48:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9CB303DAF49B; Thu, 8 Dec 2016 17:48:30 +0100 (CET) Date: Thu, 8 Dec 2016 17:48:30 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20161208164830.GB91424@elstar.local> Mail-Followup-To: netconf@ietf.org References: <20161208164203.94881B80232@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161208164203.94881B80232@rfc-editor.org> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [Netconf] RFC 8030 on Generic Event Delivery Using HTTP Push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 16:48:36 -0000 Hi, this may be relevant for some of the discussions here. /js On Thu, Dec 08, 2016 at 08:42:03AM -0800, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 8030 > > Title: Generic Event Delivery Using HTTP Push > Author: M. Thomson, > E. Damaggio, > B. Raymor, Ed. > Status: Standards Track > Stream: IETF > Date: December 2016 > Mailbox: martin.thomson@gmail.com, > elioda@microsoft.com, > brian.raymor@microsoft.com > Pages: 31 > Characters: 68069 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-webpush-protocol-12.txt > > URL: https://www.rfc-editor.org/info/rfc8030 > > DOI: 10.17487/RFC8030 > > This document describes a simple protocol for the delivery of real- > time events to user agents. This scheme uses HTTP/2 server push. > > This document is a product of the Web-Based Push Notifications Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > -- 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 Dec 8 09:46:48 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2FD12951C for ; Thu, 8 Dec 2016 09:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLwrtK9sevdq for ; Thu, 8 Dec 2016 09:46:43 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6231294EF for ; Thu, 8 Dec 2016 09:46:43 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id q130so269194684qke.1 for ; Thu, 08 Dec 2016 09:46:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fZTGqgrMMLV5bsKdPbhkS90b8d8kYiaB2EUWnQPLJZ4=; b=GQQb8tCerLJp7h0cYzzPp9JQhFXpTq3XJUFWg+9XH+PCnbmgwOZk/XPnX/A307Fp0U riHG11PHA3dUHyhlFRC33CIkR+c370ZHjCgIcQoyojP0R/PEoJ6yRjR7ZkvHjoNkb87m g9dYXZj8OkscsxG+3T/6zPEJBO9sFXGS2eBa64k04QPjel3AGLxHwe0bPFXI7S8K9hME 0gZidW885UOmxbkuzXQHI90uQruoaqZlkc7afL6G9S8N0mZTAxBiUX94I7W0o2Ti1fCQ AJLqsJF2BGJgv2JxBxV+5jxoSxVuj0vx3eYKGzDUEzqlotylwg6znHcZjbXieD0fXz5v 3ltQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fZTGqgrMMLV5bsKdPbhkS90b8d8kYiaB2EUWnQPLJZ4=; b=LeRM8NuW1+edW14bVGNdY3Zbz5+rIWYvyQRKb7J6CrPWIP5ZUnf1kJVI6W5cCJJN8J JrEAQ68mkuXR5KRqYBDPsl6/OllgqUXlxZE2ECoVMlYNTgAjWvvKKuQiWByv4UlhiQ4D qzdukpeC6lQtx4E4BWKQwR4fwKz2mzuytyjzM+nwtWwNFewH1PxXh9JwGpqsIgxERpWR 2dj8mwgnTdGI6SUCsWwlncA5XlfT1ujNRp4Kzp5p9nwYvAZ258JwfMBuon3M9zG+iAHE s3lIHmaMVzh/deqc77t+CJklST+Nzo1kI1NVvPmwrTnZlGlAA5e09Tc/mym4YTA2NdQg PmDA== X-Gm-Message-State: AKaTC03n5Udylo8osXdIueLNPD3/IVwBh3t+1Jb33Ibbof7SV+E+Cc9Sg2f6dw2kQpBuag598MmW0Ax2GbnKiw== X-Received: by 10.55.76.150 with SMTP id z144mr62759518qka.194.1481219202338; Thu, 08 Dec 2016 09:46:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Thu, 8 Dec 2016 09:46:41 -0800 (PST) In-Reply-To: References: <20161208.100745.1423954834248283961.mbj@tail-f.com> From: Andy Bierman Date: Thu, 8 Dec 2016 09:46:41 -0800 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a114a886864894c05432938e7 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 17:46:46 -0000 --001a114a886864894c05432938e7 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 8, 2016 at 6:52 AM, Eric Voit (evoit) wrote: > Hi Martin, > > > From: Martin Bjorklund, December 8, 2016 4:08 AM > > > > I think your requirements below are more like driving forces for YANG > push, > > right? Is there any of these that affects the solution in RFC 5277? > > The majority of these cases need yang-push. But yang push is only > possible when the information is yang modeled. And in some of these cases, > not all the information is yang modeled on a platform. (As much as I wish > it were.) I have indicated a few places where this is the case in-line. > > Beyond the original cases I sent, there are other use cases where there > are notifications will not be YANG modeled. > > (Category 4) Control Plane Notifications > > (4a) First-sign-of-life on new CPE. In this case you need to figure out > what to do when a new CPE appears on an access link. For example, a policy > determination needs to be made on what security treatment it needs. This > notification could be done via NETCONF. And the request could come from > the same controller subscribing to traditional NETCONF notifications. > > In the end, more and more stuff will be yang modeled on the device. That > is one reason I like your alarm-yang-module. Approaches like the alarm > will allow more robust yang-push mechanisms to be used over event > notifications. But we won't be there for a while. > > What is the control plane protocol? Seems to me you are confusing implementation details with control plane notifications. In this context, only a notification that is defined to be consumed by the notification delivery system and never needs to be seen by the subscriber would qualify. The "5277 layer" provides the subscription control. It also interfaces to the transport layer. IMO we need to support a small number (2) of standard transports 1) NETCONF elements 2) RESTCONF SSE data stream Lots of optional components make the solution worse. It's like the JSON vs. XML issue in RESTCONF. It's nice for the server developer to pick 1 of N options, but that means the client developer has to implement all options to work with all servers. I agree with Martin that create-subscription and establish-subscription are not both needed. Pick 1. IMO there is no need for configured subscriptions because Call-home can be used instead. Configurable filters (in the current drafts) are not very reusable so I don't see much value in the ability to specify 1 filter (either inline or pre-configured). IMO there is significant customer interest in YANG Push but not for anything else in this document set. The WG needs to focus on the requirements for YANG Push and only change the lower layers if they are really broken. Andy > > (Category 1) Streaming Telemetry > > > > > > High volume set of objects pushed on a predictable schedule. > > > > > > (1a) Telemetry: Fast replication of YANG operational/config data > > > off-box for traffic or configuration analysis > > > > > > (1b) Multi operations reporting: Send a targeted subset > > > operational/config data to an Operations group not directly managing > > > device > > > > > > (Category 2) Distributed Eventing > > > > > > No need to repeatedly poll to see if targeted subsets of Network > > > Element config have changed. The latest is pushed as it happens. > > > > > > (2a) Integrity Verification: Push discovered changes in keys, config, > > > software hash as they happen. Application validates that change is > > > authorized. > > Not all the needed info here is yang modeled. > > > > (2b) Eliminate Polling: NMS/controllers pushed config changes as they > > > occur in Network Elements (enabling real-time state synchronization). > > > > > > (2c) IWAN: Changes in Operational Data drive network rebalancing for > > > optimized enterprise facilities usage > > > > > > (2d) Domain Policer: provide a single policed data rate across > > > multiple data centers or branch offices > > > > > > (2e) DDoS Protection: send suspect spikes of traffic across a set > > > devices to a scrubber > > Not all the needed info here is yang modeled. > > > > > > > (Category 3) Network as the Subscriber > > > > > > Distributed CPE, VMs, routers can subscribe to a fast changing > > > centralized configuration repository > > > > > > (3a) Perimeter & Internal Blocking: When vulnerabilities are detected, > > > ephemeral remediation policies are temporarily installed across a > > > domain of devices. > > > > > > (3b) Tunnel Endpoint Synch: Filtered subsets of centrally managed > > > tunnel Ethernet endpoints can be downloaded and coordinated across > > > edge devices to minimize effort in maintaining dynamic mesh > > Not all the needed info here is yang modeled. > > Eric > > > > (3c) Policy mirroring: Enables trusted or partially-trusted edge > > > devices to mirror the state of a central configuration repository > > > > > > /martin > --001a114a886864894c05432938e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 8, 2016 at 6:52 AM, Eric Voit (evoit) <= ;evoit@cisco.com&g= t; wrote:
Hi Martin,

> From: Martin Bjorklund, December 8, 2016 4:08 AM
>
> I think your requirements below are more like driving forces for YANG = push,
> right?=C2=A0 Is there any of these that affects the solution in RFC 52= 77?

The majority of these cases need yang-push.=C2=A0 =C2=A0But yang push is on= ly possible when the information is yang modeled.=C2=A0 And in some of thes= e cases, not all the information is yang modeled on a platform.=C2=A0 (As m= uch as I wish it were.)=C2=A0 I have indicated a few places where this is t= he case in-line.

Beyond the original cases I sent, there are other use cases where there are= notifications will not be YANG modeled.

(Category 4) Control Plane Notifications

(4a) First-sign-of-life on new CPE.=C2=A0 =C2=A0In this case you need to fi= gure out what to do when a new CPE appears on an access link.=C2=A0 For exa= mple, a policy determination needs to be made on what security treatment it= needs.=C2=A0 This notification could be done via NETCONF.=C2=A0 And the re= quest could come from the same controller subscribing to traditional NETCON= F notifications.

In the end, more and more stuff will be yang modeled on the device.=C2=A0 T= hat is one reason I like your alarm-yang-module.=C2=A0 Approaches like the = alarm will allow more robust yang-push mechanisms to be used over event not= ifications.=C2=A0 But we won't be there for a while.




What is = the control plane protocol?
Seems to me you are confusing impleme= ntation details with control plane notifications.
In this context= , only a notification that is defined to be consumed by the
notif= ication delivery system and never needs to be seen by the subscriber
<= div>would qualify.

The "5277 layer" prov= ides the subscription control.
It also interfaces to the transpor= t layer.
IMO we need to support a small number (2) of standard tr= ansports
=C2=A0 1) NETCONF <notification> elements
=C2=A0 2) RESTCONF SSE data stream

Lots of optio= nal components make the solution worse.
It's like the JSON vs= . XML issue in RESTCONF.
It's nice for the server developer t= o pick 1 of N options, but that means
the client developer has to= implement all options to work with all servers.

I= agree with Martin that create-subscription and establish-subscription
are not both needed.=C2=A0 Pick 1.

IMO there= is no need for configured subscriptions because Call-home can be
used instead.=C2=A0

Configurable filters (in the = current drafts) are not very reusable so I don't see much
val= ue in the ability to specify 1 filter (either inline or pre-configured).

IMO there is significant customer interest in YANG P= ush but not for
anything else in this document set.=C2=A0 The WG = needs to focus on the
requirements for YANG Push and only change = the lower layers if they are really broken.


Andy



> > (Category 1) Streaming Telemetry
> >
> > High volume set of objects pushed on a predictable schedule.
> >
> > (1a) Telemetry: Fast replication of YANG operational/config data<= br> > > off-box for traffic or configuration analysis
> >
> > (1b) Multi operations reporting: Send a targeted subset
> > operational/config data to an Operations group not directly manag= ing
> > device
> >
> > (Category 2) Distributed Eventing
> >
> > No need to repeatedly poll to see if targeted subsets of Network<= br> > > Element config have changed. The latest is pushed as it happens.<= br> > >
> > (2a) Integrity Verification: Push discovered changes in keys, con= fig,
> > software hash as they happen.=C2=A0 Application validates that ch= ange is
> > authorized.

Not all the needed info here is yang modeled.

> > (2b) Eliminate Polling: NMS/controllers pushed config changes as = they
> > occur in Network Elements (enabling real-time state synchronizati= on).
> >
> > (2c) IWAN: Changes in Operational Data drive network rebalancing = for
> > optimized enterprise facilities usage
> >
> > (2d) Domain Policer: provide a single policed data rate across > > multiple data centers or branch offices
> >
> > (2e) DDoS Protection: send suspect spikes of traffic across a set=
> > devices to a scrubber

Not all the needed info here is yang modeled.

> >
> > (Category 3) Network as the Subscriber
> >
> > Distributed CPE, VMs, routers can subscribe to a fast changing > > centralized configuration repository
> >
> > (3a) Perimeter & Internal Blocking: When vulnerabilities are = detected,
> > ephemeral remediation policies are temporarily installed across a=
> > domain of devices.
> >
> > (3b) Tunnel Endpoint Synch: Filtered subsets of centrally managed=
> > tunnel Ethernet endpoints can be downloaded and coordinated acros= s
> > edge devices to minimize effort in maintaining dynamic mesh

Not all the needed info here is yang modeled.

Eric

> > (3c) Policy mirroring: Enables trusted or partially-trusted edge<= br> > > devices to mirror the state of a central configuration repository=
>
>
> /martin

--001a114a886864894c05432938e7-- From nobody Thu Dec 8 12:41:20 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846A3129575 for ; Thu, 8 Dec 2016 12:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh2aC-jr9X0S for ; Thu, 8 Dec 2016 12:41:17 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE71C129541 for ; Thu, 8 Dec 2016 12:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3945; q=dns/txt; s=iport; t=1481229676; x=1482439276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jOdAj83SE5rdetezFi1BCF2uh5i8xn+B6brTX5fpiz8=; b=C4heiftuKbtGEHqaPwid+VA6r8ZOK66UzY/EHI9BROJ4SiCAJRl8W4hi squtVJm1HglrHBQQISradO019N36hJaStyIZ5++bwJssKSPujWuX9LBZH /dyN2Yw84mhcbGgXN7lUitn/NnL9DNu/z6Fs8/floGQW0QkxQWJdBZy98 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQAXxElY/5pdJa1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQEfWoEGB41DlxOHdY0MgggeC4UuSgKBej8UAQIBAQE?= =?us-ascii?q?BAQEBYiiEaAEBAQMBAQE4FCALBQkCAgEIDgIEAQMMAREQGwYGCgElAgQOBQgMB?= =?us-ascii?q?wIEiDADDwgOqUmHPg2DZAEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FhjmEW4E9gQu?= =?us-ascii?q?BYQUENyaFGgWaNTUBhk6DCgyDVoNbgXyEfYlRh2WBboQ1hA0BHzeBGRQPhTNyh?= =?us-ascii?q?gSBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,321,1477958400"; d="scan'208";a="358491681" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2016 20:41:15 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uB8KfFbg019420 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Dec 2016 20:41:15 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 8 Dec 2016 15:41:14 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 8 Dec 2016 15:41:14 -0500 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder Thread-Topic: [Netconf] RFC 8030 on Generic Event Delivery Using HTTP Push Thread-Index: AQHSUXLztc76XEU1XEiH8L24gHUkmaD+a4GQ Date: Thu, 8 Dec 2016 20:41:14 +0000 Message-ID: <72371edbd9db4d57826acad656c35788@XCH-RTP-013.cisco.com> References: <20161208164203.94881B80232@rfc-editor.org> <20161208164830.GB91424@elstar.local> In-Reply-To: <20161208164830.GB91424@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] RFC 8030 on Generic Event Delivery Using HTTP Push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 20:41:18 -0000 Thanks for the pointer Juergen, The RFC does support common functional requirements such as: - DDoS protection method for HTTP2 - Prioritized messages - many subscriptions per transport session=20 - others But there were several reasons it doesn't match sufficiently for reuse with= yang data stores. Some deltas between the environments include: - Push Service as a Subscriber proxy, with caching and possible push update= aggregation (intended to save radio power) - multiple resource targets within a single subscription - configured subscription support - content/event filtering - yang - event dampening, on-change, and periodic - Use of GET to subscription resource (GRPC compatibility) - negotiation Therefore I see this as a useful reference and context rather than somethin= g normative that we can build upon. We shouldn't forget this though as there are also items we might want to ad= opt at some future point: - the Subscriber proxy model - push update TTL - tracked acknowledgement of push updates Eric > From: Juergen Schoenwaelder, December 8, 2016 11:49 AM >=20 > Hi, >=20 > this may be relevant for some of the discussions here. >=20 > /js >=20 > On Thu, Dec 08, 2016 at 08:42:03AM -0800, rfc-editor@rfc-editor.org wrote= : > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 8030 > > > > Title: Generic Event Delivery Using HTTP Push > > Author: M. Thomson, > > E. Damaggio, > > B. Raymor, Ed. > > Status: Standards Track > > Stream: IETF > > Date: December 2016 > > Mailbox: martin.thomson@gmail.com, > > elioda@microsoft.com, > > brian.raymor@microsoft.com > > Pages: 31 > > Characters: 68069 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-ietf-webpush-protocol-12.txt > > > > URL: https://www.rfc-editor.org/info/rfc8030 > > > > DOI: 10.17487/RFC8030 > > > > This document describes a simple protocol for the delivery of real- > > time events to user agents. This scheme uses HTTP/2 server push. > > > > This document is a product of the Web-Based Push Notifications Working > Group of the IETF. > > > > This is now a Proposed Standard. > > > > STANDARDS TRACK: This document specifies an Internet Standards Track > > protocol for the Internet community, and requests discussion and > > suggestions for improvements. Please refer to the current edition of > > the Official Internet Protocol Standards > > (https://www.rfc-editor.org/standards) for the standardization state > > and status of this protocol. Distribution of this memo is unlimited. > > > > This announcement is sent to the IETF-Announce and rfc-dist lists. > > To subscribe or unsubscribe, see > > https://www.ietf.org/mailman/listinfo/ietf-announce > > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > > > For searching the RFC series, see https://www.rfc-editor.org/search > > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > > > Requests for special distribution should be addressed to either the > > author of the RFC in question, or to rfc-editor@rfc-editor.org. > > Unless specifically noted otherwise on the RFC itself, all RFCs are > > for unlimited distribution. > > > > > > The RFC Editor Team > > Association Management Solutions, LLC > > > > >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Dec 8 14:29:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B76129B3C for ; Thu, 8 Dec 2016 14:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urgAfc5ozjer for ; Thu, 8 Dec 2016 14:29:50 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49D7129B0D for ; Thu, 8 Dec 2016 14:27:58 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id x190so370217qkb.0 for ; Thu, 08 Dec 2016 14:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H4AcqAajSCr/KHR0SzwYqpgPd2q24YdP+iPsoV8H0yY=; b=eplpSlycpHXT5pwzRJ2/bUwxQ+ijZGH4Iw2mrTCDQDm+lVTBeSZ8k3VE4HCzHICMcs wTzufdPKSc5JjCiXWFYEjXWuzHaYsotBhxCNnIqUvcujwRHPM6a3pIJw9QvU1+ftRXfX aEJOF2fYSlFD0rTTL+SVyiOo5u2DXW9Du+45CLLTIXKjBC798KSCDd5buDs/LSbVjjBx RoVSlwp9fM8rCe7CxkRU+0545hoHqxeVbBnRjdlmxwAgGByb0rvz2AkM5x8PlC9Ozdx1 cxk9jcRh5FFgP14YeOUQx+lhYnx6d2Y6oyrm1vs13e/PZHiTzvD/KN/NJD1InVaxAQeu FS2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H4AcqAajSCr/KHR0SzwYqpgPd2q24YdP+iPsoV8H0yY=; b=N4c2EbBLN7GCjzecKgqQF6SszqhEjuMtwgxp8IuQlPHoIt9TdzGFyWwaY2at1Olj1V 0eLWGB912QkURLE3fnJrzH/f+iDuXOqBMT2EW1V13cDoeCmt5a4q6N7pRyqoALNsG5PX OaTRCl/ASMKlRypri1juPZSq57sh2vmZHD2qQnMY9/7WE3OkAVKgl7Abs3rTKxBsWxx6 eihE6ljswouAWK5144YjHAJ51A6E9vaPKXfMAn2u20vQuNUnkyKZUctsCX2D4z+XEza0 9LpWMtB9YNyl67lRF4cx25KPdOtVSdUf3KSurmeIUg+qRtHJ3kRvHmFhCqLrY/m+lA/u 9Trg== X-Gm-Message-State: AKaTC02b/onTT/V44HZBMetgp/A3Rq2VKb4+CJy+SOqWG9oQDHy9oWnzZTGhiCfCfyikxhfLdZiC19/NOzCncQ== X-Received: by 10.55.118.3 with SMTP id r3mr13204210qkc.84.1481236077800; Thu, 08 Dec 2016 14:27:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Thu, 8 Dec 2016 14:27:57 -0800 (PST) In-Reply-To: <72371edbd9db4d57826acad656c35788@XCH-RTP-013.cisco.com> References: <20161208164203.94881B80232@rfc-editor.org> <20161208164830.GB91424@elstar.local> <72371edbd9db4d57826acad656c35788@XCH-RTP-013.cisco.com> From: Andy Bierman Date: Thu, 8 Dec 2016 14:27:57 -0800 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=94eb2c0626283f0aba05432d26ad Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] RFC 8030 on Generic Event Delivery Using HTTP Push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 22:29:53 -0000 --94eb2c0626283f0aba05432d26ad Content-Type: text/plain; charset=UTF-8 On Thu, Dec 8, 2016 at 12:41 PM, Eric Voit (evoit) wrote: > Thanks for the pointer Juergen, > > The RFC does support common functional requirements such as: > - DDoS protection method for HTTP2 > - Prioritized messages > - many subscriptions per transport session > - others > > But there were several reasons it doesn't match sufficiently for reuse > with yang data stores. Some deltas between the environments include: > - Push Service as a Subscriber proxy, with caching and possible push > update aggregation (intended to save radio power) > - multiple resource targets within a single subscription > - configured subscription support > - content/event filtering > - yang > - event dampening, on-change, and periodic > - Use of GET to subscription resource (GRPC compatibility) > - negotiation > > Therefore I see this as a useful reference and context rather than > something normative that we can build upon. > > I don't agree that all these things are needed or they cannot be done as part of the application. Not sure what YANG support means either. This does not seem to affect the bytes on the wire. I prefer to separate the protocol layers. The part that selects what events to send and other optimizations related to content selection should not be coupled to how notifications are delivered. We shouldn't forget this though as there are also items we might want to > adopt at some future point: > - the Subscriber proxy model > - push update TTL > - tracked acknowledgement of push updates > > Eric > > Andy > > From: Juergen Schoenwaelder, December 8, 2016 11:49 AM > > > > Hi, > > > > this may be relevant for some of the discussions here. > > > > /js > > > > On Thu, Dec 08, 2016 at 08:42:03AM -0800, rfc-editor@rfc-editor.org > wrote: > > > A new Request for Comments is now available in online RFC libraries. > > > > > > > > > RFC 8030 > > > > > > Title: Generic Event Delivery Using HTTP Push > > > Author: M. Thomson, > > > E. Damaggio, > > > B. Raymor, Ed. > > > Status: Standards Track > > > Stream: IETF > > > Date: December 2016 > > > Mailbox: martin.thomson@gmail.com, > > > elioda@microsoft.com, > > > brian.raymor@microsoft.com > > > Pages: 31 > > > Characters: 68069 > > > Updates/Obsoletes/SeeAlso: None > > > > > > I-D Tag: draft-ietf-webpush-protocol-12.txt > > > > > > URL: https://www.rfc-editor.org/info/rfc8030 > > > > > > DOI: 10.17487/RFC8030 > > > > > > This document describes a simple protocol for the delivery of real- > > > time events to user agents. This scheme uses HTTP/2 server push. > > > > > > This document is a product of the Web-Based Push Notifications Working > > Group of the IETF. > > > > > > This is now a Proposed Standard. > > > > > > STANDARDS TRACK: This document specifies an Internet Standards Track > > > protocol for the Internet community, and requests discussion and > > > suggestions for improvements. Please refer to the current edition of > > > the Official Internet Protocol Standards > > > (https://www.rfc-editor.org/standards) for the standardization state > > > and status of this protocol. Distribution of this memo is unlimited. > > > > > > This announcement is sent to the IETF-Announce and rfc-dist lists. > > > To subscribe or unsubscribe, see > > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > > > > > For searching the RFC series, see https://www.rfc-editor.org/search > > > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > > > > > Requests for special distribution should be addressed to either the > > > author of the RFC in question, or to rfc-editor@rfc-editor.org. > > > Unless specifically noted otherwise on the RFC itself, all RFCs are > > > for unlimited distribution. > > > > > > > > > The RFC Editor Team > > > Association Management Solutions, LLC > > > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --94eb2c0626283f0aba05432d26ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 8, 2016 at 12:41 PM, Eric Voit (evoit) &l= t;evoit@cisco.com&= gt; wrote:
Thanks for the pointer = Juergen,

The RFC does support common functional requirements such as:
- DDoS protection method for HTTP2
- Prioritized messages
- many subscriptions per transport session
- others

But there were several reasons it doesn't match sufficiently for reuse = with yang data stores.=C2=A0 Some deltas between the environments include:<= br> - Push Service as a Subscriber proxy, with caching and possible push update= aggregation (intended to save radio power)
- multiple resource targets within a single subscription
- configured subscription support
- content/event filtering
- yang
- event dampening, on-change, and periodic
- Use of GET to subscription resource (GRPC compatibility)
- negotiation

Therefore I see this as a useful reference and context rather than somethin= g normative that we can build upon.



I don't agree that = all these things are needed or they cannot be done as part of the applicati= on.
Not sure what YANG support means either.=C2=A0 This does not = seem to affect the bytes on the wire.

I prefer to = separate the protocol layers.=C2=A0 The part that selects what events to se= nd and
other optimizations related to content selection should no= t be coupled to how notifications
are delivered.=C2=A0
=


We shouldn't forget this though as there are also items we might want t= o adopt at some future point:
- the Subscriber proxy model
- push update TTL
- tracked acknowledgement of push updates

Eric



Andy
=C2=A0
> From: Juergen Schoenwaelder, December 8, 2016 11:49 AM
>
> Hi,
>
> this may be relevant for some of the discussions here.
>
> /js
>
> On Thu, Dec 08, 2016 at 08:42:03AM -0800, rfc-editor@rfc-editor.org wrote:
> > A new Request for Comments is now available in online RFC librari= es.
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 8030
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2=A0 Gener= ic Event Delivery Using HTTP Push
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author:=C2=A0 =C2=A0 =C2=A0M. Th= omson,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0E. Damaggio,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0B. Raymor, Ed.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status:=C2=A0 =C2=A0 =C2=A0Stand= ards Track
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stream:=C2=A0 =C2=A0 =C2=A0IETF<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0= December 2016
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mailbox:=C2=A0 =C2=A0 martin.thomson@gmail.com,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0elioda@microsoft.com,=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0brian.raymor@micros= oft.com
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2=A0 31 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Characters: 68069
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Updates/Obsoletes/SeeAlso:=C2=A0= =C2=A0None
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I-D Tag:=C2=A0 =C2=A0 draft-ietf= -webpush-protocol-12.txt
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = https://www.rfc-editor.org/info/rfc8030
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = 10.17487/RFC8030
> >
> > This document describes a simple protocol for the delivery of rea= l-
> > time events to user agents.=C2=A0 This scheme uses HTTP/2 server = push.
> >
> > This document is a product of the Web-Based Push Notifications Wo= rking
> Group of the IETF.
> >
> > This is now a Proposed Standard.
> >
> > STANDARDS TRACK: This document specifies an Internet Standards Tr= ack
> > protocol for the Internet community, and requests discussion and<= br> > > suggestions for improvements.=C2=A0 Please refer to the current e= dition of
> > the Official Internet Protocol Standards
> > (https://www.rfc-editor.org/standards) for th= e standardization state
> > and status of this protocol.=C2=A0 Distribution of this memo is u= nlimited.
> >
> > This announcement is sent to the IETF-Announce and rfc-dist lists= .
> > To subscribe or unsubscribe, see
> >=C2=A0 =C2=A0https://www.ietf.org/mailma= n/listinfo/ietf-announce
> >=C2=A0 =C2=A0https://mailman.rfc-ed= itor.org/mailman/listinfo/rfc-dist
> >
> > For searching the RFC series, see https://www.rfc-editor.= org/search
> > For downloading RFCs, see https://www.rfc-editor.o= rg/retrieve/bulk
> >
> > Requests for special distribution should be addressed to either t= he
> > author of the RFC in question, or to rfc-editor@rfc-editor.org.
> > Unless specifically noted otherwise on the RFC itself, all RFCs a= re
> > for unlimited distribution.
> >
> >
> > The RFC Editor Team
> > Association Management Solutions, LLC
> >
> >
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.jacobs-university.de/>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf=

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

--94eb2c0626283f0aba05432d26ad-- From nobody Thu Dec 8 14:44:13 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC55129AC1 for ; Thu, 8 Dec 2016 14:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DRWiTVsbwXm for ; Thu, 8 Dec 2016 14:44:10 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3DD8129ADB for ; Thu, 8 Dec 2016 14:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23986; q=dns/txt; s=iport; t=1481237024; x=1482446624; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aPv4zlmb9buMnyqcKYQETwxPsIN1VdlUKRQuwToChjs=; b=mlnHiZkmvRpdr1CT5kAIa/3nhANT5o5JikPoIPJRviEVqHq1V0shgb10 gm/g/LgnUNtN8m2rO2o1tUadPSAV9nsPNT8Thds5MGHC1JMhnQgHQzzT0 fwXBH+zuORFuLo0YfhxOtZ7lq9JI+TvfD66mvQvtZa92Z5Xc9c2JAzFIQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQCL4UlY/5BdJa1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJzRAEBAQEBH1qBBgeNRJcTh3WHaoUigggeAQqEQmxKAhqBYD8?= =?us-ascii?q?UAQIBAQEBAQEBYiiEaAEBAQMBAQEhCiEgCwUJAgIBCBAEAQMMARoDAgICGQYGC?= =?us-ascii?q?gEUEQIEDgUIDAcCBIgwAw8IDqc0gimHOw2DZgEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAR0FhjmEW4E9gQuBYQUELQkBFQgJggU4gl0FiGiMF4U2NQGGToMKDINWg1uBf?= =?us-ascii?q?IR9iVGHZYFuhDWEDQEfN4EZFA+DNx+BXXKGa4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,321,1477958400"; d="scan'208,217";a="184173626" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2016 22:43:43 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uB8Mhh2g016861 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Dec 2016 22:43:43 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 8 Dec 2016 17:43:42 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 8 Dec 2016 17:43:42 -0500 From: "Eric Voit (evoit)" To: Andy Bierman Thread-Topic: [Netconf] RFC 8030 on Generic Event Delivery Using HTTP Push Thread-Index: AQHSUXLztc76XEU1XEiH8L24gHUkmaD+a4GQgACKEYD//65EAA== Date: Thu, 8 Dec 2016 22:43:42 +0000 Message-ID: <62f32dbc2c334840a1f5ae3bf35dcac3@XCH-RTP-013.cisco.com> References: <20161208164203.94881B80232@rfc-editor.org> <20161208164830.GB91424@elstar.local> <72371edbd9db4d57826acad656c35788@XCH-RTP-013.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_62f32dbc2c334840a1f5ae3bf35dcac3XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] RFC 8030 on Generic Event Delivery Using HTTP Push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 22:44:12 -0000 --_000_62f32dbc2c334840a1f5ae3bf35dcac3XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjb3VsZCBoYXZlIGFsc28gYW5zd2VyZWQgdGhhdCBSRkMgODAzMCBpcyBhIHByb3h5IGNhY2hp bmcgcHJvdG9jb2wgb3B0aW1pemVkIGZvciBpbnRlcm1pdHRlbnQvIGxvdy1wb3dlciBjb25uZWN0 aXZpdHkgdG8gc21hcnRwaG9uZXMuDQoNCkl0IHdvdWxkIGJlIGRpZmZpY3VsdCB0byByZXRyb2Zp dCB0byB0aGlzIGVudmlyb25tZW50LiAgSSB3b3VsZCBiZSBpbnRyaWd1ZWQgdG8gc2VlIHRoZSBy ZXN1bHQgaWYgc29tZW9uZSBhdHRlbXB0ZWQgdGhpcy4NCg0KRXJpYw0KDQpGcm9tOiBBbmR5IEJp ZXJtYW4sIERlY2VtYmVyIDgsIDIwMTYgNToyOCBQTQ0KDQpPbiBUaHUsIERlYyA4LCAyMDE2IGF0 IDEyOjQxIFBNLCBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9p dEBjaXNjby5jb20+PiB3cm90ZToNClRoYW5rcyBmb3IgdGhlIHBvaW50ZXIgSnVlcmdlbiwNCg0K VGhlIFJGQyBkb2VzIHN1cHBvcnQgY29tbW9uIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIHN1Y2gg YXM6DQotIEREb1MgcHJvdGVjdGlvbiBtZXRob2QgZm9yIEhUVFAyDQotIFByaW9yaXRpemVkIG1l c3NhZ2VzDQotIG1hbnkgc3Vic2NyaXB0aW9ucyBwZXIgdHJhbnNwb3J0IHNlc3Npb24NCi0gb3Ro ZXJzDQoNCkJ1dCB0aGVyZSB3ZXJlIHNldmVyYWwgcmVhc29ucyBpdCBkb2Vzbid0IG1hdGNoIHN1 ZmZpY2llbnRseSBmb3IgcmV1c2Ugd2l0aCB5YW5nIGRhdGEgc3RvcmVzLiAgU29tZSBkZWx0YXMg YmV0d2VlbiB0aGUgZW52aXJvbm1lbnRzIGluY2x1ZGU6DQotIFB1c2ggU2VydmljZSBhcyBhIFN1 YnNjcmliZXIgcHJveHksIHdpdGggY2FjaGluZyBhbmQgcG9zc2libGUgcHVzaCB1cGRhdGUgYWdn cmVnYXRpb24gKGludGVuZGVkIHRvIHNhdmUgcmFkaW8gcG93ZXIpDQotIG11bHRpcGxlIHJlc291 cmNlIHRhcmdldHMgd2l0aGluIGEgc2luZ2xlIHN1YnNjcmlwdGlvbg0KLSBjb25maWd1cmVkIHN1 YnNjcmlwdGlvbiBzdXBwb3J0DQotIGNvbnRlbnQvZXZlbnQgZmlsdGVyaW5nDQotIHlhbmcNCi0g ZXZlbnQgZGFtcGVuaW5nLCBvbi1jaGFuZ2UsIGFuZCBwZXJpb2RpYw0KLSBVc2Ugb2YgR0VUIHRv IHN1YnNjcmlwdGlvbiByZXNvdXJjZSAoR1JQQyBjb21wYXRpYmlsaXR5KQ0KLSBuZWdvdGlhdGlv bg0KDQpUaGVyZWZvcmUgSSBzZWUgdGhpcyBhcyBhIHVzZWZ1bCByZWZlcmVuY2UgYW5kIGNvbnRl eHQgcmF0aGVyIHRoYW4gc29tZXRoaW5nIG5vcm1hdGl2ZSB0aGF0IHdlIGNhbiBidWlsZCB1cG9u Lg0KDQoNCkkgZG9uJ3QgYWdyZWUgdGhhdCBhbGwgdGhlc2UgdGhpbmdzIGFyZSBuZWVkZWQgb3Ig dGhleSBjYW5ub3QgYmUgZG9uZSBhcyBwYXJ0IG9mIHRoZSBhcHBsaWNhdGlvbi4NCk5vdCBzdXJl IHdoYXQgWUFORyBzdXBwb3J0IG1lYW5zIGVpdGhlci4gIFRoaXMgZG9lcyBub3Qgc2VlbSB0byBh ZmZlY3QgdGhlIGJ5dGVzIG9uIHRoZSB3aXJlLg0KDQpJIHByZWZlciB0byBzZXBhcmF0ZSB0aGUg cHJvdG9jb2wgbGF5ZXJzLiAgVGhlIHBhcnQgdGhhdCBzZWxlY3RzIHdoYXQgZXZlbnRzIHRvIHNl bmQgYW5kDQpvdGhlciBvcHRpbWl6YXRpb25zIHJlbGF0ZWQgdG8gY29udGVudCBzZWxlY3Rpb24g c2hvdWxkIG5vdCBiZSBjb3VwbGVkIHRvIGhvdyBub3RpZmljYXRpb25zDQphcmUgZGVsaXZlcmVk Lg0KDQoNCg0KV2Ugc2hvdWxkbid0IGZvcmdldCB0aGlzIHRob3VnaCBhcyB0aGVyZSBhcmUgYWxz byBpdGVtcyB3ZSBtaWdodCB3YW50IHRvIGFkb3B0IGF0IHNvbWUgZnV0dXJlIHBvaW50Og0KLSB0 aGUgU3Vic2NyaWJlciBwcm94eSBtb2RlbA0KLSBwdXNoIHVwZGF0ZSBUVEwNCi0gdHJhY2tlZCBh Y2tub3dsZWRnZW1lbnQgb2YgcHVzaCB1cGRhdGVzDQoNCkVyaWMNCg0KDQpBbmR5DQoNCj4gRnJv bTogSnVlcmdlbiBTY2hvZW53YWVsZGVyLCBEZWNlbWJlciA4LCAyMDE2IDExOjQ5IEFNDQo+DQo+ IEhpLA0KPg0KPiB0aGlzIG1heSBiZSByZWxldmFudCBmb3Igc29tZSBvZiB0aGUgZGlzY3Vzc2lv bnMgaGVyZS4NCj4NCj4gL2pzDQo+DQo+IE9uIFRodSwgRGVjIDA4LCAyMDE2IGF0IDA4OjQyOjAz QU0gLTA4MDAsIHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8bWFpbHRvOnJmYy1lZGl0b3JAcmZj LWVkaXRvci5vcmc+IHdyb3RlOg0KPiA+IEEgbmV3IFJlcXVlc3QgZm9yIENvbW1lbnRzIGlzIG5v dyBhdmFpbGFibGUgaW4gb25saW5lIFJGQyBsaWJyYXJpZXMuDQo+ID4NCj4gPg0KPiA+ICAgICAg ICAgUkZDIDgwMzANCj4gPg0KPiA+ICAgICAgICAgVGl0bGU6ICAgICAgR2VuZXJpYyBFdmVudCBE ZWxpdmVyeSBVc2luZyBIVFRQIFB1c2gNCj4gPiAgICAgICAgIEF1dGhvcjogICAgIE0uIFRob21z b24sDQo+ID4gICAgICAgICAgICAgICAgICAgICBFLiBEYW1hZ2dpbywNCj4gPiAgICAgICAgICAg ICAgICAgICAgIEIuIFJheW1vciwgRWQuDQo+ID4gICAgICAgICBTdGF0dXM6ICAgICBTdGFuZGFy ZHMgVHJhY2sNCj4gPiAgICAgICAgIFN0cmVhbTogICAgIElFVEYNCj4gPiAgICAgICAgIERhdGU6 ICAgICAgIERlY2VtYmVyIDIwMTYNCj4gPiAgICAgICAgIE1haWxib3g6ICAgIG1hcnRpbi50aG9t c29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPiwNCj4gPiAgICAg ICAgICAgICAgICAgICAgIGVsaW9kYUBtaWNyb3NvZnQuY29tPG1haWx0bzplbGlvZGFAbWljcm9z b2Z0LmNvbT4sDQo+ID4gICAgICAgICAgICAgICAgICAgICBicmlhbi5yYXltb3JAbWljcm9zb2Z0 LmNvbTxtYWlsdG86YnJpYW4ucmF5bW9yQG1pY3Jvc29mdC5jb20+DQo+ID4gICAgICAgICBQYWdl czogICAgICAzMQ0KPiA+ICAgICAgICAgQ2hhcmFjdGVyczogNjgwNjkNCj4gPiAgICAgICAgIFVw ZGF0ZXMvT2Jzb2xldGVzL1NlZUFsc286ICAgTm9uZQ0KPiA+DQo+ID4gICAgICAgICBJLUQgVGFn OiAgICBkcmFmdC1pZXRmLXdlYnB1c2gtcHJvdG9jb2wtMTIudHh0DQo+ID4NCj4gPiAgICAgICAg IFVSTDogICAgICAgIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODAzMA0KPiA+ DQo+ID4gICAgICAgICBET0k6ICAgICAgICAxMC4xNzQ4Ny9SRkM4MDMwDQo+ID4NCj4gPiBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhIHNpbXBsZSBwcm90b2NvbCBmb3IgdGhlIGRlbGl2ZXJ5IG9m IHJlYWwtDQo+ID4gdGltZSBldmVudHMgdG8gdXNlciBhZ2VudHMuICBUaGlzIHNjaGVtZSB1c2Vz IEhUVFAvMiBzZXJ2ZXIgcHVzaC4NCj4gPg0KPiA+IFRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0 IG9mIHRoZSBXZWItQmFzZWQgUHVzaCBOb3RpZmljYXRpb25zIFdvcmtpbmcNCj4gR3JvdXAgb2Yg dGhlIElFVEYuDQo+ID4NCj4gPiBUaGlzIGlzIG5vdyBhIFByb3Bvc2VkIFN0YW5kYXJkLg0KPiA+ DQo+ID4gU1RBTkRBUkRTIFRSQUNLOiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhbiBJbnRlcm5l dCBTdGFuZGFyZHMgVHJhY2sNCj4gPiBwcm90b2NvbCBmb3IgdGhlIEludGVybmV0IGNvbW11bml0 eSwgYW5kIHJlcXVlc3RzIGRpc2N1c3Npb24gYW5kDQo+ID4gc3VnZ2VzdGlvbnMgZm9yIGltcHJv dmVtZW50cy4gIFBsZWFzZSByZWZlciB0byB0aGUgY3VycmVudCBlZGl0aW9uIG9mDQo+ID4gdGhl IE9mZmljaWFsIEludGVybmV0IFByb3RvY29sIFN0YW5kYXJkcw0KPiA+IChodHRwczovL3d3dy5y ZmMtZWRpdG9yLm9yZy9zdGFuZGFyZHMpIGZvciB0aGUgc3RhbmRhcmRpemF0aW9uIHN0YXRlDQo+ ID4gYW5kIHN0YXR1cyBvZiB0aGlzIHByb3RvY29sLiAgRGlzdHJpYnV0aW9uIG9mIHRoaXMgbWVt byBpcyB1bmxpbWl0ZWQuDQo+ID4NCj4gPiBUaGlzIGFubm91bmNlbWVudCBpcyBzZW50IHRvIHRo ZSBJRVRGLUFubm91bmNlIGFuZCByZmMtZGlzdCBsaXN0cy4NCj4gPiBUbyBzdWJzY3JpYmUgb3Ig dW5zdWJzY3JpYmUsIHNlZQ0KPiA+ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZXRmLWFubm91bmNlDQo+ID4gICBodHRwczovL21haWxtYW4ucmZjLWVkaXRvci5vcmcv bWFpbG1hbi9saXN0aW5mby9yZmMtZGlzdA0KPiA+DQo+ID4gRm9yIHNlYXJjaGluZyB0aGUgUkZD IHNlcmllcywgc2VlIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3NlYXJjaA0KPiA+IEZvciBk b3dubG9hZGluZyBSRkNzLCBzZWUgaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmV0cmlldmUv YnVsaw0KPiA+DQo+ID4gUmVxdWVzdHMgZm9yIHNwZWNpYWwgZGlzdHJpYnV0aW9uIHNob3VsZCBi ZSBhZGRyZXNzZWQgdG8gZWl0aGVyIHRoZQ0KPiA+IGF1dGhvciBvZiB0aGUgUkZDIGluIHF1ZXN0 aW9uLCBvciB0byByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRpdG9yQHJm Yy1lZGl0b3Iub3JnPi4NCj4gPiBVbmxlc3Mgc3BlY2lmaWNhbGx5IG5vdGVkIG90aGVyd2lzZSBv biB0aGUgUkZDIGl0c2VsZiwgYWxsIFJGQ3MgYXJlDQo+ID4gZm9yIHVubGltaXRlZCBkaXN0cmli dXRpb24uDQo+ID4NCj4gPg0KPiA+IFRoZSBSRkMgRWRpdG9yIFRlYW0NCj4gPiBBc3NvY2lhdGlv biBNYW5hZ2VtZW50IFNvbHV0aW9ucywgTExDDQo+ID4NCj4gPg0KPg0KPiAtLQ0KPiBKdWVyZ2Vu IFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0K PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBC cmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6 Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiBOZXRj b25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGll dGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg== --_000_62f32dbc2c334840a1f5ae3bf35dcac3XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGNv dWxkIGhhdmUgYWxzbyBhbnN3ZXJlZCB0aGF0IFJGQyA4MDMwIGlzIGEgcHJveHkgY2FjaGluZyBw cm90b2NvbCBvcHRpbWl6ZWQgZm9yIGludGVybWl0dGVudC8gbG93LXBvd2VyIGNvbm5lY3Rpdml0 eSB0byBzbWFydHBob25lcy4mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SXQgd291bGQgYmUgZGlmZmljdWx0IHRvIHJldHJvZml0IHRvIHRo aXMgZW52aXJvbm1lbnQuJm5ic3A7IEkgd291bGQgYmUgaW50cmlndWVkIHRvIHNlZSB0aGUgcmVz dWx0IGlmIHNvbWVvbmUgYXR0ZW1wdGVkIHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxicj4NCkVy aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4sIERlY2VtYmVyIDgsIDIwMTYgNToyOCBQTTxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIERlYyA4LCAyMDE2IGF0IDEy OjQxIFBNLCBFcmljIFZvaXQgKGV2b2l0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmV2b2l0QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRo YW5rcyBmb3IgdGhlIHBvaW50ZXIgSnVlcmdlbiw8YnI+DQo8YnI+DQpUaGUgUkZDIGRvZXMgc3Vw cG9ydCBjb21tb24gZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgc3VjaCBhczo8YnI+DQotIEREb1Mg cHJvdGVjdGlvbiBtZXRob2QgZm9yIEhUVFAyPGJyPg0KLSBQcmlvcml0aXplZCBtZXNzYWdlczxi cj4NCi0gbWFueSBzdWJzY3JpcHRpb25zIHBlciB0cmFuc3BvcnQgc2Vzc2lvbjxicj4NCi0gb3Ro ZXJzPGJyPg0KPGJyPg0KQnV0IHRoZXJlIHdlcmUgc2V2ZXJhbCByZWFzb25zIGl0IGRvZXNuJ3Qg bWF0Y2ggc3VmZmljaWVudGx5IGZvciByZXVzZSB3aXRoIHlhbmcgZGF0YSBzdG9yZXMuJm5ic3A7 IFNvbWUgZGVsdGFzIGJldHdlZW4gdGhlIGVudmlyb25tZW50cyBpbmNsdWRlOjxicj4NCi0gUHVz aCBTZXJ2aWNlIGFzIGEgU3Vic2NyaWJlciBwcm94eSwgd2l0aCBjYWNoaW5nIGFuZCBwb3NzaWJs ZSBwdXNoIHVwZGF0ZSBhZ2dyZWdhdGlvbiAoaW50ZW5kZWQgdG8gc2F2ZSByYWRpbyBwb3dlcik8 YnI+DQotIG11bHRpcGxlIHJlc291cmNlIHRhcmdldHMgd2l0aGluIGEgc2luZ2xlIHN1YnNjcmlw dGlvbjxicj4NCi0gY29uZmlndXJlZCBzdWJzY3JpcHRpb24gc3VwcG9ydDxicj4NCi0gY29udGVu dC9ldmVudCBmaWx0ZXJpbmc8YnI+DQotIHlhbmc8YnI+DQotIGV2ZW50IGRhbXBlbmluZywgb24t Y2hhbmdlLCBhbmQgcGVyaW9kaWM8YnI+DQotIFVzZSBvZiBHRVQgdG8gc3Vic2NyaXB0aW9uIHJl c291cmNlIChHUlBDIGNvbXBhdGliaWxpdHkpPGJyPg0KLSBuZWdvdGlhdGlvbjxicj4NCjxicj4N ClRoZXJlZm9yZSBJIHNlZSB0aGlzIGFzIGEgdXNlZnVsIHJlZmVyZW5jZSBhbmQgY29udGV4dCBy YXRoZXIgdGhhbiBzb21ldGhpbmcgbm9ybWF0aXZlIHRoYXQgd2UgY2FuIGJ1aWxkIHVwb24uPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgZG9uJ3QgYWdyZWUgdGhhdCBhbGwgdGhlc2UgdGhpbmdzIGFyZSBuZWVkZWQgb3IgdGhl eSBjYW5ub3QgYmUgZG9uZSBhcyBwYXJ0IG9mIHRoZSBhcHBsaWNhdGlvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdCBzdXJlIHdoYXQgWUFO RyBzdXBwb3J0IG1lYW5zIGVpdGhlci4mbmJzcDsgVGhpcyBkb2VzIG5vdCBzZWVtIHRvIGFmZmVj dCB0aGUgYnl0ZXMgb24gdGhlIHdpcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcHJlZmVyIHRvIHNlcGFyYXRlIHRoZSBwcm90b2NvbCBs YXllcnMuJm5ic3A7IFRoZSBwYXJ0IHRoYXQgc2VsZWN0cyB3aGF0IGV2ZW50cyB0byBzZW5kIGFu ZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b3Ro ZXIgb3B0aW1pemF0aW9ucyByZWxhdGVkIHRvIGNvbnRlbnQgc2VsZWN0aW9uIHNob3VsZCBub3Qg YmUgY291cGxlZCB0byBob3cgbm90aWZpY2F0aW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXJlIGRlbGl2ZXJlZC4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPldlIHNob3VsZG4ndCBmb3JnZXQgdGhpcyB0aG91Z2ggYXMgdGhlcmUgYXJlIGFsc28g aXRlbXMgd2UgbWlnaHQgd2FudCB0byBhZG9wdCBhdCBzb21lIGZ1dHVyZSBwb2ludDo8YnI+DQot IHRoZSBTdWJzY3JpYmVyIHByb3h5IG1vZGVsPGJyPg0KLSBwdXNoIHVwZGF0ZSBUVEw8YnI+DQot IHRyYWNrZWQgYWNrbm93bGVkZ2VtZW50IG9mIHB1c2ggdXBkYXRlczxicj4NCjxicj4NCkVyaWM8 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBG cm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIsIERlY2VtYmVyIDgsIDIwMTYgMTE6NDkgQU08YnI+ DQomZ3Q7PGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyB0aGlzIG1heSBiZSByZWxl dmFudCBmb3Igc29tZSBvZiB0aGUgZGlzY3Vzc2lvbnMgaGVyZS48YnI+DQomZ3Q7PGJyPg0KJmd0 OyAvanM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBUaHUsIERlYyAwOCwgMjAxNiBhdCAwODo0Mjow M0FNIC0wODAwLCA8YSBocmVmPSJtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZyI+DQpy ZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPC9hPiB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgQSBuZXcg UmVxdWVzdCBmb3IgQ29tbWVudHMgaXMgbm93IGF2YWlsYWJsZSBpbiBvbmxpbmUgUkZDIGxpYnJh cmllcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkZDIDgwMzA8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGl0bGU6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgR2VuZXJpYyBFdmVudCBEZWxpdmVyeSBVc2luZyBIVFRQIFB1c2g8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXV0aG9yOiZuYnNwOyAm bmJzcDsgJm5ic3A7TS4gVGhvbXNvbiw8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 RS4gRGFtYWdnaW8sPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0IuIFJheW1vciwg RWQuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1N0YXR1 czombmJzcDsgJm5ic3A7ICZuYnNwO1N0YW5kYXJkcyBUcmFjazxicj4NCiZndDsgJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTdHJlYW06Jm5ic3A7ICZuYnNwOyAmbmJzcDtJ RVRGPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RhdGU6 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGVjZW1iZXIgMjAxNjxicj4NCiZndDsgJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtNYWlsYm94OiZuYnNwOyAmbmJzcDsgPGEg aHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSI+bWFydGluLnRob21zb25AZ21h aWwuY29tPC9hPiw8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFp bHRvOmVsaW9kYUBtaWNyb3NvZnQuY29tIj5lbGlvZGFAbWljcm9zb2Z0LmNvbTwvYT4sPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpicmlhbi5yYXltb3JA bWljcm9zb2Z0LmNvbSI+YnJpYW4ucmF5bW9yQG1pY3Jvc29mdC5jb208L2E+PGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2VzOiZuYnNwOyAmbmJzcDsg Jm5ic3A7IDMxPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0NoYXJhY3RlcnM6IDY4MDY5PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1VwZGF0ZXMvT2Jzb2xldGVzL1NlZUFsc286Jm5ic3A7ICZuYnNwO05vbmU8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7SS1EIFRhZzombmJzcDsgJm5ic3A7IGRyYWZ0LWlldGYtd2VicHVzaC1wcm90b2NvbC0xMi50 eHQ8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7VVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczov L3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgwMzAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODAzMDwvYT48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RE9JOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAxMC4xNzQ4Ny9SRkM4MDMwPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2ltcGxlIHByb3RvY29sIGZvciB0 aGUgZGVsaXZlcnkgb2YgcmVhbC08YnI+DQomZ3Q7ICZndDsgdGltZSBldmVudHMgdG8gdXNlciBh Z2VudHMuJm5ic3A7IFRoaXMgc2NoZW1lIHVzZXMgSFRUUC8yIHNlcnZlciBwdXNoLjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGlzIGRvY3VtZW50IGlzIGEgcHJvZHVjdCBvZiB0aGUg V2ViLUJhc2VkIFB1c2ggTm90aWZpY2F0aW9ucyBXb3JraW5nPGJyPg0KJmd0OyBHcm91cCBvZiB0 aGUgSUVURi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhpcyBpcyBub3cgYSBQcm9w b3NlZCBTdGFuZGFyZC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgU1RBTkRBUkRTIFRS QUNLOiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhbiBJbnRlcm5ldCBTdGFuZGFyZHMgVHJhY2s8 YnI+DQomZ3Q7ICZndDsgcHJvdG9jb2wgZm9yIHRoZSBJbnRlcm5ldCBjb21tdW5pdHksIGFuZCBy ZXF1ZXN0cyBkaXNjdXNzaW9uIGFuZDxicj4NCiZndDsgJmd0OyBzdWdnZXN0aW9ucyBmb3IgaW1w cm92ZW1lbnRzLiZuYnNwOyBQbGVhc2UgcmVmZXIgdG8gdGhlIGN1cnJlbnQgZWRpdGlvbiBvZjxi cj4NCiZndDsgJmd0OyB0aGUgT2ZmaWNpYWwgSW50ZXJuZXQgUHJvdG9jb2wgU3RhbmRhcmRzPGJy Pg0KJmd0OyAmZ3Q7ICg8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9zdGFuZGFy ZHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9zdGFuZGFyZHM8 L2E+KSBmb3IgdGhlIHN0YW5kYXJkaXphdGlvbiBzdGF0ZTxicj4NCiZndDsgJmd0OyBhbmQgc3Rh dHVzIG9mIHRoaXMgcHJvdG9jb2wuJm5ic3A7IERpc3RyaWJ1dGlvbiBvZiB0aGlzIG1lbW8gaXMg dW5saW1pdGVkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGlzIGFubm91bmNlbWVu dCBpcyBzZW50IHRvIHRoZSBJRVRGLUFubm91bmNlIGFuZCByZmMtZGlzdCBsaXN0cy48YnI+DQom Z3Q7ICZndDsgVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlLCBzZWU8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZXRmLWFubm91bmNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlPC9hPjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDs8YSBocmVmPSJodHRwczovL21haWxtYW4ucmZjLWVkaXRvci5vcmcvbWFpbG1hbi9saXN0aW5m by9yZmMtZGlzdCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbWFpbG1hbi5yZmMtZWRpdG9yLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JmYy1kaXN0PC9hPjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBGb3Igc2VhcmNoaW5nIHRoZSBSRkMgc2VyaWVzLCBzZWUgPGEgaHJlZj0iaHR0cHM6Ly93 d3cucmZjLWVkaXRvci5vcmcvc2VhcmNoIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5y ZmMtZWRpdG9yLm9yZy9zZWFyY2g8L2E+PGJyPg0KJmd0OyAmZ3Q7IEZvciBkb3dubG9hZGluZyBS RkNzLCBzZWUgPGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmV0cmlldmUvYnVs ayIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmV0cmlldmUv YnVsazwvYT48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgUmVxdWVzdHMgZm9yIHNwZWNp YWwgZGlzdHJpYnV0aW9uIHNob3VsZCBiZSBhZGRyZXNzZWQgdG8gZWl0aGVyIHRoZTxicj4NCiZn dDsgJmd0OyBhdXRob3Igb2YgdGhlIFJGQyBpbiBxdWVzdGlvbiwgb3IgdG8gPGEgaHJlZj0ibWFp bHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmciPg0KcmZjLWVkaXRvckByZmMtZWRpdG9yLm9y ZzwvYT4uPGJyPg0KJmd0OyAmZ3Q7IFVubGVzcyBzcGVjaWZpY2FsbHkgbm90ZWQgb3RoZXJ3aXNl IG9uIHRoZSBSRkMgaXRzZWxmLCBhbGwgUkZDcyBhcmU8YnI+DQomZ3Q7ICZndDsgZm9yIHVubGlt aXRlZCBkaXN0cmlidXRpb24uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IFRoZSBSRkMgRWRpdG9yIFRlYW08YnI+DQomZ3Q7ICZndDsgQXNzb2NpYXRpb24gTWFu YWdlbWVudCBTb2x1dGlvbnMsIExMQzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXImbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phY29icyBVbml2ZXJzaXR5IEJyZW1l biBnR21iSDxicj4NCiZndDsgUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJt YW55PGJyPg0KJmd0OyBGYXg6Jm5ic3A7ICZuYnNwOyYjNDM7NDkgNDIxIDIwMCAzMTAzJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwOi8vd3d3LmphY29i cy11bml2ZXJzaXR5LmRlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuamFjb2JzLXVuaXZl cnNpdHkuZGUvPC9hPiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgTmV0Y29uZiBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj5OZXRjb25mQGll dGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTmV0Y29uZiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_62f32dbc2c334840a1f5ae3bf35dcac3XCHRTP013ciscocom_-- From nobody Thu Dec 8 15:19:56 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18ED129BD5 for ; Thu, 8 Dec 2016 15:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWatQbuuUBX0 for ; Thu, 8 Dec 2016 15:19:52 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E043A129BD1 for ; Thu, 8 Dec 2016 15:19:50 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id x190so1462152qkb.0 for ; Thu, 08 Dec 2016 15:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hUDC/inp0XaiXaySDyDY6567rDRuGWLESTt5KAgwhmA=; b=ebqZTACA/i/P615sNYSxrPE9+bH+KwVjG1CLZYmIzcO/vy+GFRnmRaV/okEs7e7Yjv qgAUQbY8veYE+atQgCxNn2f7BxHq6+rkUoyg1tQF1G4TPbWQYfEwdy1g8uCSybswej9T tigw4cKmafPt3GiGNuL3UYWv3LzTlqG+slA1pMUrW4kDl3cFp1QkbkEgnLkaeIbmMVr/ oSOIqUoOw4dS2PFWLVGbGsN1mhDDdwHdup5qxAWX1PeeJXhEblwq/imhWcOqVld7shyu y7RZVA1k93R7cebs8AAxDV9EM77919XfAwcTJJ66ZLl5EDbOqJx22Mg47kERfX2O+ZQp 5P1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hUDC/inp0XaiXaySDyDY6567rDRuGWLESTt5KAgwhmA=; b=Lj8pYcQJPMI9nEG1G7jZbYz8AAGcVXYx2ga/vUdlOybRhj3GlqCpzUEYaavjqFOyh/ g9qyA2W6Gy1/TVSC03dd9SXq4iUUFKU1AELhCKE2tqlU3Uu2E89pWrCWFVKtoQFgCHkX TLQa/Vgp+D3ZuTYggCG75I7dvr6tf63Jo8vB1lqapEDHwjrTQTW/f56V/zm2wAwlIUlm NUc/YrW33rWs1dw7VpxO6lOHFRa24rWQuNQnYkvQMgFkcZ+QchKxzj7MNzaEydfXDWVJ FeHWNW7aVm4g91vuLEH7ItlVZN1yRATcO0izMkaj+HHghL2Yo7PRgyS3vJycHsEgcGpz fpWA== X-Gm-Message-State: AKaTC03vWUF0GIDpnxFZ3KMOkMBCH8nf3NCmH985mYjy8JGKhwPavM+9JU51FDy94CWYoxTeX7wJtvq/yT1m5A== X-Received: by 10.55.118.3 with SMTP id r3mr13366839qkc.84.1481239189918; Thu, 08 Dec 2016 15:19:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Thu, 8 Dec 2016 15:19:49 -0800 (PST) In-Reply-To: <62f32dbc2c334840a1f5ae3bf35dcac3@XCH-RTP-013.cisco.com> References: <20161208164203.94881B80232@rfc-editor.org> <20161208164830.GB91424@elstar.local> <72371edbd9db4d57826acad656c35788@XCH-RTP-013.cisco.com> <62f32dbc2c334840a1f5ae3bf35dcac3@XCH-RTP-013.cisco.com> From: Andy Bierman Date: Thu, 8 Dec 2016 15:19:49 -0800 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=94eb2c062628be2a5305432ddf38 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] RFC 8030 on Generic Event Delivery Using HTTP Push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 23:19:55 -0000 --94eb2c062628be2a5305432ddf38 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 8, 2016 at 2:43 PM, Eric Voit (evoit) wrote: > I could have also answered that RFC 8030 is a proxy caching protocol > optimized for intermittent/ low-power connectivity to smartphones. > > > > It would be difficult to retrofit to this environment. I would be > intrigued to see the result if someone attempted this. > > > You are probably right. I don't want to imply I support this approach for NETCONF and RESTCONF. Eric > Andy > > > *From:* Andy Bierman, December 8, 2016 5:28 PM > > On Thu, Dec 8, 2016 at 12:41 PM, Eric Voit (evoit) > wrote: > > Thanks for the pointer Juergen, > > The RFC does support common functional requirements such as: > - DDoS protection method for HTTP2 > - Prioritized messages > - many subscriptions per transport session > - others > > But there were several reasons it doesn't match sufficiently for reuse > with yang data stores. Some deltas between the environments include: > - Push Service as a Subscriber proxy, with caching and possible push > update aggregation (intended to save radio power) > - multiple resource targets within a single subscription > - configured subscription support > - content/event filtering > - yang > - event dampening, on-change, and periodic > - Use of GET to subscription resource (GRPC compatibility) > - negotiation > > Therefore I see this as a useful reference and context rather than > something normative that we can build upon. > > > > > > I don't agree that all these things are needed or they cannot be done as > part of the application. > > Not sure what YANG support means either. This does not seem to affect the > bytes on the wire. > > > > I prefer to separate the protocol layers. The part that selects what > events to send and > > other optimizations related to content selection should not be coupled to > how notifications > > are delivered. > > > > > > > > We shouldn't forget this though as there are also items we might want to > adopt at some future point: > - the Subscriber proxy model > - push update TTL > - tracked acknowledgement of push updates > > Eric > > > > > > Andy > > > > > From: Juergen Schoenwaelder, December 8, 2016 11:49 AM > > > > Hi, > > > > this may be relevant for some of the discussions here. > > > > /js > > > > On Thu, Dec 08, 2016 at 08:42:03AM -0800, rfc-editor@rfc-editor.org > wrote: > > > A new Request for Comments is now available in online RFC libraries. > > > > > > > > > RFC 8030 > > > > > > Title: Generic Event Delivery Using HTTP Push > > > Author: M. Thomson, > > > E. Damaggio, > > > B. Raymor, Ed. > > > Status: Standards Track > > > Stream: IETF > > > Date: December 2016 > > > Mailbox: martin.thomson@gmail.com, > > > elioda@microsoft.com, > > > brian.raymor@microsoft.com > > > Pages: 31 > > > Characters: 68069 > > > Updates/Obsoletes/SeeAlso: None > > > > > > I-D Tag: draft-ietf-webpush-protocol-12.txt > > > > > > URL: https://www.rfc-editor.org/info/rfc8030 > > > > > > DOI: 10.17487/RFC8030 > > > > > > This document describes a simple protocol for the delivery of real- > > > time events to user agents. This scheme uses HTTP/2 server push. > > > > > > This document is a product of the Web-Based Push Notifications Working > > Group of the IETF. > > > > > > This is now a Proposed Standard. > > > > > > STANDARDS TRACK: This document specifies an Internet Standards Track > > > protocol for the Internet community, and requests discussion and > > > suggestions for improvements. Please refer to the current edition of > > > the Official Internet Protocol Standards > > > (https://www.rfc-editor.org/standards) for the standardization state > > > and status of this protocol. Distribution of this memo is unlimited. > > > > > > This announcement is sent to the IETF-Announce and rfc-dist lists. > > > To subscribe or unsubscribe, see > > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > > > > > For searching the RFC series, see https://www.rfc-editor.org/search > > > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > > > > > Requests for special distribution should be addressed to either the > > > author of the RFC in question, or to rfc-editor@rfc-editor.org. > > > Unless specifically noted otherwise on the RFC itself, all RFCs are > > > for unlimited distribution. > > > > > > > > > The RFC Editor Team > > > Association Management Solutions, LLC > > > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --94eb2c062628be2a5305432ddf38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 8, 2016 at 2:43 PM, Eric Voit (evoit) <= ;evoit@cisco.com&g= t; wrote:

I could have also answered that RFC 8= 030 is a proxy caching protocol optimized for intermittent/ low-power conne= ctivity to smartphones.=C2=A0=C2=A0

=C2=A0

It would be difficult to retrofit to = this environment.=C2=A0 I would be intrigued to see the result if someone a= ttempted this.



You are probably right.
I don't want t= o imply I support this approach for =C2=A0NETCONF and RESTCONF.
<= br>

Eric


Andy
= =C2=A0

=C2=A0

From: Andy Bierman, December 8, 2016= 5:28 PM

On Thu, Dec 8, 2016 at 12:41 PM, Eric Voit (evoit) &= lt;evoit@cisco.com= > wrote:

Thanks for the pointe= r Juergen,

The RFC does support common functional requirements such as:
- DDoS protection method for HTTP2
- Prioritized messages
- many subscriptions per transport session
- others

But there were several reasons it doesn't match sufficiently for reuse = with yang data stores.=C2=A0 Some deltas between the environments include:<= br> - Push Service as a Subscriber proxy, with caching and possible push update= aggregation (intended to save radio power)
- multiple resource targets within a single subscription
- configured subscription support
- content/event filtering
- yang
- event dampening, on-change, and periodic
- Use of GET to subscription resource (GRPC compatibility)
- negotiation

Therefore I see this as a useful reference and context rather than somethin= g normative that we can build upon.

=C2=A0

=C2=A0

I don't agree that all these things are needed o= r they cannot be done as part of the application.

Not sure what YANG support means either.=C2=A0 This = does not seem to affect the bytes on the wire.

=C2=A0

I prefer to separate the protocol layers.=C2=A0 The = part that selects what events to send and

other optimizations related to content selection sho= uld not be coupled to how notifications

are delivered.=C2=A0

=C2=A0

=C2=A0

=C2=A0

We shouldn't forg= et this though as there are also items we might want to adopt at some futur= e point:
- the Subscriber proxy model
- push update TTL
- tracked acknowledgement of push updates

Eric

=C2=A0

=C2=A0

Andy

=C2=A0

> From: Juergen Schoenwaelder, December 8, 2016 1= 1:49 AM
>
> Hi,
>
> this may be relevant for some of the discussions here.
>
> /js
>
> On Thu, Dec 08, 2016 at 08:42:03AM -0800, rfc-editor@rfc-editor.org wrote:
> > A new Request for Comments is now available in online RFC librari= es.
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 8030
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2=A0 Gener= ic Event Delivery Using HTTP Push
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author:=C2=A0 =C2=A0 =C2=A0M. Th= omson,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0E. Damaggio,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0B. Raymor, Ed.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status:=C2=A0 =C2=A0 =C2=A0Stand= ards Track
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stream:=C2=A0 =C2=A0 =C2=A0IETF<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0= December 2016
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mailbox:=C2=A0 =C2=A0 martin.thomson@gmail.co= m,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0elioda@= microsoft.com,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0b= rian.raymor@microsoft.com
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2=A0 31 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Characters: 68069
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Updates/Obsoletes/SeeAlso:=C2=A0= =C2=A0None
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I-D Tag:=C2=A0 =C2=A0 draft-ietf= -webpush-protocol-12.txt
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = https://www.rfc-editor.org/info/rfc8030
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = 10.17487/RFC8030
> >
> > This document describes a simple protocol for the delivery of rea= l-
> > time events to user agents.=C2=A0 This scheme uses HTTP/2 server = push.
> >
> > This document is a product of the Web-Based Push Notifications Wo= rking
> Group of the IETF.
> >
> > This is now a Proposed Standard.
> >
> > STANDARDS TRACK: This document specifies an Internet Standards Tr= ack
> > protocol for the Internet community, and requests discussion and<= br> > > suggestions for improvements.=C2=A0 Please refer to the current e= dition of
> > the Official Internet Protocol Standards
> > (https://www.rfc-editor.org/standards) for the standardization s= tate
> > and status of this protocol.=C2=A0 Distribution of this memo is u= nlimited.
> >
> > This announcement is sent to the IETF-Announce and rfc-dist lists= .
> > To subscribe or unsubscribe, see
> >=C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/iet= f-announce
> >=C2=A0 =C2=A0https://mailman.rfc-editor.org/mailm= an/listinfo/rfc-dist
> >
> > For searching the RFC series, see https://www.rfc-editor.org/search
> > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> >
> > Requests for special distribution should be addressed to either t= he
> > author of the RFC in question, or to rfc-editor@rfc-editor.org.
> > Unless specifically noted otherwise on the RFC itself, all RFCs a= re
> > for unlimited distribution.
> >
> >
> > The RFC Editor Team
> > Association Management Solutions, LLC
> >
> >
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.= jacobs-university.de/>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf

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

=C2=A0


--94eb2c062628be2a5305432ddf38-- From nobody Fri Dec 9 00:27:01 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D932129CAF for ; Fri, 9 Dec 2016 00:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 0Q4aBIzMXJVR for ; Fri, 9 Dec 2016 00:26:54 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 67E89129CAE for ; Fri, 9 Dec 2016 00:26:54 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C7DE1AE02BC; Fri, 9 Dec 2016 09:26:52 +0100 (CET) Date: Fri, 09 Dec 2016 09:26:51 +0100 (CET) Message-Id: <20161209.092651.1622778603139515958.mbj@tail-f.com> To: evoit@cisco.com From: Martin Bjorklund In-Reply-To: References: <20161208.100745.1423954834248283961.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 08:26:59 -0000 "Eric Voit (evoit)" wrote: > Hi Martin, > > > From: Martin Bjorklund, December 8, 2016 4:08 AM > > > > I think your requirements below are more like driving forces for YANG > > push, > > right? Is there any of these that affects the solution in RFC 5277? > > The majority of these cases need yang-push. But yang push is only > possible when the information is yang modeled. Sure, but that's a completely different thing. This discussion is about what needs to be done with RFC 5277. I'll re-iterate what Andy wrote once more: What are the must-have, should-have, and nice-to-have features that are missing from RFC 5277? /martin From nobody Fri Dec 9 01:41:34 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1832212A31A for ; Fri, 9 Dec 2016 01:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 ZbLUABNMNs0j for ; Fri, 9 Dec 2016 01:41:28 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 296D712A313 for ; Fri, 9 Dec 2016 01:41:27 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 232FA1AE02BC; Fri, 9 Dec 2016 10:41:25 +0100 (CET) Date: Fri, 09 Dec 2016 10:41:24 +0100 (CET) Message-Id: <20161209.104124.355368052835019858.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20161206.162912.565827667614626853.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of "event-notification" documents X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 09:41:33 -0000 Andy Bierman wrote: > On Tue, Dec 6, 2016 at 7:29 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > Hi, > > > > > > The new solution design is completely broken unless a new notification > > > wrapper is used > > > > I agree. The current XSD in 5277 is very inflexible; it would be > > useful with a structure that allows some flexibility, specifically > > allows new "header" fields to be added w/o having to modify the > > protocol. I.e., allow elements from other namespaces after the > > built-in elements (event-time, subscription-id). > > > > > > This inflexibility has been a problem. > I think a new element in a different namespace would be better. > Clients that use the new header MUST accept and ignore unknown header > fields. > > (Examples have namespaces omitted) > > > > 1 > 4242 > // ... maybe more fields here > > > // normal notification contents > > > > or YANG 1.1 nested: > > > > > 1 > 4242 > // ... maybe more fields here > > > > eth0 > > // normal notification contents > > > > > > > > If we want to do this protocol-agnostic, we should define XML and JSON > > encoding of notifications in one document; the general concepts of > > streams and filters etc in one docuement; protocol-specific mechanisms > > to retrieve data from streams in another (unfortunately, we can't > > define protocol-agnostic rpc operations for this, since these > > operations only work for session-based protocols) > > > > > It would be better if the element could be modeled in YANG > so it can be augmented and also it would be encoding-independent. > (e.g. YANG to CBOR could be used) Yes that would be nice! There are some use cases for defining data structures that are not data nodes in a data store; this is one use case and another is restconf resources (we use rc:yang-data for this). I think Kent had another use case recently as well. We have a vendor-specific YANG extension for this: tailf:structure meta-data { description "..."; leaf device-name { ... } leaf stream-name { ... } ... } Of course, for this to work properly, we'd need this to be a built-in statement in YANG, so that augment can be made to work as well. /martin From nobody Fri Dec 9 04:31:45 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B42129873; Fri, 9 Dec 2016 04:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-3cXLw7Blno; Fri, 9 Dec 2016 04:31:34 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57951296C7; Fri, 9 Dec 2016 04:26:06 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id a20so3747828wme.2; Fri, 09 Dec 2016 04:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=H5bycSZ6TfMTplNxe3Ko6XOXZoG8sqvt3Lh61rLvc6A=; b=B3DZTpPyUuzQBTEw5HEih/Mg8PU27iHwqozlbgIgmFXKERGZO0CoCAp+4qgudrOmx/ nOsr5zonqhGOYgq2ody4OzleKRmuELaqekSRWB+Z2L0id9idvpoEsh3eGai/a64r9872 TywFO8sPuQiCN64C8iuS/RutNUXho655QhcXGeoTRYIRpLNuHv9Nw7fKHVSU+Dqj9QZ2 arzo3uSbTttr2i/lztfAosqAfEcD0dhl3ncWj5yH7OYYESc4llnhgwqpXNo0wcXgENyU jlq3ZnMf5Ounktuw5nJGhMYxAxouyLX+4qBRoV2n6tplM4VdTqpr5GH3UiEjoZt2QVrM Afog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=H5bycSZ6TfMTplNxe3Ko6XOXZoG8sqvt3Lh61rLvc6A=; b=Il0c6VF8/K8f7kiIY7m1HYA/2uqNuadClxVSw6YQ/SmghOdbIZUxsHc8Wxs0IgmgDV dQkv2PgEIgmdMYRLWdOZqs623xgB0yh21Sc4kaMWWMZbNSa56K8VMdaA0GuzlhnQ0XgR lQed6+R/xLRxmqyK/e6hVG8BChC8rTz0T0I/Xn6Y92FOE4fc5Mc+EsAZmMNtlrUwe9nZ tJizHsaDwjT+/G3Gkp12VIWOSiUAU46m4tt552Mct1M+Zz/uSotdCRwlyjA5bi35eZY1 DNHiKSsFmkTMd5hu+Xl9qu6//NYqWhx5ramSFOw/PQN5GVCwejlme59xc6GKROp9vNV6 uuUw== X-Gm-Message-State: AKaTC02cblKRVwY+ygoQAHWj4I+JXho10TQ/vZ4QHkMs+k7oQhyx+Yaaa1nyS772tK8ueFeLtN3wtDTWucxalg== X-Received: by 10.46.0.102 with SMTP id 99mr32280411lja.15.1481286365033; Fri, 09 Dec 2016 04:26:05 -0800 (PST) MIME-Version: 1.0 References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> In-Reply-To: From: MehmetErsue Date: Fri, 09 Dec 2016 12:25:54 +0000 Message-ID: To: Andy Bierman , Juergen Schoenwaelder , Ladislav Lhotka , Lou Berger , NetMod WG Chairs , Netconf , NetMod WG , NetConf WG Chairs Content-Type: multipart/alternative; boundary=001a1142c5cc993e82054338db77 Archived-At: Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 12:31:40 -0000 --001a1142c5cc993e82054338db77 Content-Type: text/plain; charset=UTF-8 Hi All, I think the adoption of the DT draft is fine. We agreed in IETF 97 to adopt and finalize the DT draft in NETMOD WG, which I still support. I believe the bigger issue is to agree on a plan concerning the related work and the re-organization of existing standards. As a matter of fact this plan will lead to updating the charter of two WGs and the work we are going to start. I see the DT document as a datastore solution proposal. There are different gaps and issues which still need to be addressed and the solution proposal needs yet to be discussed and finalized. The document is providing information on the history, explaining the need for a generic solution as well as is discussing different scenarios. As such I believe the datastore solution proposal from the DT should be published with the intended status Informational RFC. Based on the finalized and agreed datastore solution we should do different updates to existing documents in NETCONF and NETMOD WGs. With this action we can also fix well-known issues. Concerning the NETCONF WG I would see it as valuable if we develop: - a RFC6241bis draft removing the current datasore concept specification, and getting rid of well-known issues e.g. with the operation, - a new protocol- and language-independent standard document (RFC XYZ) defining the generic datastore concept and framework and describing its use (based on and following the DT solution draft), - adding potential extensions to RFC6241bis (following the DT draft and with a normative reference to RFC XYZ), - adding potential extensions to a RESTCONF-bis RFC (following the DT draft and with a normative reference to RFC XYZ), Concerning the NETMOD WG I would see it as valuable if we develop: - RFC7950bis deleting protocol-dependent details and specifying the datastore usage with YANG on a generic level (with a normative reference to RFC XYZ), - adding potential extensions to RFC7950bis, e.g. concerning the proposed element, - possibly an RFC 6244bis to describe architectural aspects. However RFC6244 is Informational and a RFC6244bis would be still Informational. I'm not sure whether this is really necessary. The DT proposal does already describe such a solution and can be seen as an update to RFC 6244. - RFC6087bis giving guidelines on how to use YANG with the new datastore concept. Referring to Lada's proposal concerning the spin off document from RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be provided in the corresponding protocol RFCs, i.e. for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. Hope this helps as a starting point on the way to a good plan. PS: As Benoit suggested some time ago we might also consider to rename NETCONF WG as it is not only on NETCONF protocol anymore. Regards, Mehmet On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman wrote: > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > I disagree that the datastore model is a protocol specific aspect. I > > > consider datastores an architectural component binding data models and > > > protocols together. In fact, the 'traditional' datastore model > > > > I would agree with this if datastores were a general concept in YANG, > but the revised-datastores draft explicitly introduces the "intended" and > "applied" datastores that may be irrelevant to other protocols using YANG, > and even needn't be used in all NETCONF implementations. I wouldn't call > this "an architectural component" of YANG. > > > > An architectural component of this new management framework (that does > not have a name). The fact that not all protocols may expose all > datastores is IMHO not a reason that the datastore model is not an > architectural framework. > > > If you are saying that it will have nontrivial impact on YANG, I would > like to see it explained in sec. 6.3. Without this information I am quite > reluctant to agree with the adoption. > > An operational state datastore has implications how one writes data > models. It may not directly affect YANG itself but surely the usage of > YANG. > > > See above - architectural aspects need to be relevant to all protocols. > > Yes, but relevant to all protocols does not mean every protocol needs > to expose say all datastores. But every protocol should be clear about > how what it exposes relates to the architectural framework. > > > > There is a "current solution" consisting of hard-wired object semantics > (e.g., ifAdminStatus and ifOperStatus). This solution does not require > special protocols or datastores, but it is being replaced by a generic > solution. > > If the "generic" solution requires special procedures which differ on each > protocol, > then it might end up be worse than the hard-wired solution that works on > every protocol. > So I agree with Juergen that this is primarily an architectural issue. > > > /js > > > Andy > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 <0421%202003587> Campus Ring 1 | 28759 > Bremen | Germany > Fax: +49 421 200 3103 <0421%202003103> < > http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- Cheers, Mehmet --001a1142c5cc993e82054338db77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,<= br class=3D"gmail_msg">
I think the adoption of the DT draft is fine. We agreed in IETF 97 to adopt and finalize the DT draft in NETMOD WG, which I still support.

I believe the bigger issue is to agree on a plan concerning the related=20 work and the re-organization of existing standards. As a matter of fact=20 this plan will lead to updating the charter of two WGs and the work we=20 are going to start.
=C2=A0
I = see=20 the DT document as a datastore solution proposal. There are different=20 gaps and issues which still need to be addressed and the solution=20 proposal needs yet to be discussed and finalized. The document is=20 providing information on the history, explaining the need for a generic=20 solution as well as is discussing different scenarios. As such I believe the datastore solution proposal from the DT should be published with the intended status Informational=20 RFC.

Based on the finalized= =20 and agreed datastore solution we should do different updates to existing documents in NETCONF and NETMOD WGs. With this action we can also fix=20 well-known issues.

Concernin= g the NETCONF WG I would see it as valuable if we develop:
- a RFC6241bis draft removing the current datasore concept specification, and getting rid of well-known issues e.g. with the <get>=20 operation,
- a new protocol- and=20 language-independent standard document (RFC XYZ) defining the generic=20 datastore concept and framework and describing its use (based on and follow= ing the DT solution=20 draft),
- adding potential extensions to RFC6241bis (following the DT d= raft and with a normative reference to RFC XYZ),
- a= dding potential extensions to a RESTCONF-bis RFC (following the DT draft an= d with a normative reference to RFC XYZ),

Concerning the NETMOD WG I would see it as valuable if we de= velop:
- RFC7950bis deleting protocol-dependent details and specifying the datastor= e usage with YANG on a generic level (with a normative reference to RFC=20 XYZ),
- adding potential extensions to RFC7950bis, e.g. concerning the proposed <notification> element,
-= possibly an RFC 6244bis to describe=20 architectural aspects. However RFC6244 is Informational and a RFC6244bis would be still Informational. I'm not sure whether this is really=20 necessary. The DT proposal does already describe such a solution and can be seen as an update to RFC 6244.
- RFC6087bis givi= ng guidelines on how to use YANG with the new datastore concept.

Referring to Lada's proposal con= cerning the spin off document from RFC7950 ("Adapting NETCONF for use = with YANG"),
I think this can be provided in the corresponding protocol RFCs, i.e.
fo= r NETCONF a section on "Using NETCONF with YANG" in RFC6241bis an= d for RESTCONF=20 "Using RESTCONF with YANG" in RESTCONF-bis RFC.

Hope this helps as a starting point on the way to a go= od plan.

PS: As Benoit suggested some time = ago we might also consider to rename NETCONF WG as it is not only on NETCON= F protocol anymore.

Regards,
Mehmet

On Mon, Dec 5, 2016 at = 6:19 PM Andy Bierman <andy@yumawor= ks.com> wrote:
On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelde= r <j.schoenwael= der@jacobs-university.de> wrote:
On Mon, Dec 05, 2016 at 11:36:11AM +010= 0, Ladislav Lhotka wrote:
>
> >
> > I disagree that the datastore model is a protocol specific aspect= . I
> > consider datastores an architectural component binding data model= s and
> > protocols together. In fact, the 'traditional' datastore = model
>
> I would agree with this if datastores were a general concept in YANG, = but the revised-datastores draft explicitly introduces the "intended&q= uot; and "applied" datastores that may be irrelevant to other pro= tocols using YANG, and even needn't be used in all NETCONF implementati= ons. I wouldn't call this "an architectural component" of YAN= G.
>

An architectural component of this new management framework (that does
not have a name). The fact that not all protocols may expose all
datastores is IMHO not a reason that the datastore model is not an
architectural framework.

> If you are saying that it will have nontrivial impact on YANG, I would= like to see it explained in sec. 6.3. Without this information I am quite = reluctant to agree with the adoption.

An operational state datastore has implications how one writes data
models. It may not directly affect YANG itself but surely the usage of
YANG.

> See above - architectural aspects need to be relevant to all protocols= .

Yes, but relevant to all protocols does not mean every protocol needs
to expose say all datastores. But every protocol should be clear about
how what it exposes relates to the architectural framework.

<= div class=3D"gmail_msg">

There is a "current solution&qu= ot; consisting of hard-wired object semantics
(e.g., ifAdminStatus and ifOperStatus).=C2=A0 This solution does not requi= re
special protocols or datastores, but it is= being replaced by a generic solution.

If the "generic"= solution requires special procedures which differ on each protocol,
<= div class=3D"gmail_msg">then it might end up be worse than the hard-wired s= olution that works on every protocol.
So I ag= ree with Juergen that this is primarily an architectural issue.

<= br class=3D"gmail_msg">
/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 | 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.d= e/>

_______________________________________________
netmod mailing list
ne= tmod@ietf.org
https://www.ietf.org/mailman/listinf= o/netmod
--
Cheers,
Mehmet
--001a1142c5cc993e82054338db77-- From nobody Fri Dec 9 04:47:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1163E129533 for ; Fri, 9 Dec 2016 04:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQrrECVs_NBI for ; Fri, 9 Dec 2016 04:47:18 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C0C1293F9 for ; Fri, 9 Dec 2016 04:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2307; q=dns/txt; s=iport; t=1481287637; x=1482497237; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=litwo2NE8eHMRkZG57/9D7+LyqgyB9xlTPGF/hwJrQs=; b=byLiAOVPYvIy6+nsEkRHoTfrbfZ2sgPMf206jXGHihuTbswRgBnGsAOX 4/LZftH+qPTt1SvJGNTsVboCS9EvoQO1w4qgC+TS75XYuIPP8xT34PsRJ 98KNSi+zgSbmzw7qV+bsiBiN7MjTkK3VWKOsbahJu3gbeZov1903cn8mg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQB2pkpY/4ENJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAR9agQYHjUKXFJUCggorhXYCggA/FAECAQEBAQEBAWIohGg?= =?us-ascii?q?BAQECAQE6NgkFCwIBCA4HAw0REDIlAgQOBQgTiEgIDqoriy0BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYY+hFuKKQWaawGGTopJkE6OC4QNAR83gSEkhTVyAYgugQ0?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.33,324,1477958400"; d="scan'208";a="358671080" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2016 12:47:16 +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 uB9ClGY9025626 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Dec 2016 12:47:16 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 07:47:16 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 9 Dec 2016 07:47:15 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund Thread-Topic: [Netconf] Subscription Use Cases Thread-Index: AQHSUTKNz0LSmZX5b0GYyl1Cgj0Ou6D+G3xggAGB64D///FKsA== Date: Fri, 9 Dec 2016 12:47:15 +0000 Message-ID: <5e06ffa5d92a4227ae1d64bc8531ac40@XCH-RTP-013.cisco.com> References: <20161208.100745.1423954834248283961.mbj@tail-f.com> <20161209.092651.1622778603139515958.mbj@tail-f.com> In-Reply-To: <20161209.092651.1622778603139515958.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 12:47:20 -0000 > From: Martin Bjorklund, December 9, 2016 3:27 AM >=20 > "Eric Voit (evoit)" wrote: > > Hi Martin, > > > > > From: Martin Bjorklund, December 8, 2016 4:08 AM > > > > > > I think your requirements below are more like driving forces for > > > YANG push, right? Is there any of these that affects the solution > > > in RFC 5277? > > > > The majority of these cases need yang-push. But yang push is only > > possible when the information is yang modeled. >=20 > Sure, but that's a completely different thing. >=20 > This discussion is about what needs to be done with RFC 5277. I'll re-it= erate > what Andy wrote once more: >=20 > What are the must-have, should-have, and nice-to-have features that are > missing from RFC 5277? At a high level incremental functionality we have been discussing since IET= F 94, 95, 96, 97 includes: - configured subscriptions - many subscriptions per transport - modify and delete subscriptions - control plane notifications - Restconf & HTTP support - Data plan notification including subscription-id At a medium level, existing documentation detailing these requirements can = be seen in places like: =20 https://www.ietf.org/proceedings/95/slides/slides-95-netconf-7.pdf Slide = 5 https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf Slides= 5, 28 https://www.ietf.org/proceedings/97/slides/slides-97-netconf-draft-ietf-net= conf-yang-push-01.pdf Slides 20 & 21 At a detailed level, I2RS's RFC-7923 has functional requirements for yang s= ubscriptions. This is what was requested by the WG to be made available for= event notifications. =20 as well as various WG meeting minutes. And of course the existing WG minutes, the four draft document appendices, = and the Dezign team minutes at: https://github.com/netconf-wg/yang-push/wiki/Minutes Attempts to keep a running list of to-be-resolved dialogs. Of course there= is a lag between dialogs and embodiment in the drafts. If anyone wants to propose a revision to the requirements, I propose they d= o this as deltas from the existing documentation. Or course we in the WG can and should discuss and tweak any specific requir= ement on this mailer based on ongoing learnings over time. =20 Eric > /martin From nobody Fri Dec 9 04:48:43 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1D8129413; Fri, 9 Dec 2016 04:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 5r-9Z2u94jA5; Fri, 9 Dec 2016 04:48:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE73129407; Fri, 9 Dec 2016 04:48:37 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:ade0:95a:a7e1:737f] (unknown [IPv6:2001:718:1a02:1:ade0:95a:a7e1:737f]) by mail.nic.cz (Postfix) with ESMTPSA id 055D061D83; Fri, 9 Dec 2016 13:48:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481287716; bh=Oztfg1BR3xLx2TtAPlPE7jW9q5pUvv25PzFfMTaTzNg=; h=From:Date:To; b=ab9Y00IWj0jEboN+7dfbEMaDgKuaQT/5TF8olTQaxH7jDAuzSMPsBZAP44a7JK/tV ZXqwGzXf73tpuECEcsph6Smq774Loa4ne1R/+GVwmT9o59mLg441q+SKj0N0Maoekh BltOq7aGDo1S/c5UL73IvULvwI8rTVXBLQH4BJgg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 9 Dec 2016 13:48:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> To: MehmetErsue X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 12:48:41 -0000 Hi Mehmet, I think I could just sign your text at the bottom. Lada > On 9 Dec 2016, at 13:25, MehmetErsue wrote: >=20 > Hi All, >=20 > I think the adoption of the DT draft is fine. We agreed in IETF 97 to = adopt and finalize the DT draft in NETMOD WG, which I still support. >=20 > I believe the bigger issue is to agree on a plan concerning the = related work and the re-organization of existing standards. As a matter = of fact this plan will lead to updating the charter of two WGs and the = work we are going to start. > =20 > I see the DT document as a datastore solution proposal. There are = different gaps and issues which still need to be addressed and the = solution proposal needs yet to be discussed and finalized. The document = is providing information on the history, explaining the need for a = generic solution as well as is discussing different scenarios. As such I = believe the datastore solution proposal from the DT should be published = with the intended status Informational RFC.=20 >=20 > Based on the finalized and agreed datastore solution we should do = different updates to existing documents in NETCONF and NETMOD WGs. With = this action we can also fix well-known issues. >=20 > Concerning the NETCONF WG I would see it as valuable if we develop: > - a RFC6241bis draft removing the current datasore concept = specification, and getting rid of well-known issues e.g. with the = operation, > - a new protocol- and language-independent standard document (RFC XYZ) = defining the generic datastore concept and framework and describing its = use (based on and following the DT solution draft),=20 > - adding potential extensions to RFC6241bis (following the DT draft = and with a normative reference to RFC XYZ), > - adding potential extensions to a RESTCONF-bis RFC (following the DT = draft and with a normative reference to RFC XYZ), >=20 > Concerning the NETMOD WG I would see it as valuable if we develop: > - RFC7950bis deleting protocol-dependent details and specifying the = datastore usage with YANG on a generic level (with a normative reference = to RFC XYZ), > - adding potential extensions to RFC7950bis, e.g. concerning the = proposed element, > - possibly an RFC 6244bis to describe architectural aspects. However = RFC6244 is Informational and a RFC6244bis would be still Informational. = I'm not sure whether this is really necessary. The DT proposal does = already describe such a solution and can be seen as an update to RFC = 6244. > - RFC6087bis giving guidelines on how to use YANG with the new = datastore concept. >=20 > Referring to Lada's proposal concerning the spin off document from = RFC7950 ("Adapting NETCONF for use with YANG"),=20 > I think this can be provided in the corresponding protocol RFCs, i.e.=20= > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and = for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. >=20 > Hope this helps as a starting point on the way to a good plan. >=20 > PS: As Benoit suggested some time ago we might also consider to rename = NETCONF WG as it is not only on NETCONF protocol anymore.=20 >=20 > Regards, > Mehmet=20 >=20 > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman = wrote: > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder = wrote: > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > I disagree that the datastore model is a protocol specific aspect. = I > > > consider datastores an architectural component binding data models = and > > > protocols together. In fact, the 'traditional' datastore model > > > > I would agree with this if datastores were a general concept in = YANG, but the revised-datastores draft explicitly introduces the = "intended" and "applied" datastores that may be irrelevant to other = protocols using YANG, and even needn't be used in all NETCONF = implementations. I wouldn't call this "an architectural component" of = YANG. > > >=20 > An architectural component of this new management framework (that does > not have a name). The fact that not all protocols may expose all > datastores is IMHO not a reason that the datastore model is not an > architectural framework. >=20 > > If you are saying that it will have nontrivial impact on YANG, I = would like to see it explained in sec. 6.3. Without this information I = am quite reluctant to agree with the adoption. >=20 > An operational state datastore has implications how one writes data > models. It may not directly affect YANG itself but surely the usage of > YANG. >=20 > > See above - architectural aspects need to be relevant to all = protocols. >=20 > Yes, but relevant to all protocols does not mean every protocol needs > to expose say all datastores. But every protocol should be clear about > how what it exposes relates to the architectural framework. >=20 >=20 >=20 > There is a "current solution" consisting of hard-wired object = semantics > (e.g., ifAdminStatus and ifOperStatus). This solution does not = require > special protocols or datastores, but it is being replaced by a generic = solution. >=20 > If the "generic" solution requires special procedures which differ on = each protocol, > then it might end up be worse than the hard-wired solution that works = on every protocol. > So I agree with Juergen that this is primarily an architectural issue. >=20 >=20 > /js >=20 > Andy >=20 > =20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --=20 > Cheers, > Mehmet -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 9 05:08:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5CC12979D; Fri, 9 Dec 2016 05:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRRAM1rtEfuD; Fri, 9 Dec 2016 05:08:51 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1E3129715; Fri, 9 Dec 2016 05:08:50 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id m203so3954305wma.3; Fri, 09 Dec 2016 05:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=XFK06eiNR7RJsPkq1q4QXx/QUZIlhtp6IiQ0qZQEDLg=; b=WrU+ZptGXx4c/lEhULdr5k3iQAy6I+Q9uxIDM0Vdym1yPfyXeh3cRLDKOnGIgRNpfp Sj6IOVUIvQaND/j/3b4ZJRu4wq5Xt6WURZhtU+IYRFiZpNhhRRUP8dJKJRWG1pvLIbqd TJETpH1fYS2CPbaq32HzzrTd5+ytVsDxuj7K19ndATe33XoEd+a1EwyIoIhUVpN2oU6/ Z9TgMLEwl4tjssnNAg+yfiyyCW3TwX0MHBJherq7rECgKGgwUu3QDYDRToUcGgD+xjU7 Bjd44/vtdXQvJIQd3JzZuePch//KGdtsxkdXXcRffMWYzEEHbQ8uVx4RRYczwllhgsdM gzfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XFK06eiNR7RJsPkq1q4QXx/QUZIlhtp6IiQ0qZQEDLg=; b=lvlaCYgxg9j3W9SP5iPrJ7zAE3iS8tA9h6f8LV6KzvxCgKqMTsTF6wh/XE7IenFEUW tm+RWajEIHCC5XbyAiaoDq4ujk8GBd3ihLLGjOvUUsF/rgYSPXZ4zwy0b4AghEyJRNWI lJJ6ZEYTVmlr6UVOnR7ZuikpK1upypz6jmw7P0gkD5VFyzXWrLxaYztDIOM1qPbV/cIZ vQZ1ayzXNw7+/Cgx5HLk1BdkmRDR+Mg4gSdTOdUmtvwTbn6DdmNHVTjgDBGE7QjNiGZ0 9i3GeXGVejyIHpENh4AGtR5cSnDWkYWXNMO+rO0qT+hoKXQjiuHNS5QCwOihXwB4SwKW cfCA== X-Gm-Message-State: AKaTC03rrW6tEahxPtRnMhLOBmNT88aFksXwFX9y0fvomx8v2WyXbsWpBDrBaWyvEdlN18gg8FeLfYU+kjBj+w== X-Received: by 10.25.23.221 with SMTP id 90mr27068689lfx.34.1481288928997; Fri, 09 Dec 2016 05:08:48 -0800 (PST) MIME-Version: 1.0 From: MehmetErsue Date: Fri, 09 Dec 2016 13:08:37 +0000 Message-ID: To: Ladislav Lhotka , Lou Berger , Netconf , NetMod WG Content-Type: multipart/alternative; boundary=001a114118a06c3c0005433974dd Archived-At: Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 13:08:54 -0000 --001a114118a06c3c0005433974dd Content-Type: text/plain; charset=UTF-8 *[Sorry for reposting. Gmail client seems to add some confusing quotations.]* Hi All, I think the adoption of the DT draft is fine. We agreed in IETF 97 to adopt and finalize the DT draft in NETMOD WG, which I still support. I believe the bigger issue is to agree on a plan concerning the related work and the re-organization of existing standards. As a matter of fact this plan will lead to updating the charter of two WGs and the work we are going to start. I see the DT document as a datastore solution proposal. There are different gaps and issues which still need to be addressed and the solution proposal needs yet to be discussed and finalized. The document is providing information on the history, explaining the need for a generic solution as well as is discussing different scenarios. As such I believe the datastore solution proposal from the DT should be published with the intended status Informational RFC. Based on the finalized and agreed datastore solution we should do different updates to existing documents in NETCONF and NETMOD WGs. With this action we can also fix well-known issues. Concerning the NETCONF WG I would see it as valuable if we develop: - a RFC6241bis draft removing the current datasore concept specification, and getting rid of well-known issues e.g. with the operation, - a new protocol- and language-independent standard document (RFC XYZ) defining the generic datastore concept and framework and describing its use (based on and following the DT solution draft), - adding potential extensions to RFC6241bis (following the DT draft and with a normative reference to RFC XYZ), - adding potential extensions to a RESTCONF-bis RFC (following the DT draft and with a normative reference to RFC XYZ), Concerning the NETMOD WG I would see it as valuable if we develop: - RFC7950bis deleting protocol-dependent details and specifying the datastore usage with YANG on a generic level (with a normative reference to RFC XYZ), - adding potential extensions to RFC7950bis, e.g. concerning the proposed element, - possibly an RFC 6244bis to describe architectural aspects. However RFC6244 is Informational and a RFC6244bis would be still Informational. I'm not sure whether this is really necessary. The DT proposal does already describe such a solution and can be seen as an update to RFC 6244. - RFC6087bis giving guidelines on how to use YANG with the new datastore concept. Referring to Lada's proposal concerning the spin off document from RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be provided in the corresponding protocol RFCs, i.e. for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. Hope this helps as a starting point on the way to a good plan. PS: As Benoit suggested some time ago we might also consider to rename NETCONF WG as it is not only on NETCONF protocol anymore. Regards, Mehmet -- Cheers, Mehmet --001a114118a06c3c0005433974dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Sorry for reposting. Gmail client seems to add some co= nfusing quotations.]

Hi All,

I think the adopti= on of the DT draft is fine. We agreed in IETF 97 to adopt and finalize the = DT draft in NETMOD WG, which I still support.

I believe the bigger i= ssue is to agree on a plan concerning the related work and the re-organizat= ion of existing standards. As a matter of fact this plan will lead to updat= ing the charter of two WGs and the work we are going to start.
=C2=A0I see the DT document as a datastore solution proposal. There are differen= t gaps and issues which still need to be addressed and the solution proposa= l needs yet to be discussed and finalized. The document is providing inform= ation on the history, explaining the need for a generic solution as well as= is discussing different scenarios. As such I believe the datastore solutio= n proposal from the DT should be published with the intended status Informa= tional RFC.

Based on the finalized and agreed datastore solution we= should do different updates to existing documents in NETCONF and NETMOD WG= s. With this action we can also fix well-known issues.

Concerning th= e NETCONF WG I would see it as valuable if we develop:
- a RFC6241bis dr= aft removing the current datasore concept specification, and getting rid of= well-known issues e.g. with the <get> operation,
- a new protocol= - and language-independent standard document (RFC XYZ) defining the generic= datastore concept and framework and describing its use (based on and follo= wing the DT solution draft),
- adding potential extensions to RFC6241bis= (following the DT draft and with a normative reference to RFC XYZ),
- a= dding potential extensions to a RESTCONF-bis RFC (following the DT draft an= d with a normative reference to RFC XYZ),

Concerning the NETMOD WG I= would see it as valuable if we develop:
- RFC7950bis deleting protocol-= dependent details and specifying the datastore usage with YANG on a generic= level (with a normative reference to RFC XYZ),
- adding potential exten= sions to RFC7950bis, e.g. concerning the proposed <notification> elem= ent,
- possibly an RFC 6244bis to describe architectural aspects. Howeve= r RFC6244 is Informational and a RFC6244bis would be still Informational. I= 'm not sure whether this is really necessary. The DT proposal does alre= ady describe such a solution and can be seen as an update to RFC 6244.
-= RFC6087bis giving guidelines on how to use YANG with the new datastore con= cept.

Referring to Lada's proposal concerning the spin off docum= ent from RFC7950 ("Adapting NETCONF for use with YANG"),
I thi= nk this can be provided in the corresponding protocol RFCs, i.e.
for NET= CONF a section on "Using NETCONF with YANG" in RFC6241bis and for= RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC.

= Hope this helps as a starting point on the way to a good plan.

PS: A= s Benoit suggested some time ago we might also consider to rename NETCONF W= G as it is not only on NETCONF protocol anymore.

Regards,
Mehmet =
--

--001a1140657855a4ad0543913a0c-- From nobody Tue Dec 13 14:47:17 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46103129C23; Tue, 13 Dec 2016 14:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 JRLPzOgl8ijb; Tue, 13 Dec 2016 14:47:12 -0800 (PST) Received: from mail-wj0-x243.google.com (mail-wj0-x243.google.com [IPv6:2a00:1450:400c:c01::243]) (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 93598129C10; Tue, 13 Dec 2016 14:47:11 -0800 (PST) Received: by mail-wj0-x243.google.com with SMTP id he10so395197wjc.2; Tue, 13 Dec 2016 14:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language :disposition-notification-to; bh=FkK1cTPTIgGhmsjdyuS1NjFj9Eeka4K9/uhUvaHz9lE=; b=iN6XTcuWlq9ojexjFICmdagbj6uxyIusi38A3ri7PSjR5poRqBoCcLZKYC2oVkpH/6 VJUVw/FD1mWfFkjxaN3Kn6D+TV/nZBQCHwrhbAD+2Wch6RXVrKxHu/skki6AEIZVOhau osgBvA9OvHw7+A3eneA6SP8G8LJjz5KlD3TiX8ugoWXjV6W2ywccdR3RaO9XyEkD6GiA PcQ7pLCBuyPTtqatctMnSNrD8pSSgns9rccSNvn3I9S5GYnjx3TklIwPb66IlHJ50wp8 J7B9cGCzgXly74FqN4gV7RObRJxv/7xkJltn+Z+DNptWeURZsLwBVJShqHNinUeiAzPw f0qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language :disposition-notification-to; bh=FkK1cTPTIgGhmsjdyuS1NjFj9Eeka4K9/uhUvaHz9lE=; b=FXogPukfdvLZIWgivByDYTStkc/lHuddwlDDMUCHw2ib7TORZ4lx1Cv8Jx8mL2p3vs +jhtz0bcdBOSFNgS/597PZnTVb2Ov+jJo0hpBeJ82ru2+pu+9Y7KjjkA/Y3rW/2vtQ6C CiK0f4LAjUy7PcMrLE9mLmcRF0X5g+Fdh+uw1ElB0s1UCgMoyfRZQ/narZoJQHO9F8WU IuJXwGG+ipzcqlI+daAbaJWNRFGGR+pB6C9KFE6lgggUc8EcZIaAyI4Mv/aVfaETxzMr otBWq7rJlVOE79pacjbfHxFuyeIlVQ9SQGTq5+5ln2tyS7m1tU9Fvm2f270Yle2oI388 afMg== X-Gm-Message-State: AKaTC03dB8f+ReBn7/InnAYyhULc65NiDu/KGLxMMRIBmOS2JDEo45TDyoTihRZu72BW2A== X-Received: by 10.194.201.103 with SMTP id jz7mr95774289wjc.70.1481669229893; Tue, 13 Dec 2016 14:47:09 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5DCC6EDC.dip0.t-ipconnect.de. [93.204.110.220]) by smtp.gmail.com with ESMTPSA id vr9sm64232555wjc.35.2016.12.13.14.47.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Dec 2016 14:47:08 -0800 (PST) From: "Mehmet Ersue" To: "'Andy Bierman'" References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> In-Reply-To: Date: Tue, 13 Dec 2016 23:47:05 +0100 Message-ID: <00ae01d25592$d46ee7f0$7d4cb7d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01D2559B.36399180" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJvIdnLcbPhtZVe/ZwhlJOAl849fwFrVtQ3AezV2tIA+5xlnwL4zh2sAk77YEwCCFzmZgJIVCHNAgcLeowB7aW4ZgFJbBpLAgSx2bCfI2eN8A== Content-Language: de X-AVK-Virus-Check: AVA 25.9511;155A1E2 X-AVK-Spam-Check: 1; str=0001.0A0C0205.58507A6C.00F0,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; F1206 Archived-At: Cc: 'NetMod WG Chairs' , 'NetConf WG Chairs' , 'NetMod WG' , 'Netconf' Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 22:47:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AF_01D2559B.36399180 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Technically spoken actually both options work for me:=20 Keeping current concept in 6241 or having everything in one document. I prefer the latter. =20 We actually don=E2=80=99t want to remove , only solve issues. Any change to is for sure subject to WG decision. =20 Mehmet =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Tuesday, December 13, 2016 10:52 PM To: Mehmet Ersue Cc: Eric Voit (evoit) ; Ladislav Lhotka = ; NetMod WG Chairs ; NetConf WG = Chairs ; NetMod WG ; Netconf = Subject: Re: [netmod] [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00 =20 =20 =20 On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue > wrote: Hi Andy, =20 > This architectural change needs to be implemented in various = protocols. > I am not sure a 6241bis is the best approach because it is not clear = which > servers really need to implement the revised datastores. =20 =20 I agree fully. This is the reason why I wrote in my mail: =20 >> - a new protocol- and language-independent standard document (RFC = XYZ) defining the generic datastore concept and framework and describing = its use (based on and following the DT solution draft), >> - a RFC6241bis draft removing the current datasore concept = specification, and getting rid of well-known issues e.g. with the = operation, =20 I do not agree with the text you wrote. I do not want to remove candidate, running, and startup from RFC 6241. IMO the new datastores can be defined in a new document that does not = redefine the existing datastores. =20 I also do not want to get rid of , It works as intended. It is not a problem on small devices. It is not a problem on large = devices if sufficient filtering is used. It does not differentiate between = intended and applied config or understand different types of config=3Dfalse nodes. Use a new = operation to add these features. =20 =20 =20 =20 =20 Mehmet =20 =20 Andy =20 =20 =20 From: Andy Bierman [mailto:andy@yumaworks.com = ]=20 Sent: Dienstag, 13. Dezember 2016 18:38 To: Eric Voit (evoit) > Cc: Ladislav Lhotka >; MehmetErsue = >; NetMod WG Chairs = >; NetConf WG = Chairs >; = NetMod WG >; Netconf = > Subject: Re: [netmod] [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00 =20 =20 =20 On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > wrote: I support adoption, and like Mehmet's thinking as well. Also worth focusing on is transport protocol independent yang filtering. = So along with how to frame get operations against one of the = datastores, how do you know which subtrees/nodes should be = included/excluded. =20 =20 This architectural change needs to be implemented in various protocols. I am not sure a 6241bis is the best approach because it is not clear = which servers really need to implement the revised datastores. Since RD is = purely optional to implement, it should not obsolete 6241 in any way. It should be = possible to add new operations and/or new parameters to existing operations = without needing to redefine what is already there. =20 The new protocol features need to explain how to include/exclude = subtrees. IMO we should only support YANG defined data. This allows the solutions to be generalized and reusable across protocols (e.g., using YANG = extensions). =20 =20 Eric =20 =20 Andy =20 > From: Netconf, December 9, 2016 7:49 AM > > Hi Mehmet, > > I think I could just sign your text at the bottom. > > Lada > > > On 9 Dec 2016, at 13:25, MehmetErsue > wrote: > > > > Hi All, > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 = to adopt and > finalize the DT draft in NETMOD WG, which I still support. > > > > I believe the bigger issue is to agree on a plan concerning the = related work > and the re-organization of existing standards. As a matter of fact = this plan will > lead to updating the charter of two WGs and the work we are going to = start. > > > > I see the DT document as a datastore solution proposal. There are = different > gaps and issues which still need to be addressed and the solution = proposal > needs yet to be discussed and finalized. The document is providing = information > on the history, explaining the need for a generic solution as well as = is discussing > different scenarios. As such I believe the datastore solution proposal = from the > DT should be published with the intended status Informational RFC. > > > > Based on the finalized and agreed datastore solution we should do = different > updates to existing documents in NETCONF and NETMOD WGs. With this > action we can also fix well-known issues. > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > - a RFC6241bis draft removing the current datasore concept > > specification, and getting rid of well-known issues e.g. with the > > operation, > > - a new protocol- and language-independent standard document (RFC = XYZ) > > defining the generic datastore concept and framework and describing > > its use (based on and following the DT solution draft), > > - adding potential extensions to RFC6241bis (following the DT draft > > and with a normative reference to RFC XYZ), > > - adding potential extensions to a RESTCONF-bis RFC (following the = DT > > draft and with a normative reference to RFC XYZ), > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > - RFC7950bis deleting protocol-dependent details and specifying the > > datastore usage with YANG on a generic level (with a normative > > reference to RFC XYZ), > > - adding potential extensions to RFC7950bis, e.g. concerning the > > proposed element, > > - possibly an RFC 6244bis to describe architectural aspects. However = RFC6244 > is Informational and a RFC6244bis would be still Informational. I'm = not sure > whether this is really necessary. The DT proposal does already = describe such a > solution and can be seen as an update to RFC 6244. > > - RFC6087bis giving guidelines on how to use YANG with the new = datastore > concept. > > > > Referring to Lada's proposal concerning the spin off document from > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > provided in the corresponding protocol RFCs, i.e. > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > Hope this helps as a starting point on the way to a good plan. > > > > PS: As Benoit suggested some time ago we might also consider to = rename > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > Regards, > > Mehmet > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > wrote: > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > wrote: > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > I disagree that the datastore model is a protocol specific = aspect. > > > > I consider datastores an architectural component binding data > > > > models and protocols together. In fact, the 'traditional' > > > > datastore model > > > > > > I would agree with this if datastores were a general concept in = YANG, but > the revised-datastores draft explicitly introduces the "intended" and = "applied" > datastores that may be irrelevant to other protocols using YANG, and = even > needn't be used in all NETCONF implementations. I wouldn't call this = "an > architectural component" of YANG. > > > > > > > An architectural component of this new management framework (that = does > > not have a name). The fact that not all protocols may expose all > > datastores is IMHO not a reason that the datastore model is not an > > architectural framework. > > > > > If you are saying that it will have nontrivial impact on YANG, I = would like to > see it explained in sec. 6.3. Without this information I am quite = reluctant to > agree with the adoption. > > > > An operational state datastore has implications how one writes data > > models. It may not directly affect YANG itself but surely the usage = of > > YANG. > > > > > See above - architectural aspects need to be relevant to all = protocols. > > > > Yes, but relevant to all protocols does not mean every protocol = needs > > to expose say all datastores. But every protocol should be clear = about > > how what it exposes relates to the architectural framework. > > > > > > > > There is a "current solution" consisting of hard-wired object > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution = does > > not require special protocols or datastores, but it is being = replaced by a > generic solution. > > > > If the "generic" solution requires special procedures which differ = on > > each protocol, then it might end up be worse than the hard-wired = solution > that works on every protocol. > > So I agree with Juergen that this is primarily an architectural = issue. > > > > > > /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 =20 > > https://www.ietf.org/mailman/listinfo/netmod > > -- > > Cheers, > > Mehmet > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org =20 > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netmod mailing list netmod@ietf.org =20 https://www.ietf.org/mailman/listinfo/netmod =20 =20 ------=_NextPart_000_00AF_01D2559B.36399180 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Technically = spoken actually both options work for me:

Keeping = current concept in 6241 or having everything in one = document.

I prefer the = latter.

 

We actually = don=E2=80=99t want to = remove <get>, only solve issues.

Any change = to <get> is for sure subject to WG = decision.

 

Mehmet

 

From:<= /b> = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Tuesday, = December 13, 2016 10:52 PM
To: Mehmet Ersue = <mersue@gmail.com>
Cc: Eric Voit (evoit) = <evoit@cisco.com>; Ladislav Lhotka <lhotka@nic.cz>; NetMod = WG Chairs <netmod-chairs@ietf.org>; NetConf WG Chairs = <netconf-chairs@ietf.org>; NetMod WG <netmod@ietf.org>; = Netconf <netconf@ietf.org>
Subject: Re: [netmod] = [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00

 

 

 

On Tue, = Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com> = wrote:

Hi = Andy,

 =

> This = architectural change needs to be implemented in various = protocols.

> I am = not sure a 6241bis is the best approach because it is not clear = which

> servers = really need to implement the revised datastores. 

 =

I agree = fully. This is the reason why I wrote in my mail:

 =

>> - a = new protocol- and language-independent standard document (RFC XYZ) = defining the generic datastore concept and framework and describing its = use (based on and following the DT solution draft),

>> - a = RFC6241bis draft removing the current datasore concept specification, = and getting rid of well-known issues e.g. with the <get> = operation,

 

I = do not agree with the text you wrote.

I do not want to remove candidate, running, and = startup from RFC 6241.

IMO = the new datastores can be defined in a new document that does not = redefine the existing datastores.

 

I = also do not want to get rid of <get>,  It works as = intended.

It is not a = problem on small devices.  It is not a problem on large devices = if

sufficient filtering is = used.  It does not differentiate between intended and applied = config

or understand = different types of config=3Dfalse nodes.  Use a new operation = to

add these = features.

 

 

 

 

 

Mehmet=

 

 

Andy

 

 

 =

From:<= /b> = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Dienstag, 13. = Dezember 2016 18:38
To: Eric Voit (evoit) <evoit@cisco.com>
Cc: Ladislav Lhotka = <lhotka@nic.cz>; MehmetErsue <mersue@gmail.com>; NetMod WG Chairs <netmod-chairs@ietf.org>; NetConf WG Chairs = <netconf-chairs@ietf.org>; NetMod WG <netmod@ietf.org>; Netconf <netconf@ietf.org>
Subject: Re: = [netmod] [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00

 

 

 

On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

I = support adoption, and like Mehmet's thinking as well.

Also worth = focusing on is transport protocol independent yang filtering.  So = along with how to frame get operations against one of the datastores, = how do you know which subtrees/nodes should be = included/excluded.

 

 

This architectural change needs to be implemented in various = protocols.

I am not sure a 6241bis is the best approach because it is not = clear which

servers really need to implement the revised datastores.  = Since RD is purely optional

to implement, it should not obsolete 6241 in any way.  It = should be possible

to add new operations and/or new parameters to existing = operations without

needing to redefine what is already = there.

 

The new protocol features need to explain how to = include/exclude subtrees.

IMO we should only support YANG defined data.  This = allows the solutions

to be generalized and reusable across protocols (e.g., using = YANG extensions).

 

 

Eric

 

 

Andy

 


> From: Netconf, December 9, 2016 7:49 = AM
>
> Hi Mehmet,
>
> I think I could just sign = your text at the bottom.
>
> Lada
>
> > On 9 = Dec 2016, at 13:25, MehmetErsue <mersue@gmail.com> wrote:
> >
> = > Hi All,
> >
> > I think the adoption of the DT = draft is fine. We agreed in IETF 97 to adopt and
> finalize the DT = draft in NETMOD WG, which I still support.
> >
> > I = believe the bigger issue is to agree on a plan concerning the related = work
> and the re-organization of existing standards. As a matter = of fact this plan will
> lead to updating the charter of two WGs = and the work we are going to start.
> >
> > I see the = DT document as a datastore solution proposal. There are = different
> gaps and issues which still need to be addressed and = the solution proposal
> needs yet to be discussed and finalized. = The document is providing information
> on the history, explaining = the need for a generic solution as well as is discussing
> = different scenarios. As such I believe the datastore solution proposal = from the
> DT should be published with the intended status = Informational RFC.
> >
> > Based on the finalized and = agreed datastore solution we should do different
> updates to = existing documents in NETCONF and NETMOD WGs. With this
> action = we can also fix well-known issues.
> >
> > Concerning = the NETCONF WG I would see it as valuable if we develop:
> > - = a RFC6241bis draft removing the current datasore concept
> > = specification, and getting rid of well-known issues e.g. with = the
> > <get> operation,
> > - a new protocol- = and language-independent standard document (RFC XYZ)
> > = defining the generic datastore concept and framework and = describing
> > its use (based on and following the DT solution = draft),
> > - adding potential extensions to RFC6241bis = (following the DT draft
> > and with a normative reference to = RFC XYZ),
> > - adding potential extensions to a RESTCONF-bis = RFC (following the DT
> > draft and with a normative reference = to RFC XYZ),
> >
> > Concerning the NETMOD WG I would = see it as valuable if we develop:
> > - RFC7950bis deleting = protocol-dependent details and specifying the
> > datastore = usage with YANG on a generic level (with a normative
> > = reference to RFC XYZ),
> > - adding potential extensions to = RFC7950bis, e.g. concerning the
> > proposed = <notification> element,
> > - possibly an RFC 6244bis to = describe architectural aspects. However RFC6244
> is Informational = and a RFC6244bis would be still Informational. I'm not sure
> = whether this is really necessary. The DT proposal does already describe = such a
> solution and can be seen as an update to RFC = 6244.
> > - RFC6087bis giving guidelines on how to use YANG = with the new datastore
> concept.
> >
> > = Referring to Lada's proposal concerning the spin off document = from
> > RFC7950 ("Adapting NETCONF for use with = YANG"), I think this can be
> provided in the corresponding = protocol RFCs, i.e.
> > for NETCONF a section on "Using = NETCONF with YANG" in RFC6241bis and
> for RESTCONF = "Using RESTCONF with YANG" in RESTCONF-bis RFC.
> = >
> > Hope this helps as a starting point on the way to a = good plan.
> >
> > PS: As Benoit suggested some time = ago we might also consider to rename
> NETCONF WG as it is not = only on NETCONF protocol anymore.
> >
> > = Regards,
> > Mehmet
> >
> > On Mon, Dec 5, = 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> wrote:
> > = On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-university.de> = wrote:
> > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav = Lhotka wrote:
> > >
> > > >
> > > = > I disagree that the datastore model is a protocol specific = aspect.
> > > > I consider datastores an architectural = component binding data
> > > > models and protocols = together. In fact, the 'traditional'
> > > > datastore = model
> > >
> > > I would agree with this if = datastores were a general concept in YANG, but
> the = revised-datastores draft explicitly introduces the "intended" = and "applied"
> datastores that may be irrelevant to = other protocols using YANG, and even
> needn't be used in all = NETCONF implementations. I wouldn't call this "an
> = architectural component" of YANG.
> > >
> = >
> > An architectural component of this new management = framework (that does
> > not have a name). The fact that not = all protocols may expose all
> > datastores is IMHO not a = reason that the datastore model is not an
> > architectural = framework.
> >
> > > If you are saying that it will = have nontrivial impact on YANG, I would like to
> see it explained = in sec. 6.3. Without this information I am quite reluctant to
> = agree with the adoption.
> >
> > An operational state = datastore has implications how one writes data
> > models. It = may not directly affect YANG itself but surely the usage of
> > = YANG.
> >
> > > See above - architectural aspects = need to be relevant to all protocols.
> >
> > Yes, but = relevant to all protocols does not mean every protocol needs
> = > to expose say all datastores. But every protocol should be clear = about
> > how what it exposes relates to the architectural = framework.
> >
> >
> >
> > There is = a "current solution" consisting of hard-wired object
> = > semantics (e.g., ifAdminStatus and ifOperStatus).  This = solution does
> > not require special protocols or datastores, = but it is being replaced by a
> generic solution.
> = >
> > If the "generic" solution requires special = procedures which differ on
> > each protocol, then it might end = up be worse than the hard-wired solution
> that works on every = protocol.
> > So I agree with Juergen that this is primarily an = architectural issue.
> >
> >
> > /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
>= ; > --
> > Cheers,
> > Mehmet
>
> = --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: = E74E8C0C
>
>
>
>
> = _______________________________________________
> Netconf mailing = list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

 

------=_NextPart_000_00AF_01D2559B.36399180-- From nobody Tue Dec 13 23:49:41 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883A8129C99 for ; Tue, 13 Dec 2016 23:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 wDSvk6bNePM9 for ; Tue, 13 Dec 2016 23:49:36 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 6A621129C80 for ; Tue, 13 Dec 2016 23:49:36 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 7C989F791A7C7 for ; Wed, 14 Dec 2016 07:49:31 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uBE7nVKs020318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Dec 2016 07:49:33 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uBE7mq3q018073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 14 Dec 2016 07:49:29 GMT Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Wed, 14 Dec 2016 08:49:11 +0100 From: "Bogaert, Bart (Nokia - BE)" To: "netconf@ietf.org" Thread-Topic: Question on NACM usage Thread-Index: AdJV3UXYgEg9XZFpRp2SVghevL67Og== Date: Wed, 14 Dec 2016 07:49:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00DC_01D255E6.EF6EA2D0" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Question on NACM usage X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 07:49:39 -0000 ------=_NextPart_000_00DC_01D255E6.EF6EA2D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00DD_01D255E6.EF6EA2D0" ------=_NextPart_001_00DD_01D255E6.EF6EA2D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi I would like to continue on one of the examples given in the appendix of the NACM RFC: permit-dummy-interface /acme:interfaces/acme:interface[acme:name='dummy'] read update permit Allow the limited and guest groups read and update access to the dummy interface. I am assuming that this rule allows read and update access to all leaves of the data node identified by the path, so it would allow to update a specific leaf of that data node. Is my understanding correct? Another question I have is related to the XPATH itself. In the above example I think that the name leaf is the key of the list. Can we use another leaf to identify a data node and allow specific access to that data node? Assume that there would be a leaf called 'pool-id' which can take values from 1 to 10, could the XPATH look like below? /acme:interfaces/acme:interface[acme:pool-id=5] We would like to allow/deny access to data nodes (and the leafs of that data node) to groups based on the value of the pool-id. Is the above the correct way to express the access control? Best regards - Vriendelijke groeten, Bart Bogaert Broadband-Access System Architect Data Contact number +32 3 2408310 (+32 477 673952) NOKIA Copernicuslaan 50, 2018 Antwerp, Belgium ------=_NextPart_001_00DD_01D255E6.EF6EA2D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

I would like to continue on one of the examples given in = the appendix of the NACM RFC:

 

       = <rule>

      &nbs= p;  = <name>permit-dummy-interface</name>

      &nbs= p;  <path = xmlns:acme=3D"http://example.com/ns/itf"><= /p>

      &nbs= p;    = /acme:interfaces/acme:interface[acme:name=3D'dummy']

      &nbs= p;  </path>

      &nbs= p;  <access-operations>read = update</access-operations>

      &nbs= p;  <action>permit</action>

      &nbs= p;  <comment>

      &nbs= p;    Allow the limited and guest groups = read

      &nbs= p;    and update access to the dummy = interface.

      &nbs= p;  </comment>

       = </rule>

 

I am assuming that this rule allows read and update access = to all leaves of the data node identified by the path, so it would allow = to update a specific leaf of that data node.  Is my understanding = correct?

Another question I have is related to the XPATH = itself.  In the above example I think that the name leaf is the key = of the list.  Can we use another leaf to identify a data node and = allow specific access to that data node?

Assume that there would be a leaf = called ‘pool-id’ which can take values from 1 to 10, could = the XPATH look like below?

 

      &nbs= p;  <path = xmlns:acme=3D"http://example.com/ns/itf"><= /p>

      &nbs= p;    = /acme:interfaces/acme:interface[acme:pool-id=3D5]

      &nbs= p;  </path>

 

We would like to allow/deny access to data nodes (and the = leafs of that data node) to groups based on the value of the = pool-id.  Is the above the correct way to express the access = control?

 

Best regards - Vriendelijke groeten,

Bart Bogaert

Broadband-Access System Architect Data

Contact number +32 3 2408310 (+32 477 = 673952)

 

NOKIA

Copernicuslaan 50, 2018 Antwerp, = Belgium

 

------=_NextPart_001_00DD_01D255E6.EF6EA2D0-- ------=_NextPart_000_00DC_01D255E6.EF6EA2D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMjE0MDc0OTA5WjAjBgkqhkiG9w0B CQQxFgQUIFhVBhzAlZ/r8QhkQMGHbeAz3xIwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQAU Tc/GRzViEMhjrJkfe5daAL6vOeKPMv92wew9KoEIqXgYiaLFeoA7Ey7OtUvExkypSUkXQWFEREba 9jUdKORuoKkMLNT2T3ukTbWnhy/oiZRpjr9nUT75rAkBzPt9NYO5xQcaubR0Szdc5XbQybc/eFfD AWhNMPQiRtXOzqih+OeWm1yiSbKwB7BJqrqPDJr06VsdsSUx0Hq41RVsiF+7D6TfAIG680dQ8God imSUBJc4TYBowbHFE0JC8QTkhQmUkuJb++L37CtZM8ZB0ptgoS9RnExbVvQrJ398GVZuilrOMsAG 2KAn5Jj1fTTdA9cibkvj8VF74VK6QhwPSQLPAAAAAAAA ------=_NextPart_000_00DC_01D255E6.EF6EA2D0-- From nobody Wed Dec 14 03:03:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34ED129A42 for ; Wed, 14 Dec 2016 03:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 r9nKsSS5Fx3e for ; Wed, 14 Dec 2016 03:03:16 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDF7129D30 for ; Wed, 14 Dec 2016 03:03:14 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id CC3441AE03EE; Wed, 14 Dec 2016 12:03:12 +0100 (CET) Date: Wed, 14 Dec 2016 12:03:11 +0100 (CET) Message-Id: <20161214.120311.1883256843897609564.mbj@tail-f.com> To: lmacko@cisco.com From: Martin Bjorklund In-Reply-To: <58ad2f124ce14b77a71e799c23801acd@XCH-ALN-015.cisco.com> References: <58ad2f124ce14b77a71e799c23801acd@XCH-ALN-015.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: Cc: netconf@ietf.org Subject: Re: [Netconf] netconf-config-change target in case of delete operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 11:03:21 -0000 "Lukas Macko -X (lmacko - PANTHEON TECHNOLOGIES at Cisco)" wrote: > Hi, > > I am trying to implement netconf-config-change notifications defined > in RFC6470. > > The issue I came across is that I am not sure what instance id should > be provided for leaf /netconf-config-change/list/target in case of > delete or remove operation. > Since the target leaf doesn't specify require-instance false in > schema, I can not specify instance id of deleted node to pass the > validation. I think the intention was that you should set the target to the deleted instance. But you are right, this would need a "require-instance false;". However, you can set it to the deleted node's parent and the operation to 'merge'. /martin From nobody Wed Dec 14 03:08:17 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E038F129D69; Wed, 14 Dec 2016 03:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 NqSSoyTw5SPQ; Wed, 14 Dec 2016 03:08:09 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8612D129D53; Wed, 14 Dec 2016 03:07:56 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 6459B1AE0457; Wed, 14 Dec 2016 12:07:55 +0100 (CET) Date: Wed, 14 Dec 2016 12:07:54 +0100 (CET) Message-Id: <20161214.120754.915451205380944115.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <004101d25589$a0cd5f20$e2681d60$@gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 11:08:16 -0000 Andy Bierman wrote: > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue wrote: > > > Hi Andy, > > > > > > > > > This architectural change needs to be implemented in various protocols. > > > > > I am not sure a 6241bis is the best approach because it is not clear > > which > > > > > servers really need to implement the revised datastores. > > > > > > > > I agree fully. This is the reason why I wrote in my mail: > > > > > > > > >> - a new protocol- and language-independent standard document (RFC XYZ) > > defining the generic datastore concept and framework and describing its use > > (based on and following the DT solution draft), > > > > >> - a RFC6241bis draft removing the current datasore concept > > specification, and getting rid of well-known issues e.g. with the > > operation, > > > > > I do not agree with the text you wrote. > I do not want to remove candidate, running, and startup from RFC 6241. > IMO the new datastores can be defined in a new document that does not > redefine the existing datastores. > > I also do not want to get rid of , It works as intended. > It is not a problem on small devices. Andy, the problem with has nothing to do with the size of the device. The problem is that returns two things (running config + operational state) in one merged output document. This forces people to split data models so that config and state are mutually exclusive (/interfaces and /interfaces-state). This draft proposes a fix for this, which makes less useful. /martin > It is not a problem on large devices > if > sufficient filtering is used. It does not differentiate between intended > and applied config > or understand different types of config=false nodes. Use a new operation to > add these features. > > > > > > > > Mehmet > > > > > Andy > > > > > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > > *Sent:* Dienstag, 13. Dezember 2016 18:38 > > *To:* Eric Voit (evoit) > > *Cc:* Ladislav Lhotka ; MehmetErsue ; > > NetMod WG Chairs ; NetConf WG Chairs < > > netconf-chairs@ietf.org>; NetMod WG ; Netconf < > > netconf@ietf.org> > > *Subject:* Re: [netmod] [Netconf] WG adoption poll > > draft-nmdsdt-netmod-revised-datastores-00 > > > > > > > > > > > > > > > > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > > wrote: > > > > I support adoption, and like Mehmet's thinking as well. > > > > Also worth focusing on is transport protocol independent yang filtering. > > So along with how to frame get operations against one of the datastores, > > how do you know which subtrees/nodes should be included/excluded. > > > > > > > > > > > > This architectural change needs to be implemented in various protocols. > > > > I am not sure a 6241bis is the best approach because it is not clear which > > > > servers really need to implement the revised datastores. Since RD is > > purely optional > > > > to implement, it should not obsolete 6241 in any way. It should be > > possible > > > > to add new operations and/or new parameters to existing operations without > > > > needing to redefine what is already there. > > > > > > > > The new protocol features need to explain how to include/exclude subtrees. > > > > IMO we should only support YANG defined data. This allows the solutions > > > > to be generalized and reusable across protocols (e.g., using YANG > > extensions). > > > > > > > > > > > > Eric > > > > > > > > > > > > Andy > > > > > > > > > > > From: Netconf, December 9, 2016 7:49 AM > > > > > > Hi Mehmet, > > > > > > I think I could just sign your text at the bottom. > > > > > > Lada > > > > > > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: > > > > > > > > Hi All, > > > > > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to > > adopt and > > > finalize the DT draft in NETMOD WG, which I still support. > > > > > > > > I believe the bigger issue is to agree on a plan concerning the > > related work > > > and the re-organization of existing standards. As a matter of fact this > > plan will > > > lead to updating the charter of two WGs and the work we are going to > > start. > > > > > > > > I see the DT document as a datastore solution proposal. There are > > different > > > gaps and issues which still need to be addressed and the solution > > proposal > > > needs yet to be discussed and finalized. The document is providing > > information > > > on the history, explaining the need for a generic solution as well as is > > discussing > > > different scenarios. As such I believe the datastore solution proposal > > from the > > > DT should be published with the intended status Informational RFC. > > > > > > > > Based on the finalized and agreed datastore solution we should do > > different > > > updates to existing documents in NETCONF and NETMOD WGs. With this > > > action we can also fix well-known issues. > > > > > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > > > - a RFC6241bis draft removing the current datasore concept > > > > specification, and getting rid of well-known issues e.g. with the > > > > operation, > > > > - a new protocol- and language-independent standard document (RFC XYZ) > > > > defining the generic datastore concept and framework and describing > > > > its use (based on and following the DT solution draft), > > > > - adding potential extensions to RFC6241bis (following the DT draft > > > > and with a normative reference to RFC XYZ), > > > > - adding potential extensions to a RESTCONF-bis RFC (following the DT > > > > draft and with a normative reference to RFC XYZ), > > > > > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > > > - RFC7950bis deleting protocol-dependent details and specifying the > > > > datastore usage with YANG on a generic level (with a normative > > > > reference to RFC XYZ), > > > > - adding potential extensions to RFC7950bis, e.g. concerning the > > > > proposed element, > > > > - possibly an RFC 6244bis to describe architectural aspects. However > > RFC6244 > > > is Informational and a RFC6244bis would be still Informational. I'm not > > sure > > > whether this is really necessary. The DT proposal does already describe > > such a > > > solution and can be seen as an update to RFC 6244. > > > > - RFC6087bis giving guidelines on how to use YANG with the new > > datastore > > > concept. > > > > > > > > Referring to Lada's proposal concerning the spin off document from > > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > > > provided in the corresponding protocol RFCs, i.e. > > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > > > > > Hope this helps as a starting point on the way to a good plan. > > > > > > > > PS: As Benoit suggested some time ago we might also consider to rename > > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > > > > > Regards, > > > > Mehmet > > > > > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > > wrote: > > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > > wrote: > > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > > > > > > > I disagree that the datastore model is a protocol specific aspect. > > > > > > I consider datastores an architectural component binding data > > > > > > models and protocols together. In fact, the 'traditional' > > > > > > datastore model > > > > > > > > > > I would agree with this if datastores were a general concept in > > YANG, but > > > the revised-datastores draft explicitly introduces the "intended" and > > "applied" > > > datastores that may be irrelevant to other protocols using YANG, and even > > > needn't be used in all NETCONF implementations. I wouldn't call this "an > > > architectural component" of YANG. > > > > > > > > > > > > > An architectural component of this new management framework (that does > > > > not have a name). The fact that not all protocols may expose all > > > > datastores is IMHO not a reason that the datastore model is not an > > > > architectural framework. > > > > > > > > > If you are saying that it will have nontrivial impact on YANG, I > > would like to > > > see it explained in sec. 6.3. Without this information I am quite > > reluctant to > > > agree with the adoption. > > > > > > > > An operational state datastore has implications how one writes data > > > > models. It may not directly affect YANG itself but surely the usage of > > > > YANG. > > > > > > > > > See above - architectural aspects need to be relevant to all > > protocols. > > > > > > > > Yes, but relevant to all protocols does not mean every protocol needs > > > > to expose say all datastores. But every protocol should be clear about > > > > how what it exposes relates to the architectural framework. > > > > > > > > > > > > > > > > There is a "current solution" consisting of hard-wired object > > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution does > > > > not require special protocols or datastores, but it is being replaced > > by a > > > generic solution. > > > > > > > > If the "generic" solution requires special procedures which differ on > > > > each protocol, then it might end up be worse than the hard-wired > > solution > > > that works on every protocol. > > > > So I agree with Juergen that this is primarily an architectural issue. > > > > > > > > > > > > /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 > > > > -- > > > > Cheers, > > > > Mehmet > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > From nobody Wed Dec 14 03:22:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBE2129D87 for ; Wed, 14 Dec 2016 03:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 XQaZMZHvrbo8 for ; Wed, 14 Dec 2016 03:22:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 85751129D8F for ; Wed, 14 Dec 2016 03:22:07 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 8CB711AE03EE; Wed, 14 Dec 2016 12:22:06 +0100 (CET) Date: Wed, 14 Dec 2016 12:22:05 +0100 (CET) Message-Id: <20161214.122205.1943287191256158009.mbj@tail-f.com> To: bart.bogaert@nokia.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Question on NACM usage X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 11:22:33 -0000 "Bogaert, Bart (Nokia - BE)" wrote: > Hi > > > > I would like to continue on one of the examples given in the appendix of the > NACM RFC: > > > > > > permit-dummy-interface > > > > /acme:interfaces/acme:interface[acme:name='dummy'] > > > > read update > > permit > > > > Allow the limited and guest groups read > > and update access to the dummy interface. > > > > > > > > I am assuming that this rule allows read and update access to all leaves of > the data node identified by the path, so it would allow to update a specific > leaf of that data node. Is my understanding correct? Yes. (not just leafs but also leaf-lists and containers and lists). > Another question I have is related to the XPATH itself. In the above > example I think that the name leaf is the key of the list. Can we use > another leaf to identify a data node and allow specific access to that data > node? No. > Assume that there would be a leaf called 'pool-id' which can take values > from 1 to 10, could the XPATH look like below? > > > > > > /acme:interfaces/acme:interface[acme:pool-id=5] > > > > > > We would like to allow/deny access to data nodes (and the leafs of that data > node) to groups based on the value of the pool-id. Is the above the correct > way to express the access control? No this is not possible. The reason is that if we allow any XPath expression here, the complexity of implementing this increases dramatically. Also the complexity of using this and understanding how rules interact will increase, thus increasing the risk of mis-configuration (which would be security impacting). /martin From nobody Wed Dec 14 03:40:02 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF9F129DCF for ; Wed, 14 Dec 2016 03:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 trPa4EOwmowD for ; Wed, 14 Dec 2016 03:39:59 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2C5D129DBF for ; Wed, 14 Dec 2016 03:39:59 -0800 (PST) Received: from mars.tail-f.com (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id A2EC51AE03EE; Wed, 14 Dec 2016 12:39:57 +0100 (CET) To: Martin Bjorklund References: <20161214.122205.1943287191256158009.mbj@tail-f.com> From: Per Hedeland Message-ID: <58512F8D.5000404@tail-f.com> Date: Wed, 14 Dec 2016 12:39:57 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20161214.122205.1943287191256158009.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Question on NACM usage X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 11:40:01 -0000 On 2016-12-14 12:22, Martin Bjorklund wrote: > > No this is not possible. The reason is that if we allow any XPath > expression here, the complexity of implementing this increases > dramatically. Also the complexity of using this and understanding how > rules interact will increase, thus increasing the risk of > mis-configuration (which would be security impacting). ...and of course, the spec says that it's not possible - RFC 6536: typedef node-instance-identifier { type yang:xpath1.0; description "Path expression used to represent a special data node instance identifier string. A node-instance-identifier value is an unrestricted YANG instance-identifier expression. All the same rules as an instance-identifier apply except predicates for keys are optional. If a key predicate is missing, then the node-instance-identifier represents all possible server instances for that key. RFC 6020, section 9.13: The syntax for an instance-identifier is a subset of the XPath abbreviated syntax, formally defined by the rule "instance-identifier" in Section 12. It is used to uniquely identify a node in the data tree. Predicates are used only for specifying the values for the key nodes for list entries, a value of a leaf-list entry, or a positional index for a list without keys. For identifying list entries with keys, each predicate consists of one equality test per key, and each key MUST have a corresponding predicate. --Per Hedeland From nobody Wed Dec 14 06:09:22 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADBA1296A8 for ; Wed, 14 Dec 2016 06:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAUYOEhJJI-q for ; Wed, 14 Dec 2016 06:09:16 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450A7129692 for ; Wed, 14 Dec 2016 06:09:13 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id n6so23928878qtd.1 for ; Wed, 14 Dec 2016 06:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L5VlPjZ9QV78j/ZwMfb+EayVzFvhy2co8v24/eN+ZdE=; b=c6AQHQgAHKyRAGxaaXejvLOBSwFL0vLPdkv5xTkEJ4kKVxqxf4fT4ayjWuDV0iGh/K rLgbn04ef90vBGH0NlvxAP3aW60DvLycqQuRFC8cfVKXocyMxt6q+PVuj3LZWqFqid+y U2GSGvWSMT10NazEXe2kvgx2S4Flfuc5joBioflU26vcF1j/0BFEE+XMgiieLxfT+H+Y fVwDDRQD8wfleEqYPheH83/OxGMIqKDTVGK+EeI09SGFR4imCUE6F5wwJuwOecit+GN0 01oOZDMDCSaIDNS7tJJ3s/LxC0u6DHTq6tV0Qdtn5OmTroTCuPv3eS8BEGS0no1hWQZF P2oA== 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=L5VlPjZ9QV78j/ZwMfb+EayVzFvhy2co8v24/eN+ZdE=; b=bB3qnFxb64z+n2p2mjcKvqgZ4G7aF8HdBXpxj7zjNfv16FxhRCsxe/3wiXeAQrEAo0 hz3BJhisl1JVLGipv9yMB0xyNGQdw7QlRu0b1or/yG2jK11nK08T0CZH8oH3HpJUNos0 B9KHE0FtBCh4rEeFJENTERdBgOUkFOIeITS6gep9zgsjBjU7oVYQ3uQ/9asvIqqnNMIs Xq5XzX7q3gJyPurgei1UXGhL3ppZRvRjloizDoNHvSaQH++iJjOwgXJYOyh+C1p/sdd2 2tv0wwnYO4k/N4J4fqT1VL+XwjCxxBqgF9B+7bHgvY9aYCmK44V2DbI/mjW1souWdPIS ldzQ== X-Gm-Message-State: AKaTC00aNSKNgzCHEIdawvULjjQF9ohhqWZEDaRurot897E4XkyWwPLEZC14lcrkt0SWAIj2EC6ox+iEfeyQfw== X-Received: by 10.237.48.139 with SMTP id 11mr87043764qtf.219.1481724552333; Wed, 14 Dec 2016 06:09:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Wed, 14 Dec 2016 06:09:11 -0800 (PST) In-Reply-To: <20161214.120754.915451205380944115.mbj@tail-f.com> References: <004101d25589$a0cd5f20$e2681d60$@gmail.com> <20161214.120754.915451205380944115.mbj@tail-f.com> From: Andy Bierman Date: Wed, 14 Dec 2016 06:09:11 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=94eb2c0c865a9903a305439ee1e1 Archived-At: Cc: NetMod WG Chairs , "netmod@ietf.org" , NETCONF Working Group , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 14:09:20 -0000 --94eb2c0c865a9903a305439ee1e1 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue wrote: > > > > > Hi Andy, > > > > > > > > > > > > > This architectural change needs to be implemented in various > protocols. > > > > > > > I am not sure a 6241bis is the best approach because it is not clear > > > which > > > > > > > servers really need to implement the revised datastores. > > > > > > > > > > > > I agree fully. This is the reason why I wrote in my mail: > > > > > > > > > > > > >> - a new protocol- and language-independent standard document (RFC > XYZ) > > > defining the generic datastore concept and framework and describing > its use > > > (based on and following the DT solution draft), > > > > > > >> - a RFC6241bis draft removing the current datasore concept > > > specification, and getting rid of well-known issues e.g. with the > > > operation, > > > > > > > > I do not agree with the text you wrote. > > I do not want to remove candidate, running, and startup from RFC 6241. > > IMO the new datastores can be defined in a new document that does not > > redefine the existing datastores. > > > > I also do not want to get rid of , It works as intended. > > It is not a problem on small devices. > > Andy, the problem with has nothing to do with the size of the > device. The problem is that returns two things (running config > + operational state) in one merged output document. This forces > people to split data models so that config and state are mutually > exclusive (/interfaces and /interfaces-state). This draft proposes a > fix for this, which makes less useful. > > This "problem" exists for some new overloaded use of that did not exist before. The operation only mixes config=true and config=false. It never had anything to do with intended vs. applied. IMO your proposed solution is not very backward compatible with simple systems that do not have delays between intended and applied. > > /martin > Andy > > > > > It is not a problem on large devices > > if > > sufficient filtering is used. It does not differentiate between intended > > and applied config > > or understand different types of config=false nodes. Use a new > operation to > > add these features. > > > > > > > > > > > > > > > Mehmet > > > > > > > > > Andy > > > > > > > > > > > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > > > *Sent:* Dienstag, 13. Dezember 2016 18:38 > > > *To:* Eric Voit (evoit) > > > *Cc:* Ladislav Lhotka ; MehmetErsue ; > > > NetMod WG Chairs ; NetConf WG Chairs < > > > netconf-chairs@ietf.org>; NetMod WG ; Netconf < > > > netconf@ietf.org> > > > *Subject:* Re: [netmod] [Netconf] WG adoption poll > > > draft-nmdsdt-netmod-revised-datastores-00 > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > > > wrote: > > > > > > I support adoption, and like Mehmet's thinking as well. > > > > > > Also worth focusing on is transport protocol independent yang > filtering. > > > So along with how to frame get operations against one of the > datastores, > > > how do you know which subtrees/nodes should be included/excluded. > > > > > > > > > > > > > > > > > > This architectural change needs to be implemented in various protocols. > > > > > > I am not sure a 6241bis is the best approach because it is not clear > which > > > > > > servers really need to implement the revised datastores. Since RD is > > > purely optional > > > > > > to implement, it should not obsolete 6241 in any way. It should be > > > possible > > > > > > to add new operations and/or new parameters to existing operations > without > > > > > > needing to redefine what is already there. > > > > > > > > > > > > The new protocol features need to explain how to include/exclude > subtrees. > > > > > > IMO we should only support YANG defined data. This allows the > solutions > > > > > > to be generalized and reusable across protocols (e.g., using YANG > > > extensions). > > > > > > > > > > > > > > > > > > Eric > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > From: Netconf, December 9, 2016 7:49 AM > > > > > > > > Hi Mehmet, > > > > > > > > I think I could just sign your text at the bottom. > > > > > > > > Lada > > > > > > > > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: > > > > > > > > > > Hi All, > > > > > > > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 > to > > > adopt and > > > > finalize the DT draft in NETMOD WG, which I still support. > > > > > > > > > > I believe the bigger issue is to agree on a plan concerning the > > > related work > > > > and the re-organization of existing standards. As a matter of fact > this > > > plan will > > > > lead to updating the charter of two WGs and the work we are going to > > > start. > > > > > > > > > > I see the DT document as a datastore solution proposal. There are > > > different > > > > gaps and issues which still need to be addressed and the solution > > > proposal > > > > needs yet to be discussed and finalized. The document is providing > > > information > > > > on the history, explaining the need for a generic solution as well > as is > > > discussing > > > > different scenarios. As such I believe the datastore solution > proposal > > > from the > > > > DT should be published with the intended status Informational RFC. > > > > > > > > > > Based on the finalized and agreed datastore solution we should do > > > different > > > > updates to existing documents in NETCONF and NETMOD WGs. With this > > > > action we can also fix well-known issues. > > > > > > > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > > > > - a RFC6241bis draft removing the current datasore concept > > > > > specification, and getting rid of well-known issues e.g. with the > > > > > operation, > > > > > - a new protocol- and language-independent standard document (RFC > XYZ) > > > > > defining the generic datastore concept and framework and describing > > > > > its use (based on and following the DT solution draft), > > > > > - adding potential extensions to RFC6241bis (following the DT draft > > > > > and with a normative reference to RFC XYZ), > > > > > - adding potential extensions to a RESTCONF-bis RFC (following the > DT > > > > > draft and with a normative reference to RFC XYZ), > > > > > > > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > > > > - RFC7950bis deleting protocol-dependent details and specifying the > > > > > datastore usage with YANG on a generic level (with a normative > > > > > reference to RFC XYZ), > > > > > - adding potential extensions to RFC7950bis, e.g. concerning the > > > > > proposed element, > > > > > - possibly an RFC 6244bis to describe architectural aspects. > However > > > RFC6244 > > > > is Informational and a RFC6244bis would be still Informational. I'm > not > > > sure > > > > whether this is really necessary. The DT proposal does already > describe > > > such a > > > > solution and can be seen as an update to RFC 6244. > > > > > - RFC6087bis giving guidelines on how to use YANG with the new > > > datastore > > > > concept. > > > > > > > > > > Referring to Lada's proposal concerning the spin off document from > > > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > > > > provided in the corresponding protocol RFCs, i.e. > > > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis > and > > > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > > > > > > > Hope this helps as a starting point on the way to a good plan. > > > > > > > > > > PS: As Benoit suggested some time ago we might also consider to > rename > > > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > > > > > > > Regards, > > > > > Mehmet > > > > > > > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > > > wrote: > > > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > > > wrote: > > > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > > > > > > > > > > I disagree that the datastore model is a protocol specific > aspect. > > > > > > > I consider datastores an architectural component binding data > > > > > > > models and protocols together. In fact, the 'traditional' > > > > > > > datastore model > > > > > > > > > > > > I would agree with this if datastores were a general concept in > > > YANG, but > > > > the revised-datastores draft explicitly introduces the "intended" and > > > "applied" > > > > datastores that may be irrelevant to other protocols using YANG, and > even > > > > needn't be used in all NETCONF implementations. I wouldn't call this > "an > > > > architectural component" of YANG. > > > > > > > > > > > > > > > > An architectural component of this new management framework (that > does > > > > > not have a name). The fact that not all protocols may expose all > > > > > datastores is IMHO not a reason that the datastore model is not an > > > > > architectural framework. > > > > > > > > > > > If you are saying that it will have nontrivial impact on YANG, I > > > would like to > > > > see it explained in sec. 6.3. Without this information I am quite > > > reluctant to > > > > agree with the adoption. > > > > > > > > > > An operational state datastore has implications how one writes data > > > > > models. It may not directly affect YANG itself but surely the > usage of > > > > > YANG. > > > > > > > > > > > See above - architectural aspects need to be relevant to all > > > protocols. > > > > > > > > > > Yes, but relevant to all protocols does not mean every protocol > needs > > > > > to expose say all datastores. But every protocol should be clear > about > > > > > how what it exposes relates to the architectural framework. > > > > > > > > > > > > > > > > > > > > There is a "current solution" consisting of hard-wired object > > > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution > does > > > > > not require special protocols or datastores, but it is being > replaced > > > by a > > > > generic solution. > > > > > > > > > > If the "generic" solution requires special procedures which differ > on > > > > > each protocol, then it might end up be worse than the hard-wired > > > solution > > > > that works on every protocol. > > > > > So I agree with Juergen that this is primarily an architectural > issue. > > > > > > > > > > > > > > > /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 > > > > > -- > > > > > Cheers, > > > > > Mehmet > > > > > > > > -- > > > > Ladislav Lhotka, CZ.NIC Labs > > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > --94eb2c0c865a9903a305439ee1e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com> wrote:
>
> > Hi Andy,
> >
> >
> >
> > > This architectural change needs to be implemented in various= protocols.
> >
> > > I am not sure a 6241bis is the best approach because it is n= ot clear
> > which
> >
> > > servers really need to implement the revised datastores.
> >
> >
> >
> > I agree fully. This is the reason why I wrote in my mail:
> >
> >
> >
> > >> - a new protocol- and language-independent standard docu= ment (RFC XYZ)
> > defining the generic datastore concept and framework and describi= ng its use
> > (based on and following the DT solution draft),
> >
> > >> - a RFC6241bis draft removing the current datasore conce= pt
> > specification, and getting rid of well-known issues e.g. with the= <get>
> > operation,
> >
> >
> I do not agree with the text you wrote.
> I do not want to remove candidate, running, and startup from RFC 6241.=
> IMO the new datastores can be defined in a new document that does not<= br> > redefine the existing datastores.
>
> I also do not want to get rid of <get>,=C2=A0 It works as intend= ed.
> It is not a problem on small devices.

Andy, the problem with <get> has nothing to do with the size of the device.=C2=A0 The problem is that <get> returns two things (running c= onfig
+ operational state) in one merged output document.=C2=A0 This forces
people to split data models so that config and state are mutually
exclusive (/interfaces and /interfaces-state).=C2=A0 This draft proposes a<= br> fix for this, which makes <get> less useful.


This "problem" exists for so= me new overloaded use of <get> that did not exist before.
T= he <get> operation only mixes config=3Dtrue and config=3Dfalse. It ne= ver had anything
to do with intended vs. applied.=C2=A0 IMO your = proposed solution is not very backward compatible
with simple sys= tems that do not have delays between intended and applied.

=C2=A0

/martin


Andy
= =C2=A0



> It is not a problem on large devices
> if
> sufficient filtering is used.=C2=A0 It does not differentiate between = intended
> and applied config
> or understand different types of config=3Dfalse nodes.=C2=A0 Use a new= operation to
> add these features.
>
>
>
>
>
>
> > Mehmet
> >
>
>
> Andy
>
>
>
> >
> >
> > *From:* Andy Bierman [mailto:andy@yumaworks.com]
> > *Sent:* Dienstag, 13. Dezember 2016 18:38
> > *To:* Eric Voit (evoit) <ev= oit@cisco.com>
> > *Cc:* Ladislav Lhotka <lhotka= @nic.cz>; MehmetErsue <mersue= @gmail.com>;
> > NetMod WG Chairs <ne= tmod-chairs@ietf.org>; NetConf WG Chairs <
> > netconf-chairs@ietf.or= g>; NetMod WG <netmod@ietf.org= >; Netconf <
> > netconf@ietf.org>
> > *Subject:* Re: [netmod] [Netconf] WG adoption poll
> > draft-nmdsdt-netmod-revised-datastores-00
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com>
> > wrote:
> >
> > I support adoption, and like Mehmet's thinking as well.
> >
> > Also worth focusing on is transport protocol independent yang fil= tering.
> > So along with how to frame get operations against one of the data= stores,
> > how do you know which subtrees/nodes should be included/excluded.=
> >
> >
> >
> >
> >
> > This architectural change needs to be implemented in various prot= ocols.
> >
> > I am not sure a 6241bis is the best approach because it is not cl= ear which
> >
> > servers really need to implement the revised datastores.=C2=A0 Si= nce RD is
> > purely optional
> >
> > to implement, it should not obsolete 6241 in any way.=C2=A0 It sh= ould be
> > possible
> >
> > to add new operations and/or new parameters to existing operation= s without
> >
> > needing to redefine what is already there.
> >
> >
> >
> > The new protocol features need to explain how to include/exclude = subtrees.
> >
> > IMO we should only support YANG defined data.=C2=A0 This allows t= he solutions
> >
> > to be generalized and reusable across protocols (e.g., using YANG=
> > extensions).
> >
> >
> >
> >
> >
> > Eric
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> > > From: Netconf, December 9, 2016 7:49 AM
> > >
> > > Hi Mehmet,
> > >
> > > I think I could just sign your text at the bottom.
> > >
> > > Lada
> > >
> > > > On 9 Dec 2016, at 13:25, MehmetErsue <mersue@gmail.com> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I think the adoption of the DT draft is fine. We agreed= in IETF 97 to
> > adopt and
> > > finalize the DT draft in NETMOD WG, which I still support. > > > >
> > > > I believe the bigger issue is to agree on a plan concer= ning the
> > related work
> > > and the re-organization of existing standards. As a matter o= f fact this
> > plan will
> > > lead to updating the charter of two WGs and the work we are = going to
> > start.
> > > >
> > > > I see the DT document as a datastore solution proposal.= There are
> > different
> > > gaps and issues which still need to be addressed and the sol= ution
> > proposal
> > > needs yet to be discussed and finalized. The document is pro= viding
> > information
> > > on the history, explaining the need for a generic solution a= s well as is
> > discussing
> > > different scenarios. As such I believe the datastore solutio= n proposal
> > from the
> > > DT should be published with the intended status Informationa= l RFC.
> > > >
> > > > Based on the finalized and agreed datastore solution we= should do
> > different
> > > updates to existing documents in NETCONF and NETMOD WGs. Wit= h this
> > > action we can also fix well-known issues.
> > > >
> > > > Concerning the NETCONF WG I would see it as valuable if= we develop:
> > > > - a RFC6241bis draft removing the current datasore conc= ept
> > > > specification, and getting rid of well-known issues e.g= . with the
> > > > <get> operation,
> > > > - a new protocol- and language-independent standard doc= ument (RFC XYZ)
> > > > defining the generic datastore concept and framework an= d describing
> > > > its use (based on and following the DT solution draft),=
> > > > - adding potential extensions to RFC6241bis (following = the DT draft
> > > > and with a normative reference to RFC XYZ),
> > > > - adding potential extensions to a RESTCONF-bis RFC (fo= llowing the DT
> > > > draft and with a normative reference to RFC XYZ),
> > > >
> > > > Concerning the NETMOD WG I would see it as valuable if = we develop:
> > > > - RFC7950bis deleting protocol-dependent details and sp= ecifying the
> > > > datastore usage with YANG on a generic level (with a no= rmative
> > > > reference to RFC XYZ),
> > > > - adding potential extensions to RFC7950bis, e.g. conce= rning the
> > > > proposed <notification> element,
> > > > - possibly an RFC 6244bis to describe architectural asp= ects. However
> > RFC6244
> > > is Informational and a RFC6244bis would be still Information= al. I'm not
> > sure
> > > whether this is really necessary. The DT proposal does alrea= dy describe
> > such a
> > > solution and can be seen as an update to RFC 6244.
> > > > - RFC6087bis giving guidelines on how to use YANG with = the new
> > datastore
> > > concept.
> > > >
> > > > Referring to Lada's proposal concerning the spin of= f document from
> > > > RFC7950 ("Adapting NETCONF for use with YANG"= ), I think this can be
> > > provided in the corresponding protocol RFCs, i.e.
> > > > for NETCONF a section on "Using NETCONF with YANG&= quot; in RFC6241bis and
> > > for RESTCONF "Using RESTCONF with YANG" in RESTCON= F-bis RFC.
> > > >
> > > > Hope this helps as a starting point on the way to a goo= d plan.
> > > >
> > > > PS: As Benoit suggested some time ago we might also con= sider to rename
> > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > >
> > > > Regards,
> > > > Mehmet
> > > >
> > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> > > wrote:
> > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > > <= j.schoenwaelder@jacobs-university.de> wrote:
> > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhot= ka wrote:
> > > > >
> > > > > >
> > > > > > I disagree that the datastore model is a prot= ocol specific aspect.
> > > > > > I consider datastores an architectural compon= ent binding data
> > > > > > models and protocols together. In fact, the &= #39;traditional'
> > > > > > datastore model
> > > > >
> > > > > I would agree with this if datastores were a gener= al concept in
> > YANG, but
> > > the revised-datastores draft explicitly introduces the "= ;intended" and
> > "applied"
> > > datastores that may be irrelevant to other protocols using Y= ANG, and even
> > > needn't be used in all NETCONF implementations. I wouldn= 't call this "an
> > > architectural component" of YANG.
> > > > >
> > > >
> > > > An architectural component of this new management frame= work (that does
> > > > not have a name). The fact that not all protocols may e= xpose all
> > > > datastores is IMHO not a reason that the datastore mode= l is not an
> > > > architectural framework.
> > > >
> > > > > If you are saying that it will have nontrivial imp= act on YANG, I
> > would like to
> > > see it explained in sec. 6.3. Without this information I am = quite
> > reluctant to
> > > agree with the adoption.
> > > >
> > > > An operational state datastore has implications how one= writes data
> > > > models. It may not directly affect YANG itself but sure= ly the usage of
> > > > YANG.
> > > >
> > > > > See above - architectural aspects need to be relev= ant to all
> > protocols.
> > > >
> > > > Yes, but relevant to all protocols does not mean every = protocol needs
> > > > to expose say all datastores. But every protocol should= be clear about
> > > > how what it exposes relates to the architectural framew= ork.
> > > >
> > > >
> > > >
> > > > There is a "current solution" consisting of h= ard-wired object
> > > > semantics (e.g., ifAdminStatus and ifOperStatus).=C2=A0= This solution does
> > > > not require special protocols or datastores, but it is = being replaced
> > by a
> > > generic solution.
> > > >
> > > > If the "generic" solution requires special pr= ocedures which differ on
> > > > each protocol, then it might end up be worse than the h= ard-wired
> > solution
> > > that works on every protocol.
> > > > So I agree with Juergen that this is primarily an archi= tectural issue.
> > > >
> > > >
> > > > /js
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > > --
> > > > 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<= br> > > > > https://www.ietf.org/mailman/li= stinfo/netmod
> > > > --
> > > > Cheers,
> > > > Mehmet
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listin= fo/netconf
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/net= mod
> >
> >
> >

--94eb2c0c865a9903a305439ee1e1-- From nobody Wed Dec 14 06:25:36 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB758129A65; Wed, 14 Dec 2016 06:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRMZMaw9SbB5; Wed, 14 Dec 2016 06:25:32 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B02641296DE; Wed, 14 Dec 2016 06:25:30 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2FFC51CC02AA; Wed, 14 Dec 2016 15:25:30 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Mehmet Ersue In-Reply-To: References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> Date: Wed, 14 Dec 2016 15:25:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 14:25:35 -0000 Andy Bierman writes: > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue wrote: > >> Hi Andy, >> >> >> >> > This architectural change needs to be implemented in various protocols. >> >> > I am not sure a 6241bis is the best approach because it is not clear >> which >> >> > servers really need to implement the revised datastores. >> >> >> >> I agree fully. This is the reason why I wrote in my mail: >> >> >> >> >> - a new protocol- and language-independent standard document (RFC XYZ) >> defining the generic datastore concept and framework and describing its use >> (based on and following the DT solution draft), >> >> >> - a RFC6241bis draft removing the current datasore concept >> specification, and getting rid of well-known issues e.g. with the >> operation, >> >> > I do not agree with the text you wrote. > I do not want to remove candidate, running, and startup from RFC 6241. > IMO the new datastores can be defined in a new document that does not > redefine the existing datastores. As for candidate, it is optional and we all know that it is quite problematic if concurrent access of multiple clients is possible. Therefore, it would IMO be a good riddance. Lada > > I also do not want to get rid of , It works as intended. > It is not a problem on small devices. It is not a problem on large devices > if > sufficient filtering is used. It does not differentiate between intended > and applied config > or understand different types of config=false nodes. Use a new operation to > add these features. > > > > > > >> Mehmet >> > > > Andy > > > >> >> >> *From:* Andy Bierman [mailto:andy@yumaworks.com] >> *Sent:* Dienstag, 13. Dezember 2016 18:38 >> *To:* Eric Voit (evoit) >> *Cc:* Ladislav Lhotka ; MehmetErsue ; >> NetMod WG Chairs ; NetConf WG Chairs < >> netconf-chairs@ietf.org>; NetMod WG ; Netconf < >> netconf@ietf.org> >> *Subject:* Re: [netmod] [Netconf] WG adoption poll >> draft-nmdsdt-netmod-revised-datastores-00 >> >> >> >> >> >> >> >> On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) >> wrote: >> >> I support adoption, and like Mehmet's thinking as well. >> >> Also worth focusing on is transport protocol independent yang filtering. >> So along with how to frame get operations against one of the datastores, >> how do you know which subtrees/nodes should be included/excluded. >> >> >> >> >> >> This architectural change needs to be implemented in various protocols. >> >> I am not sure a 6241bis is the best approach because it is not clear which >> >> servers really need to implement the revised datastores. Since RD is >> purely optional >> >> to implement, it should not obsolete 6241 in any way. It should be >> possible >> >> to add new operations and/or new parameters to existing operations without >> >> needing to redefine what is already there. >> >> >> >> The new protocol features need to explain how to include/exclude subtrees. >> >> IMO we should only support YANG defined data. This allows the solutions >> >> to be generalized and reusable across protocols (e.g., using YANG >> extensions). >> >> >> >> >> >> Eric >> >> >> >> >> >> Andy >> >> >> >> >> > From: Netconf, December 9, 2016 7:49 AM >> > >> > Hi Mehmet, >> > >> > I think I could just sign your text at the bottom. >> > >> > Lada >> > >> > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: >> > > >> > > Hi All, >> > > >> > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to >> adopt and >> > finalize the DT draft in NETMOD WG, which I still support. >> > > >> > > I believe the bigger issue is to agree on a plan concerning the >> related work >> > and the re-organization of existing standards. As a matter of fact this >> plan will >> > lead to updating the charter of two WGs and the work we are going to >> start. >> > > >> > > I see the DT document as a datastore solution proposal. There are >> different >> > gaps and issues which still need to be addressed and the solution >> proposal >> > needs yet to be discussed and finalized. The document is providing >> information >> > on the history, explaining the need for a generic solution as well as is >> discussing >> > different scenarios. As such I believe the datastore solution proposal >> from the >> > DT should be published with the intended status Informational RFC. >> > > >> > > Based on the finalized and agreed datastore solution we should do >> different >> > updates to existing documents in NETCONF and NETMOD WGs. With this >> > action we can also fix well-known issues. >> > > >> > > Concerning the NETCONF WG I would see it as valuable if we develop: >> > > - a RFC6241bis draft removing the current datasore concept >> > > specification, and getting rid of well-known issues e.g. with the >> > > operation, >> > > - a new protocol- and language-independent standard document (RFC XYZ) >> > > defining the generic datastore concept and framework and describing >> > > its use (based on and following the DT solution draft), >> > > - adding potential extensions to RFC6241bis (following the DT draft >> > > and with a normative reference to RFC XYZ), >> > > - adding potential extensions to a RESTCONF-bis RFC (following the DT >> > > draft and with a normative reference to RFC XYZ), >> > > >> > > Concerning the NETMOD WG I would see it as valuable if we develop: >> > > - RFC7950bis deleting protocol-dependent details and specifying the >> > > datastore usage with YANG on a generic level (with a normative >> > > reference to RFC XYZ), >> > > - adding potential extensions to RFC7950bis, e.g. concerning the >> > > proposed element, >> > > - possibly an RFC 6244bis to describe architectural aspects. However >> RFC6244 >> > is Informational and a RFC6244bis would be still Informational. I'm not >> sure >> > whether this is really necessary. The DT proposal does already describe >> such a >> > solution and can be seen as an update to RFC 6244. >> > > - RFC6087bis giving guidelines on how to use YANG with the new >> datastore >> > concept. >> > > >> > > Referring to Lada's proposal concerning the spin off document from >> > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be >> > provided in the corresponding protocol RFCs, i.e. >> > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and >> > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. >> > > >> > > Hope this helps as a starting point on the way to a good plan. >> > > >> > > PS: As Benoit suggested some time ago we might also consider to rename >> > NETCONF WG as it is not only on NETCONF protocol anymore. >> > > >> > > Regards, >> > > Mehmet >> > > >> > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman >> > wrote: >> > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder >> > wrote: >> > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: >> > > > >> > > > > >> > > > > I disagree that the datastore model is a protocol specific aspect. >> > > > > I consider datastores an architectural component binding data >> > > > > models and protocols together. In fact, the 'traditional' >> > > > > datastore model >> > > > >> > > > I would agree with this if datastores were a general concept in >> YANG, but >> > the revised-datastores draft explicitly introduces the "intended" and >> "applied" >> > datastores that may be irrelevant to other protocols using YANG, and even >> > needn't be used in all NETCONF implementations. I wouldn't call this "an >> > architectural component" of YANG. >> > > > >> > > >> > > An architectural component of this new management framework (that does >> > > not have a name). The fact that not all protocols may expose all >> > > datastores is IMHO not a reason that the datastore model is not an >> > > architectural framework. >> > > >> > > > If you are saying that it will have nontrivial impact on YANG, I >> would like to >> > see it explained in sec. 6.3. Without this information I am quite >> reluctant to >> > agree with the adoption. >> > > >> > > An operational state datastore has implications how one writes data >> > > models. It may not directly affect YANG itself but surely the usage of >> > > YANG. >> > > >> > > > See above - architectural aspects need to be relevant to all >> protocols. >> > > >> > > Yes, but relevant to all protocols does not mean every protocol needs >> > > to expose say all datastores. But every protocol should be clear about >> > > how what it exposes relates to the architectural framework. >> > > >> > > >> > > >> > > There is a "current solution" consisting of hard-wired object >> > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution does >> > > not require special protocols or datastores, but it is being replaced >> by a >> > generic solution. >> > > >> > > If the "generic" solution requires special procedures which differ on >> > > each protocol, then it might end up be worse than the hard-wired >> solution >> > that works on every protocol. >> > > So I agree with Juergen that this is primarily an architectural issue. >> > > >> > > >> > > /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 >> > > -- >> > > Cheers, >> > > Mehmet >> > >> > -- >> > Ladislav Lhotka, CZ.NIC Labs >> > PGP Key ID: E74E8C0C >> > >> > >> > >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Dec 14 06:42:23 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398011295C8; Wed, 14 Dec 2016 06:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogPmve6bAAa7; Wed, 14 Dec 2016 06:42:18 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0B6128B37; Wed, 14 Dec 2016 06:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43713; q=dns/txt; s=iport; t=1481726535; x=1482936135; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=zsy9nV5xv0zeVjgctAiqGuqGS5mpveme+wyY/K1pOCI=; b=LFwO1c1eJPNx8tpwLaPnGijW6ig0WMU0Z4pIz1LPl2IgHyIkTktTmsw5 mg6E4KuacGo+rrkofySUrztxbpb7lEoWZdPQdgCitEW7DKjTzfX1q5rxj 3U60dZgiPlMkbi0dlBPEB1lttOUm1b3qyBCU8xBVAHguvuzIL0e+sG9Od E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHAwAnWVFY/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQF5LgRUjU5ylimHdo0RggYDHwEKhB6BEEoCgjEUAQI?= =?us-ascii?q?BAQEBAQEBYiiEaAEBAQMBAQEYVAsFCQILEAEEAQEBIAEGBxsGBh8JCAYBDAYCA?= =?us-ascii?q?QEXiDYDDwgOrBkvhwcNg0kBAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYY5gX2CXoJ?= =?us-ascii?q?IgVNOJoUaBY8BizU1jUCDbYF0iCiGL4dsgXFSg2WEDx83gQETDimDFTscGIFFP?= =?us-ascii?q?jSFdYI8AQEB?= X-IronPort-AV: E=Sophos;i="5.33,347,1477958400"; d="scan'208,217";a="690441376" 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; 14 Dec 2016 14:42:09 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBEEg8XY009786; Wed, 14 Dec 2016 14:42:09 GMT To: Andy Bierman , Martin Bjorklund References: <004101d25589$a0cd5f20$e2681d60$@gmail.com> <20161214.120754.915451205380944115.mbj@tail-f.com> From: Robert Wilton Message-ID: <372fdb96-295c-1a3e-de12-6693d3560de7@cisco.com> Date: Wed, 14 Dec 2016 14:42:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------587EAFBEBDEDB7D855C9762D" Archived-At: Cc: NetMod WG Chairs , NETCONF Working Group , "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 14:42:22 -0000 This is a multi-part message in MIME format. --------------587EAFBEBDEDB7D855C9762D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 14/12/2016 14:09, Andy Bierman wrote: > > > On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund > wrote: > > Andy Bierman > wrote: > > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue > wrote: > > > > > Hi Andy, > > > > > > > > > > > > > This architectural change needs to be implemented in various > protocols. > > > > > > > I am not sure a 6241bis is the best approach because it is > not clear > > > which > > > > > > > servers really need to implement the revised datastores. > > > > > > > > > > > > I agree fully. This is the reason why I wrote in my mail: > > > > > > > > > > > > >> - a new protocol- and language-independent standard > document (RFC XYZ) > > > defining the generic datastore concept and framework and > describing its use > > > (based on and following the DT solution draft), > > > > > > >> - a RFC6241bis draft removing the current datasore concept > > > specification, and getting rid of well-known issues e.g. with > the > > > operation, > > > > > > > > I do not agree with the text you wrote. > > I do not want to remove candidate, running, and startup from RFC > 6241. > > IMO the new datastores can be defined in a new document that > does not > > redefine the existing datastores. > > > > I also do not want to get rid of , It works as intended. > > It is not a problem on small devices. > > Andy, the problem with has nothing to do with the size of the > device. The problem is that returns two things (running config > + operational state) in one merged output document. This forces > people to split data models so that config and state are mutually > exclusive (/interfaces and /interfaces-state). This draft proposes a > fix for this, which makes less useful. > > > This "problem" exists for some new overloaded use of that did > not exist before. > The operation only mixes config=true and config=false. It never > had anything > to do with intended vs. applied. IMO your proposed solution is not > very backward compatible > with simple systems that do not have delays between intended and applied. I've been informed (repeatedly ;-) that has always only ever meant intended configuration. I.e. that it is reasonable behaviour for a system to accept config into and then fail to apply that configuration for some reason (daemon is unavailable, linecards is down, resources have been exceeded, programming error, etc). If this interpretation is correct then the NETCONF operation is poorly defined because it is mixing "intended configuration of the system" along with "actual running state". What NETCONF should really be providing is "actual configuration in use by the system" along with "actual running state". Of course this is effectively what the new operational state datastore is defined as containing. If I understand it correctly, I think that Andy's point is that for lots of systems "intended configuration of the system" and "actual configuration of the system" are effectively one and the same thing. If this is the case then it should be easy for clients/servers to migrate from an existing request to a request that just returns the data from the operational state datastore. It sounds like the actual data returned in both cases should be the same? Thanks, Rob > > > > /martin > > > > Andy > > > > > > It is not a problem on large devices > > if > > sufficient filtering is used. It does not differentiate between > intended > > and applied config > > or understand different types of config=false nodes. Use a new > operation to > > add these features. > > > > > > > > > > > > > > > Mehmet > > > > > > > > > Andy > > > > > > > > > > > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com > ] > > > *Sent:* Dienstag, 13. Dezember 2016 18:38 > > > *To:* Eric Voit (evoit) > > > > *Cc:* Ladislav Lhotka >; > MehmetErsue >; > > > NetMod WG Chairs >; NetConf WG Chairs < > > > netconf-chairs@ietf.org >; > NetMod WG >; Netconf < > > > netconf@ietf.org > > > > *Subject:* Re: [netmod] [Netconf] WG adoption poll > > > draft-nmdsdt-netmod-revised-datastores-00 > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > > > > > wrote: > > > > > > I support adoption, and like Mehmet's thinking as well. > > > > > > Also worth focusing on is transport protocol independent yang > filtering. > > > So along with how to frame get operations against one of the > datastores, > > > how do you know which subtrees/nodes should be included/excluded. > > > > > > > > > > > > > > > > > > This architectural change needs to be implemented in various > protocols. > > > > > > I am not sure a 6241bis is the best approach because it is not > clear which > > > > > > servers really need to implement the revised datastores. > Since RD is > > > purely optional > > > > > > to implement, it should not obsolete 6241 in any way. It > should be > > > possible > > > > > > to add new operations and/or new parameters to existing > operations without > > > > > > needing to redefine what is already there. > > > > > > > > > > > > The new protocol features need to explain how to > include/exclude subtrees. > > > > > > IMO we should only support YANG defined data. This allows the > solutions > > > > > > to be generalized and reusable across protocols (e.g., using YANG > > > extensions). > > > > > > > > > > > > > > > > > > Eric > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > From: Netconf, December 9, 2016 7:49 AM > > > > > > > > Hi Mehmet, > > > > > > > > I think I could just sign your text at the bottom. > > > > > > > > Lada > > > > > > > > > On 9 Dec 2016, at 13:25, MehmetErsue > wrote: > > > > > > > > > > Hi All, > > > > > > > > > > I think the adoption of the DT draft is fine. We agreed in > IETF 97 to > > > adopt and > > > > finalize the DT draft in NETMOD WG, which I still support. > > > > > > > > > > I believe the bigger issue is to agree on a plan > concerning the > > > related work > > > > and the re-organization of existing standards. As a matter > of fact this > > > plan will > > > > lead to updating the charter of two WGs and the work we are > going to > > > start. > > > > > > > > > > I see the DT document as a datastore solution proposal. > There are > > > different > > > > gaps and issues which still need to be addressed and the > solution > > > proposal > > > > needs yet to be discussed and finalized. The document is > providing > > > information > > > > on the history, explaining the need for a generic solution > as well as is > > > discussing > > > > different scenarios. As such I believe the datastore > solution proposal > > > from the > > > > DT should be published with the intended status > Informational RFC. > > > > > > > > > > Based on the finalized and agreed datastore solution we > should do > > > different > > > > updates to existing documents in NETCONF and NETMOD WGs. > With this > > > > action we can also fix well-known issues. > > > > > > > > > > Concerning the NETCONF WG I would see it as valuable if we > develop: > > > > > - a RFC6241bis draft removing the current datasore concept > > > > > specification, and getting rid of well-known issues e.g. > with the > > > > > operation, > > > > > - a new protocol- and language-independent standard > document (RFC XYZ) > > > > > defining the generic datastore concept and framework and > describing > > > > > its use (based on and following the DT solution draft), > > > > > - adding potential extensions to RFC6241bis (following the > DT draft > > > > > and with a normative reference to RFC XYZ), > > > > > - adding potential extensions to a RESTCONF-bis RFC > (following the DT > > > > > draft and with a normative reference to RFC XYZ), > > > > > > > > > > Concerning the NETMOD WG I would see it as valuable if we > develop: > > > > > - RFC7950bis deleting protocol-dependent details and > specifying the > > > > > datastore usage with YANG on a generic level (with a normative > > > > > reference to RFC XYZ), > > > > > - adding potential extensions to RFC7950bis, e.g. > concerning the > > > > > proposed element, > > > > > - possibly an RFC 6244bis to describe architectural > aspects. However > > > RFC6244 > > > > is Informational and a RFC6244bis would be still > Informational. I'm not > > > sure > > > > whether this is really necessary. The DT proposal does > already describe > > > such a > > > > solution and can be seen as an update to RFC 6244. > > > > > - RFC6087bis giving guidelines on how to use YANG with the new > > > datastore > > > > concept. > > > > > > > > > > Referring to Lada's proposal concerning the spin off > document from > > > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think > this can be > > > > provided in the corresponding protocol RFCs, i.e. > > > > > for NETCONF a section on "Using NETCONF with YANG" in > RFC6241bis and > > > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > > > > > > > Hope this helps as a starting point on the way to a good plan. > > > > > > > > > > PS: As Benoit suggested some time ago we might also > consider to rename > > > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > > > > > > > Regards, > > > > > Mehmet > > > > > > > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > > > > > wrote: > > > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > > > > wrote: > > > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka > wrote: > > > > > > > > > > > > > > > > > > > > I disagree that the datastore model is a protocol > specific aspect. > > > > > > > I consider datastores an architectural component > binding data > > > > > > > models and protocols together. In fact, the 'traditional' > > > > > > > datastore model > > > > > > > > > > > > I would agree with this if datastores were a general > concept in > > > YANG, but > > > > the revised-datastores draft explicitly introduces the > "intended" and > > > "applied" > > > > datastores that may be irrelevant to other protocols using > YANG, and even > > > > needn't be used in all NETCONF implementations. I wouldn't > call this "an > > > > architectural component" of YANG. > > > > > > > > > > > > > > > > An architectural component of this new management > framework (that does > > > > > not have a name). The fact that not all protocols may > expose all > > > > > datastores is IMHO not a reason that the datastore model > is not an > > > > > architectural framework. > > > > > > > > > > > If you are saying that it will have nontrivial impact on > YANG, I > > > would like to > > > > see it explained in sec. 6.3. Without this information I am > quite > > > reluctant to > > > > agree with the adoption. > > > > > > > > > > An operational state datastore has implications how one > writes data > > > > > models. It may not directly affect YANG itself but surely > the usage of > > > > > YANG. > > > > > > > > > > > See above - architectural aspects need to be relevant to all > > > protocols. > > > > > > > > > > Yes, but relevant to all protocols does not mean every > protocol needs > > > > > to expose say all datastores. But every protocol should be > clear about > > > > > how what it exposes relates to the architectural framework. > > > > > > > > > > > > > > > > > > > > There is a "current solution" consisting of hard-wired object > > > > > semantics (e.g., ifAdminStatus and ifOperStatus). This > solution does > > > > > not require special protocols or datastores, but it is > being replaced > > > by a > > > > generic solution. > > > > > > > > > > If the "generic" solution requires special procedures > which differ on > > > > > each protocol, then it might end up be worse than the > hard-wired > > > solution > > > > that works on every protocol. > > > > > So I agree with Juergen that this is primarily an > architectural issue. > > > > > > > > > > > > > > > /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 > > > > > > -- > > > > > Cheers, > > > > > Mehmet > > > > > > > > -- > > > > Ladislav Lhotka, CZ.NIC Labs > > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > _______________________________________________ > > > 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 --------------587EAFBEBDEDB7D855C9762D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 14/12/2016 14:09, Andy Bierman wrote:


On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com> wrote:
>
> > Hi Andy,
> >
> >
> >
> > > This architectural change needs to be implemented in various protocols.
> >
> > > I am not sure a 6241bis is the best approach because it is not clear
> > which
> >
> > > servers really need to implement the revised datastores.
> >
> >
> >
> > I agree fully. This is the reason why I wrote in my mail:
> >
> >
> >
> > >> - a new protocol- and language-independent standard document (RFC XYZ)
> > defining the generic datastore concept and framework and describing its use
> > (based on and following the DT solution draft),
> >
> > >> - a RFC6241bis draft removing the current datasore concept
> > specification, and getting rid of well-known issues e.g. with the <get>
> > operation,
> >
> >
> I do not agree with the text you wrote.
> I do not want to remove candidate, running, and startup from RFC 6241.
> IMO the new datastores can be defined in a new document that does not
> redefine the existing datastores.
>
> I also do not want to get rid of <get>,  It works as intended.
> It is not a problem on small devices.

Andy, the problem with <get> has nothing to do with the size of the
device.  The problem is that <get> returns two things (running config
+ operational state) in one merged output document.  This forces
people to split data models so that config and state are mutually
exclusive (/interfaces and /interfaces-state).  This draft proposes a
fix for this, which makes <get> less useful.


This "problem" exists for some new overloaded use of <get> that did not exist before.
The <get> operation only mixes config=true and config=false. It never had anything
to do with intended vs. applied.  IMO your proposed solution is not very backward compatible
with simple systems that do not have delays between intended and applied.

I've been informed (repeatedly ;-) that <running> has always only ever meant intended configuration.  I.e. that it is reasonable behaviour for a system to accept config into <running> and then fail to apply that configuration for some reason (daemon is unavailable, linecards is down, resources have been exceeded, programming error, etc).  If this interpretation is correct then the NETCONF <get> operation is poorly defined because it is mixing "intended configuration of the system" along with "actual running state".

What NETCONF <get> should really be providing is "actual configuration in use by the system" along with "actual running state".  Of course this is effectively what the new operational state datastore is defined as containing.

If I understand it correctly, I think that Andy's point is that for lots of systems "intended configuration of the system" and "actual configuration of the system" are effectively one and the same thing.  If this is the case then it should be easy for clients/servers to migrate from an existing <get> request to a <get-data> request that just returns the data from the operational state datastore.  It sounds like the actual data returned in both cases should be the same?

Thanks,
Rob



 

/martin


Andy
 



> It is not a problem on large devices
> if
> sufficient filtering is used.  It does not differentiate between intended
> and applied config
> or understand different types of config=false nodes.  Use a new operation to
> add these features.
>
>
>
>
>
>
> > Mehmet
> >
>
>
> Andy
>
>
>
> >
> >
> > *From:* Andy Bierman [mailto:andy@yumaworks.com]
> > *Sent:* Dienstag, 13. Dezember 2016 18:38
> > *To:* Eric Voit (evoit) <evoit@cisco.com>
> > *Cc:* Ladislav Lhotka <lhotka@nic.cz>; MehmetErsue <mersue@gmail.com>;
> > NetMod WG Chairs <netmod-chairs@ietf.org>; NetConf WG Chairs <
> > netconf-chairs@ietf.org>; NetMod WG <netmod@ietf.org>; Netconf <
> > netconf@ietf.org>
> > *Subject:* Re: [netmod] [Netconf] WG adoption poll
> > draft-nmdsdt-netmod-revised-datastores-00
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com>
> > wrote:
> >
> > I support adoption, and like Mehmet's thinking as well.
> >
> > Also worth focusing on is transport protocol independent yang filtering.
> > So along with how to frame get operations against one of the datastores,
> > how do you know which subtrees/nodes should be included/excluded.
> >
> >
> >
> >
> >
> > This architectural change needs to be implemented in various protocols.
> >
> > I am not sure a 6241bis is the best approach because it is not clear which
> >
> > servers really need to implement the revised datastores.  Since RD is
> > purely optional
> >
> > to implement, it should not obsolete 6241 in any way.  It should be
> > possible
> >
> > to add new operations and/or new parameters to existing operations without
> >
> > needing to redefine what is already there.
> >
> >
> >
> > The new protocol features need to explain how to include/exclude subtrees.
> >
> > IMO we should only support YANG defined data.  This allows the solutions
> >
> > to be generalized and reusable across protocols (e.g., using YANG
> > extensions).
> >
> >
> >
> >
> >
> > Eric
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> > > From: Netconf, December 9, 2016 7:49 AM
> > >
> > > Hi Mehmet,
> > >
> > > I think I could just sign your text at the bottom.
> > >
> > > Lada
> > >
> > > > On 9 Dec 2016, at 13:25, MehmetErsue <mersue@gmail.com> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to
> > adopt and
> > > finalize the DT draft in NETMOD WG, which I still support.
> > > >
> > > > I believe the bigger issue is to agree on a plan concerning the
> > related work
> > > and the re-organization of existing standards. As a matter of fact this
> > plan will
> > > lead to updating the charter of two WGs and the work we are going to
> > start.
> > > >
> > > > I see the DT document as a datastore solution proposal. There are
> > different
> > > gaps and issues which still need to be addressed and the solution
> > proposal
> > > needs yet to be discussed and finalized. The document is providing
> > information
> > > on the history, explaining the need for a generic solution as well as is
> > discussing
> > > different scenarios. As such I believe the datastore solution proposal
> > from the
> > > DT should be published with the intended status Informational RFC.
> > > >
> > > > Based on the finalized and agreed datastore solution we should do
> > different
> > > updates to existing documents in NETCONF and NETMOD WGs. With this
> > > action we can also fix well-known issues.
> > > >
> > > > Concerning the NETCONF WG I would see it as valuable if we develop:
> > > > - a RFC6241bis draft removing the current datasore concept
> > > > specification, and getting rid of well-known issues e.g. with the
> > > > <get> operation,
> > > > - a new protocol- and language-independent standard document (RFC XYZ)
> > > > defining the generic datastore concept and framework and describing
> > > > its use (based on and following the DT solution draft),
> > > > - adding potential extensions to RFC6241bis (following the DT draft
> > > > and with a normative reference to RFC XYZ),
> > > > - adding potential extensions to a RESTCONF-bis RFC (following the DT
> > > > draft and with a normative reference to RFC XYZ),
> > > >
> > > > Concerning the NETMOD WG I would see it as valuable if we develop:
> > > > - RFC7950bis deleting protocol-dependent details and specifying the
> > > > datastore usage with YANG on a generic level (with a normative
> > > > reference to RFC XYZ),
> > > > - adding potential extensions to RFC7950bis, e.g. concerning the
> > > > proposed <notification> element,
> > > > - possibly an RFC 6244bis to describe architectural aspects. However
> > RFC6244
> > > is Informational and a RFC6244bis would be still Informational. I'm not
> > sure
> > > whether this is really necessary. The DT proposal does already describe
> > such a
> > > solution and can be seen as an update to RFC 6244.
> > > > - RFC6087bis giving guidelines on how to use YANG with the new
> > datastore
> > > concept.
> > > >
> > > > Referring to Lada's proposal concerning the spin off document from
> > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be
> > > provided in the corresponding protocol RFCs, i.e.
> > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and
> > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC.
> > > >
> > > > Hope this helps as a starting point on the way to a good plan.
> > > >
> > > > PS: As Benoit suggested some time ago we might also consider to rename
> > > NETCONF WG as it is not only on NETCONF protocol anymore.
> > > >
> > > > Regards,
> > > > Mehmet
> > > >
> > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> > > wrote:
> > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
> > > <j.schoenwaelder@jacobs-university.de> wrote:
> > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote:
> > > > >
> > > > > >
> > > > > > I disagree that the datastore model is a protocol specific aspect.
> > > > > > I consider datastores an architectural component binding data
> > > > > > models and protocols together. In fact, the 'traditional'
> > > > > > datastore model
> > > > >
> > > > > I would agree with this if datastores were a general concept in
> > YANG, but
> > > the revised-datastores draft explicitly introduces the "intended" and
> > "applied"
> > > datastores that may be irrelevant to other protocols using YANG, and even
> > > needn't be used in all NETCONF implementations. I wouldn't call this "an
> > > architectural component" of YANG.
> > > > >
> > > >
> > > > An architectural component of this new management framework (that does
> > > > not have a name). The fact that not all protocols may expose all
> > > > datastores is IMHO not a reason that the datastore model is not an
> > > > architectural framework.
> > > >
> > > > > If you are saying that it will have nontrivial impact on YANG, I
> > would like to
> > > see it explained in sec. 6.3. Without this information I am quite
> > reluctant to
> > > agree with the adoption.
> > > >
> > > > An operational state datastore has implications how one writes data
> > > > models. It may not directly affect YANG itself but surely the usage of
> > > > YANG.
> > > >
> > > > > See above - architectural aspects need to be relevant to all
> > protocols.
> > > >
> > > > Yes, but relevant to all protocols does not mean every protocol needs
> > > > to expose say all datastores. But every protocol should be clear about
> > > > how what it exposes relates to the architectural framework.
> > > >
> > > >
> > > >
> > > > There is a "current solution" consisting of hard-wired object
> > > > semantics (e.g., ifAdminStatus and ifOperStatus).  This solution does
> > > > not require special protocols or datastores, but it is being replaced
> > by a
> > > generic solution.
> > > >
> > > > If the "generic" solution requires special procedures which differ on
> > > > each protocol, then it might end up be worse than the hard-wired
> > solution
> > > that works on every protocol.
> > > > So I agree with Juergen that this is primarily an architectural issue.
> > > >
> > > >
> > > > /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
> > > > --
> > > > Cheers,
> > > > Mehmet
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> >
> > _______________________________________________
> > 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

--------------587EAFBEBDEDB7D855C9762D-- From nobody Wed Dec 14 07:42:03 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A09129A93 for ; Wed, 14 Dec 2016 07:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aa8T6_N6Rbf4 for ; Wed, 14 Dec 2016 07:41:59 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258EC1293F5 for ; Wed, 14 Dec 2016 07:41:55 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id n21so25205300qka.3 for ; Wed, 14 Dec 2016 07:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ORFyVo7zn1xzYc126MoJrMw/JhG9tFeq4CqbhU8RCH4=; b=QoJgp/JyFJRnj5/lE/QiDyx+S4yl8HhBbAC9RSEcx/T7xP+dJ9CkTz2dvGM+sZRLgA E5pFXUTHyH5kBGhMsMeyw6mCvcXOC9Qh1oTTj+sTzRHenb9YgG1syJt5B983LuYacaY1 OT98aIDTl6ePIpOEbr/oCXYPwSmCbqvNYrG2Ee2aJcaHBowZBMg2usylcx5g2D3xW7VX vbslXHokplByRZh2kuUTHXZGM3iUbCehUSIVo/zdJKgXPxLc9cwyQygJmAVV6Kz29/rS 0WiM5tLNp//78htueOI7pIaZxPS972kBr4+cFCMFrw/15fCIkkfgOkpB1EHPxaCw0hoz KHBQ== 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=ORFyVo7zn1xzYc126MoJrMw/JhG9tFeq4CqbhU8RCH4=; b=iN7erW8E1Avc5355tym3SlaRLZDJyjjIr3pmKoJJnaYGHenw+VUVvqHLmQlMeC6Pk+ jyE0oohmJKcC0Wkd2ngLe18kuImc6fDDvW5MmUriQQtwX9+vzt0neMrOBS6XJ2oB4cIL Qzx1Zpnxqp5hFfmGODO/kPvPLuZB0xU2o3ZTVauULePHEdC29Uw96X33vfKCHQT2DZFW nSISVpfSC94Lm7tgClZqo2nJaOITyUHmRrXe81ewiqblWiICMshOuI5J3BWnX91NpVdZ MUQJINCXhj53+MRTQ5zrIawvxuUqBFZqI+O59YEjNMAiXS5xCDt7ZmTmFv46t9+AHjMA nUog== X-Gm-Message-State: AKaTC03lVmOuFo6+iL3ZW8MITsKj+oRZ/caZ23HIILYc312OoK42l7T+WKIgU6rikNwL1IpSOwF1AW9WoKeQnA== X-Received: by 10.55.72.22 with SMTP id v22mr83429022qka.50.1481730114012; Wed, 14 Dec 2016 07:41:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Wed, 14 Dec 2016 07:41:53 -0800 (PST) In-Reply-To: <372fdb96-295c-1a3e-de12-6693d3560de7@cisco.com> References: <004101d25589$a0cd5f20$e2681d60$@gmail.com> <20161214.120754.915451205380944115.mbj@tail-f.com> <372fdb96-295c-1a3e-de12-6693d3560de7@cisco.com> From: Andy Bierman Date: Wed, 14 Dec 2016 07:41:53 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=001a114a893c1962270543a02d31 Archived-At: Cc: NetMod WG Chairs , NETCONF Working Group , "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 15:42:02 -0000 --001a114a893c1962270543a02d31 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton wrote: > > > On 14/12/2016 14:09, Andy Bierman wrote: > > > > On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund wrote: > >> Andy Bierman wrote: >> > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue wrote: >> > >> > > Hi Andy, >> > > >> > > >> > > >> > > > This architectural change needs to be implemented in various >> protocols. >> > > >> > > > I am not sure a 6241bis is the best approach because it is not clear >> > > which >> > > >> > > > servers really need to implement the revised datastores. >> > > >> > > >> > > >> > > I agree fully. This is the reason why I wrote in my mail: >> > > >> > > >> > > >> > > >> - a new protocol- and language-independent standard document (RFC >> XYZ) >> > > defining the generic datastore concept and framework and describing >> its use >> > > (based on and following the DT solution draft), >> > > >> > > >> - a RFC6241bis draft removing the current datasore concept >> > > specification, and getting rid of well-known issues e.g. with the >> >> > > operation, >> > > >> > > >> > I do not agree with the text you wrote. >> > I do not want to remove candidate, running, and startup from RFC 6241. >> > IMO the new datastores can be defined in a new document that does not >> > redefine the existing datastores. >> > >> > I also do not want to get rid of , It works as intended. >> > It is not a problem on small devices. >> >> Andy, the problem with has nothing to do with the size of the >> device. The problem is that returns two things (running config >> + operational state) in one merged output document. This forces >> people to split data models so that config and state are mutually >> exclusive (/interfaces and /interfaces-state). This draft proposes a >> fix for this, which makes less useful. >> >> > This "problem" exists for some new overloaded use of that did not > exist before. > The operation only mixes config=true and config=false. It never had > anything > to do with intended vs. applied. IMO your proposed solution is not very > backward compatible > with simple systems that do not have delays between intended and applied. > > > I've been informed (repeatedly ;-) that has always only ever > meant intended configuration. I.e. that it is reasonable behaviour for a > system to accept config into and then fail to apply that > configuration for some reason (daemon is unavailable, linecards is down, > resources have been exceeded, programming error, etc). If this > interpretation is correct then the NETCONF operation is poorly > defined because it is mixing "intended configuration of the system" along > with "actual running state". > > What NETCONF should really be providing is "actual configuration in > use by the system" along with "actual running state". Of course this is > effectively what the new operational state datastore is defined as > containing. > > If I understand it correctly, I think that Andy's point is that for lots > of systems "intended configuration of the system" and "actual configuration > of the system" are effectively one and the same thing. If this is the case > then it should be easy for clients/servers to migrate from an existing > request to a request that just returns the data from the > operational state datastore. It sounds like the actual data returned in > both cases should be the same? > > I do not understand the new solution because it has not been well-defined. In the old solution, I have 2 leafs /foo and /foo-state. I can retrieve both of these leafs at once with . I can decide if /foo and /foo-state are the values I expect. But if I overload /foo such that it represents different semantics in different datastores, now a retrieval operation can only get 1 at a time. If I set /foo, then get-state(/foo), how do I know the config value for /foo has not changed in the meantime? If the server returns 2 /foo leafs in the same message body, then it is no longer YANG schema-valid (only 1 /foo node is allowed) The operation does not overload objects with different semantics. Only a new server that eliminates /foo-state is overloading the semantics of /foo. The ability to retrieve /foo-state is lost for a client that only knows (and not is broken. It just means the ability to access /foo-state is removed. Thanks, > Rob > > Andy > > > > >> >> /martin >> > > > Andy > > >> >> >> >> > It is not a problem on large devices >> > if >> > sufficient filtering is used. It does not differentiate between >> intended >> > and applied config >> > or understand different types of config=false nodes. Use a new >> operation to >> > add these features. >> > >> > >> > >> > >> > >> > >> > > Mehmet >> > > >> > >> > >> > Andy >> > >> > >> > >> > > >> > > >> > > *From:* Andy Bierman [mailto:andy@yumaworks.com] >> > > *Sent:* Dienstag, 13. Dezember 2016 18:38 >> > > *To:* Eric Voit (evoit) >> > > *Cc:* Ladislav Lhotka ; MehmetErsue > >; >> > > NetMod WG Chairs ; NetConf WG Chairs < >> > > netconf-chairs@ietf.org>; NetMod WG ; Netconf < >> > > netconf@ietf.org> >> > > *Subject:* Re: [netmod] [Netconf] WG adoption poll >> > > draft-nmdsdt-netmod-revised-datastores-00 >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) >> > > wrote: >> > > >> > > I support adoption, and like Mehmet's thinking as well. >> > > >> > > Also worth focusing on is transport protocol independent yang >> filtering. >> > > So along with how to frame get operations against one of the >> datastores, >> > > how do you know which subtrees/nodes should be included/excluded. >> > > >> > > >> > > >> > > >> > > >> > > This architectural change needs to be implemented in various >> protocols. >> > > >> > > I am not sure a 6241bis is the best approach because it is not clear >> which >> > > >> > > servers really need to implement the revised datastores. Since RD is >> > > purely optional >> > > >> > > to implement, it should not obsolete 6241 in any way. It should be >> > > possible >> > > >> > > to add new operations and/or new parameters to existing operations >> without >> > > >> > > needing to redefine what is already there. >> > > >> > > >> > > >> > > The new protocol features need to explain how to include/exclude >> subtrees. >> > > >> > > IMO we should only support YANG defined data. This allows the >> solutions >> > > >> > > to be generalized and reusable across protocols (e.g., using YANG >> > > extensions). >> > > >> > > >> > > >> > > >> > > >> > > Eric >> > > >> > > >> > > >> > > >> > > >> > > Andy >> > > >> > > >> > > >> > > >> > > > From: Netconf, December 9, 2016 7:49 AM >> > > > >> > > > Hi Mehmet, >> > > > >> > > > I think I could just sign your text at the bottom. >> > > > >> > > > Lada >> > > > >> > > > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: >> > > > > >> > > > > Hi All, >> > > > > >> > > > > I think the adoption of the DT draft is fine. We agreed in IETF >> 97 to >> > > adopt and >> > > > finalize the DT draft in NETMOD WG, which I still support. >> > > > > >> > > > > I believe the bigger issue is to agree on a plan concerning the >> > > related work >> > > > and the re-organization of existing standards. As a matter of fact >> this >> > > plan will >> > > > lead to updating the charter of two WGs and the work we are going to >> > > start. >> > > > > >> > > > > I see the DT document as a datastore solution proposal. There are >> > > different >> > > > gaps and issues which still need to be addressed and the solution >> > > proposal >> > > > needs yet to be discussed and finalized. The document is providing >> > > information >> > > > on the history, explaining the need for a generic solution as well >> as is >> > > discussing >> > > > different scenarios. As such I believe the datastore solution >> proposal >> > > from the >> > > > DT should be published with the intended status Informational RFC. >> > > > > >> > > > > Based on the finalized and agreed datastore solution we should do >> > > different >> > > > updates to existing documents in NETCONF and NETMOD WGs. With this >> > > > action we can also fix well-known issues. >> > > > > >> > > > > Concerning the NETCONF WG I would see it as valuable if we >> develop: >> > > > > - a RFC6241bis draft removing the current datasore concept >> > > > > specification, and getting rid of well-known issues e.g. with the >> > > > > operation, >> > > > > - a new protocol- and language-independent standard document (RFC >> XYZ) >> > > > > defining the generic datastore concept and framework and >> describing >> > > > > its use (based on and following the DT solution draft), >> > > > > - adding potential extensions to RFC6241bis (following the DT >> draft >> > > > > and with a normative reference to RFC XYZ), >> > > > > - adding potential extensions to a RESTCONF-bis RFC (following >> the DT >> > > > > draft and with a normative reference to RFC XYZ), >> > > > > >> > > > > Concerning the NETMOD WG I would see it as valuable if we develop: >> > > > > - RFC7950bis deleting protocol-dependent details and specifying >> the >> > > > > datastore usage with YANG on a generic level (with a normative >> > > > > reference to RFC XYZ), >> > > > > - adding potential extensions to RFC7950bis, e.g. concerning the >> > > > > proposed element, >> > > > > - possibly an RFC 6244bis to describe architectural aspects. >> However >> > > RFC6244 >> > > > is Informational and a RFC6244bis would be still Informational. I'm >> not >> > > sure >> > > > whether this is really necessary. The DT proposal does already >> describe >> > > such a >> > > > solution and can be seen as an update to RFC 6244. >> > > > > - RFC6087bis giving guidelines on how to use YANG with the new >> > > datastore >> > > > concept. >> > > > > >> > > > > Referring to Lada's proposal concerning the spin off document from >> > > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can >> be >> > > > provided in the corresponding protocol RFCs, i.e. >> > > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis >> and >> > > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. >> > > > > >> > > > > Hope this helps as a starting point on the way to a good plan. >> > > > > >> > > > > PS: As Benoit suggested some time ago we might also consider to >> rename >> > > > NETCONF WG as it is not only on NETCONF protocol anymore. >> > > > > >> > > > > Regards, >> > > > > Mehmet >> > > > > >> > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman >> > > > wrote: >> > > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder >> > > > wrote: >> > > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: >> > > > > > >> > > > > > > >> > > > > > > I disagree that the datastore model is a protocol specific >> aspect. >> > > > > > > I consider datastores an architectural component binding data >> > > > > > > models and protocols together. In fact, the 'traditional' >> > > > > > > datastore model >> > > > > > >> > > > > > I would agree with this if datastores were a general concept in >> > > YANG, but >> > > > the revised-datastores draft explicitly introduces the "intended" >> and >> > > "applied" >> > > > datastores that may be irrelevant to other protocols using YANG, >> and even >> > > > needn't be used in all NETCONF implementations. I wouldn't call >> this "an >> > > > architectural component" of YANG. >> > > > > > >> > > > > >> > > > > An architectural component of this new management framework (that >> does >> > > > > not have a name). The fact that not all protocols may expose all >> > > > > datastores is IMHO not a reason that the datastore model is not an >> > > > > architectural framework. >> > > > > >> > > > > > If you are saying that it will have nontrivial impact on YANG, I >> > > would like to >> > > > see it explained in sec. 6.3. Without this information I am quite >> > > reluctant to >> > > > agree with the adoption. >> > > > > >> > > > > An operational state datastore has implications how one writes >> data >> > > > > models. It may not directly affect YANG itself but surely the >> usage of >> > > > > YANG. >> > > > > >> > > > > > See above - architectural aspects need to be relevant to all >> > > protocols. >> > > > > >> > > > > Yes, but relevant to all protocols does not mean every protocol >> needs >> > > > > to expose say all datastores. But every protocol should be clear >> about >> > > > > how what it exposes relates to the architectural framework. >> > > > > >> > > > > >> > > > > >> > > > > There is a "current solution" consisting of hard-wired object >> > > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution >> does >> > > > > not require special protocols or datastores, but it is being >> replaced >> > > by a >> > > > generic solution. >> > > > > >> > > > > If the "generic" solution requires special procedures which >> differ on >> > > > > each protocol, then it might end up be worse than the hard-wired >> > > solution >> > > > that works on every protocol. >> > > > > So I agree with Juergen that this is primarily an architectural >> issue. >> > > > > >> > > > > >> > > > > /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 >> > > > > -- >> > > > > Cheers, >> > > > > Mehmet >> > > > >> > > > -- >> > > > Ladislav Lhotka, CZ.NIC Labs >> > > > PGP Key ID: E74E8C0C >> > > > >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > Netconf mailing list >> > > > Netconf@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/netconf >> > > >> > > _______________________________________________ >> > > netmod mailing list >> > > netmod@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netmod >> > > >> > > >> > > >> > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > --001a114a893c1962270543a02d31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20



On 14/12/2016 14:09,= Andy Bierman wrote:
=20


On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com> wrote:
>
> > Hi Andy,
> >
> >
> >
> > > This architectural change needs to be implemented in various protocols.
> >
> > > I am not sure a 6241bis is the best approach because it is not clear
> > which
> >
> > > servers really need to implement the revised datastores.
> >
> >
> >
> > I agree fully. This is the reason why I wrote in my mail:
> >
> >
> >
> > >> - a new protocol- and language-independent standard document (RFC XYZ)
> > defining the generic datastore concept and framework and describing its use
> > (based on and following the DT solution draft),
> >
> > >> - a RFC6241bis draft removing the current datasore concept
> > specification, and getting rid of well-known issues e.g. with the <get>
> > operation,
> >
> >
> I do not agree with the text you wrote.
> I do not want to remove candidate, running, and startup from RFC 6241.
> IMO the new datastores can be defined in a new document that does not
> redefine the existing datastores.
>
> I also do not want to get rid of <get>,=C2=A0 It works as intended.
> It is not a problem on small devices.

Andy, the problem with <get> has nothing to do with the size of the
device.=C2=A0 The problem is that <get> returns two things (running config
+ operational state) in one merged output document.=C2=A0 Thi= s forces
people to split data models so that config and state are mutually
exclusive (/interfaces and /interfaces-state).=C2=A0 This dra= ft proposes a
fix for this, which makes <get> less useful.


This "problem" exists for some new overloaded us= e of <get> that did not exist before.
The <get> operation only mixes config=3Dtrue and config=3Dfalse. It never had anything
to do with intended vs. applied.=C2=A0 IMO your proposed solution is not very backward compatible
with simple systems that do not have delays between intended and applied.

I've been informed (repeatedly ;-) that <running> has always only ever meant intended configuration.=C2=A0 I.e. that it is reasonabl= e behaviour for a system to accept config into <running> and then fail to apply that configuration for some reason (daemon is unavailable, linecards is down, resources have been exceeded, programming error, etc).=C2=A0 If this interpretation is correct then t= he NETCONF <get> operation is poorly defined because it is mixing "intended configuration of the system" along with "actua= l running state".

What NETCONF <get> should really be providing is "actual configuration in use by the system" along with "actual runnin= g state".=C2=A0 Of course this is effectively what the new operation= al state datastore is defined as containing.

If I understand it correctly, I think that Andy's point is that for lots of systems "intended configuration of the system" and &q= uot;actual configuration of the system" are effectively one and the same thing.=C2=A0 If this is the case then it should be easy for clients/servers to migrate from an existing <get> request to a <get-data> request that just returns the data from the operational state datastore.=C2=A0 It sounds like the actual data returned in both cases should be the same?



I do not unde= rstand the new solution because it has not been well-defined.
In the old solution, I have 2 leafs /foo and /foo-state.
<= div>I can retrieve both of these leafs at once with <get>.
= I can decide if /foo and /foo-state are the values I expect.

=
But if I overload /foo such that it represents different semanti= cs in
different datastores, now a retrieval operation can only ge= t 1 at a time.
If I set /foo, then get-state(/foo), how do I know= the config value for /foo
has not changed in the meantime?=C2=A0= If the server returns 2 /foo leafs in the same
message body, the= n it is no longer YANG schema-valid (only 1 /foo node is allowed)

The =C2=A0<get> operation does not overload objects w= ith different semantics.
Only a new server that eliminates /foo-s= tate is overloading the semantics of /foo.
The ability to retriev= e /foo-state is lost for a client that only knows <get> (and not <= get-state).
This does not mean <get> is broken.=C2=A0 It ju= st means the ability to access /foo-state is removed.

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

/martin


Andy
=C2=A0



> It is not a problem on large devices
> if
> sufficient filtering is used.=C2=A0 It does not differentiate between intended
> and applied config
> or understand different types of config=3Dfalse nodes.= =C2=A0 Use a new operation to
> add these features.
>
>
>
>
>
>
> > Mehmet
> >
>
>
> Andy
>
>
>
> >
> >
> > *From:* Andy Bierman [mailto:andy@yumaworks.com]
> > *Sent:* Dienstag, 13. Dezember 2016 18:38
> > *To:* Eric Voit (evoit) <evoit@cisco.com>
> > *Cc:* Ladislav Lhotka <lhotka@nic.cz>; MehmetErsue <mersue@gmail.com>;
> > NetMod WG Chairs <netmod-chairs@ietf.org>; NetConf WG Chairs <
> > netconf-chairs@ietf.org>; NetMod WG <netmod@ietf.org>; Netconf <
> > netconf@ietf.org>
> > *Subject:* Re: [netmod] [Netconf] WG adoption poll
> > draft-nmdsdt-netmod-revised-datastores-00
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com>
> > wrote:
> >
> > I support adoption, and like Mehmet's thinking as well.
> >
> > Also worth focusing on is transport protocol independent yang filtering.
> > So along with how to frame get operations against one of the datastores,
> > how do you know which subtrees/nodes should be included/excluded.
> >
> >
> >
> >
> >
> > This architectural change needs to be implemented in various protocols.
> >
> > I am not sure a 6241bis is the best approach because it is not clear which
> >
> > servers really need to implement the revised datastores.=C2=A0 Since RD is
> > purely optional
> >
> > to implement, it should not obsolete 6241 in any way.=C2=A0 It should be
> > possible
> >
> > to add new operations and/or new parameters to existing operations without
> >
> > needing to redefine what is already there.
> >
> >
> >
> > The new protocol features need to explain how to include/exclude subtrees.
> >
> > IMO we should only support YANG defined data.=C2=A0 This allows the solutions
> >
> > to be generalized and reusable across protocols (e.g., using YANG
> > extensions).
> >
> >
> >
> >
> >
> > Eric
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> > > From: Netconf, December 9, 2016 7:49 AM
> > >
> > > Hi Mehmet,
> > >
> > > I think I could just sign your text at the bottom.
> > >
> > > Lada
> > >
> > > > On 9 Dec 2016, at 13:25, MehmetErsue <mer= sue@gmail.com> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to
> > adopt and
> > > finalize the DT draft in NETMOD WG, which I still support.
> > > >
> > > > I believe the bigger issue is to agree on a plan concerning the
> > related work
> > > and the re-organization of existing standards. As a matter of fact this
> > plan will
> > > lead to updating the charter of two WGs and the work we are going to
> > start.
> > > >
> > > > I see the DT document as a datastore solution proposal. There are
> > different
> > > gaps and issues which still need to be addressed and the solution
> > proposal
> > > needs yet to be discussed and finalized. The document is providing
> > information
> > > on the history, explaining the need for a generic solution as well as is
> > discussing
> > > different scenarios. As such I believe the datastore solution proposal
> > from the
> > > DT should be published with the intended status Informational RFC.
> > > >
> > > > Based on the finalized and agreed datastore solution we should do
> > different
> > > updates to existing documents in NETCONF and NETMOD WGs. With this
> > > action we can also fix well-known issues.
> > > >
> > > > Concerning the NETCONF WG I would see it as valuable if we develop:
> > > > - a RFC6241bis draft removing the current datasore concept
> > > > specification, and getting rid of well-known issues e.g. with the
> > > > <get> operation,
> > > > - a new protocol- and language-independent standard document (RFC XYZ)
> > > > defining the generic datastore concept and framework and describing
> > > > its use (based on and following the DT solution draft),
> > > > - adding potential extensions to RFC6241bis (following the DT draft
> > > > and with a normative reference to RFC XYZ),
> > > > - adding potential extensions to a RESTCONF-bis RFC (following the DT
> > > > draft and with a normative reference to RFC XYZ),
> > > >
> > > > Concerning the NETMOD WG I would see it as valuable if we develop:
> > > > - RFC7950bis deleting protocol-dependent details and specifying the
> > > > datastore usage with YANG on a generic level (with a normative
> > > > reference to RFC XYZ),
> > > > - adding potential extensions to RFC7950bis, e.g. concerning the
> > > > proposed <notification> element, > > > > - possibly an RFC 6244bis to describe architectural aspects. However
> > RFC6244
> > > is Informational and a RFC6244bis would be still Informational. I'm not
> > sure
> > > whether this is really necessary. The DT proposal does already describe
> > such a
> > > solution and can be seen as an update to RFC 6244.
> > > > - RFC6087bis giving guidelines on how to use YANG with the new
> > datastore
> > > concept.
> > > >
> > > > Referring to Lada's proposal concerning the spin off document from
> > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be
> > > provided in the corresponding protocol RFCs, i.e.
> > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and
> > > for RESTCONF "Using RESTCONF with YANG&qu= ot; in RESTCONF-bis RFC.
> > > >
> > > > Hope this helps as a starting point on the way to a good plan.
> > > >
> > > > PS: As Benoit suggested some time ago we might also consider to rename
> > > NETCONF WG as it is not only on NETCONF protocol anymore.
> > > >
> > > > Regards,
> > > > Mehmet
> > > >
> > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> > > wrote:
> > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
> > > <j.schoenwaelder@jacobs-university.de> wrote:
> > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote:
> > > > >
> > > > > >
> > > > > > I disagree that the datastore model is a protocol specific aspect.
> > > > > > I consider datastores an architectural component binding data
> > > > > > models and protocols together. In fact, the 'traditional'
> > > > > > datastore model
> > > > >
> > > > > I would agree with this if datastores were a general concept in
> > YANG, but
> > > the revised-datastores draft explicitly introduces the "intended" and
> > "applied"
> > > datastores that may be irrelevant to other protocols using YANG, and even
> > > needn't be used in all NETCONF implementations. I wouldn't call this "an
> > > architectural component" of YANG.
> > > > >
> > > >
> > > > An architectural component of this new management framework (that does
> > > > not have a name). The fact that not all protocols may expose all
> > > > datastores is IMHO not a reason that the datastore model is not an
> > > > architectural framework.
> > > >
> > > > > If you are saying that it will have nontrivial impact on YANG, I
> > would like to
> > > see it explained in sec. 6.3. Without this information I am quite
> > reluctant to
> > > agree with the adoption.
> > > >
> > > > An operational state datastore has implications how one writes data
> > > > models. It may not directly affect YANG itself but surely the usage of
> > > > YANG.
> > > >
> > > > > See above - architectural aspects need to be relevant to all
> > protocols.
> > > >
> > > > Yes, but relevant to all protocols does not mean every protocol needs
> > > > to expose say all datastores. But every protocol should be clear about
> > > > how what it exposes relates to the architectural framework.
> > > >
> > > >
> > > >
> > > > There is a "current solution" consisting of hard-wired object
> > > > semantics (e.g., ifAdminStatus and ifOperStatus).=C2=A0 This solution does
> > > > not require special protocols or datastores, but it is being replaced
> > by a
> > > generic solution.
> > > >
> > > > If the "generic" solution requi= res special procedures which differ on
> > > > each protocol, then it might end up be worse than the hard-wired
> > solution
> > > that works on every protocol.
> > > > So I agree with Juergen that this is primarily an architectural issue.
> > > >
> > > >
> > > > /js
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> > > > --
> > > > Cheers,
> > > > Mehmet
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _________________________________________= ______
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailm= an/listinfo/netconf
> >
> > ______________________________________________= _
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> >



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


--001a114a893c1962270543a02d31-- From nobody Wed Dec 14 08:27:06 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F8E129EB8; Wed, 14 Dec 2016 08:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N07g-Y1jFznD; Wed, 14 Dec 2016 08:26:58 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C61D129EC9; Wed, 14 Dec 2016 08:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22753; q=dns/txt; s=iport; t=1481732721; x=1482942321; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=morGy4Zph6ezyjwWbqptsIhHCq62mCO8tx+9xRTRA74=; b=b/jgFG/LbTK/AT024gPyJamzsjzNxgnFzo/rPzP0LgrnGPccWcPQj3rx KrmWwtly0pbqRsv0yE1Liitn23t5sdAejTpzHWPF7/B0Td4QHpKGug88c k1F9D0gqYn8tTFNW7aTeBL+vFX6kKwfuPSXQ1HrwSqs4VUr/ERP0ri5Qq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAwABclFY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAYEnBFSNTnKWKYd2jRGCCYYiAoI1FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDASNWBQsLGCcDAgIhJREGDQYCAQEXiDYDDwiqJYIoL4cLDYNJAQEBA?= =?us-ascii?q?QEBAQECAQEBAQEBAQEBAR6GPoF9CIJWgkiBUxeDGoJdBZo2NY1Ag22BdIUBgyc?= =?us-ascii?q?jhgyJXVKDZYQPHzeBARMOg3kcGIFFPjSFdYI8AQEB?= X-IronPort-AV: E=Sophos;i="5.33,347,1477958400"; d="scan'208,217";a="648903740" 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; 14 Dec 2016 16:25:13 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBEGPDsb032166; Wed, 14 Dec 2016 16:25:13 GMT To: Andy Bierman References: <004101d25589$a0cd5f20$e2681d60$@gmail.com> <20161214.120754.915451205380944115.mbj@tail-f.com> <372fdb96-295c-1a3e-de12-6693d3560de7@cisco.com> From: Robert Wilton Message-ID: Date: Wed, 14 Dec 2016 16:25:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------07658C88751289A7C49D0F14" Archived-At: Cc: NetMod WG Chairs , NETCONF Working Group , "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 16:27:01 -0000 This is a multi-part message in MIME format. --------------07658C88751289A7C49D0F14 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, Thanks for you comments, please see inline. On 14/12/2016 15:41, Andy Bierman wrote: > > > On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton > wrote: > > > > On 14/12/2016 14:09, Andy Bierman wrote: >> >> >> On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund > > wrote: >> >> Andy Bierman > >> wrote: >> > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue >> > wrote: >> > >> > > Hi Andy, >> > > >> > > >> > > >> > > > This architectural change needs to be implemented in >> various protocols. >> > > >> > > > I am not sure a 6241bis is the best approach because it >> is not clear >> > > which >> > > >> > > > servers really need to implement the revised datastores. >> > > >> > > >> > > >> > > I agree fully. This is the reason why I wrote in my mail: >> > > >> > > >> > > >> > > >> - a new protocol- and language-independent standard >> document (RFC XYZ) >> > > defining the generic datastore concept and framework and >> describing its use >> > > (based on and following the DT solution draft), >> > > >> > > >> - a RFC6241bis draft removing the current datasore concept >> > > specification, and getting rid of well-known issues e.g. >> with the >> > > operation, >> > > >> > > >> > I do not agree with the text you wrote. >> > I do not want to remove candidate, running, and startup >> from RFC 6241. >> > IMO the new datastores can be defined in a new document >> that does not >> > redefine the existing datastores. >> > >> > I also do not want to get rid of , It works as intended. >> > It is not a problem on small devices. >> >> Andy, the problem with has nothing to do with the size >> of the >> device. The problem is that returns two things >> (running config >> + operational state) in one merged output document. This forces >> people to split data models so that config and state are mutually >> exclusive (/interfaces and /interfaces-state). This draft >> proposes a >> fix for this, which makes less useful. >> >> >> This "problem" exists for some new overloaded use of that >> did not exist before. >> The operation only mixes config=true and config=false. It >> never had anything >> to do with intended vs. applied. IMO your proposed solution is >> not very backward compatible >> with simple systems that do not have delays between intended and >> applied. > > I've been informed (repeatedly ;-) that has always only > ever meant intended configuration. I.e. that it is reasonable > behaviour for a system to accept config into and then > fail to apply that configuration for some reason (daemon is > unavailable, linecards is down, resources have been exceeded, > programming error, etc). If this interpretation is correct then > the NETCONF operation is poorly defined because it is mixing > "intended configuration of the system" along with "actual running > state". > > What NETCONF should really be providing is "actual > configuration in use by the system" along with "actual running > state". Of course this is effectively what the new operational > state datastore is defined as containing. > > If I understand it correctly, I think that Andy's point is that > for lots of systems "intended configuration of the system" and > "actual configuration of the system" are effectively one and the > same thing. If this is the case then it should be easy for > clients/servers to migrate from an existing request to a > request that just returns the data from the operational > state datastore. It sounds like the actual data returned in both > cases should be the same? > > > > I do not understand the new solution because it has not been well-defined. > > In the old solution, I have 2 leafs /foo and /foo-state. > I can retrieve both of these leafs at once with . > I can decide if /foo and /foo-state are the values I expect. Yes, this is true. But to be a programmatically easily consumable solution it requires that the structure under /foo is also exactly replicated under /foo-state. This probably means that most config needs to be put into groupings, and IMO, I think that it makes the models hard to read, and also harder to maintain. > > But if I overload /foo such that it represents different semantics in > different datastores, now a retrieval operation can only get 1 at a time. Yes, this is true. Although it should be possible to define RPC operations that fetch more than one datastore in the same message if required, although I'm not convinced that is truly needed. > If I set /foo, then get-state(/foo), how do I know the config value > for /foo > has not changed in the meantime? You don't, unless you also do a get on the running config datastore as well. But I also don't see why this is a problem. Either the client knows what the config should be, in which case it probably doesn't need to explicitly ask the device, but can infer it from the operational state. Alternatively, if another client may also be modifying the configuration at the same time then the client needs to be designed to expect and handle this. Even with the existing request, I don't think that any non trivial device can guarantee that all the data returned in that get request is atomically consistent with itself. > If the server returns 2 /foo leafs in the same > message body, then it is no longer YANG schema-valid (only 1 /foo node > is allowed) The message body would need to return two separate data trees, one for each datastore that is being returned. > > The operation does not overload objects with different semantics. > Only a new server that eliminates /foo-state is overloading the > semantics of /foo. The new server doesn't overload the same object with different semantics, it is really just saying that the value of an object depends on what datastore it is being read from, which is true in NETCONF even today. I.e. the value for a given config leaf could already differ between candidate, running, startup. What is being proposed doesn't seem to fundamentally change the meaning of the config leaves in a new and different way, it is just defining new datastores with associated more tightly specified semantics. > The ability to retrieve /foo-state is lost for a client that only > knows (and not This does not mean is broken. It just means the ability to > access /foo-state is removed. I think that is broken in the sense that it is combining together two sets of data that cannot always be combined in a meaningful way. For me the bigger problem is that it is only under rare conditions that the problem scenarios arise, meaning that clients may not be coded to be robust under those scenarios devaluing the YANG automation proposition. Thanks, Rob --------------07658C88751289A7C49D0F14 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,

Thanks for you comments, please see inline.


On 14/12/2016 15:41, Andy Bierman wrote:


On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton <rwilton@cisco.com> wrote:



On 14/12/2016 14:09, Andy Bierman wrote:


On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com> wrote:
>
> > Hi Andy,
> >
> >
> >
> > > This architectural change needs to be implemented in various protocols.
> >
> > > I am not sure a 6241bis is the best approach because it is not clear
> > which
> >
> > > servers really need to implement the revised datastores.
> >
> >
> >
> > I agree fully. This is the reason why I wrote in my mail:
> >
> >
> >
> > >> - a new protocol- and language-independent standard document (RFC XYZ)
> > defining the generic datastore concept and framework and describing its use
> > (based on and following the DT solution draft),
> >
> > >> - a RFC6241bis draft removing the current datasore concept
> > specification, and getting rid of well-known issues e.g. with the <get>
> > operation,
> >
> >
> I do not agree with the text you wrote.
> I do not want to remove candidate, running, and startup from RFC 6241.
> IMO the new datastores can be defined in a new document that does not
> redefine the existing datastores.
>
> I also do not want to get rid of <get>,  It works as intended.
> It is not a problem on small devices.

Andy, the problem with <get> has nothing to do with the size of the
device.  The problem is that <get> returns two things (running config
+ operational state) in one merged output document.  This forces
people to split data models so that config and state are mutually
exclusive (/interfaces and /interfaces-state).  This draft proposes a
fix for this, which makes <get> less useful.


This "problem" exists for some new overloaded use of <get> that did not exist before.
The <get> operation only mixes config=true and config=false. It never had anything
to do with intended vs. applied.  IMO your proposed solution is not very backward compatible
with simple systems that do not have delays between intended and applied.

I've been informed (repeatedly ;-) that <running> has always only ever meant intended configuration.  I.e. that it is reasonable behaviour for a system to accept config into <running> and then fail to apply that configuration for some reason (daemon is unavailable, linecards is down, resources have been exceeded, programming error, etc).  If this interpretation is correct then the NETCONF <get> operation is poorly defined because it is mixing "intended configuration of the system" along with "actual running state".

What NETCONF <get> should really be providing is "actual configuration in use by the system" along with "actual running state".  Of course this is effectively what the new operational state datastore is defined as containing.

If I understand it correctly, I think that Andy's point is that for lots of systems "intended configuration of the system" and "actual configuration of the system" are effectively one and the same thing.  If this is the case then it should be easy for clients/servers to migrate from an existing <get> request to a <get-data> request that just returns the data from the operational state datastore.  It sounds like the actual data returned in both cases should be the same?



I do not understand the new solution because it has not been well-defined.

In the old solution, I have 2 leafs /foo and /foo-state.
I can retrieve both of these leafs at once with <get>.
I can decide if /foo and /foo-state are the values I expect.
Yes, this is true. But to be a programmatically easily consumable solution it requires that the structure under /foo is also exactly replicated under /foo-state.  This probably means that most config needs to be put into groupings, and IMO, I think that it makes the models hard to read, and also harder to maintain.



But if I overload /foo such that it represents different semantics in
different datastores, now a retrieval operation can only get 1 at a time.
Yes, this is true.  Although it should be possible to define RPC operations that fetch more than one datastore in the same message if required, although I'm not convinced that is truly needed.


If I set /foo, then get-state(/foo), how do I know the config value for /foo
has not changed in the meantime?
You don't, unless you also do a get on the running config datastore as well.

But I also don't see why this is a problem.  Either the client knows what the config should be, in which case it probably doesn't need to explicitly ask the device, but can infer it from the operational state.  Alternatively, if another client may also be modifying the configuration at the same time then the client needs to be designed to expect and handle this.

Even with the existing <get> request, I don't think that any non trivial device can guarantee that all the data returned in that get request is atomically consistent with itself.


  If the server returns 2 /foo leafs in the same
message body, then it is no longer YANG schema-valid (only 1 /foo node is allowed)
The message body would need to return two separate data trees, one for each datastore that is being returned.


The  <get> operation does not overload objects with different semantics.
Only a new server that eliminates /foo-state is overloading the semantics of /foo.
The new server doesn't overload the same object with different semantics, it is really just saying that the value of an object depends on what datastore it is being read from, which is true in NETCONF even today.  I.e. the value for a given config leaf could already differ between candidate, running, startup.  What is being proposed doesn't seem to fundamentally change the meaning of the config leaves in a new and different way, it is just defining new datastores with associated more tightly specified semantics.


The ability to retrieve /foo-state is lost for a client that only knows <get> (and not <get-state).
This does not mean <get> is broken.  It just means the ability to access /foo-state is removed.
I think that <get> is broken in the sense that it is combining together two sets of data that cannot always be combined in a meaningful way.  For me the bigger problem is that it is only under rare conditions that the problem scenarios arise, meaning that clients may not be coded to be robust under those scenarios devaluing the YANG automation proposition.

Thanks,
Rob

--------------07658C88751289A7C49D0F14-- From nobody Wed Dec 14 12:02:37 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7FF129ECD for ; Wed, 14 Dec 2016 12:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPHeEslRehyc for ; Wed, 14 Dec 2016 12:02:34 -0800 (PST) Received: from mail-wj0-x22b.google.com (mail-wj0-x22b.google.com [IPv6:2a00:1450:400c:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A725712941E for ; Wed, 14 Dec 2016 12:02:33 -0800 (PST) Received: by mail-wj0-x22b.google.com with SMTP id tk12so47642295wjb.3 for ; Wed, 14 Dec 2016 12:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language :disposition-notification-to; bh=8SfIcLWScaKUHmCrBEOi2fmvsyHdGgRo2SvGAzLqVz4=; b=V0pRQAAcMlJjVTMxymLDF6sM9cFV3dEv6F2hXhe7Jk3+eT/48DypDNYh83feQB4g9f l8PElMTn6NTwtIaxTaq8dXQ2KZ71yEAeCe7nskK+SdzKAs0FZReffEcQF6/9LhewUdxz B0UYHLyxQXPlt2q2Mpp8OqV6dv1UZPEF4Vq18kN0+xvgZmh0+zD6v+hMmscAMMW/H34l 2BH0iNxfu0Wogc/S7LSzuun5Cr8FUDhRvVNYGbzS3uhNWCF1FjkScD5eF/C300I7pSnE wP6AsaTrsviFgOH37GJzORIe9FnoUzFDCbRglQ4nMfZiDy4DqQNFyFjzftZtJLMNGEPh FBJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language :disposition-notification-to; bh=8SfIcLWScaKUHmCrBEOi2fmvsyHdGgRo2SvGAzLqVz4=; b=Hr/weecZ0cbE0inS+T8VAj5ypJv5Gq66AZqoM85FWIq8Vi46jpwuRvQNMJHnltZG2C 84AjWReiHyJ360sPI1026ATjV2+lMM35+fWOVlKQOIlZp+O5kZpef+wW8yfkcXUFd8Jp 8H/MaHGF3Cqe0jSRnt6hqY2/DiObn8887KstyyY0J4WkzRV34TcMENLgqhVEo9mInTDT pHI7V3/Mmx07tODD0gNzKsZm5b/0GGzCRdEe/cdnbjlP889jUI+rQwXhOqCxeOFTn66i VjMnlKwl8wthRoy3hMEC1IiwBSFx7y0DgySV2DyfzxpTlNp/K20QKkgNulNICh31WzCT thMQ== X-Gm-Message-State: AKaTC03dWigRK1AwgKv72ncTcPQmVrKpQK8RbbN16WhGDy8Vdf3x5yJBoHGqaoTl2/0X8Q== X-Received: by 10.194.3.47 with SMTP id 15mr87396972wjz.17.1481745751655; Wed, 14 Dec 2016 12:02:31 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B34016F.dip0.t-ipconnect.de. [91.52.1.111]) by smtp.gmail.com with ESMTPSA id x5sm68705204wje.36.2016.12.14.12.02.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Dec 2016 12:02:30 -0800 (PST) From: "Mehmet Ersue" To: "'Netconf'" Date: Wed, 14 Dec 2016 21:02:29 +0100 Message-ID: <02e601d25645$003cea50$00b6bef0$@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: AdJWRINl9HfMmxfAQ2qhSDPcnKxRRg== Content-Language: de X-AVK-Virus-Check: AVA 25.9511;155A1E2 X-AVK-Spam-Check: 1; str=0001.0A0C0204.5851A556.00C2,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; F1206 Archived-At: Cc: 'RFC Editor' Subject: [Netconf] Inconsistency in Section 1.4 of draft-ietf-netconf-restconf-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 20:02:35 -0000 Dear NETCONF WG, RFC Editor found an inconsistency in Section 1.4 of draft-ietf-netconf-restconf-18, where paragraph 6 says: "If the NETCONF server is expecting a "persist-id" parameter to complete the confirmed commit procedure then the RESTCONF edit operation MUST fail with a "409 Conflict" status-line. There error-tag "in-use" is returned in this case. The error-tag value "resource-denied" is used in this case." Myself as the document shepherd and the authors agreed to use the error-tag value "invalid value" to align with the operations and in RFC 6241. The correction will be done as below: OLD: There error-tag "in-use" is returned in this case. The error-tag value "resource-denied" is used in this case. NEW: The error-tag value "invalid-value" is used in this case. Please speak up within 2 days if you have a strong objection. Regards, Mehmet From nobody Wed Dec 14 13:20:06 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD131296AC for ; Wed, 14 Dec 2016 13:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HOzMyat0Mz3 for ; Wed, 14 Dec 2016 13:20:03 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CAC12968D for ; Wed, 14 Dec 2016 13:20:03 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id a197so133484062wmd.0 for ; Wed, 14 Dec 2016 13:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language :disposition-notification-to; bh=O3vXzoz2q6CG4CJziI1mkKtjRDTIcM9kWcXrtSG/nVE=; b=RvIkBc55JF0vC9Gs9Gjm0tELnMYpQBcMpu/e9KWfFxp0bKilJBx3xqdNbMW33q0DtH pG5oNGF31If3EyNHfmD3XduVEn2OWWiZSoXEDZ7igR4VhjBq4i5uM9DJFBx/q/+gYX8Q Ux8iBYBcADpvMipBnRKORRv1N+bksYe8j3hVPmyt9CoMS1C332tUKaljzxBTK0Z9NuDN SkOxfgjxJbIxWXjvjqhoaEI2JdmzFvvLDgXDVLtnnbWjmLipoBbUNss7F06Jw25LFHxX inhKSsGJiuqRG0E+9DVbDFiriyt6aI7h9k8AXtIdbXmP89UGBBtnZ8TfsgH1JwIvlCrO rqdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language :disposition-notification-to; bh=O3vXzoz2q6CG4CJziI1mkKtjRDTIcM9kWcXrtSG/nVE=; b=Ge+L7PdjLvFYmhI0xSRu4DLYnD1gsYlrI/lVQEM6otF+Ww+AzoNdTv/sVY76KbEhPw It/TORnLpdI1q5A57lEopkcgEImgRpHHDQ8bFRElM2AeJZm4B+mDeoI9PYZA+eZJXX9y wgot7lKXjgSOviKDdGHL7CpFHfFkx1GNHu/ohW0Gb7SfxvGTvyKa84Tn+4gjzUUj8aFv wz3nEA7IpojNnxI+f2ssQfKl1s4i4xdsNFRdfq0LTOz3PWIcqSuzC6+EanEuQXSPzW7U PEHlJvwoXvK6JF6rBkDfyqcyZO2WvY6ZZCjd5otG8i0tgR+MHENKIDkxAVePLnooacu5 iFZw== X-Gm-Message-State: AKaTC02ubttdu8NYtoCFst+xYVoPuXWATCwgs/kbbhkzcjG9UxjYbquV2O79v8fryKw/2g== X-Received: by 10.28.132.201 with SMTP id g192mr9179760wmd.134.1481750401590; Wed, 14 Dec 2016 13:20:01 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B34016F.dip0.t-ipconnect.de. [91.52.1.111]) by smtp.gmail.com with ESMTPSA id g197sm9384992wmd.15.2016.12.14.13.20.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Dec 2016 13:20:00 -0800 (PST) From: "Mehmet Ersue" To: "'Netconf'" Date: Wed, 14 Dec 2016 22:19:59 +0100 Message-ID: <03ce01d2564f$d3c23150$7b4693f0$@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: AdJWTdQCfxsU7wp9Qjibxm94X5trHg== Content-Language: de X-AVK-Virus-Check: AVA 25.9511;155A1E2 X-AVK-Spam-Check: 1; str=0001.0A0C0207.5851B780.008E,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; F1206 Archived-At: Subject: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 21:20:05 -0000 Dear NETCONF WG, for the potential topics to add we only got comments from Martin. We assume now there are no other comments. This is a 2+ week WG adoption call for draft-bierman-netconf-rfc6536bis to adopt as NETCONF WG item. Please state your opinion on the mail list by December 30, 2016 with "yes/support" or "no support". If you support, please let us know what you would like to address additionally. If you don't support, please elaborate your reasons. Thank you, Mehmet & Mahesh -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Wednesday, December 7, 2016 9:20 AM To: mersue@gmail.com Cc: andy@yumaworks.com; netconf@ietf.org Subject: Re: [Netconf] new NACM draft MehmetErsue > wrote: > Hi Andy, Martin, > > thank you for the initial draft. > > We discussed in IETF 97 different issues and the additional sections > we could add. Ok. But do we have to resolve all issues before adopting this document? I think the current document is ready for adoption, and then the WG can work on fixing any open issues. > IIRC the list was: > - schema-mount related text into schema-mount or the NACM draft, I think schema mount needs to discuss how it works with NACM. This should be an open issue in schema mount. > - assigning priorities to clients, I don't believe this is a NACM issue. > - access control on dynamic datastores (e.g. I2RS), The text in 3.2 probably need to be relaxed a bit to allow NACM to be applied to other datastores. > - the issue from RFC 6536 with parent/child relationships which is > important for RESTCONF. Can you elaborate on this? /martin > > I would like to suggest to have a discussion on these issues and > understand whether they should be included. > > Mehmet > > On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman > wrote: > > > Hi, > > > > A new version of draft-bierman-netconf-rfc6536bis has been posted: > > https://www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt > > > > > > We would like this draft to be adopted as the starting point for > > item #5 in the current NETCONF charter. > > > > > > > > Andy and Martin > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > -- > Cheers, > Mehmet From nobody Wed Dec 14 13:27:05 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F0F129491 for ; Wed, 14 Dec 2016 13:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 n5fKCFmNvvPB for ; Wed, 14 Dec 2016 13:27:01 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8240F12968D for ; Wed, 14 Dec 2016 13:27:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D816E371; Wed, 14 Dec 2016 22:26:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UnBuPJ44neuL; Wed, 14 Dec 2016 22:26:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 14 Dec 2016 22:26:59 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5950E20074; Wed, 14 Dec 2016 22:27:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id l6E9LYkDs11g; Wed, 14 Dec 2016 22:26:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE2DF2006D; Wed, 14 Dec 2016 22:27:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D1FFE3DBA507; Wed, 14 Dec 2016 22:26:57 +0100 (CET) Date: Wed, 14 Dec 2016 22:26:57 +0100 From: Juergen Schoenwaelder To: Mehmet Ersue Message-ID: <20161214212657.GA5212@elstar.local> Mail-Followup-To: Mehmet Ersue , 'Netconf' References: <03ce01d2564f$d3c23150$7b4693f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03ce01d2564f$d3c23150$7b4693f0$@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: 'Netconf' Subject: Re: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 21:27:04 -0000 I support this update since it is necessary to make NACM work with YANG 1.1 and RESTCONF (and I think this should be the scope of this update effort). /js On Wed, Dec 14, 2016 at 10:19:59PM +0100, Mehmet Ersue wrote: > Dear NETCONF WG, > > for the potential topics to add we only got comments from Martin. We assume > now there are no other comments. > > This is a 2+ week WG adoption call for draft-bierman-netconf-rfc6536bis to > adopt as NETCONF WG item. > > Please state your opinion on the mail list by December 30, 2016 with > "yes/support" or "no support". > > If you support, please let us know what you would like to address > additionally. > If you don't support, please elaborate your reasons. > > Thank you, > Mehmet & Mahesh > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, December 7, 2016 9:20 AM > To: mersue@gmail.com > Cc: andy@yumaworks.com; netconf@ietf.org > Subject: Re: [Netconf] new NACM draft > > MehmetErsue > wrote: > > Hi Andy, Martin, > > > > thank you for the initial draft. > > > > We discussed in IETF 97 different issues and the additional sections > > we could add. > > Ok. But do we have to resolve all issues before adopting this document? I > think the current document is ready for adoption, and then the WG can work > on fixing any open issues. > > > IIRC the list was: > > - schema-mount related text into schema-mount or the NACM draft, > > I think schema mount needs to discuss how it works with NACM. This should > be an open issue in schema mount. > > > - assigning priorities to clients, > > I don't believe this is a NACM issue. > > > - access control on dynamic datastores (e.g. I2RS), > > The text in 3.2 probably need to be relaxed a bit to allow NACM to be > applied to other datastores. > > > - the issue from RFC 6536 with parent/child relationships which is > > important for RESTCONF. > > Can you elaborate on this? > > > /martin > > > > > > > I would like to suggest to have a discussion on these issues and > > understand whether they should be included. > > > > Mehmet > > > > On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman > wrote: > > > > > Hi, > > > > > > A new version of draft-bierman-netconf-rfc6536bis has been posted: > > > https://www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt > > > > > > > > > We would like this draft to be adopted as the starting point for > > > item #5 in the current NETCONF charter. > > > > > > > > > > > > Andy and Martin > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > -- > > Cheers, > > Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- 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 Dec 15 00:01:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28485129461 for ; Thu, 15 Dec 2016 00:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 MXikKnYtIXB6 for ; Thu, 15 Dec 2016 00:01:15 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6867128B44 for ; Thu, 15 Dec 2016 00:01:14 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:3cde:959f:d398:7940] (unknown [IPv6:2001:718:1a02:1:3cde:959f:d398:7940]) by mail.nic.cz (Postfix) with ESMTPSA id D7A6060D14; Thu, 15 Dec 2016 09:01:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481788872; bh=39D+IV5HGkHCW6pZIwSntGi1KYSuMAhotXl3I5goXtk=; h=From:Date:To; b=jk9oEoN762MulXq7atTz9bB+BTCQpOXfc81RurL/iiIupCeqa+XjJP4t3NfRqd7ct 8IkSHbxy6axzrtCrSiW8GtwRnTka8do/XMiN86J4x2damkr7AfIjUO1mF8RT4SthT9 ZolPCE2yKLaJqijONomEBzRh4Sv9YEBioPtcDyaE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <03ce01d2564f$d3c23150$7b4693f0$@gmail.com> Date: Thu, 15 Dec 2016 09:01:12 +0100 Content-Transfer-Encoding: 7bit Message-Id: <3225C63B-0C41-4104-B619-495E6952EF66@nic.cz> References: <03ce01d2564f$d3c23150$7b4693f0$@gmail.com> To: Mehmet Ersue X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 08:01:17 -0000 Support. Lada > On 14 Dec 2016, at 22:19, Mehmet Ersue wrote: > > Dear NETCONF WG, > > for the potential topics to add we only got comments from Martin. We assume > now there are no other comments. > > This is a 2+ week WG adoption call for draft-bierman-netconf-rfc6536bis to > adopt as NETCONF WG item. > > Please state your opinion on the mail list by December 30, 2016 with > "yes/support" or "no support". > > If you support, please let us know what you would like to address > additionally. > If you don't support, please elaborate your reasons. > > Thank you, > Mehmet & Mahesh > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, December 7, 2016 9:20 AM > To: mersue@gmail.com > Cc: andy@yumaworks.com; netconf@ietf.org > Subject: Re: [Netconf] new NACM draft > > MehmetErsue > wrote: >> Hi Andy, Martin, >> >> thank you for the initial draft. >> >> We discussed in IETF 97 different issues and the additional sections >> we could add. > > Ok. But do we have to resolve all issues before adopting this document? I > think the current document is ready for adoption, and then the WG can work > on fixing any open issues. > >> IIRC the list was: >> - schema-mount related text into schema-mount or the NACM draft, > > I think schema mount needs to discuss how it works with NACM. This should > be an open issue in schema mount. > >> - assigning priorities to clients, > > I don't believe this is a NACM issue. > >> - access control on dynamic datastores (e.g. I2RS), > > The text in 3.2 probably need to be relaxed a bit to allow NACM to be > applied to other datastores. > >> - the issue from RFC 6536 with parent/child relationships which is >> important for RESTCONF. > > Can you elaborate on this? > > > /martin > > > >> >> I would like to suggest to have a discussion on these issues and >> understand whether they should be included. >> >> Mehmet >> >> On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman > wrote: >> >>> Hi, >>> >>> A new version of draft-bierman-netconf-rfc6536bis has been posted: >>> https://www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt >>> >>> >>> We would like this draft to be adopted as the starting point for >>> item #5 in the current NETCONF charter. >>> >>> >>> >>> Andy and Martin >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> >> >> -- >> Cheers, >> Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 15 04:01:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F39129D9B for ; Thu, 15 Dec 2016 04:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 LAD3rmvVHEkY for ; Thu, 15 Dec 2016 04:01:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF3E12A0BF for ; Thu, 15 Dec 2016 03:47:14 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 719011AE018B; Thu, 15 Dec 2016 12:47:12 +0100 (CET) Date: Thu, 15 Dec 2016 12:47:11 +0100 (CET) Message-Id: <20161215.124711.2216477344616156120.mbj@tail-f.com> To: mersue@gmail.com From: Martin Bjorklund In-Reply-To: <02e601d25645$003cea50$00b6bef0$@gmail.com> References: <02e601d25645$003cea50$00b6bef0$@gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [Netconf] Inconsistency in Section 1.4 of draft-ietf-netconf-restconf-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 12:01:52 -0000 "Mehmet Ersue" wrote: > Dear NETCONF WG, > > RFC Editor found an inconsistency in Section 1.4 of > draft-ietf-netconf-restconf-18, where paragraph 6 says: > > "If the NETCONF server is expecting a > "persist-id" parameter to complete the confirmed commit procedure > then the RESTCONF edit operation MUST fail with a "409 Conflict" > status-line. There error-tag "in-use" is returned in this case. The > error-tag value "resource-denied" is used in this case." > > Myself as the document shepherd and the authors agreed to use the error-tag > value "invalid value" to align with the operations and > in RFC 6241. > The correction will be done as below: > > OLD: > There error-tag "in-use" is returned in this case. The > error-tag value "resource-denied" is used in this case. > > NEW: > The error-tag value "invalid-value" is used in this case. > > Please speak up within 2 days if you have a strong objection. I don't think invalid-value is appropriate. It signals that the client provided an invalid value for some parameter, but that's not true in this case - there is nothing the client can do in order to fix the situation. I prefer to use 'resource-denied' (which is actually what Mehmet suggested). /martin From nobody Thu Dec 15 09:55:30 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5273412940E for ; Thu, 15 Dec 2016 09:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WujO51qISIcD for ; Thu, 15 Dec 2016 09:55:27 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0132.outbound.protection.outlook.com [104.47.32.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C39A120725 for ; Thu, 15 Dec 2016 09:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7iFdW/6fL0xxE0Jp7IkErBALgfiIJM9rQjI2QN1NCEk=; b=Xk/Fpcq7Ve72kf7DR5HNWN/yc4im10FunBTdoJ1Q2AzeRwti8TL1s54R8nNeMB3Nelfp7WzLRG3FgBXC4hZnoqIdLd89C2jWQk9+EXZOA0wvufZ6j09L7KmfnfiNPiQwTFWKjq3NE/YHj7NTCKItdqEjttXGchmlDVA66pbJkf4= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.5; Thu, 15 Dec 2016 17:55: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.01.0789.014; Thu, 15 Dec 2016 17:55:27 +0000 From: Kent Watsen To: Martin Bjorklund , "mersue@gmail.com" Thread-Topic: [Netconf] Inconsistency in Section 1.4 of draft-ietf-netconf-restconf-18 Thread-Index: AQHSVssKbf/q5VyazECXOOWgD+2fGKEI92uA Date: Thu, 15 Dec 2016 17:55:27 +0000 Message-ID: <19D8E110-ADA3-4652-9338-D8136511690D@juniper.net> References: <02e601d25645$003cea50$00b6bef0$@gmail.com> <20161215.124711.2216477344616156120.mbj@tail-f.com> In-Reply-To: <20161215.124711.2216477344616156120.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.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: cbc56f3d-6764-4923-96ba-08d425138da7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:+G9TWzTPv9XeRclsRn2wX56eDRhDlIXKQNkYXDh97nFBmgd61UbsmZafvy2A0udo7a0lfYlJrWqMd9Ak1s9nrBr7Fuc9LsfeKdCUR1Ol2ctQiK/QS9ZPPvDqTP3y4nbAuS9Ax6jCEWZDaJR9x/o2PKwjAS1KSHz5brXbq/a95D1/5/Lsy5gaCsRRg+WZasuPiW3z/Wur8nKHDLJFD/JNorI4alSIw42gBa3BiUyt2Y974RmhYLJS2lMnMwXdSP88pLKxVVB9q43AJna64fdRXXH35Q4VwDjZp2s/fWrjYCkl8+ROrWYsnP6UUUHhZTQwy1axlq1+gVg1RdfhJwCA+t0KNl7g1CIdSsmAdh3Tt1L7OTepP4JJCfCX0NCUj0gT5m+VGtddSw8lT65cd0Iof37H4UA7Yo21tSm8cu8TWfBm1GP/+tBt8/HgnknYpksvQr49VCIEvOTqeAKBilV1gA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(189002)(199003)(24454002)(66066001)(38730400001)(5001770100001)(54356999)(76176999)(50986999)(8676002)(4326007)(122556002)(230783001)(7736002)(305945005)(3280700002)(39060400001)(3660700001)(77096006)(6486002)(105586002)(106116001)(68736007)(106356001)(2950100002)(3846002)(102836003)(99286002)(6116002)(2501003)(229853002)(101416001)(5660300001)(82746002)(25786008)(2900100001)(83506001)(189998001)(81166006)(92566002)(81156014)(8936002)(4001350100001)(86362001)(83716003)(6512006)(6436002)(2906002)(6506006)(33656002)(97736004)(36756003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9546D6D4B8F84E4E9A7E6538BF797EBB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 17:55:27.5938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: "netconf@ietf.org" , "rfc-editor@rfc-editor.org" Subject: Re: [Netconf] Inconsistency in Section 1.4 of draft-ietf-netconf-restconf-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 17:55:29 -0000 DQoNCiJNZWhtZXQgRXJzdWUiIDxtZXJzdWVAZ21haWwuY29tPiB3cm90ZToNCj4gRGVhciBORVRD T05GIFdHLA0KPiANCj4gUkZDIEVkaXRvciBmb3VuZCBhbiBpbmNvbnNpc3RlbmN5IGluIFNlY3Rp b24gMS40IG9mDQo+IGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi0xOCwgd2hlcmUgcGFyYWdy YXBoIDYgc2F5czoNCj4gDQo+ICAgICJJZiB0aGUgTkVUQ09ORiBzZXJ2ZXIgaXMgZXhwZWN0aW5n IGENCj4gICAgInBlcnNpc3QtaWQiIHBhcmFtZXRlciB0byBjb21wbGV0ZSB0aGUgY29uZmlybWVk IGNvbW1pdCBwcm9jZWR1cmUNCj4gICAgdGhlbiB0aGUgUkVTVENPTkYgZWRpdCBvcGVyYXRpb24g TVVTVCBmYWlsIHdpdGggYSAiNDA5IENvbmZsaWN0Ig0KPiAgICBzdGF0dXMtbGluZS4gIFRoZXJl IGVycm9yLXRhZyAiaW4tdXNlIiBpcyByZXR1cm5lZCBpbiB0aGlzIGNhc2UuICBUaGUNCj4gICAg ZXJyb3ItdGFnIHZhbHVlICJyZXNvdXJjZS1kZW5pZWQiIGlzIHVzZWQgaW4gdGhpcyBjYXNlLiIN Cj4gDQo+IE15c2VsZiBhcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQgYW5kIHRoZSBhdXRob3JzIGFn cmVlZCB0byB1c2UgdGhlIGVycm9yLXRhZw0KPiB2YWx1ZSAiaW52YWxpZCB2YWx1ZSIgdG8gYWxp Z24gd2l0aCB0aGUgb3BlcmF0aW9ucyA8Y2FuY2VsLWNvbW1pdD4gYW5kDQo+IDxjb21taXQ+IGlu IFJGQyA2MjQxLg0KPiBUaGUgY29ycmVjdGlvbiB3aWxsIGJlIGRvbmUgYXMgYmVsb3c6DQo+IA0K PiBPTEQ6DQo+ICAgIFRoZXJlIGVycm9yLXRhZyAiaW4tdXNlIiBpcyByZXR1cm5lZCBpbiB0aGlz IGNhc2UuICBUaGUNCj4gICAgZXJyb3ItdGFnIHZhbHVlICJyZXNvdXJjZS1kZW5pZWQiIGlzIHVz ZWQgaW4gdGhpcyBjYXNlLg0KPiANCj4gTkVXOg0KPiAgICAgICBUaGUgZXJyb3ItdGFnIHZhbHVl ICJpbnZhbGlkLXZhbHVlIiBpcyB1c2VkIGluIHRoaXMgY2FzZS4NCj4gDQo+IFBsZWFzZSBzcGVh ayB1cCB3aXRoaW4gMiBkYXlzIGlmIHlvdSBoYXZlIGEgc3Ryb25nIG9iamVjdGlvbi4NCg0KSSBk b24ndCB0aGluayBpbnZhbGlkLXZhbHVlIGlzIGFwcHJvcHJpYXRlLiAgSXQgc2lnbmFscyB0aGF0 IHRoZQ0KY2xpZW50IHByb3ZpZGVkIGFuIGludmFsaWQgdmFsdWUgZm9yIHNvbWUgcGFyYW1ldGVy LCBidXQgdGhhdCdzIG5vdA0KdHJ1ZSBpbiB0aGlzIGNhc2UgLSB0aGVyZSBpcyBub3RoaW5nIHRo ZSBjbGllbnQgY2FuIGRvIGluIG9yZGVyIHRvIGZpeA0KdGhlIHNpdHVhdGlvbi4gIEkgcHJlZmVy IHRvIHVzZSAncmVzb3VyY2UtZGVuaWVkJyAod2hpY2ggaXMgYWN0dWFsbHkNCndoYXQgTWVobWV0 IHN1Z2dlc3RlZCkuDQoNCg0KDQpXaGF0IGRvIE5FVENPTkYgc2VydmVycyByZXR1cm4gd2hlbiBu byBwZXJzaXN0LWlkIGlzIHBhc3NlZCBldmVuIHRob3VnaCBvbmUgaXMgbmVlZGVkPyAgUkZDIDYy NDEgaXNu4oCZdCBjbGVhci4gICBSRkMgNjI0MSBzZWVtcyB0byBvbmx5IHNwZWFrIHRvIHdoZW4g dGhlIHdyb25nIHBlcnNpc3QtaWQgaXMgcGFzc2VkLiAgRWl0aGVyIGNhc2UsIFJFU1RDT05GIFNI T1VMRCByZXR1cm4gdGhlIHNhbWUgZXJyb3ItdGFnIHZhbHVlIHRoYXQgYSBORVRDT05GIHNlcnZl ciByZXR1cm5zIGZvciB0aGVzZSBjYXNlcywgcmlnaHQ/DQoNCktlbnQNCg0KDQoNCg== From nobody Thu Dec 15 09:58:01 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B19012940E for ; Thu, 15 Dec 2016 09:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYutTRlu4Szl for ; Thu, 15 Dec 2016 09:57:58 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0120.outbound.protection.outlook.com [104.47.32.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BB61296B8 for ; Thu, 15 Dec 2016 09:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=df4ERmnk6hOCKXitMEEzpWYd6NmLAoCS5Dj4Wu9j+Lw=; b=S2+4TW+QEtcDRYxk+s+QSiBGcWOx0jHnnl/6rXxlHF8vDnoekceUPasSETxPsUKY8uLdyr76MKDPsDgQfNRfIGqvqn3/7DOTU+pXZtpq5zoHNtjkd38UppVbBBA6e5Kz53zBBrmJToTzgtPwWduKkEecO7AuNNP6OpVpwk3WBMg= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.5; Thu, 15 Dec 2016 17:57:58 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0789.014; Thu, 15 Dec 2016 17:57:58 +0000 From: Kent Watsen To: Mehmet Ersue , 'Netconf' Thread-Topic: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft Thread-Index: AdJWTdQCfxsU7wp9Qjibxm94X5trHgAhQYiA Date: Thu, 15 Dec 2016 17:57:57 +0000 Message-ID: <86885D36-C9E1-4280-9027-DB93B2399EED@juniper.net> References: <03ce01d2564f$d3c23150$7b4693f0$@gmail.com> In-Reply-To: <03ce01d2564f$d3c23150$7b4693f0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1c.1.161117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: bb8fcdcc-e4f9-4782-63c9-08d42513e751 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:QU9Sb5NmJuSkbyLCOAqlWQsIKSHKnCoBRdqx4rUevsGJJ/jmGLfC0+heeJUn2hywWhOUHYzW4UTDp7P4dWI+ByCpIPCSJopW0jW4cR6YIr5DAPaqu/yIgiDO/ciO6QM/i9iatssNevYrzEAX6PqSFXE5mzI8dTF0suB68/TVUcvX0/OVn9nLKghlHBRReCvhgmtdwBAvoZSqpMcYbrdc8lKlveJJ0yur3p+ySCD7wQzGDGt6dGQzRsVxXftItgcjb13JPhkdA/bqE3DqgP97560G4t1JTDb0Xi7poC79sNze208Lr5BIiCLI8uYNFKUaUEmhCkj2ZQCIRqEqy5KpI5PGxYAeYP+l702dprLYeM3ofnVZS1Js+8nUU9k1kUQIJ49uGupdTCAt2CqmK8J7PYrRonDrX1PoLdkDo17wcJRThGmHMJJS9AzXqN2CNTQMGU5DW42qx/o/vDCXOiMUjQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(189002)(377454003)(199003)(67374002)(24454002)(13464003)(66066001)(38730400001)(5001770100001)(54356999)(76176999)(50986999)(8676002)(122556002)(230783001)(7736002)(305945005)(3280700002)(39060400001)(3660700001)(77096006)(6486002)(105586002)(68736007)(106356001)(2950100002)(3846002)(102836003)(99286002)(6116002)(229853002)(101416001)(107886002)(5660300001)(345774005)(82746002)(25786008)(2900100001)(83506001)(189998001)(81166006)(92566002)(81156014)(8936002)(4001350100001)(86362001)(83716003)(6512006)(6436002)(2906002)(6506006)(33656002)(97736004)(36756003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <72EFD57E33DA434581AAAC74222086C5@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 17:57:57.9718 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 17:58:00 -0000 eWVzL3N1cHBvcnQgLSBpdCBuZWVkcyB0byBiZSB1cGRhdGVkLg0KDQpLZW50DQoNCg0KDQpEZWFy IE5FVENPTkYgV0csDQoNCmZvciB0aGUgcG90ZW50aWFsIHRvcGljcyB0byBhZGQgd2Ugb25seSBn b3QgY29tbWVudHMgZnJvbSBNYXJ0aW4uIFdlIGFzc3VtZQ0Kbm93IHRoZXJlIGFyZSBubyBvdGhl ciBjb21tZW50cy4NCg0KVGhpcyBpcyBhIDIrIHdlZWsgV0cgYWRvcHRpb24gY2FsbCBmb3IgZHJh ZnQtYmllcm1hbi1uZXRjb25mLXJmYzY1MzZiaXMgdG8NCmFkb3B0IGFzIE5FVENPTkYgV0cgaXRl bS4NCg0KUGxlYXNlIHN0YXRlIHlvdXIgb3BpbmlvbiBvbiB0aGUgbWFpbCBsaXN0IGJ5IERlY2Vt YmVyIDMwLCAyMDE2IHdpdGgNCiJ5ZXMvc3VwcG9ydCIgb3IgIm5vIHN1cHBvcnQiLiAgDQoNCklm IHlvdSBzdXBwb3J0LCBwbGVhc2UgbGV0IHVzIGtub3cgd2hhdCB5b3Ugd291bGQgbGlrZSB0byBh ZGRyZXNzDQphZGRpdGlvbmFsbHkuDQpJZiB5b3UgZG9uJ3Qgc3VwcG9ydCwgcGxlYXNlIGVsYWJv cmF0ZSB5b3VyIHJlYXNvbnMuICANCg0KVGhhbmsgeW91LA0KTWVobWV0ICYgTWFoZXNoDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBCam9ya2x1bmQgW21haWx0 bzptYmpAdGFpbC1mLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDcsIDIwMTYgOToy MCBBTQ0KVG86IG1lcnN1ZUBnbWFpbC5jb20NCkNjOiBhbmR5QHl1bWF3b3Jrcy5jb207IG5ldGNv bmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gbmV3IE5BQ00gZHJhZnQNCg0KTWVo bWV0RXJzdWUgPG1lcnN1ZUBnbWFpbC5jb20gPG1haWx0bzptZXJzdWVAZ21haWwuY29tPiA+IHdy b3RlOg0KPiBIaSBBbmR5LCBNYXJ0aW4sDQo+IA0KPiB0aGFuayB5b3UgZm9yIHRoZSBpbml0aWFs IGRyYWZ0Lg0KPiANCj4gV2UgZGlzY3Vzc2VkIGluIElFVEYgOTcgZGlmZmVyZW50IGlzc3VlcyBh bmQgdGhlIGFkZGl0aW9uYWwgc2VjdGlvbnMgDQo+IHdlIGNvdWxkIGFkZC4NCg0KT2suICBCdXQg ZG8gd2UgaGF2ZSB0byByZXNvbHZlIGFsbCBpc3N1ZXMgYmVmb3JlIGFkb3B0aW5nIHRoaXMgZG9j dW1lbnQ/ICBJDQp0aGluayB0aGUgY3VycmVudCBkb2N1bWVudCBpcyByZWFkeSBmb3IgYWRvcHRp b24sIGFuZCB0aGVuIHRoZSBXRyBjYW4gd29yaw0Kb24gZml4aW5nIGFueSBvcGVuIGlzc3Vlcy4N Cg0KPiBJSVJDIHRoZSBsaXN0IHdhczoNCj4gLSBzY2hlbWEtbW91bnQgcmVsYXRlZCB0ZXh0IGlu dG8gc2NoZW1hLW1vdW50IG9yIHRoZSBOQUNNIGRyYWZ0LA0KDQpJIHRoaW5rIHNjaGVtYSBtb3Vu dCBuZWVkcyB0byBkaXNjdXNzIGhvdyBpdCB3b3JrcyB3aXRoIE5BQ00uICBUaGlzIHNob3VsZA0K YmUgYW4gb3BlbiBpc3N1ZSBpbiBzY2hlbWEgbW91bnQuDQoNCj4gLSBhc3NpZ25pbmcgcHJpb3Jp dGllcyB0byBjbGllbnRzLA0KDQpJIGRvbid0IGJlbGlldmUgdGhpcyBpcyBhIE5BQ00gaXNzdWUu DQoNCj4gLSBhY2Nlc3MgY29udHJvbCBvbiBkeW5hbWljIGRhdGFzdG9yZXMgKGUuZy4gSTJSUyks DQoNClRoZSB0ZXh0IGluIDMuMiBwcm9iYWJseSBuZWVkIHRvIGJlIHJlbGF4ZWQgYSBiaXQgdG8g YWxsb3cgTkFDTSB0byBiZQ0KYXBwbGllZCB0byBvdGhlciBkYXRhc3RvcmVzLg0KDQo+IC0gdGhl IGlzc3VlIGZyb20gUkZDIDY1MzYgd2l0aCBwYXJlbnQvY2hpbGQgcmVsYXRpb25zaGlwcyB3aGlj aCBpcyANCj4gaW1wb3J0YW50IGZvciBSRVNUQ09ORi4NCg0KQ2FuIHlvdSBlbGFib3JhdGUgb24g dGhpcz8NCg0KDQovbWFydGluDQoNCg0KDQo+IA0KPiBJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0 byBoYXZlIGEgZGlzY3Vzc2lvbiBvbiB0aGVzZSBpc3N1ZXMgYW5kIA0KPiB1bmRlcnN0YW5kIHdo ZXRoZXIgdGhleSBzaG91bGQgYmUgaW5jbHVkZWQuDQo+IA0KPiBNZWhtZXQNCj4gDQo+IE9uIFdl ZCwgTm92IDMwLCAyMDE2IGF0IDI6MTAgQU0sIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3Mu Y29tDQo8bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4gPiB3cm90ZToNCj4gDQo+ID4gSGksDQo+ ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWJpZXJtYW4tbmV0Y29uZi1yZmM2NTM2Ymlz IGhhcyBiZWVuIHBvc3RlZDoNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1iaWVy bWFuLW5ldGNvbmYtcmZjNjUzNmJpcy0wMS50eHQNCj4gPg0KPiA+DQo+ID4gV2Ugd291bGQgbGlr ZSB0aGlzIGRyYWZ0IHRvIGJlIGFkb3B0ZWQgYXMgdGhlIHN0YXJ0aW5nIHBvaW50IGZvciANCj4g PiBpdGVtICM1IGluIHRoZSBjdXJyZW50IE5FVENPTkYgY2hhcnRlci4NCj4gPg0KPiA+DQo+ID4N Cj4gPiBBbmR5IGFuZCBNYXJ0aW4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+ IE5ldGNvbmZAaWV0Zi5vcmcgPG1haWx0bzpOZXRjb25mQGlldGYub3JnPiANCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPg0KPiA+DQo+IA0KPiAN Cj4gLS0NCj4gQ2hlZXJzLA0KPiBNZWhtZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KDQo= From nobody Thu Dec 15 10:06:58 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB30E12995C for ; Thu, 15 Dec 2016 10:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDjwDS3G75DM for ; Thu, 15 Dec 2016 10:06:55 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091FD129C07 for ; Thu, 15 Dec 2016 10:06:52 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id n6so64730518qtd.1 for ; Thu, 15 Dec 2016 10:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PU8tuCVtuhqwahI4Lnf9i+Dy4KZTOx4xZJF6OO1ev2o=; b=MiSN726AzQoerjlR+k5e7aNtlICFxAx+eO3F5Gjsab8YIgLelIyZgHLPSzUlYQqRs9 TrTNq62ToVxn/gGE6c/pke/06biVY/tf3t8SIIp9U2x0wnqtKfqbwRsBa2xbqy/fTJHw RjrHsOKUJ6mP4PCu93R2d9BaESGR37frY9VSZFw2/msNWLcPl6Z8agWWyNl2dKPJT3qT ymUJy8PRd2hJi2zCtfV3zyDq2pywJ3BnwBJiFqJQgYHU+mwiNqIKME5xcSSB7VCo0bCy bXJObbI18bhCct5hcYQn9Uk0CptAGhFy4B1cPErzdjZcqM3KbyxlXtFQ7Pk+wPkaDmci 4bVQ== 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=PU8tuCVtuhqwahI4Lnf9i+Dy4KZTOx4xZJF6OO1ev2o=; b=B4m1qZ4Ur2f5ODWTJiScCiIk0ION9X6pp6YxEAmOmOpWU0J+W+Wu4yXVtoC2t3nJak 864psbW2iJOqk31VyFlaj0PcdKcUOFlDDwMJhR0acw3Jgl9SNkQwKX2pKWhpKgVEZ53H 3X4tMcFx17pd9k5YpLfSx7sIq4avAMxsDxRzj6vFpjFxVKoxJbJyzMsvsuzc94Kd0U/O fONE1/nVL26fS+BjMtTrRdA9oK+I4p3gfS0FTfxCjhKlqhk7s13kT/1wbSlCiPoZpko7 GWGsmV8FdwM614R1mv5VKEnqMRhzpx6XSx4f4GqwU+c6wxnMF5O1D1qCgGx6lnfpU8ge ADkA== X-Gm-Message-State: AIkVDXKxMGzfp5Jh7ezjbbUXH1z7SpjEtnBLPUddunOYb8v2Fz60npE792hccKCTt1o6SVLkcPTV5C20NEC25w== X-Received: by 10.200.41.171 with SMTP id 40mr1979238qts.235.1481825211092; Thu, 15 Dec 2016 10:06:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Thu, 15 Dec 2016 10:06:50 -0800 (PST) In-Reply-To: <19D8E110-ADA3-4652-9338-D8136511690D@juniper.net> References: <02e601d25645$003cea50$00b6bef0$@gmail.com> <20161215.124711.2216477344616156120.mbj@tail-f.com> <19D8E110-ADA3-4652-9338-D8136511690D@juniper.net> From: Andy Bierman Date: Thu, 15 Dec 2016 10:06:50 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a1140657853cde80543b65102 Archived-At: Cc: "netconf@ietf.org" , "rfc-editor@rfc-editor.org" Subject: Re: [Netconf] Inconsistency in Section 1.4 of draft-ietf-netconf-restconf-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 18:06:57 -0000 --001a1140657853cde80543b65102 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 15, 2016 at 9:55 AM, Kent Watsen wrote: > > > "Mehmet Ersue" wrote: > > Dear NETCONF WG, > > > > RFC Editor found an inconsistency in Section 1.4 of > > draft-ietf-netconf-restconf-18, where paragraph 6 says: > > > > "If the NETCONF server is expecting a > > "persist-id" parameter to complete the confirmed commit procedure > > then the RESTCONF edit operation MUST fail with a "409 Conflict" > > status-line. There error-tag "in-use" is returned in this case. Th= e > > error-tag value "resource-denied" is used in this case." > > > > Myself as the document shepherd and the authors agreed to use the > error-tag > > value "invalid value" to align with the operations and > > in RFC 6241. > > The correction will be done as below: > > > > OLD: > > There error-tag "in-use" is returned in this case. The > > error-tag value "resource-denied" is used in this case. > > > > NEW: > > The error-tag value "invalid-value" is used in this case. > > > > Please speak up within 2 days if you have a strong objection. > > I don't think invalid-value is appropriate. It signals that the > client provided an invalid value for some parameter, but that's not > true in this case - there is nothing the client can do in order to fix > the situation. I prefer to use 'resource-denied' (which is actually > what Mehmet suggested). > > > > What do NETCONF servers return when no persist-id is passed even though > one is needed? RFC 6241 isn=E2=80=99t clear. RFC 6241 seems to only sp= eak to > when the wrong persist-id is passed. Either case, RESTCONF SHOULD return > the same error-tag value that a NETCONF server returns for these cases, > right? > > Our server returns 'in-use' and error-app-tag 'outstanding-confirmed-commit= ' if client B tries a on client A's confirmed commit. rpc-reply { rpc-error { error-info { error-number 373 } error-type protocol error-tag in-use error-severity error error-app-tag outstanding-confirmed-commit error-message 'cannot perform the operation with confirmed-commit pending' } } However, our RESTCONF server supports the confirmed-commit procedure using query parameters (confirmed, persist, persist-id, confirm-timeout) and also a POST on /restconf/operations/commit. (IMO some NETCONF operations are needed to make RESTCONF as robust as NETCONF) > Kent > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1140657853cde80543b65102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 15, 2016 at 9:55 AM, Kent Watsen <kwatsen@juniper.net> wrote:


"Mehmet Ersue" <mersue@gma= il.com> wrote:
> Dear NETCONF WG,
>
> RFC Editor found an inconsistency in Section 1.4 of
> draft-ietf-netconf-restconf-18, where paragraph 6 says:
>
>=C2=A0 =C2=A0 "If the NETCONF server is expecting a
>=C2=A0 =C2=A0 "persist-id" parameter to complete the confirme= d commit procedure
>=C2=A0 =C2=A0 then the RESTCONF edit operation MUST fail with a "4= 09 Conflict"
>=C2=A0 =C2=A0 status-line.=C2=A0 There error-tag "in-use" is = returned in this case.=C2=A0 The
>=C2=A0 =C2=A0 error-tag value "resource-denied" is used in th= is case."
>
> Myself as the document shepherd and the authors agreed to use the erro= r-tag
> value "invalid value" to align with the operations <cance= l-commit> and
> <commit> in RFC 6241.
> The correction will be done as below:
>
> OLD:
>=C2=A0 =C2=A0 There error-tag "in-use" is returned in this ca= se.=C2=A0 The
>=C2=A0 =C2=A0 error-tag value "resource-denied" is used in th= is case.
>
> NEW:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The error-tag value "invalid-value"= ; is used in this case.
>
> Please speak up within 2 days if you have a strong objection.

I don't think invalid-value is appropriate.=C2=A0 It signals that the client provided an invalid value for some parameter, but that's not
true in this case - there is nothing the client can do in order to fix
the situation.=C2=A0 I prefer to use 'resource-denied' (which is ac= tually
what Mehmet suggested).



What do NETCONF servers return when no persist-id is passed even though one= is needed?=C2=A0 RFC 6241 isn=E2=80=99t clear.=C2=A0 =C2=A0RFC 6241 seems = to only speak to when the wrong persist-id is passed.=C2=A0 Either case, RE= STCONF SHOULD return the same error-tag value that a NETCONF server returns= for these cases, right?



Our server returns '= ;in-use' and error-app-tag 'outstanding-confirmed-commit'
=
if client B tries a <commit> on client A's confirmed commit.=



rpc-reply {
=C2=A0 rpc-error {
=C2=A0 =C2=A0 error-info {
=C2=A0= =C2=A0 =C2=A0 error-number 373
=C2=A0 =C2=A0 }
=C2=A0 = =C2=A0 error-type protocol
=C2=A0 =C2=A0 error-tag in-use
=C2=A0 =C2=A0 error-severity error
=C2=A0 =C2=A0 error-app-tag= outstanding-confirmed-commit
=C2=A0 =C2=A0 error-message 'ca= nnot perform the operation with confirmed-commit pending'
=C2= =A0 }
}


However, our REST= CONF server supports the confirmed-commit procedure using
query p= arameters (confirmed, persist, persist-id, confirm-timeout) and also
<= div>a POST on /restconf/operations/commit. =C2=A0(IMO some NETCONF operatio= ns are
needed to make RESTCONF as robust as NETCONF)


=C2=A0
Kent


Andy
=C2= =A0



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

--001a1140657853cde80543b65102-- From nobody Thu Dec 15 12:28:44 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A11126CD8; Thu, 15 Dec 2016 12:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdpSA5cLiy1c; Thu, 15 Dec 2016 12:28:40 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBDB81296A7; Thu, 15 Dec 2016 12:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61798; q=dns/txt; s=iport; t=1481833720; x=1483043320; h=from:to:subject:date:message-id:mime-version; bh=qwnh941qR1EkaKY7/w5/AxaFwBWbUBj8X5FlvKDpBuE=; b=gEd+HtFOEUea0JCQK2/UA5NrYBq1/2PmpsILLpWpQ9O6pxVKuZE+aBxf SOV1UVuQhp+aAXg7wt9qYcVDyKucxqgx3qXCC8jtog6wEtXwYf94zgXZO EcO6+UbgowFEUAX3v+vT5dzyxcQGonMOeftxLeZ60oNOLAfEJ+mZEzzIR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQAo/FJY/5xdJa1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJzOQsBAQEBAR9agQYHjUepU4IPggkshhKBbj8UAQIBAQEBAQE?= =?us-ascii?q?BYiiEbxIRCl4BLQsIAQMGAgQwJgEEARoaiEkOLpsDAY12giiDWIcwAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEZBYY2hhaBRoILgX44gl0FjwCFf4VsAYZQilmBfYUBiVa?= =?us-ascii?q?HbIYohA4BHzeBIimDTwUcgV1yAQSHWoENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,353,1477958400"; d="scan'208,217";a="360742141" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2016 20:28:38 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uBFKScJD027964 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Dec 2016 20:28:38 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 15 Dec 2016 15:28:37 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 15 Dec 2016 15:28:37 -0500 From: "Eric Voit (evoit)" To: "netconf@ietf.org" , "'netconf-subscriptions-dt@voit.org'" , NetConf WG Chairs Thread-Topic: Minutes 14-Dec: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts Thread-Index: AdJXEcE9YXnjTzr8TlarA4PrbNqzqA== Date: Thu, 15 Dec 2016 20:28:37 +0000 Message-ID: <37cf381a875e45b8a9da6639195c3fc9@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_37cf381a875e45b8a9da6639195c3fc9XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Minutes 14-Dec: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 20:28:42 -0000 --_000_37cf381a875e45b8a9da6639195c3fc9XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWludXRlcyBwb3N0ZWQgYXQ6DQpodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy95YW5nLXB1 c2gvd2lraS9NaW51dGVzLTIwMTYtMTItMTQNCg0KwrcgICAgICAgIEFzIGFsd2F5cywgb3VyIERl emlnblRNIFRlYW0gaXMgYSBnYXRoZXJpbmcgb2YgaW5kaXZpZHVhbHMgcHJvdmlkaW5nIGluZm9y bWFsIGlucHV0IHRvIE5FVENPTkYuIFdlIGFzayBORVRDT05GIFdHIHRvIGNvbW1lbnQgb24gb3Vy IGRpc2N1c3Npb24gcmVzdWx0cyBhcyBhIHByZXBhcmF0aW9uIGZvciB0aGUgV0cgY29uc2Vuc3Vz LiBQbGVhc2UgYXBwcm9hY2ggRXJpYyBWb2l0IGlmIHlvdSB3YW50IHRvIGJlIGluY2x1ZGVkIGRp cmVjdGx5IGluIHRoZXNlIG1lZXRpbmdzLg0KDQoNCk1lZXRpbmcgTWF0ZXJpYWxzDQoNCkF0dGVu ZGluZw0KDQpXZWJFeCBSZWNvcmRpbmc8aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxl cy9sc3IucGhwP1JDSUQ9MTg3MmMxZDZiNzM0NDM4OWJkYTIxYzU0YTFkYjA3MWQ+DQpwYXNzd29y ZDogSm1uRWlqaTgNCg0KQW5keSBCaWVybWFuLCBBbGV4YW5kZXIgQ2xlbW0sIEFtYmlrYSBUcmlw YXRoeSwgRWluYXIgTmlsc2VuLU55Z2FhcmQsIEVyaWMgVm9pdCwgVGltIEplbmtpbnMsIEJhbGF6 cyBMZW5neWVsLCBNYWhlc2ggSmV0aGFuYW5kYW5pLCBBbWJpa2EgVHJpcGF0aHkNCg0KNTI3N2Jp cyBTY29wZSAmIE5hbWluZw0KDQogICogICBTdHJvbmcgYWdyZWVtZW50IHRoYXQgdGhlIGV4aXN0 aW5nIGZ1bmN0aW9uYWwgc3BsaXQgYmV0d2VlbiA1Mjc3YmlzICYgeWFuZy1wdXNoIGlzIGFwcHJv cHJpYXRlIGFuZCB0aGF0IGJvdGggYXJlIG5lZWRlZA0KICAgICAqICAgQmV5b25kIHRoZSByZWFz b25zIGxpc3Qgb24gdGhlIFdHIGFsaWFzOiBNU0RDIG5lZWRzIHRyYW5zcG9ydHMgb3RoZXIgdGhh biBORVRDT05GICYgUkVTVENPTkYNCiAgKiAgIEFjdGlvbiBJdGVtIGZvciBNYWhlc2ggJiBNZWht ZXQNCiAgICAgKiAgIE5vYm9keSB3ZSBrbm93IG9mIGlzIHN1Z2dlc3RpbmcgZXh0ZW5kaW5nIGNy ZWF0ZS1zdWJzY3JpcHRpb24uIERvIHlvdS9XRyBzdXBwb3J0IHRoZSBwYXRoIHRoYXQgd2UgbWFr ZSA1Mjc3IGxlZ2FjeSwgd2l0aCBhIHJlY29tbWVuZGF0aW9uIHRoYXQgZXhpc3RpbmcgaW1wbGVt ZW50YXRpb25zIGNhbiBhbmQgc2hvdWxkIGNvbnRpbnVlIHRvIGJlIHN1cHBvcnRlZCB2aWEgYW4g YWR2ZXJ0aXNlbWVudCAidXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmlj YXRpb246MS4wIj8NCiAgICAgKiAgIElmIHllcywgZG8gd2UgbmVlZCBhIGNoYXJ0ZXIgY2hhbmdl Pw0KICAgICAgICAqICAgKEVyaWMgYWRkaXRpb24gcG9zdCBtZWV0aW5nKSBJZiB5ZXMsIHRoaXMg Y2hhcnRlciB1cGRhdGUgY291bGQgYmUgYXMgc2ltcGxlIGFzIGNoYW5naW5nIHRoZSBjaGFydGVy IHRleHQgIkVuaGFuY2UgUkZDIDUyNzciIHRvICJDcmVhdGUgYSBzcGVjaWZpY2F0aW9uIHdoaWNo IHRha2VzIFJGQyA1Mjc3IGNhcGFiaWxpdGllcyBhbmQgZW5oYW5jZXMgaXQiDQogICogICBJZi93 aGVuIHRoZSBhcHByb3ByaWF0ZSBjaGFydGVyIGNoYW5nZSBpcyBtYWRlLCB3ZSB3aWxsIGNoYW5n ZSB0aGUgbmFtZSBvZiB0aGUgZG9jIGZyb20gNTI3N2Jpcy4gU3VnZ2VzdGVkIG5hbWUgaXM6IGRy YWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMNCg0KTWFuYWdlbWVudCBv cGVyYXRpb25zIG9uIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucw0KDQogICogICBUaGUgb3BlcmF0 b3IgbmVlZHMgdGhlIGNhcGFiaWxpdHkgdG8gdGVhciBkb3duIGEgRHluYW1pYyBzdWJzY3JpcHRp b24NCiAgICAgKiAgIFdlIHdvbid0IHVzZSBkZWxldGUtc3Vic2NyaXB0aW9uIGFzIE5BQ00gaGFz IG5vIGFiaWxpdHkgdG8gZGlmZmVyZW50aWF0ZQ0KICAqICAgTmV3IEtpbGwgc3Vic2NyaXB0aW9u IFJQQyB3aWxsIGdvIGludG8gNTI3N2Jpcy4NCiAgICAgKiAgIENvdWxkIHB1dCBOQUNNICJ2ZXJ5 LXNlY3VyZSIgdGFnIG9uIHRoaXMgUlBDIHNvIHRoYXQgb25seSBhZG1pbmlzdHJhdG9ycyBjYW4g YWNjZXNzLg0KICAgICAqICAgTXVzdCBiZSBhYmxlIHRvIHN1cHBvcnQgYSBzdWJzY3JpcHRpb24t dGVybWluYXRpb24gbm90aWZpY2F0aW9uIHRvIGR5bmFtaWMgJiBjb25maWd1cmVkIHN1YnNjcmlw dGlvbnMuDQoNCkRhdGEgUGxhbmUgTm90aWZpY2F0aW9ucw0KDQogICogICBTdWJzY3JpcHRpb24g SUQgaW4gZGF0YSBwbGFuZSBuZWVkcyB0byBiZSBkb25lIGFsd2F5cywgYW5kIHdpbGwgYmUgbGF5 ZXJlZCBpbnRvIHRoZSBkb2N1bWVudC4gVGhpcyBpcyBkaWZmZXJlbnQgdGhhbiA1Mjc3Lg0KICAq ICAgSGVhZGVyczogd2Ugd2FudCB0byBhbGxvdyBleHRlbnNpYmlsaXR5IGZvciBkYXRhIHBsYW5l IG5vdGlmaWNhdGlvbnMuIEV4YW1wbGU6IGEgcG90ZW50aWFsIGZvciBUcmFjZS1JRCBmb3IgZGlh Z25vc3RpY3MNCiAgKiAgIEFjdGlvbiBJdGVtOiBBbmR5IGlzIHdpbGxpbmcgdG8gcHJvdmlkZSB0 ZXh0IGZvciB0aGlzLiBUaGlzIGNvdWxkIGJlIGJ1aWx0IG9mZiBvZiBUYWlsRiBleHRlbnNpb24g YXMgc3RhcnRpbmcgcG9pbnQgZm9yIHRoZSBkYXRhIHN0cnVjdHVyZS4NCg0KImlkZW50aWZpZXIi IHZzICJzdWJzY3JpcHRpb24taWQiDQoNCiAgKiAgIFJldmlldyBmcm9tIE1hcnRpbiBzdWdnZXN0 cyBtb3ZpbmcgdG8gImlkZW50aWZpZXIiIGlzIHVzZWQgZm9yIGVkaXQtY29uZmlnLiAic3Vic2Ny aXB0aW9uLWlkIg0KICAqICAgInN1YnNjcmlwdGlvbi1pZCIgaXMgdXNlZCBmb3IgUlBDcz8gSXMg dGhlcmUgYSBjb252ZW50aW9uIGFzIHRvIHdoeSBub3Q/DQogICogICBLZXkgaXMgdGhhdCB3ZSBt dXN0IGRpc2FtYmlndWF0ZS4NCiAgKiAgIFBvc3QgbWVldGluZyBub3RlOiBJIGNhbid0IHNlZSBh IHRpbWUgd2hlcmUgd2Ugd2lsbCBwYXNzIHRoZSBmaWx0ZXIgaWRlbnRpZmllciB2aWEgYW4gUlBD LiAoSXQgaXMganVzdCBiZWluZyBwYXNzZWQgYXMgYSByZWZlcmVuY2UuKSBTbyBpdCBzaG91bGQg YmUgb2sgdG8gdXNlIGlkZW50aWZpZXIgZm9yIGJvdGggb2JqZWN0cy4NCg0KRmlsdGVycy4NCg0K ICAqICAgRG8gd2UgcmVvcGVuIGZpbHRlcnMgYmV5b25kIHhwYXRoIGFuZCA2MjQxPyBBbnN3ZXIg aXMgbm8uDQogICAgICogICBDb21iaW5pbmcgZmlsdGVycyBpcyBoYXJkLiBJdCBkb2Vzbid0IHdv cmsgZm9yIEdldCAmIEdldC1jb25maWcuIEUuZy4sIGRlcHRoIGFuZCBmaWx0ZXJzIGlzbid0IHNv bWV0aGluZyB3ZSB1bmRlcnN0YW5kIHlldC4NCiAgKiAgIFdlIGRvIGFsbG93IGZvciBhdWdtZW50 YXRpb24gZm9yIHRoZXNlIGFzIGEgZnV0dXJlIGZpbHRlciB0eXBlLg0KDQpDb3VudGVycyBmb3Ig UGFzcy9Ecm9wDQoNCiAgKiAgIFN0aWxsIHBlbmRpbmcgaXMgdGhlIG5lZWQgZm9yIG9wZXJhdGlv bmFsIGRhdGEsIGluY2x1ZGluZyB0b3RhbCBhbmQgcGFzc2VkIHVwZGF0ZSBjb3VudGVycy4NCg0K --_000_37cf381a875e45b8a9da6639195c3fc9XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpoMg0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxOC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KaDMNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNv LXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SGVhZGluZyAyIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5r OiJIZWFkaW5nIDIiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5IZWFkaW5nM0NoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsN Cgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LXdlaWdodDpib2xkO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5t LTUwNzE2NTE3Mjk4OTEzMTQ2ODZtc29saXN0cGFyYWdyYXBoLCBsaS5tLTUwNzE2NTE3Mjk4OTEz MTQ2ODZtc29saXN0cGFyYWdyYXBoLCBkaXYubS01MDcxNjUxNzI5ODkxMzE0Njg2bXNvbGlzdHBh cmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTptXy01MDcxNjUxNzI5ODkxMzE0Njg2bXNvbGlzdHBh cmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9u cyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTM4NDI0NzQzOw0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTY2NTcxNjYgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MjY0MDAwODUwOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotNDA4MzY3NTMyO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlz dC1pZDoyNzE0MDQ1ODU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1Mjk2MjI1NTY7fQ0KQGxp c3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjMyNDE2MzYzOTsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6MTU3NzQzNzc2O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs NA0KCXttc28tbGlzdC1pZDo0MzI5NDMyMjc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjM3NjIx NDY3NDt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0Omxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6NjE2OTA5 NTM1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3NDMyMjIzNDA7fQ0KQGxpc3QgbDU6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1 OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGw2DQoJe21zby1saXN0LWlkOjcwNDkwNzQ1MTsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6NDQ4NTg4NTgwO30NCkBsaXN0IGw2OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDY6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNjpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsNjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsNjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNw0KCXttc28tbGlz dC1pZDo3NTcwOTkxNTQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0MDgyODMzODI7fQ0KQGxp c3QgbDc6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNzpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGw3OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3 OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGw3OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3Omxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGw4DQoJe21zby1saXN0LWlkOjEwNjUzNjk1MTk7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0xMzE1OTQwNzYyO30NCkBsaXN0IGw4OmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDg6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsODpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsODpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsOQ0KCXttc28tbGlzdC1pZDoyMDM1NjkzNzQ5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczox ODE3NDcwMzM2O30NCkBsaXN0IGw5OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDk6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsOTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsOTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs OTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsOTpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsOTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsOTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsOTps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTANCgl7bXNvLWxpc3QtaWQ6 MjA3Mzc2ODU3MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA4NTA1MjExNjt9DQpAbGlzdCBs MTA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMTA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEw OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDEwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5NaW51dGVzIHBvc3RlZCBhdDo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJl Zj0iaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cveWFuZy1wdXNoL3dpa2kvTWludXRlcy0y MDE2LTEyLTE0Ij5odHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy95YW5nLXB1c2gvd2lraS9N aW51dGVzLTIwMTYtMTItMTQ8L2E+ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6d2hpdGUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJs YWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+QXMgYWx3YXlzLCBvdXIgRGV6aWduPHN1cD5UTTwvc3VwPiBU ZWFtIGlzIGEgZ2F0aGVyaW5nIG9mIGluZGl2aWR1YWxzIHByb3ZpZGluZyBpbmZvcm1hbCBpbnB1 dCB0byBORVRDT05GLiBXZSBhc2sgTkVUQ09ORiBXRyB0byBjb21tZW50IG9uIG91ciBkaXNjdXNz aW9uDQogcmVzdWx0cyBhcyBhIHByZXBhcmF0aW9uIGZvciB0aGUgV0cgY29uc2Vuc3VzLiBQbGVh c2UgYXBwcm9hY2ggRXJpYyBWb2l0IGlmIHlvdSB3YW50IHRvIGJlIGluY2x1ZGVkIGRpcmVjdGx5 IGluIHRoZXNlIG1lZXRpbmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSIxNDAwIiBzdHlsZT0id2lkdGg6NTI1LjBwdDtiYWNrZ3JvdW5kOndoaXRlO2JvcmRlci1jb2xs YXBzZTpjb2xsYXBzZSI+DQo8dGhlYWQ+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpzb2xpZCAj REREREREIDEuMHB0O3BhZGRpbmc6NC41cHQgOS43NXB0IDQuNXB0IDkuNzVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7 dGV4dC1hbGlnbjpjZW50ZXIiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Nl Z29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+TWVldGluZyBNYXRlcmlhbHM8 L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8 L3RkPg0KPHRkIHN0eWxlPSJib3JkZXI6c29saWQgI0RERERERCAxLjBwdDtib3JkZXItbGVmdDpu b25lO3BhZGRpbmc6NC41cHQgOS43NXB0IDQuNXB0IDkuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGln bjpjZW50ZXIiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+QXR0ZW5kaW5nPG86cD48L286cD48L3NwYW4+ PC9iPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90aGVhZD4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iYm94 LXNpemluZzogYm9yZGVyLWJveCI+DQo8dGQgc3R5bGU9ImJvcmRlcjpzb2xpZCAjREREREREIDEu MHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjQuNXB0IDkuNzVwdCA0LjVwdCA5Ljc1cHQ7Ym94 LXNpemluZzogYm9yZGVyLWJveCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2Vi ZXguY29tL2Npc2Nvc2FsZXMvbHNyLnBocD9SQ0lEPTE4NzJjMWQ2YjczNDQzODliZGEyMWM1NGEx ZGIwNzFkIj48c3BhbiBzdHlsZT0iY29sb3I6IzQwNzhDMDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ V2ViRXgNCiBSZWNvcmRpbmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMz MyI+cGFzc3dvcmQ6IEptbkVpamk4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBz dHlsZT0iYm9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp ZCAjREREREREIDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAjREREREREIDEuMHB0O3BhZGRpbmc6 NC41cHQgOS43NXB0IDQuNXB0IDkuNzVwdDtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMz MyI+QW5keSBCaWVybWFuLCBBbGV4YW5kZXIgQ2xlbW0sIEFtYmlrYSBUcmlwYXRoeSwgRWluYXIg Tmlsc2VuLU55Z2FhcmQsIEVyaWMgVm9pdCwgVGltIEplbmtpbnMsIEJhbGF6cyBMZW5neWVsLCBN YWhlc2ggSmV0aGFuYW5kYW5pLCBBbWJpa2EgVHJpcGF0aHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1l bnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgI0VFRUVF RSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gNC4wcHQgMGluO2JhY2tncm91bmQ6d2hpdGUiPg0KPGgy IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6LjI1aW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47YmFja2dyb3VuZDp3aGl0ZTtib3JkZXI6bm9u ZTtwYWRkaW5nOjBpbjtib3gtc2l6aW5nOiBib3JkZXItYm94O2ZvbnQtdmFyaWFudC1saWdhdHVy ZXM6IG5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGln bjpzdGFydDt3aWRvd3M6IDI7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+NTI3N2JpcyBTY29wZSAmYW1wOyBOYW1pbmc8bzpw PjwvbzpwPjwvc3Bhbj48L2gyPg0KPC9kaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzY7YmFja2dy b3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5TdHJvbmcgYWdyZWVtZW50IHRo YXQgdGhlIGV4aXN0aW5nIGZ1bmN0aW9uYWwgc3BsaXQgYmV0d2VlbiA1Mjc3YmlzICZhbXA7IHlh bmctcHVzaCBpcyBhcHByb3ByaWF0ZSBhbmQgdGhhdCBib3RoIGFyZSBuZWVkZWQ8bzpwPjwvbzpw Pjwvc3Bhbj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0Omw0IGxldmVsMiBsZm82O2JhY2tncm91bmQ6d2hpdGU7Ym94LXNp emluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkmcXVvdDssc2Fucy1zZXJpZiI+QmV5b25kIHRoZSByZWFzb25zIGxpc3Qgb24gdGhlIFdHIGFs aWFzOiBNU0RDIG5lZWRzIHRyYW5zcG9ydHMgb3RoZXIgdGhhbiBORVRDT05GICZhbXA7IFJFU1RD T05GPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsNCBsZXZlbDEgbGZvNjtiYWNrZ3JvdW5kOndoaXRlO2JveC1z aXppbmc6IGJvcmRlci1ib3giPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+QWN0aW9uIEl0ZW0gZm9yIE1haGVzaCAmYW1w OyBNZWhtZXQ8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Nl Z29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPg0KPHVsIHR5cGU9ImNp cmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQg bGV2ZWwyIGxmbzY7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5O b2JvZHkgd2Uga25vdyBvZiBpcyBzdWdnZXN0aW5nIGV4dGVuZGluZyBjcmVhdGUtc3Vic2NyaXB0 aW9uLiBEbyB5b3UvV0cgc3VwcG9ydCB0aGUgcGF0aCB0aGF0IHdlIG1ha2UgNTI3NyBsZWdhY3ks IHdpdGggYSByZWNvbW1lbmRhdGlvbiB0aGF0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBjYW4g YW5kIHNob3VsZCBjb250aW51ZSB0byBiZSBzdXBwb3J0ZWQgdmlhDQogYW4gYWR2ZXJ0aXNlbWVu dCAmcXVvdDt1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5Om5vdGlmaWNhdGlvbjox LjAmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsNCBsZXZlbDIgbGZvNjtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6 IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1 b3Q7LHNhbnMtc2VyaWYiPklmIHllcywgZG8gd2UgbmVlZCBhIGNoYXJ0ZXIgY2hhbmdlPzxvOnA+ PC9vOnA+PC9zcGFuPg0KPHVsIHR5cGU9InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQgbGV2ZWwzIGxmbzY7YmFja2dyb3VuZDp3aGl0ZTti b3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj4oRXJpYyBhZGRpdGlvbiBwb3N0IG1lZXRpbmcpIElm IHllcywgdGhpcyBjaGFydGVyIHVwZGF0ZSBjb3VsZCBiZSBhcyBzaW1wbGUgYXMgY2hhbmdpbmcg dGhlIGNoYXJ0ZXIgdGV4dCAmcXVvdDtFbmhhbmNlIFJGQyA1Mjc3JnF1b3Q7IHRvICZxdW90O0Ny ZWF0ZSBhIHNwZWNpZmljYXRpb24gd2hpY2ggdGFrZXMgUkZDIDUyNzcgY2FwYWJpbGl0aWVzIGFu ZCBlbmhhbmNlcyBpdCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvbGk+PC91 bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21hcmdp bi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQgbGV2ZWwx IGxmbzY7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5JZi93aGVu IHRoZSBhcHByb3ByaWF0ZSBjaGFydGVyIGNoYW5nZSBpcyBtYWRlLCB3ZSB3aWxsIGNoYW5nZSB0 aGUgbmFtZSBvZiB0aGUgZG9jIGZyb20gNTI3N2Jpcy4gU3VnZ2VzdGVkIG5hbWUgaXM6IGRyYWZ0 LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjwvdWw+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVy Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjRUVFRUVFIDEuMHB0O3BhZGRpbmc6MGluIDBpbiA0 LjBwdCAwaW47YmFja2dyb3VuZDp3aGl0ZSI+DQo8aDIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDouMjVpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0 OjBpbjtiYWNrZ3JvdW5kOndoaXRlO2JvcmRlcjpub25lO3BhZGRpbmc6MGluO2JveC1zaXppbmc6 IGJvcmRlci1ib3g7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMz Ij5NYW5hZ2VtZW50IG9wZXJhdGlvbnMgb24gY29uZmlndXJlZCBzdWJzY3JpcHRpb25zPG86cD48 L286cD48L3NwYW4+PC9oMj4NCjwvZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm83O2JhY2tncm91 bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIG9wZXJhdG9yIG5lZWRzIHRo ZSBjYXBhYmlsaXR5IHRvIHRlYXIgZG93biBhIER5bmFtaWMgc3Vic2NyaXB0aW9uPG86cD48L286 cD48L3NwYW4+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6IzMzMzMzMzttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDIgbGZvNztiYWNrZ3JvdW5kOndoaXRlO2JveC1z aXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29l IFVJJnF1b3Q7LHNhbnMtc2VyaWYiPldlIHdvbid0IHVzZSBkZWxldGUtc3Vic2NyaXB0aW9uIGFz IE5BQ00gaGFzIG5vIGFiaWxpdHkgdG8gZGlmZmVyZW50aWF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMz O21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIg bGV2ZWwxIGxmbzc7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5O ZXcgS2lsbCBzdWJzY3JpcHRpb24gUlBDIHdpbGwgZ28gaW50byA1Mjc3YmlzLjxvOnA+PC9vOnA+ PC9zcGFuPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzc7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6 aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBV SSZxdW90OyxzYW5zLXNlcmlmIj5Db3VsZCBwdXQgTkFDTSAmcXVvdDt2ZXJ5LXNlY3VyZSZxdW90 OyB0YWcgb24gdGhpcyBSUEMgc28gdGhhdCBvbmx5IGFkbWluaXN0cmF0b3JzIGNhbiBhY2Nlc3Mu PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9y OiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMiBsZXZlbDIgbGZvNztiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJvcmRlci1i b3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt c2VyaWYiPk11c3QgYmUgYWJsZSB0byBzdXBwb3J0IGEgc3Vic2NyaXB0aW9uLXRlcm1pbmF0aW9u IG5vdGlmaWNhdGlvbiB0byBkeW5hbWljICZhbXA7IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucy48 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2xpPjwvdWw+DQo8ZGl2IHN0eWxlPSJtc28t ZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAj RUVFRUVFIDEuMHB0O3BhZGRpbmc6MGluIDBpbiA0LjBwdCAwaW47YmFja2dyb3VuZDp3aGl0ZSI+ DQo8aDIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDouMjVpbjttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbjtiYWNrZ3JvdW5kOndoaXRlO2JvcmRl cjpub25lO3BhZGRpbmc6MGluO2JveC1zaXppbmc6IGJvcmRlci1ib3g7Zm9udC12YXJpYW50LWxp Z2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5EYXRhIFBsYW5lIE5vdGlmaWNhdGlvbnM8 bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0KPC9kaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzg7YmFj a2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5TdWJzY3JpcHRpb24gSUQg aW4gZGF0YSBwbGFuZSBuZWVkcyB0byBiZSBkb25lIGFsd2F5cywgYW5kIHdpbGwgYmUgbGF5ZXJl ZCBpbnRvIHRoZSBkb2N1bWVudC4gVGhpcyBpcyBkaWZmZXJlbnQgdGhhbiA1Mjc3LjxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMz O21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMg bGV2ZWwxIGxmbzg7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5I ZWFkZXJzOiB3ZSB3YW50IHRvIGFsbG93IGV4dGVuc2liaWxpdHkgZm9yIGRhdGEgcGxhbmUgbm90 aWZpY2F0aW9ucy4gRXhhbXBsZTogYSBwb3RlbnRpYWwgZm9yIFRyYWNlLUlEIGZvciBkaWFnbm9z dGljczxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj b2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzg7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3Jk ZXItYm94Ij4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJ JnF1b3Q7LHNhbnMtc2VyaWYiPkFjdGlvbiBJdGVtOiBBbmR5IGlzIHdpbGxpbmcgdG8gcHJvdmlk ZSB0ZXh0IGZvciB0aGlzLjwvc3Bhbj48L3N0cm9uZz48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+VGhpcw0KIGNvdWxkIGJlIGJ1aWx0IG9m ZiBvZiBUYWlsRiBleHRlbnNpb24gYXMgc3RhcnRpbmcgcG9pbnQgZm9yIHRoZSBkYXRhIHN0cnVj dHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVu dDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjRUVFRUVF IDEuMHB0O3BhZGRpbmc6MGluIDBpbiA0LjBwdCAwaW47YmFja2dyb3VuZDp3aGl0ZSI+DQo8aDIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDouMjVpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbjtiYWNrZ3JvdW5kOndoaXRlO2JvcmRlcjpub25l O3BhZGRpbmc6MGluO2JveC1zaXppbmc6IGJvcmRlci1ib3g7Zm9udC12YXJpYW50LWxpZ2F0dXJl czogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWdu OnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj4mcXVvdDtpZGVudGlmaWVyJnF1b3Q7IHZzICZxdW90 O3N1YnNjcmlwdGlvbi1pZCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8L2Rpdj4NCjx1 bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMz Mzttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsNyBsZXZlbDEgbGZvOTtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJvcmRlci1i b3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt c2VyaWYiPlJldmlldyBmcm9tIE1hcnRpbiBzdWdnZXN0cyBtb3ZpbmcgdG8gJnF1b3Q7aWRlbnRp ZmllciZxdW90OyBpcyB1c2VkIGZvciBlZGl0LWNvbmZpZy4gJnF1b3Q7c3Vic2NyaXB0aW9uLWlk JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsNyBsZXZlbDEgbGZvOTtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJv cmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7 LHNhbnMtc2VyaWYiPiZxdW90O3N1YnNjcmlwdGlvbi1pZCZxdW90OyBpcyB1c2VkIGZvciBSUENz PyBJcyB0aGVyZSBhIGNvbnZlbnRpb24gYXMgdG8gd2h5IG5vdD88bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9w OjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw3IGxldmVsMSBsZm85 O2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+S2V5IGlzIHRoYXQg d2UgbXVzdCBkaXNhbWJpZ3VhdGUuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNyBsZXZlbDEgbGZvOTtiYWNrZ3JvdW5kOndoaXRl O2JveC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPlBvc3QgbWVldGluZyBub3RlOiBJIGNhbid0IHNl ZSBhIHRpbWUgd2hlcmUgd2Ugd2lsbCBwYXNzIHRoZSBmaWx0ZXIgaWRlbnRpZmllciB2aWEgYW4g UlBDLiAoSXQgaXMganVzdCBiZWluZyBwYXNzZWQgYXMgYSByZWZlcmVuY2UuKSBTbyBpdCBzaG91 bGQgYmUgb2sgdG8gdXNlIGlkZW50aWZpZXIgZm9yIGJvdGggb2JqZWN0cy48bzpwPjwvbzpwPjwv c3Bhbj48L2xpPjwvdWw+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7 Ym9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjRUVFRUVFIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiA0LjBwdCAwaW47YmFja2dyb3VuZDp3aGl0ZSI+DQo8aDIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDouMjVpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdp bi1sZWZ0OjBpbjtiYWNrZ3JvdW5kOndoaXRlO2JvcmRlcjpub25lO3BhZGRpbmc6MGluO2JveC1z aXppbmc6IGJvcmRlci1ib3g7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjst d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MzMzMzMzIj5GaWx0ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8L2Rpdj4NCjx1bCB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps MTAgbGV2ZWwxIGxmbzEwO2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJp ZiI+RG8gd2UgcmVvcGVuIGZpbHRlcnMgYmV5b25kIHhwYXRoIGFuZCA2MjQxPyBBbnN3ZXIgaXMg bm8uPG86cD48L286cD48L3NwYW4+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMTAgbGV2ZWwyIGxmbzEwO2JhY2tncm91 bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+Q29tYmluaW5nIGZpbHRlcnMgaXMg aGFyZC4gSXQgZG9lc24ndCB3b3JrIGZvciBHZXQgJmFtcDsgR2V0LWNvbmZpZy4gRS5nLiwgZGVw dGggYW5kIGZpbHRlcnMgaXNuJ3Qgc29tZXRoaW5nIHdlIHVuZGVyc3RhbmQgeWV0LjxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj b2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDEwIGxldmVsMSBsZm8xMDtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJv cmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7 LHNhbnMtc2VyaWYiPldlIGRvIGFsbG93IGZvciBhdWdtZW50YXRpb24gZm9yIHRoZXNlIGFzIGEg ZnV0dXJlIGZpbHRlciB0eXBlLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxkaXYgc3R5 bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6bm9uZTtib3JkZXItYm90dG9t OnNvbGlkICNFRUVFRUUgMS4wcHQ7cGFkZGluZzowaW4gMGluIDQuMHB0IDBpbjtiYWNrZ3JvdW5k OndoaXRlIj4NCjxoMiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0Oi4yNWluO21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluO2JhY2tncm91bmQ6d2hp dGU7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW47Ym94LXNpemluZzogYm9yZGVyLWJveDtmb250LXZh cmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5z OiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkNvdW50ZXJzIGZvciBQYXNz L0Ryb3A8bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0KPC9kaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzExO2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+U3RpbGwgcGVu ZGluZyBpcyB0aGUgbmVlZCBmb3Igb3BlcmF0aW9uYWwgZGF0YSwgaW5jbHVkaW5nIHRvdGFsIGFu ZCBwYXNzZWQgdXBkYXRlIGNvdW50ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_37cf381a875e45b8a9da6639195c3fc9XCHRTP013ciscocom_-- From nobody Thu Dec 15 12:45:46 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED796129446 for ; Thu, 15 Dec 2016 12:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 AmSchMDMuiIh for ; Thu, 15 Dec 2016 12:45:43 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 719BB126CD8 for ; Thu, 15 Dec 2016 12:45:43 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 557EA1AE018B; Thu, 15 Dec 2016 21:45:42 +0100 (CET) Date: Thu, 15 Dec 2016 21:45:42 +0100 (CET) Message-Id: <20161215.214542.1421958322980601199.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20161215.124711.2216477344616156120.mbj@tail-f.com> <19D8E110-ADA3-4652-9338-D8136511690D@juniper.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [Netconf] Inconsistency in Section 1.4 of draft-ietf-netconf-restconf-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 20:45:45 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUaHUsIERlYyAx NSwgMjAxNiBhdCA5OjU1IEFNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3Jv dGU6DQo+IA0KPiA+DQo+ID4NCj4gPiAiTWVobWV0IEVyc3VlIiA8bWVyc3VlQGdtYWlsLmNvbT4g d3JvdGU6DQo+ID4gPiBEZWFyIE5FVENPTkYgV0csDQo+ID4gPg0KPiA+ID4gUkZDIEVkaXRvciBm b3VuZCBhbiBpbmNvbnNpc3RlbmN5IGluIFNlY3Rpb24gMS40IG9mDQo+ID4gPiBkcmFmdC1pZXRm LW5ldGNvbmYtcmVzdGNvbmYtMTgsIHdoZXJlIHBhcmFncmFwaCA2IHNheXM6DQo+ID4gPg0KPiA+ ID4gICAgIklmIHRoZSBORVRDT05GIHNlcnZlciBpcyBleHBlY3RpbmcgYQ0KPiA+ID4gICAgInBl cnNpc3QtaWQiIHBhcmFtZXRlciB0byBjb21wbGV0ZSB0aGUgY29uZmlybWVkIGNvbW1pdCBwcm9j ZWR1cmUNCj4gPiA+ICAgIHRoZW4gdGhlIFJFU1RDT05GIGVkaXQgb3BlcmF0aW9uIE1VU1QgZmFp bCB3aXRoIGEgIjQwOSBDb25mbGljdCINCj4gPiA+ICAgIHN0YXR1cy1saW5lLiAgVGhlcmUgZXJy b3ItdGFnICJpbi11c2UiIGlzIHJldHVybmVkIGluIHRoaXMgY2FzZS4gIFRoZQ0KPiA+ID4gICAg ZXJyb3ItdGFnIHZhbHVlICJyZXNvdXJjZS1kZW5pZWQiIGlzIHVzZWQgaW4gdGhpcyBjYXNlLiIN Cj4gPiA+DQo+ID4gPiBNeXNlbGYgYXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkIGFuZCB0aGUgYXV0 aG9ycyBhZ3JlZWQgdG8gdXNlIHRoZQ0KPiA+IGVycm9yLXRhZw0KPiA+ID4gdmFsdWUgImludmFs aWQgdmFsdWUiIHRvIGFsaWduIHdpdGggdGhlIG9wZXJhdGlvbnMgPGNhbmNlbC1jb21taXQ+IGFu ZA0KPiA+ID4gPGNvbW1pdD4gaW4gUkZDIDYyNDEuDQo+ID4gPiBUaGUgY29ycmVjdGlvbiB3aWxs IGJlIGRvbmUgYXMgYmVsb3c6DQo+ID4gPg0KPiA+ID4gT0xEOg0KPiA+ID4gICAgVGhlcmUgZXJy b3ItdGFnICJpbi11c2UiIGlzIHJldHVybmVkIGluIHRoaXMgY2FzZS4gIFRoZQ0KPiA+ID4gICAg ZXJyb3ItdGFnIHZhbHVlICJyZXNvdXJjZS1kZW5pZWQiIGlzIHVzZWQgaW4gdGhpcyBjYXNlLg0K PiA+ID4NCj4gPiA+IE5FVzoNCj4gPiA+ICAgICAgIFRoZSBlcnJvci10YWcgdmFsdWUgImludmFs aWQtdmFsdWUiIGlzIHVzZWQgaW4gdGhpcyBjYXNlLg0KPiA+ID4NCj4gPiA+IFBsZWFzZSBzcGVh ayB1cCB3aXRoaW4gMiBkYXlzIGlmIHlvdSBoYXZlIGEgc3Ryb25nIG9iamVjdGlvbi4NCj4gPg0K PiA+IEkgZG9uJ3QgdGhpbmsgaW52YWxpZC12YWx1ZSBpcyBhcHByb3ByaWF0ZS4gIEl0IHNpZ25h bHMgdGhhdCB0aGUNCj4gPiBjbGllbnQgcHJvdmlkZWQgYW4gaW52YWxpZCB2YWx1ZSBmb3Igc29t ZSBwYXJhbWV0ZXIsIGJ1dCB0aGF0J3Mgbm90DQo+ID4gdHJ1ZSBpbiB0aGlzIGNhc2UgLSB0aGVy ZSBpcyBub3RoaW5nIHRoZSBjbGllbnQgY2FuIGRvIGluIG9yZGVyIHRvIGZpeA0KPiA+IHRoZSBz aXR1YXRpb24uICBJIHByZWZlciB0byB1c2UgJ3Jlc291cmNlLWRlbmllZCcgKHdoaWNoIGlzIGFj dHVhbGx5DQo+ID4gd2hhdCBNZWhtZXQgc3VnZ2VzdGVkKS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBX aGF0IGRvIE5FVENPTkYgc2VydmVycyByZXR1cm4gd2hlbiBubyBwZXJzaXN0LWlkIGlzIHBhc3Nl ZCBldmVuIHRob3VnaA0KPiA+IG9uZSBpcyBuZWVkZWQ/ICBSRkMgNjI0MSBpc27igJl0IGNsZWFy LiAgIFJGQyA2MjQxIHNlZW1zIHRvIG9ubHkgc3BlYWsgdG8NCj4gPiB3aGVuIHRoZSB3cm9uZyBw ZXJzaXN0LWlkIGlzIHBhc3NlZC4gIEVpdGhlciBjYXNlLCBSRVNUQ09ORiBTSE9VTEQgcmV0dXJu DQo+ID4gdGhlIHNhbWUgZXJyb3ItdGFnIHZhbHVlIHRoYXQgYSBORVRDT05GIHNlcnZlciByZXR1 cm5zIGZvciB0aGVzZSBjYXNlcywNCj4gPiByaWdodD8NCg0KQWdyZWVkLCBidXQgYXMgeW91IG5v dGUgUkZDIDYyNDEgaXMgbm90IGNsZWFyIG9uIHRoZSB0b3BpYy4NCg0KPiBPdXIgc2VydmVyIHJl dHVybnMgJ2luLXVzZScNCg0KT3VyIGRvZXMgdGhhdCBhcyB3ZWxsLg0KDQoNCkFjdHVhbGx5LCB0 aGUgZGVzY3JpcHRpb24gZm9yIGluLXVzZSBzYXlzOg0KDQogICBEZXNjcmlwdGlvbjogICAgVGhl IHJlcXVlc3QgcmVxdWlyZXMgYSByZXNvdXJjZSB0aGF0IGFscmVhZHkgaXMgaW4NCiAgICAgICAg ICAgICAgICAgICB1c2UuDQoNCndoaWNoIG1hdGNoZXMgdGhpcyBjYXNlIGZhaXJseSB3ZWxsLg0K DQpyZXNvdXJjZS1kZW5pZWQgbWVhbnMgc29tZXRoaW5nIGVsc2U6DQoNCiAgIERlc2NyaXB0aW9u OiAgICBSZXF1ZXN0IGNvdWxkIG5vdCBiZSBjb21wbGV0ZWQgYmVjYXVzZSBvZg0KICAgICAgICAg ICAgICAgICAgIGluc3VmZmljaWVudCByZXNvdXJjZXMuDQoNCg0KU28sIGluLXVzZSBpcyBwcm9i YWJseSBiZXR0ZXIuDQoNCg0KL21hcnRpbg0K From nobody Thu Dec 15 21:44:22 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB181293F8 for ; Thu, 15 Dec 2016 21:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, 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 uObySJ5khU6V for ; Thu, 15 Dec 2016 21:44:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3C5129541 for ; Thu, 15 Dec 2016 21:44:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXE63581; Fri, 16 Dec 2016 05:44:14 +0000 (GMT) Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 16 Dec 2016 05:44:13 +0000 Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.221]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0301.000; Fri, 16 Dec 2016 13:44:02 +0800 From: Rohit R Ranade To: "netconf@ietf.org" Thread-Topic: Leaf-list usage Thread-Index: AdJXX2aakgSC5E/YQlukLb5liyQxsw== Date: Fri, 16 Dec 2016 05:44:02 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B004002@DGGEMA502-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.242.206] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6B004002DGGEMA502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58537F2F.019D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.221, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3996e83d90f485caa55005401cfc68b5 Archived-At: Subject: [Netconf] Leaf-list usage X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 05:44:21 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A6B004002DGGEMA502MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was going through the ietf discussion for leaf-list subtree and found a l= ink (https://www.ietf.org/mail-archive/web/netmod/current/msg01982.html) A question that I have : 1) Consider leaf-list f1=3D [1, 2, 3] in DB.. If I provide condition o= n leaflist f1=3D[1], will it select [1,2,3] ? Will it always be sub-set ma= tch ? How to get an exact match for the whole leaf-list. --_000_991B70D8B4112A4699D5C00DDBBF878A6B004002DGGEMA502MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was going through the ietf discussion for leaf-lis= t subtree and found a link (https://www.ietf.org/mail-archive/web/netmo= d/current/msg01982.html)

 

A question that I have :

1)      Consider leaf-list f1=3D [1, 2, 3] in DB.. If I pro= vide condition on leaflist f1=3D[1],  will it select [1,2,3] ? Will it= always be sub-set match   ? How to get an exact match for the wh= ole leaf-list.  

 

 

--_000_991B70D8B4112A4699D5C00DDBBF878A6B004002DGGEMA502MBXchi_-- From nobody Fri Dec 16 01:53:11 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3462B129417; Fri, 16 Dec 2016 01:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 CzsSq5NeC9xo; Fri, 16 Dec 2016 01:53:07 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 28AA8129461; Fri, 16 Dec 2016 01:53:07 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 5C96B1AE028C; Fri, 16 Dec 2016 10:53:06 +0100 (CET) Date: Fri, 16 Dec 2016 10:53:06 +0100 (CET) Message-Id: <20161216.105306.1840712711228239629.mbj@tail-f.com> To: evoit@cisco.com From: Martin Bjorklund In-Reply-To: <37cf381a875e45b8a9da6639195c3fc9@XCH-RTP-013.cisco.com> References: <37cf381a875e45b8a9da6639195c3fc9@XCH-RTP-013.cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netconf@ietf.org, netconf-subscriptions-dt@voit.org, netconf-chairs@ietf.org Subject: Re: [Netconf] Minutes 14-Dec: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 09:53:09 -0000 Hi Eric, "Eric Voit (evoit)" wrote: > Minutes posted at: > https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-12-14 > = > =B7 As always, our DezignTM Team is a gathering of individuals= providing informal input to NETCONF. We ask NETCONF WG to comment on o= ur discussion results as a preparation for the WG consensus. Please app= roach Eric Voit if you want to be included directly in these meetings. > = > = > Meeting Materials > = > Attending > = > WebEx Recording > password: JmnEiji8 > = > Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard,= Eric Voit, Tim Jenkins, Balazs Lengyel, Mahesh Jethanandani, Ambika Tr= ipathy > = > 5277bis Scope & Naming > = > * Strong agreement that the existing functional split between 527= 7bis & yang-push is appropriate and that both are needed It is great that you publish these minutes, but this topic is an ongoing discussion in the WG on the ML. So could we please continue the discussion on the list? Hmm, you wrote split between 5277bis and yang-push; maybe this is a new issue? The current discussion is re. the split between 5277bis and event-notifications. /martin > * Beyond the reasons list on the WG alias: MSDC needs transpor= ts other than NETCONF & RESTCONF > * Action Item for Mahesh & Mehmet > * Nobody we know of is suggesting extending create-subscriptio= n. Do you/WG support the path that we make 5277 legacy, with a recommen= dation that existing implementations can and should continue to be supp= orted via an advertisement "urn:ietf:params:netconf:capability:notifica= tion:1.0"? > * If yes, do we need a charter change? > * (Eric addition post meeting) If yes, this charter update = could be as simple as changing the charter text "Enhance RFC 5277" to "= Create a specification which takes RFC 5277 capabilities and enhances i= t" > * If/when the appropriate charter change is made, we will change = the name of the doc from 5277bis. Suggested name is: draft-ietf-netconf= -subscribed-notifications > = > Management operations on configured subscriptions > = > * The operator needs the capability to tear down a Dynamic subscr= iption > * We won't use delete-subscription as NACM has no ability to d= ifferentiate > * New Kill subscription RPC will go into 5277bis. > * Could put NACM "very-secure" tag on this RPC so that only ad= ministrators can access. > * Must be able to support a subscription-termination notificat= ion to dynamic & configured subscriptions. > = > Data Plane Notifications > = > * Subscription ID in data plane needs to be done always, and will= be layered into the document. This is different than 5277. > * Headers: we want to allow extensibility for data plane notifica= tions. Example: a potential for Trace-ID for diagnostics > * Action Item: Andy is willing to provide text for this. This cou= ld be built off of TailF extension as starting point for the data struc= ture. > = > "identifier" vs "subscription-id" > = > * Review from Martin suggests moving to "identifier" is used for = edit-config. "subscription-id" > * "subscription-id" is used for RPCs? Is there a convention as to= why not? > * Key is that we must disambiguate. > * Post meeting note: I can't see a time where we will pass the fi= lter identifier via an RPC. (It is just being passed as a reference.) S= o it should be ok to use identifier for both objects. > = > Filters. > = > * Do we reopen filters beyond xpath and 6241? Answer is no. > * Combining filters is hard. It doesn't work for Get & Get-con= fig. E.g., depth and filters isn't something we understand yet. > * We do allow for augmentation for these as a future filter type.= > = > Counters for Pass/Drop > = > * Still pending is the need for operational data, including total= and passed update counters. > = From nobody Fri Dec 16 09:21:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D7C1296CD for ; Fri, 16 Dec 2016 09:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Sgxuwo9w45p for ; Fri, 16 Dec 2016 09:21:47 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1B31279EB for ; Fri, 16 Dec 2016 09:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6692; q=dns/txt; s=iport; t=1481908907; x=1483118507; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NI8Yw/o0pvg2+rYEcVdrPJMIGteWQQLxBlADe/Jliok=; b=UEY5hL7tJwwYxvweOe/haysdk8fvUxrhqv5KE7ZDi7q0YERfGxjL4fuh bqHXC1qqby7lsenwTQwEYlsI2d2HclO+vET5RS3Azvh905kWF01V9X3Hh IrmaQTByUQBfO6llkKLhDzeTneu8rWL2m0nNXGqJ+g34ksAuLfIblPV14 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQB5IVRY/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9agQYHjUeWV5UNggkqhXgCghg/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQECAQESKDYJBQsCAQgOBwMNERAyJQIEAQ0FCBMHiEEIDpoeAZAeix8BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYY2hFmEKoV3BZpwAYZRgxKHSIF9jlmHcIY?= =?us-ascii?q?phA4BHzeBIimDVByBXXIBh2+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,358,1477958400"; d="scan'208";a="173739027" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2016 17:21:46 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBGHLjrj032718 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Dec 2016 17:21:46 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 16 Dec 2016 12:21:45 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 16 Dec 2016 12:21:45 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund , "andy@yumaworks.com" Thread-Topic: [Netconf] Subscription Use Cases Thread-Index: AQHSUTKNz0LSmZX5b0GYyl1Cgj0Ou6D+G3xggAGB64D///FKsIAAZEcAgAAdoYCAAAL2gIAKrZ7w Date: Fri, 16 Dec 2016 17:21:45 +0000 Message-ID: References: <5e06ffa5d92a4227ae1d64bc8531ac40@XCH-RTP-013.cisco.com> <20161209.143306.1544319624979225814.mbj@tail-f.com> <20161209.162945.891266044701376554.mbj@tail-f.com> In-Reply-To: <20161209.162945.891266044701376554.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 17:21:50 -0000 > From: Martin Bjorklund, December 9, 2016 10:30 AM >=20 > Andy Bierman wrote: > > On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund wrote= : > > > > > "Eric Voit (evoit)" wrote: > > > > > From: Martin Bjorklund, December 9, 2016 3:27 AM > > > > > > > > > > "Eric Voit (evoit)" wrote: > > > > > > Hi Martin, > > > > > > > > > > > > > From: Martin Bjorklund, December 8, 2016 4:08 AM > > > > > > > > > > > > > > I think your requirements below are more like driving forces > > > > > > > for YANG push, right? Is there any of these that affects > > > > > > > the solution in RFC 5277? > > > > > > > > > > > > The majority of these cases need yang-push. But yang push is > > > > > > only possible when the information is yang modeled. > > > > > > > > > > Sure, but that's a completely different thing. > > > > > > > > > > This discussion is about what needs to be done with RFC 5277. > > > > > I'll > > > re-iterate > > > > > what Andy wrote once more: > > > > > > > > > > What are the must-have, should-have, and nice-to-have features > > > > > that > > > are > > > > > missing from RFC 5277? > > > > > > > > At a high level incremental functionality we have been discussing > > > > since > > > IETF 94, 95, 96, 97 includes: > > > > - configured subscriptions > > > > - many subscriptions per transport > > > > - modify and delete subscriptions > > > > - control plane notifications > > > > - Restconf & HTTP support > > > > - Data plan notification including subscription-id > > > > > > > > At a medium level, existing documentation detailing these > > > > requirements > > > can be seen in places like: > > > > https://www.ietf.org/proceedings/95/slides/slides-95-netconf-7.pdf > > > Slide 5 > > > > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf > > > Slides 5, 28 > > > > https://www.ietf.org/proceedings/97/slides/slides- > > > 97-netconf-draft-ietf-netconf-yang-push-01.pdf Slides 20 & 21 > > > > > > I think the list above summarizes what's in the slides. > > > > > > So, let me re-order this list a bit: > > > > > > - configured subscriptions > > > - many subscriptions per transport > > > - Data plan notification including subscription-id > > > - modify and delete subscriptions > > > > > > I don't view "control plane notifications" as a deficiency of 5277; > > > it already has a few, and if new functionality requires us to define > > > more control plane notifications, that's not a problem. > > > > > > As for "Restconf & HTTP support", RESTCONF already supports > > > notifications, and there need to be a RESTCONF-specific solution in > > > place. I do agree that if we open 5277, we should make sure we have > > > a small protocol-dependent part, and a generic, protocol-independent > > > part. > > > > > > So there are really two (major) requirements: > > > > > > 1. configured subscriptions > > > 2. many subscriptions per transport session > > > > > > Do you agree, or did I miss anything? > > > > > > (1) can be done completely backwards compatible; in fact it might > > > not even require an update to 5277. > > > > > > (2) requires an update to the element, as discussed > > > earlier. > > > > > > Did you want to make support for (2) mandatory to implement? If so, > > > we need to make :interleave mandatory, or remove it. > > > > > > Maybe it should be noted that when SSH is used, there really is no > > > need for (2), since it is trivial and cheap to open new SSH channels. > > > I thus assume that the reason for wanting to do (2) is that sessions > > > are expensive when SSH is not used. > > > > > > > > > > Why are configured subscriptions needed if we have Call-home for both > > NETCONF and RESTCONF? >=20 > The server must be told *when* to call home, right? I assume that the > configured subscriptions provides this; i.e., if a notif is generated for= a > configured subscription, and there is no active session, the server will = call > home. The client can listen for a while and then hang up (I assume). Wh= en a > new notif is generated the server will call home again. This does seem a= bit > complex, and I'm not sure it is needed. Yes, the basic flow above is what we have been aiming to do. For both conf= igured and dynamic subscriptions, there are deployment types which benefit = from reducing the number of active transport sessions. This is easier to d= o with some transport types than others. Call home helps secure devices by ensuring it is the network element which = initiates a transport connection. Call home is not needed for all types of= configured subscriptions transport types, just those on NETCONF. The reas= on NETCONF needs call home is that the NETCONF server must always be the Pu= blisher, and therefore you need to signal the NETCONF client when there are= updates to push should no transport currently exist. HTTP2 & GRPC based protocols will have configured subscriptions on the publ= isher have their updates pushed via an HTTP Client. So call home is not ne= cessary in that environment.=20 > But I don't think this solution is well documented in the current set of = drafts. We will get there :-) Eric =20 > /martin >=20 >=20 > > I prefer 1 mandatory-to-implement RPC instead of duplicated optional > > solutions. > > The new feature is really "server initiates notifications upon a > > reboot", not "configured notifications". > > > > > > > > > > > > > > > /martin > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > At a detailed level, I2RS's RFC-7923 has functional requirements > > > > for > > > yang subscriptions. This is what was requested by the WG to be made > > > available for event notifications. > > > > as well as various WG meeting minutes. > > > > > > > > And of course the existing WG minutes, the four draft document > > > appendices, and the Dezign team minutes at: > > > > https://github.com/netconf-wg/yang-push/wiki/Minutes > > > > Attempts to keep a running list of to-be-resolved dialogs. Of > > > > course > > > there is a lag between dialogs and embodiment in the drafts. > > > > > > > > If anyone wants to propose a revision to the requirements, I > > > > propose > > > they do this as deltas from the existing documentation. > > > > > > > > Or course we in the WG can and should discuss and tweak any > > > > specific > > > requirement on this mailer based on ongoing learnings over time. > > > > > > > > Eric > > > > > > > > > /martin > > > > > > > From nobody Fri Dec 16 09:30:38 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1670B1296E8; Fri, 16 Dec 2016 09:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exHIWYEc2GM2; Fri, 16 Dec 2016 09:30:35 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3081296CD; Fri, 16 Dec 2016 09:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2448; q=dns/txt; s=iport; t=1481909435; x=1483119035; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IOaMEiWvoGMLeP88C7qi8KUITG10zTDzgfSZjSMm5gc=; b=Ddf//CFObsZZwVi6q04NGzZuLkXgZOhq7m9/iraUQXc7ZOQ8OJF+xjeK 3/s7CBJj2kN4073ynzSuH1NWTNCpGMQ04w16v7rPSMmqCJvpOJZCcUevZ E83mfL0UpaW7JkQj1JHQJy7E54DxoB3rpWS6iDYLJPu3C30CEA8VQvqEx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQD4I1RY/4UNJK1CGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQEfWoEGB41HlleSfoIPggkqhXgCghg/FAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEDARIoNAsFCwIBCA4HAw0LBgYKMiUBAQQOBQgaiEEIDi6aAwGQH?= =?us-ascii?q?oNYh0cBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYY2hFmBPYFGgguFEwWacAGGUYp?= =?us-ascii?q?agX2FA4lWjhmEDgEfN4EiKYNUHBiBRXIBh2+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,358,1477958400"; d="scan'208";a="182328434" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Dec 2016 17:30:34 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uBGHUXJm021391 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Dec 2016 17:30:34 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 16 Dec 2016 12:30:33 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 16 Dec 2016 12:30:33 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund Thread-Topic: [Netconf] Minutes 14-Dec: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts Thread-Index: AdJXEcE9YXnjTzr8TlarA4PrbNqzqAAmlqUAAAOk31A= Date: Fri, 16 Dec 2016 17:30:33 +0000 Message-ID: <1faa6961013d426291bebc9272a715bf@XCH-RTP-013.cisco.com> References: <37cf381a875e45b8a9da6639195c3fc9@XCH-RTP-013.cisco.com> <20161216.105306.1840712711228239629.mbj@tail-f.com> In-Reply-To: <20161216.105306.1840712711228239629.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , "netconf-subscriptions-dt@voit.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] Minutes 14-Dec: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 17:30:37 -0000 > From: Martin Bjorklund, December 16, 2016 4:53 AM > Hi Eric, > > "Eric Voit (evoit)" wrote: >> Minutes posted at: >> https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-12-14 >>=20 >> As always, our DezignTM Team is a gathering of individuals providing inf= ormal=20 >> input to NETCONF. We ask NETCONF WG to comment on our discussion results= =20 >> as a preparation for the WG consensus. Please approach Eric Voit if you = want=20 >> to be included directly in these meetings. >>=20 >>=20 >> Meeting Materials >>=20 >> Attending >>=20 >> WebEx=20 >> Recording> 4389bda21c54a1db071d> >> password: JmnEiji8 >>=20 >> Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard,=20 >> Eric Voit, Tim Jenkins, Balazs Lengyel, Mahesh Jethanandani, Ambika=20 >> Tripathy >>=20 >> 5277bis Scope & Naming >=20 > It is great that you publish these minutes, but this topic is an ongoing > discussion in the WG on the ML. So could we please continue the discussi= on on > the list? That is the intent. All official work happens on the mailing list. These = phone conversations are just a way to more quickly get input, feedback, tho= ughts, new directions, etc. All NETCONF participants are welcome to join i= n. > Hmm, you wrote split between 5277bis and yang-push; maybe this is a new > issue? The current discussion is re. the split between 5277bis and event= - > notifications. Yes, this was the topic. We were revisiting discussions from the last year= on whether the requirements we have been working for yang-push are also ne= eded for an evolved event notifications capability. The thinking from the = call is yes. This also matches to Andy's requirement list from the Dec 9th= Use Case thread. Beyond this while it is perhaps possible to put band-aids around 5277, this= wouldn't be preferable. For example transport independence would not be a= chieved, also you would still have to build a parallel control plane for ya= ng-push with its own independent set of operations/diagnostics/troubleshoot= ing/etc. (As an FYI on each individuals' thinking, there are supplementary= details on the WebEx recording from 5:58-16:54.) =20 So at this point the authors believe it appropriate to continue down the co= mmon control plane approach.=20 Eric=20 >=20 > /martin From nobody Mon Dec 19 00:09:44 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC87129522; Mon, 19 Dec 2016 00:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s88LG0D4he87; Mon, 19 Dec 2016 00:09:37 -0800 (PST) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B3C126B6D; Mon, 19 Dec 2016 00:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References: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=dFC+NGluHVhOMVBPb5Ulco2YCZW+MwgiQMvgJtiRh8I=; b=mJLyJNc0vlANT9AN5meIYfVTvE fRk1ivANjfXQfADQZFDUKtebMcg+77LCTe/M+TMzUDj9N3PoFrgO6Z5bYyGTns69OAGvRR3doZA1D jjmrlcMMcsTY1RI29flf7BFcP6WUIO/hcPcvApBwmXpF2qEhPhXuVCyeQLWzS6RKZjHWHXK06Ge66 HRd8RpERa9WsIRmksUTBXNvw8SwT//lbTji+v3QKk/akL6kit4PNgbuzBRV2Lgp3INT+jtjFuh4jP fKz64HOuW3sBKGGMN70Kg2tpZuGLGugAeHFsWe6BfzfceMufg1eW4jlzmToNHlcBOeqlPPMzKAuHH Cv7h2zOw==; Received: from hansfords.plus.com ([84.92.116.209]:37265 helo=Vanguard) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cIt0p-002Nb7-63; Mon, 19 Dec 2016 08:09:35 +0000 From: "Jonathan Hansford" To: "'Ladislav Lhotka'" , "'Andy Bierman'" , "'Mehmet Ersue'" References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> In-Reply-To: Date: Mon, 19 Dec 2016 08:09:36 -0000 Message-ID: <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJvIdnLcbPhtZVe/ZwhlJOAl849fwFrVtQ3AezV2tIA+5xlnwL4zh2sAk77YEwCCFzmZgJIVCHNAgcLeowB7aW4ZgFJbBpLAgSx2bABY2d4S58gwHvQ Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Archived-At: Cc: 'NetMod WG Chairs' , 'NetConf WG Chairs' , 'NetMod WG' , 'Netconf' Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 08:09:39 -0000 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav > Lhotka > Sent: 14 December 2016 14:25 > To: Andy Bierman ; Mehmet Ersue > > Cc: NetMod WG Chairs ; NetConf WG Chairs > ; NetMod WG ; Netconf > > Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod- > revised-datastores-00 > : > As for candidate, it is optional and we all know that it is quite problematic if > concurrent access of multiple clients is possible. Therefore, it would IMO be a > good riddance. For someone who is yet to see NETCONF and YANG used in anger, can you explain why judicious use of candidate and lock is problematic with concurrent access and why, as a consequence, it should be got rid of? One of the features of NETCONF that attracted us to it is its support for transactioning, a feature which it would appear came from previous experience with JUNOS. Is it current guidance that transactioning should not be used? Jonathan > > Lada From nobody Mon Dec 19 02:38:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33261129604; Mon, 19 Dec 2016 02:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 f5GrbuPt3m7P; Mon, 19 Dec 2016 02:38:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F994129669; Mon, 19 Dec 2016 02:37:59 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be] (unknown [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be]) by mail.nic.cz (Postfix) with ESMTPSA id 0120A60ABD; Mon, 19 Dec 2016 11:37:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482143878; bh=urzxPjNQEFqpMbcIwqR441qts8iytfuTnei3g17JSMQ=; h=From:Date:To; b=IGZMfYePYBHZQ1Boy77dyhnvs4+nsGYhVaPpqWxzA5drZg6OIBApYeeWHIPMku0fM pf4SxlFvaBNif9mWAA3YMKXYOBZEy1Wa1Pdlq7iigMeCxIDdtUd8+Pkl3jYEnb2PKw 35orx6ZvLSjA1n0GmuMl+084FN7j7UuSy3nw0vDQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> Date: Mon, 19 Dec 2016 11:37:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <462EE5E8-2FBD-4946-93B5-81E048AB3BE2@nic.cz> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> To: Jonathan Hansford X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 10:38:18 -0000 > On 19 Dec 2016, at 09:09, Jonathan Hansford = wrote: >=20 >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav >> Lhotka >> Sent: 14 December 2016 14:25 >> To: Andy Bierman ; Mehmet Ersue >> >> Cc: NetMod WG Chairs ; NetConf WG Chairs >> ; NetMod WG ; Netconf >> >> Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod- >> revised-datastores-00 >>=20 > : >> As for candidate, it is optional and we all know that it is quite > problematic if >> concurrent access of multiple clients is possible. Therefore, it = would IMO > be a >> good riddance. >=20 > For someone who is yet to see NETCONF and YANG used in anger, can you > explain why judicious use of candidate and lock is problematic with > concurrent access and why, as a consequence, it should be got rid of? = One of I am not proposing to ban candidate or something but IMO it needn't be = part of the base NETCONF (or whatever protocol) spec. A typical problem of candidate combined with NACM is that user A edits = item X and B edits Y in candidate. If B doesn't have write access to X = and A to Y, then none of them is able to make a commit. Lada > the features of NETCONF that attracted us to it is its support for > transactioning, a feature which it would appear came from previous > experience with JUNOS. Is it current guidance that transactioning = should not > be used? >=20 > Jonathan >=20 >>=20 >> Lada >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 19 02:50:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C29E1296FC; Mon, 19 Dec 2016 02:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-Hbqs4pvmqO; Mon, 19 Dec 2016 02:50:50 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF52129887; Mon, 19 Dec 2016 02:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2481; q=dns/txt; s=iport; t=1482144521; x=1483354121; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=+GcnLQAOV8Z12lB15Xbozb79KNz40GIVWbNRNBJmvfw=; b=RYxJ7LtXFtmjKq+LPCqt654lcqWEI+xRqYVgZS0iAeCvFkEnXW9kOHW7 FpaeaY+niudQ44UO8UQedNVXkpoLmTVTc8ZNjAV+Zxrxx12AJtSSCAJz/ 1XQNk2YMZ6dqTlbBv3jHW8FqJT6KdQpVzF5JDwF/4qG8D8GRsHiP7o8Wm M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAgDOuVdY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywLAQEBAQF5gQaOQpVkh3aNGIIKHwuFLkoCglYSAQIBAQEBAQE?= =?us-ascii?q?BYiiEaAEBAQQBARAmNgsMBAsRAQMBAQEnByEGHwMGCAYBDAYCAQEXB4gvAxcOn?= =?us-ascii?q?kIBkB6HJw2DVwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhjaBfQiCVIJIh1kFiFu?= =?us-ascii?q?HaIl4NY1Cg3KBdIgqhi+HcIFyUoNlhA8mDSOBAhUOK4NdHBiBRT40iFwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,373,1477958400"; d="scan'208";a="690562521" 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; 19 Dec 2016 10:48:39 +0000 Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBJAmcZ2008163; Mon, 19 Dec 2016 10:48:39 GMT To: Jonathan Hansford , "'Ladislav Lhotka'" , "'Andy Bierman'" , "'Mehmet Ersue'" References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> From: Robert Wilton Message-ID: <1665b254-b9eb-3260-9b66-1e82662b36ac@cisco.com> Date: Mon, 19 Dec 2016 10:48:34 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 'NetMod WG Chairs' , 'NetConf WG Chairs' , 'NetMod WG' , 'Netconf' Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 10:50:51 -0000 Hi Jonathan, These are just my thoughts ... I'm not advocating getting rid of candidate/locking, but if I was designing a new network management solution, I would not plan on using candidate/locking. Candidate is great when you have got a human operator typing in some config on the CLI and want to stop anyone (or anything) else changing the config at the same time under their feet. But once you only have machines programming the config, then they should be able to easily construct a single message for each edit of the config (which can be applied/failed in its entirety). Candidate and locking don't seem to help here. Further, if you want to update multiple devices at the same time then you end up in the realm of distributed transactions which get very complicated and are hard to get right in a fully robust fashion. It is at this point, that I would try hard to build a network management architecture that doesn't rely on transactions or locking, and instead only relies on individual updates being consistently applied in a serialized fashion. Rob On 19/12/2016 08:09, Jonathan Hansford wrote: >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav >> Lhotka >> Sent: 14 December 2016 14:25 >> To: Andy Bierman ; Mehmet Ersue >> >> Cc: NetMod WG Chairs ; NetConf WG Chairs >> ; NetMod WG ; Netconf >> >> Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod- >> revised-datastores-00 >> > : >> As for candidate, it is optional and we all know that it is quite > problematic if >> concurrent access of multiple clients is possible. Therefore, it would IMO > be a >> good riddance. > For someone who is yet to see NETCONF and YANG used in anger, can you > explain why judicious use of candidate and lock is problematic with > concurrent access and why, as a consequence, it should be got rid of? One of > the features of NETCONF that attracted us to it is its support for > transactioning, a feature which it would appear came from previous > experience with JUNOS. Is it current guidance that transactioning should not > be used? > > Jonathan > >> Lada > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Dec 19 02:58:03 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24767129884 for ; Mon, 19 Dec 2016 02:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5pAV55klvFC for ; Mon, 19 Dec 2016 02:57:59 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1541296F4 for ; Mon, 19 Dec 2016 02:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2278; q=dns/txt; s=iport; t=1482145079; x=1483354679; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=M5KSzbGRQecJG/iNIrCjFb6Mp/PDq2AUCMz5hmOOkGU=; b=KApMf+slxq4w2V3FmVDwaQCDUL+ND+Xm+TuW5fB7FldauA40f/mc9H0s XDNpaNRa9beeVqaCQ8J5A6ywq9zyZXi+D5Jb57rX+KZsVlPPMdy8xJN26 4LnE2WaoKzSX7isxLSILepI4l1AjeqVIr84W/fwoVF9bRJBO2q48Tfs5Y 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AABVvFdY/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQF5gQaNT3Oqc4IKKoV4AoJUFAECAQEBAQEBAWIohGk?= =?us-ascii?q?CBBImQRALRlcHDAYCAQEeiEkOLp4dAZAeiwsBAQEBAQEBAQEBAQEBAQEBASGGN?= =?us-ascii?q?oF9glyBPYFGhx4FiGIRh1CKLZE0gXSFA4Mnhi+KNId0HzeBAhUOFoNyDQ+BXj0?= =?us-ascii?q?0AROISAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,373,1477958400"; d="scan'208";a="690562731" 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; 19 Dec 2016 10:57:57 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBJAvvYm008493; Mon, 19 Dec 2016 10:57:57 GMT To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com, joelja@bogus.com, mjethanandani@gmail.com, mehmet.ersue@nokia.com References: <20161108093217.CC0C7B808C2@rfc-editor.org> From: Benoit Claise Message-ID: <484cbbb6-e11d-9ad5-cfce-cfed667ceded@cisco.com> Date: Mon, 19 Dec 2016 11:57:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161108093217.CC0C7B808C2@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (4856) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 10:58:02 -0000 Dear all, Please let me know what you think of this errata. Regards, Benoit. > The following errata report has been submitted for RFC6241, > "Network Configuration Protocol (NETCONF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4856 > > -------------------------------------- > Type: Technical > Reported by: frank feng > > Section: 7.2 > > Original Text > ------------- > config: A hierarchy of configuration data as defined by one of > the device's data models. The contents MUST be placed in an > appropriate namespace, to allow the device to detect the > appropriate data model, and the contents MUST follow the > constraints of that data model, as defined by its capability > definition. Capabilities are discussed in Section 8. > > Corrected Text > -------------- > config: A hierarchy of configuration data as defined by one or more of > the device's data models. The contents MUST be placed in an > appropriate namespace, to allow the device to detect the > appropriate data model, and the contents MUST follow the > constraints of that data model, as defined by its capability > definition. Capabilities are discussed in Section 8. > > Notes > ----- > > > 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. > > -------------------------------------- > RFC6241 (draft-ietf-netconf-4741bis-10) > -------------------------------------- > Title : Network Configuration Protocol (NETCONF) > Publication Date : June 2011 > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > From nobody Mon Dec 19 03:31:17 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3760129712; Mon, 19 Dec 2016 03:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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_ZsF0ONAfF4; Mon, 19 Dec 2016 03:31:11 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95E12954D; Mon, 19 Dec 2016 03:31:11 -0800 (PST) Received: from [10.147.40.119] (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 88C3D1AE028C; Mon, 19 Dec 2016 12:31:08 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3270799B-4DF7-49D6-8547-35878A9D6488"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jan Lindblad In-Reply-To: <1665b254-b9eb-3260-9b66-1e82662b36ac@cisco.com> Date: Mon, 19 Dec 2016 12:31:07 +0100 Message-Id: <81B98FB8-DF86-4151-B3E6-322F0A5FAAAE@tail-f.com> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> <1665b254-b9eb-3260-9b66-1e82662b36ac@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3124) Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 11:31:14 -0000 --Apple-Mail=_3270799B-4DF7-49D6-8547-35878A9D6488 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > But once you only have machines programming the config, then they = should be able to easily construct a single message for each edit of the = config (which can be applied/failed in its entirety). Candidate and = locking don't seem to help here. >=20 > Further, if you want to update multiple devices at the same time then = you end up in the realm of distributed transactions which get very = complicated and are hard to get right in a fully robust fashion. Harder still without the candidate. Any case where transaction phases or = timing is involved would be harder to get right without the candidate = and confirmed commit. Being far from perfect, it's the best standardized = configuration protocol out there. /jan --Apple-Mail=_3270799B-4DF7-49D6-8547-35878A9D6488 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYV8T7AAoJEBSCnbqufIis6Q4H/1oMPJdVqJBtZnLVm0EZ9s6V huYfmCep5sRUJqPeET2qiBpKsUuN9P6SThI6h1+hdQlMaMX03bFEcNAs+ozlMMOR +65L345lhijhf6plRj1JsslWcF77XV2kbybmcMfidIj1ZaltZ7kLOS4QYGISVgGi Fv63G/TiQrw/EjhGh94ttlOWJ4mcLegLMnO4ioZvs5rZEKJydvSrhcTMwCNKhscq g2uH6/svwCcDsPUAlZpUNxxV3W2GJfjFwORpYmjenIZYJc03copN+e94U4GGgxVc rWSbUR+Zme2lD8UuG/BdhGAm3qHfLnNXmtYMlWDCRnrgicfL6zzT6GhXGaVnNP0= =NmGu -----END PGP SIGNATURE----- --Apple-Mail=_3270799B-4DF7-49D6-8547-35878A9D6488-- From nobody Mon Dec 19 04:43:31 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203DA1299D3 for ; Mon, 19 Dec 2016 04:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UNqKPRqIxNV for ; Mon, 19 Dec 2016 04:43:28 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF531299B3 for ; Mon, 19 Dec 2016 04:43:27 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EF7AC8A4; Mon, 19 Dec 2016 13:43:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zThUebQsvShK; Mon, 19 Dec 2016 13:43:24 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 Dec 2016 13:43:25 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7207A2007A; Mon, 19 Dec 2016 13:43:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6tIUIAOhcgVN; Mon, 19 Dec 2016 13:43:24 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16B0320079; Mon, 19 Dec 2016 13:43:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8D94A3DD5BC7; Mon, 19 Dec 2016 13:43:23 +0100 (CET) Date: Mon, 19 Dec 2016 13:43:23 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20161219124323.GA2012@elstar.local> Mail-Followup-To: Benoit Claise , rob.enns@gmail.com, mbj@tail-f.com, andy@yumaworks.com, joelja@bogus.com, mjethanandani@gmail.com, mehmet.ersue@nokia.com, frank.fengchong@huawei.com, netconf@ietf.org References: <20161108093217.CC0C7B808C2@rfc-editor.org> <484cbbb6-e11d-9ad5-cfce-cfed667ceded@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <484cbbb6-e11d-9ad5-cfce-cfed667ceded@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: rob.enns@gmail.com, mehmet.ersue@nokia.com, joelja@bogus.com, netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (4856) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 12:43:30 -0000 I think this is not needed. I am not sure what the wording change is trying to fix, I do not see how the new wording would be a significant improvement. If the 'by one of' is considered problematic, then I would just remove it. config: A hierarchy of configuration data as defined by the device's data models. The contents MUST be placed in an /js On Mon, Dec 19, 2016 at 11:57:57AM +0100, Benoit Claise wrote: > Dear all, > > Please let me know what you think of this errata. > > Regards, Benoit. > > The following errata report has been submitted for RFC6241, > > "Network Configuration Protocol (NETCONF)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4856 > > > > -------------------------------------- > > Type: Technical > > Reported by: frank feng > > > > Section: 7.2 > > > > Original Text > > ------------- > > config: A hierarchy of configuration data as defined by one of > > the device's data models. The contents MUST be placed in an > > appropriate namespace, to allow the device to detect the > > appropriate data model, and the contents MUST follow the > > constraints of that data model, as defined by its capability > > definition. Capabilities are discussed in Section 8. > > > > Corrected Text > > -------------- > > config: A hierarchy of configuration data as defined by one or more of > > the device's data models. The contents MUST be placed in an > > appropriate namespace, to allow the device to detect the > > appropriate data model, and the contents MUST follow the > > constraints of that data model, as defined by its capability > > definition. Capabilities are discussed in Section 8. > > > > Notes > > ----- > > > > > > 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. > > > > -------------------------------------- > > RFC6241 (draft-ietf-netconf-4741bis-10) > > -------------------------------------- > > Title : Network Configuration Protocol (NETCONF) > > Publication Date : June 2011 > > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. > > Category : PROPOSED STANDARD > > Source : Network Configuration > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > . > > > -- 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 Dec 19 04:49:05 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA349129A04; Mon, 19 Dec 2016 04:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSUkvY9f7T7G; Mon, 19 Dec 2016 04:48:55 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D94B1299F4; Mon, 19 Dec 2016 04:48:55 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6B6F77D5; Mon, 19 Dec 2016 13:48:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EJ4p9j1z2vsy; Mon, 19 Dec 2016 13:48:53 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 Dec 2016 13:48:54 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B5F12007A; Mon, 19 Dec 2016 13:48:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bqyrs2dg56pt; Mon, 19 Dec 2016 13:48:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DBF3B20079; Mon, 19 Dec 2016 13:48:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7F8D33DD5C91; Mon, 19 Dec 2016 13:48:53 +0100 (CET) Date: Mon, 19 Dec 2016 13:48:53 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161219124853.GB2012@elstar.local> Mail-Followup-To: Ladislav Lhotka , Jonathan Hansford , NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf References: <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> <462EE5E8-2FBD-4946-93B5-81E048AB3BE2@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <462EE5E8-2FBD-4946-93B5-81E048AB3BE2@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 12:48:57 -0000 On Mon, Dec 19, 2016 at 11:37:57AM +0100, Ladislav Lhotka wrote: > > I am not proposing to ban candidate or something but IMO it needn't be part of the base NETCONF (or whatever protocol) spec. > Lets recall that candidate is a _capability_. Nobody is required to implement it. > A typical problem of candidate combined with NACM is that user A edits item X and B edits Y in candidate. If B doesn't have write access to X and A to Y, then none of them is able to make a commit. > The problem is caused by allowing users with inconsistent access rights to both use candidate. So you get what you asked for. But I assume you can still do and recover. /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 Dec 19 04:56:26 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C241299D6; Mon, 19 Dec 2016 04:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 N4qKF6Io6mlg; Mon, 19 Dec 2016 04:56:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381F41299F2; Mon, 19 Dec 2016 04:56:19 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be] (unknown [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be]) by mail.nic.cz (Postfix) with ESMTPSA id 920DE6FF55; Mon, 19 Dec 2016 13:56:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482152177; bh=zniibWwvHrKScqhkfICCfXWiFBTXM07XczeXdktOCjg=; h=From:Date:To; b=EU9MYYE1NZpdumi3kWkQRzSijzTqdJa5A6Wts92tKTIrdWQUzJ1EktgoP8qK8NUiS xuNurvVwmfeXS+jxH7dJ+bfX/ZxBoNM03b1q3jJXgZ1hWVUHrNHteJQSVqi3JL/+nI xn6XL1z8sBW/ZcQuerHaUlIzoefWtURyLNFzo5Eg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <81B98FB8-DF86-4151-B3E6-322F0A5FAAAE@tail-f.com> Date: Mon, 19 Dec 2016 13:56:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> <1665b254-b9eb-3260-9b66-1e82662b36ac@cisco.com> <81B98FB8-DF86-4151-B3E6-322F0A5FAAAE@tail-f.com> To: Jan Lindblad X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 12:56:22 -0000 > On 19 Dec 2016, at 12:31, Jan Lindblad wrote: >=20 >> But once you only have machines programming the config, then they = should be able to easily construct a single message for each edit of the = config (which can be applied/failed in its entirety). Candidate and = locking don't seem to help here. >>=20 >> Further, if you want to update multiple devices at the same time then = you end up in the realm of distributed transactions which get very = complicated and are hard to get right in a fully robust fashion. >=20 > Harder still without the candidate. Any case where transaction phases = or timing is involved would be harder to get right without the candidate = and confirmed commit. Being far from perfect, it's the best standardized = configuration protocol out there. Per-user candidate datastores are much easier to deal with, and this is = what we do in our RESTCONF implementation: https://github.com/CZ-NIC/jetconf Lada >=20 > /jan >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 19 05:14:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEBB129A1E; Mon, 19 Dec 2016 05:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 YO5PT2Zj2iYO; Mon, 19 Dec 2016 05:14:51 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E06D129A20; Mon, 19 Dec 2016 05:14:50 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be] (unknown [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be]) by mail.nic.cz (Postfix) with ESMTPSA id 967DB75DBC; Mon, 19 Dec 2016 14:14:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482153289; bh=YJHx5RcAP2rGd/zqh2R6rtjUjcZE3HZysDl+EFwT+zw=; h=From:Date:To; b=RA/l3pDfIHRGhpRbZFDkHk0HeAgJ0snJooHQvuNpZ2DECN49xHz3N+0vaBcYg6Eex NPMtNwkDUWBEFnbYqx2dkmytPqL05wGkj4uRnRZL/HSC88MVw0DiUVA1A3Jg0c2QUP 2oWFeAUxBvrwzUzdDJw2EhV3NkWZ7kCM7bfUxj80= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20161219124853.GB2012@elstar.local> Date: Mon, 19 Dec 2016 14:14:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <357D486B-0EB0-45E6-9583-730AF0FBB260@nic.cz> References: <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> <462EE5E8-2FBD-4946-93B5-81E048AB3BE2@nic.cz> <20161219124853.GB2012@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 13:14:52 -0000 > On 19 Dec 2016, at 13:48, Juergen Schoenwaelder = wrote: >=20 > On Mon, Dec 19, 2016 at 11:37:57AM +0100, Ladislav Lhotka wrote: >>=20 >> I am not proposing to ban candidate or something but IMO it needn't = be part of the base NETCONF (or whatever protocol) spec. >>=20 >=20 > Lets recall that candidate is a _capability_. Nobody is required to > implement it. Yes, this is what I wrote. My point is that this capability could/should = be moved out of the NETCONF spec to a separate document. The latter can = then be modified without affecting the former.=20 >=20 >> A typical problem of candidate combined with NACM is that user A = edits item X and B edits Y in candidate. If B doesn't have write access = to X and A to Y, then none of them is able to make a commit. >>=20 >=20 > The problem is caused by allowing users with inconsistent access > rights to both use candidate. So you get what you asked for. But I Well, as soon as you let clients manage their private data (user = accounts, routing instances etc.) you get these "inconsistent" access = rights automatically. > assume you can still do and recover. ..., or find somebody with superuser privileges to perform the commit, = but it is clumsy either way. Automated solutions are likely to break. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Dec 19 05:28:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894DA129A59; Mon, 19 Dec 2016 05:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-ITQ8QOzM8g; Mon, 19 Dec 2016 05:28:47 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2136129A53; Mon, 19 Dec 2016 05:28:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AFE3B7F8; Mon, 19 Dec 2016 14:28:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 58WbtETeCw4A; Mon, 19 Dec 2016 14:28:44 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 Dec 2016 14:28:45 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CAAC2007A; Mon, 19 Dec 2016 14:28:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rG3Jg9I1IUW3; Mon, 19 Dec 2016 14:28:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D7B120079; Mon, 19 Dec 2016 14:28:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC0FC3DD5F01; Mon, 19 Dec 2016 14:28:44 +0100 (CET) Date: Mon, 19 Dec 2016 14:28:44 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161219132844.GA2177@elstar.local> Mail-Followup-To: Ladislav Lhotka , Jonathan Hansford , NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf References: <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> <462EE5E8-2FBD-4946-93B5-81E048AB3BE2@nic.cz> <20161219124853.GB2012@elstar.local> <357D486B-0EB0-45E6-9583-730AF0FBB260@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <357D486B-0EB0-45E6-9583-730AF0FBB260@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 13:28:49 -0000 On Mon, Dec 19, 2016 at 02:14:49PM +0100, Ladislav Lhotka wrote: > > > On 19 Dec 2016, at 13:48, Juergen Schoenwaelder wrote: > > > > On Mon, Dec 19, 2016 at 11:37:57AM +0100, Ladislav Lhotka wrote: > >> > >> I am not proposing to ban candidate or something but IMO it needn't be part of the base NETCONF (or whatever protocol) spec. > >> > > > > Lets recall that candidate is a _capability_. Nobody is required to > > implement it. > > Yes, this is what I wrote. My point is that this capability could/should be moved out of the NETCONF spec to a separate document. The latter can then be modified without affecting the former. > I believe it does not matter where a capability is defined. You can even declare the capability dead by writing a document declaring it dead; this does not require to revise the RFC the capability is defined in. Since the candidate datastore has been in NETCONF since day one and it is out there and apparently used, I do not see a strong reason to move the definition. Those who do not like it simply do not implement it. /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 Dec 19 05:34:01 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67DC129A62 for ; Mon, 19 Dec 2016 05:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 mtN2DGOQmvfy for ; Mon, 19 Dec 2016 05:33:55 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id E7CB9129A60 for ; Mon, 19 Dec 2016 05:33:54 -0800 (PST) Received: (qmail 16382 invoked by uid 0); 19 Dec 2016 13:33:53 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 19 Dec 2016 13:33:53 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id MpZq1u00g2SSUrH01pZt9E; Mon, 19 Dec 2016 06:33:53 -0700 X-Authority-Analysis: v=2.1 cv=DKocvU9b c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n5n_aSjo0skA:10 a=2pI7ILdtxjVHaGA5pc8A: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:Cc:References:To:Subject; bh=NrheFPL+6qLWm+r+TGAmbAkHIK4ifFbUYuIvz0xSuCM=; b=D22E3Bo0dgCCdvja0vjoowVV5E AqSIr2oxyFRH8AepyHU/c/bkzYT9RlJarHahyjX+R68xY7HBw+6mLvGTGAabn/sr4CB3mKBk3/2uI x0lgWS5MJmpC9IdkvcqhttNiG; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:58903 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cIy4c-0004dp-GA; Mon, 19 Dec 2016 06:33:50 -0700 To: NetMod WG , NetConf WG References: From: Lou Berger Message-ID: <23632d7c-51c2-732d-4928-1c23b3089077@labn.net> Date: Mon, 19 Dec 2016 08:33:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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.85.191 X-Exim-ID: 1cIy4c-0004dp-GA X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:58903 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs Subject: Re: [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 13:33:56 -0000 All, This poll is closed and this document is adopted in the NETMOD WG. There have been many good topics raised during the call adoption call that we will work through. Kent and I are already working on a draft of the updated charter. Authors, Please resubmit your draft with the new name draft-nmdsdt-netmod-revised-datastores-00 and with that and the date being the only change. Please consider how you want to track and resolve the topics/issues raised during the adoption call. WG trac and github issue tracker are available to you. Please also set a topic-specific Subject line in any list followup. -- Draft specific discussion can now be limited to just the netmod list. Thank you! Lou On 12/2/2016 4:26 PM, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group > document. This document is unusual in that WG last call will be jointly > held in both the NetConf and NetMod WGs, while adoption and day-to-day processing > will take place in NetMod. > > 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 December 16. > > Thank you, > NetConf and NetMod WG Chairs > > From nobody Mon Dec 19 06:25:30 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A86A129ADE; Mon, 19 Dec 2016 06:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 VVePhkMNmLDZ; Mon, 19 Dec 2016 06:25:26 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 A1AB4129AEB; Mon, 19 Dec 2016 06:25:25 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id g23so18970858wme.1; Mon, 19 Dec 2016 06:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language:disposition-notification-to; bh=yhhuobGye+0YSENxtbGJCq9MpZ7VNsewJcmQIvQTxFo=; b=QYGkTZPvZXCyykp3YuCAccicKmm72Zo4u+nhUENReN7FY+pYz6yeTRrvnEfohXrlkz dC9MW6FcbADi/pGpDeXbyZacO9Hn06H9BCMBYt1ZN7ZbaU0cOrfRoRaGlFMylc5B8/ka yTJdzWeFl6BpNmIR3LfBV8EyrC2GLu0xOmXKFPESqTn75DUFbti3EzgXnL8FlSjiHAK/ /wKNM82tal6M8SuM21g567c7BFuN9kk5AtQscJp8EXBEIQKfFmeL3NCk92qQMhsqPUXX AHFCBSGwz+NbUk0SSRni22bb+uxB3WOu/jX4LCYci/ILj19HQXjSeTyJet8Q8kYX14gC fNYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language:disposition-notification-to; bh=yhhuobGye+0YSENxtbGJCq9MpZ7VNsewJcmQIvQTxFo=; b=RHlLvVd5CCDxt6BC3hbvXkf9E1VZjPfiArkAFvL49zqvcATL3I3mws/iV03EMHdA5x LgYx3w+EA/l9vXiQg3GiMjXMKs0bf0TQdiw9odb1Azo1UUN3sj8GTto5Oorbie/jD+pm K3o5tOKBKjmmtycRsSsvEf/hYoOSu8TBi9VfTk1kaFsP/U8U4ZQLrx2JGW06RxJzYi2M dwgkMB3214757wnAVFeWlWQ5Xy4qpZ7YHVroTzQoasQSYHIeb1TCvrRLYpgr9tYMK05g aT/xMfr2LAuI7l1GPSKnU/wGqrVHFuaN9l2ty97nY3lwyjnWgiWVrfylGGfU/csLcbZR g8aQ== X-Gm-Message-State: AIkVDXL1cOQXiPGAswUw+Lnz+RJRPHqiYa79ty5HHDmW+tYr2wan33d1nDhDADAklewLwg== X-Received: by 10.28.164.196 with SMTP id n187mr13389447wme.44.1482157524099; Mon, 19 Dec 2016 06:25:24 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B3402E0.dip0.t-ipconnect.de. [91.52.2.224]) by smtp.gmail.com with ESMTPSA id d64sm17419475wmh.3.2016.12.19.06.25.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Dec 2016 06:25:23 -0800 (PST) From: "Mehmet Ersue" To: "'Lou Berger'" , "'NetMod WG'" , "'NetConf WG'" References: <23632d7c-51c2-732d-4928-1c23b3089077@labn.net> In-Reply-To: <23632d7c-51c2-732d-4928-1c23b3089077@labn.net> Date: Mon, 19 Dec 2016 15:25:22 +0100 Message-ID: <008e01d25a03$bc57d440$35077cc0$@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: AQJvIdnLcbPhtZVe/ZwhlJOAl849fwJKHC9Dn8Nxd/A= Content-Language: de X-AVK-Virus-Check: AVA 25.9617;3C2B908 X-AVK-Spam-Check: 1; str=0001.0A0C0201.5857EDD3.005B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: 'NetMod WG Chairs' , 'NetConf WG Chairs' Subject: Re: [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 14:25:28 -0000 Dear Lou, as I stated earlier and some people agreed, I believe this document = should be published as Informational RFC. The reason I gave is below: > I see the DT document as a datastore solution proposal. There are = different gaps and issues which still need to be addressed and the = solution proposal needs yet to be=20 > discussed and finalized. The document is providing information on the = history, explaining the need for a generic solution as well as is = discussing different scenarios.=20 > As such I believe the datastore solution proposal from the DT should = be published with the intended status Informational RFC. I would like to recommend to change the intended status of the draft = accordingly. Thanks, Mehmet -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Monday, December 19, 2016 2:34 PM To: NetMod WG ; NetConf WG Cc: NetMod WG Chairs ; NetConf WG Chairs = Subject: Re: WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 All, This poll is closed and this document is adopted in the NETMOD WG. There have been many good topics raised during the call adoption call = that we will work through. Kent and I are already working on a draft of = the updated charter. Authors, Please resubmit your draft with the new name draft-nmdsdt-netmod-revised-datastores-00 and with that and the date = being the only change. Please consider how you want to track and resolve the topics/issues = raised during the adoption call. WG trac and github issue tracker are = available to you. Please also set a topic-specific Subject line in any = list followup.=20 -- Draft specific discussion can now be limited to just the netmod list. Thank you! Lou On 12/2/2016 4:26 PM, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group=20 > document. This document is unusual in that WG last call will be=20 > jointly held in both the NetConf and NetMod WGs, while adoption and=20 > day-to-day processing will take place in NetMod. > > Please send email to the list indicating "yes/support" or "no/do not=20 > support". If indicating no, please state your reservations with the=20 > document. If yes, please also feel free to provide comments you'd=20 > like to see addressed once the document is a WG document. > > The poll ends December 16. > > Thank you, > NetConf and NetMod WG Chairs > > From nobody Mon Dec 19 07:03:43 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250D2129B07 for ; Mon, 19 Dec 2016 07:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 sx4aE5uZfZId for ; Mon, 19 Dec 2016 07:03:39 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 DA2AB129B3F for ; Mon, 19 Dec 2016 07:03:20 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D986613EA922F for ; Mon, 19 Dec 2016 15:03:15 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uBJF3HbV030592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Dec 2016 15:03:18 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uBJF39gG003522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 19 Dec 2016 15:03:16 GMT Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.191]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Mon, 19 Dec 2016 16:03:08 +0100 From: "Beauville, Yves (Nokia - BE)" To: "netconf@ietf.org" Thread-Topic: Subscription with Replay Thread-Index: AdJaCImWjYbGpT/+TTGf6QoaoXGE3A== Date: Mon, 19 Dec 2016 15:03:07 +0000 Message-ID: <3004A47FF33FC14B9680465CD90772CC47CD6215@FR711WXCHMBA08.zeu.alcatel-lucent.com> Accept-Language: fr-BE, en-US Content-Language: fr-BE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_3004A47FF33FC14B9680465CD90772CC47CD6215FR711WXCHMBA08z_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Subscription with Replay X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 15:03:41 -0000 --_000_3004A47FF33FC14B9680465CD90772CC47CD6215FR711WXCHMBA08z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I have a concern with RFC5277 that I do not see addressed in the scope of R= FC5277bis. I would appreciate feedback whether the following point is valid= or not. I have the following use case for notification replay * A NETCONF client caches a subset of the server data, E.G. a list of alarm= s * The NETCONF client uses notifications to keep its cache up-to-date with t= he server * The NETCONF client uses notification replay to re-synchronize its cache a= fter a client/server disconnection * In order to use notification replay, the client also caches the time-stam= p of the last notification received from the server (lastNotificationTime) The following re-synchronization scenario is used: Step 1. The client sends a on the stream for replayLogCreationTime = and replayLogAgedTime. The client uses lastNotificationTime, replayLogCreat= ionTime and replayLogAgedTime to assess whether replay is possible. If replay is not possible, the client gets part of the YANG data tree fro= m the server to re-synchronize its cache, E.G. a list of alarms, else, step= 2 is played. Step 2. The client sends on the stream with startTi= me=3DlastNotificationTime. The client processes re-played notifications to = re-synchronize its cache Open Point: between steps 1. & 2., new notifications may occur in the serve= r and they may cause the stream to no longer be capable of replaying notifi= cations since the last received notification. Creating the subscription will succeed as specified in the RFC: If the specified is earlier than the log can support, the replay will begi= n with the earliest available notification Because of the above, the client will not be aware that notifications were = lost. Does RFC5277 provides a solution to overcome this issue? If not, should it = provide means to let the client control the behavior of the create-subscrip= tion RPC when the server is not capable of replaying notifications since th= e startTime? By delegating to the server the responsibility to assess if th= e stream log is sufficient to allow replay, it could address my open point. Regards, Yves Beauville --_000_3004A47FF33FC14B9680465CD90772CC47CD6215FR711WXCHMBA08z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,

I have a concern with RFC5277 that I do not see addressed in the scope of R= FC5277bis. I would appreciate feedback whether the following point is valid= or not.

I have the following use case for notification replay
* A NETCONF client caches a subset of the server data, E.G. a list of alarm= s
* The NETCONF client uses notifications to keep its cache up-to-date with t= he server
* The NETCONF client uses notification replay to re-synchronize its cache a= fter a client/server disconnection
* In order to use notification replay, the client also caches the time-stam= p of the last notification received from the server (lastNotificationTime)<= br>
The following re-synchronization scenario is used:

  Step 1. The client sends a <get> on the stream for replayLogCr= eationTime and replayLogAgedTime. The client uses lastNotificationTime, rep= layLogCreationTime and replayLogAgedTime to assess whether replay is possib= le.

  If replay is not possible, the client gets part of the YANG data tree from the ser= ver to re-synchronize its cache, E.G. a list of alarms, else, step 2 is pla= yed.

  Step 2. The client sends <create-subscription> on the stream w= ith startTime=3DlastNotificationTime. The client processes re-played notifi= cations to re-synchronize its cache

Open Point: between steps 1. & 2., new notifications may occur in the s= erver and they may cause the stream to no longer be capable of replaying no= tifications since the last received notification.

Creating the subscription will succeed as specified in the RFC: If the <= startTime> specified is earlier than the log can support, the replay wil= l begin with the earliest available notification

Because of the above, the client will not be aware that notifications were = lost.

Does RFC5277 provides a solution to overcome this issue? If not, should it = provide means to let the client control the behavior of the create-subscrip= tion RPC when the server is not capable of replaying notifications since th= e startTime? By delegating to the server the responsibility to assess if the stream log is sufficient to all= ow replay, it could address my open point.

Regards,
Yves Beauville

--_000_3004A47FF33FC14B9680465CD90772CC47CD6215FR711WXCHMBA08z_-- From nobody Mon Dec 19 07:51:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27865129B7E for ; Mon, 19 Dec 2016 07:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2kWP3EWvvX7 for ; Mon, 19 Dec 2016 07:51:32 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDA71294C0 for ; Mon, 19 Dec 2016 07:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9967; q=dns/txt; s=iport; t=1482162692; x=1483372292; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FEC80Diqa0LrIsOxjd7J1/RxP8gxKYOJfirnsOrbKVk=; b=YnxtHO7d1hor9Hm2VefMAgGjctxiNXmNMSTHBlOSjHHCtprITDqyxSVL nM9PJgyWRrsfhdKUmin4D7X+rWEYICFmUpT0P9L4Ex8UiiipygghVhmLY VG48QoCg3E67P0QMFkiczwTMdAOTtlZTVmNr+wc7MQ8qC1PTkXb2hTiCm w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQAhAVhY/4kNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnNEAQEBAQEfWoENjUiWWY9phSWCCoYiAoICPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBBBIbTBACAQgVECEyJQEBBA4NEweISZlOAZAeiw0BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdhjaEWYQqhXcFmnABiWOHR5BWjhmEDgEfN4ElK4VWiG+BDQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.33,374,1477958400"; d="scan'208,217";a="183293420" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2016 15:51:31 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBJFpUkf011693 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Dec 2016 15:51:31 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Dec 2016 10:51:30 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Mon, 19 Dec 2016 10:51:30 -0500 From: "Eric Voit (evoit)" To: "Beauville, Yves (Nokia - BE)" Thread-Topic: Subscription with Replay Thread-Index: AdJaCImWjYbGpT/+TTGf6QoaoXGE3AABSkkQ Date: Mon, 19 Dec 2016 15:51:30 +0000 Message-ID: <05c52fa2cd6045e5b682edfb31bcf39b@XCH-RTP-013.cisco.com> References: <3004A47FF33FC14B9680465CD90772CC47CD6215@FR711WXCHMBA08.zeu.alcatel-lucent.com> In-Reply-To: <3004A47FF33FC14B9680465CD90772CC47CD6215@FR711WXCHMBA08.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_05c52fa2cd6045e5b682edfb31bcf39bXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Subscription with Replay X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 15:51:34 -0000 --_000_05c52fa2cd6045e5b682edfb31bcf39bXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yves, In 5277bis we have discussed using subscription negotiation for items like = this. For negotiation to work, we would send back a replay start time whi= ch would be acceptable to the publisher as part of the error response. A = publisher can determine the earliest possible start time as you describe be= low. If you (and others) are ok with this mechanism, we can add details within a= specific replay section of 5277bis. Eric From: Netconf, December 19, 2016 10:03 AM Hi All, I have a concern with RFC5277 that I do not see addressed in the scope of R= FC5277bis. I would appreciate feedback whether the following point is valid= or not. I have the following use case for notification replay * A NETCONF client caches a subset of the server data, E.G. a list of alarm= s * The NETCONF client uses notifications to keep its cache up-to-date with t= he server * The NETCONF client uses notification replay to re-synchronize its cache a= fter a client/server disconnection * In order to use notification replay, the client also caches the time-stam= p of the last notification received from the server (lastNotificationTime) The following re-synchronization scenario is used: Step 1. The client sends a on the stream for replayLogCreationTime = and replayLogAgedTime. The client uses lastNotificationTime, replayLogCreat= ionTime and replayLogAgedTime to assess whether replay is possible. If replay is not possible, the client gets part of the YANG data tree fro= m the server to re-synchronize its cache, E.G. a list of alarms, else, step= 2 is played. Step 2. The client sends on the stream with startTi= me=3DlastNotificationTime. The client processes re-played notifications to = re-synchronize its cache Open Point: between steps 1. & 2., new notifications may occur in the serve= r and they may cause the stream to no longer be capable of replaying notifi= cations since the last received notification. Creating the subscription will succeed as specified in the RFC: If the specified is earlier than the log can support, the replay will begi= n with the earliest available notification Because of the above, the client will not be aware that notifications were = lost. Does RFC5277 provides a solution to overcome this issue? If not, should it = provide means to let the client control the behavior of the create-subscrip= tion RPC when the server is not capable of replaying notifications since th= e startTime? By delegating to the server the responsibility to assess if th= e stream log is sufficient to allow replay, it could address my open point. Regards, Yves Beauville --_000_05c52fa2cd6045e5b682edfb31bcf39bXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yves,

 

In 5277bis we have discussed using su= bscription negotiation for items like this.   For negotiation to = work, we would send back a replay start time which would be acceptable to the publisher as part of the error response.   = A publisher can determine the earliest possible start time as you describe = below.

 

If you (and others) are ok with this = mechanism, we can add details within a specific replay section of 5277bis.<= o:p>


Eric

 

 

From: Netconf, December 19, 2016 10:= 03 AM

Hi All,

I have a concern with RFC5277 that I do not see addressed in the scope of R= FC5277bis. I would appreciate feedback whether the following point is valid= or not.

I have the following use case for notification replay
* A NETCONF client caches a subset of the server data, E.G. a list of alarm= s
* The NETCONF client uses notifications to keep its cache up-to-date with t= he server
* The NETCONF client uses notification replay to re-synchronize its cache a= fter a client/server disconnection
* In order to use notification replay, the client also caches the time-stam= p of the last notification received from the server (lastNotificationTime)<= br>
The following re-synchronization scenario is used:

  Step 1. The client sends a <get> on the stream for replayLogCr= eationTime and replayLogAgedTime. The client uses lastNotificationTime, rep= layLogCreationTime and replayLogAgedTime to assess whether replay is possib= le.

  If replay is not possible, the client gets part of the YANG data tre= e from the server to re-synchronize its cache, E.G. a list of alarms, else,= step 2 is played.

  Step 2. The client sends <create-subscription> on the stream w= ith startTime=3DlastNotificationTime. The client processes re-played notifi= cations to re-synchronize its cache

Open Point: between steps 1. & 2., new notifications may occur in the s= erver and they may cause the stream to no longer be capable of replaying no= tifications since the last received notification.

Creating the subscription will succeed as specified in the RFC: If the <= startTime> specified is earlier than the log can support, the replay wil= l begin with the earliest available notification

Because of the above, the client will not be aware that notifications were = lost.

Does RFC5277 provides a solution to overcome this issue? If not, should it = provide means to let the client control the behavior of the create-subscrip= tion RPC when the server is not capable of replaying notifications since th= e startTime? By delegating to the server the responsibility to assess if the stream log is sufficient to all= ow replay, it could address my open point.

Regards,
Yves Beauville

--_000_05c52fa2cd6045e5b682edfb31bcf39bXCHRTP013ciscocom_-- From nobody Mon Dec 19 08:14:57 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30776129BC3 for ; Mon, 19 Dec 2016 08:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaSjXrmARGS0 for ; Mon, 19 Dec 2016 08:14:53 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C407C129BB0 for ; Mon, 19 Dec 2016 08:14:46 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id q68so19964727qki.1 for ; Mon, 19 Dec 2016 08:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TLfHIt7KVdi+vIxT+jETcCK3RF/DEi159tyCH2vOnrA=; b=iJWnGEEvEo0N/s3PH13cW8VzC+fZm7G8THKn/vKXZ2k9tb9YnBA5q5xsrgwjvhTjDA Sq+fV1F5CwDvtnrLz7tCkNVv0zEbyShM8VtRKgwqf9L8HS+ktNHKBN7+xIz/vUgL2SCi Vcstg2uXA68+eezZycfA1VdRbUh/29TrfEeQCWI+67j3bjTJe2NKoBVsbpXjX8ehZ6SE 3qFuLJ0UiwdkPXFemLhC/6dyT1TNYuPOeY5d4PyEZ114+5Dol3wSMUJhmlZK8QSpq8yp h8bKFEzGOuxGTXltkdlB/UiHW8OmG+FeNJzs/rhu1fWGpcNgEdyOoPFZ6Md9lcR7Ib9+ lK4Q== 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=TLfHIt7KVdi+vIxT+jETcCK3RF/DEi159tyCH2vOnrA=; b=YX0StvCICdLJAszxa1mrv7JWI+61Ioz9xIa4EXDnovkFqwO97KnuDd+I2gwDPPVzXB jVyw11cHzrFuDP7NM0h9jaXWCMpWdvTFVzCUkJEDouDpgBeJQ7NT9sYSy4xcR2MRryKs T4xtb+wzwiQT8vkshExi3cUpoHZ4s3zSG0i1zu/wc1ttSJkqqvQwgwa1aNlZrzyh43zP 1nO4gj/13HSp6ldCsFVdX5ZohvuqUajo5JYed0BXZ5oRjw7G6lTtBT2SyGB5nwJGomA4 STK2T3UDu9s1REf7Qr7ZQ66qLBNO2lwxLto76Fv6x3z9OoNJbvHWkoQuyHAyVEtIp+mv TI/g== X-Gm-Message-State: AIkVDXJsd2XAr4fuUkN6dyeGDbTASF0lzwmnkgZJtfXxH5lIMMV38ozTdjLRpqOGNiHtvwcerJRTTaqiiYsuhw== X-Received: by 10.55.22.97 with SMTP id g94mr1342375qkh.287.1482164085891; Mon, 19 Dec 2016 08:14:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Mon, 19 Dec 2016 08:14:45 -0800 (PST) In-Reply-To: <484cbbb6-e11d-9ad5-cfce-cfed667ceded@cisco.com> References: <20161108093217.CC0C7B808C2@rfc-editor.org> <484cbbb6-e11d-9ad5-cfce-cfed667ceded@cisco.com> From: Andy Bierman Date: Mon, 19 Dec 2016 08:14:45 -0800 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=001a114967ead6cc10054405378c Archived-At: Cc: Rob Enns , "Ersue, Mehmet \(Nokia - DE/Munich\)" , Joel Jaeggli , Netconf Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (4856) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 16:14:55 -0000 --001a114967ead6cc10054405378c Content-Type: text/plain; charset=UTF-8 Hi, this should be rejected. The changed text implies that different configurations are present, each derived from some unspecified subset of modules. This is not correct. Andy On Mon, Dec 19, 2016 at 2:57 AM, Benoit Claise wrote: > Dear all, > > Please let me know what you think of this errata. > > Regards, Benoit. > >> The following errata report has been submitted for RFC6241, >> "Network Configuration Protocol (NETCONF)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4856 >> >> -------------------------------------- >> Type: Technical >> Reported by: frank feng >> >> Section: 7.2 >> >> Original Text >> ------------- >> config: A hierarchy of configuration data as defined by one of >> the device's data models. The contents MUST be placed in an >> appropriate namespace, to allow the device to detect the >> appropriate data model, and the contents MUST follow the >> constraints of that data model, as defined by its capability >> definition. Capabilities are discussed in Section 8. >> >> Corrected Text >> -------------- >> config: A hierarchy of configuration data as defined by one or more of >> the device's data models. The contents MUST be placed in an >> appropriate namespace, to allow the device to detect the >> appropriate data model, and the contents MUST follow the >> constraints of that data model, as defined by its capability >> definition. Capabilities are discussed in Section 8. >> >> Notes >> ----- >> >> >> 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. >> >> -------------------------------------- >> RFC6241 (draft-ietf-netconf-4741bis-10) >> -------------------------------------- >> Title : Network Configuration Protocol (NETCONF) >> Publication Date : June 2011 >> Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, >> Ed., A. Bierman, Ed. >> Category : PROPOSED STANDARD >> Source : Network Configuration >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> . >> >> > --001a114967ead6cc10054405378c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

this should be rejected.
= The changed text implies that different configurations are present,
each derived from some unspecified subset of modules.
This is = not correct.


Andy


On Mon, = Dec 19, 2016 at 2:57 AM, Benoit Claise <bclaise@cisco.com> w= rote:
Dear all,

Please let me know what you think of this errata.

Regards, Benoit.
The following errata report has been submitted for RFC6241,
"Network Configuration Protocol (NETCONF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/err= ata_search.php?rfc=3D6241&eid=3D4856

--------------------------------------
Type: Technical
Reported by: frank feng <frank.fengchong@huawei.com>

Section: 7.2

Original Text
-------------
config:=C2=A0 A hierarchy of configuration data as defined by one of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the device's data models.=C2=A0 The = contents MUST be placed in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate namespace, to allow the devi= ce to detect the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate data model, and the contents= MUST follow the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 constraints of that data model, as defin= ed by its capability
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definition.=C2=A0 Capabilities are discu= ssed in Section 8.

Corrected Text
--------------
config:=C2=A0 A hierarchy of configuration data as defined by one or more o= f
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the device's data models.=C2=A0 The = contents MUST be placed in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate namespace, to allow the devi= ce to detect the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate data model, and the contents= MUST follow the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 constraints of that data model, as defin= ed by its capability
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definition.=C2=A0 Capabilities are discu= ssed in Section 8.

Notes
-----


Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
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.

--------------------------------------
RFC6241 (draft-ietf-netconf-4741bis-10)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Network Confi= guration Protocol (NETCONF)
Publication Date=C2=A0 =C2=A0 : June 2011
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: R. Enns, Ed., M. Bjorkl= und, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Configurat= ion
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operations an= d Management
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
.



--001a114967ead6cc10054405378c-- From nobody Mon Dec 19 10:33:26 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 996431295B1; Mon, 19 Dec 2016 10:33:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148217240162.12870.15841709839958684237.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2016 10:33:21 -0800 Archived-At: Cc: mehmet.ersue@nokia.com, netconf-chairs@ietf.org, netconf@ietf.org Subject: [Netconf] netconf - New Meeting Session Request for IETF 98 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 18:33:21 -0000 A new meeting session request has just been submitted by Mehmet Ersue, a Chair of the netconf working group. --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mehmet Ersue Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: netmod opsarea opsawg l2sm lime supa Second Priority: nmrg i2rs i2nsf nfvrg Third Priority: anima sacm v6ops core 6tisch 6lo Special Requests: Please schedule the NETCONF session on Tue, Wed or Thu. Friday is NOT possible. (netmod opsarea opsawg l2sm lime supa are a conflict for the OPS AD Benoit Claise) Thanks. --------------------------------------------------------- From nobody Mon Dec 19 23:28:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1449129CFF for ; Mon, 19 Dec 2016 23:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 C2orY_-IW35f for ; Mon, 19 Dec 2016 23:28:22 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 9FA6D129CFB for ; Mon, 19 Dec 2016 23:28:09 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 2B74D7B44AB13; Tue, 20 Dec 2016 07:28:06 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uBK7S6dp026840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2016 07:28:07 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uBK7RwSe032383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Dec 2016 07:28:05 GMT Received: from [138.203.136.12] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 20 Dec 2016 08:28:03 +0100 To: "Eric Voit (evoit)" References: <3004A47FF33FC14B9680465CD90772CC47CD6215@FR711WXCHMBA08.zeu.alcatel-lucent.com> <05c52fa2cd6045e5b682edfb31bcf39b@XCH-RTP-013.cisco.com> From: Yves Beauville Message-ID: <55c8e5bb-1893-38c6-56c5-e109dd7d493a@nokia.com> Date: Tue, 20 Dec 2016 08:28:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <05c52fa2cd6045e5b682edfb31bcf39b@XCH-RTP-013.cisco.com> Content-Type: multipart/alternative; boundary="------------269D194785B57AD0B9D889FB" X-Originating-IP: [135.239.27.40] Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Subscription with Replay X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 07:28:23 -0000 --------------269D194785B57AD0B9D889FB Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hi Eric, I am definitely interested in a mechanism for subscription negotiation. Note that in my use case, I do not want to trigger a replay if the server cannot perform it from the specified startTime. I expect that subscription negotiation could cover this case. Yves On 12/19/2016 4:51 PM, Eric Voit (evoit) wrote: > > Hi Yves, > > In 5277bis we have discussed using subscription negotiation for items > like this. For negotiation to work, we would send back a replay > start time which would be acceptable to the publisher as part of the > error response. A publisher can determine the earliest possible > start time as you describe below. > > If you (and others) are ok with this mechanism, we can add details > within a specific replay section of 5277bis. > > > Eric > > *From:*Netconf, December 19, 2016 10:03 AM > > Hi All, > > I have a concern with RFC5277 that I do not see addressed in the scope > of RFC5277bis. I would appreciate feedback whether the following point > is valid or not. > > I have the following use case for notification replay > * A NETCONF client caches a subset of the server data, E.G. a list of > alarms > * The NETCONF client uses notifications to keep its cache up-to-date > with the server > * The NETCONF client uses notification replay to re-synchronize its > cache after a client/server disconnection > * In order to use notification replay, the client also caches the > time-stamp of the last notification received from the server > (lastNotificationTime) > > The following re-synchronization scenario is used: > > Step 1. The client sends a on the stream for > replayLogCreationTime and replayLogAgedTime. The client uses > lastNotificationTime, replayLogCreationTime and replayLogAgedTime to > assess whether replay is possible. > > If replay is not possible, the client gets part of the YANG data > tree from the server to re-synchronize its cache, E.G. a list of > alarms, else, step 2 is played. > > Step 2. The client sends on the stream with > startTime=lastNotificationTime. The client processes re-played > notifications to re-synchronize its cache > > Open Point: between steps 1. & 2., new notifications may occur in the > server and they may cause the stream to no longer be capable of > replaying notifications since the last received notification. > > Creating the subscription will succeed as specified in the RFC: If the > specified is earlier than the log can support, the replay > will begin with the earliest available notification > > Because of the above, the client will not be aware that notifications > were lost. > > Does RFC5277 provides a solution to overcome this issue? If not, > should it provide means to let the client control the behavior of the > create-subscription RPC when the server is not capable of replaying > notifications since the startTime? By delegating to the server the > responsibility to assess if the stream log is sufficient to allow > replay, it could address my open point. > > Regards, > Yves Beauville > --------------269D194785B57AD0B9D889FB Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi Eric,
 
I am definitely interested in a mechanism for subscription negotiation.

Note that in my use case, I do not want to trigger a replay if the server cannot perform it from the specified startTime. I expect that subscription negotiation could cover this case.

Yves

On 12/19/2016 4:51 PM, Eric Voit (evoit) wrote:

Hi Yves,

 

In 5277bis we have discussed using subscription negotiation for items like this.   For negotiation to work, we would send back a replay start time which would be acceptable to the publisher as part of the error response.   A publisher can determine the earliest possible start time as you describe below.

 

If you (and others) are ok with this mechanism, we can add details within a specific replay section of 5277bis.


Eric

 

 

From: Netconf, December 19, 2016 10:03 AM

Hi All,

I have a concern with RFC5277 that I do not see addressed in the scope of RFC5277bis. I would appreciate feedback whether the following point is valid or not.

I have the following use case for notification replay
* A NETCONF client caches a subset of the server data, E.G. a list of alarms
* The NETCONF client uses notifications to keep its cache up-to-date with the server
* The NETCONF client uses notification replay to re-synchronize its cache after a client/server disconnection
* In order to use notification replay, the client also caches the time-stamp of the last notification received from the server (lastNotificationTime)

The following re-synchronization scenario is used:

  Step 1. The client sends a <get> on the stream for replayLogCreationTime and replayLogAgedTime. The client uses lastNotificationTime, replayLogCreationTime and replayLogAgedTime to assess whether replay is possible.

  If replay is not possible, the client gets part of the YANG data tree from the server to re-synchronize its cache, E.G. a list of alarms, else, step 2 is played.

  Step 2. The client sends <create-subscription> on the stream with startTime=lastNotificationTime. The client processes re-played notifications to re-synchronize its cache

Open Point: between steps 1. & 2., new notifications may occur in the server and they may cause the stream to no longer be capable of replaying notifications since the last received notification.

Creating the subscription will succeed as specified in the RFC: If the <startTime> specified is earlier than the log can support, the replay will begin with the earliest available notification

Because of the above, the client will not be aware that notifications were lost.

Does RFC5277 provides a solution to overcome this issue? If not, should it provide means to let the client control the behavior of the create-subscription RPC when the server is not capable of replaying notifications since the startTime? By delegating to the server the responsibility to assess if the stream log is sufficient to allow replay, it could address my open point.

Regards,
Yves Beauville


--------------269D194785B57AD0B9D889FB-- From nobody Tue Dec 20 03:37:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A401293E1 for ; Tue, 20 Dec 2016 03:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrJ1RYsh27vD for ; Tue, 20 Dec 2016 03:37:57 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DFD128B44 for ; Tue, 20 Dec 2016 03:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9126; q=dns/txt; s=iport; t=1482233876; x=1483443476; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=GJ0ZvLIolSLylmU2u6wrJT1ZwJzelnBcR/CH2olaT40=; b=ADtp5pgE+i2Su/wg4o8DxewOqqSWgUJo5GQEAZuN82N7tn7fZdTSqiqN qwinhsdhWzekMNS31QOllTl538qGLdkzcb/mkqdBeL/zRDs9oIgizUHuD TIcmQV7ugC3d24JKCRPAFZ1YDjfWOV9VMwIncqho8dV2O1BGW+FVa7hkl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAQBBF1lY/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQF5LliNUHOVZ49phSWCCiqFeAKCOhQBAgEBAQEBAQF?= =?us-ascii?q?iKIRpAQEEEhFWEAkCGCcDAgJGEQYNBgIBAR6ISQ4ujCmPVQGNdoIoL4pnAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYY2gX2CXIE9gUaEQYJdBYhiEYdQhECFbZE0gXS?= =?us-ascii?q?FA4Mnhi+KNINlhA8fNzFSFQ4Wgzw7DQ+BXj00AROIXgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,378,1477958400"; d="scan'208,217";a="650873735" 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 Dec 2016 11:37:54 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uBKBbrah017679; Tue, 20 Dec 2016 11:37:53 GMT To: Andy Bierman References: <20161108093217.CC0C7B808C2@rfc-editor.org> <484cbbb6-e11d-9ad5-cfce-cfed667ceded@cisco.com> From: Benoit Claise Message-ID: Date: Tue, 20 Dec 2016 12:37:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E5E4F20862868A7E9619050B" Archived-At: Cc: Rob Enns , "Ersue, Mehmet \(Nokia - DE/Munich\)" , Joel Jaeggli , Netconf Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (4856) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 11:37:59 -0000 This is a multi-part message in MIME format. --------------E5E4F20862868A7E9619050B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit OK, thanks Andy and Jürgen. Regards, B. > Hi, > > this should be rejected. > The changed text implies that different configurations are present, > each derived from some unspecified subset of modules. > This is not correct. > > > Andy > > > On Mon, Dec 19, 2016 at 2:57 AM, Benoit Claise > wrote: > > Dear all, > > Please let me know what you think of this errata. > > Regards, Benoit. > > The following errata report has been submitted for RFC6241, > "Network Configuration Protocol (NETCONF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4856 > > > -------------------------------------- > Type: Technical > Reported by: frank feng > > > Section: 7.2 > > Original Text > ------------- > config: A hierarchy of configuration data as defined by one of > the device's data models. The contents MUST be > placed in an > appropriate namespace, to allow the device to detect the > appropriate data model, and the contents MUST follow the > constraints of that data model, as defined by its > capability > definition. Capabilities are discussed in Section 8. > > Corrected Text > -------------- > config: A hierarchy of configuration data as defined by one > or more of > the device's data models. The contents MUST be > placed in an > appropriate namespace, to allow the device to detect the > appropriate data model, and the contents MUST follow the > constraints of that data model, as defined by its > capability > definition. Capabilities are discussed in Section 8. > > Notes > ----- > > > 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. > > -------------------------------------- > RFC6241 (draft-ietf-netconf-4741bis-10) > -------------------------------------- > Title : Network Configuration Protocol (NETCONF) > Publication Date : June 2011 > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. > Schoenwaelder, Ed., A. Bierman, Ed. > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > > > --------------E5E4F20862868A7E9619050B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
OK, thanks Andy and Jürgen.

Regards, B.
Hi,

this should be rejected.
The changed text implies that different configurations are present,
each derived from some unspecified subset of modules.
This is not correct.


Andy


On Mon, Dec 19, 2016 at 2:57 AM, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

Please let me know what you think of this errata.

Regards, Benoit.
The following errata report has been submitted for RFC6241,
"Network Configuration Protocol (NETCONF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4856

--------------------------------------
Type: Technical
Reported by: frank feng <frank.fengchong@huawei.com>

Section: 7.2

Original Text
-------------
config:  A hierarchy of configuration data as defined by one of
          the device's data models.  The contents MUST be placed in an
          appropriate namespace, to allow the device to detect the
          appropriate data model, and the contents MUST follow the
          constraints of that data model, as defined by its capability
          definition.  Capabilities are discussed in Section 8.

Corrected Text
--------------
config:  A hierarchy of configuration data as defined by one or more of
          the device's data models.  The contents MUST be placed in an
          appropriate namespace, to allow the device to detect the
          appropriate data model, and the contents MUST follow the
          constraints of that data model, as defined by its capability
          definition.  Capabilities are discussed in Section 8.

Notes
-----


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.

--------------------------------------
RFC6241 (draft-ietf-netconf-4741bis-10)
--------------------------------------
Title               : Network Configuration Protocol (NETCONF)
Publication Date    : June 2011
Author(s)           : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.
Category            : PROPOSED STANDARD
Source              : Network Configuration
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
.




--------------E5E4F20862868A7E9619050B-- From nobody Tue Dec 20 03:40:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6FB12956A; Tue, 20 Dec 2016 03:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.302 X-Spam-Level: X-Spam-Status: No, score=-7.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmjB7EozaKFs; Tue, 20 Dec 2016 03:40:15 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44DB129567; Tue, 20 Dec 2016 03:40:15 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C50C4B808E0; Tue, 20 Dec 2016 03:40:15 -0800 (PST) To: frank.fengchong@huawei.com, rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161220114015.C50C4B808E0@rfc-editor.org> Date: Tue, 20 Dec 2016 03:40:15 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Rejected] RFC6241 (4856) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 11:40:17 -0000 The following errata report has been rejected for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4856 -------------------------------------- Status: Rejected Type: Technical Reported by: frank feng Date Reported: 2016-11-08 Rejected by: Benoit Claise (IESG) Section: 7.2 Original Text ------------- config: A hierarchy of configuration data as defined by one of the device's data models. The contents MUST be placed in an appropriate namespace, to allow the device to detect the appropriate data model, and the contents MUST follow the constraints of that data model, as defined by its capability definition. Capabilities are discussed in Section 8. Corrected Text -------------- config: A hierarchy of configuration data as defined by one or more of the device's data models. The contents MUST be placed in an appropriate namespace, to allow the device to detect the appropriate data model, and the contents MUST follow the constraints of that data model, as defined by its capability definition. Capabilities are discussed in Section 8. Notes ----- --VERIFIER NOTES-- As discussed on the NETCONF mailing list. -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Dec 20 04:28:16 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDCA129672 for ; Tue, 20 Dec 2016 04:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQn_AkwP1lMg for ; Tue, 20 Dec 2016 04:28:14 -0800 (PST) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::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 32807129668 for ; Tue, 20 Dec 2016 04:28:14 -0800 (PST) Received: by mail-qt0-x244.google.com with SMTP id l20so22614048qta.1 for ; Tue, 20 Dec 2016 04:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O3PDWPmjhPm2bVIdjTHKjkhBiYI1oDWrzE/lcSilt9Y=; b=R4FJYKJ7HL6uY3oHroBE/ekH48Du/kraDPAjg6wjIdIQjCbQhmhc6oY2e57lbQspuW FHh9cqb/PXMN8YgYnA0KZ5bj1i0X2E1vf+P0gPEG+h9WYaRHQkIdIVg800LvcbIfX2/g YC94hOWN/w70SoIt4L28O2LofZ5zuhKvVfrD8uL/wy4od2uaMP7CHvq77ClF9ip2fRs4 wI93v2jZeloMM78thD/T2TNIv3msYZG2xEuFd3jQrFrPJhGDBg/KltmylSUCFNZbwKbh bb5cw8vQoftD5Q5P10ScbH2QC9izZGWP/xlSJSoQqvFAzp4jTb/DAusLY2oDB+wnba2o rFWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O3PDWPmjhPm2bVIdjTHKjkhBiYI1oDWrzE/lcSilt9Y=; b=Y9XTQpPX5fd/2CpipMsHRBdR6t8QeSvrZduVcS5Y7TmL3NlWPO557M8Cs2TpGGjzsV LTXKynFPJvPszUdWdzOERfzxq4/CEPG8f1tG7ydugo+jl8YVQYWHhHvGWHcG0G/ekweX if3PDCxkrNRbrp4xUEl68zrBstA+p85xIKNNww9OefUpX/4THGfrRJCC1D7d0I8vhJ3U cJLiR0yWOUEOR1ztaDS6qD5Rk2/VE2w6d76fLjflYv2mFQ5wIw4C1GtRAjAgXWfn9U5e /gQT4YeppbAcXhYlSvt3Lfo9R1LlsCkwnWKZwlH5rXWu9pY07AHyGKyAUsvGR3go6uQ4 nulg== X-Gm-Message-State: AIkVDXKG/FOoH7xaOLDI2GIP6mEVW+rslRIY/XSNXKBIR83pXrmxZf/83PrSTeExGDNSqWaWhH6H/lzMCsHOvA== X-Received: by 10.200.41.248 with SMTP id 53mr21847969qtt.3.1482236893189; Tue, 20 Dec 2016 04:28:13 -0800 (PST) MIME-Version: 1.0 References: <20161108093217.CC0C7B808C2@rfc-editor.org> <484cbbb6-e11d-9ad5-cfce-cfed667ceded@cisco.com> In-Reply-To: From: MehmetErsue Date: Tue, 20 Dec 2016 12:28:02 +0000 Message-ID: To: Benoit Claise , Andy Bierman Content-Type: multipart/alternative; boundary=001a114107847df34d0544162ba5 Archived-At: Cc: Joel Jaeggli , "Ersue, Mehmet \(Nokia - DE/Munich\)" , Rob Enns , Netconf Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (4856) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 12:28:16 -0000 --001a114107847df34d0544162ba5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I kind of agree with Andy and Juergen. Mehmet Benoit Claise schrieb am Di., 20. Dez. 2016, 12:38: > OK, thanks Andy and J=C3=BCrgen. > > Regards, B. > > Hi, > > this should be rejected. > The changed text implies that different configurations are present, > each derived from some unspecified subset of modules. > This is not correct. > > > Andy > > > On Mon, Dec 19, 2016 at 2:57 AM, Benoit Claise wrote: > > Dear all, > > Please let me know what you think of this errata. > > Regards, Benoit. > > The following errata report has been submitted for RFC6241, > "Network Configuration Protocol (NETCONF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6241&eid=3D4856 > > -------------------------------------- > Type: Technical > Reported by: frank feng > > Section: 7.2 > > Original Text > ------------- > config: A hierarchy of configuration data as defined by one of > the device's data models. The contents MUST be placed in an > appropriate namespace, to allow the device to detect the > appropriate data model, and the contents MUST follow the > constraints of that data model, as defined by its capability > definition. Capabilities are discussed in Section 8. > > Corrected Text > -------------- > config: A hierarchy of configuration data as defined by one or more of > the device's data models. The contents MUST be placed in an > appropriate namespace, to allow the device to detect the > appropriate data model, and the contents MUST follow the > constraints of that data model, as defined by its capability > definition. Capabilities are discussed in Section 8. > > Notes > ----- > > > 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. > > -------------------------------------- > RFC6241 (draft-ietf-netconf-4741bis-10) > -------------------------------------- > Title : Network Configuration Protocol (NETCONF) > Publication Date : June 2011 > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, > Ed., A. Bierman, Ed. > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --=20 Cheers, Mehmet --001a114107847df34d0544162ba5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I kind of agree with Andy and Juergen.=C2=A0

Mehmet=C2= =A0

Benoit Claise= <bclaise@cisco.com> schrieb= am Di., 20. Dez. 2016, 12:38:
=20 =20 =20
OK, than= ks Andy and J=C3=BCrgen.

Regards, B.
=20
Hi,

this should be rejected.
The changed text implies that different co= nfigurations are present,
each derived from some unspecified subset = of modules.
This is not correct.


Andy


On Mon, Dec 19, 2016 at 2:57 A= M, Benoit Claise <bclaise@cisco.co= m> wrote:
Dear all,

Please let me know what you think of this errata.

Regards, Benoit.
The following errata report has been submitted for RFC6241,
"Network Configuration Protocol (NETCONF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D6241&eid=3D4856

--------------------------------------
Type: Technical
Reported by: frank feng <frank.fengchong@huawei.c= om>

Section: 7.2

Original Text
-------------
config:=C2=A0 A hierarchy of configuration data as defined by one of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the device's data mode= ls.=C2=A0 The contents MUST be placed in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate namespace, to = allow the device to detect the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate data model, an= d the contents MUST follow the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 constraints of that data m= odel, as defined by its capability
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definition.=C2=A0 Capabili= ties are discussed in Section 8.

Corrected Text
--------------
config:=C2=A0 A hierarchy of configuration data as defined by one or more of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the device's data mode= ls.=C2=A0 The contents MUST be placed in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate namespace, to = allow the device to detect the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate data model, an= d the contents MUST follow the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 constraints of that data m= odel, as defined by its capability
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definition.=C2=A0 Capabili= ties are discussed in Section 8.

Notes
-----


Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be ver= ified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6241 (draft-ietf-netconf-4741bis-10)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Network Configuration Protocol (NETCONF)
Publication Date=C2=A0 =C2=A0 : June 2011
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: R. Enns, = Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED = STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Netw= ork Configuration
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := Operations and Management
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF=
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
.




_______________________________________________
Netconf mailing list
N= etconf@ietf.org
https://www.ietf.org/mailman/listin= fo/netconf
--
Cheers,
Mehmet
--001a114107847df34d0544162ba5-- From nobody Tue Dec 20 07:32:44 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B4C1299F3; Tue, 20 Dec 2016 07:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cahciOWzckD7; Tue, 20 Dec 2016 07:32:38 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5181296DC; Tue, 20 Dec 2016 07:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20379; q=dns/txt; s=iport; t=1482247958; x=1483457558; h=from:to:subject:date:message-id:mime-version; bh=TbAGkKz44vY7QIdMFG5e8mBFLDDwCiapSb0ms0FM0CA=; b=YKKPMSsBEji75GFgcEf+D0AnvPdFCL19jTyWfQ5j241OO5gKt8A9KQnt gu5oycAceMTgS3pkSJCJs1w2FlCiTmsfYQgUxl3nE18DLtItT2OmLmw5n dcWgtAsRP+AadWw90gPgyOHfJ2F5xkmoRBuiIVv7Zq61BCB88b3CrxsYR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQBITllY/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnNEAQEBAQEfWoENjUmraIIKiAc/FAECAQEBAQEBAWIohG8SG0o?= =?us-ascii?q?UAS0TQCYBBAEaEweISZtEAZAeixsBAQEBAQUBAQEBAQEihjaOegWacAGRKoF9j?= =?us-ascii?q?lmHcIo3AR83gSYshVqIV4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,379,1477958400"; d="scan'208,217";a="362662709" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Dec 2016 15:32:37 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uBKFWaV2024893 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Dec 2016 15:32:37 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Dec 2016 10:32:36 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Tue, 20 Dec 2016 10:32:36 -0500 From: "Eric Voit (evoit)" To: "netconf@ietf.org" , "netconf-chairs@ietf.org" Thread-Topic: 3 Options for Subscription & Event Notification draft structure Thread-Index: AdJa002bNCznOyZwQL2tYKqXggHZBA== Date: Tue, 20 Dec 2016 15:32:36 +0000 Message-ID: <970f48bdc9cd4e68b7792e91c1a04e5f@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_970f48bdc9cd4e68b7792e91c1a04e5fXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 15:32:41 -0000 --_000_970f48bdc9cd4e68b7792e91c1a04e5fXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To summarize previous threads, key benefits of 5277bis over RFC 5277 includ= e: (1) transport independence (2) configured subscriptions (3) many subscriptions per transport session (4) modify and delete subscription RPCs (5) control plane notifications (6) data plane notification including subscription-id (7) negotiation (see Yves' thread from yesterday) (8) control plane reuse with draft-ietf-netconf-yang-push. Those of us working 5277bis had been planning on supporting existing 5277 i= mplementations via a separate backwards compatibility section. But as we h= ave gone forward, we see no meaningful technical overlaps. I.e., there are= no RPC or notifications shared between the 5277 and 5277bis solutions. An= y compatibility mode section would be fully standalone. Considering that p= eople can just refer to 5277 if they need it, and considering 5277 & 5277bi= s could easily run in parallel on different transport sessions, building a = standalone backwards compatibility section seems both confusing and redunda= nt. This leaves three options: (i.) OBSOLETE 5277 by replacing it with 5277bis (ii.) Support 5277bis without Obsoleting 5277 (iii.) Write a new UPDATE draft for 5277 NETCONF only transport The benefits and issues of each are as follows: (i.) OBSOLETE 5277 by replacing it with 5277bis * Supports all requirements (1) through (8). * IETF does not continue protocol maintenance of 5277. o Implementations can still choose 5277 or 5277bis, even though IETF reco= mmends 5277bis. o Implementations provide backwards compatibility through concurrent, par= allel support of both specifications. o Although obsoleted, the IETF does not deprecate 5277 so that current im= plementations may stay with existing 5277. * Need to change the NETCONF WG charter to show that 5277 is being re= placed rather than enhanced. (ii.) Support 5277bis without Obsoleting 5277 * Technically identical to (i). * Implementations free to choose 5277 or 5277bis, with no guidance on= which the WG recommends. o This could be confusing to customers as NETCONF WG will be advocating c= ompeting technologies for the place of overlap. -- i.e., NETCONF over XML = with a single subscription. * Establishes competing technology futures where one direction would = suffice. (iii.) Write a new UPDATE draft for 5277 NETCONF only transport * Supports a subset of requirements: o Cannot support (1) or (8) o Supporting (2), (3), (4), (5), (6), & (7) possible, but would require t= he creation of replicated/competing mechanisms with (8). * Doubles the development effort if the yang-push control plane is al= so required. * WG would need to build guidelines on when to use 5277bis or this ne= w UPDATE draft (assuming the WG wanted to proceed with the transport indepe= ndent 5277bis.) * No identified author / champion for this path. (Because business d= rivers being driven by other than NETCONF/XML.) * Update draft itself wouldn't require a NETCONF charter update. Based on this list, the people working in on the Subscription & Event Notif= ication weekly calls have a preference for (i.) followed by (ii.). Do you = have a preference or additional questions not addressed here or in the earl= ier threads? Thanks, Eric --_000_970f48bdc9cd4e68b7792e91c1a04e5fXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

  (1) transport independence

  (2) configured subscriptions

  (3) many subscriptions per transport sessi= on

  (4) modify and delete subscription RPCs

  (5) control plane notifications=

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

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

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

 

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

 

This leaves three options:

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

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

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

 

The benefits and issues of each are as follows:

 

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

·       Supports all requirements (1) through (8).

·       IETF does not continue protocol maintenance = of 5277.

o   Implementations can still choose 5277 or 527= 7bis, even though IETF recommends 5277bis.

o   Implementations provide backwards compatibil= ity through concurrent, parallel support of both specifications.=

o   Although obsoleted, the IETF does not deprec= ate 5277 so that current implementations may stay with existing 5277.<= /o:p>

·       Need to change the NETCONF WG charter to sho= w that 5277 is being replaced rather than enhanced.

 

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

·       Technically identical to (i).

·       Implementations free to choose 5277 or 5277b= is, with no guidance on which the WG recommends. 

o   This could be confusing to customers as NETC= ONF WG will be advocating competing technologies for the place of overlap. =  -- i.e., NETCONF over XML with a single subscription.

·       Establishes competing technology futures whe= re one direction would suffice.

 

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

·       Supports a subset of requirements:

o   Cannot support (1) or (8)

o   Supporting (2), (3), (4), (5), (6), & (7= ) possible, but would require the creation of replicated/competing mechanis= ms with (8). 

·       Doubles the development effort if the yang-p= ush control plane is also required.

·       WG would need to build guidelines on when to= use 5277bis or this new UPDATE draft (assuming the WG wanted to proceed wi= th the transport independent 5277bis.)

·       No identified author / champion for this pat= h.  (Because business drivers being driven by other than NETCONF/XML.)=

·       Update draft itself wouldn’t require a= NETCONF charter update.

 

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

 

Thanks,

Eric

 

--_000_970f48bdc9cd4e68b7792e91c1a04e5fXCHRTP013ciscocom_-- From nobody Wed Dec 21 02:06:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A74C1294E9; Wed, 21 Dec 2016 02:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 H1DGNBfqJVSB; Wed, 21 Dec 2016 02:06:55 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3300212941E; Wed, 21 Dec 2016 02:06:55 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 01A4E1AE030A; Wed, 21 Dec 2016 11:06:53 +0100 (CET) Date: Wed, 21 Dec 2016 11:06:52 +0100 (CET) Message-Id: <20161221.110652.2082676844450734019.mbj@tail-f.com> To: evoit@cisco.com From: Martin Bjorklund In-Reply-To: <970f48bdc9cd4e68b7792e91c1a04e5f@XCH-RTP-013.cisco.com> References: <970f48bdc9cd4e68b7792e91c1a04e5f@XCH-RTP-013.cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netconf-chairs@ietf.org Subject: Re: [Netconf] 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 10:06:58 -0000 "Eric Voit (evoit)" wrote: > To summarize previous threads, key benefits of 5277bis over RFC 5277 > include: > > (1) transport independence > > (2) configured subscriptions > > (3) many subscriptions per transport session > > (4) modify and delete subscription RPCs > > (5) control plane notifications > > (6) data plane notification including subscription-id > > (7) negotiation (see Yves' thread from yesterday) > > (8) control plane reuse with draft-ietf-netconf-yang-push. I will have to assume that when you say "5277bis" you mean draft-ietf-netconf-rfc5277bis-00. If this is true, I don't think that your statement above is correct. Maybe this is your *plan*, but it is difficult to comment on... Also note that RFC 5277 defines how notifications are sent over NETCONF. This is by nature protocol-specific, and it must be done. So the fact that draft-ietf-netconf-rfc5277bis-00 does (1) is a bug, not a feature, if you want to obsolete RFC 5277. > Those of us working 5277bis had been planning on supporting existing > 5277 implementations via a separate backwards compatibility section. > But as we have gone forward, we see no meaningful technical overlaps. > I.e., there are no RPC or notifications shared between the 5277 and > 5277bis solutions. Any compatibility mode section would be fully > standalone. Considering that people can just refer to 5277 if they > need it, and considering 5277 & 5277bis could easily run in parallel > on different transport sessions, building a standalone backwards > compatibility section seems both confusing and redundant. > > > > This leaves three options: > > (i.) OBSOLETE 5277 by replacing it with 5277bis > > (ii.) Support 5277bis without Obsoleting 5277 > > (iii.) Write a new UPDATE draft for 5277 NETCONF only transport > > > > The benefits and issues of each are as follows: > > > > (i.) OBSOLETE 5277 by replacing it with 5277bis > > * Supports all requirements (1) through (8). Maybe, but note that (1) through (8) is not a *complete* list of requirements. (And not all items are real requirements, e.g., (6)). For example, the requirement that we must have a definition for how notifications are sent over NETCONF is not addressed by draft-ietf-netconf-rfc5277bis-00. > * IETF does not continue protocol maintenance of 5277. > > o Implementations can still choose 5277 or 5277bis, even though IETF > recommends 5277bis. > > o Implementations provide backwards compatibility through concurrent, > parallel support of both specifications. > > o Although obsoleted, the IETF does not deprecate 5277 so that current > implementations may stay with existing 5277. I don't get this. If the spec is obsolete then it is obsolete. > * Need to change the NETCONF WG charter to show that 5277 is being > * replaced rather than enhanced. > > > > (ii.) Support 5277bis without Obsoleting 5277 > > * Technically identical to (i). > > * Implementations free to choose 5277 or 5277bis, with no guidance on > * which the WG recommends. > > o This could be confusing to customers as NETCONF WG will be > advocating competing technologies for the place of overlap. -- i.e., > NETCONF over XML with a single subscription. > > * Establishes competing technology futures where one direction would > * suffice. > > > > (iii.) Write a new UPDATE draft for 5277 NETCONF only transport I'm not sure what you have in mind? What exactly would this new draft contain? > * Supports a subset of requirements: > > o Cannot support (1) or (8) > > o Supporting (2), (3), (4), (5), (6), & (7) possible, but would > require the creation of replicated/competing mechanisms with (8). > > * Doubles the development effort if the yang-push control plane is also > * required. > > * WG would need to build guidelines on when to use 5277bis or this new > * UPDATE draft (assuming the WG wanted to proceed with the transport > * independent 5277bis.) > > * No identified author / champion for this path. (Because business > * drivers being driven by other than NETCONF/XML.) > > * Update draft itself wouldn't require a NETCONF charter update. > > > Based on this list, the people working in on the Subscription & Event > Notification weekly calls have a preference for (i.) followed by > (ii.). Do you have a preference or additional questions not addressed > here or in the earlier threads? I think the reasoning goes something like this: We need to support multiple subscriptions in a single NETCONF session. This implies that we need a 'subscription-id' field in the payload. The current payload does not contain a 'subscription-id', and it is inflexible in the sense that it does not allow us to add header fields. Thus, we need a new notification payload, which means that we cannot simply update RFC 5277 and be backwards compatible. If this is correct, I think it is fine to obsolete RFC 5277, but not with the current draft-ietf-netconf-rfc5277bis-00. Instead, I propose: A. one document that defines, in a protocol-neutral manner, the notification architecture, i.e., explains the concepts of streams, replay, filters, and subscriptions etc. B. one document that defines, in a protocol-neutral manner, how YANG notifications are encoded in XML and JSON. This covers NETCONF and RESTCONF (future protocols might reuse this, or they might need something else). C1. one document that defines how notifications are sent over NETCONF. Specifially, it needs to generalize section 3.7 of RFC 5277, since it changes the message flow defined in RFC 6241. (In the best of worlds, this would be a section in the NETCONF protocol spec). C2. one document that defines how notifications are sent over RESTCONF (this is currently section 6 in draft-ietf-netconf-restconf-18, and it needs to be updated) D. one document that defines the YANG data model for stream detection, subscription mgmt etc. This is mostly the current draft-ietf-netconf-rfc5277bis-00. Note that RFC 5277 contains A+B+C1+D. Maybe some of these could be collapsed into one document, e.g. A+B, or maybe A+B+D. /martin From nobody Wed Dec 21 09:13:11 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6183D1296CB; Wed, 21 Dec 2016 09:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXWZJd9dO7ZI; Wed, 21 Dec 2016 09:13:07 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3984129670; Wed, 21 Dec 2016 09:13:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9176; q=dns/txt; s=iport; t=1482340386; x=1483549986; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Z/LOtS9auho19S2edXYGbSgWUC2/CbuAwlEG8mAb9nA=; b=O/G6AiJCsv7W63xKCThghtCGb0lQn/wCuwhGq/qhlSygrECRAMutiROt jcqrJ4cI1KvwcN0ojpHSB3nI3TK0jx/j0TLU/BLysnjgq3nsCPJ0k9XdW 394ru4mqHp51vqZ3yhHFhtkQKuNM/X2LphS+7MM7sZkOWUmXZE+lRUdSO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBUt1pY/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAR9cgQgHjUqWUJUTggoshXYCgV4/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDATo9AgULAgEIDgQDAw0REDIXDgEBBA4FCBOISQgOqmmLBgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFhjaEWYohBZUHhXABhlGKXoF+jlyHeYYrhA4BHze?= =?us-ascii?q?BKi6FXnKHS4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,384,1477958400"; d="scan'208";a="363745863" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2016 17:13:05 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uBLHD51e020085 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Dec 2016 17:13:05 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Dec 2016 12:13:05 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 21 Dec 2016 12:13:04 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund Thread-Topic: [Netconf] 3 Options for Subscription & Event Notification draft structure Thread-Index: AdJa002bNCznOyZwQL2tYKqXggHZBAAyI6cAAARYNuA= Date: Wed, 21 Dec 2016 17:13:04 +0000 Message-ID: <3e4b821491f24fff9b1d0a8edcdf33ba@XCH-RTP-013.cisco.com> References: <970f48bdc9cd4e68b7792e91c1a04e5f@XCH-RTP-013.cisco.com> <20161221.110652.2082676844450734019.mbj@tail-f.com> In-Reply-To: <20161221.110652.2082676844450734019.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 17:13:09 -0000 Hi Martin, Thanks for the thoughts... =20 > From: Martin Bjorklund, December 21, 2016 5:07 AM > "Eric Voit (evoit)" wrote: > > To summarize previous threads, key benefits of 5277bis over RFC 5277 > > include: > > > > (1) transport independence > > > > (2) configured subscriptions > > > > (3) many subscriptions per transport session > > > > (4) modify and delete subscription RPCs > > > > (5) control plane notifications > > > > (6) data plane notification including subscription-id > > > > (7) negotiation (see Yves' thread from yesterday) > > > > (8) control plane reuse with draft-ietf-netconf-yang-push. >=20 > I will have to assume that when you say "5277bis" you mean draft-ietf-net= conf- > rfc5277bis-00. If this is true, I don't think that your statement above = is correct. > Maybe this is your *plan*, but it is difficult to comment on... current WG draft is -01. =20 A working version of -02 is at https://github.com/netconf-wg/rfc5277bis/blob/master/rfc5277bis-02-v20Dec20= 16.txt=20 But it hasn't been posted yet. =20 > Also note that RFC 5277 defines how notifications are sent over NETCONF. = This > is by nature protocol-specific, and it must be done. > So the fact that draft-ietf-netconf-rfc5277bis-00 does (1) is a bug, not = a > feature, if you want to obsolete RFC 5277. the obsoleting of 5277 is intended to come from a combination of=20 draft-ietf-netconf-rfc5277bis & draft-ietf-netconf-netconf-event-notificati= ons I agree work is needed to get the full coverage across them. > > Those of us working 5277bis had been planning on supporting existing > > 5277 implementations via a separate backwards compatibility section. > > But as we have gone forward, we see no meaningful technical overlaps. > > I.e., there are no RPC or notifications shared between the 5277 and > > 5277bis solutions. Any compatibility mode section would be fully > > standalone. Considering that people can just refer to 5277 if they > > need it, and considering 5277 & 5277bis could easily run in parallel > > on different transport sessions, building a standalone backwards > > compatibility section seems both confusing and redundant. > > > > > > > > This leaves three options: > > > > (i.) OBSOLETE 5277 by replacing it with 5277bis > > > > (ii.) Support 5277bis without Obsoleting 5277 > > > > (iii.) Write a new UPDATE draft for 5277 NETCONF only transport > > > > > > > > The benefits and issues of each are as follows: > > > > > > > > (i.) OBSOLETE 5277 by replacing it with 5277bis > > > > * Supports all requirements (1) through (8). >=20 > Maybe, but note that (1) through (8) is not a *complete* list of requirem= ents. Yes. (1)-(8) is a summary. > (And not all items are real requirements, e.g., (6)). Below you note that we need a 'subscription-id' field in the payload'. Tha= t is what is intended in (6)=20 > For example, the requirement that we must have a definition for how > notifications are sent over NETCONF is not addressed by draft-ietf-netcon= f- > rfc5277bis-00. Payload headers are coming in the next 5277bis version. Per the last minut= es, Andy is thinking about using some TailF stuff as a starting point. Th= e transport encapsulation for NETCONF will be in draft-ietf-netconf-netconf= -event-notifications. Alberto is awaiting the new notification payload bef= ore writing that up. =20 > > * IETF does not continue protocol maintenance of 5277. > > > > o Implementations can still choose 5277 or 5277bis, even though IETF > > recommends 5277bis. > > > > o Implementations provide backwards compatibility through concurrent, > > parallel support of both specifications. > > > > o Although obsoleted, the IETF does not deprecate 5277 so that current > > implementations may stay with existing 5277. >=20 > I don't get this. If the spec is obsolete then it is obsolete. Old protocols live in deployments after a doc is obsoleted. My assumption = is that deprecated means we actively provide reasons why people shouldn't u= se an old spec tp make people convert faster. Does Obsolete require Deprec= ate? I don't know. I am happy to go with whatever the IETF process uses = here. > > * Need to change the NETCONF WG charter to show that 5277 is bein= g > > * replaced rather than enhanced. > > > > > > > > (ii.) Support 5277bis without Obsoleting 5277 > > > > * Technically identical to (i). > > > > * Implementations free to choose 5277 or 5277bis, with no guidanc= e on > > * which the WG recommends. > > > > o This could be confusing to customers as NETCONF WG will be > > advocating competing technologies for the place of overlap. -- i.e., > > NETCONF over XML with a single subscription. > > > > * Establishes competing technology futures where one direction wo= uld > > * suffice. > > > > > > > > (iii.) Write a new UPDATE draft for 5277 NETCONF only transport >=20 > I'm not sure what you have in mind? What exactly would this new draft > contain? I don't find this path interesting, nor do I plan any authorship on this op= tion. So I am not thinking about it much. I am not sure if anyone wants (= iii.). > > * Supports a subset of requirements: > > > > o Cannot support (1) or (8) > > > > o Supporting (2), (3), (4), (5), (6), & (7) possible, but would > > require the creation of replicated/competing mechanisms with (8). > > > > * Doubles the development effort if the yang-push control plane i= s also > > * required. > > > > * WG would need to build guidelines on when to use 5277bis or thi= s new > > * UPDATE draft (assuming the WG wanted to proceed with the transp= ort > > * independent 5277bis.) > > > > * No identified author / champion for this path. (Because busine= ss > > * drivers being driven by other than NETCONF/XML.) > > > > * Update draft itself wouldn't require a NETCONF charter update. > > > > > > Based on this list, the people working in on the Subscription & Event > > Notification weekly calls have a preference for (i.) followed by > > (ii.). Do you have a preference or additional questions not addressed > > here or in the earlier threads? >=20 > I think the reasoning goes something like this: >=20 > We need to support multiple subscriptions in a single NETCONF > session. This implies that we need a 'subscription-id' field in the > payload. The current payload does not contain a 'subscription-id', > and it is inflexible in the sense that it does not allow us to add > header fields. >=20 > Thus, we need a new notification payload, which means that we cannot > simply update RFC 5277 and be backwards compatible. >=20 > If this is correct, It is. > I think it is fine to obsolete RFC 5277, but not with the current > draft-ietf-netconf-rfc5277bis-00. Instead, I > propose: >=20 > A. one document that defines, in a protocol-neutral manner, the > notification architecture, i.e., explains the concepts of > streams, replay, filters, and subscriptions etc. This is in 5277bis.=20 > B. one document that defines, in a protocol-neutral manner, how YANG > notifications are encoded in XML and JSON. This covers NETCONF > and RESTCONF (future protocols might reuse this, or they might > need something else). Currently encoding examples are in draft-ietf-netconf-netconf-event-notific= ations and draft-ietf-netconf-restconf-notif. Incomplete notification defi= nitions are in 5277bis (as noted above). But if the WG wishes, we could re= arrange things and have a protocol independent encoding document for notifi= cations. =20 I believe we should revisit the proper placement of this now as part of our= discussion on the structure of the notifications. =20 =20 > C1. one document that defines how notifications are sent over > NETCONF. Specifially, it needs to generalize section 3.7 of RFC > 5277, since it changes the message flow defined in RFC 6241. > (In the best of worlds, this would be a section in the NETCONF > protocol spec). draft-ietf-netconf-netconf-event-notifications =20 > C2. one document that defines how notifications are sent over > RESTCONF (this is currently section 6 in > draft-ietf-netconf-restconf-18, and it needs to be updated) draft-ietf-netconf-restconf-notif, although we recommend HTTP2 for the noti= fications, and RESTCONF for the dynamic subscription establishment. > D. one document that defines the YANG data model for stream > detection, subscription mgmt etc. This is mostly the current > draft-ietf-netconf-rfc5277bis-00. Yes =20 > Note that RFC 5277 contains A+B+C1+D. >=20 > Maybe some of these could be collapsed into one document, e.g. A+B, or > maybe A+B+D. The current document breakdown covers the intents above. But we could move= B to an independent draft if the WG prefers. Eric >=20 > /martin From nobody Wed Dec 21 12:34:45 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080451295FC; Wed, 21 Dec 2016 12:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy9sb1Atylc7; Wed, 21 Dec 2016 12:34:42 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5F11296B0; Wed, 21 Dec 2016 12:34:42 -0800 (PST) Received: from LAPTOPR7T053C2 ([47.143.86.36]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LoH8R-1cmYks0GUL-00gD4o; Wed, 21 Dec 2016 21:34:03 +0100 From: To: "'Eric Voit \(evoit\)'" , "'Martin Bjorklund'" References: <970f48bdc9cd4e68b7792e91c1a04e5f@XCH-RTP-013.cisco.com> <20161221.110652.2082676844450734019.mbj@tail-f.com> <3e4b821491f24fff9b1d0a8edcdf33ba@XCH-RTP-013.cisco.com> In-Reply-To: <3e4b821491f24fff9b1d0a8edcdf33ba@XCH-RTP-013.cisco.com> Date: Wed, 21 Dec 2016 12:33:56 -0800 Message-ID: <000e01d25bc9$91d42800$b57c7800$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJO++ql8Z3FoyVmW5r4wUaYpD19aQKNE2X2AbvXWsaf91CFEA== Content-Language: en-us X-Provags-ID: V03:K0:bt9XuCTnsbWhocCQrYzcvYaFMiHUCWlUHIHuBRG6qRZljLEpidW QbNMzJcobGSB476dDEvlxsgfzbo5NugeE6+5uihUwMI9IcZcno0FWqqFzpTCrV2LL+y+Ko7 MltX35KreB721DTZkOMEAhaTWMbJTJqBVk2pjJrbLInji9A1dwB4fyy3Z/VcKzQC45frBmO nuZPLDTiJtKNPypEDIN6w== X-UI-Out-Filterresults: notjunk:1;V01:K0:smkN6RcNeaI=:r7kzvra8RtM4BwakfOL1f5 qTpqf1wQBMiEePt1HlntUfw6hwqRkZZZtWxNbC6debrWNFg8/ag7yyaHVaJjAFs/odEvCWBe2 0f9wW5NipxGH8wopIUrHDj50F4Gi1tYZjifvMNY5QP/WoG8y2TXoUoBT8UHhGeBDmQgU8MPqC P2/jt/b69SbgaferqIa8+LNQHbbeU4rOYLIutBv0mVY5t/e7QCQjxGasd2eYBUztbu1hskH8Y q1sZ2VxFjwnwxdCzvO+Hmd/5s0e6WzhKZhSEq6+0kITRVlE7J5fl7g621LgMTKa/btEWh9qWc 1tF2rmzQlvQsvo2xZDTF2rJs0o+5THTf75GQJQOuTelicDaWMasVRvzNgyD3wBvjZrTex3JAE C6ugzjidVD6VoCVRH8+LK3hgsCKpEGDbUcQJPJLsf/XbFPojUC/HfdnzomGUNcxTN3pTJzaXd 9wNYnEeArNtB97Wh4i/yPFAKerzTkYJw5IbBNsFWinT6Ya+soDwOjf/s81zeclNtIzfk7oPnC uN0T7UD9JkKbyMrKhraf+aKx1/C4ShEDOXSY/dbYCG/9mbJ+UMawh5V1SsHkWXUOvFBuNl3AN mCivKLLu6Leo/A77HuDpTunEJnFoT8rmd1FQJPTHQAvW9e1mZTBKRFQdrAZC2jHL4Lr9aZklR 4vbtxAdXtsd4Zf0bkCfS4ZrQJvXslxi/v25FaLEa1HeU2LvcI9f/XiB+JOCEfcliGjxKY4WVb 3Eh7PIdWPrAGntGV Archived-At: Cc: netconf@ietf.org, netconf-chairs@ietf.org Subject: Re: [Netconf] 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 20:34:45 -0000 (resending, not sure my earlier message got through) Couple of additional thoughts: Re: relationship with 5277 to 5277bis version and obsoleting RFC 5277: - Yes, clearly 5277 defines how notifications are sent over Netconf. This aspect is actually covered in draft-ietf-netconf-netconf-event-notifications. The scope of RFC 5277 has been split, in order to distinguish the transport independent and transport dependent aspects. So, it is the combination of draft-ietf-netconf-netconf-event-notifications and RFC 5277bis which covers the original scope of bis. - Clearly, implementations can choose to continue to support 5277. I don't see how marking 5277 as obsolete would change that. De-facto I would think that the new sets of draft provide richer capabilities that implementations will want to support so I think de-facto 5277 is being deprecated, how this should best be reflected in status I don't know but seems somewhat secondary to me. Re: breaking out the aspect of encoding of notifications from the current into a separate draft, it's possible although I don't think necessary. It leads to further proliferation of number of drafts; I think it can just as well stay in 5277bis (whatever will be its name). That said, I can think of instances where it will make sense to refer to such encoding, such as when it comes to persisting event notifications in logs. --- Alex -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, December 21, 2016 9:13 AM To: Martin Bjorklund Cc: netconf@ietf.org; netconf-chairs@ietf.org Subject: Re: [Netconf] 3 Options for Subscription & Event Notification draft structure Hi Martin, Thanks for the thoughts... > From: Martin Bjorklund, December 21, 2016 5:07 AM "Eric Voit (evoit)" > wrote: > > To summarize previous threads, key benefits of 5277bis over RFC 5277 > > include: > > > > (1) transport independence > > > > (2) configured subscriptions > > > > (3) many subscriptions per transport session > > > > (4) modify and delete subscription RPCs > > > > (5) control plane notifications > > > > (6) data plane notification including subscription-id > > > > (7) negotiation (see Yves' thread from yesterday) > > > > (8) control plane reuse with draft-ietf-netconf-yang-push. > > I will have to assume that when you say "5277bis" you mean > draft-ietf-netconf- rfc5277bis-00. If this is true, I don't think that your statement above is correct. > Maybe this is your *plan*, but it is difficult to comment on... current WG draft is -01. A working version of -02 is at https://github.com/netconf-wg/rfc5277bis/blob/master/rfc5277bis-02-v20Dec201 6.txt But it hasn't been posted yet. > Also note that RFC 5277 defines how notifications are sent over > NETCONF. This is by nature protocol-specific, and it must be done. > So the fact that draft-ietf-netconf-rfc5277bis-00 does (1) is a bug, > not a feature, if you want to obsolete RFC 5277. the obsoleting of 5277 is intended to come from a combination of draft-ietf-netconf-rfc5277bis & draft-ietf-netconf-netconf-event-notifications I agree work is needed to get the full coverage across them. > > Those of us working 5277bis had been planning on supporting existing > > 5277 implementations via a separate backwards compatibility section. > > But as we have gone forward, we see no meaningful technical overlaps. > > I.e., there are no RPC or notifications shared between the 5277 and > > 5277bis solutions. Any compatibility mode section would be fully > > standalone. Considering that people can just refer to 5277 if they > > need it, and considering 5277 & 5277bis could easily run in parallel > > on different transport sessions, building a standalone backwards > > compatibility section seems both confusing and redundant. > > > > > > > > This leaves three options: > > > > (i.) OBSOLETE 5277 by replacing it with 5277bis > > > > (ii.) Support 5277bis without Obsoleting 5277 > > > > (iii.) Write a new UPDATE draft for 5277 NETCONF only transport > > > > > > > > The benefits and issues of each are as follows: > > > > > > > > (i.) OBSOLETE 5277 by replacing it with 5277bis > > > > * Supports all requirements (1) through (8). > > Maybe, but note that (1) through (8) is not a *complete* list of requirements. Yes. (1)-(8) is a summary. > (And not all items are real requirements, e.g., (6)). Below you note that we need a 'subscription-id' field in the payload'. That is what is intended in (6) > For example, the requirement that we must have a definition for how > notifications are sent over NETCONF is not addressed by > draft-ietf-netconf- rfc5277bis-00. Payload headers are coming in the next 5277bis version. Per the last minutes, Andy is thinking about using some TailF stuff as a starting point. The transport encapsulation for NETCONF will be in draft-ietf-netconf-netconf-event-notifications. Alberto is awaiting the new notification payload before writing that up. > > * IETF does not continue protocol maintenance of 5277. > > > > o Implementations can still choose 5277 or 5277bis, even though IETF > > recommends 5277bis. > > > > o Implementations provide backwards compatibility through > > concurrent, parallel support of both specifications. > > > > o Although obsoleted, the IETF does not deprecate 5277 so that > > current implementations may stay with existing 5277. > > I don't get this. If the spec is obsolete then it is obsolete. Old protocols live in deployments after a doc is obsoleted. My assumption is that deprecated means we actively provide reasons why people shouldn't use an old spec tp make people convert faster. Does Obsolete require Deprecate? I don't know. I am happy to go with whatever the IETF process uses here. > > * Need to change the NETCONF WG charter to show that 5277 is being > > * replaced rather than enhanced. > > > > > > > > (ii.) Support 5277bis without Obsoleting 5277 > > > > * Technically identical to (i). > > > > * Implementations free to choose 5277 or 5277bis, with no guidance on > > * which the WG recommends. > > > > o This could be confusing to customers as NETCONF WG will be > > advocating competing technologies for the place of overlap. -- > > i.e., NETCONF over XML with a single subscription. > > > > * Establishes competing technology futures where one direction would > > * suffice. > > > > > > > > (iii.) Write a new UPDATE draft for 5277 NETCONF only transport > > I'm not sure what you have in mind? What exactly would this new draft > contain? I don't find this path interesting, nor do I plan any authorship on this option. So I am not thinking about it much. I am not sure if anyone wants (iii.). > > * Supports a subset of requirements: > > > > o Cannot support (1) or (8) > > > > o Supporting (2), (3), (4), (5), (6), & (7) possible, but would > > require the creation of replicated/competing mechanisms with (8). > > > > * Doubles the development effort if the yang-push control plane is also > > * required. > > > > * WG would need to build guidelines on when to use 5277bis or this new > > * UPDATE draft (assuming the WG wanted to proceed with the transport > > * independent 5277bis.) > > > > * No identified author / champion for this path. (Because business > > * drivers being driven by other than NETCONF/XML.) > > > > * Update draft itself wouldn't require a NETCONF charter update. > > > > > > Based on this list, the people working in on the Subscription & > > Event Notification weekly calls have a preference for (i.) followed > > by (ii.). Do you have a preference or additional questions not > > addressed here or in the earlier threads? > > I think the reasoning goes something like this: > > We need to support multiple subscriptions in a single NETCONF > session. This implies that we need a 'subscription-id' field in the > payload. The current payload does not contain a 'subscription-id', > and it is inflexible in the sense that it does not allow us to add > header fields. > > Thus, we need a new notification payload, which means that we cannot > simply update RFC 5277 and be backwards compatible. > > If this is correct, It is. > I think it is fine to obsolete RFC 5277, but not with the current > draft-ietf-netconf-rfc5277bis-00. Instead, I > propose: > > A. one document that defines, in a protocol-neutral manner, the > notification architecture, i.e., explains the concepts of > streams, replay, filters, and subscriptions etc. This is in 5277bis. > B. one document that defines, in a protocol-neutral manner, how YANG > notifications are encoded in XML and JSON. This covers NETCONF > and RESTCONF (future protocols might reuse this, or they might > need something else). Currently encoding examples are in draft-ietf-netconf-netconf-event-notifications and draft-ietf-netconf-restconf-notif. Incomplete notification definitions are in 5277bis (as noted above). But if the WG wishes, we could rearrange things and have a protocol independent encoding document for notifications. I believe we should revisit the proper placement of this now as part of our discussion on the structure of the notifications. > C1. one document that defines how notifications are sent over > NETCONF. Specifially, it needs to generalize section 3.7 of RFC > 5277, since it changes the message flow defined in RFC 6241. > (In the best of worlds, this would be a section in the NETCONF > protocol spec). draft-ietf-netconf-netconf-event-notifications > C2. one document that defines how notifications are sent over > RESTCONF (this is currently section 6 in > draft-ietf-netconf-restconf-18, and it needs to be updated) draft-ietf-netconf-restconf-notif, although we recommend HTTP2 for the notifications, and RESTCONF for the dynamic subscription establishment. > D. one document that defines the YANG data model for stream > detection, subscription mgmt etc. This is mostly the current > draft-ietf-netconf-rfc5277bis-00. Yes > Note that RFC 5277 contains A+B+C1+D. > > Maybe some of these could be collapsed into one document, e.g. A+B, or > maybe A+B+D. The current document breakdown covers the intents above. But we could move B to an independent draft if the WG prefers. Eric > > /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Dec 21 23:08:31 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A340129515; Wed, 21 Dec 2016 23:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 FQBrI9Dd-_NX; Wed, 21 Dec 2016 23:08:27 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A2A8E12951C; Wed, 21 Dec 2016 23:08:27 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 5EA221AE028C; Thu, 22 Dec 2016 08:08:25 +0100 (CET) Date: Thu, 22 Dec 2016 08:08:25 +0100 (CET) Message-Id: <20161222.080825.2020963748801156593.mbj@tail-f.com> To: evoit@cisco.com From: Martin Bjorklund In-Reply-To: <3e4b821491f24fff9b1d0a8edcdf33ba@XCH-RTP-013.cisco.com> References: <970f48bdc9cd4e68b7792e91c1a04e5f@XCH-RTP-013.cisco.com> <20161221.110652.2082676844450734019.mbj@tail-f.com> <3e4b821491f24fff9b1d0a8edcdf33ba@XCH-RTP-013.cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netconf-chairs@ietf.org Subject: Re: [Netconf] 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 07:08:29 -0000 "Eric Voit (evoit)" wrote: > Hi Martin, > > Thanks for the thoughts... > > > From: Martin Bjorklund, December 21, 2016 5:07 AM > > "Eric Voit (evoit)" wrote: > > > To summarize previous threads, key benefits of 5277bis over RFC 5277 > > > include: > > > > > > (1) transport independence > > > > > > (2) configured subscriptions > > > > > > (3) many subscriptions per transport session > > > > > > (4) modify and delete subscription RPCs > > > > > > (5) control plane notifications > > > > > > (6) data plane notification including subscription-id > > > > > > (7) negotiation (see Yves' thread from yesterday) > > > > > > (8) control plane reuse with draft-ietf-netconf-yang-push. > > > > I will have to assume that when you say "5277bis" you mean draft-ietf-netconf- > > rfc5277bis-00. If this is true, I don't think that your statement above is correct. > > Maybe this is your *plan*, but it is difficult to comment on... > > current WG draft is -01. > > A working version of -02 is at > https://github.com/netconf-wg/rfc5277bis/blob/master/rfc5277bis-02-v20Dec2016.txt > But it hasn't been posted yet. > > > Also note that RFC 5277 defines how notifications are sent over NETCONF. This > > is by nature protocol-specific, and it must be done. > > So the fact that draft-ietf-netconf-rfc5277bis-00 does (1) is a bug, not a > > feature, if you want to obsolete RFC 5277. > > the obsoleting of 5277 is intended to come from a combination of > draft-ietf-netconf-rfc5277bis & draft-ietf-netconf-netconf-event-notifications > > I agree work is needed to get the full coverage across them. > > > > Those of us working 5277bis had been planning on supporting existing > > > 5277 implementations via a separate backwards compatibility section. > > > But as we have gone forward, we see no meaningful technical overlaps. > > > I.e., there are no RPC or notifications shared between the 5277 and > > > 5277bis solutions. Any compatibility mode section would be fully > > > standalone. Considering that people can just refer to 5277 if they > > > need it, and considering 5277 & 5277bis could easily run in parallel > > > on different transport sessions, building a standalone backwards > > > compatibility section seems both confusing and redundant. > > > > > > > > > > > > This leaves three options: > > > > > > (i.) OBSOLETE 5277 by replacing it with 5277bis > > > > > > (ii.) Support 5277bis without Obsoleting 5277 > > > > > > (iii.) Write a new UPDATE draft for 5277 NETCONF only transport > > > > > > > > > > > > The benefits and issues of each are as follows: > > > > > > > > > > > > (i.) OBSOLETE 5277 by replacing it with 5277bis > > > > > > * Supports all requirements (1) through (8). > > > > Maybe, but note that (1) through (8) is not a *complete* list of requirements. > > Yes. (1)-(8) is a summary. > > > (And not all items are real requirements, e.g., (6)). > > Below you note that we need a 'subscription-id' field in the > payload'. Yes, but this is a solution that follows from the requirements; it is not a requirement in itself. [...] > > I think it is fine to obsolete RFC 5277, but not with the current > > draft-ietf-netconf-rfc5277bis-00. Instead, I > > propose: > > > > A. one document that defines, in a protocol-neutral manner, the > > notification architecture, i.e., explains the concepts of > > streams, replay, filters, and subscriptions etc. > > This is in 5277bis. Ok. I think we already agree that some things are currently missing, like replay, but that's fine. > > B. one document that defines, in a protocol-neutral manner, how YANG > > notifications are encoded in XML and JSON. This covers NETCONF > > and RESTCONF (future protocols might reuse this, or they might > > need something else). > > Currently encoding examples are in draft-ietf-netconf-netconf-event-notifications and draft-ietf-netconf-restconf-notif. Incomplete notification definitions are in 5277bis (as noted above). But if the WG wishes, we could rearrange things and have a protocol independent encoding document for notifications. > > I believe we should revisit the proper placement of this now as part of our discussion on the structure of the notifications. See below; (a chapter in 5277bis for this topic is fine) > > C1. one document that defines how notifications are sent over > > NETCONF. Specifially, it needs to generalize section 3.7 of RFC > > 5277, since it changes the message flow defined in RFC 6241. > > (In the best of worlds, this would be a section in the NETCONF > > protocol spec). > > draft-ietf-netconf-netconf-event-notifications Ok, good. But as I wrote in my most recent review, I think draft-ietf-netconf-netconf-event-notifications needs to be rewritten. It should be a pretty short document that focuses on the message flow for notifications over NETCONF. The current document doesn't have any new normative text. > > C2. one document that defines how notifications are sent over > > RESTCONF (this is currently section 6 in > > draft-ietf-netconf-restconf-18, and it needs to be updated) > > draft-ietf-netconf-restconf-notif, although we recommend HTTP2 for the notifications, and RESTCONF for the dynamic subscription establishment. > > > D. one document that defines the YANG data model for stream > > detection, subscription mgmt etc. This is mostly the current > > draft-ietf-netconf-rfc5277bis-00. > > Yes > > > Note that RFC 5277 contains A+B+C1+D. > > > > Maybe some of these could be collapsed into one document, e.g. A+B, or > > maybe A+B+D. > > The current document breakdown covers the intents above. But we could move B to an independent draft if the WG prefers. The name of the drafts are confusing, esp. 5277bis. But I don't propose a change of the draft names. Maybe we should adjust the titles a bit, when we have agreement on what goes into the different drafts. As I wrote earlier, it is fine if there is one document that covers A+B+D, and if that is 5277bis, that's fine with me. /martin From nobody Thu Dec 22 04:12:38 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2E5129959 for ; Thu, 22 Dec 2016 04:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYWeWq0-vCCC for ; Thu, 22 Dec 2016 04:12:32 -0800 (PST) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201A5129952 for ; Thu, 22 Dec 2016 04:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: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=e79LZYV8B4bSSWVlr/P+J2yepg7RBe+L9VijyZLhV3Q=; b=oWODwsG281BBv5D3vhoqqjC672 x09+T/pyIYcatgB7HxmDN6d+yVdfm0idGYGDLVXIWFDObq0oEdNG2lYivYkJDJLKk/GfTtHRbShku McEbErmkxnJGf79XYmH86ATYyf6GbbtedfyzLGxQqtmNCugdXGqW6S1CZICkL2fOjjq4FAhd7N6EZ 5Z7xvSFuiSzzQVoD4xvSqYDRRc4wLXLpfxtTuOlb8cKAhruf9C+w8OgMf/8F3LDpuZL5CrCvyDGwA Lpx04bCJ/8VPA9rpRvvtra+GgFqXt7NNnVmf44BaCAH5XYz+4JaIXxKpl0TERdgxAnhpcjhSgilkv Xvzro02Q==; Received: from hansfords.plus.com ([84.92.116.209]:39884 helo=Vanguard) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cK2EW-001IQy-TQ for netconf@ietf.org; Thu, 22 Dec 2016 12:12:29 +0000 From: "Jonathan Hansford" To: "'Netconf'" Date: Thu, 22 Dec 2016 12:12:30 -0000 Message-ID: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0164_01D25C4C.AB79C5C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdJb+2dYNiDGrFcrRNO/H9B8RvAZTg== Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Archived-At: Subject: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 12:12:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0164_01D25C4C.AB79C5C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit draft-ietf-netconf-restconf-18, page 13 states "If the NETCONF server supports :writable-running, all edits to configuration nodes in {+restconf}/data are performed in the running configuration datastore. Otherwise, if the device supports :candidate, all edits to configuration nodes in {+restconf}/data are performed in the candidate configuration datastore." I have been reading through the mail archive on the relationship between :writable-running and :candidate (see excerpts below) and my understanding is as follows: For a NETCONF client to be able to update the configuration of a server, the server must support :writable-running and/or :candidate. A NETCONF server can support both :writable-running and :candidate, indeed there appear to be some in the wild that do, but there is a measure of unease about this, with the suggestion by some the combination should be deprecated. Based on the text from the draft (above) it would appear that, should a NETCONF server support both capabilities, all RESTCONF edits should be performed in the running configuration datastore. Is that considered the lesser of two evils, the other being that all RESTCONF edits should be performed in the candidate configuration datastore, or was the possibility overlooked? My gut feel is that it would be safer to use the candidate configuration datastore and that the two paragraphs in the draft should be the other way around, i.e. "If the NETCONF server supports :candidate, all edits to configuration nodes in {+restconf}/data are performed in the candidate configuration datastore. Otherwise, if the device supports :writable-running, all edits to configuration nodes in {+restconf}/data are performed in the running configuration datastore." Jonathan --- "Re: NETCONF modelled in UML" Andy Bierman (Jun 01 2004) states: "We . thought we should keep the #candidate and #writable-running capabilities independent. maybe we should make these capabilities mutually exclusive." "[Netconf] partial-lock feedback" Phil Shafer (Nov 13 2008) states: "There's some logic that says the intersection of boxes with :writable-running and :candidate is (or should be) nil." "Re: [Netconf] partial-lock feedback" Balazs Lengyel (Nov 17 2008) states: "It is not stated anywhere that you can't have candidate and writable-running together." "[Netconf] :candidate vs :writable-running" Tomasz Mikolajczyk (Nov 28 2008), quotes from http://www.netconfcentral.com/netconf_docs that: "Agent platforms which support the :candidate capability usually do not also support the :writable-running capability, since mixing direct edits to would defeat the purpose of using this scratchpad database to collect and validate changes before applying them." This text persists, though "Agent platforms" has been replaced with "Server platforms". "Re: [Netconf] :candidate vs :writable-running" Martin Bjorklund (Dec 01 2008) states: "I don't know about others, but I do know that many (most?) of our customers have both :candidate and :writable-running. By having both, you give the choice to the client application - either make sure you're alone and work with the candidate or edit running directly. Some changes might be easier to just edit to running." "Re: [Netconf] lock/unlock on candidate" Martin Bjorklund (Dec 01 2008) states: "This is only an issue if the box supports :candidate and :writable-running." "Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt" Kent Watsen (Mar 18 2009) states: "can devices advertize both :candidate and :writable-running? - aren't those capabilities mutually exclusive?" "Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt" Martin Bjorklund (Mar 18 2009) states: "There's nothing in 4741 that says that they are mutually exclusive. And I don't think they should be. Some devices already support this combination." "Re: [Netconf] :writable-running" WashamFan (May 11 2009) states: "Given session A with :candidate and session B with :writable-running, it is beneficial for session A to lock both and for consistency." "Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Andy Bierman (Jul 25 2009) states: "every agent MUST have exactly 1 database that can be the target of an operation. (Writing to both and does not work!) therefore the agent MUST support the :candidate OR: writable-running capabilities, but not both" "Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Phil Shafer (Jul 25 2009) states: "I think Martin's code support this (both)." "Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Martin Bjorklund (Jul 25 2009) states: "Yes it does. I agree that other combinations are more useful, but also this combination works. If you can copy from candidate to url X, and from url X to running, why not copy from candidate to running directly? (and IMO it means just that). It only works if you have a candidate AND :writable-running of course." "Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Andy Bierman (Jul 25 2009) states: "I think the standard is poorly specified in this entire area." "Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Martin Bjorklund (Jul 26 2009) states: " has more parameters than , so I think it must be kept. Also, you cannot copy-config to running unless :writable-running is advertised, so is needed." "[Netconf] :writable-running and :candidate" Andy Bierman (Aug 01 2009) states: "I asked (in email) how the :candidate and :writable-running capabilities can possibly be supported on the same agent. I never got an answer. I do not understand how the candidate database stays in synch with the running database if user B can write to running while user A has the candidate locked. Also what happens to the edits made by user A when user B issues a ? Are the changes just made to running undone (they were not in the candidate, so they must be undone, right?) Is this part of the intended database architecture or not? And if user A does a copy-config from a locked candidate to running? That is allowed of course." "Re: [Netconf] Fw: Database Architecture OK or NOT-OK?" Andy Bierman (Aug 03 2009) states: "IMO, :candidate and :writable-running do not work together. They almost work together, and only go horribly wrong sometimes. If that's good enough for the NETCONF database architecture, then I guess there is nothing to fix." "Re: [Netconf] :writable-running and :candidate" Phil Shafer (Aug 08 2009), in reply to Andy Bierman's previous email comment "I asked (in email) how the :candidate and :writable-running capabilities can possibly be supported on the same agent. I never got an answer.", states: "I believe I answered you, saying that tail-f's sw does this." "Re: [Netconf] :writable-running and :candidate" Andy Bierman (Aug 08 2009) states: "I asked for clarifications on the standard, for specific corner-cases that IMO indicate that this combination is not supported by the standard. The thread reached a conclusion that even though any changes made to running will get wiped-out as soon as the candidate is committed, this is how the standard is intended to work. I can't imagine that an operator or NMS developer using :writable-running would reach the same conclusion, but that's their problem -- not an IETF standards problem, right?" "Re: [Netconf] Fw: Database Architecture OK or NOT-OK?" Phil Shafer (Aug 10 2009) states: "I don't support :writable-running, just :candidate, and the interaction between the two isn't clear. Martin, how does this work on your sw?" "Re: [Netconf] Fw: Database Architecture OK or NOT-OK?" Martin Bjorklund (Aug 11 2009) states: "There is no magic going on just because the box is configured to use both :candidate and :writable-running. Each operation behaves the same regardless of the other capabilities. So resets candidate to the contents of running, and replaces running with the contents of candidate. I agree that it is a burden on the client software to support all different combinations of (startup, writable-running, candidate), and a server developer that has a choice should carefully consider which combination to implement." "Re: [Netconf] Fw: Database Architecture OK or NOT-OK?" Juergen Schoenwaelder (Aug 11 2009) states: "The candidate design does not work with :writeable-running unless we find a more precise definition how to determine whether candidate is in a "good shape" or not." "Re: [Netconf] NACM issue?" Martin Bjorklund (Jan 11 2012) states ".only if :writable-running and :candidate is advertised at the same time, and I think we have agreed that this is a Bad Idea." "Re: [Netconf] The configuration datastore and :writable-running" Juergen Schoenwaelder (Aug 08 2013) states: "Implementing NETCONF read-only has obviously little value for real configuration management. The reason why we have :writable-running and :candidate is that some major vendors use very different models when it comes to making configuration changes and as such you will see implementations that either announce :writable-running or :candidate or :writable-running and :candidate together." "Re: [Netconf] The configuration datastore and :writable-running" Andy Bierman (Aug 08 2013) states: ":candidate and :writable-running together should be considered deprecated. This is a degenerate use-case for concurrent transactions. The WG should standardize this properly at some point in the future, so clients can use a predictable standard transaction model." "Re: [Netconf] in a server that supports both writable-running and candidate" Andy Bierman (Jul 14 2016) states: "The reason nobody implements :candidate and :writable-running together is because there is no way to synch the candidate if running has been changed underneath it." "Re: [Netconf] in a server that supports both writable-running and candidate" Sterne, Jason (Nokia - CA) (Jul 14 2016) states: "Nokia SR OS supports both writable-running and candidate. And yes it is complex to manage. The two datastores can't be simply treated independently and some locking/coherency mechanisms are needed between them." ------=_NextPart_000_0164_01D25C4C.AB79C5C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-ietf-netconf-restconf-18, page 13 states = “If the NETCONF server supports :writable-running, all edits to = configuration nodes in {+restconf}/data are performed in the running = configuration datastore… Otherwise, if the device supports = :candidate, all edits to configuration nodes in {+restconf}/data are = performed in the candidate configuration = datastore.”

 

I have been = reading through the mail archive on the relationship between = :writable-running and :candidate (see excerpts below) and my = understanding is as follows:

 

For a = NETCONF client to be able to update the configuration of a server, the = server must support :writable-running and/or = :candidate.

A NETCONF server can = support both :writable-running and :candidate, indeed there appear to be = some in the wild that do, but there is a measure of unease about this, = with the suggestion by some the combination should be = deprecated.

 

Based on the text from the draft (above) it would = appear that, should a NETCONF server support both capabilities, all = RESTCONF edits should be performed in the running configuration = datastore. Is that considered the lesser of two evils, the other being = that all RESTCONF edits should be performed in the candidate = configuration datastore, or was the possibility overlooked? My gut feel = is that it would be safer to use the candidate configuration datastore = and that the two paragraphs in the draft should be the other way around, = i.e. “If the NETCONF server supports :candidate, all edits to = configuration nodes in {+restconf}/data are performed in the candidate = configuration datastore… Otherwise, if the device supports = :writable-running, all edits to configuration nodes in {+restconf}/data = are performed in the running configuration = datastore.”

 

Jonathan

 

---

 

"Re: NETCONF modelled in UML" Andy Bierman (Jun 01 = 2004) states: “We … thought we should keep the #candidate = and #writable-running capabilities independent… maybe we should = make these capabilities mutually exclusive.”

 

"[Netconf] partial-lock feedback" Phil Shafer (Nov 13 = 2008) states: “There's some logic that says the intersection of = boxes with :writable-running and :candidate is (or should be) = nil.”

 

"Re: [Netconf] partial-lock feedback" Balazs Lengyel = (Nov 17 2008) states: “It is not stated anywhere that you can't = have candidate and writable-running together.”

 

“[Netconf] :candidate vs :writable-running” Tomasz = Mikolajczyk (Nov 28 2008), quotes from http://www.netconfcen= tral.com/netconf_docs that: “Agent platforms which support the = :candidate capability usually do not also support the = :writable-running  capability, since mixing direct edits to = <running/>  would defeat the purpose of using this scratchpad = database to collect and validate changes before applying them.” = This text persists, though “Agent platforms” has been = replaced with “Server platforms”.

 

“Re: [Netconf] :candidate vs :writable-running” = Martin Bjorklund (Dec 01 2008) states: “I don't know about others, = but I do know that many (most?) of our customers have both :candidate = and :writable-running.  By having both, you give the choice to the = client application - either make sure you're alone and work with the = candidate or edit running directly. Some changes might be easier to just = edit to running.”

 

“Re: [Netconf] lock/unlock on candidate” Martin = Bjorklund (Dec 01 2008) states: “This is only an issue if the box = supports :candidate and :writable-running.”

 

“Re: [Netconf] issue with = draft-ietf-netconf-partial-lock-07.txt” Kent Watsen (Mar 18 = 2009) states: “can devices advertize both :candidate and = :writable-running?  - aren't those capabilities mutually = exclusive?”

 

“Re: [Netconf] issue with = draft-ietf-netconf-partial-lock-07.txt” Martin Bjorklund (Mar = 18 2009) states: “There's nothing in 4741 that says that they are = mutually exclusive. And I don't think they should be.  Some devices = already support this combination.”

 

“Re: [Netconf] :writable-running” WashamFan (May 11 = 2009) states: “Given session A with :candidate and session B with = :writable-running, it is beneficial for session A to lock both = <candidate> and <running> for = consistency.”

 

“Re: [Netconf] Comments = :draft-ietf-netconf-4741bis-01.txt” Andy Bierman (Jul 25 2009) = states: “every agent MUST have exactly 1 database that can be the = target of an <edit-config> operation. (Writing to both = <candidate> and <running> does not work!) therefore the = agent MUST support the :candidate OR: writable-running capabilities, but = not both”

 

“Re: [Netconf] Comments = :draft-ietf-netconf-4741bis-01.txt” Phil Shafer (Jul 25 2009) = states: “I think Martin's code support this = (both).”

 

“Re: [Netconf] Comments = :draft-ietf-netconf-4741bis-01.txt” Martin Bjorklund (Jul 25 = 2009) states: “Yes it does.  I agree that other combinations = are more useful, but also this combination works… If you can copy = from candidate to url X, and from url X to running, why not copy from = candidate to running directly?  (and IMO it means just that).  = It only works if you have a candidate AND :writable-running of = course.”

 

“Re: [Netconf] Comments = :draft-ietf-netconf-4741bis-01.txt” Andy Bierman (Jul 25 2009) = states: “I think the standard is poorly specified in this entire = area.”

 

“Re: [Netconf] Comments = :draft-ietf-netconf-4741bis-01.txt” Martin Bjorklund (Jul 26 = 2009) states: “<commit> has more parameters than = <copy-config>, so I think it must be kept.  Also, you cannot = copy-config to running unless :writable-running is advertised, so = <commit> is needed.”

 

“[Netconf] :writable-running and :candidate” Andy = Bierman (Aug 01 2009) states: “I asked (in email) how the = :candidate and :writable-running capabilities can possibly be supported = on the same agent. I never got an answer. I do not understand how the = candidate database stays in synch with the running database if user B = can write to running while user A has the candidate locked.  Also = what happens to the edits made by user A when user B issues a = <commit>? Are the changes just made to running undone (they were = not in the candidate, so they must be undone, right?) Is this part of = the intended database architecture or not? And if user A does a = copy-config from a locked candidate to running? That is allowed of = course.”

 

“Re: [Netconf] Fw: Database Architecture OK or = NOT-OK?” Andy Bierman (Aug 03 2009) states: “IMO, = :candidate and :writable-running do not work together.  They almost = work together, and only go horribly wrong sometimes.  If that's = good enough for the NETCONF database architecture, then I guess there is = nothing to fix.”

 

“Re: [Netconf] :writable-running and :candidate” = Phil Shafer (Aug 08 2009), in reply to Andy Bierman’s previous = email comment “I asked (in email) how the :candidate and = :writable-running capabilities can possibly be supported on the same = agent. I never got an answer.”, states: “I believe I = answered you, saying that tail-f's sw does this.”

 

“Re: [Netconf] :writable-running and :candidate” = Andy Bierman (Aug 08 2009) states: “I asked for clarifications on = the standard, for specific corner-cases that IMO indicate that this = combination is not supported by the standard. The thread reached a = conclusion that even though any changes made to running will get = wiped-out as soon as the candidate is committed, this is how the = standard is intended to work. I can't imagine that an operator or NMS = developer using :writable-running would reach the same conclusion, but = that's their problem -- not an IETF standards problem, = right?”

 

“Re: [Netconf] Fw: Database Architecture OK or = NOT-OK?” Phil Shafer (Aug 10 2009) states: “I don't = support :writable-running, just :candidate, and the interaction between = the two isn't clear.  Martin, how does this work on your = sw?”

 

“Re: [Netconf] Fw: Database Architecture OK or = NOT-OK?” Martin Bjorklund (Aug 11 2009) states: “There = is no magic going on just because the box is configured to use both = :candidate and :writable-running.  Each operation behaves the same = regardless of the other capabilities.  So <discard-changes> = resets candidate to the contents of running, and <commit> replaces = running with the contents of candidate. I agree that it is a burden on = the client software to support all different combinations of (startup, = writable-running, candidate), and a server developer that has a choice = should carefully consider which combination to = implement.”

 

“Re: [Netconf] Fw: Database Architecture OK or = NOT-OK?” Juergen Schoenwaelder (Aug 11 2009) states: = “The candidate design does not work with :writeable-running unless = we find a more precise definition how to determine whether candidate is = in a "good shape" or not.”

 

“Re: [Netconf] NACM issue?” Martin Bjorklund (Jan 11 = 2012) states “…only if :writable-running and :candidate is = advertised at the same time, and I think we have agreed that this is a = Bad Idea.”

 

“Re: [Netconf] The <running> configuration datastore and = :writable-running” Juergen Schoenwaelder (Aug 08 2013) states: = “Implementing NETCONF read-only has obviously little value for = real configuration management. The reason why we have :writable-running = and :candidate is that some major vendors use very different models when = it comes to making configuration changes and as such you will see = implementations that either announce :writable-running or :candidate or = :writable-running and :candidate together.”

 

“Re: [Netconf] The <running> configuration datastore and = :writable-running” Andy Bierman (Aug 08 2013) states: = “:candidate and :writable-running together should be considered = deprecated. This is a degenerate use-case for concurrent = transactions.  The WG should standardize this properly at some = point in the future, so clients can use a predictable standard = transaction model.”

 

“Re: [Netconf] <lock> in a server that supports both = writable-running and candidate” Andy Bierman (Jul 14 2016) = states: “The reason nobody implements :candidate and = :writable-running together is because there is no way to synch the = candidate if running has been changed underneath = it.”

 

“Re: [Netconf] <lock> in a server that supports both = writable-running and candidate” Sterne, Jason (Nokia - CA) = (Jul 14 2016) states: “Nokia SR OS supports both writable-running = and candidate.  And yes it is complex to manage.  The two = datastores can’t be simply treated independently and some = locking/coherency mechanisms are needed between = them.”

------=_NextPart_000_0164_01D25C4C.AB79C5C0-- From nobody Thu Dec 22 06:24:30 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2CA128E19; Thu, 22 Dec 2016 06:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2hQL2-resvg; Thu, 22 Dec 2016 06:24:22 -0800 (PST) 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 1A93D1200A0; Thu, 22 Dec 2016 06:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6827; q=dns/txt; s=iport; t=1482416662; x=1483626262; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7lMN3L+d/UXDr6sXcbcG5Nd0jfL2jRy2xRiaQi/7Dtk=; b=WucMGEDSpXf66Ky0sf+MU3Chm1IMGYRKcrYzeUchsYLJ+fGg9XGQW9h3 pNIEID/mVWpxqvzwMm60URrMuqMyU63LXKQSKLEp9+kBVEPt04v/TGfg+ MQAG0o8U4j6QWczLK6qTCkNGhda7tt+yLc8HgQqKW7ShiucLwzr7x5RAg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQDo4FtY/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAR9cgQgHjUqWUpUVggkqhXgCgWw/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDATo9AgULAgEIDgQDAw0REDIXDgEBBA4FCBOISggOq2yLBQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGQWGSIRjiiwFjwSLdQGGUYpfgX6OXYd6hiyEDgEfN4E?= =?us-ascii?q?qLoVhcodcgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,388,1477958400"; d="scan'208";a="188519639" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2016 14:24:20 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uBMEOKnq009407 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Dec 2016 14:24:20 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 22 Dec 2016 09:24:19 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 22 Dec 2016 09:24:19 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund Thread-Topic: [Netconf] 3 Options for Subscription & Event Notification draft structure Thread-Index: AdJa002bNCznOyZwQL2tYKqXggHZBAAyI6cAAARYNuAAJ7btgAAEq5Hg Date: Thu, 22 Dec 2016 14:24:19 +0000 Message-ID: References: <970f48bdc9cd4e68b7792e91c1a04e5f@XCH-RTP-013.cisco.com> <20161221.110652.2082676844450734019.mbj@tail-f.com> <3e4b821491f24fff9b1d0a8edcdf33ba@XCH-RTP-013.cisco.com> <20161222.080825.2020963748801156593.mbj@tail-f.com> In-Reply-To: <20161222.080825.2020963748801156593.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 14:24:29 -0000 Thanks Martin, I think we are in the same place then. Eric > From: Martin Bjorklund, December 22, 2016 2:08 AM >=20 > "Eric Voit (evoit)" wrote: > > Hi Martin, > > > > Thanks for the thoughts... > > > > > From: Martin Bjorklund, December 21, 2016 5:07 AM "Eric Voit > > > (evoit)" wrote: > > > > To summarize previous threads, key benefits of 5277bis over RFC > > > > 5277 > > > > include: > > > > > > > > (1) transport independence > > > > > > > > (2) configured subscriptions > > > > > > > > (3) many subscriptions per transport session > > > > > > > > (4) modify and delete subscription RPCs > > > > > > > > (5) control plane notifications > > > > > > > > (6) data plane notification including subscription-id > > > > > > > > (7) negotiation (see Yves' thread from yesterday) > > > > > > > > (8) control plane reuse with draft-ietf-netconf-yang-push. > > > > > > I will have to assume that when you say "5277bis" you mean > > > draft-ietf-netconf- rfc5277bis-00. If this is true, I don't think th= at your > statement above is correct. > > > Maybe this is your *plan*, but it is difficult to comment on... > > > > current WG draft is -01. > > > > A working version of -02 is at > > https://github.com/netconf-wg/rfc5277bis/blob/master/rfc5277bis-02-v20 > > Dec2016.txt > > But it hasn't been posted yet. > > > > > Also note that RFC 5277 defines how notifications are sent over > > > NETCONF. This is by nature protocol-specific, and it must be done. > > > So the fact that draft-ietf-netconf-rfc5277bis-00 does (1) is a bug, > > > not a feature, if you want to obsolete RFC 5277. > > > > the obsoleting of 5277 is intended to come from a combination of > > draft-ietf-netconf-rfc5277bis & > > draft-ietf-netconf-netconf-event-notifications > > > > I agree work is needed to get the full coverage across them. > > > > > > Those of us working 5277bis had been planning on supporting > > > > existing > > > > 5277 implementations via a separate backwards compatibility section= . > > > > But as we have gone forward, we see no meaningful technical overlap= s. > > > > I.e., there are no RPC or notifications shared between the 5277 > > > > and 5277bis solutions. Any compatibility mode section would be > > > > fully standalone. Considering that people can just refer to 5277 > > > > if they need it, and considering 5277 & 5277bis could easily run > > > > in parallel on different transport sessions, building a standalone > > > > backwards compatibility section seems both confusing and redundant. > > > > > > > > > > > > > > > > This leaves three options: > > > > > > > > (i.) OBSOLETE 5277 by replacing it with 5277bis > > > > > > > > (ii.) Support 5277bis without Obsoleting 5277 > > > > > > > > (iii.) Write a new UPDATE draft for 5277 NETCONF only transport > > > > > > > > > > > > > > > > The benefits and issues of each are as follows: > > > > > > > > > > > > > > > > (i.) OBSOLETE 5277 by replacing it with 5277bis > > > > > > > > * Supports all requirements (1) through (8). > > > > > > Maybe, but note that (1) through (8) is not a *complete* list of > requirements. > > > > Yes. (1)-(8) is a summary. > > > > > (And not all items are real requirements, e.g., (6)). > > > > Below you note that we need a 'subscription-id' field in the payload'. >=20 > Yes, but this is a solution that follows from the requirements; it is not= a > requirement in itself. >=20 > [...] >=20 > > > I think it is fine to obsolete RFC 5277, but not with the current > > > draft-ietf-netconf-rfc5277bis-00. Instead, I > > > propose: > > > > > > A. one document that defines, in a protocol-neutral manner, the > > > notification architecture, i.e., explains the concepts of > > > streams, replay, filters, and subscriptions etc. > > > > This is in 5277bis. >=20 > Ok. I think we already agree that some things are currently missing, lik= e replay, > but that's fine. >=20 > > > B. one document that defines, in a protocol-neutral manner, how YAN= G > > > notifications are encoded in XML and JSON. This covers NETCONF > > > and RESTCONF (future protocols might reuse this, or they might > > > need something else). > > > > Currently encoding examples are in draft-ietf-netconf-netconf-event- > notifications and draft-ietf-netconf-restconf-notif. Incomplete notifica= tion > definitions are in 5277bis (as noted above). But if the WG wishes, we co= uld > rearrange things and have a protocol independent encoding document for > notifications. > > > > I believe we should revisit the proper placement of this now as part of= our > discussion on the structure of the notifications. >=20 > See below; (a chapter in 5277bis for this topic is fine) >=20 > > > C1. one document that defines how notifications are sent over > > > NETCONF. Specifially, it needs to generalize section 3.7 of RFC > > > 5277, since it changes the message flow defined in RFC 6241. > > > (In the best of worlds, this would be a section in the NETCONF > > > protocol spec). > > > > draft-ietf-netconf-netconf-event-notifications >=20 > Ok, good. >=20 > But as I wrote in my most recent review, I think draft-ietf-netconf-netco= nf- > event-notifications needs to be rewritten. > It should be a pretty short document that focuses on the message flow for > notifications over NETCONF. The current document doesn't have any new > normative text. >=20 > > > C2. one document that defines how notifications are sent over > > > RESTCONF (this is currently section 6 in > > > draft-ietf-netconf-restconf-18, and it needs to be updated) > > > > draft-ietf-netconf-restconf-notif, although we recommend HTTP2 for the > notifications, and RESTCONF for the dynamic subscription establishment. > > > > > D. one document that defines the YANG data model for stream > > > detection, subscription mgmt etc. This is mostly the current > > > draft-ietf-netconf-rfc5277bis-00. > > > > Yes > > > > > Note that RFC 5277 contains A+B+C1+D. > > > > > > Maybe some of these could be collapsed into one document, e.g. A+B, > > > or maybe A+B+D. > > > > The current document breakdown covers the intents above. But we could > move B to an independent draft if the WG prefers. >=20 > The name of the drafts are confusing, esp. 5277bis. But I don't propose = a > change of the draft names. Maybe we should adjust the titles a bit, when= we > have agreement on what goes into the different drafts. >=20 > As I wrote earlier, it is fine if there is one document that covers > A+B+D, and if that is 5277bis, that's fine with me. >=20 >=20 > /martin From nobody Thu Dec 22 11:27:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED586129550 for ; Thu, 22 Dec 2016 11:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2_lKazv2OMn for ; Thu, 22 Dec 2016 11:27:22 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3398A12949B for ; Thu, 22 Dec 2016 11:27:22 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id c47so243722475qtc.2 for ; Thu, 22 Dec 2016 11:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4vvEPQGGXjqhlj6WROfZoXo/7WaYcu38nFrnWuyuSAI=; b=Q15CaREDfbLcW25rmj90gOXj3rav/PRIds20EvLCCVicsMkFQiaTuq07UDjbFLXV1C wEFmdWGhpli6Xk40mwRu36s8YuSd44fNclE12EuivwFxVD7uwS0muokI6O0b+uYyAW9F VHMgOXtXBI01eQZOGvBqPsCmJWXLh/9JaplNXZngTnBHmoQA0xU4880QNT0d4odqcnAF SU7RiaCd783/1o4qRVXXhZc9WCH82qqTzw0qt4PHxMUBOzPA7glqYsh5rnNNrE1xOnJJ z4sFhFzl2FuX/jx18w+IPcOx4PVl/j7dGestbml3NcbpcHn5fhuIVwOSUNe247VjylG+ uHNw== 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=4vvEPQGGXjqhlj6WROfZoXo/7WaYcu38nFrnWuyuSAI=; b=L91C5o9n+yWQmVuPCG32oHz+K5VWmOdC288Qvqi5ALMzM/NaXh7B3oq8hFvMKCHQU2 8gZjgHa1HYyRaylx7k/7ptLiJlbGEF1nXR9TQOCB+KpB+EsA8mo68vz26ShEN6qcc7Xr CyWYJ3ICSYkchtXiEAPS/rCYGuvsNqBrVE6gAYgVHtK4EWm3Yp/JRt2rHNBrjGYA6Mj4 yJgolpXKL0viX4pwWWgXFtIQoyjpYxWp3iMC9FOGckQ4Fh6VBQ0prg7WiFhWmEoULaI2 k/4iWGf0+7Fezrr4K6CEZDrehB3V7VYTlzII0lCQo2stYGw8e9L7MgpnOegqrzncw9LV 8oew== X-Gm-Message-State: AIkVDXJE6fwo3QPsf7s/QYCdxAi92UZgSbmU/2V0P4llnzRGg4zuWmP8VCwxQWSKnCT5drApMboEHfo77G0SYg== X-Received: by 10.200.37.52 with SMTP id 49mr10991528qtm.240.1482434841333; Thu, 22 Dec 2016 11:27:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Thu, 22 Dec 2016 11:27:20 -0800 (PST) In-Reply-To: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> From: Andy Bierman Date: Thu, 22 Dec 2016 11:27:20 -0800 Message-ID: To: Jonathan Hansford Content-Type: multipart/alternative; boundary=001a1135b1ec1ee2b505444442fe Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 19:27:25 -0000 --001a1135b1ec1ee2b505444442fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Thu, Dec 22, 2016 at 4:12 AM, Jonathan Hansford wrote: > draft-ietf-netconf-restconf-18, page 13 states =E2=80=9CIf the NETCONF se= rver > supports :writable-running, all edits to configuration nodes in > {+restconf}/data are performed in the running configuration datastore=E2= =80=A6 > Otherwise, if the device supports :candidate, all edits to configuration > nodes in {+restconf}/data are performed in the candidate configuration > datastore.=E2=80=9D > > > > I have been reading through the mail archive on the relationship between > :writable-running and :candidate (see excerpts below) and my understandin= g > is as follows: > > > > For a NETCONF client to be able to update the configuration of a server, > the server must support :writable-running and/or :candidate. > > A NETCONF server can support both :writable-running and :candidate, indee= d > there appear to be some in the wild that do, but there is a measure of > unease about this, with the suggestion by some the combination should be > deprecated. > > > > Based on the text from the draft (above) it would appear that, should a > NETCONF server support both capabilities, all RESTCONF edits should be > performed in the running configuration datastore. Is that considered the > lesser of two evils, the other being that all RESTCONF edits should be > performed in the candidate configuration datastore, or was the possibilit= y > overlooked? My gut feel is that it would be safer to use the candidate > configuration datastore and that the two paragraphs in the draft should b= e > the other way around, i.e. =E2=80=9CIf the NETCONF server supports :candi= date, all > edits to configuration nodes in {+restconf}/data are performed in the > candidate configuration datastore=E2=80=A6 Otherwise, if the device suppo= rts > :writable-running, all edits to configuration nodes in {+restconf}/data a= re > performed in the running configuration datastore.=E2=80=9D > > > This seems OK, but we do not support candidate and running as targets at the same time, so I do not know how it impacts the implementation to add this constraint. I do not agree that the strict text in RFC 6241 actually supports this editing mode. If it does, then following the spec would lead to an implementation where the candidate would clobber edits made in running. There is no text that seems to support automatic update of candidate after the edit to running. There is certainly no text that describes how edit conflicts in candidate are resolved. > Jonathan > > > Andy > --- > > > > "Re: NETCONF modelled in UML" > > Andy Bierman (Jun 01 2004) states: =E2=80=9CWe =E2=80=A6 thought we shoul= d keep the > #candidate and #writable-running capabilities independent=E2=80=A6 maybe = we should > make these capabilities mutually exclusive.=E2=80=9D > > > > "[Netconf] partial-lock feedback" > > Phil Shafer (Nov 13 2008) states: =E2=80=9CThere's some logic that says t= he > intersection of boxes with :writable-running and :candidate is (or should > be) nil.=E2=80=9D > > > > "Re: [Netconf] partial-lock feedback" > > Balazs Lengyel (Nov 17 2008) states: =E2=80=9CIt is not stated anywhere t= hat you > can't have candidate and writable-running together.=E2=80=9D > > > > =E2=80=9C[Netconf] :candidate vs :writable-running=E2=80=9D > > Tomasz Mikolajczyk (Nov 28 2008), quotes from > http://www.netconfcentral.com/netconf_docs that: =E2=80=9CAgent platforms= which > support the :candidate capability usually do not also support the > :writable-running capability, since mixing direct edits to > would defeat the purpose of using this scratchpad database to collect and > validate changes before applying them.=E2=80=9D This text persists, thoug= h =E2=80=9CAgent > platforms=E2=80=9D has been replaced with =E2=80=9CServer platforms=E2=80= =9D. > > > > =E2=80=9CRe: [Netconf] :candidate vs :writable-running=E2=80=9D > > Martin Bjorklund (Dec 01 2008) states: =E2=80=9CI don't know about others= , but I do > know that many (most?) of our customers have both :candidate and > :writable-running. By having both, you give the choice to the client > application - either make sure you're alone and work with the candidate o= r > edit running directly. Some changes might be easier to just edit to > running.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] lock/unlock on candidate=E2=80=9D > > Martin Bjorklund (Dec 01 2008) states: =E2=80=9CThis is only an issue if = the box > supports :candidate and :writable-running.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt= =E2=80=9D > > Kent Watsen (Mar 18 2009) states: =E2=80=9Ccan devices advertize both :ca= ndidate > and :writable-running? - aren't those capabilities mutually exclusive?= =E2=80=9D > > > > =E2=80=9CRe: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt= =E2=80=9D > > Martin Bjorklund (Mar 18 2009) states: =E2=80=9CThere's nothing in 4741 t= hat says > that they are mutually exclusive. And I don't think they should be. Some > devices already support this combination.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] :writable-running=E2=80=9D > > WashamFan (May 11 2009) states: =E2=80=9CGiven session A with :candidate = and > session B with :writable-running, it is beneficial for session A to lock > both and for consistency.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt=E2=80= =9D > > Andy Bierman (Jul 25 2009) states: =E2=80=9Cevery agent MUST have exactly= 1 > database that can be the target of an operation. (Writing t= o > both and does not work!) therefore the agent MUST > support the :candidate OR: writable-running capabilities, but not both=E2= =80=9D > > > > =E2=80=9CRe: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt=E2=80= =9D > > Phil Shafer (Jul 25 2009) states: =E2=80=9CI think Martin's code support = this > (both).=E2=80=9D > > > > =E2=80=9CRe: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt=E2=80= =9D > > Martin Bjorklund (Jul 25 2009) states: =E2=80=9CYes it does. I agree tha= t other > combinations are more useful, but also this combination works=E2=80=A6 If= you can > copy from candidate to url X, and from url X to running, why not copy fro= m > candidate to running directly? (and IMO it means just that). It only > works if you have a candidate AND :writable-running of course.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt=E2=80= =9D > > Andy Bierman (Jul 25 2009) states: =E2=80=9CI think the standard is poorl= y > specified in this entire area.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt=E2=80= =9D > > Martin Bjorklund (Jul 26 2009) states: =E2=80=9C has more paramet= ers than > , so I think it must be kept. Also, you cannot copy-config = to > running unless :writable-running is advertised, so is needed.=E2= =80=9D > > > > =E2=80=9C[Netconf] :writable-running and :candidate=E2=80=9D > > Andy Bierman (Aug 01 2009) states: =E2=80=9CI asked (in email) how the :c= andidate > and :writable-running capabilities can possibly be supported on the same > agent. I never got an answer. I do not understand how the candidate > database stays in synch with the running database if user B can write to > running while user A has the candidate locked. Also what happens to the > edits made by user A when user B issues a ? Are the changes just > made to running undone (they were not in the candidate, so they must be > undone, right?) Is this part of the intended database architecture or not= ? > And if user A does a copy-config from a locked candidate to running? That > is allowed of course.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] Fw: Database Architecture OK or NOT-OK?=E2=80=9D > > Andy Bierman (Aug 03 2009) states: =E2=80=9CIMO, :candidate and :writable= -running > do not work together. They almost work together, and only go horribly > wrong sometimes. If that's good enough for the NETCONF database > architecture, then I guess there is nothing to fix.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] :writable-running and :candidate=E2=80=9D > > Phil Shafer (Aug 08 2009), in reply to Andy Bierman=E2=80=99s previous em= ail > comment =E2=80=9CI asked (in email) how the :candidate and :writable-runn= ing > capabilities can possibly be supported on the same agent. I never got an > answer.=E2=80=9D, states: =E2=80=9CI believe I answered you, saying that = tail-f's sw does > this.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] :writable-running and :candidate=E2=80=9D > > Andy Bierman (Aug 08 2009) states: =E2=80=9CI asked for clarifications on= the > standard, for specific corner-cases that IMO indicate that this combinati= on > is not supported by the standard. The thread reached a conclusion that ev= en > though any changes made to running will get wiped-out as soon as the > candidate is committed, this is how the standard is intended to work. I > can't imagine that an operator or NMS developer using :writable-running > would reach the same conclusion, but that's their problem -- not an IETF > standards problem, right?=E2=80=9D > > > > =E2=80=9CRe: [Netconf] Fw: Database Architecture OK or NOT-OK?=E2=80=9D > > Phil Shafer (Aug 10 2009) states: =E2=80=9CI don't support :writable-runn= ing, just > :candidate, and the interaction between the two isn't clear. Martin, how > does this work on your sw?=E2=80=9D > > > > =E2=80=9CRe: [Netconf] Fw: Database Architecture OK or NOT-OK?=E2=80=9D > > Martin Bjorklund (Aug 11 2009) states: =E2=80=9CThere is no magic going o= n just > because the box is configured to use both :candidate and > :writable-running. Each operation behaves the same regardless of the oth= er > capabilities. So resets candidate to the contents of > running, and replaces running with the contents of candidate. I > agree that it is a burden on the client software to support all different > combinations of (startup, writable-running, candidate), and a server > developer that has a choice should carefully consider which combination t= o > implement.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] Fw: Database Architecture OK or NOT-OK?=E2=80=9D > > Juergen Schoenwaelder (Aug 11 2009) states: =E2=80=9CThe candidate design= does not > work with :writeable-running unless we find a more precise definition how > to determine whether candidate is in a "good shape" or not.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] NACM issue?=E2=80=9D > > Martin Bjorklund (Jan 11 2012) states =E2=80=9C=E2=80=A6only if :writable= -running and > :candidate is advertised at the same time, and I think we have agreed tha= t > this is a Bad Idea.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] The configuration datastore and :writabl= e-running=E2=80=9D > > Juergen Schoenwaelder (Aug 08 2013) states: =E2=80=9CImplementing NETCONF= read-only > has obviously little value for real configuration management. The reason > why we have :writable-running and :candidate is that some major vendors u= se > very different models when it comes to making configuration changes and a= s > such you will see implementations that either announce :writable-running = or > :candidate or :writable-running and :candidate together.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] The configuration datastore and :writabl= e-running=E2=80=9D > > Andy Bierman (Aug 08 2013) states: =E2=80=9C:candidate and :writable-runn= ing > together should be considered deprecated. This is a degenerate use-case f= or > concurrent transactions. The WG should standardize this properly at some > point in the future, so clients can use a predictable standard transactio= n > model.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] in a server that supports both writable-run= ning and > candidate=E2=80=9D > > Andy Bierman (Jul 14 2016) states: =E2=80=9CThe reason nobody implements = :candidate > and :writable-running together is because there is no way to synch the > candidate if running has been changed underneath it.=E2=80=9D > > > > =E2=80=9CRe: [Netconf] in a server that supports both writable-run= ning and > candidate=E2=80=9D > > Sterne, Jason (Nokia - CA) (Jul 14 2016) states: =E2=80=9CNokia SR OS sup= ports both > writable-running and candidate. And yes it is complex to manage. The tw= o > datastores can=E2=80=99t be simply treated independently and some locking= /coherency > mechanisms are needed between them.=E2=80=9D > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a1135b1ec1ee2b505444442fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,



On Thu, Dec 22, 2016 at 4:12 AM, Jonathan = Hansford <jonathan@hansfords.net> wrote:
=

dr= aft-ietf-netconf-restconf-18, page 13 states =E2=80=9CIf the NETCONF s= erver supports :writable-running, all edits to configuration nodes in {+res= tconf}/data are performed in the running configuration datastore=E2=80=A6 O= therwise, if the device supports :candidate, all edits to configuration nod= es in {+restconf}/data are performed in the candidate configuration datasto= re.=E2=80=9D

=C2=A0

I have been reading through the mail archive on th= e relationship between :writable-running and :candidate (see excerpts below= ) and my understanding is as follows:

=C2=A0

For a NETCONF client to b= e able to update the configuration of a server, the server must support :wr= itable-running and/or :candidate.

A= NETCONF server can support both :writable-running and :candidate, indeed t= here appear to be some in the wild that do, but there is a measure of uneas= e about this, with the suggestion by some the combination should be depreca= ted.

=C2=A0

Based on the text from the draft (above) it would appear t= hat, should a NETCONF server support both capabilities, all RESTCONF edits = should be performed in the running configuration datastore. Is that conside= red the lesser of two evils, the other being that all RESTCONF edits should= be performed in the candidate configuration datastore, or was the possibil= ity overlooked? My gut feel is that it would be safer to use the candidate = configuration datastore and that the two paragraphs in the draft should be = the other way around, i.e. =E2=80=9CIf the NETCONF server supports :candida= te, all edits to configuration nodes in {+restconf}/data are performed in t= he candidate configuration datastore=E2=80=A6 Otherwise, if the device supp= orts :writable-running, all edits to configuration nodes in {+restconf}/dat= a are performed in the running configuration datastore.=E2=80=9D<= /u>

=C2=A0



This seems OK, but we do not support candid= ate and running as targets at the same time,
so I do not know how= it impacts the implementation to add this constraint.=C2=A0

=
I do not agree that the strict text in RFC 6241 actually support= s this editing mode.
If it does, then following the spec would le= ad to an implementation where
the candidate would clobber edits m= ade in running.=C2=A0 There is no text that seems
to support auto= matic update of candidate after the edit to running. There is certainly
no text that describes how edit conflicts in candidate are resolved.=


=C2=A0

<= p class=3D"MsoNormal">Jonathan

<= /u>=C2=A0



An= dy
=C2=A0

---<= /u>

=C2=A0

"Re: NETCONF modelled in UML"= Andy Bierman (Jun 01 2004) states: =E2=80=9CWe =E2=80=A6 thought we should= keep the #candidate and #writable-running capabilities independent=E2=80= =A6 maybe we should make these capabilities mutually exclusive.=E2=80=9D=

=C2=A0

"[Netconf] partial-lock feedback"= ; Phil Shafer (Nov 13 2008) states: =E2=80=9CThere's some logic tha= t says the intersection of boxes with :writable-running and :candidate is (= or should be) nil.=E2=80=9D

= =C2=A0

"Re: [N= etconf] partial-lock feedback" Balazs Lengyel (Nov 17 2008) states= : =E2=80=9CIt is not stated anywhere that you can't have candidate and = writable-running together.=E2=80=9D

=C2=A0

=E2= =80=9C[Netconf] :candidate vs :writable-running=E2=80=9D Tomasz Mikolaj= czyk (Nov 28 2008), quotes from http://www.netconfcentral.com/netconf_do= cs that: =E2=80=9CAgent platforms which support the :candidate capabili= ty usually do not also support the :writable-running=C2=A0 capability, sinc= e mixing direct edits to <running/>=C2=A0 would defeat the purpose of= using this scratchpad database to collect and validate changes before appl= ying them.=E2=80=9D This text persists, though =E2=80=9CAgent platforms=E2= =80=9D has been replaced with =E2=80=9CServer platforms=E2=80=9D.=

=C2=A0

=E2=80=9CRe: [Netconf] :candidate vs :writable-ru= nning=E2=80=9D Martin Bjorklund (Dec 01 2008) states: =E2=80=9CI don= 9;t know about others, but I do know that many (most?) of our customers hav= e both :candidate and :writable-running.=C2=A0 By having both, you give the= choice to the client application - either make sure you're alone and w= ork with the candidate or edit running directly. Some changes might be easi= er to just edit to running.=E2=80=9D

=C2=A0

=E2= =80=9CRe: [Netconf] lock/unlock on candidate=E2=80=9D Martin Bjorklund = (Dec 01 2008) states: =E2=80=9CThis is only an issue if the box supports :c= andidate and :writable-running.=E2=80=9D

=C2=A0

=E2=80=9CRe: [Netconf] issue with draft-ietf-netconf-partial-lock-07.= txt=E2=80=9D Kent Watsen (Mar 18 2009) states: =E2=80=9Ccan devices adv= ertize both :candidate and :writable-running?=C2=A0 - aren't those capa= bilities mutually exclusive?=E2=80=9D

=C2=A0

= =E2=80=9CRe: [Netconf] issue with draft-ietf-netconf-partial-lock-07.t= xt=E2=80=9D Martin Bjorklund (Mar 18 2009) states: =E2=80=9CThere's= nothing in 4741 that says that they are mutually exclusive. And I don'= t think they should be.=C2=A0 Some devices already support this combination= .=E2=80=9D

=C2=A0

=

=E2=80=9CRe: [Netconf] :writa= ble-running=E2=80=9D WashamFan (May 11 2009) states: =E2=80=9CGiven ses= sion A with :candidate and session B with :writable-running, it is benefici= al for session A to lock both <candidate> and <running> for con= sistency.=E2=80=9D

=C2=A0=

=E2=80=9CRe: [Netconf= ] Comments :draft-ietf-netconf-4741bis-01.txt=E2=80=9D Andy Bierma= n (Jul 25 2009) states: =E2=80=9Cevery agent MUST have exactly 1 database t= hat can be the target of an <edit-config> operation. (Writing to both= <candidate> and <running> does not work!) therefore the agent = MUST support the :candidate OR: writable-running capabilities, but not both= =E2=80=9D

=C2=A0

<= p class=3D"MsoNormal">=E2=80=9CRe: [Netconf] Comment= s :draft-ietf-netconf-4741bis-01.txt=E2=80=9D Phil Shafer (Jul 25 = 2009) states: =E2=80=9CI think Martin's code support this (both).=E2=80= =9D

=C2=A0

=E2=80=9CRe: [Netconf] Comments :dra= ft-ietf-netconf-4741bis-01.txt=E2=80=9D Martin Bjorklund (Jul 25 2= 009) states: =E2=80=9CYes it does.=C2=A0 I agree that other combinations ar= e more useful, but also this combination works=E2=80=A6 If you can copy fro= m candidate to url X, and from url X to running, why not copy from candidat= e to running directly?=C2=A0 (and IMO it means just that).=C2=A0 It only wo= rks if you have a candidate AND :writable-running of course.=E2=80=9D

=C2=A0

=E2=80=9CRe: [Netconf] Comments :draft-ietf-n= etconf-4741bis-01.txt=E2=80=9D Andy Bierman (Jul 25 2009) states: = =E2=80=9CI think the standard is poorly specified in this entire area.=E2= =80=9D

=C2=A0

=E2=80=9CRe: [Netconf] Comments := draft-ietf-netconf-4741bis-01.txt=E2=80=9D Martin Bjorklund (Jul 2= 6 2009) states: =E2=80=9C<commit> has more parameters than <copy-c= onfig>, so I think it must be kept.=C2=A0 Also, you cannot copy-config t= o running unless :writable-running is advertised, so <commit> is need= ed.=E2=80=9D

=C2=A0

=E2=80=9C[Netconf] :writabl= e-running and :candidate=E2=80=9D Andy Bierman (Aug 01 2009) states: = =E2=80=9CI asked (in email) how the :candidate and :writable-running capabi= lities can possibly be supported on the same agent. I never got an answer. = I do not understand how the candidate database stays in synch with the runn= ing database if user B can write to running while user A has the candidate = locked.=C2=A0 Also what happens to the edits made by user A when user B iss= ues a <commit>? Are the changes just made to running undone (they wer= e not in the candidate, so they must be undone, right?) Is this part of the= intended database architecture or not? And if user A does a copy-config fr= om a locked candidate to running? That is allowed of course.=E2=80=9D

=C2=A0

=E2=80=9CRe: [Netconf] Fw: Database Architect= ure OK or NOT-OK?=E2=80=9D Andy Bierman (Aug 03 2009) states: =E2=80=9C= IMO, :candidate and :writable-running do not work together.=C2=A0 They almo= st work together, and only go horribly wrong sometimes.=C2=A0 If that's= good enough for the NETCONF database architecture, then I guess there is n= othing to fix.=E2=80=9D

=C2= =A0

=E2=80=9CRe: [N= etconf] :writable-running and :candidate=E2=80=9D Phil Shafer (Aug 08 2= 009), in reply to Andy Bierman=E2=80=99s previous email comment =E2=80=9CI = asked (in email) how the :candidate and :writable-running capabilities can = possibly be supported on the same agent. I never got an answer.=E2=80=9D, s= tates: =E2=80=9CI believe I answered you, saying that tail-f's sw does = this.=E2=80=9D

=C2=A0=

=E2=80=9CRe: [Netconf] :w= ritable-running and :candidate=E2=80=9D Andy Bierman (Aug 08 2009) stat= es: =E2=80=9CI asked for clarifications on the standard, for specific corne= r-cases that IMO indicate that this combination is not supported by the sta= ndard. The thread reached a conclusion that even though any changes made to= running will get wiped-out as soon as the candidate is committed, this is = how the standard is intended to work. I can't imagine that an operator = or NMS developer using :writable-running would reach the same conclusion, b= ut that's their problem -- not an IETF standards problem, right?=E2=80= =9D

=C2=A0

=E2=80=9CRe: [Netconf] Fw: Database = Architecture OK or NOT-OK?=E2=80=9D Phil Shafer (Aug 10 2009) states: = =E2=80=9CI don't support :writable-running, just :candidate, and the in= teraction between the two isn't clear.=C2=A0 Martin, how does this work= on your sw?=E2=80=9D

=C2=A0=

=E2=80=9CRe: [Netc= onf] Fw: Database Architecture OK or NOT-OK?=E2=80=9D Martin Bjorklund = (Aug 11 2009) states: =E2=80=9CThere is no magic going on just because the = box is configured to use both :candidate and :writable-running.=C2=A0 Each = operation behaves the same regardless of the other capabilities.=C2=A0 So &= lt;discard-changes> resets candidate to the contents of running, and <= ;commit> replaces running with the contents of candidate. I agree that i= t is a burden on the client software to support all different combinations = of (startup, writable-running, candidate), and a server developer that has = a choice should carefully consider which combination to implement.=E2=80=9D=

=C2=A0

=E2=80=9CRe: [Netconf] Fw: Database A= rchitecture OK or NOT-OK?=E2=80=9D Juergen Schoenwaelder (Aug 11 2009) = states: =E2=80=9CThe candidate design does not work with :writeable-running= unless we find a more precise definition how to determine whether candidat= e is in a "good shape" or not.=E2=80=9D

=C2=A0

=E2=80=9CRe: [Netconf] NACM issue?=E2=80=9D Martin Bjorklun= d (Jan 11 2012) states =E2=80=9C=E2=80=A6only if :writable-running and :can= didate is advertised at the same time, and I think we have agreed that this= is a Bad Idea.=E2=80=9D

=C2= =A0

=E2=80=9CRe: [N= etconf] The <running> configuration datastore and :writable-running= =E2=80=9D Juergen Schoenwaelder (Aug 08 2013) states: =E2=80=9CImplemen= ting NETCONF read-only has obviously little value for real configuration ma= nagement. The reason why we have :writable-running and :candidate is that s= ome major vendors use very different models when it comes to making configu= ration changes and as such you will see implementations that either announc= e :writable-running or :candidate or :writable-running and :candidate toget= her.=E2=80=9D

=C2=A0<= /p>

=E2=80=9CRe: [Netconf] The= <running> configuration datastore and :writable-running=E2=80=9D= Andy Bierman (Aug 08 2013) states: =E2=80=9C:candidate and :writable-runni= ng together should be considered deprecated. This is a degenerate use-case = for concurrent transactions.=C2=A0 The WG should standardize this properly = at some point in the future, so clients can use a predictable standard tran= saction model.=E2=80=9D

=C2= =A0

=E2=80=9CRe: [N= etconf] <lock> in a server that supports both writable-running and ca= ndidate=E2=80=9D Andy Bierman (Jul 14 2016) states: =E2=80=9CThe reason= nobody implements :candidate and :writable-running together is because the= re is no way to synch the candidate if running has been changed underneath = it.=E2=80=9D

=C2=A0

=E2=80=9CRe: [Netconf] <= lock> in a server that supports both writable-running and candidate=E2= =80=9D Sterne, Jason (Nokia - CA) (Jul 14 2016) states: =E2=80=9CNokia = SR OS supports both writable-running and candidate.=C2=A0 And yes it is com= plex to manage.=C2=A0 The two datastores can=E2=80=99t be simply treated in= dependently and some locking/coherency mechanisms are needed between them.= =E2=80=9D


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

--001a1135b1ec1ee2b505444442fe-- From nobody Thu Dec 22 14:05:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D366E1295F9 for ; Thu, 22 Dec 2016 14:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.283 X-Spam-Level: X-Spam-Status: No, score=0.283 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FSL_HELO_BARE_IP_2=1.119, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=1.164] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9fUAL6pwIpI for ; Thu, 22 Dec 2016 14:05:51 -0800 (PST) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835661295F1 for ; Thu, 22 Dec 2016 14:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Transfer-Encoding:MIME-Version: Content-Type:In-Reply-To:References:Subject:Cc:To:From:Message-ID:Date: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=F9yoBQJv3OHuMrXnATl1rq/oR439u28JuKDz2dI5Y+U=; b=Mipp2QDjEqsdeQ+8GPOlWBT9Ld M81LUhqMqt8Cz0YwpPmJhbw0mZZM5S5JiZJkuzdDpxy3cv2EAo0MfSt1kzMPWskgpUDr/Dl+ZqjZ+ 4apcHEyXxWzIvRaHAqgZ99ZM8mEQH2xIvgjV+dX2extm4jOMFsPLWoBKAxtctPxQ7l5/ZtwPFTu+T dDUBTv4FVW1TDY/WxrzzN9GHVF4kv4M9u+kVhHsrwvgKJkf4/oPuoIV1qXlrwtJJ3BHqqruzajBeg D09MwjFxbUOm50vhoGFgfetlemnNnSrspeka79tYAFjWl3nzM12q0vNCMyqY4VN07Y1E4MYPRUU2p qXvnzasg==; Received: from [::1] (port=45638 helo=server.myfast.site) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cKBUi-0021rf-Ii; Thu, 22 Dec 2016 22:05:48 +0000 Received: from 84.92.116.209 ([84.92.116.209]) by server.myfast.site (Horde Framework) with HTTPS; Thu, 22 Dec 2016 22:05:48 +0000 Date: Thu, 22 Dec 2016 22:05:48 +0000 Message-ID: <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> From: jonathan@hansfords.net To: Andy Bierman References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 22:05:53 -0000 Quoting Andy Bierman : > Hi, > > On Thu, Dec 22, 2016 at 4:12 AM, Jonathan Hansford > wrote: > >> draft-ietf-netconf-restconf-18, page 13 states “If the NETCONF server >> supports :writable-running, all edits to configuration nodes in >> {+restconf}/data are performed in the running configuration datastore… >> Otherwise, if the device supports :candidate, all edits to configuration >> nodes in {+restconf}/data are performed in the candidate configuration >> datastore.†>> >> I have been reading through the mail archive on the relationship between >> :writable-running and :candidate (see excerpts below) and my understanding >> is as follows: >> >> For a NETCONF client to be able to update the configuration of a server, >> the server must support :writable-running and/or :candidate. >> >> A NETCONF server can support both :writable-running and :candidate, indeed >> there appear to be some in the wild that do, but there is a measure of >> unease about this, with the suggestion by some the combination should be >> deprecated. >> >> Based on the text from the draft (above) it would appear that, should a >> NETCONF server support both capabilities, all RESTCONF edits should be >> performed in the running configuration datastore. Is that considered the >> lesser of two evils, the other being that all RESTCONF edits should be >> performed in the candidate configuration datastore, or was the possibility >> overlooked? My gut feel is that it would be safer to use the candidate >> configuration datastore and that the two paragraphs in the draft should be >> the other way around, i.e. “If the NETCONF server supports :candidate, all >> edits to configuration nodes in {+restconf}/data are performed in the >> candidate configuration datastore… Otherwise, if the device supports >> :writable-running, all edits to configuration nodes in {+restconf}/data are >> performed in the running configuration datastore.†> > This seems OK, but we do not support candidate and running as targets at > the same time, > so I do not know how it impacts the implementation to add this constraint. > > I do not agree that the strict text in RFC 6241 actually supports this > editing mode. > If it does, then following the spec would lead to an implementation where > the candidate would clobber edits made in running. There is no text that > seems > to support automatic update of candidate after the edit to running. There > is certainly > no text that describes how edit conflicts in candidate are resolved. > Coming to RFC 6241 cold(ish), it is not immediately obvious that (a) for a server’s config to be editable it should support either the :writable-running or :candidate capability and (b) it is not recommended for a server to support both capabilities. Is there anywhere that best practice like this is captured? There are so many nuggets that have appeared in the mail list over time, some even with a measure of consensus(!), that it would be good to capture them for the uninitiated and non-gurus. > >> Jonathan > > Andy From nobody Fri Dec 23 02:45:51 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8F21297CE for ; Fri, 23 Dec 2016 02:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 39nVwxnNr6ya for ; Fri, 23 Dec 2016 02:45:47 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0118.outbound.protection.outlook.com [104.47.1.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E1F1299B7 for ; Fri, 23 Dec 2016 02:45:46 -0800 (PST) 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=BtiDiuV4SuDHQCpae7kHXqOgx+G7JUrWHw18vmpd1OY=; b=LqTAI3bgyGtTH2RhA0pXl5o8DjSHhlmuMrxqxLKT+SRNaU3Bvfg6rDWJHaFmQ1ALQvfer9t8xwMRkPfYIvRMVzDmwURYo1N2s5KUp86vQHXDysKL4A/6wzUk3pPPbJUfPmv/jPqTOD9PIulSpBVrqikZOzTBjhsK/xZk3QmPf3g= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by VI1PR0701MB3007.eurprd07.prod.outlook.com (10.173.72.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.5; Fri, 23 Dec 2016 10:45:44 +0000 Message-ID: <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> From: t.petch To: , Andy Bierman References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> Date: Fri, 23 Dec 2016 10:35:30 +0000 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: [81.135.210.62] X-ClientProxiedBy: AM4PR0101CA0046.eurprd01.prod.exchangelabs.com (10.165.22.142) To VI1PR0701MB3007.eurprd07.prod.outlook.com (10.173.72.149) X-MS-Office365-Filtering-Correlation-Id: b2ec34bf-4215-4020-b995-08d42b20d8fa X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0701MB3007; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 3:6ChSX1WpKfOJVQQfTXkigbt04KFi2OaHfQakyDSwvJE+PeOQhJ3URPyx6+2BQ9tbdZnc6oU9f4g9zVbrxo5aMQMbO8doFh5t1BRzo1Kac3bKiT4LulQiNLdl4dtvXOBR/EffXQnVEJTdEL+aTqyAmuFonjyWIU0U90GjKH0ptMmSOCGtunO71SRS0sorvOaMS1ePy5KL35YbLcbpuUMQfkmN+QJxcPDPMOwbRDPqvhXL7LJFUziJAN6Tt+U3jhxHkw3DKNni/7Fr1Ox3HuZB1Q==; 25:XoQAgq1Iw14U/CFM/q4ElL88tbWFbGneAaGIu9dXyJgrTcLNLnTML3zjp498P9G8UeDgJZi+RsfuywDfaSstd5PKfECktiCjeIg10Mu8GpmIQ14fwwEtda3cfpl+PAdOo5Ms1vwGLLx6/ennuRiRI6AJZf5x7bH+1G+VqsCDnFmdejOpY7LT4Czt6rBs7lZnB4oFl3kLSsfVxLgsJrWnCyR3pd2yVqvoNuJlvB0TjPB8/mDCvO96ST4yo3o0fC0v4H8SQtUbT8p1NYwQIwMBur1ugrcrkjbeuTnaMNuTAKe1oHN2vVU3abV7uGAURKeHT24zPgr/fairjYONGkSXzvpx2FynVA1vwNYACisOBTnR7lxaLWEE8VN60UiAAtja7YhCE9yJ1gtX/NgJT4+wxoZaGT5rsx4eEH07MCtcNgKEW1X6qjzxNaAEEPZ44oMrCaF0soLPx/yf3yyiueCtNg== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 31:Jwf7J33iA4KuahXh8PE9lOmRXoPlI6EffKwSQZJx1vcj4/Z32ZIqemsOSBiR1Qi+8NdGS9RXW9LJD3tD0+Dae+dseEqjUJOWXrZ7aaq7Ma6e6W47GrnsvCBaJkH4aNwIgLmVCLC5DEhSZN0gG6R8Zcw7vuLYSYIOYRGaFlxOkJjM8wyU2etnITcNk8rw6jUnVgApRx4gozG+uK3mV3MSQDwf1utJ+eUu7UEuFwGAfJXnaQ8bJw5IDIwtnGJ1k+4FRMQRCJiKubNJj4J/Z6YE6A== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:VI1PR0701MB3007; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3007; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 4:IYfor8GeH8qK0QqVzLcSAE0aEhoN9dXaTQIxM3ukqjIsSTc8LBC/6bjSNzAGxT/0NXPyi4MzWAmqQgPvB5fgkNOcGS28ugIwC7K/d6rYDKi4f+YAm7JCunxpT3wFsvX6shIn5mfEJAhwVlNAqz9o2F0sx9S7M74vkruLIFL2yB42JNfRiKWe7Uugvby5fRjQLgu7dW8cSbJWJ6AJkrEGqvtEpOmHYc8bRmrj/ab1P5xNEBhcITAATO9ldks4xaQbpfSqIKuznlFM+SXgLnxlZVSXinXVaspb9Yvhlrg1XO2h0i/KhWc/Fczvj4P58AJ7xBTdfNm4qu4hyj5tlCOpsFd+bc0KlPjwhgjklgc/VsvPQMRIyh8o3F0/s3aVEVmeegdOvW+Bw3EAUOObqnBVSexC0H0JcMW7VB1ZWHt9JIzc8gbS9QtEYxu4u7IhWOh26mwUOUiAUbvXVhfUBDWJ2tgY3zTB9/qQbENrstfnzd6PkFJpvEFZMeOZfuRdCfywGuYacUtbqYdbhdpHf/mdEkUcX9G5rgorFLp4t3UNUJK9hXq5n9jxyaA0VFwtOxu0WqNhaidJIUQSzG9xUYtygXBXJYLToEjyJKqD+Gd+d2ilYEfnmXV0Y7AYcFJh8ATWp6mfc6yvZOnwiWUG3fBMdQ== X-Forefront-PRVS: 016572D96D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(13464003)(199003)(377454003)(51444003)(189002)(4326007)(1556002)(86362001)(5820100001)(14496001)(76176999)(101416001)(81816999)(61296003)(42186005)(8676002)(50986999)(81686999)(106356001)(50466002)(92566002)(81156014)(62236002)(44716002)(50226002)(9686002)(81166006)(105586002)(5001770100001)(97736004)(189998001)(23676002)(305945005)(1456003)(3846002)(6496003)(66066001)(44736005)(229853002)(25786008)(38730400001)(68736007)(116806002)(6116002)(47776003)(4720700003)(6666003)(84392002)(5660300001)(2870700001)(2906002)(33646002)(6486002)(7736002)(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?MTtWSTFQUjA3MDFNQjMwMDc7MjM6dDQ0NUoxR0hhdnZCTkM2bisyZ2g0Q0Nr?= =?utf-8?B?aVk3dEZQK0REK3JMaW91by94Rk4xT1ZqTVJyVjVMR1hiTzRxODF4SDlLd2JG?= =?utf-8?B?cGxrcHE1M0ZtdFdnQ2dhZDg0eC9jN0NYRnlRRVBXcU9aUWtsRE8xdThPWDE2?= =?utf-8?B?RXB3QytKWmw3UTVSekNtNkpRMXExK2NTWlRrMnBnQzFNeU5jTkF1bkJIVTVo?= =?utf-8?B?MEUwcEJ1eVdDQUVFd0JJVE90NFcwQjJZRXNPenBnV0NjMWY1Nk9GR1FLajha?= =?utf-8?B?dStHS3gvVFFaVFh4K0w1Wm5uQWNJZDk5WVVMcFFkNmxNSmxWSXI3MnFmbnpD?= =?utf-8?B?T0hvSG5zOTV2bFkvTmovcFQxWU1aelNHa2wrVUE4eHM4R3R2aC9PN1FGZjFL?= =?utf-8?B?WXBUQ25xSktPZit3TExnR2JIb2libU5sS3o2cUFOTXpNMXQ0Q3JFSGo2MVZE?= =?utf-8?B?TnNieGRkdElhcWpLcGpiSjI1RmhYaGpNWkxBSFhjTnJqVU9xcHNjbExmSkZ5?= =?utf-8?B?eHNtVWRLZWpBMEYzRTFwYk9VQ3FnYUllbThTdXkzaVlnUCttd2pHb05TaUFk?= =?utf-8?B?MjByRGlYTEl2NXFLK3ZueDhJL3h0TzYyMCsvdi9mK25VNDVnYmVJOVlOZUcx?= =?utf-8?B?eW5sNllTN3lGTCs1Rnh1Um1VK2ZlRXNTNTRmSXdYOE9MRjBDWmVROUZjM1Mx?= =?utf-8?B?VWU4S2M1M1FrSG5yUFA2ZjdiSVJOQzhQek9aQWlPMG9HS1JLVUhLYjJrU2J4?= =?utf-8?B?NzZQdXB3TE1QNEFWUEtXREVYZEt4dDNMVWpLb2dYYzJTK1hHTFpQeStYa2Zz?= =?utf-8?B?YnNtc1ZqajV4Rkg4ZTNMTitJS1JFVy83LzVpZWNWV0gwK1lIV2hjTGYwdUZ4?= =?utf-8?B?aU1rVEYxdUdwR01pNmo5ZzlzMzRBNEpuUUpRek56VFNZcGczT3djRXcwL25O?= =?utf-8?B?eHROS3NleTEraWUyaEJTVkljRzFuT0VZTjE5eGxCVmFjMWxLMmd2S3c3YUpT?= =?utf-8?B?cDgzdTUzQk93R0twVmZCN3dpRkU2L1E0WWFzTlQ3T1BMb0lITGY3OWFHU0p4?= =?utf-8?B?VXFHa091cnAvNGJyOHZZRk1nS0pIWnJRTmwxNVdWWkRha1ltMkdmZ0FFYXBU?= =?utf-8?B?OStnSHUvY1FBVWhRVHlHdWdFL0hhTUlrMHhYNU1sYTk1R1g0YVVJRGRkUDJm?= =?utf-8?B?RVNmbnZ0QytIcWllVURkaitFSG84MEdEc1pubm81UzgvaWw2Z1RTWFdhNld6?= =?utf-8?B?N0k5YzU3N2J1Z1BVTE5NU1NmTG56dWdVRWFsNDBaUUZaV3Y2RzRmSndiaVpp?= =?utf-8?B?c01ZY1IvRXM3MGZYcnU0WE90TE40YUVkakFzR0laNCtwZHhCUURDbHYwSXpE?= =?utf-8?B?YjJOMkNyOWhPWU9LUmpGYml1ZndZdWdHb3pMTUpGbXMxYnkyNldsYkU0UFNh?= =?utf-8?B?TG1PWDVIQlQwZDhBc2g1ZkNCYjdDK0k5S0szK1lTV2ZTNCsvVUI4UHNkdW84?= =?utf-8?B?U0dmNEZlSmxHSHBEbkdJNzJ3T2ZUSEJ1cUk5MGNCdWxrOEI3Z29RV2xqRFho?= =?utf-8?B?ZGxta21GMW93SE82L090T3ZoUktuS2JWbTFHUXFTNFVHZGFtbi80WUY4Tzla?= =?utf-8?B?NlNObSt4cUpRN0drcG1wangxZ3UzbDZ5TGNBcnIvYngwYlVCT05sMWdSUTVZ?= =?utf-8?B?ejRDYmdUWExTdlphcHl5NU5YN0xKK3RtbXhwaG5OVm9hS2dyS1lpa2ZuL0k0?= =?utf-8?B?eTB1eEdVTDRCcDdMWGp5Nnk3dG1yWS9pVU5oTU50N3JTL3FmZWVIS2ZqaHF2?= =?utf-8?B?aFRKeTE5eGlNOWdvMU83KzU3MXI2QnkrWjZGS0dvNUFlUGRoYkcxaFVwZFVv?= =?utf-8?B?S29HMVpDNVFxamgwamZIVTFqbnRyTWtlNXdEQkU1MUZTN2FzWDZDd2Y4ekZU?= =?utf-8?B?MlphZklLUlkyNGc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 6:uPEy+ER8Lg9du7RKecpT2Ems+QpKNOzOEQXv5/wxKz2LF3KzvYuehV7BaosCjJYtZItqwRncUV15xaxwScMHBurGQSoe06hF/TChBm4zFE2Nd3t8LCfrD1sWwV4hXg2uV2GAZdHo5GRKsnY2BrNxRiVSNkkEW2dS+ElH//fACqeLDXBCAHV2zN28wSPo922uovTQi40Ysp8nfoqri+7o2HbPVj7yIUah1X2NeJGRocdAmahQ6qeUHeYCN8cftGYxd1MqxP2yfGkZrC27r1LOP+r6uqbK3E57W2+3po/a6cOy53Vc0aXlvxzbQHw+24l/BRjMsEK5k+6fYfROncX4GxO2YCQECT4xmBVgBX38T06b+dufvYA6MvNt3PpwGf8ULyLXOYS0wo98GZtNyzXW0656fNP1s2w5hrT4d9C64G0=; 5:UNIlLxDlmpPYsrnziHuLtLnfVinSmOG1ivbIldUhH3vma6wOCzeVhKdW8SiHGRxEw+wSBT7jhwbAB8vSH67Kwr0RVKoZnZD57kGJF/QjAq0dRvBZxS0TNGZ6pIT3iHxlOcqYyNW/bv9q2FpKTZhkiw==; 24:3lVCwqA3GxWVkjiYuEEVSV/iFFM+e1i99sAkyPuP13VnrH1ck+TrmD1ZIQ2tMhEm9RKX/k4v1kbnI0YLcN+ftzjqZ9zfhN0KxeJO6oT0ayc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 7:NxWsgfdKp6kdFZqE3cmQ8fI5ENUrRge/6MpgDv4NNNodsDvYL9IrVfslH0QB4CffrcOQ2pPLBiUp1AQKMOSdsRus/AxmFsDC+Y4umx1UllAeSimq+DT6wfmwGicH4u/cR57u9R9BtDjkWOcJLm2y1rRefizX46SJpnZHl6kJQwNljrN5lM6/dhr5JFbKTSjgtfaUixdAl1gU4olBI6UN/W2ZN6fNGF6Ox9PjEj9WxIM/NA4mYlq043gm7bpi4Mu3C3e2ZT1DvOsMiRGfjJ2BzADiQCD1SLrX8JUxFmuGCi2/JwLbpz4Qa+xuGSB729xTnw+3N3kWZevywcS657G8jqm6395l+XIx6ugKi4NVOwjhLye/rzdaVgW7Ha/q4Vp/HT0fHAMgP5Cn2aq/brS6zUIrURGefw/H66755tCLNtewMixLDTmZHcP4h+8XJnFBzqiVQh0lEfDuvpcMk9YnJA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Dec 2016 10:45:44.1487 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3007 Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 10:45:50 -0000 ---- Original Message ----- From: To: "Andy Bierman" Cc: "Netconf" Sent: Thursday, December 22, 2016 10:05 PM > > Quoting Andy Bierman : > > > On Thu, Dec 22, 2016 at 4:12 AM, Jonathan Hansford > > > >> draft-ietf-netconf-restconf-18, page 13 states “If the NETCONF server > >> supports :writable-running, all edits to configuration nodes in > >> {+restconf}/data are performed in the running configuration datastore… > >> Otherwise, if the device supports :candidate, all edits to configuration > >> nodes in {+restconf}/data are performed in the candidate configuration > >> datastore.†> >> > >> I have been reading through the mail archive on the relationship between > >> :writable-running and :candidate (see excerpts below) and my understanding > >> is as follows: > >> > >> For a NETCONF client to be able to update the configuration of a server, > >> the server must support :writable-running and/or :candidate. > >> > >> A NETCONF server can support both :writable-running and :candidate, indeed > >> there appear to be some in the wild that do, but there is a measure of > >> unease about this, with the suggestion by some the combination should be > >> deprecated. > >> > >> Based on the text from the draft (above) it would appear that, should a > >> NETCONF server support both capabilities, all RESTCONF edits should be > >> performed in the running configuration datastore. Is that considered the > >> lesser of two evils, the other being that all RESTCONF edits should be > >> performed in the candidate configuration datastore, or was the possibility > >> overlooked? My gut feel is that it would be safer to use the candidate > >> configuration datastore and that the two paragraphs in the draft should be > >> the other way around, i.e. “If the NETCONF server supports :candidate, all > >> edits to configuration nodes in {+restconf}/data are performed in the > >> candidate configuration datastore… Otherwise, if the device supports > >> :writable-running, all edits to configuration nodes in {+restconf}/data are > >> performed in the running configuration datastore.†> > > > This seems OK, but we do not support candidate and running as targets at > > the same time, > > so I do not know how it impacts the implementation to add this constraint. > > > > I do not agree that the strict text in RFC 6241 actually supports this > > editing mode. > > If it does, then following the spec would lead to an implementation where > > the candidate would clobber edits made in running. There is no text that > > seems > > to support automatic update of candidate after the edit to running. There > > is certainly > > no text that describes how edit conflicts in candidate are resolved. > > > > Coming to RFC 6241 cold(ish), it is not immediately obvious that (a) > for a server’s config to be editable it should support either the > :writable-running or :candidate capability and (b) it is not > recommended for a server to support both capabilities. Is there > anywhere that best practice like this is captured? There are so many > nuggets that have appeared in the mail list over time, some even with > a measure of consensus(!), that it would be good to capture them for > the uninitiated and non-gurus. Yes, I think that this work has three parts, of which the protocol is well-defined in RFC6241 and the DDL is well-defined in RFC6020 and the third part is not well-defined:-) You will find a little more in RFC6244 but, for me, that was a missed opportunity. However, we have a fresh opportunity with draft-ietf-netmod-revised-datastores-00 which, since we have no good definition (IMHO) of what is being revised, needs to make that clear. Which it goes some way towards doing, so I suggest you go to that I-D cold-ish and raise anything that you think has been omitted. We almost need a third mailing list to discuss these matters since previous discusssions have floated between the Netconf and netmod lists Tom Petch > >> Jonathan > > > > Andy From nobody Fri Dec 23 03:40:39 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AFA1297E4 for ; Fri, 23 Dec 2016 03:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.283 X-Spam-Level: X-Spam-Status: No, score=0.283 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FSL_HELO_BARE_IP_2=1.119, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=1.164] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqAsbzHYPo1w for ; Fri, 23 Dec 2016 03:40:36 -0800 (PST) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ADF81297E8 for ; Fri, 23 Dec 2016 03:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Transfer-Encoding:MIME-Version: Content-Type:In-Reply-To:References:Subject:Cc:To:From:Message-ID:Date: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=2MPpBQ812iCBL3tsSlxXoPhOozNjQVM7sooceLG4WNU=; b=JE6RCZ+r9FJgYk3oHWG7EOk5Bz ZMe9PBvqYWYrahQzvC9k+Ctc3Hbiqwm1wGfP6PPZMGpmWVCisYu8VhbYdZYJqeSmeJRqjgdXB+vMd JWmqZwjC5ab2Tl4JkLr4u18otFZcp9/c9lbQ1HTjS5Sk59meLk66Dfm0tcf7zabsb+b8cWt2mVT+Y OaafauO48ieA2anHWHQ8hSuYNTO5UhgP8KO3P6RL1YEKNorido2Nqy4jMMt63YSxFVJGG7VzfEO2U MVTAuWWtOs5hUCozoXOPQ90ze2RuWGjWX6yAngHJOhzafNJr3WF34ZRTAvjka4tYwPovS6BaVLtXk 6z20eapA==; Received: from [::1] (port=43563 helo=server.myfast.site) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cKODB-000su2-JX; Fri, 23 Dec 2016 11:40:33 +0000 Received: from 84.92.116.209 ([84.92.116.209]) by server.myfast.site (Horde Framework) with HTTPS; Fri, 23 Dec 2016 11:40:33 +0000 Date: Fri, 23 Dec 2016 11:40:33 +0000 Message-ID: <20161223114033.Horde.4e5vAs_n2nvmbKyDaP7s6zT@server.myfast.site> From: Jonathan Hansford To: "t.petch" References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> In-Reply-To: <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 11:40:38 -0000 Quoting "t.petch" : > ---- Original Message ----- > From: > To: "Andy Bierman" > Cc: "Netconf" > Sent: Thursday, December 22, 2016 10:05 PM >> >> Quoting Andy Bierman : >> >>> On Thu, Dec 22, 2016 at 4:12 AM, Jonathan Hansford >>> >>>> draft-ietf-netconf-restconf-18, page 13 states “If the NETCONF >>>> server supports :writable-running, all edits to configuration >>>> nodes in {+restconf}/data are performed in the running >>>> configuration datastore… Otherwise, if the device supports >>>> :candidate, all edits to configuration nodes in {+restconf}/data >>>> are performed in the candidate configuration datastore.†>>>> >>>> I have been reading through the mail archive on the relationship >>>> between :writable-running and :candidate ... and my >>>> understanding is as follows: >>>> >>>> For a NETCONF client to be able to update the configuration of a >>>> server, the server must support :writable-running and/or >>>> :candidate. >>>> >>>> A NETCONF server can support both :writable-running and >>>> :candidate, indeed there appear to be some in the wild that do, >>>> but there is a measure of unease about this, with the suggestion >>>> by some the combination should be deprecated. >>>> >>>> Based on the text from the draft (above) it would appear that, >>>> should a NETCONF server support both capabilities, all RESTCONF >>>> edits should be performed in the running configuration >>>> datastore. Is that considered the lesser of two evils, the >>>> other being that all RESTCONF edits should be performed in the >>>> candidate configuration datastore, or was the possibility >>>> overlooked? My gut feel is that it would be safer to use the >>>> candidate configuration datastore and that the two paragraphs >>>> in the draft should be the other way around, i.e. “If the >>>> NETCONF server supports :candidate, all edits to configuration >>>> nodes in {+restconf}/data are performed in the candidate >>>> configuration datastore… Otherwise, if the device supports >>>> :writable-running, all edits to configuration nodes in >>>> {+restconf}/data are performed in the running configuration >>>> datastore.†>>> >>> This seems OK, but we do not support candidate and running as >>> targets at the same time, so I do not know how it impacts the >>> implementation to add this constraint. >>> >>> I do not agree that the strict text in RFC 6241 actually supports >>> this editing mode. If it does, then following the spec would >>> lead to an implementation where the candidate would clobber >>> edits made in running. There is no text that seems to support >>> automatic update of candidate after the edit to running. There >>> is certainly no text that describes how edit conflicts in >>> candidate are resolved. >>> >> >> Coming to RFC 6241 cold(ish), it is not immediately obvious that >> (a) for a server’s config to be editable it should support either >> the :writable-running or :candidate capability and (b) it is not >> recommended for a server to support both capabilities. Is there >> anywhere that best practice like this is captured? There are so >> many nuggets that have appeared in the mail list over time, some >> even with a measure of consensus(!), that it would be good to >> capture them for the uninitiated and non-gurus. > > > > Yes, I think that this work has three parts, of which the protocol > is well-defined in RFC6241 and the DDL is well-defined in RFC6020 > and the third part is not well-defined:-) > > You will find a little more in RFC6244 but, for me, that was a > missed opportunity. > > However, we have a fresh opportunity with > draft-ietf-netmod-revised-datastores-00 > which, since we have no good definition (IMHO) of what is being > revised, needs to make that clear. Which it goes some way towards > doing, so I suggest you go to that I-D cold-ish and raise anything > that you think has been omitted. > Though some best practice could be captured in the revised datastores draft, this specific example concerns the interaction of NETCONF capabilities with both the datastores and RESTCONF. Is the revised datastores draft the best place to address this? Jonathan > > We almost need a third mailing list to discuss these matters since > previous discusssions have floated between the Netconf and netmod > lists > > Tom Petch > >>>> Jonathan >>> >>> Andy From nobody Fri Dec 23 05:57:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7AE1294BC for ; Fri, 23 Dec 2016 05:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 kBgDqwA574wG for ; Fri, 23 Dec 2016 05:57:55 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EBA4C129471 for ; Fri, 23 Dec 2016 05:57:54 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 792901CC009F; Fri, 23 Dec 2016 14:57:55 +0100 (CET) From: Ladislav Lhotka To: "t.petch" , jonathan@hansfords.net, Andy Bierman In-Reply-To: <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> Date: Fri, 23 Dec 2016 14:57:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 13:57:57 -0000 "t.petch" writes: > ---- Original Message ----- > From: > To: "Andy Bierman" > Cc: "Netconf" > Sent: Thursday, December 22, 2016 10:05 PM >> >> Quoting Andy Bierman : >> >> > On Thu, Dec 22, 2016 at 4:12 AM, Jonathan Hansford >> > >> >> draft-ietf-netconf-restconf-18, page 13 states =E2=80=9CIf the NETCONF > server >> >> supports :writable-running, all edits to configuration nodes in >> >> {+restconf}/data are performed in the running configuration > datastore=E2=80=A6 >> >> Otherwise, if the device supports :candidate, all edits to > configuration >> >> nodes in {+restconf}/data are performed in the candidate > configuration >> >> datastore.=E2=80=9D >> >> >> >> I have been reading through the mail archive on the relationship > between >> >> :writable-running and :candidate (see excerpts below) and my > understanding >> >> is as follows: >> >> >> >> For a NETCONF client to be able to update the configuration of a > server, >> >> the server must support :writable-running and/or :candidate. >> >> >> >> A NETCONF server can support both :writable-running and :candidate, > indeed >> >> there appear to be some in the wild that do, but there is a measure > of >> >> unease about this, with the suggestion by some the combination > should be >> >> deprecated. >> >> >> >> Based on the text from the draft (above) it would appear that, > should a >> >> NETCONF server support both capabilities, all RESTCONF edits should > be >> >> performed in the running configuration datastore. Is that > considered the >> >> lesser of two evils, the other being that all RESTCONF edits should > be >> >> performed in the candidate configuration datastore, or was the > possibility >> >> overlooked? My gut feel is that it would be safer to use the > candidate >> >> configuration datastore and that the two paragraphs in the draft > should be >> >> the other way around, i.e. =E2=80=9CIf the NETCONF server supports > :candidate, all >> >> edits to configuration nodes in {+restconf}/data are performed in > the >> >> candidate configuration datastore=E2=80=A6 Otherwise, if the device > supports >> >> :writable-running, all edits to configuration nodes in > {+restconf}/data are >> >> performed in the running configuration datastore.=E2=80=9D >> > >> > This seems OK, but we do not support candidate and running as > targets at >> > the same time, >> > so I do not know how it impacts the implementation to add this > constraint. >> > >> > I do not agree that the strict text in RFC 6241 actually supports > this >> > editing mode. >> > If it does, then following the spec would lead to an implementation > where >> > the candidate would clobber edits made in running. There is no text > that >> > seems >> > to support automatic update of candidate after the edit to running. > There >> > is certainly >> > no text that describes how edit conflicts in candidate are resolved. >> > >> >> Coming to RFC 6241 cold(ish), it is not immediately obvious that (a) >> for a server=E2=80=99s config to be editable it should support either the >> :writable-running or :candidate capability and (b) it is not >> recommended for a server to support both capabilities. Is there >> anywhere that best practice like this is captured? There are so many >> nuggets that have appeared in the mail list over time, some even with >> a measure of consensus(!), that it would be good to capture them for >> the uninitiated and non-gurus. > > > > Yes, I think that this work has three parts, of which the protocol is > well-defined in RFC6241 and the DDL is well-defined in RFC6020 and the > third part is not well-defined:-) Both 6241 and 6020/7950 address the third part to some extent but the result isn't very clear and consistent. In fact, 6020/7950 also "patches" the NETCONF protocol, e.g. with "insert" and "value" attributes. In retrospect, the status quo is quite understandable but eventually it would be extremely useful to have clean and separate specifications of all three parts. > > You will find a little more in RFC6244 but, for me, that was a missed > opportunity. > > However, we have a fresh opportunity with > draft-ietf-netmod-revised-datastores-00 > which, since we have no good definition (IMHO) of what is being revised, > needs to make that clear. Which it goes some way towards doing, so I > suggest you go to that I-D cold-ish and raise anything that you think > has been omitted. I agree and, moreover, I think that it makes sense to allow for multiple datastore architectures because there is nothing like one size fits all: what's good for big routers doesn't work for SOHO devices or IoT. We can take an analogy from WWW: whilst the protocol (HTTP) and content rules (HTML) are now pretty standard, there are zillions of web application architectures. Perhaps our aim could be to have one DDL (YANG), several protocols (NETCONF, RESTCONF, CoAP, ...) and any number of datastore/application architectures. That's why I also support Mehmet's proposal to make the datastore document infomational. Lada > > We almost need a third mailing list to discuss these matters since > previous discusssions have floated between the Netconf and netmod lists > > Tom Petch > >> >> Jonathan >> > >> > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Dec 23 08:41:07 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC6D12994F for ; Fri, 23 Dec 2016 08:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PL74yMC8WCpq for ; Fri, 23 Dec 2016 08:41:04 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5741294DF for ; Fri, 23 Dec 2016 08:41:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2A3F539; Fri, 23 Dec 2016 17:41:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zQDmojOupQPL; Fri, 23 Dec 2016 17:40:58 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 Dec 2016 17:41:01 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E420D20080; Fri, 23 Dec 2016 17:41:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nDn5UHvPUn6W; Fri, 23 Dec 2016 17:41:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B0EA2007F; Fri, 23 Dec 2016 17:41:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 521FE3DDB7FB; Fri, 23 Dec 2016 17:41:01 +0100 (CET) Date: Fri, 23 Dec 2016 17:41:01 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161223164101.GA5986@elstar.local> Mail-Followup-To: Ladislav Lhotka , "t.petch" , jonathan@hansfords.net, Andy Bierman , Netconf References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 16:41:06 -0000 On Fri, Dec 23, 2016 at 02:57:53PM +0100, Ladislav Lhotka wrote: > > Perhaps our aim could be to have one DDL (YANG), several protocols > (NETCONF, RESTCONF, CoAP, ...) and any number of datastore/application > architectures. That's why I also support Mehmet's proposal to make the > datastore document infomational. > For me, datastores are an architectural concept binding the protocols and the data modeling language together. As we understand better now, the datastore model also impacts how you write data models. /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 Dec 24 05:09:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C82128824 for ; Sat, 24 Dec 2016 05:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 JYGUfgi95gHP for ; Sat, 24 Dec 2016 05:09:55 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0105.outbound.protection.outlook.com [104.47.2.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006B9120727 for ; Sat, 24 Dec 2016 05:09:54 -0800 (PST) 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=G1P6m8vpQmaK1KEUi68Lxbb7y54Q16wLZPBnrz5UjtI=; b=QKgNFEwmufaXyOSvjfaKo9DPYvSoLjc6QFYBvDSJuItHxFkslWJQdrAeHyTpsttqKG1YxRV0JbC4zeMW0Kupi62hkcTMP1gGHEHOabTjWsduWOgwRSFK6Id3aFSXV2IcSWJ4fwX8TG4p/Nn4/7BhOlbrWp7Bg0wTGBrJDgW6yNw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by VI1PR0701MB3008.eurprd07.prod.outlook.com (10.173.72.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.5; Sat, 24 Dec 2016 13:09:51 +0000 Message-ID: <018601d25de6$d657b860$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , Ladislav Lhotka References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> Date: Sat, 24 Dec 2016 13:08:22 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.135.210.62] X-ClientProxiedBy: DB6P18901CA0020.EURP189.PROD.OUTLOOK.COM (10.169.208.158) To VI1PR0701MB3008.eurprd07.prod.outlook.com (10.173.72.150) X-MS-Office365-Filtering-Correlation-Id: aceb57cc-3fa0-4a24-8dd2-08d42bfe25a3 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0701MB3008; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 3:WB5wzZsjF/+/QXVye60/VHkWFtpKQ66/6/pgTiI8eB+zKntCxijHS5I9gUljd7Q1HJ5ttfwpdf7PRgunL4ZXL5ZPK6+1GnFmDDgxNogQUu7XnzpzO1jTIXCAZzwDnZisQAhN+csPmYCvHGffBCZPZCjLu6lktWE1rmhnUp7Gcx0T6aSlSuY9/ae820AGP6hTLAiHXmUdL6plsPt8BJz3GzryaSH0FVvn9Hbj7lZBlf3o+1C9IkuvDj2nSn5GxRfynsh4K2pkns+QoAhnQ0GICg==; 25:mxrdSieL0w7rgSW1uvgzWSNek7BM96lF+pbFN+9XnFb/uNWr3KOENJ6PBudf68VqxZPAnvDHcETGPpAD7/6jgPuo+KXgub11aFBTBPxCTrOWG9kFYzKfCC+QuXILbv54aFYJNHbN2NfmnkVR+auob58koHfvT3Bdl3LEIyXU0cxHH5CkKDgsbKJt5Ixi7ptojTFqfRtjRdSNxIk7UFoke4iQC6N84j4UM2VLlmbRwWtbeg0ejTk54PYAQ3YFzVgTE0PI2lVrWvENJ9wM8b3br0N6HXeMLrc++gVev7CAz4GhBd4G3Jhp8wR0TVP88MxcGAU2U2zrX7Cr550yjAoE1Ka4G/md2HouSo1BTLubXyvVwLNmVPE2laG5rtdMcygkNQfdSsdQF9A1hyyQJg34un/weFpy96KGc3ASPmB/84aaHy81CRu1/sMVGMyOGWSUwJT2sUFNMpypSXTN0xlmlw== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 31:BwXZ3SJuSwb/6fWHQklye8mKnwi+8fXvYrEpTTtawJ+CeTdldPkuTOSbuBWuxzHNbXGqfUAh1VI6VlUY8bCvMAeK81psHNlKylc2T06ErIwPAvIH7FDdcvmx9XL1piCduMndBEsLR66v3UZIlk7mIPtNxapZAruzHc0t066WDhOv8sStrRHJjJkxYsnx/c4OZcVTzI/yTAwfZ0dkPXDoc+6BrGeGmFITMtnWA8Q+644U0OUptLRRBiJlkV73nd36uWZBLOy6jOkDJ3pUwjX5xQ==; 4:TFfi7ORIYQ3jyAm33IX2IClg+03gtUoq17SBcu8BXKW9qfeuRPmAgmveI/Pp1oY6CMKh5R3+SQYPdwW9ijyFwMJSk91LTCo8lXLzNEQO41y+g2YZNUsdamejv8qOO5LNDJrNY9q8XpZMvEPzSn/83T34TLXa4lx5Vao7GMEO5Twmr4eync8Zozcl5H+mJqq/re5XducptSjuey+urX5IHVqs4sLxptyl3HH5p48b3sjg31WK3DGVCU7w+4t0gYpKONUhqq/+bl1KApO02Tsw6JBP4AwIH1qtecT3465TAgLvbk42ZVnofnCqDG3TlyGmbVql3vMnmtCfOC2FdcWk2ITVwZVbRZe5ABo38gZlRyIgaQVKhbXb+bn6bT/7ofg/+GpbXRvcb1tksMYBeWV8uVGNpVweaL19PcP1vcAG99nkLndSns44VZn+KE4QfGCl3Q++3+sX2Po7SrdH5jZs5zxZA7E/+M2tqLHAhW25ZpXhm2mCYI1NkzTou0Kmj56sUJIrxKhulGh4LNis2xuulmfir9D9ouCK00wGQe3g9HxqtU+ZnzvatI0tZqIUjLb8DbC0wbRAvIMGumcFEjsQvA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:VI1PR0701MB3008; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3008; X-Forefront-PRVS: 0166B75B74 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(189002)(13464003)(24454002)(199003)(377454003)(189998001)(14496001)(97736004)(5001770100001)(50226002)(44716002)(62236002)(1556002)(230700001)(47776003)(81156014)(81166006)(9686002)(66066001)(8676002)(68736007)(86362001)(50466002)(84392002)(38730400001)(23756003)(4326007)(105586002)(106356001)(25786008)(229853002)(6496003)(6486002)(44736005)(561944003)(50986999)(92566002)(1456003)(81816999)(61296003)(3846002)(42186005)(6116002)(76176999)(81686999)(305945005)(7736002)(6666003)(101416001)(2906002)(4720700003)(93886004)(33646002)(116806002)(5660300001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3008; 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; VI1PR0701MB3008; 23:hoP09YyhaQ+qlVtLL7XEI+NBTz9NBrao3/P7B?= =?iso-8859-1?Q?uoRTbTfkmYJs4eVe0CjptJkGJJbh8HofBMUy8rNX5KZ15z4e9ZxxqH3eIi?= =?iso-8859-1?Q?+nI2UhYfx1X2WwFqTYtsGGXtD4I9HhOFgRUZLDRRhK1pZ3liF6RwcLfcN8?= =?iso-8859-1?Q?aag5r1lpfz8n92hkR7BBs2Hu0osXqi6gFsTduTlT5IHgJno8DeDhjk1AcF?= =?iso-8859-1?Q?R6XaoBnwtEp63wTs2KEy9r3DnJPxnMwM/goD63L9FUBP0fVJJxTkX5PeI2?= =?iso-8859-1?Q?8IsOJ1+vg93KnpQzMZBj6Gk5JOs0UANDV3FQ3GD4yZz99sQbvD2NAzkEFB?= =?iso-8859-1?Q?xVmrdmnCntBvutZmcxd7PwW9R3AgVT61Jh70ze2swuKWQhKfneXuoI59hY?= =?iso-8859-1?Q?CpID/wwjUzNMAUqgBmQIXmIOWZq3HeIRnf+C0faEXKbwon1ehx8/LU1ypY?= =?iso-8859-1?Q?xl1lIo7calayoMKiEXI2cZ3d11eU4zucaxf6/hizqEJrOds/4B/D6EzBC5?= =?iso-8859-1?Q?qOYNceDDr1O7+ptYuJE87abY+tFz04r2e2KN1XgtzRVRmfdH+/JdHALpY7?= =?iso-8859-1?Q?trbGLYAsSkHkV0N1H8BJaUt1QAQgO82gSxjZrFcHE3/pLrU6NrG8nCTNtu?= =?iso-8859-1?Q?tQrrzYjc5UcqvcsTD0lAtTAzV9FXRYx5JHaBq0xpet84NHEyILtrF26RzL?= =?iso-8859-1?Q?0juVudqQG/jzLxsX+LjGb12WzFp3/Dio/zqPYclYAljaOx2OnOCMAMORwq?= =?iso-8859-1?Q?VA0ILik2kiPhrglaqplgC+gIF+izlzoloEkTndO5WPcXoEzJOq7Y+9zyQT?= =?iso-8859-1?Q?D9laljaTmJHNzuoLPYBdX+Iy4FcXYfGkxr2ILsKIfqawOU/mr4lhYF4AZ2?= =?iso-8859-1?Q?zvdmJixkVd3UcVRuERaAsJoOuSS0qSWduaBv2Nl3RMZ2UEwALBAS0JZ24y?= =?iso-8859-1?Q?TXrsNrbKdjNJInzWuukHFQ7nFy5MynHDcvFZ2sfjTOlr96+HU0nHxkEfHY?= =?iso-8859-1?Q?nzMaipmv5fwk500MI6d7uJR/O7fpWzhY49txNnvtEraIIugxDGTkjZ8WLX?= =?iso-8859-1?Q?7AA01NB/PI7FOhBGYurc9f6FAd3zkjmCvMfiu/UJDzNlsuu5mIFSyF8BQ4?= =?iso-8859-1?Q?jGuswK+dzzMT+/tdTw/Do6W3fY6JD6UdlCpJGSglqwx9qI2Yj8FovPZrAM?= =?iso-8859-1?Q?+RnBbuNCqSmLHpTdk8yja5mRVipvqixorNQ/aHrizd9n77AjTE2x6T9Zrf?= =?iso-8859-1?Q?totcbsTAtmD+R0qkDcO16VeXKUGcjw+qhc5yWbLjmySUAPXvi9+OC3/bs8?= =?iso-8859-1?Q?H9Vy3BErR+n5OF5jKxHGbXpRM+Uv7tsh+yjVE8yvo5A4GcgRHHpBlIecBr?= =?iso-8859-1?Q?G+3E5EDZDtNrFEy6jyWm2uPZh0nuZmMBviX20oJD2IBjlfFMslIO0qmU40?= =?iso-8859-1?Q?3gWSAoYMY7UygB4XVg/q0zMN0oVZg2iH8/iMbrsVLmMVHlFxbngecX4H4q?= =?iso-8859-1?Q?78pbFnn2A3FHsR6ooJ62mo=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 6:AUlHkAPTf7wN/fvPpfNKl/9kfJA/o0JpZJ2nEOG04rxJOYYDRlrWo1LMBFCj1waFD63+/wzyc0IuzmHhSAtzJjif//toFxQkSXPjYYJfLBx8A5cRDxuP9T53elJT+CoxN4bE5zv1t3wXO2zIFEi4IkCuhrAOCXmIp5YyUcQuZc48CIsuJl8xuXQtUOgxd68UGxceDs4LSWr6d8KG+zu/3+gX0Iq9P8LVNTA+BMldUoS4SJky9hASQ6g0FmV40bpCjrKKHOB/lfCCdGQ3QCBJCKMzonenur/PfnK0iQubI5EtPEB4+Xoi2xa8dLnvNaV6tJQCkWWpMK1TK8csgOGF50j1Z9kd1hh231pIg1F/7uKBqeR5ZQPqaSNgldk/SjoTZDHUS53BAMx9lIh8xQqWQYv3g66bgg6BLR0b89XUepM=; 5:7bYq3d9X7nzzcqkI/GGZ0aOJCZLDeVZ77srmLoCnDiAprle+d5GlD2CShXBmLcGks0Ol9IOSTx7LZx3W0eYYmw3FhW8EhrhcLGDTDuyrRhbpygZhHACwPm7tDWaAhlh50Sy8S2ax3DnPwQA4XNXEwQ==; 24:3y/OwmbXh+NONwF9w0u60ewzlDD6D6h3/jMgBCjJvMcd6pRcgDYKUvFgnQdBLxiOgQIuRnhRHZe7MHjSa2PRacmcg4z6mZGWkeToG0/7wo8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 7:R/ARmKQULIRaRojaaoghcimcUrj2towBaJ7he0PkD/lf7v1kEq/f2v0pMcJ/pu/j6ysAEOPKblrbJzVaUXVhpbmJIBeteElNXerPYVCvsDyO8T7rqYhJNrJP0wK/FaWbFfYLUIclZYI4XcaU1jAgum82Eg5g52HwbyNohFdIBou4GvrSuQnUT/JrkYoUoGLluSobHkdt2noOPxcO7UjrS0GFHseiGY3oGgKefMVyiGsCLsLh86ZbR5/pNq7Ha847cmmYPNljxvs4bSzFv9m6tnYr0psmrEih34jt2czJqk/F9ZhR45NqHiCYZsjhoNHdUR/3MBHW+Vy2sBMGjedbs/RAJd9ddsAqT8SciR3bZQzyAiGBIrjYUa+jV1NXcKksvT50m80lk4ghejcNmdQbuVrnbT8ZgW2/h+0CmFQT0g6YX7OZ8AwtA5Y08VQX4EUtkjYxkNeMsCk4WQrk4p7TLw== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Dec 2016 13:09:51.2851 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3008 Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2016 13:09:57 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Friday, December 23, 2016 4:41 PM > On Fri, Dec 23, 2016 at 02:57:53PM +0100, Ladislav Lhotka wrote: > > > > Perhaps our aim could be to have one DDL (YANG), several protocols > > (NETCONF, RESTCONF, CoAP, ...) and any number of datastore/application > > architectures. That's why I also support Mehmet's proposal to make the > > datastore document infomational. > > > For me, datastores are an architectural concept binding the protocols > and the data modeling language together. As we understand better now, > the datastore model also impacts how you write data models. Yes, there is an architectural concept but it might not be datastores. The DDL needs a scope, a boundary within which validation is applied, and ability to join pieces together but whether or not that is a single datastore, or could be several joined by such as URL, a distributed database, needs defining, even if at the moment it seems obvious. We have an object class, I am unsure what the attributes of it are, to use an analogy Likewise, the protocol needs something at the other end to target, and that could be a single something or linked somethings or ... again, a starting point could be what attributes it needs. I find talking to those unfamiliar with history yet wanting to do something (such as I2RS) have some interesting misunderstandings, bringing in 'obvious' concepts from other places - as I doubtless do from my history with SMI. I find that the addition of a second something makes me aware of the true characteristics of a something, so the addition of RESTCONF alongside NETCONF as a second protocol makes it clearer to me what is protocol and what is something else. Is :writable-running anything to do with NETCONF? Nope:-) (but that is where it is currently defined:-( Tom Petch > /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 Dec 27 01:09:03 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A079A1295D1 for ; Tue, 27 Dec 2016 01:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xp6akwwjZpHY for ; Tue, 27 Dec 2016 01:09:01 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id F3F441295CE for ; Tue, 27 Dec 2016 01:09:00 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 95F731CC0175; Tue, 27 Dec 2016 10:09:00 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20161223164101.GA5986@elstar.local> References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> Date: Tue, 27 Dec 2016 10:08:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 09:09:02 -0000 Juergen Schoenwaelder writes: > On Fri, Dec 23, 2016 at 02:57:53PM +0100, Ladislav Lhotka wrote: >> >> Perhaps our aim could be to have one DDL (YANG), several protocols >> (NETCONF, RESTCONF, CoAP, ...) and any number of datastore/application >> architectures. That's why I also support Mehmet's proposal to make the >> datastore document infomational. >> > > For me, datastores are an architectural concept binding the protocols > and the data modeling language together. As we understand better now, > the datastore model also impacts how you write data models. I think that protocols can and should remain reasonably general, and a data modelling language even more so. Tying a protocol to a set of datastores with detailed relationships and semantics would make the protocol just a remote API for a particular management application. The power and universality of HTTP stems also from the clever abstraction of resources and representations, and IMO it is possible to do something similar, albeit less general. Apart from resources and representations (aka encodings), we probably also need the concept of an (abstract) datastore. Protocols should define CRUD operations, RPCs and notifications and needn't care about semantics of datastores. And a data model should just tell whether a datastore content is valid or not, and not much more. In fact, NETCONF, as it is defined in RFC 6241, can work this way - by design it is possible to use it for retrieving and editing any data from any datastore. Those parts that talk about particular datastores can be moved to another document without affecting the protocol, and made more precise. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 27 05:55:58 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9D6129489 for ; Tue, 27 Dec 2016 05:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DihMZhmVVoOy for ; Tue, 27 Dec 2016 05:55:55 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 90CE5129407 for ; Tue, 27 Dec 2016 05:55:54 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 935A51CC0175 for ; Tue, 27 Dec 2016 14:55:54 +0100 (CET) From: Ladislav Lhotka To: netconf@ietf.org Date: Tue, 27 Dec 2016 14:55:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Netconf] restconf-notif and HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 13:55:57 -0000 Hi, in Section 3.2.1 of draft-ietf-netconf-restconf-notif-01, I don't understand how notification data are supposed to be delivered to the subscriber. In Fig. 2, the subscriber sends HTTP POST on channel (b) and receives 200 OK. But then "HTTP Data" is sent from the publisher, apparently without any extra request from the client/subscriber. Is SSE expected to be used here as well? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 27 06:29:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFDC127078 for ; Tue, 27 Dec 2016 06:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VizFS83zBAkQ for ; Tue, 27 Dec 2016 06:29:22 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9551294E8 for ; Tue, 27 Dec 2016 06:29:21 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D9ED2699; Tue, 27 Dec 2016 15:29:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NNDDEHmHvkOu; Tue, 27 Dec 2016 15:29:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 27 Dec 2016 15:29:19 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CCDD20080; Tue, 27 Dec 2016 15:29:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gVG2K-Cz-ONE; Tue, 27 Dec 2016 15:29:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F6402007F; Tue, 27 Dec 2016 15:29:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3233F3DE08B8; Tue, 27 Dec 2016 15:29:19 +0100 (CET) Date: Tue, 27 Dec 2016 15:29:19 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161227142918.GA8070@elstar.local> Mail-Followup-To: Ladislav Lhotka , "t.petch" , jonathan@hansfords.net, Andy Bierman , Netconf References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 14:29:24 -0000 On Tue, Dec 27, 2016 at 10:08:58AM +0100, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Fri, Dec 23, 2016 at 02:57:53PM +0100, Ladislav Lhotka wrote: > >> > >> Perhaps our aim could be to have one DDL (YANG), several protocols > >> (NETCONF, RESTCONF, CoAP, ...) and any number of datastore/application > >> architectures. That's why I also support Mehmet's proposal to make the > >> datastore document infomational. > >> > > > > For me, datastores are an architectural concept binding the protocols > > and the data modeling language together. As we understand better now, > > the datastore model also impacts how you write data models. > > I think that protocols can and should remain reasonably general, and a > data modelling language even more so. Tying a protocol to a set of > datastores with detailed relationships and semantics would make the > protocol just a remote API for a particular management application. > A remote API for management applications was our original target and this is where YANG is doing well (and we apparently still have work to do to improve things). /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 Dec 27 06:47:15 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7314D129600 for ; Tue, 27 Dec 2016 06:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 ctmJIz6ipCfA for ; Tue, 27 Dec 2016 06:47:12 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B38129A94 for ; Tue, 27 Dec 2016 06:47:12 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:c452:7caa:82e4:5386] (unknown [IPv6:2001:718:1a02:1:c452:7caa:82e4:5386]) by mail.nic.cz (Postfix) with ESMTPSA id 6987660BBE; Tue, 27 Dec 2016 15:47:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482850031; bh=lzMC+U5DEyJgnc1e+EnlKFeotiURsQW6cAokPR+stz8=; h=From:Date:To; b=rnl2j0Xjo+jUXSjGyLTW44O5RNxrYKmOyY+P4bbR1VpYUtS/AGpvTtDG8UHBSsZUI Uk0FATZSKABOmpF/c3pvDdMPIHNiAk1Sz+hm8OHVfxk6eIQQq9wtqgSjjW2ynh4Hwo e9ymwKxAmOTF7aTJ/kdZy4YIsOn3NezZyuLd91Zo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20161227142918.GA8070@elstar.local> Date: Tue, 27 Dec 2016 15:47:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 14:47:14 -0000 > On 27 Dec 2016, at 15:29, Juergen Schoenwaelder = wrote: >=20 > On Tue, Dec 27, 2016 at 10:08:58AM +0100, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> On Fri, Dec 23, 2016 at 02:57:53PM +0100, Ladislav Lhotka wrote: >>>>=20 >>>> Perhaps our aim could be to have one DDL (YANG), several protocols >>>> (NETCONF, RESTCONF, CoAP, ...) and any number of = datastore/application >>>> architectures. That's why I also support Mehmet's proposal to make = the >>>> datastore document infomational. >>>>=20 >>>=20 >>> For me, datastores are an architectural concept binding the = protocols >>> and the data modeling language together. As we understand better = now, >>> the datastore model also impacts how you write data models. >>=20 >> I think that protocols can and should remain reasonably general, and = a >> data modelling language even more so. Tying a protocol to a set of >> datastores with detailed relationships and semantics would make the >> protocol just a remote API for a particular management application. >>=20 >=20 > A remote API for management applications was our original target and > this is where YANG is doing well (and we apparently still have work to > do to improve things). By "management application" I mean a specific implementation with a = fixed set of datastores and precise semantics. I do argue that neither = RFC 6241, nor "revised-datastores" nor any other *specific* setup of = datastores is going to work for all use cases, yet the protocols and = YANG can be pretty universal. We have already seen YANG being used in areas that are, strictly = speaking, not supported by 6020/7950. Rather than tolerating such uses = (which is a slippery slope), I would prefer to make them - within = reasonable limits - officially supported. =20 Lada=20 >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 27 07:37:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AEA1294CF for ; Tue, 27 Dec 2016 07:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4zbyO2kLSu0 for ; Tue, 27 Dec 2016 07:37:08 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD2E12944A for ; Tue, 27 Dec 2016 07:37:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A266D712; Tue, 27 Dec 2016 16:37:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wmWaXKIQUx8H; Tue, 27 Dec 2016 16:37:04 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 27 Dec 2016 16:37:06 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5949A20080; Tue, 27 Dec 2016 16:37:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0kliu8IB6akv; Tue, 27 Dec 2016 16:37:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E12772007F; Tue, 27 Dec 2016 16:37:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 297393DE09E2; Tue, 27 Dec 2016 16:37:06 +0100 (CET) Date: Tue, 27 Dec 2016 16:37:06 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161227153706.GA8152@elstar.local> Mail-Followup-To: Ladislav Lhotka , "t.petch" , jonathan@hansfords.net, Andy Bierman , Netconf References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 15:37:09 -0000 On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote: > > > > > A remote API for management applications was our original target and > > this is where YANG is doing well (and we apparently still have work to > > do to improve things). > > By "management application" I mean a specific implementation with a fixed set of datastores and precise semantics. I do argue that neither RFC 6241, nor "revised-datastores" nor any other *specific* setup of datastores is going to work for all use cases, yet the protocols and YANG can be pretty universal. > > We have already seen YANG being used in areas that are, strictly speaking, not supported by 6020/7950. Rather than tolerating such uses (which is a slippery slope), I would prefer to make them - within reasonable limits - officially supported. > This is too abstract for me. What do you suggest to change in the revised datastore architecture? I do believe that having a number of well defined datastores with specific semantics is necessary for having interoperability. /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 Dec 27 09:13:56 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD5D12940B for ; Tue, 27 Dec 2016 09:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHcb-gFTuKzl for ; Tue, 27 Dec 2016 09:13:54 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 EC23D1293E9 for ; Tue, 27 Dec 2016 09:13:53 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id d45so109795187qta.1 for ; Tue, 27 Dec 2016 09:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=g7NiB8JMojX9fwkHb1O0Yv65UVcSbQKQOzCigq4ACvI=; b=clRzYsMnAed+JLcJHPFqaAHrYcgBmjx7jTtnsQzQYxeqjZr7/4hvfqCCvam2FL5U9W unzFqZcUF7QRAW9DySKHofv7HmULF+VJYArxaEUPPCiGaHqd17uioo+MhLQ3FJVYTvbx hVAL6e/yE+VoHSgPRgE6rB9gJm0SuVN6CMK7oSlsuQqGKPvfugF/+cJXr94rKBxLdnUi pvwcLLFEs+5hrvo28H3A8DpvzaYUgQS+YMTojO1pF5huOE9DIVCGvnS/dq2Z0zNJsvbM mxc8/dIRGP1GecNdD6OgYk/5lvF5xlN/RsPhWSKCIFd+GKh2cyA7gZFD2xBDEDGZIWqf ci1A== 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=g7NiB8JMojX9fwkHb1O0Yv65UVcSbQKQOzCigq4ACvI=; b=GvCRtwaapbK3muIsOmRPwwsa1M+wJIRrkzI+6mfzlBrT1A26YLrzQXhalCNqWrSaeY tNgr0KSj8BoquRaDC0T0rXsN7bFoLXSAbEl3caVA9qgzWrpJehSxmS+TPKja9iKSqwkw qXfUMv8SHd3jSlOs5M5ytSIyej3pJFD3xJptdcuHwm92W2YjpIX973oxmrK8JFxwFayU 4jU5kL780PzycmVu757KQpBwyPoPLUGKAXB3ELmaN7sKZSk8nSyydWSzx81xTefBZHMX PI9lcTOb8PnWQCJuxIcQiKfTXTFMsxPn6R3D2sAYQqCdZsZE3/PWJdQ3j3BYHAP+eBUn /Q+g== X-Gm-Message-State: AIkVDXLbWsML0PEyYW2SV1wcHYRGfjvSY+j/37AzSi1iWyPNwEs2SwNEEeYixU0UOj8PxD6w0EMelxOdV4DNLA== X-Received: by 10.237.63.25 with SMTP id p25mr29648446qtf.18.1482858832900; Tue, 27 Dec 2016 09:13:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Tue, 27 Dec 2016 09:13:52 -0800 (PST) In-Reply-To: <20161227153706.GA8152@elstar.local> References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> From: Andy Bierman Date: Tue, 27 Dec 2016 09:13:52 -0800 Message-ID: To: Juergen Schoenwaelder , Ladislav Lhotka , "t.petch" , Jonathan Hansford , Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=001a1138ed6efcefe30544a6f9b8 Archived-At: Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 17:13:56 -0000 --001a1138ed6efcefe30544a6f9b8 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 27, 2016 at 7:37 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote: > > > > > > > > A remote API for management applications was our original target and > > > this is where YANG is doing well (and we apparently still have work to > > > do to improve things). > > > > By "management application" I mean a specific implementation with a > fixed set of datastores and precise semantics. I do argue that neither RFC > 6241, nor "revised-datastores" nor any other *specific* setup of datastores > is going to work for all use cases, yet the protocols and YANG can be > pretty universal. > > > > We have already seen YANG being used in areas that are, strictly > speaking, not supported by 6020/7950. Rather than tolerating such uses > (which is a slippery slope), I would prefer to make them - within > reasonable limits - officially supported. > > > > So what? We have a very open standards process. If people think the YANG-based protocols need improvement, they can write a draft and try to get people to support it. > This is too abstract for me. What do you suggest to change in the > revised datastore architecture? I do believe that having a number of > well defined datastores with specific semantics is necessary for > having interoperability. > IMO the revised datastores draft is clean, not over-engineered, and easy to integrate into systems that need the new datastores. (Let's see how long that lasts once the WG starts on it ;-) > > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a1138ed6efcefe30544a6f9b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 27, 2016 at 7:37 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav L= hotka wrote:
>
> >
> > A remote API for management applications was our original target = and
> > this is where YANG is doing well (and we apparently still have wo= rk to
> > do to improve things).
>
> By "management application" I mean a specific implementation= with a fixed set of datastores and precise semantics. I do argue that neit= her RFC 6241, nor "revised-datastores" nor any other *specific* s= etup of datastores is going to work for all use cases, yet the protocols an= d YANG can be pretty universal.
>
> We have already seen YANG being used in areas that are, strictly speak= ing, not supported by 6020/7950. Rather than tolerating such uses (which is= a slippery slope), I would prefer to make them - within reasonable limits = - officially supported.
>


So what?
We have a very open= standards process.
If people think the YANG-based protocols need= improvement,
they can write a draft and try to get people to sup= port it.

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

--001a1138ed6efcefe30544a6f9b8-- From nobody Tue Dec 27 10:01:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA3A129479 for ; Tue, 27 Dec 2016 10:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 ez09rMehCKYW for ; Tue, 27 Dec 2016 10:01:47 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58527129455 for ; Tue, 27 Dec 2016 10:01:47 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:3c0f:1d8:b398:2e67] (unknown [IPv6:2a01:5e0:29:fffe:3c0f:1d8:b398:2e67]) by mail.nic.cz (Postfix) with ESMTPSA id 40FD760D15; Tue, 27 Dec 2016 19:01:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482861705; bh=mzHIqmGL0O8urKEzXsVHqXRE1CTUoDKXL7tMmZO7nys=; h=From:Date:To; b=v3bbg9qnabiOyN47ETPEC+Ac/yqgeMprKTjt7AegAmJ29DgpP2CBJq8KU1UTcZYM2 zfU7dTv1RSJVoPTvCSc6PZeXNrvrOul0jEyI5wj05UeucUYZizpDnAH44wCnvil66Y Xs30CP3y/d1qri10zNM/mPScl+UDWBylR77Breeo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20161227153706.GA8152@elstar.local> Date: Tue, 27 Dec 2016 19:01:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <298CE651-FAC7-43C8-B9ED-DCF0EB4965D3@nic.cz> References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 18:01:49 -0000 > On 27 Dec 2016, at 16:37, Juergen Schoenwaelder = wrote: >=20 > On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote: >>=20 >>>=20 >>> A remote API for management applications was our original target and >>> this is where YANG is doing well (and we apparently still have work = to >>> do to improve things). >>=20 >> By "management application" I mean a specific implementation with a = fixed set of datastores and precise semantics. I do argue that neither = RFC 6241, nor "revised-datastores" nor any other *specific* setup of = datastores is going to work for all use cases, yet the protocols and = YANG can be pretty universal. >>=20 >> We have already seen YANG being used in areas that are, strictly = speaking, not supported by 6020/7950. Rather than tolerating such uses = (which is a slippery slope), I would prefer to make them - within = reasonable limits - officially supported. =20 >>=20 >=20 > This is too abstract for me. What do you suggest to change in the > revised datastore architecture? I do believe that having a number of > well defined datastores with specific semantics is necessary for > having interoperability. I wrote it already several times: I support(ed) Mehmet's proposal to = make the revised-datastores I-D informative. The document was adopted as = a Standard Track WG item although I didn't see anything close to rough = consensus during the adoption poll. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 27 10:14:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A841296A0 for ; Tue, 27 Dec 2016 10:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 sNHweUauuBX8 for ; Tue, 27 Dec 2016 10:14:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B97129697 for ; Tue, 27 Dec 2016 10:14:56 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:3c0f:1d8:b398:2e67] (unknown [IPv6:2a01:5e0:29:fffe:3c0f:1d8:b398:2e67]) by mail.nic.cz (Postfix) with ESMTPSA id B234660ABF; Tue, 27 Dec 2016 19:14:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482862494; bh=73tc4Gs/n8XMLMFvqs3r3Ou70076iT6QeYGzLnY+2po=; h=From:Date:To; b=N0yyKBMkhJ955Yjzyhq0k2fBT6VEFl18qlFqR9ZSPHgvmPMrHifrUTXl7/vpn1jGq mvOFrFxM/PhqnY772cZmtivAP1xO1v4W0rJcbTHnjh85fBm1ym6fGqC2oAZgeUNUsv lfZIxKVWUoPrtN0OIsG8lfHXKtKuzUWBzXYBpXyg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 27 Dec 2016 19:14:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5668E97B-5427-4E8D-B6EC-59D790C092C3@nic.cz> References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 18:14:58 -0000 > On 27 Dec 2016, at 18:13, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Dec 27, 2016 at 7:37 AM, Juergen Schoenwaelder = wrote: > On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote: > > > > > > > > A remote API for management applications was our original target = and > > > this is where YANG is doing well (and we apparently still have = work to > > > do to improve things). > > > > By "management application" I mean a specific implementation with a = fixed set of datastores and precise semantics. I do argue that neither = RFC 6241, nor "revised-datastores" nor any other *specific* setup of = datastores is going to work for all use cases, yet the protocols and = YANG can be pretty universal. > > > > We have already seen YANG being used in areas that are, strictly = speaking, not supported by 6020/7950. Rather than tolerating such uses = (which is a slippery slope), I would prefer to make them - within = reasonable limits - officially supported. > > >=20 >=20 > So what? > We have a very open standards process. > If people think the YANG-based protocols need improvement, > they can write a draft and try to get people to support it. Of course, rewriting RFC 7950 on my own makes no sense at all, and you = know it very well. >=20 > =20 > This is too abstract for me. What do you suggest to change in the > revised datastore architecture? I do believe that having a number of > well defined datastores with specific semantics is necessary for > having interoperability. >=20 > IMO the revised datastores draft is clean, not over-engineered, and = easy > to integrate into systems that need the new datastores. (Let's see = how > long that lasts once the WG starts on it ;-) I am not against it provided other alternatives remain possible. Lada >=20 >=20 > =20 >=20 > /js >=20 >=20 > Andy > =20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 27 10:34:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1679E129AC6 for ; Tue, 27 Dec 2016 10:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO-TefMBGtWb for ; Tue, 27 Dec 2016 10:34:22 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE7C12944F for ; Tue, 27 Dec 2016 10:34:21 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id h201so86796549qke.1 for ; Tue, 27 Dec 2016 10:34:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gV6nDkxh492h5Aw3AKyuq/A2w9QhZ5pZ9RR3DBf2BeE=; b=OUBo9hUiLlNRFKgptoStUKLvi1vkhASgwn/dTIzyT+IRiF4Gl0J+v7wwtSZlw5v0La Ul8hhKvsoA9tBydznIpp+xqr5sf4ERk/OlXQRluqT8ApNVEt8WRQYphgVWEtUx0ooftM fIAPFNmApKD3lZGUeZIdg/NNl7mGilIE+m6i9w6eowVasjhiFEeVmk2m6iedLQWvL6/n LDeZvUrXcCez5CIisJdbhkuLpfDF3T3rOMp31/z+cYLPl3YJz3VdPa8r4Af5Q8D4eMwQ s/mDcxrWivZqRomgFBDsxovqGiPSrpCOLqu6uEczgqWHt4PS2KgeVGaGr1Z6aGuEv+5+ keqQ== 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=gV6nDkxh492h5Aw3AKyuq/A2w9QhZ5pZ9RR3DBf2BeE=; b=ECuI9ODhCEukGTcHGTBLN/VZbLMipoOEDMr7+fZ33/OvsUGNy58xu0bueEltYf2B06 u/PUnAu1yhsnfQL98efyK5KDdt7Tmo1ZNV1pOxl0rCzUbWh7kM/EvBi3Tbt7hvig5+xD T136VA7H8DoOIwhOsuj+phF+jaZ9rDywO3cGV2YZRtEsGeLIBQDgDWHnt8gX+jGeJnGl cMSNR118ucafx7+cDKLnUfRk8nABkOAPOPgUz1uz8wKg5aRtNQy9PRHqQEOwNB0ckUNU LK74zRT87g6KeH3trjWpR9O5z1KLciA09F3RD89IvZpG5wDOo0MvEEwVoU8Uc5EF6600 xv8Q== X-Gm-Message-State: AIkVDXIYug8eOEoQ9tSxCKX8zAaNBbUhN1YiytHwexN/2QBeijtu80MtdWt2q9vT+FKWzVg3cVPX2V+uUo8iFw== X-Received: by 10.55.76.197 with SMTP id z188mr31497004qka.184.1482863661015; Tue, 27 Dec 2016 10:34:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Tue, 27 Dec 2016 10:34:20 -0800 (PST) In-Reply-To: <298CE651-FAC7-43C8-B9ED-DCF0EB4965D3@nic.cz> References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> <298CE651-FAC7-43C8-B9ED-DCF0EB4965D3@nic.cz> From: Andy Bierman Date: Tue, 27 Dec 2016 10:34:20 -0800 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a114a8062c3fd740544a819af Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 18:34:24 -0000 --001a114a8062c3fd740544a819af Content-Type: text/plain; charset=UTF-8 On Tue, Dec 27, 2016 at 10:01 AM, Ladislav Lhotka wrote: > > > On 27 Dec 2016, at 16:37, Juergen Schoenwaelder university.de> wrote: > > > > On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote: > >> > >>> > >>> A remote API for management applications was our original target and > >>> this is where YANG is doing well (and we apparently still have work to > >>> do to improve things). > >> > >> By "management application" I mean a specific implementation with a > fixed set of datastores and precise semantics. I do argue that neither RFC > 6241, nor "revised-datastores" nor any other *specific* setup of datastores > is going to work for all use cases, yet the protocols and YANG can be > pretty universal. > >> > >> We have already seen YANG being used in areas that are, strictly > speaking, not supported by 6020/7950. Rather than tolerating such uses > (which is a slippery slope), I would prefer to make them - within > reasonable limits - officially supported. > >> > > > > This is too abstract for me. What do you suggest to change in the > > revised datastore architecture? I do believe that having a number of > > well defined datastores with specific semantics is necessary for > > having interoperability. > > I wrote it already several times: I support(ed) Mehmet's proposal to make > the revised-datastores I-D informative. The document was adopted as a > Standard Track WG item although I didn't see anything close to rough > consensus during the adoption poll. > > It appears to me that there is consensus to making this a standards track solution. Datastores allow universal concepts about managed data to be standardized across multiple protocols. In a protocol, the datastore name serves as an input parameter value. It needs to be normative in order for a standards-track protocol to use it. Changing standards track status never addresses real technical problems. I do not understand your objections or alternate proposals. My Applicability Statement concerns are related to developers deciding if a server implementation needs to expose 'intended' and 'applied'. I would like a definitive statement like "If an intended value takes more than 5 seconds to become applied (due to implementation, not missing hardware), then the 'intended' and 'applied' datastores SHOULD be supported." I think the definitions of the datastores apply to all servers, and the set of new datastores is the correct and the semantics are clear. > Lada > Andy > > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --001a114a8062c3fd740544a819af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 27, 2016 at 10:01 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 27 Dec 2016, at 16:37, Juergen Schoenwaelder <j.schoenwaelder@jacobs-universit= y.de> wrote:
>
> On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote:
>>
>>>
>>> A remote API for management applications was our original targ= et and
>>> this is where YANG is doing well (and we apparently still have= work to
>>> do to improve things).
>>
>> By "management application" I mean a specific implementa= tion with a fixed set of datastores and precise semantics. I do argue that = neither RFC 6241, nor "revised-datastores" nor any other *specifi= c* setup of datastores is going to work for all use cases, yet the protocol= s and YANG can be pretty universal.
>>
>> We have already seen YANG being used in areas that are, strictly s= peaking, not supported by 6020/7950. Rather than tolerating such uses (whic= h is a slippery slope), I would prefer to make them - within reasonable lim= its - officially supported.
>>
>
> This is too abstract for me. What do you suggest to change in the
> revised datastore architecture? I do believe that having a number of > well defined datastores with specific semantics is necessary for
> having interoperability.

I wrote it already several times: I support(ed) Mehmet's proposal to ma= ke the revised-datastores I-D informative. The document was adopted as a St= andard Track WG item although I didn't see anything close to rough cons= ensus during the adoption poll.



It appears to me that t= here is consensus to making this a standards track solution.

=
Datastores allow universal concepts about managed data to be sta= ndardized
across multiple protocols.=C2=A0 In a protocol, the dat= astore name serves as
an input parameter value.=C2=A0 It needs to= be normative in order for a
standards-track protocol to use it.<= /div>

Changing standards track status never addresses re= al technical problems.
I do not understand your objections or alt= ernate proposals.

My Applicability Statement conce= rns are related to developers deciding
if a server implementation= needs to expose 'intended' and 'applied'.
I woul= d like a definitive statement like "If an intended value takes more th= an 5 seconds
to become applied (due to implementation, not missin= g hardware), then
the 'intended' and 'applied' da= tastores SHOULD be supported."

I think the de= finitions of the datastores apply to all servers, and the
set of = new datastores is the correct and the semantics are clear.

=C2=A0
Lada

Andy
=C2=A0

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

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






--001a114a8062c3fd740544a819af-- From nobody Wed Dec 28 01:06:12 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3338E12949F for ; Wed, 28 Dec 2016 01:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 lkbKV1hKPSXC for ; Wed, 28 Dec 2016 01:06:09 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F981295C5 for ; Wed, 28 Dec 2016 01:06:08 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:8592:9cb5:fd30:269] (unknown [IPv6:2001:718:1a02:1:8592:9cb5:fd30:269]) by mail.nic.cz (Postfix) with ESMTPSA id 78D80600B6; Wed, 28 Dec 2016 10:06:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482915966; bh=ilhv0gwJiG7Xn9NNWYIFOjBo1vN5OTMaZuinQwE9lSs=; h=From:Date:To; b=a6KTwkuGeBu8CSYgwgYzko/iu/4Zg9P96MQSHiyPbEfzGs5bicGGP9gMIqYvQar4D 1CxrvowiTfDEe23miextM/4DAtnk5RZBH8zeNsAn4MMBkOyEng+ZQHIoxXdDQBWShA nmXzGbrvlZV5OBTCekpVDyEkYdOEFdEHEhtYdsuI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 28 Dec 2016 10:06:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <01E837C0-8E9B-4EF5-88F9-5E132DB17723@nic.cz> References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> <298CE651-FAC7-43C8-B9ED-DCF0EB4965D3@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 09:06:11 -0000 > On 27 Dec 2016, at 19:34, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Dec 27, 2016 at 10:01 AM, Ladislav Lhotka = wrote: >=20 > > On 27 Dec 2016, at 16:37, Juergen Schoenwaelder = wrote: > > > > On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote: > >> > >>> > >>> A remote API for management applications was our original target = and > >>> this is where YANG is doing well (and we apparently still have = work to > >>> do to improve things). > >> > >> By "management application" I mean a specific implementation with a = fixed set of datastores and precise semantics. I do argue that neither = RFC 6241, nor "revised-datastores" nor any other *specific* setup of = datastores is going to work for all use cases, yet the protocols and = YANG can be pretty universal. > >> > >> We have already seen YANG being used in areas that are, strictly = speaking, not supported by 6020/7950. Rather than tolerating such uses = (which is a slippery slope), I would prefer to make them - within = reasonable limits - officially supported. > >> > > > > This is too abstract for me. What do you suggest to change in the > > revised datastore architecture? I do believe that having a number of > > well defined datastores with specific semantics is necessary for > > having interoperability. >=20 > I wrote it already several times: I support(ed) Mehmet's proposal to = make the revised-datastores I-D informative. The document was adopted as = a Standard Track WG item although I didn't see anything close to rough = consensus during the adoption poll. >=20 >=20 >=20 > It appears to me that there is consensus to making this a standards = track solution. Where is any evidence of this? >=20 > Datastores allow universal concepts about managed data to be = standardized > across multiple protocols. In a protocol, the datastore name serves = as > an input parameter value. It needs to be normative in order for a > standards-track protocol to use it. For the protocol, the RPC parameter needs to be normative, not a = particular datastore name or semantics. >=20 > Changing standards track status never addresses real technical = problems. > I do not understand your objections or alternate proposals. I think this proposal will lead to rather significant changes to the = protocols and YANG, and their extent IMO isn't clear yet. For one, the = draft aims at moving validation from "running" to "intended". But if = "intended" is optional to implement (sec. 6.1), I don't get how = validation in YANG can be (re)defined to apply also to implementations = that don't have "intended". What I would like to do is to make protocols and YANG work equally well = for all datastore architectures so that the protocols and YANG needn't = be changed each time the current architecture is found to require = adjustments. >=20 > My Applicability Statement concerns are related to developers deciding > if a server implementation needs to expose 'intended' and 'applied'. > I would like a definitive statement like "If an intended value takes = more than 5 seconds > to become applied (due to implementation, not missing hardware), then > the 'intended' and 'applied' datastores SHOULD be supported." >=20 > I think the definitions of the datastores apply to all servers, and = the > set of new datastores is the correct and the semantics are clear. For some servers running-intended-applied is way too complicated, and = good old "running" may be all that's needed. Lada >=20 > =20 > Lada >=20 > Andy > =20 >=20 > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Dec 28 01:11:09 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763051294DC for ; Wed, 28 Dec 2016 01:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6exuLYKwJI1 for ; Wed, 28 Dec 2016 01:11:06 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B0B12949F for ; Wed, 28 Dec 2016 01:11:05 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE45F760; Wed, 28 Dec 2016 10:11:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fZ_ttH4-Awdp; Wed, 28 Dec 2016 10:11:01 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 28 Dec 2016 10:11:03 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 831D620082; Wed, 28 Dec 2016 10:11:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NI2qPK03CrZh; Wed, 28 Dec 2016 10:11:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E351D2007F; Wed, 28 Dec 2016 10:11:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 42CCD3DE1C69; Wed, 28 Dec 2016 10:11:03 +0100 (CET) Date: Wed, 28 Dec 2016 10:11:03 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161228091103.GA8799@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "t.petch" , Jonathan Hansford , Netconf References: <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> <298CE651-FAC7-43C8-B9ED-DCF0EB4965D3@nic.cz> <01E837C0-8E9B-4EF5-88F9-5E132DB17723@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01E837C0-8E9B-4EF5-88F9-5E132DB17723@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 09:11:08 -0000 On Wed, Dec 28, 2016 at 10:06:05AM +0100, Ladislav Lhotka wrote: > > > > > Datastores allow universal concepts about managed data to be standardized > > across multiple protocols. In a protocol, the datastore name serves as > > an input parameter value. It needs to be normative in order for a > > standards-track protocol to use it. > > For the protocol, the RPC parameter needs to be normative, not a particular datastore name or semantics. > Datastores have associated behaviour, as you discuss below... > > Changing standards track status never addresses real technical problems. > > I do not understand your objections or alternate proposals. > > I think this proposal will lead to rather significant changes to the protocols and YANG, and their extent IMO isn't clear yet. For one, the draft aims at moving validation from "running" to "intended". But if "intended" is optional to implement (sec. 6.1), I don't get how validation in YANG can be (re)defined to apply also to implementations that don't have "intended". > It is a conceptual datastore model. A device may not expose and on some implementations is the same as . The I-D says: On a traditional NETCONF implementation, and are always the same. > What I would like to do is to make protocols and YANG work equally well for all datastore architectures so that the protocols and YANG needn't be changed each time the current architecture is found to require adjustments. Datastores have associated behaviour. > For some servers running-intended-applied is way too complicated, and good old "running" may be all that's needed. And this is all fine: On a traditional NETCONF implementation, and are always the same. /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 Dec 28 01:33:17 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67935129431 for ; Wed, 28 Dec 2016 01:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 0-4LjPxKB1Uo for ; Wed, 28 Dec 2016 01:33:14 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E2212940F for ; Wed, 28 Dec 2016 01:33:14 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:8592:9cb5:fd30:269] (unknown [IPv6:2001:718:1a02:1:8592:9cb5:fd30:269]) by mail.nic.cz (Postfix) with ESMTPSA id 0C9E06095E; Wed, 28 Dec 2016 10:33:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482917593; bh=CWqI1aj8ZkwYfkGicFZUVKFNm4iQDBvlLnRzW4Z2zxI=; h=From:Date:To; b=s235N5eHVeSrMGeGlIbUnpGqDpeyhTj0mSW8ENT+Tzc6rGNeIPIOrIWoieNVW91tu CDFBqhHhgaHLCYOAXwQopVLShUg/1rjPForxjy8DRf3MCjSnafWhhn3/3kw7Dx8tLF d1UfQd2s/ZkUDUg4sWkjaS48aoQnsfVsNyaVX8sQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20161228091103.GA8799@elstar.local> Date: Wed, 28 Dec 2016 10:33:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <06EACA2D-21A9-4A5F-B21E-C1CBB87D8A48@nic.cz> References: <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> <298CE651-FAC7-43C8-B9ED-DCF0EB4965D3@nic.cz> <01E837C0-8E9B-4EF5-88F9-5E132DB17723@nic.cz> <20161228091103.GA8799@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 09:33:16 -0000 > On 28 Dec 2016, at 10:11, Juergen Schoenwaelder = wrote: >=20 > On Wed, Dec 28, 2016 at 10:06:05AM +0100, Ladislav Lhotka wrote: >>=20 >>>=20 >>> Datastores allow universal concepts about managed data to be = standardized >>> across multiple protocols. In a protocol, the datastore name serves = as >>> an input parameter value. It needs to be normative in order for a >>> standards-track protocol to use it. >>=20 >> For the protocol, the RPC parameter needs to be normative, not a = particular datastore name or semantics. >>=20 >=20 > Datastores have associated behaviour, as you discuss below... >=20 >>> Changing standards track status never addresses real technical = problems. >>> I do not understand your objections or alternate proposals. >>=20 >> I think this proposal will lead to rather significant changes to the = protocols and YANG, and their extent IMO isn't clear yet. For one, the = draft aims at moving validation from "running" to "intended". But if = "intended" is optional to implement (sec. 6.1), I don't get how = validation in YANG can be (re)defined to apply also to implementations = that don't have "intended". >>=20 >=20 > It is a conceptual datastore model. A device may not expose > and on some implementations is the same as . The > I-D says: >=20 > On a traditional NETCONF implementation, and = are > always the same. My question was about changes in sec. 8 of RFC 7950.=20 >=20 >> What I would like to do is to make protocols and YANG work equally = well for all datastore architectures so that the protocols and YANG = needn't be changed each time the current architecture is found to = require adjustments. >=20 > Datastores have associated behaviour. Yes, so it's important for the management application to know available = datastores and their behaviour, not necessarily for the protocol or data = modelling language. Using again the web analogy, a web application has = to know the structure and semantics of resources but these are = completely transparent to HTTP and schema languages, if they are used. Lada=20 >=20 >> For some servers running-intended-applied is way too complicated, and = good old "running" may be all that's needed. >=20 > And this is all fine: >=20 > On a traditional NETCONF implementation, and = are > always the same. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Dec 28 01:42:48 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1597129460 for ; Wed, 28 Dec 2016 01:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h54Bpur_ilu4 for ; Wed, 28 Dec 2016 01:42:46 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3D4128AB0 for ; Wed, 28 Dec 2016 01:42:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5A41D6EA; Wed, 28 Dec 2016 10:42:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WZ_cFwx5NbM9; Wed, 28 Dec 2016 10:42:43 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 28 Dec 2016 10:42:45 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1805820080; Wed, 28 Dec 2016 10:42:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mxwY3pwogtP1; Wed, 28 Dec 2016 10:42:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A57B2007F; Wed, 28 Dec 2016 10:42:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8D8EA3DE1F27; Wed, 28 Dec 2016 10:42:44 +0100 (CET) Date: Wed, 28 Dec 2016 10:42:44 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161228094244.GB8847@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "t.petch" , Jonathan Hansford , Netconf References: <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> <298CE651-FAC7-43C8-B9ED-DCF0EB4965D3@nic.cz> <01E837C0-8E9B-4EF5-88F9-5E132DB17723@nic.cz> <20161228091103.GA8799@elstar.local> <06EACA2D-21A9-4A5F-B21E-C1CBB87D8A48@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06EACA2D-21A9-4A5F-B21E-C1CBB87D8A48@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 09:42:48 -0000 On Wed, Dec 28, 2016 at 10:33:12AM +0100, Ladislav Lhotka wrote: > > > > > Datastores have associated behaviour. > > Yes, so it's important for the management application to know available datastores and their behaviour, not necessarily for the protocol or data modelling language. Using again the web analogy, a web application has to know the structure and semantics of resources but these are completely transparent to HTTP and schema languages, if they are used. > The NETCONF goal is interoperable data model driven management of configuration of devices. This goes a bit beyond what you find commonly on the web, where the expectation for an exchange to lead to the same result across multiple independent implementations and deployments is usually low. /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 Dec 28 02:13:02 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7F41294BB for ; Wed, 28 Dec 2016 02:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 0vHIM0CGA_lu for ; Wed, 28 Dec 2016 02:12:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8B7129466 for ; Wed, 28 Dec 2016 02:12:59 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:8592:9cb5:fd30:269] (unknown [IPv6:2001:718:1a02:1:8592:9cb5:fd30:269]) by mail.nic.cz (Postfix) with ESMTPSA id D6CEB60D7D; Wed, 28 Dec 2016 11:12:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482919977; bh=v20i1/DJMNEyTCDEFV6ZUMp+7FEOk+N4Bh8Hkh850AA=; h=From:Date:To; b=MzYUpEcafl3HSoj7cD20Pio7nsSB6tq070kQYH7Hh9hAePKrxl3i8ATw283BTG0UR YU0Wbg29bwXLukOVQhCPUFDsZK+MkbUpSHoMZXtSI6uG50iwN9ql7P0PvO3apfxSoB wxQFMzYAkhzxfg9YJyeo9WMMHqmQjVlreWX1MhyU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20161228094244.GB8847@elstar.local> Date: Wed, 28 Dec 2016 11:12:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A5F3C9C-69A1-44A8-80A4-CA0A005B24A2@nic.cz> References: <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> <298CE651-FAC7-43C8-B9ED-DCF0EB4965D3@nic.cz> <01E837C0-8E9B-4EF5-88F9-5E132DB17723@nic.cz> <20161228091103.GA8799@elstar.local> <06EACA2D-21A9-4A5F-B21E-C1CBB87D8A48@nic.cz> <20161228094244.GB8847@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 10:13:01 -0000 > On 28 Dec 2016, at 10:42, Juergen Schoenwaelder = wrote: >=20 > On Wed, Dec 28, 2016 at 10:33:12AM +0100, Ladislav Lhotka wrote: >>=20 >>>=20 >>> Datastores have associated behaviour. >>=20 >> Yes, so it's important for the management application to know = available datastores and their behaviour, not necessarily for the = protocol or data modelling language. Using again the web analogy, a web = application has to know the structure and semantics of resources but = these are completely transparent to HTTP and schema languages, if they = are used. >>=20 >=20 > The NETCONF goal is interoperable data model driven management of > configuration of devices. This goes a bit beyond what you find > commonly on the web, where the expectation for an exchange to lead to > the same result across multiple independent implementations and > deployments is usually low. It doesn't mean that similar separation of concerns is impossible in = this area. YANG could just define what (different levels of) validity = means for a data tree, and it would be up to documents defining = particular datastore architectures to state ro/rw properties for = individual datastores, validation requirements etc. And servers could = advertise the datastore architecture they use as a capability. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Dec 28 02:21:02 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306EF1295BE for ; Wed, 28 Dec 2016 02:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hFyG1ppHMyz for ; Wed, 28 Dec 2016 02:20:58 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD0A1295BB for ; Wed, 28 Dec 2016 02:20:58 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9481C775; Wed, 28 Dec 2016 11:20:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9CM-0ul2ZntQ; Wed, 28 Dec 2016 11:20:55 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 28 Dec 2016 11:20:57 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 489EE2007F; Wed, 28 Dec 2016 11:20:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zbQYdJ4ZzlOG; Wed, 28 Dec 2016 11:20:56 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71DCE20080; Wed, 28 Dec 2016 11:20:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C0A103DE20D3; Wed, 28 Dec 2016 11:20:55 +0100 (CET) Date: Wed, 28 Dec 2016 11:20:55 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20161228102055.GA8999@elstar.local> Mail-Followup-To: Ladislav Lhotka , Netconf References: <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> <298CE651-FAC7-43C8-B9ED-DCF0EB4965D3@nic.cz> <01E837C0-8E9B-4EF5-88F9-5E132DB17723@nic.cz> <20161228091103.GA8799@elstar.local> <06EACA2D-21A9-4A5F-B21E-C1CBB87D8A48@nic.cz> <20161228094244.GB8847@elstar.local> <0A5F3C9C-69A1-44A8-80A4-CA0A005B24A2@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A5F3C9C-69A1-44A8-80A4-CA0A005B24A2@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 10:21:00 -0000 On Wed, Dec 28, 2016 at 11:12:57AM +0100, Ladislav Lhotka wrote: > > It doesn't mean that similar separation of concerns is impossible in this area. YANG could just define what (different levels of) validity means for a data tree, and it would be up to documents defining particular datastore architectures to state ro/rw properties for individual datastores, validation requirements etc. And servers could advertise the datastore architecture they use as a capability. > You would have to define a proper meta-model and make implementations capable of interpreting such a meta-model. Whether this is overall easier than simply agreeing on a common set of datastores remains to be seen. Write and I-D defining such a meta-model. A key goal is that clients can manage different servers and there is a trade-off between forcing some commonality on the servers in order to allow simpler clients or to allow for more flexibility on the server side at the expense that clients will become more complex since they have to be able to adapt to server semantics or we will face clients that stop to work across multiple 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 Dec 28 02:54:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779561297DE for ; Wed, 28 Dec 2016 02:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 RN7w6g30-b5q for ; Wed, 28 Dec 2016 02:54:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE571297CF for ; Wed, 28 Dec 2016 02:54:48 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:8592:9cb5:fd30:269] (unknown [IPv6:2001:718:1a02:1:8592:9cb5:fd30:269]) by mail.nic.cz (Postfix) with ESMTPSA id 101E760B5D; Wed, 28 Dec 2016 11:54:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482922487; bh=+B7INYT5p0ZDhkAytX8DhVKzTsWQkhiVzCaiiaFxSOE=; h=From:Date:To; b=I7Vo4nPoPmTaC/OjMp86bmA2tOX8Rd6+leRkXuRPFwEQ1bKK+7prwG4NGuSxiuQZr zhXBIOaN5MtS1bB3ym4PQNurDfMkBXBqCvcSJm9T+rWHn5GOskCz6PlJE8MLbvrKDm T797kf81T3FzXmwNLooPe8A5mwoQ4lJ51n4hcEps= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20161228102055.GA8999@elstar.local> Date: Wed, 28 Dec 2016 11:54:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> <298CE651-FAC7-43C8-B9ED-DCF0EB4965D3@nic.cz> <01E837C0-8E9B-4EF5-88F9-5E132DB17723@nic.cz> <20161228091103.GA8799@elstar.local> <06EACA2D-21A9-4A5F-B21E-C1CBB87D8A48@nic.cz> <20161228094244.GB8847@elstar.local> <0A5F3C9C-69A1-44A8-80A4-CA0A005B24A2@nic.cz> <20161228102055.GA8999@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 10:54:50 -0000 > On 28 Dec 2016, at 11:20, Juergen Schoenwaelder = wrote: >=20 > On Wed, Dec 28, 2016 at 11:12:57AM +0100, Ladislav Lhotka wrote: >>=20 >> It doesn't mean that similar separation of concerns is impossible in = this area. YANG could just define what (different levels of) validity = means for a data tree, and it would be up to documents defining = particular datastore architectures to state ro/rw properties for = individual datastores, validation requirements etc. And servers could = advertise the datastore architecture they use as a capability. >>=20 >=20 > You would have to define a proper meta-model and make implementations > capable of interpreting such a meta-model. Whether this is overall > easier than simply agreeing on a common set of datastores remains to > be seen. Write and I-D defining such a meta-model. For the time being, I am going to wait for changes to 6241 and 7950 that = will be induced by revised-datastores. >=20 > A key goal is that clients can manage different servers and there is a > trade-off between forcing some commonality on the servers in order to > allow simpler clients or to allow for more flexibility on the server > side at the expense that clients will become more complex since they > have to be able to adapt to server semantics or we will face clients > that stop to work across multiple implementations. Yes. In fact, various combinations of :writable-running, :candidate and = :startup define several different datastore architectures (some make = more sense than others). As there is no requirement that clients have to = support all of them, we already have different client-server management = applications that still use the same protocol and data modelling = language. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Dec 28 09:36:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3E612962E for ; Wed, 28 Dec 2016 09:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7DtY3yvMSJi for ; Wed, 28 Dec 2016 09:36:32 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 ED32B1294A8 for ; Wed, 28 Dec 2016 09:36:31 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id p16so352138270qta.0 for ; Wed, 28 Dec 2016 09:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5KoDnaN/qHwVZ8IEKqlUhBeUMJjTxoo+2p0zbmLU2os=; b=HAoGXLXGX6goczNLLMR2frjjv/vfN0WwWNvSYwYOTDn9yTQ9HNWESdBU4erJHvAGsc btDoEehz8haweVZna3xhV6YczWfL5Vusq9FF7DWw8zr5drDMT2ymd4GxM7n4/zeWZPJd O4QH16m0OjVXYRO5EWE1ijaqvVi1bv9sVuB4YOUj3DxCPM4sqJEuLUEjswBpAa2bcmco wqm1vckUSX0VtkKwxWrtonBQ8JQ0VYYK3m0sE15edNU3T7VXHSfNUNM+XrIHTbvefky1 wXKKsef02gnPDUi4ZpubCFUvDWsRhh6c77VI6GVWYUAYRHzMo5gnrgW5J272ChM6Zdgh xFjQ== 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=5KoDnaN/qHwVZ8IEKqlUhBeUMJjTxoo+2p0zbmLU2os=; b=awA724dqDcLkKTp3YJVSCWSn9oosAeHtT1qwRstvBHYckWgv4qfRbasPUGJ1OkWDBQ kYE/cSuCdWdlbcxJsk0c9oP6PvdhUXNDz9hiRhSvxJqAwEG+aAY4NrCrqCxhE682tt4Q KWcQb7qHdIDokbkaE1QAa+bMgyj2ZFSdl2PitipOPDu8MHMmK1mSwjznUBXXZu2QPPbr Ni/cao+DavR7JCL8tplXSKocVaGzvu+rYnVasDoFj1LFFPNNQ1EIbYwAjlonWBvClYnb KXm4j0JEklHuddrPgElNHSXKcyKcBgLJWwJaJnPUWgDF8nkZT6MSgqXGeu+eVmtW9Z6k zStg== X-Gm-Message-State: AIkVDXJDwvo2g4Oh9QCAnsY9ntiaGGNOsa7mTM+YQasMlFqMRRrlK86QKc6NivSb3AQVG+hxi5vm5k2Y8RAIpA== X-Received: by 10.237.51.167 with SMTP id v36mr38191881qtd.46.1482946590957; Wed, 28 Dec 2016 09:36:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.113 with HTTP; Wed, 28 Dec 2016 09:36:30 -0800 (PST) In-Reply-To: <01E837C0-8E9B-4EF5-88F9-5E132DB17723@nic.cz> References: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net> <20161222220548.Horde.12GuFmzyfUJfkL8vCmpxFqs@server.myfast.site> <014801d25d09$8a6c2e00$4001a8c0@gateway.2wire.net> <20161223164101.GA5986@elstar.local> <20161227142918.GA8070@elstar.local> <0BFC3140-CE77-46BF-B31E-B630D6D7C6D2@nic.cz> <20161227153706.GA8152@elstar.local> <298CE651-FAC7-43C8-B9ED-DCF0EB4965D3@nic.cz> <01E837C0-8E9B-4EF5-88F9-5E132DB17723@nic.cz> From: Andy Bierman Date: Wed, 28 Dec 2016 09:36:30 -0800 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=94eb2c125666c684370544bb684e Archived-At: Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 17:36:34 -0000 --94eb2c125666c684370544bb684e Content-Type: text/plain; charset=UTF-8 On Wed, Dec 28, 2016 at 1:06 AM, Ladislav Lhotka wrote: > > > On 27 Dec 2016, at 19:34, Andy Bierman wrote: > > > > > > > > On Tue, Dec 27, 2016 at 10:01 AM, Ladislav Lhotka wrote: > > > > > On 27 Dec 2016, at 16:37, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote: > > >> > > >>> > > >>> A remote API for management applications was our original target and > > >>> this is where YANG is doing well (and we apparently still have work > to > > >>> do to improve things). > > >> > > >> By "management application" I mean a specific implementation with a > fixed set of datastores and precise semantics. I do argue that neither RFC > 6241, nor "revised-datastores" nor any other *specific* setup of datastores > is going to work for all use cases, yet the protocols and YANG can be > pretty universal. > > >> > > >> We have already seen YANG being used in areas that are, strictly > speaking, not supported by 6020/7950. Rather than tolerating such uses > (which is a slippery slope), I would prefer to make them - within > reasonable limits - officially supported. > > >> > > > > > > This is too abstract for me. What do you suggest to change in the > > > revised datastore architecture? I do believe that having a number of > > > well defined datastores with specific semantics is necessary for > > > having interoperability. > > > > I wrote it already several times: I support(ed) Mehmet's proposal to > make the revised-datastores I-D informative. The document was adopted as a > Standard Track WG item although I didn't see anything close to rough > consensus during the adoption poll. > > > > > > > > It appears to me that there is consensus to making this a standards > track solution. > > Where is any evidence of this? > > I think there was approval in the room in Seoul, and it is being confirmed on the mailing list. > > > > Datastores allow universal concepts about managed data to be standardized > > across multiple protocols. In a protocol, the datastore name serves as > > an input parameter value. It needs to be normative in order for a > > standards-track protocol to use it. > > For the protocol, the RPC parameter needs to be normative, not a > particular datastore name or semantics. > > > > > Changing standards track status never addresses real technical problems. > > I do not understand your objections or alternate proposals. > > I think this proposal will lead to rather significant changes to the > protocols and YANG, and their extent IMO isn't clear yet. For one, the > draft aims at moving validation from "running" to "intended". But if > "intended" is optional to implement (sec. 6.1), I don't get how validation > in YANG can be (re)defined to apply also to implementations that don't have > "intended". > It should be possible to add new operations to NETCONF and new query parameters to RESTCONF that support the operator requirements, and still preserve existing operations. I am not in favor of rewriting operations that move the validation to 'intended'. That would not be backward-compatible so it is a non-starter. > What I would like to do is to make protocols and YANG work equally well > for all datastore architectures so that the protocols and YANG needn't be > changed each time the current architecture is found to require adjustments. > > This does not make sense to me. First, I do not care about non-standard, private architectures, just the standard architecture. Applications cannot be forced to hard-wire all the details about configuration management. Let's not go back to data silo architecture. The standards need to expose the details in a common framework to enable data-driven automation tools. That means the protocols and the data models have to support a standard datastore framework. > > > My Applicability Statement concerns are related to developers deciding > > if a server implementation needs to expose 'intended' and 'applied'. > > I would like a definitive statement like "If an intended value takes > more than 5 seconds > > to become applied (due to implementation, not missing hardware), then > > the 'intended' and 'applied' datastores SHOULD be supported." > > > > I think the definitions of the datastores apply to all servers, and the > > set of new datastores is the correct and the semantics are clear. > > For some servers running-intended-applied is way too complicated, and good > old "running" may be all that's needed. > Agreed. These servers do not need to implement the new datastores. The same is true for the 'candidate' and 'startup' datastores already. > > Lada > > Andy > > > > > > Lada > > > > Andy > > > > > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --94eb2c125666c684370544bb684e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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

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

Where is any evidence of this?



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

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

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

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

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

<= /div>


It should be possible to add new op= erations to NETCONF and
new query parameters to RESTCONF that sup= port the operator requirements,
and still preserve existing opera= tions.

I am not in favor of rewriting operations t= hat move the validation to 'intended'.
That would not be = backward-compatible so it is a non-starter.



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



This does not make sens= e to me.
First, I do not care about non-standard, private archite= ctures, just the
standard architecture.=C2=A0 Applications cannot= be forced to hard-wire all the
details about configuration manag= ement.=C2=A0 Let's not go back to data silo architecture.
The standards need to expose the details in a common framework = to enable
data-driven automation tools.=C2=A0 That means the prot= ocols and the data models
have to support a standard datastore fr= amework.


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

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

Agreed.=C2=A0 These servers do not need to im= plement the new datastores.
The same is true for the 'candida= te' and 'startup' datastores already.
=C2=A0

Lada



Andy
=C2=A0
>
>
> Lada
>
> Andy
>
>
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67

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






--94eb2c125666c684370544bb684e-- From nobody Thu Dec 29 09:13:49 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5563E1296AC for ; Thu, 29 Dec 2016 09:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzXPStm0xr4j for ; Thu, 29 Dec 2016 09:13:46 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D5E129866 for ; Thu, 29 Dec 2016 09:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1061; q=dns/txt; s=iport; t=1483031626; x=1484241226; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=p08dvPL+UaGZsg6ZmoTGL3gB5amLIWfbW2zvw5irwv0=; b=KEJkeRtVdM5i88hT51BmZc9wKmFmxywB2fLAf82Qe3wxH/7booZ3pY1c oLXsteBFJsTvB69vZ/9g9q+xKYsgUuXU3vKsIDyTX1udhXWARixjpJ/Gg j7/3p3s5Vo2qXB+zvm1gg0Q9lL6tnE8XsVfF74kbK1Xt8Ys13q/0tHnep k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQB8Q2VY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9fgQwHjU2UQ5UbggcfC4UuSgKBWj8UAQIBAQEBAQE?= =?us-ascii?q?BYiiEaAEBAQMBAQE4NBALAgEINhAnCyUCBAESCIhgCA6wOopKAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEZBYZGhGOKKgWafQGRNZBfkj0BHziBKi6FYHKHc4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,428,1477958400"; d="scan'208";a="178005340" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Dec 2016 17:13:45 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uBTHDj2n002260 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Dec 2016 17:13:45 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 29 Dec 2016 12:13:44 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 29 Dec 2016 12:13:44 -0500 From: "Eric Voit (evoit)" To: Ladislav Lhotka , "netconf@ietf.org" , Eric Anderson Thread-Topic: [Netconf] restconf-notif and HTTP/2 Thread-Index: AQHSYEj4r+OgtxX/iku8iWrIh7UoxaEfGWxg Date: Thu, 29 Dec 2016 17:13:44 +0000 Message-ID: <1d0102de04314babbbe2ce32ed996dd7@XCH-RTP-013.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] restconf-notif and HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 17:13:48 -0000 Hi Lada, No need for SSE here. The HTTP2 an OK message on stream (7) consists of he= aders and an unbounded set of HTTP Data. The message isn't over until END_= STREAM flag is set. In the case of Fig 2, the OK message doesn't actually = end until the "HTTP Headers (end of stream)". This is identical to how GRPC works. (Adding Eric A. in case he wants to c= hime in.) Eric > Hi, >=20 > in Section 3.2.1 of draft-ietf-netconf-restconf-notif-01, I don't underst= and how > notification data are supposed to be delivered to the subscriber. In Fig.= 2, the > subscriber sends HTTP POST on channel (b) and receives 200 OK. But then > "HTTP Data" is sent from the publisher, apparently without any extra requ= est > from the client/subscriber. Is SSE expected to be used here as well? >=20 > Thanks, Lada >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Dec 30 00:38:02 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A1A1296D2 for ; Fri, 30 Dec 2016 00:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 x5r-lHSpPjuq for ; Fri, 30 Dec 2016 00:37:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5DB1296C9 for ; Fri, 30 Dec 2016 00:37:58 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:f88b:4cf5:e255:c255] (unknown [IPv6:2001:718:1a02:1:f88b:4cf5:e255:c255]) by mail.nic.cz (Postfix) with ESMTPSA id 76810615F1; Fri, 30 Dec 2016 09:37:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1483087076; bh=EsgC1NDHgzECu44nALfLlMDSdqceHjKgtHI6Wpvq9I8=; h=From:Date:To; b=wSOCm49I2NJkJ4oU8idFdMU9kUmiDeusKwHZznZDfmIFMnEpaumYZhYMTyTFXiDfz 2tRC9l5GOyQpmz5De1RlAq88382VvQ/6BI7fs/Uj1/VdRtd+Pk37x0NWNJ/aWGUWDO 5GmF2wek9JPXnuD95sw040+Z3f4zMpOGemPqKzE8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <1d0102de04314babbbe2ce32ed996dd7@XCH-RTP-013.cisco.com> Date: Fri, 30 Dec 2016 09:37:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E5DAC86-7F3C-4352-9197-DB056AB7C51C@nic.cz> References: <1d0102de04314babbbe2ce32ed996dd7@XCH-RTP-013.cisco.com> To: "Eric Voit (evoit)" X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , Eric Anderson Subject: Re: [Netconf] restconf-notif and HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 08:38:01 -0000 Hi Eric, thanks for explanation, I didn't know this. Happy New Year, Lada > On 29 Dec 2016, at 18:13, Eric Voit (evoit) wrote: >=20 > Hi Lada, >=20 > No need for SSE here. The HTTP2 an OK message on stream (7) consists = of headers and an unbounded set of HTTP Data. The message isn't over = until END_STREAM flag is set. In the case of Fig 2, the OK message = doesn't actually end until the "HTTP Headers (end of stream)". >=20 > This is identical to how GRPC works. (Adding Eric A. in case he wants = to chime in.) >=20 > Eric >=20 >> Hi, >>=20 >> in Section 3.2.1 of draft-ietf-netconf-restconf-notif-01, I don't = understand how >> notification data are supposed to be delivered to the subscriber. In = Fig. 2, the >> subscriber sends HTTP POST on channel (b) and receives 200 OK. But = then >> "HTTP Data" is sent from the publisher, apparently without any extra = request >> from the client/subscriber. Is SSE expected to be used here as well? >>=20 >> Thanks, Lada >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
Cheers,
Mehmet
--001a114118a06c3c0005433974dd-- From nobody Fri Dec 9 05:33:16 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2045712943A for ; Fri, 9 Dec 2016 05:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 GDzZbItOspbt for ; Fri, 9 Dec 2016 05:33:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 75731129418 for ; Fri, 9 Dec 2016 05:33:08 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 52FE61AE02BC; Fri, 9 Dec 2016 14:33:06 +0100 (CET) Date: Fri, 09 Dec 2016 14:33:06 +0100 (CET) Message-Id: <20161209.143306.1544319624979225814.mbj@tail-f.com> To: evoit@cisco.com From: Martin Bjorklund In-Reply-To: <5e06ffa5d92a4227ae1d64bc8531ac40@XCH-RTP-013.cisco.com> References: <20161209.092651.1622778603139515958.mbj@tail-f.com> <5e06ffa5d92a4227ae1d64bc8531ac40@XCH-RTP-013.cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 13:33:15 -0000 "Eric Voit (evoit)" wrote: > > From: Martin Bjorklund, December 9, 2016 3:27 AM > > > > "Eric Voit (evoit)" wrote: > > > Hi Martin, > > > > > > > From: Martin Bjorklund, December 8, 2016 4:08 AM > > > > > > > > I think your requirements below are more like driving forces for > > > > YANG push, right? Is there any of these that affects the solution > > > > in RFC 5277? > > > > > > The majority of these cases need yang-push. But yang push is only > > > possible when the information is yang modeled. > > > > Sure, but that's a completely different thing. > > > > This discussion is about what needs to be done with RFC 5277. I'll re-iterate > > what Andy wrote once more: > > > > What are the must-have, should-have, and nice-to-have features that are > > missing from RFC 5277? > > At a high level incremental functionality we have been discussing since IETF 94, 95, 96, 97 includes: > - configured subscriptions > - many subscriptions per transport > - modify and delete subscriptions > - control plane notifications > - Restconf & HTTP support > - Data plan notification including subscription-id > > At a medium level, existing documentation detailing these requirements can be seen in places like: > https://www.ietf.org/proceedings/95/slides/slides-95-netconf-7.pdf Slide 5 > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf Slides 5, 28 > https://www.ietf.org/proceedings/97/slides/slides-97-netconf-draft-ietf-netconf-yang-push-01.pdf Slides 20 & 21 I think the list above summarizes what's in the slides. So, let me re-order this list a bit: - configured subscriptions - many subscriptions per transport - Data plan notification including subscription-id - modify and delete subscriptions I don't view "control plane notifications" as a deficiency of 5277; it already has a few, and if new functionality requires us to define more control plane notifications, that's not a problem. As for "Restconf & HTTP support", RESTCONF already supports notifications, and there need to be a RESTCONF-specific solution in place. I do agree that if we open 5277, we should make sure we have a small protocol-dependent part, and a generic, protocol-independent part. So there are really two (major) requirements: 1. configured subscriptions 2. many subscriptions per transport session Do you agree, or did I miss anything? (1) can be done completely backwards compatible; in fact it might not even require an update to 5277. (2) requires an update to the element, as discussed earlier. Did you want to make support for (2) mandatory to implement? If so, we need to make :interleave mandatory, or remove it. Maybe it should be noted that when SSH is used, there really is no need for (2), since it is trivial and cheap to open new SSH channels. I thus assume that the reason for wanting to do (2) is that sessions are expensive when SSH is not used. /martin > > At a detailed level, I2RS's RFC-7923 has functional requirements for yang subscriptions. This is what was requested by the WG to be made available for event notifications. > as well as various WG meeting minutes. > > And of course the existing WG minutes, the four draft document appendices, and the Dezign team minutes at: > https://github.com/netconf-wg/yang-push/wiki/Minutes > Attempts to keep a running list of to-be-resolved dialogs. Of course there is a lag between dialogs and embodiment in the drafts. > > If anyone wants to propose a revision to the requirements, I propose they do this as deltas from the existing documentation. > > Or course we in the WG can and should discuss and tweak any specific requirement on this mailer based on ongoing learnings over time. > > Eric > > > /martin > From nobody Fri Dec 9 07:19:15 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6322C12949A for ; Fri, 9 Dec 2016 07:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0THpG21IuQG3 for ; Fri, 9 Dec 2016 07:19:11 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C8F1294A0 for ; Fri, 9 Dec 2016 07:19:10 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id n21so20228997qka.3 for ; Fri, 09 Dec 2016 07:19:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qmluxf8Ra+C33EQxMkp6N4W7WbahYMs+9aZqit59NEY=; b=VBktNtfpw3bGdIEgjDNrl+czSQp53SWSvcUvqEEuqabk8L465/B639bPWad+GupCak Ikrut8jKgc9fQAMbN46lWnqAWttxtsZBFpczX/acT+JOeoRMnWn9Q9Dg7nGtKfGZBx1p da/+0TyXtlUAjLpJJMs6pYrDq0pInFo7ORM/h5ezAaoVwF+T+iX/EW9USj/ovS2c6VFN xLyas3M6a+4ELM47HYvMXzHcFH+MP1WCxET52N59xzHS1y5DzgBYNya1R+TVwg8oDfEY 1tULszCK5yODmric8Ip7lYhh0D36ACPlDhi7FrjLp5t7laaXNw7XQk8cRUsl0Yg2Y/9V rLQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qmluxf8Ra+C33EQxMkp6N4W7WbahYMs+9aZqit59NEY=; b=IkZU4C+/5ZGVUaGz9yM2zYPPbPVn5VQ4VeWOwDfw7zs57rAlnoWipwPaquYeyACHCL Y30qoBMli/8zV5dUy3iZ1Rq3/yMR4FvXCQLGxM3yzfZdXCYjuzhxKdV9e836HSsItQAb 5FFasLfaUAP8zhq7mLG8ZoD8ZTSkAov8hrezMBcYNSvucdtKpV/GGC3WPgvIuLr0KQQF kCnmorWtRZUQoIVGfaJ9jKnsgFC/wA6vAFIhO6/w1LKWEKU2wg6BAX+UIXNqHle+7s1I YsY+oG2gAi2ODeQRy0wNm5tteZRLukwHT5jGlaqM7qnsd9Ham4jhWQNi7hHamSehOqmc wPmw== X-Gm-Message-State: AKaTC00dw+A2eqh/canNzPjqV0yCFlwMKkTazaYSWGSqmwgFJMaYNikiwuHazTJYSRG/oBdKeaVyFB03L9rNKw== X-Received: by 10.55.76.150 with SMTP id z144mr66733101qka.194.1481296749892; Fri, 09 Dec 2016 07:19:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Fri, 9 Dec 2016 07:19:09 -0800 (PST) In-Reply-To: <20161209.143306.1544319624979225814.mbj@tail-f.com> References: <20161209.092651.1622778603139515958.mbj@tail-f.com> <5e06ffa5d92a4227ae1d64bc8531ac40@XCH-RTP-013.cisco.com> <20161209.143306.1544319624979225814.mbj@tail-f.com> From: Andy Bierman Date: Fri, 9 Dec 2016 07:19:09 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a114a886895cf8505433b465f Archived-At: Cc: Netconf Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:19:14 -0000 --001a114a886895cf8505433b465f Content-Type: text/plain; charset=UTF-8 On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund wrote: > "Eric Voit (evoit)" wrote: > > > From: Martin Bjorklund, December 9, 2016 3:27 AM > > > > > > "Eric Voit (evoit)" wrote: > > > > Hi Martin, > > > > > > > > > From: Martin Bjorklund, December 8, 2016 4:08 AM > > > > > > > > > > I think your requirements below are more like driving forces for > > > > > YANG push, right? Is there any of these that affects the solution > > > > > in RFC 5277? > > > > > > > > The majority of these cases need yang-push. But yang push is only > > > > possible when the information is yang modeled. > > > > > > Sure, but that's a completely different thing. > > > > > > This discussion is about what needs to be done with RFC 5277. I'll > re-iterate > > > what Andy wrote once more: > > > > > > What are the must-have, should-have, and nice-to-have features that > are > > > missing from RFC 5277? > > > > At a high level incremental functionality we have been discussing since > IETF 94, 95, 96, 97 includes: > > - configured subscriptions > > - many subscriptions per transport > > - modify and delete subscriptions > > - control plane notifications > > - Restconf & HTTP support > > - Data plan notification including subscription-id > > > > At a medium level, existing documentation detailing these requirements > can be seen in places like: > > https://www.ietf.org/proceedings/95/slides/slides-95-netconf-7.pdf > Slide 5 > > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf > Slides 5, 28 > > https://www.ietf.org/proceedings/97/slides/slides- > 97-netconf-draft-ietf-netconf-yang-push-01.pdf Slides 20 & 21 > > I think the list above summarizes what's in the slides. > > So, let me re-order this list a bit: > > - configured subscriptions > - many subscriptions per transport > - Data plan notification including subscription-id > - modify and delete subscriptions > > I don't view "control plane notifications" as a deficiency of 5277; it > already has a few, and if new functionality requires us to define more > control plane notifications, that's not a problem. > > As for "Restconf & HTTP support", RESTCONF already supports > notifications, and there need to be a RESTCONF-specific solution in > place. I do agree that if we open 5277, we should make sure we have a > small protocol-dependent part, and a generic, protocol-independent > part. > > So there are really two (major) requirements: > > 1. configured subscriptions > 2. many subscriptions per transport session > > Do you agree, or did I miss anything? > > (1) can be done completely backwards compatible; in fact it might not > even require an update to 5277. > > (2) requires an update to the element, as discussed > earlier. > > Did you want to make support for (2) mandatory to implement? If so, > we need to make :interleave mandatory, or remove it. > > Maybe it should be noted that when SSH is used, there really is no > need for (2), since it is trivial and cheap to open new SSH channels. > I thus assume that the reason for wanting to do (2) is that sessions > are expensive when SSH is not used. > > Why are configured subscriptions needed if we have Call-home for both NETCONF and RESTCONF? I prefer 1 mandatory-to-implement RPC instead of duplicated optional solutions. The new feature is really "server initiates notifications upon a reboot", not "configured notifications". > > > /martin > > Andy > > > > > > At a detailed level, I2RS's RFC-7923 has functional requirements for > yang subscriptions. This is what was requested by the WG to be made > available for event notifications. > > as well as various WG meeting minutes. > > > > And of course the existing WG minutes, the four draft document > appendices, and the Dezign team minutes at: > > https://github.com/netconf-wg/yang-push/wiki/Minutes > > Attempts to keep a running list of to-be-resolved dialogs. Of course > there is a lag between dialogs and embodiment in the drafts. > > > > If anyone wants to propose a revision to the requirements, I propose > they do this as deltas from the existing documentation. > > > > Or course we in the WG can and should discuss and tweak any specific > requirement on this mailer based on ongoing learnings over time. > > > > Eric > > > > > /martin > > > --001a114a886895cf8505433b465f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
"Eric Voit (evoit)&quo= t; <evoit@cisco.com> wrote: > > From: Martin Bjorklund, December 9, 2016 3:27 AM
> >
> > "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > Hi Martin,
> > >
> > > > From: Martin Bjorklund, December 8, 2016 4:08 AM
> > > >
> > > > I think your requirements below are more like driving f= orces for
> > > > YANG push, right?=C2=A0 Is there any of these that affe= cts the solution
> > > > in RFC 5277?
> > >
> > > The majority of these cases need yang-push.=C2=A0 But yang p= ush is only
> > > possible when the information is yang modeled.
> >
> > Sure, but that's a completely different thing.
> >
> > This discussion is about what needs to be done with RFC 5277.=C2= =A0 I'll re-iterate
> > what Andy wrote once more:
> >
> >=C2=A0 =C2=A0What are the must-have, should-have, and nice-to-have= features that are
> >=C2=A0 =C2=A0missing from RFC 5277?
>
> At a high level incremental functionality we have been discussing sinc= e IETF 94, 95, 96, 97 includes:
> - configured subscriptions
> - many subscriptions per transport
> - modify and delete subscriptions
> - control plane notifications
> - Restconf & HTTP support
> - Data plan notification including subscription-id
>
> At a medium level, existing documentation detailing these requirements= can be seen in places like:
> https://www.ietf.org/pro= ceedings/95/slides/slides-95-netconf-7.pdf=C2=A0 =C2=A0Slide 5
> https://www.ietf.org/pro= ceedings/96/slides/slides-96-netconf-5.pdf=C2=A0 =C2=A0Slides 5, 2= 8
> https://www.ietf.org/proceedings/97/slides/slides-97-netconf-dra= ft-ietf-netconf-yang-push-01.pdf=C2=A0 Slides 20 & 21

I think the list above summarizes what's in the slides.

So, let me re-order this list a bit:

- configured subscriptions
- many subscriptions per transport
=C2=A0 - Data plan notification including subscription-id
=C2=A0 - modify and delete subscriptions

I don't view "control plane notifications" as a deficiency of= 5277; it
already has a few, and if new functionality requires us to define more
control plane notifications, that's not a problem.

As for "Restconf & HTTP support", RESTCONF already supports notifications, and there need to be a RESTCONF-specific solution in
place.=C2=A0 I do agree that if we open 5277, we should make sure we have a=
small protocol-dependent part, and a generic, protocol-independent
part.

So there are really two (major) requirements:

=C2=A0 1.=C2=A0 configured subscriptions
=C2=A0 2.=C2=A0 many subscriptions per transport session

Do you agree, or did I miss anything?

(1) can be done completely backwards compatible; in fact it might not
even require an update to 5277.

(2) requires an update to the <notification> element, as discussed earlier.

Did you want to make support for (2) mandatory to implement?=C2=A0 If so, we need to make :interleave mandatory, or remove it.

Maybe it should be noted that when SSH is used, there really is no
need for (2), since it is trivial and cheap to open new SSH channels.
I thus assume that the reason for wanting to do (2) is that sessions
are expensive when SSH is not used.



Why are configured subs= criptions needed if we have Call-home for both NETCONF and RESTCONF?
<= div>I prefer 1 mandatory-to-implement RPC instead of duplicated optional so= lutions.
The new feature is really "server initiates notific= ations upon a reboot", not "configured notifications".
=

=C2=A0


/martin



Andy
=C2=A0


>
> At a detailed level, I2RS's RFC-7923 has functional requirements f= or yang subscriptions. This is what was requested by the WG to be made avai= lable for event notifications.
> as well as various WG meeting minutes.
>
> And of course the existing WG minutes, the four draft document appendi= ces, and the Dezign team minutes at:
> https://github.com/netconf-wg/yang-p= ush/wiki/Minutes
> Attempts to keep a running list of to-be-resolved dialogs.=C2=A0 Of co= urse there is a lag between dialogs and embodiment in the drafts.
>
> If anyone wants to propose a revision to the requirements, I propose t= hey do this as deltas from the existing documentation.
>
> Or course we in the WG can and should discuss and tweak any specific r= equirement on this mailer based on ongoing learnings over time.
>
> Eric
>
> > /martin
>

--001a114a886895cf8505433b465f-- From nobody Fri Dec 9 07:29:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AEF1294A0 for ; Fri, 9 Dec 2016 07:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 O2UOW5KNiatR for ; Fri, 9 Dec 2016 07:29:47 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DA9E612945D for ; Fri, 9 Dec 2016 07:29:46 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 23E2F1AE02BC; Fri, 9 Dec 2016 16:29:46 +0100 (CET) Date: Fri, 09 Dec 2016 16:29:45 +0100 (CET) Message-Id: <20161209.162945.891266044701376554.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <5e06ffa5d92a4227ae1d64bc8531ac40@XCH-RTP-013.cisco.com> <20161209.143306.1544319624979225814.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:29:49 -0000 Andy Bierman wrote: > On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund wrote: > > > "Eric Voit (evoit)" wrote: > > > > From: Martin Bjorklund, December 9, 2016 3:27 AM > > > > > > > > "Eric Voit (evoit)" wrote: > > > > > Hi Martin, > > > > > > > > > > > From: Martin Bjorklund, December 8, 2016 4:08 AM > > > > > > > > > > > > I think your requirements below are more like driving forces for > > > > > > YANG push, right? Is there any of these that affects the solution > > > > > > in RFC 5277? > > > > > > > > > > The majority of these cases need yang-push. But yang push is only > > > > > possible when the information is yang modeled. > > > > > > > > Sure, but that's a completely different thing. > > > > > > > > This discussion is about what needs to be done with RFC 5277. I'll > > re-iterate > > > > what Andy wrote once more: > > > > > > > > What are the must-have, should-have, and nice-to-have features that > > are > > > > missing from RFC 5277? > > > > > > At a high level incremental functionality we have been discussing since > > IETF 94, 95, 96, 97 includes: > > > - configured subscriptions > > > - many subscriptions per transport > > > - modify and delete subscriptions > > > - control plane notifications > > > - Restconf & HTTP support > > > - Data plan notification including subscription-id > > > > > > At a medium level, existing documentation detailing these requirements > > can be seen in places like: > > > https://www.ietf.org/proceedings/95/slides/slides-95-netconf-7.pdf > > Slide 5 > > > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf > > Slides 5, 28 > > > https://www.ietf.org/proceedings/97/slides/slides- > > 97-netconf-draft-ietf-netconf-yang-push-01.pdf Slides 20 & 21 > > > > I think the list above summarizes what's in the slides. > > > > So, let me re-order this list a bit: > > > > - configured subscriptions > > - many subscriptions per transport > > - Data plan notification including subscription-id > > - modify and delete subscriptions > > > > I don't view "control plane notifications" as a deficiency of 5277; it > > already has a few, and if new functionality requires us to define more > > control plane notifications, that's not a problem. > > > > As for "Restconf & HTTP support", RESTCONF already supports > > notifications, and there need to be a RESTCONF-specific solution in > > place. I do agree that if we open 5277, we should make sure we have a > > small protocol-dependent part, and a generic, protocol-independent > > part. > > > > So there are really two (major) requirements: > > > > 1. configured subscriptions > > 2. many subscriptions per transport session > > > > Do you agree, or did I miss anything? > > > > (1) can be done completely backwards compatible; in fact it might not > > even require an update to 5277. > > > > (2) requires an update to the element, as discussed > > earlier. > > > > Did you want to make support for (2) mandatory to implement? If so, > > we need to make :interleave mandatory, or remove it. > > > > Maybe it should be noted that when SSH is used, there really is no > > need for (2), since it is trivial and cheap to open new SSH channels. > > I thus assume that the reason for wanting to do (2) is that sessions > > are expensive when SSH is not used. > > > > > > Why are configured subscriptions needed if we have Call-home for both > NETCONF and RESTCONF? The server must be told *when* to call home, right? I assume that the configured subscriptions provides this; i.e., if a notif is generated for a configured subscription, and there is no active session, the server will call home. The client can listen for a while and then hang up (I assume). When a new notif is generated the server will call home again. This does seem a bit complex, and I'm not sure it is needed. But I don't think this solution is well documented in the current set of drafts. /martin > I prefer 1 mandatory-to-implement RPC instead of duplicated optional > solutions. > The new feature is really "server initiates notifications upon a reboot", > not "configured notifications". > > > > > > > > > /martin > > > > > > Andy > > > > > > > > > > > > At a detailed level, I2RS's RFC-7923 has functional requirements for > > yang subscriptions. This is what was requested by the WG to be made > > available for event notifications. > > > as well as various WG meeting minutes. > > > > > > And of course the existing WG minutes, the four draft document > > appendices, and the Dezign team minutes at: > > > https://github.com/netconf-wg/yang-push/wiki/Minutes > > > Attempts to keep a running list of to-be-resolved dialogs. Of course > > there is a lag between dialogs and embodiment in the drafts. > > > > > > If anyone wants to propose a revision to the requirements, I propose > > they do this as deltas from the existing documentation. > > > > > > Or course we in the WG can and should discuss and tweak any specific > > requirement on this mailer based on ongoing learnings over time. > > > > > > Eric > > > > > > > /martin > > > > > From nobody Fri Dec 9 07:51:32 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D290E129864 for ; Fri, 9 Dec 2016 07:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQTIUU5-oRXL for ; Fri, 9 Dec 2016 07:51:28 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 12EE312946A for ; Fri, 9 Dec 2016 07:51:28 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id w33so19454775qtc.3 for ; Fri, 09 Dec 2016 07:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tppenK9y4WI/jP5EyGhAxMy6xGzzRZxc54FcCcHc8Uk=; b=tL6NbgCEsadRCZULOH/crmtgquJhOD1UvnjMDiPWazTOXhG8O5YOt6/R1YBJC8Ks9Y g46dObJ6p7io+6Mo4IGkPM7F3oBo6A82YKiB+VbDyQzq74uDlPe7rRY1eXi/1xgUaljT 0wenvZ3IGmjOu8xdcZikT1ipF0r8U+e5M9gCrSqe6phR/g+wdGsu4/jzm7gTRY44uC2O mLelS7qmG/yog/oQKUOy1qKuXXFhxSQ9s4bhGAjdyds0pQQx3R1v8n7XxOcBY91f7tz5 m8epdqs6awVWGGxLi4S577Ae8M13IJPW+NhshxvYot/3z94mAkRbP+PXsJEsWdtLZ9Li KC7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tppenK9y4WI/jP5EyGhAxMy6xGzzRZxc54FcCcHc8Uk=; b=EYax+khA5KvV8X4uoRJZphWatVOllaD8mLqTeiBOWqaPAOt4Qj5tV8ZDEOoXA+cbTS teot1s/o2EKfIbReQWLLAZxZjMB8NLhd1InM0UoSNPgWuGkZj3Zv5K7WuSZElMhc0RM0 qCiu+8PGwko4VoaWRlNyPF30xOETUGPrQS6RZE1encUgXL7fLeMy+IdA/mggL98hJQuq iQPk4GLmJDYYFtBnVQ8M+tZXGdmrE/tbySX1S1WRTf4Gq4pKpCpgrLMx53orpz/VKQXJ GiNRswHtFOnkq2j0U6zbBeFK7pDkF7jheitqle6J0ZvKF5+OqjihUtURpEPv6jdfoFPK IN6Q== X-Gm-Message-State: AKaTC03PsVVMIoWPvhVVKTbiw6UZcbzuG3h8jlhunc/Izj0Qoy3TN8tvLAJkcBeKUXlQ+0ViRIZZp6q4LRb90A== X-Received: by 10.200.37.7 with SMTP id 7mr79316164qtm.102.1481298687146; Fri, 09 Dec 2016 07:51:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Fri, 9 Dec 2016 07:51:26 -0800 (PST) In-Reply-To: <20161209.162945.891266044701376554.mbj@tail-f.com> References: <5e06ffa5d92a4227ae1d64bc8531ac40@XCH-RTP-013.cisco.com> <20161209.143306.1544319624979225814.mbj@tail-f.com> <20161209.162945.891266044701376554.mbj@tail-f.com> From: Andy Bierman Date: Fri, 9 Dec 2016 07:51:26 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1141f99e0dd21e05433bbafd Archived-At: Cc: Netconf Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:51:31 -0000 --001a1141f99e0dd21e05433bbafd Content-Type: text/plain; charset=UTF-8 On Fri, Dec 9, 2016 at 7:29 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund wrote: > > > > > "Eric Voit (evoit)" wrote: > > > > > From: Martin Bjorklund, December 9, 2016 3:27 AM > > > > > > > > > > "Eric Voit (evoit)" wrote: > > > > > > Hi Martin, > > > > > > > > > > > > > From: Martin Bjorklund, December 8, 2016 4:08 AM > > > > > > > > > > > > > > I think your requirements below are more like driving forces > for > > > > > > > YANG push, right? Is there any of these that affects the > solution > > > > > > > in RFC 5277? > > > > > > > > > > > > The majority of these cases need yang-push. But yang push is > only > > > > > > possible when the information is yang modeled. > > > > > > > > > > Sure, but that's a completely different thing. > > > > > > > > > > This discussion is about what needs to be done with RFC 5277. I'll > > > re-iterate > > > > > what Andy wrote once more: > > > > > > > > > > What are the must-have, should-have, and nice-to-have features > that > > > are > > > > > missing from RFC 5277? > > > > > > > > At a high level incremental functionality we have been discussing > since > > > IETF 94, 95, 96, 97 includes: > > > > - configured subscriptions > > > > - many subscriptions per transport > > > > - modify and delete subscriptions > > > > - control plane notifications > > > > - Restconf & HTTP support > > > > - Data plan notification including subscription-id > > > > > > > > At a medium level, existing documentation detailing these > requirements > > > can be seen in places like: > > > > https://www.ietf.org/proceedings/95/slides/slides-95-netconf-7.pdf > > > Slide 5 > > > > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf > > > Slides 5, 28 > > > > https://www.ietf.org/proceedings/97/slides/slides- > > > 97-netconf-draft-ietf-netconf-yang-push-01.pdf Slides 20 & 21 > > > > > > I think the list above summarizes what's in the slides. > > > > > > So, let me re-order this list a bit: > > > > > > - configured subscriptions > > > - many subscriptions per transport > > > - Data plan notification including subscription-id > > > - modify and delete subscriptions > > > > > > I don't view "control plane notifications" as a deficiency of 5277; it > > > already has a few, and if new functionality requires us to define more > > > control plane notifications, that's not a problem. > > > > > > As for "Restconf & HTTP support", RESTCONF already supports > > > notifications, and there need to be a RESTCONF-specific solution in > > > place. I do agree that if we open 5277, we should make sure we have a > > > small protocol-dependent part, and a generic, protocol-independent > > > part. > > > > > > So there are really two (major) requirements: > > > > > > 1. configured subscriptions > > > 2. many subscriptions per transport session > > > > > > Do you agree, or did I miss anything? > > > > > > (1) can be done completely backwards compatible; in fact it might not > > > even require an update to 5277. > > > > > > (2) requires an update to the element, as discussed > > > earlier. > > > > > > Did you want to make support for (2) mandatory to implement? If so, > > > we need to make :interleave mandatory, or remove it. > > > > > > Maybe it should be noted that when SSH is used, there really is no > > > need for (2), since it is trivial and cheap to open new SSH channels. > > > I thus assume that the reason for wanting to do (2) is that sessions > > > are expensive when SSH is not used. > > > > > > > > > > Why are configured subscriptions needed if we have Call-home for both > > NETCONF and RESTCONF? > > The server must be told *when* to call home, right? I assume that the > configured subscriptions provides this; i.e., if a notif is generated > for a configured subscription, and there is no active session, the > server will call home. The client can listen for a while and then > hang up (I assume). When a new notif is generated the server will > call home again. This does seem a bit complex, and I'm not sure it is > needed. > > It would be configured in the call-home configuration. I think that is 1 of Kent's server modules. The general re-connect strategy for call-home should control this behavior. > But I don't think this solution is well documented in the current set > of drafts. > > /martin > Andy > > > > I prefer 1 mandatory-to-implement RPC instead of duplicated optional > > solutions. > > The new feature is really "server initiates notifications upon a reboot", > > not "configured notifications". > > > > > > > > > > > > > > > /martin > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > At a detailed level, I2RS's RFC-7923 has functional requirements for > > > yang subscriptions. This is what was requested by the WG to be made > > > available for event notifications. > > > > as well as various WG meeting minutes. > > > > > > > > And of course the existing WG minutes, the four draft document > > > appendices, and the Dezign team minutes at: > > > > https://github.com/netconf-wg/yang-push/wiki/Minutes > > > > Attempts to keep a running list of to-be-resolved dialogs. Of course > > > there is a lag between dialogs and embodiment in the drafts. > > > > > > > > If anyone wants to propose a revision to the requirements, I propose > > > they do this as deltas from the existing documentation. > > > > > > > > Or course we in the WG can and should discuss and tweak any specific > > > requirement on this mailer based on ongoing learnings over time. > > > > > > > > Eric > > > > > > > > > /martin > > > > > > > > --001a1141f99e0dd21e05433bbafd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 9, 2016 at 7:29 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > > From: Martin Bjorklund, December 9, 2016 3:27 AM
> > > >
> > > > "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > > > Hi Martin,
> > > > >
> > > > > > From: Martin Bjorklund, December 8, 2016 4:08= AM
> > > > > >
> > > > > > I think your requirements below are more like= driving forces for
> > > > > > YANG push, right?=C2=A0 Is there any of these= that affects the solution
> > > > > > in RFC 5277?
> > > > >
> > > > > The majority of these cases need yang-push.=C2=A0 = But yang push is only
> > > > > possible when the information is yang modeled.
> > > >
> > > > Sure, but that's a completely different thing.
> > > >
> > > > This discussion is about what needs to be done with RFC= 5277.=C2=A0 I'll
> > re-iterate
> > > > what Andy wrote once more:
> > > >
> > > >=C2=A0 =C2=A0What are the must-have, should-have, and ni= ce-to-have features that
> > are
> > > >=C2=A0 =C2=A0missing from RFC 5277?
> > >
> > > At a high level incremental functionality we have been discu= ssing since
> > IETF 94, 95, 96, 97 includes:
> > > - configured subscriptions
> > > - many subscriptions per transport
> > > - modify and delete subscriptions
> > > - control plane notifications
> > > - Restconf & HTTP support
> > > - Data plan notification including subscription-id
> > >
> > > At a medium level, existing documentation detailing these re= quirements
> > can be seen in places like:
> > > https://www.ietf.or= g/proceedings/95/slides/slides-95-netconf-7.pdf
> >=C2=A0 Slide 5
> > > https://www.ietf.or= g/proceedings/96/slides/slides-96-netconf-5.pdf
> >=C2=A0 Slides 5, 28
> > > https://www.ietf.org/proceedin= gs/97/slides/slides-
> > 97-netconf-draft-ietf-netconf-yang-push-01.pdf=C2=A0 Slides = 20 & 21
> >
> > I think the list above summarizes what's in the slides.
> >
> > So, let me re-order this list a bit:
> >
> > - configured subscriptions
> > - many subscriptions per transport
> >=C2=A0 =C2=A0- Data plan notification including subscription-id > >=C2=A0 =C2=A0- modify and delete subscriptions
> >
> > I don't view "control plane notifications" as a def= iciency of 5277; it
> > already has a few, and if new functionality requires us to define= more
> > control plane notifications, that's not a problem.
> >
> > As for "Restconf & HTTP support", RESTCONF already = supports
> > notifications, and there need to be a RESTCONF-specific solution = in
> > place.=C2=A0 I do agree that if we open 5277, we should make sure= we have a
> > small protocol-dependent part, and a generic, protocol-independen= t
> > part.
> >
> > So there are really two (major) requirements:
> >
> >=C2=A0 =C2=A01.=C2=A0 configured subscriptions
> >=C2=A0 =C2=A02.=C2=A0 many subscriptions per transport session
> >
> > Do you agree, or did I miss anything?
> >
> > (1) can be done completely backwards compatible; in fact it might= not
> > even require an update to 5277.
> >
> > (2) requires an update to the <notification> element, as di= scussed
> > earlier.
> >
> > Did you want to make support for (2) mandatory to implement?=C2= =A0 If so,
> > we need to make :interleave mandatory, or remove it.
> >
> > Maybe it should be noted that when SSH is used, there really is n= o
> > need for (2), since it is trivial and cheap to open new SSH chann= els.
> > I thus assume that the reason for wanting to do (2) is that sessi= ons
> > are expensive when SSH is not used.
> >
> >
>
> Why are configured subscriptions needed if we have Call-home for both<= br> > NETCONF and RESTCONF?

The server must be told *when* to call home, right?=C2=A0 I assume that the=
configured subscriptions provides this; i.e., if a notif is generated
for a configured subscription, and there is no active session, the
server will call home.=C2=A0 The client can listen for a while and then
hang up (I assume).=C2=A0 When a new notif is generated the server will
call home again.=C2=A0 This does seem a bit complex, and I'm not sure i= t is
needed.


It would be configured in the call-hom= e configuration.
I think that is 1 of Kent's server modules.<= /div>

The general re-connect strategy for call-home shou= ld control this behavior.

=C2=A0
But I don't think this solution is well documented in the current set of drafts.=C2=A0


/martin


Andy
= =C2=A0


> I prefer 1 mandatory-to-implement RPC instead of duplicated optional > solutions.
> The new feature is really "server initiates notifications upon a = reboot",
> not "configured notifications".
>
>
>
> >
> >
> > /martin
> >
> >
>
> Andy
>
>
> >
> >
> > >
> > > At a detailed level, I2RS's RFC-7923 has functional requ= irements for
> > yang subscriptions. This is what was requested by the WG to be ma= de
> > available for event notifications.
> > > as well as various WG meeting minutes.
> > >
> > > And of course the existing WG minutes, the four draft docume= nt
> > appendices, and the Dezign team minutes at:
> > > https://github.com/netconf-wg/yang-push/wiki/Minutes
> > > Attempts to keep a running list of to-be-resolved dialogs.= =C2=A0 Of course
> > there is a lag between dialogs and embodiment in the drafts.
> > >
> > > If anyone wants to propose a revision to the requirements, I= propose
> > they do this as deltas from the existing documentation.
> > >
> > > Or course we in the WG can and should discuss and tweak any = specific
> > requirement on this mailer based on ongoing learnings over time.<= br> > > >
> > > Eric
> > >
> > > > /martin
> > >
> >

--001a1141f99e0dd21e05433bbafd-- From nobody Fri Dec 9 15:30:13 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B861295BA for ; Fri, 9 Dec 2016 15:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdApLYBXqhRr for ; Fri, 9 Dec 2016 15:30:08 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB66A1279EB for ; Fri, 9 Dec 2016 15:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=88578; q=dns/txt; s=iport; t=1481326207; x=1482535807; h=from:to:cc:subject:date:message-id:mime-version; bh=c0tAdNKQ4I2QD6RZoPBalms6XaJ37eSpga2wHncQKq8=; b=OzGbKB8JcwOYIFr71s3hd8mfSPT5/TiC4coKgCQZgDGTX11QC4WUpmuT KEkXA3pLCQfx2h4mf0fS2Hl9XP9KL2ZBKy9mk3f/nmNm5AnDDWr2L7+iI +XT6auGk9OskbrwMWBpbgYgj+dBK+iZhQG/FUCOagWZrRVJdvYDtkAW/p w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQD0PUtY/4wNJK1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJzRAEBAQEBH1qBBgeNQpcUlQKCCimFeAIagUw/FAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQMBARoBCApKAgUNAQYTBAEBDhMBBgMCBDAUCQkBBA4FCBIBiEgID?= =?us-ascii?q?o1gnUqCKYsiAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGPoNThSAJBA1Mgk6CPx4?= =?us-ascii?q?FiHSGDYFChD2FawGBSY9OgXyOUodmhiWEDQEfNzBxJIM8HBiBRXIBhhkBJYEKg?= =?us-ascii?q?Q0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="scan'208,217";a="358997437" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2016 23:30:05 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uB9NU5O6010173 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Dec 2016 23:30:05 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 18:30:04 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 9 Dec 2016 18:30:04 -0500 From: "Eric Voit (evoit)" To: Andy Bierman Thread-Topic: Filter construction (was RE: [Netconf] review of "event-notification" documents) Thread-Index: AdJSdCSaSF+UTkJSRBOZkyJdg/DiEA== Date: Fri, 9 Dec 2016 23:30:04 +0000 Message-ID: <4fab79c122c24e0ab2300d47d7f72b3e@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_4fab79c122c24e0ab2300d47d7f72b3eXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , "alex@clemm.org" Subject: [Netconf] Filter construction (was RE: review of "event-notification" documents) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 23:30:12 -0000 --_000_4fab79c122c24e0ab2300d47d7f72b3eXCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhlIGlzIGEgbG90IGludGVyZXN0aW5nIGluIHlvdXIgZmlsdGVyLnlhbmcg ZmlsZS4gIElmIHRoZSBXRyBkZXNpcmVzIHRvIGdvIGJleW9uZCB0aGUgZXhpc3Rpbmcgc3VidHJl ZSBmaWx0ZXJpbmcgJiB4cGF0aCBtZWNoYW5pc21zLCB3ZSBzaG91bGQgZGV0ZXJtaW5lIGlmIHdl IGNhbiB1c2UgdGhpcyBhcyBhIGJhc2UuICBCdXQgaWYgd2UgZ28gZG93biB0aGlzIHBhdGggaXQg d2lsbCB0YWtlIHNvbWUgdGltZSB0byBnZXQgdGhpcyByaWdodC4gIEFuZCBpZiB3ZSBkbyB0aGlz LCB3ZSBzaG91bGQgc3RydWN0dXJlIGFsbCBkcmFmdHMgc28gdGhhdCBmaWx0ZXJzIGNhbiBiZSBl eHRlbmRlZCBvdmVyIHRpbWUgd2l0aG91dCBuZWVkaW5nIHRvIG1vcnBoIHRoZSBzdWJzY3JpcHRp b25zIGRyYWZ0cy4NCg0KTXkgaW5pdGlhbCB0YWtlIG9uIHRoaXMgaXMgdGhhdCBpZiB3ZSBjaG9v c2UgdG8gcHVyc3VlIGZpbHRlci55YW5nLCBsYW5kaW5nIGZpbHRlcnMueWFuZyBhcyBhIHNlcGFy YXRlIG1vZGVsL2RyYWZ0IG1ha2VzIHNlbnNlLiAgUHV0IHNpbXBseSwgZmlsdGVycyBuZWVkIG5v dCBiZSBzdWJzY3JpcHRpb24gc3BlY2lmaWMuICAgSW4gZmFjdCwgaGF2aW5nIHByZWRlZmluZWQs IGRlY291cGxlZCBmaWx0ZXJzIG9uIGRldmljZSBldmVuIGZvciBhIG5vcm1hbCBHRVQgY2FuIGdv IGEgbG9uZyB3YXkgdG8gZW5zdXJpbmcgdGhhdCBhbnkgc3BlY2lmaWMgZmlsdGVyIGhhcyBiZWVu IHByZXF1YWxpZmllZCBhcyBub3QgYmVpbmcgcmVzb3VyY2UtcHJvaGliaXRpdmUuDQoNClNvIGhv dyBtaWdodCB3ZSBpbnRlZ3JhdGUgc3Vic2NyaXB0aW9ucyBhbmQgZmlsdGVycy55YW5nPzoNCi0g Zm9yIHBlcnNpc3RlbnQgZmlsdGVycyB0aGF0IGFyZSBpbmRlcGVuZGVudCBvZiB0aGUgc3Vic2Ny aXB0aW9uIGxpZmVjeWNsZTogdGhlIHN1YnNjcmlwdGlvbuKAmXMgZmlsdGVyLXJlZiBjYW4gcG9p bnQgdG8gYSBzdGFuZC1hbG9uZSB5YW5nIGZpbHRlciBtb2RlbCBpbiBhbiBpbXBvcnRlZCBmaWx0 ZXIueWFuZw0KLSBmb3IgZmlsdGVycyB3aGljaCBzaG91bGQgb25seSBleGlzdCBhcyBwYXJ0IG9m IHRoZSBsaWZlY3ljbGUgb2YgYSBzdWJzY3JpcHRpb246IHBlcmhhcHMgZG8gYSBzY2hlbWEgbW91 bnQgb2YgZmlsdGVyLnlhbmc/IFRoZSBtb3VudGVkIHNjaGVtYSBjYW4gYmUgdXNlZCB0byBhY2Nl cHQgaW5wdXQgZnJvbSBhbiBSUEMgYW5kIHN0b3JlIGl0IGFzIGEgdHJhbnNpZW50IGluLWxpbmUg ZmlsdGVyLiAgSS5lLiwgdGhpcyB3YXkgdGhlIGNvbnRlbnRzIG9mIHRoZSBpbmxpbmUgZmlsdGVy cyB3aWxsIG5vdCBwZXJzaXN0IGxvbmdlciB0aGFuIHRoZSBzdWJzY3JpcHRpb24uICAoSXMgdGhl cmUgYSB3YXkgdG8gZG8gdGhpcyB3aXRoIGdyb3VwaW5ncy9hdWdtZW50YXRpb25zIHNvIHRoYXQg c2NoZW1hIG1vdW50IGlzbuKAmXQgbmVlZGVkPykNCg0KSSBzdXNwZWN0IGJ5IGFwcHJvYWNoaW5n IHRoZSBpbnRlZ3JhdGlvbiBpbiB0aGlzIHdheSwgaXQgaXMgcG9zc2libGUgdG8gZXZvbHZlIGZp bHRlci55YW5nIHdpdGhvdXQgZGlyZWN0bHkgY2hhbmdpbmcgdGhlIHN1YnNjcmlwdGlvbiBtb2Rl bC4gIChUaGUgb25seSB0aGluZyB3b3VsZCBiZSB0aGF0IHlvdSBoYXZlIHRvIHJldiBpcyB0byBh IG5ldyBtb2RlbCB2ZXJzaW9uLikNCg0KQmV5b25kIHRoaXMgaW50ZWdyYXRpb24gc3BlY3VsYXRp b24sIGJlbG93IGFyZSBzb21lIHRob3VnaHRzIG9uIHNwZWNpZmljIGVsZW1lbnRzIG9mIHlvdXIg 4oCcZmlsdGVycy55YW5n4oCZIGF0dGFjaG1lbnQ6DQoNCsK3ICAgICAgIExpbmUgMjk6IGlmLWZl YXR1cmUtc3RtdC1zdHIgc2hvdWxkIGJlIGlmLWZlYXR1cmUtc3RtdCwgY29ycmVjdD8NCg0Kwrcg ICAgICAgTGluZSA0MTogaWYtZmlsdGVyLWZhY3RvciBzaG91bGQgYmUgZmlsdGVyLWZhY3Rvciwg Y29ycmVjdD8NCg0KwrcgICAgICAgTGluZSA1NjogbWl4ZWQgbWV0YXBob3Igb2YgYS9iL2MgYW5k IDEvMi8zLg0KDQrCtyAgICAgICBMaW5lIDIwOiB3ZSBsaWtlbHkgbmVlZCBhbiBpZGVudGl0eSBm b3IgYSBzdHJlYW0gc28gdGhhdCBpdCBjYW4gYmUgdXNlZCBhcyBhIGZpbHRlci10ZXJtDQoNCsK3 ICAgICAgIFRoZSBzZXQgb2Ygb3BlcmF0b3JzIGlzIOKAmGFuZOKAmSwg4oCYb3LigJkuICBUaGVy ZSBpcyBhbHNvIGZhY3RvcmluZyB3aXRoIOKAmCjigJggYW5kIOKAmCnigJkuICBCdXQgdGhlIG1h am9yaXR5IG9mIHhwYXRoIG9wZXJhdG9ycyBhbmQgc3ludGF4IGlzIG5vdCBpbmNsdWRlZC4gIFdo aWNoIGlzIGEgZ29vZCB0aGluZy4gIEFzIGZpbHRlcnMgYXJlIG5vdCBuZWNlc3NhcmlseSBib29s ZWFuIGl0IG1pZ2h0IGJlIGludGVyZXN0aW5nIHRvIGZpZ3VyZSBvdXQgd2hhdCBvdGhlciBlbGVt ZW50cyBtaWdodCBiZSBuZWVkZWQuICBUaGlzIHdpbGwgdGFrZSBzb21lIHRpbWUgdG8gZG8gcmln aHQuDQoNCsK3ICAgICAgIEkgYW0gbm90IGNhdGNoaW5nIGFsbCB0aGUgc3VidGx0aWVzIGhlcmUu ICBDb3VsZCB5b3UgcmV2aWV3IHRoaXMgb24gdGhlIG5leHQgRGV6aWduIHRlYW0gY2FsbD8NCg0K wrcgICAgICAgV2UgcHJvYmFibHkgZGlzY3VzcyB3aGV0aGVyIHdlIHdhbnQgdG8gbGltaXQgdGhl IGFsbG93YWJsZSBhbW91bnQgb2YgbmVzdGluZyB3aXRoaW4gdGhlIGZpbHRlcmluZyBzeW50YXgu ICBSRkMgNTI3NyBkaWRu4oCZdCBkbyBzdWNoIGxpbWl0aW5nLiAgQW5kIHdpdGhvdXQga25vd2lu ZyB0aGUgYSBkZXNpcmVkIGZpbHRlciBjcml0ZXJpYSB3aGljaCBjYW4gYmUgYXBwbGllZCBhZ2Fp bnN0IHJhbmRvbSBjb2xsZWN0aW9ucyBvZiBvYmplY3RzLCBJIHN1Z2dlc3Qgd2UgZG9u4oCZdCBh dHRlbXB0IHRoaXMgZWl0aGVyLiAgUGVyaGFwcyBzb21lb25lIGluIHRoZSBmdXR1cmUgY2FuIGRl ZmluZSBhIG1pbmltYWwgc2V0IG9mIG5lc3Rpbmcgd2hpY2ggbXVzdCBiZSBzdXBwb3J0ZWQgaWYg c29tZW9uZSBkZXNpcmVzIGZvciB0aGUgZmlsdGVycyB0aGVtc2VsdmVzIHRvIGJlIHBvcnRhYmxl IGFjcm9zcyBpbXBsZW1lbnRhdGlvbnMuDQoNCsK3ICAgICAgIEZvciB0aGUgaWRlbnRpdHkgbmV0 Y29uZi1zdHJlYW0sIHlvdSByZWZlciB0byBSRkM1Mjc3IHNlYyAzLjIuICBJZiB0aGlzIGlzIGJl aW5nIG9ic29sZXRlZCwgZG8gd2UgbmVlZCBhbm90aGVyIGRlZmluaXRpb24gc291cmNlPyAoQXMg dGhlIOKAmG9ic29sZXRl4oCZIGRpc2N1c3Npb24gaGFwcGVuZWQgYWZ0ZXIgeW91IHdyb3RlIHRo ZSBmaWx0ZXIueWFuZywgcGVyaGFwcyB0aGlzIGNhbiBqdXN0IGJlIHJlbW92ZWQgaWYgd2UgZ28g dG8g4oCYb2Jzb2xldGXigJk/KQ0KDQpBbnl3YXkgdGhlcmUgaXMgdGhlIHN0YXJ0ZXIgdGhpbmtp bmcgSSBwcm9taXNlZC4gIExldOKAmXMgY2hhdCBtb3JlIGlmIHlvdSBhcmUgd2lsbGluZyB0byBy ZXZpZXcgdGhpcyBvbiB0aGUgV2VkIGNhbGwuDQoNCkVyaWMNCg0KRnJvbTogQW5keSBCaWVybWFu IFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDEs IDIwMTYgMTo0MSBQTQ0KVG86IEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb20+DQpD YzogQmFsYXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT4gKGJhbGF6cy5s ZW5neWVsQGVyaWNzc29uLmNvbSkgPGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT47IGFsZXhA Y2xlbW0ub3JnOyBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT47IEFsYmVydG8gR29u emFsZXogUHJpZXRvIChhbGJlcnRnbykgPGFsYmVydGdvQGNpc2NvLmNvbT47IG5ldGNvbmZAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gcmV2aWV3IG9mICJldmVudC1ub3RpZmljYXRp b24iIGRvY3VtZW50cw0KDQpIaSwNCg0KSSB3b3JrZWQgb24gdGhlIGZpbHRlcmluZyBwcm9ibGVt IGEgYml0IG1vcmUuDQpIZXJlIGlzIGZpbHRlci55YW5nLCBhIGZpbHRlcmluZyBmcmFtZXdvcmss IGFuZCB0b3BpYy55YW5nLCBhbmQgZXhhbXBsZSBvZiBhIGZpbHRlciB0eXBlDQp0aGF0IGNhbiBi ZSB1c2VkIGluIGZpbHRlci55YW5nLiBUb3BpYy1iYXNlZCBmaWx0ZXJpbmcgd2FzIGJyaWVmbHkg ZGlzY3Vzc2VkIGluIFNlb3VsLg0KDQpJTU8gZmlsdGVycyB3aWxsIGNvbnRpbnVlIHRvIGV2b2x2 ZSBvdmVyIHRpbWUgc28gdGhlIHNvbHV0aW9uIG5lZWRzIHRvIGFsbG93DQp0aGVtIHRvIGJlIGFk ZGVkIGFuZCBjb21iaW5lZCB3aXRoIG90aGVyIGZpbHRlcnMuICBUaGUgY3VycmVudCBZQU5HIGNo b2ljZS1zdG10DQppcyBub3QgZXh0ZW5zaWJsZSBlbm91Z2ggb3IgcG93ZXJmdWwgZW5vdWdoLg0K DQoNCkFuZHkNCg0KDQpPbiBUdWUsIE5vdiAyOSwgMjAxNiBhdCA3OjExIFBNLCBFcmljIFZvaXQg KGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5jb20+PiB3cm90ZToN CkZyb206IEFuZHkgQmllcm1hbiwgTm92ZW1iZXIgMjksIDIwMTYgODozMCBQTQ0KT24gVHVlLCBO b3YgMjksIDIwMTYgYXQgODowNSBBTSwgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNv bTxtYWlsdG86ZXZvaXRAY2lzY28uY29tPj4gd3JvdGU6DQpUaGFua3MgTWFydGluLA0KDQpNb3Jl IGluIGxpbmUuICAgQWxzbyBJIGV4dHJhY3RlZCBhcmVhcyB3aGVyZSB3ZSBhbHJlYWR5IGFncmVl IHRvIG1ha2UgdGhpcyBlYXNpZXIgdG8gZm9sbG93Lg0KDQo+IEZyb206IE1hcnRpbiBCam9ya2x1 bmQsIE5vdmVtYmVyIDI5LCAyMDE2IDY6NDAgQU0NCj4gPiA+SWYgSSB1bmRlcnN0YW5kIHRoZSBp bnRlbnRpb24gY29ycmVjdGx5LCB0aGlzIGRvY3VtZW50IGlzIHN1cHBvc2VkIHRvDQo+ID4gPipk ZWZpbmUqIGhvdyBub3RpZmljYXRpb25zIGFyZSBzZW50IG92ZXIgTkVUQ09ORi4gIEJ1dCB0aGVy ZSBpcyBubw0KPiA+ID5zdWNoIGRlZmluaXRpb24gaW4gdGhpcyBkb2N1bWVudC4gIEluc3RlYWQg aXQgc2ltcGx5IHJlcGVhdHMNCj4gPiA+aW5mb3JtYXRpb24gYWxyZWFkeSBkZWZpbmVkIGluIGRy YWZ0LWlldGYtbmV0Y29uZi1yZmM1Mjc3YmlzLTAxLnR4dCwNCj4gPiA+YW5kIHByb3ZpZGVzIGxv dHMgb2YgZXhhbXBsZXMgb2YgaG93IHRoZSBZQU5HIG9wZXJhdGlvbnMgZGVmaW5lZCBpbg0KPiA+ ID5yZmM1Mjc3YmlzIGFyZSBlbmNvZGVkIGluIFhNTCBhbmQgc2VudCBvdmVyIE5FVENPTkYuDQo+ ID4gPg0KPiA+ID5JIHN1Z2dlc3QgdGhhdCB0aGlzIGRvY3VtZW50IGlzIHJld3JpdHRlbi4gIFNp bmNlIHRoZSBpZGVhIGlzIHRvDQo+ID4gPnJlcGxhY2UgUkZDIDUyNzcsIGl0IG5lZWRzIHRvIGZv Y3VzIG9uIGhvdyBub3RpZmljYXRpb25zIGFyZSBzZW50DQo+ID4gPm92ZXIgTkVUQ09ORiwgYW5k IG5vdCBob3cgUlBDcyBhcmUgZW5jb2RlZCBpbiBYTUwuDQo+ID4gSSBhZ3JlZSAtLSBtYXliZSBn ZXQgcmlkIG9mIGl0IGFuZCBqdXN0IGhhdmUgcmZjNTI3N2JpcyBjb250YWluIHRoaXMNCj4gPiB0 ZXh0DQo+ID4NCj4gPiA8ZXY+IDUyNzdiaXMgaXMgc3VwcG9zZWQgdG8gYWxsb3cgdHJhbnNwb3J0 cyBvdGhlciB0aGFuIE5FVENPTkYuICBJZiB3ZSBwdXQNCj4gdGhlIE5FVENPTkYgc3BlY2lmaWMg c3R1ZmYgaW4gaGVyZSB3ZSBsb3NlIHRoYXQgc2VwYXJhdGlvbi4NCj4NCj4gV2UgbmVlZCAqc29t ZSogZG9jdW1lbnQgdGhhdCBkZWZpbmVzIGhvdyBub3RpZmljYXRpb25zIGFyZSBzZW50IG92ZXIN Cj4gTkVUQ09ORi4gIFRoaXMgZG9jdW1lbnQgbmVlZHMgdG8gaGF2ZSB0aGUgc3BlY2lmaWNhdGlv biBmb3IgdGhlIDxub3RpZmljYXRpb24+DQo+IGVsZW1lbnQuDQo+DQo+IFRoZW4gd2UgbmVlZCBh IHByb3RvY29sLWluZGVwZW5kZW50IGRvY3VtZW50IHRoYXQgZGVmaW5lcyB0aGUgY29uY2VwdCBv Zg0KPiBzdHJlYW1zIGFuZCBzdWJzY3JpcHRpb25zLCBzdHJlYW0gZGlzY292ZXJ5LCBldGMuDQo+ DQo+IEkgKnRoaW5rKiB0aGF0IHlvdXIgaW50ZW50aW9uIGlzIHRoYXQgbmV3IGNsaWVudHMgcmVh bGx5IHNob3VsZCBiZSB1c2luZw0KPiA8ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbj4gaW5zdGVhZCBv ZiA8Y3JlYXRlLXN1YnNjcmlwdGlvbj4sIHNpbmNlIGl0IGlzIHByb3RvY29sLQ0KPiBpbmRlcGVu ZGVudCBhbmQgc3VwcG9ydCBtb2RpZmljYXRpb24gYW5kIGRlbGV0aW9uLg0KPg0KPiBJZiB3ZSBh bHNvIHdhbnQgdG8gYmUgZnVsbHkgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCA1Mjc3LCBJIHRo aW5rIHdlIHNob3VsZA0KPiBjcmVhdGUgYSBkb2N1bWVudCB0aGF0IGlzIG11Y2ggY2xvc2VyIHRv IHRoZSBjdXJyZW50IDUyNzcgLSBlc3NlbnRpYWxseSBqdXN0DQo+IGNyZWF0aW5nIGEgWUFORyBt b2RlbCBmb3IgdGhlIGNvbmZpZyBmYWxzZSBkYXRhIGFuZCBmb3IgdGhlICJvbGQiIDxjcmVhdGUt DQo+IHN1YnNjcmlwdGlvbj4uDQoNCldlIGFic29sdXRlbHkgd2FudCB0byBoYXZlIGEgZnVsbCBi YWNrd2FyZHMgY29tcGF0aWJsZSBjYXBhYmlsaXR5LiAgVGhlIHF1ZXN0aW9uIGlzIGhvdyB0byBi ZXN0IGZyYW1lIHRoaXMgaW4gZG9jdW1lbnRzLiAgSXQgaXMgcG9zc2libGUgdG8gcmVidWlsZCBS RkMtNTI3NyB3aXRoIGEgWUFORyBtb2RlbC4gIEJ1dCB0aGVuIHlvdSBjYW4ndCBqdXN0IGxheWVy IG9uIG5ldyBjYXBhYmlsaXRpZXMgZHJpdmluZyB0aGlzIHdvcmsuICAoQW5kIHRoaXMgaXMgd2h5 IHdlIG5lZWQgc2VwYXJhdGUgbmFtZXNwYWNlcy4pDQoNCg0KV2UgbmVlZCB0byBwYXJzZSBhbmQg dW5kZXJzdGFuZCAiZnVsbCBiYWNrd2FyZHMgY29tcGF0aWJsZSIuDQoNCkRvIHdlIHdhbnQgZXhp c3RpbmcgaW1wbGVtZW50YXRpb25zIHRvIGJlIGxldmVyYWdlZCBpbnRvIHRoZSBuZXcgc29sdXRp b24/ICBZZXMNCkEgc2VydmVyIHNob3VsZCBiZSBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgPGNyZWF0 ZS1zdWJzY3JpcHRpb24+IGZvcg0Kb2xkLCBkZXByZWNhdGVkIHN1YnNjcmlwdGlvbnMsIGFuZCA8 ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbj4gZm9yIHRoZSBuZXcgY3VycmVudCBzdWJzY3JpcHRpb25z Lg0KDQpEbyB3ZSBuZWVkIHRvIHVwZGF0ZSBSRkMgNTI3NyBvciByZXBsYWNlIGl0PyBJTU8sIHJl cGxhY2UgaXQuDQpTaW5jZSB0aGUgPGNyZWF0ZS1zdWJzY3JpcHRpb24+IFJQQyB3YXMgbmV2ZXIg aW4gYSBZQU5HIG1vZHVsZSwNCml0IGNhbiBiZSBsZWZ0IG91dCBvZiB0aGUgbmV3IG1vZHVsZS4N Cg0KPGV2PiBJIGJlbGlldmUgYXQgbWluaW11bSB0aGF0IDxjcmVhdGUgc3Vic2NyaXB0aW9uPiBz aG91bGQgYmUgcHVsbGVkIG91dCBvZiB0aGUgbmV3IG1vZHVsZS4gIEl0IG5lZWRzIGl0cyBzZXBh cmF0ZSBuYW1lc3BhY2UuICAgUGVyaGFwcyBub2JvZHkgaXMgcmVhZHkgdG8gYWR2b2NhdGUgZm9y IGEgcGFyYWxsZWwgNTI3Ny1sZWdhY3kgWUFORyBtb2RlbCBzaW5jZSBuZXcgZGV2ZWxvcG1lbnQg c2hvdWxkIGdvIHRvIHRoZSBuZXcgcGFyYWRpZ20gYW55d2F5LiAgSW4gdGhpcyBjYXNlLCB3ZSBj b3VsZCBqdXN0IGhhdmUgYSBzdGFuZGFsb25lIGxlZ2FjeSA1Mjc3IHNlY3Rpb24gaW4gdGhlIGRv Y3VtZW50IGZvciBhbnl0aGluZyBuZWVkZWQuICBUaGlzIHdvdWxkIG1ha2UgdGhpbmdzIHNpbXBs ZXIgYW5kIGVhc2llciB0byB0ZWFzZSBhcGFydC4NCg0KRXZlbiBtb3JlIHJhZGljYWwsIEkgdGhp bmsgc3RyZWFtcyBzaG91bGQgYmUgcmVtb3ZlZCwgZXZlbiB0aGUgTkVUQ09ORiBzdHJlYW0uDQpU aGV5IHJlYWxseSBzZXJ2ZSBubyBwdXJwb3NlIG5vdyB0aGF0IHN1YnNjcmlwdGlvbnMgYXJlIGZv cm1hbGl6ZWQgYW5kIGNhbg0KZXZlbiBiZSBjb25maWd1cmVkLiAgSXQgaXMgYWxzbyBiYWQgZGVz aWduIHRvIGNvdXBsZSB0aGUgb3V0cHV0IG1lc3NhZ2UgZW5jb2RpbmcNCmludG8gdGhlIGlucHV0 IHN0cmVhbS4gKGUuZy4sIE5FVENPTkYgc3RyZWFtIE1VU1QgYmUgWE1MIGVuY29kZWQpLg0KDQo8 ZXY+IEV2ZW4gYXMgd2UgbW92ZSBhd2F5IGZyb20gc3RyZWFtcywgSSBzdGlsbCBjYW4gc2VlIHJl YXNvbnMgZm9yIGl0LiAgKEFkZGluZyBCYWxhenMgJiBBbGV4IGFzIHRoZXkgaGF2ZSBiZWVuIHBy b3BvbmVudHMuKSAgVGhlIGJpZ2dlc3QgcmVhc29uIGZvciBzdHJlYW1zIGlzIHRoYXQgYSByb2J1 c3QgY3VzdG9tZXIgZGVzaWduZWQgZmlsdGVycyBhcmUgaGFyZC4gIElmIGEgdmVuZG9yL2N1c3Rv bWVyL2V0Yy4gaXMgYWJsZSB0byBwcmUtZmlsdGVyIG5vdGlmaWNhdGlvbnMgb3IgZGF0YXN0b3Jl IGluIGFuIGludGVyZXN0aW5nIGFuZCB1c2VmdWwgd2F5IG5vdCBzdXBwb3J0YWJsZSBieSBvdXIg ZmlsdGVyaW5nIHNlbWFudGljcywgdGhpcyBpcyBhIGdvb2Qgd2F5IHRvIGFsbG93IHRoZSBwcmUt ZmlsdGVyaW5nLiBTb21lIGV4YW1wbGVzIHdoaWNoIGNvdWxkIGJlIGludGVyZXN0aW5nOg0KDQri gKIgICAgICAgRXZlbnQgbm90aWZpY2F0aW9ucyB3aGVuIG5ldyBkZXZpY2VzIGNvbm5lY3QgdG8g YSBuZXR3b3JrDQoNCuKAoiAgICAgICBBbGFybXMgcG90ZW50aWFsbHkgc2V0IGFjcm9zcyBtdWx0 aXBsZSBZQU5HIG1vZGVscw0KDQpDdXJyZW50bHksIGZpbHRlcnMgYXJlIGRlZmluZWQgYXMgYSBj aG9pY2Utc3RtdC4NClRoaXMgaW1wbGllZCBPUi1leHByIGlzIHRvbyBzaW1wbGlzdGljLiBBbiBl eHBsaWNpdCBjb21iaW5hdGlvbiBvZiBPUiwgQU5ELCBhbmQgTk9UIGlzIHJlcXVpcmVkDQpmb3Ig ZGlmZmVyZW50IHR5cGVzIG9mIGZpbHRlcnMuICAoc2ltaWxhciB0byBZQU5HIDEuMSBpZi1mZWF0 dXJlLXN0bXQgc3ludGF4KS4NCg0KPGV2PiBUb3RhbGx5IGFncmVlIHRoYXQgd2UgbmVlZCByb2J1 c3QgZmlsdGVycy4gIEZpZ3VyaW5nIHRoaXMgcHJvYmxlbSBzcGFjZSBvdXQgaXMgYSBmdWxsIHRp bWUgam9iLiAgRmlndXJpbmcgb3V0IGhvdyB0byBlbmNvZGluZyBmaWx0ZXJpbmcgY2FwYWJpbGl0 aWVzIHN1cHBvcnRlZCBvbiBkaWZmZXJlbnQgdHlwZXMgb2YgY29uc3RyYWluZWQgcGxhdGZvcm1z IGlzIG5vbi10cml2aWFsLiAgSSB3b3VsZCBsb3ZlIHRvIHNlZSBzb21lb25lIHRha2UgdGhpcyBv biBmb3IgdGhlIGluZHVzdHJ5LiAgQW55IHRha2Vycz8NCg0KRXJpYw0KDQpBbmR5DQoNCg0KQXMg bGF5ZXJpbmcgdXBvbiBSRkMtNTI3NyBjYW5ub3QgZ2l2ZSB0aGUgbmV3IGNhcGFiaWxpdGllcyBi ZWluZyByZXF1ZXN0ZWQgb2YgdXMgaW4gcGxhY2VzIGxpa2UgUkZDLTc5MjMgKGUuZy4sIG11bHRp cGxlIHN1YnNjcmlwdGlvbnMvc2Vzc2lvbiksIHdlIGFyZSBtb3Zpbmcgbm93IHRvIHB1dCBhbGwg ZWxlbWVudHMganVzdCBuZWVkZWQgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGluIHRoZSBu ZXRjb25mIHRyYW5zcG9ydCBkcmFmdC4gIFdlIGNvdWxkIGFsc28gc2VwYXJhdGUgYWxsIHRoaXMg b3V0IGludG8gYW5vdGhlciBpbmRlcGVuZGVudCBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBleHRl bnNpb24uICBCdXQgd2UgZmVsdCB3ZSBoYWQgZW5vdWdoIGRyYWZ0cyBpbiBwcm9ncmVzcyB3aGVy ZSB3ZSBkaWRuJ3Qgd2FudC9uZWVkIGEgZmlmdGggb25lLg0KDQo+ID4gW0FHXSBGV0lXLCB0aGUg c2NvcGUgb2YgZWFjaCBkb2MgaXMgc3VtbWFyaXplZCBvbg0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtbmV0Y29uZi01LnBkZg0KPiA+IChz bGlkZQ0KPiA+ICM1KQ0KPiA+IFtBR10gVGhlIGtleSBpcyB0aGF0IHRoZSBzcGVjIGZvciBOQyBj b21lcyBmcm9tIHRoZSB1bmlvbiBvZiA1Mjc3LWJpcw0KPiA+IGFuZCB0aGUgTkMgdHJhbnNwb3J0 IGRvYw0KPiA+IChkcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25z LTAxLnR4dCkgVGhlIE5DDQo+ID4gdHJhbnNwb3J0IGRvYyBpcyBub3QgbWVhbnQgdG8gc3RhbmQg YWxvbmUuDQo+ID4gVGhlIGRvYyBjb250YWlucyBob3cgNTI3Ny1iaXMgY29uY2VwdHMgYXJlIHJl YWxpemVkIHdoZW4gdXNpbmcgTkMgYW5kDQo+ID4gTkMtc3BlY2lmaWMgYXNwZWN0cy4gRS5nLjoN Cj4gPiAtIHRoZSB1c2Ugb2YgTkMgY2FsbC1ob21lIGZvciBjb25maWd1cmVkIHN1YnNjcmlwdGlv bnMNCj4gPiAtIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5DQo+ID4gICAgLSB0aGUgZXhpc3RlbmNl IG9mIGEgTkVUQ09ORiBzdHJlYW0NCj4gPiAgICAtIHN1cHBvcnQgb2YgL25ldGNvbmYvc3RyZWFt cw0KPiA+IDxldj4gWWVzLCBhbnkgNTI3N2JpcyB0b3BpYyBzcGVjaWZpYyB0byBvbmx5IE5FVENP TkYgdHJhbnNwb3J0IHNob3VsZA0KPiA+IGJlIGluIG5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9u cw0KPiA+DQo+ID4gSSBhZ3JlZSB3aXRoIE1hcnRpbiB0aGF0IGR1cGxpY2F0aW5nIG5vcm1hdGl2 ZSB0ZXh0IGlzIGJhZC4NCj4gPiBOb3QgaGF2aW5nIGFueSBub3JtYXRpdmUgdGV4dCBpcyBldmVu IHdvcnNlLg0KPiA+DQo+ID4gPGV2PiArMS4gIFRvIGhlbHAgYWRkcmVzcyB0aGF0LCBJIGp1c3Qg YnVpbHQgYSB3aG9sZSBsaXN0IG9mIHBlbmRpbmcgY2hhbmdlcw0KPiBhY3Jvc3MgdGhlIGZvdXIg ZHJhZnRzLiAgQW5kIGluIHF1aXRlIGEgZmV3IHBsYWNlcyBJIHB1bGxlZCBvdXQgZHVwbGljYXRp dmUgdGV4dC4NCj4gPg0KPiA+IC0gdGhlIGRlZmluaXRpb24gb2YgY3JlYXRlLXN1YnNjcmlwdGlv biBtYXkgYmUgbW92ZWQgdG8gdGhpcyBkb2Mgc28NCj4gPiB0aGF0IG90aGVyIHRyYW5zcG9ydHMg d291bGQgaWdub3JlIGNyZWF0ZS1zdWJzY3JpcHRpb24gYW5kIHVzZSBvbmx5DQo+ID4gZXN0YWJs aXNoLXN1YnNjcmlwdGlvbiwgc2ltcGxpZnlpbmcgdGhlIHNvbHV0aW9uDQo+ID4NCj4gPg0KPiA+ IFRoYXQgc2VlbXMgd3Jvbmcgc2luY2UgNTI3NyBoYWQgY3JlYXRlLXN1YnNjcmlwdGlvbiBzbyBp dCBzaG91bGQgc3RheQ0KPiA+IGluIDUyNzdiaXMNCj4gPg0KPiA+IDxldj4gSXQgaXMgcmVhbGx5 IGEgc3R5bGUgdGhpbmcgc28gaXQgZG9lc27igJl0IG1hdHRlciB0aGF0IG11Y2ggZWl0aGVyIHdh eS4NCj4gQ3VycmVudCB0aGlua2luZyBpcyB0aGF0IGFzIHdlIG5lZWQgYm90aCB0aGUgbmV3IGFu ZCBvbGQgbmFtZXNwYWNlcy4NCj4gVGhlcmVmb3JlIGl0IHNlZW1zIHNpbXBsZXIgdG8gaGF2ZSBh bnl0aGluZyBpbiB0aGUgb2xkIG5hbWVzcGFjZSAo4oCcY3JlYXRlLQ0KPiBzdWJzY3JpcHRpb27i gJ0pIGluIG5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9uIGRyYWZ0Lg0KPg0KPiBJIGFncmVlIHdp dGggQW5keSB0aGF0IGFueXRoaW5nIHRoYXQgY29tZXMgZnJvbSA1Mjc3IHRoYXQgeW91IG5lZWQg dG8ga2VlcA0KPiBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgcmVhc29ucyBzaG91bGQgZ28g aW50byA1Mjc3YmlzLg0KDQpSaWdodCBub3cgaXQgaXMgaW4gNTI3N2Jpcy4gIEJ1dCB3ZSBhbHJl YWR5IGNhbid0IGhhdmUgZXZlcnl0aGluZyBuZWVkZWQgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmls aXR5IHNpbmNlIHRoZSA1Mjc3YmlzIGlzIHRyYW5zcG9ydCAoTkVUQ09ORikgaW5kZXBlbmRlbnQu ICBTbyBpdCBzZWVtZWQgbG9naWNhbCB0byBwdXQgaXQgTkVUQ09ORiB0cmFuc3BvcnQgZHJhZnQu ICAoQWdhaW4gd2Ugd2VyZSB0cnlpbmcgdG8gbGltaXQgdGhlIHByb2xpZmVyYXRpb24gb2YgZHJh ZnRzLikNCg0KSW4gdGhlIGVuZCwgSSBhbSBvayBhcyBsb25nIGFzIGl0IGxhbmRzIHNvbWV3aGVy ZS4gIFNvIGlmIHBlb3BsZSBwcmVmZXIsIHdlIGNvdWxkIGFsc28gaGF2ZSB0aGlzIGFzIGEgY29t cGxldGVseSBzZXBhcmF0ZSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBzZWN0aW9uICsgWUFORyBt b2RlbCBpbiA1Mjc3YmlzLg0KDQo+ID4gLSBob3cgdG8gaXNzdWUgbm90aWZpY2F0aW9ucyBpbiBK U09OIGFyZSBzZW50IHVzaW5nIE5DICh0aGlzIGlzIGFsc28NCj4gPiBpbiA1Mjc3LWJpcykuIEFy Z3VhYmx5LCBpdCBiZWxvbmdzIGluIHRoZSBOQyB0cmFuc3BvcnQgZG9jDQo+ID4NCj4gPg0KPiA+ DQo+ID4gVGhpcyBpcyBwb29ybHkgZGVmaW5lZC4NCj4gPiBORVRDT05GIGRvZXMgbm90IHN1cHBv cnQgSlNPTiBlbmNvZGluZyBhbmQgSU1PIHNob3VsZCBub3QgZGVmaW5lIEpTT04NCj4gPiBlbmNv ZGluZyB1bmxlc3MgdGhlIGVudGlyZSBwcm90b2NvbCBzdXBwb3J0cyBpdCBjbGVhbmx5Lg0KPiA+ IFRoZSBwcm9wb3NhbCBzZWVtcyB0byBiZSB0byB1c2UgWE1MIGZvciA8cnBjPiBhbmQgPHJwYy1y ZXBseT4sIGJ1dA0KPiA+IGFsbG93IHNvbWUgc3BlY2lhbCBtb2RlIHdoZXJlIDxub3RpZmljYXRp b24+IGlzIHNlbnQgaW4gSlNPTi4NCj4gPg0KPiA+ID4NCj4gPiA+byAgU2VjdGlvbiAyLjENCj4g PiA+DQo+ID4gPiAgVGhlIHRleHQgc2F5czoNCj4gPiA+DQo+ID4gPiAgIFRoZSBORVRDT05GIGV2 ZW50IHN0cmVhbSBjb250YWlucyBhbGwNCj4gPiA+ICAgTkVUQ09ORiBYTUwgZXZlbnQgbm90aWZp Y2F0aW9ucyBzdXBwb3J0ZWQgYnkgdGhlIHB1Ymxpc2hlciwNCj4gPiA+DQo+ID4gPiAgRmlyc3Qg b2YgYWxsLCBzaW5jZSB0aGlzIGRvY3VtZW50IGlzIHByb3RvY29sLWFnbm9zdGljLCBzaG91bGQg aXQNCj4gPiA+IHJlYWxseSBkZWZpbmUgdGhlIHN0cmVhbSAiTkVUQ09ORiI/DQo+ID4NCj4gPiA8 ZXY+IEFncmVlLCB3aGljaCBpcyB3aHkgdGhpcyBpcyBnb2luZyB0byBuZXRjb25mLWV2ZW50LW5v dGlmaWNhdGlvbi4NCj4gPg0KPiA+ID4gIFNlY29uZGx5LCB0aGlzIHdvdWxkIGJlIGEgbmV3IHJl cXVpcmVtZW50LiAgVGhlcmUgaXMgbm90aGluZyBpbiBSRkMNCj4gPiA+ICA1Mjc3IHRoYXQgc2F5 cyB0aGF0IGEgbm90aWZpY2F0aW9uIGlzIHNlbnQgb24gIk5FVENPTkYiIGJlIGRlZmF1bHQuDQo+ ID4NCj4gPiA8ZXY+IDUyNzcgc2VjdGlvbiAzLjIuMyB0YWxrcyBhYm91dCB0aGUgZGVmYXVsdCBl dmVudCBzdHJlYW0gd2hpY2ggaGFzDQo+ID4gYWxsIE5FVENPTkYgZXZlbnQgbm90aWZpY2F0aW9u cw0KPg0KPiBZb3UncmUgcmlnaHQuICBUaGUgcXVlc3Rpb24gaXMgdGhlbiB3aGF0IGlzIGFuICJO RVRDT05GIFhNTCBldmVudA0KPiBub3RpZmljYXRpb24iPyAgSSB0aGluayB0aGUgaW50ZW50aW9u IHdhcyB0aGF0IHRoZXNlIHdvdWxkIGJlICJub3RpZmljYXRpb25zDQo+IHJlbGF0ZWQgdG8gTkVU Q09ORiIsIHJhdGhlciB0aGFuICJhbGwgWUFORy1kZWZpbmVkIG5vdGlmaWNhdGlvbnMiLiAgVGhp cyBuZWVkcw0KPiBzb21lIGRpc3Vjc3Npb24uDQoNCkFncmVlDQoNCj4gPiA+ICBJIHRoaW5rIHRo aXMgdGV4dCBzaG91bGQgYmUgcmVtb3ZlZC4gIEhvdyBub3RpZmljYXRpb25zIGFyZSBtYXBwZWQN Cj4gPiA+IHRvIHN0cmVhbXMgaXMgc2hvdWxkIGJlIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1 bWVudC4NCj4gPg0KPiA+IDxldj4gWWVzLCBzdHJlYW1zIGFzIGEgd2hvbGUgd2VyZSBzb21ldGhp bmcgd2UgZGVmZXJyZWQgZm9yIGEgd2hpbGUuICBMYXRlc3QNCj4gdGhpbmtpbmcgaXMgd2UgbWlu aW1pemUgc3RyZWFtcyB0byB0aGUgZGVncmVlIHBvc3NpYmxlLiAgTG9vayBmb3IgbGVnYWN5IHN0 dWZmIHRvDQo+IGJlIGluIG5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9uLg0KPg0KPiBEbyB5b3Ug bWVhbiB0aGF0IHlvdSBwbGFuIHRvIHVwZGF0ZSB0aGUgdGV4dCBhcm91bmQgc3RyZWFtcz8gIElm IHNvLCB0aGF0J3MNCj4gZmluZS4NCg0KWWVzDQoNCj4gPiA+ICBJbiBsaXN0ICJmaWx0ZXIiLCBj aGFuZ2UgImZpbHRlci1pZCIgdG8gImlkIi4NCj4gPiA+DQo+ID4gPiAgSW4gbGlzdCAic3Vic2Ny aXB0aW9uIiwgY2hhbmdlICJzdWJzY3JpcHRpb24taWQiIHRvICJpZCIuDQo+ID4NCj4gPiA8ZXY+ IE1vZGVsIHB1cml0eS13aXNlIHlvdSBhcmUgY29ycmVjdC4gIFdpdGggYm90aCBzdWJzY3JpcHRp b24gaWQgYW5kIGZpbHRlcg0KPiBpZCwgc2V2ZXJhbCBwZW9wbGUgZXhwcmVzc2VkIHRoZXkgd2Fu dGVkIHRoZSBvYmplY3RzIHRvIGJlIGltbWVkaWF0ZWx5IGFuZA0KPiBvYnZpb3VzbHkgZGlmZmVy ZW50aWFibGUuICAgSG9wZWZ1bGx5IG90aGVycyB3aWxsIGNoaW1lIGluIGhlcmUuDQo+DQo+IEkg dGhpbmsgd2Ugc2hvdWxkIHRyeSB0byBrZWVwIHRoZSBzYW1lIHN0eWxlIGFjcm9zcyBJRVRGIGRv Y3VtZW50cy4NCj4gTW9zdCBtb2RlbHMgZG8gbm90IHVzZSByZWR1bmRhbnQgcXVhbGlmaWVycywg ZXNwZWNpYWxseSBub3QgZm9yIGdlbmVyaWMgbmFtZXMNCj4gbGlrZSAnaWQnIG9yICduYW1lJyB3 aGVuIHVzZWQgYXMgYSBrZXkuDQoNCkkgYW0gaGFwcHkgd2l0aCB3aGF0ZXZlciBjb252ZW50aW9u IHRoZSBXRyBjaG9vc2VzLg0KDQo+ID4gPiAgSW4gbGlzdCAic3Vic2NyaXB0aW9uIiwgY2hhbmdl ICJzdGFydFRpbWUiIHRvICJzdGFydC10aW1lIiBhbmQNCj4gPiA+ICJzdG9wVGltZSIgdG8gInN0 b3AtdGltZSIsIGZvciBjb25zaXN0ZW5jeS4NCj4gPg0KPiA+IDxldj4gd2Uga2VwdCB0aGUgb2xk IG5hbWVzIGZvciBiYWNrd2FyZHMgZXF1aXZhbGVuY3kgdG8gNTI3Ny4NCj4NCj4gQnV0IHRoZXJl IGlzIG5vdGhpbmcgdG8gYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBpbiB0aGlzIGNhc2Uu DQo+IFRoZSBpbnB1dCBwYXJhbXRlcnMgdG8gdGhlIGV4aXN0aW5nIDxjcmVhdGUtc3Vic2NyaXB0 aW9uPiBjYW5ub3QgYmUgY2hhbmdlZCwNCj4gYnV0IG5ldyBub2RlcyBzaG91bGQgYmUga2VwdCBj b25zaXN0ZW50Lg0KDQpPay4gIFNvIHlvdSB3YW50IHN0YXJ0LXRpbWUgaW4gdGhlIFlBTkcgbW9k ZWwsIGFuZCBzdGFydFRpbWUgaW4gdGhlIFJQQy4gIFRoYXQgY2FuIGJlIGRvbmUuDQoNCj4gPiA+ ICBJbiBsaXN0ICJzdWJzY3JpcHRpb24iLCBjaGFuZ2UgY2hvaWNlICJwdXNoLXNvdXJjZSIgdG8g YSBiZXR0ZXINCj4gPiA+IG5hbWUsIG1heWJlICJlZ3Jlc3MtaW50ZXJmYWNlIiAodGhpcyBpcyBo b3cgaXQgaXMgZGVzY3JpYmVkKS4NCj4gPg0KPiA+IDxldj4gcHVzaC1zb3VyY2UgY2FuIGFsc28g YmUgYW4gSVAgQWRkcmVzcy4gIEFub3RoZXIgbmFtZSBwb3NzaWJpbGl0eSBmb3IgdGhpcw0KPiBt aWdodCBiZSDigJxPcmlnaW5hdGVzLWZyb23igJ0sIHRoYXQgaXMgdGhlIGJhc2ljIGlkZWEuDQo+ DQo+IFRoZSBjdXJyZW50IGRyYWZ0IGhhczoNCj4NCj4gICAgICAgIGNob2ljZSBwdXNoLXNvdXJj ZSB7DQo+ICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAgIklkZW50aWZpZXMgdGhl IGVncmVzcyBpbnRlcmZhY2Ugb24gdGhlIFB1Ymxpc2hlciBmcm9tDQo+ICAgICAgICAgICAgIHdo aWNoIG5vdGlmaWNhdGlvbnMgd2lsbCBvciBhcmUgYmVpbmcgc2VudC4iOw0KPg0KPiBZb3UgcHJv YmFibHkgbmVlZCB0byBhZGp1c3QgdGhpcywgYW5kIG1ha2UgaXQgY2xlYXIgd2hhdCB0aGUgaXAt YWRkcmVzcyBjYXNlDQo+IHJlYWxseSBtZWFucy4NCg0KYWdyZWUNCg0KPiA+ID4gIEluIGxpc3Qg InJlY2VpdmVyIiwgd2hhdCBpcyBhICJtdWx0aXBvaW50IGFkZHJlc3MiPw0KPiA+DQo+ID4gPGV2 PiB3ZSBhcmUgdHJ5aW5nIG5vdCB0byBsaW1pdCByZWNlaXZlcnMgdG8gaG9zdHMuIFBlcmhhcHMg bXVsdGljYXN0IGFkZHJlc3MgaXMNCj4gb2suICBSZWFsbHkgd2Ugd291bGQgYmUgZ29vZCB3aXRo IHR5cGU6IGluZXQ6aG9zdC4NCj4NCj4gVGhlIHR5cGUgaXMgaW5ldDpob3N0IGFscmVhZHkuDQo+ DQo+IFlvdSBzaG91bGQgcHJvYmFibHkgY2xhcmlmeSB0aGUgZGVzY3JpcHRpb25zLg0KDQphZ3Jl ZQ0KDQo+ID4gPiAgUmVtb3ZlIHRoZSBsZWFmICJzb3VyY2UtdnJmIjsgdGhpcyBzaG91bGQgZXZl bnR1YWxseSBiZSBhbGlnbmVkDQo+ID4gPiB3aXRoICBkcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVs Lg0KPiA+DQo+ID4gUGVyaGFwcyBhIHBsYWNlIGZvciBzY2hlbWEtbW91bnQ/DQo+DQo+IE5vdCBy ZWFsbHksIHJhdGhlciBhbiBhdWdtZW50Lg0KDQpIYXBweSB0byBnbyB3aXRoIHdoYXRldmVyIGNv bnZlbnRpb24gcGVvcGxlIHdhbnQgdG8gdXNlLg0KDQo+ID4gV2Ugc2hvdWxkIGxlYXZlIHNvdXJj ZS12cmYgaW4NCj4gPiBwbGFjZSB1bnRpbCB3ZSBoYXZlIHRoZSBwcm9wZXIgZGVmaW5pdGlvbi4N Cj4NCj4gTm8gSSBzYXkgcmVtb3ZlIGl0IHVudGlsIHlvdSBoYXZlIGEgcHJvcGVyIGRlZmluaXRp b24uICBJZiB5b3Uga2VlcCBpdCB5b3UgbmVlZCB0bw0KPiBoYXZlIGEgcHJvcGVyIGRlZmluaXRp b24gb2Ygd2hhdCBpdCBpcywgYW5kIGl0IG5lZWRzIHRvIGJlIGludGVyb3BlcmFibGUgYWNyb3Nz DQo+IGltcGxlbWVudGF0aW9ucy4NCg0KV2Ugd2lsbCBhZGRyZXNzIHdpdGggdGhlIHByb3BlciBj b252ZW50aW9uIGluIHRoZSBuZXh0IGRyYWZ0DQoNCj4gPiBCdXQgd2UgY291bGQgdXBkYXRlIHRo ZSB0ZXh0IHNob3dpbmcgdGhlcmUgaXMgYSBwZW5kaW5nIGRlY2lzaW9uLg0KPiA+DQo+ID4gPiAg WW91IGhhdmUgbWFkZSB0aGUgc3RyZWFtIG5hbWUgYW4gaWRlbnRpdHkuICBJbiBSRkMgNTI3NyBp dCB3YXMgYQ0KPiA+ID4gc3RyaW5nLiAgQnkgdXNpbmcgYW4gaWRlbnRpdHksIHlvdSBzZXZlcmx5 IGxpbWl0IGhvdyBpdCBjYW4gYmUgdXNlZDsNCj4gPiA+IHdpdGggYSBzdHJpbmcgbmV3IHN0cmVh bXMgY2FuIGJlIGR5bmFtaWNhbGx5IGNyZWF0ZWQgYXQgcnVuLXRpbWUsDQo+ID4gPiBidXQgd2l0 aCBhbiBpZGVudGl0eSBzdHJlYW0gbmFtZXMgbXVzdCBiZSBrbm93biBhdCBkZXNpZ24tdGltZS4N Cj4gPiA+ICBJIHRoaW5rIHRoZSBzdHJlYW0gbmFtZSBzaG91bGQgYmUgY2hhbmdlZCBiYWNrIHRv IGEgc3RyaW5nLg0KPiA+DQo+ID4gPGV2PiBhcyB0aGUgbWFqb3JpdHkgb2YgdGhlIHBlb3BsZSBp biB0aGUgaW5mb3JtYWwgZGVzaWduIHRlYW0gd2VyZSBhZ2FpbnN0DQo+IHRoZSBleHBhbnNpb24g b2Ygc3RyZWFtcywgdGhpcyBpcyBsaWtlbHkgYSBtb290IHBvaW50Lg0KPg0KPiBJIGRvbid0IGtu b3cgd2hhdCAiZXhwYW5zaW9uIG9mIHN0cmVhbXMiIG1lYW5zLCBhbmQgSSBkb24ndCB1bmRlcnN0 YW5kIHdoYXQNCj4gInRoaXMiIHJlZmVycyB0byBpbiAidGhpcyBpcyBsaWtlbHkgYSBtb290IHBv aW50Ii4NCj4NCj4gQnV0IGlmIHdlIGtlZXAgdGhlIHN0cmVhbSBuYW1lIGFzIGFuIGlkZW50aXR5 IHdlJ3JlIG5vIGxvbmdlciBiYWNrd2FyZHMNCj4gY29tcGF0aWJsZSB3aXRoIFJGQyA1Mjc3LCBh bmQgd2Ugc2V2ZXJseSBsaW1pdCB0aGUgZnVuY3Rpb25hbGl0eS4gIEkgc3Ryb25nbHkNCj4gb2Jq ZWN0IHRvIHN1Y2ggYSBjaGFuZ2UuDQoNCkkgYW0gZmluZSB3aXRoIHN0cmluZywgZXNwZWNpYWxs eSBhczoNCihhKSB3ZSBhcmUgbW92aW5nIGF3YXkgZnJvbSBzdHJpbmdzIGluIGZhdm9yIG9mIGZp bHRlcnMNCihiKSBjdXN0b20gc3RyZWFtcyBhcmUgbGlrZWx5IHRvIGJlIHRoZSBkb21pbmFudCB1 c2UuDQpBbnlvbmUgaGF2ZSBhbiBvYmplY3Rpb24gIHRvIHRoaXMgY2hhbmdlPw0KDQo+ID4gPm8g IFNlY3Rpb24gNC4xDQo+ID4gPg0KPiA+ID4gIFRoZSB0ZXh0IHNheXM6DQo+ID4gPg0KPiA+ID4g ICBJZiB0aGUNCj4gPiA+ICAgcmVxdWVzdCBpcyByZWplY3RlZCBiZWNhdXNlIHRoZSBwdWJsaXNo ZXIgaXMgbm90IGFibGUgdG8gc2VydmUgaXQsDQo+ID4gPiAgIHRoZSBwdWJsaXNoZXIgU0hPVUxE IGluY2x1ZGUgaW4gdGhlIHJldHVybmVkIGVycm9yIHdoYXQgc3Vic2NyaXB0aW9uDQo+ID4gPiAg IHBhcmFtZXRlcnMgd291bGQgaGF2ZSBiZWVuIGFjY2VwdGVkIGZvciB0aGUgcmVxdWVzdCB3aGVu IGl0IHdhcw0KPiA+ID4gICBwcm9jZXNzZWQuDQo+ID4gPg0KPiA+ID4gIEkgdGhpbmsgdGhpcyBp cyBhIHByZXR0eSB3ZWlyZCBpZGVhLiAgSXQgc2VlbXMgZXh0cmVtZWx5IGRpZmZpY3VsdA0KPiA+ ID4gdG8gaW1wbGVtZW50LCBhbmQgdGhlIHVzZSBjYXNlIGlzIG5vdCBjbGVhciBhdCBhbGwuICBJ biBhbg0KPiA+ID4gYXV0b21hdGlvbiBkZXBsb3ltZW50LCBkbyB3ZSBleHBlY3QgdGhhdCB0aGUg Y2xpZW50IGFwcGxpY2F0aW9uIGNvZGUNCj4gPiA+IGNvbnRhaW5zIGxvZ2ljIHRvIHJld3JpdGUg aXRzZWxmIHRvIHNlbmQgcHJvcGVyIHJlcXVlc3RzIHRoZSBuZXh0DQo+ID4gPiAgdGltZT8gICBJ ZiBpdCBpcyBmb3IgZGVidWdnaW5nIHB1cnBvc2VzIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgdXAg dG8NCj4gPiA+ICBpbXBsZW1lbnRhdGlvbnMgdG8gZmlndXJlIG91dC4gIFdlIHNob3VsZG4ndCBh ZGQgc3VjaCB0aGluZ3MgdG8NCj4gPiA+IHN0YW5kYXJkIFJQQ3MuDQo+ID4NCj4gPiA8ZXY+IHRo ZXJlIGhhcyBiZWVuIGxvdHMgb2YgZGlzY3Vzc2lvbiBvbiB0aGlzIG9uZS4gIFRoZSBiaWdnZXN0 IGlzc3VlIGhhcyBiZWVuDQo+IHRoYXQgdGhlcmUgYXJlIGVub3VnaCB2YXJpYXRpb25zIG9mIHBh cmFtZXRlcnMgd2hlcmUgdGhlIGd1aWRhbmNlIG9uIHdoYXQNCj4gbWlnaHQgYmUgYWNjZXB0YWJs ZSBpcyB0aGUgb25seSB3YXkgdG8gbWFrZSBzb21lIHNjZW5hcmlvcyB3b3JrLiAgKFdhcyBpdCB0 aGUNCj4gcGVyaW9kIHdoaWNoIHdhcyBhIHByb2JsZW0/ICBXYXMgaXQgdGhlIGNvbXBsZXhpdHkg b2YgdGhlIGZpbHRlcj8pICBPYnZpb3VzbHkNCj4gd2UgZG8gbmVlZCB0byBib3VuZCB3aGF0IGNv dWxkIGJlIHByb3ZpZGVkIGJhY2sgdG8gdGhlIHN1YnNjcmliZXIuDQo+DQo+IFNvIHRoZW4gdGhl IHRleHQgc2hvdWxkIGVuY291cmFnZSBpbXBsZW1lbnRhdGlvbnMgdG8gcHJvdmlkZSBnb29kIGVy cm9yDQo+IG1lc3NhZ2VzLg0KDQp5ZXMNCg0KPiA+IFRoZSBnb29kIG5ld3MgaXMgdGhhdCBpZiBh IHB1Ymxpc2hlciBjYW5ub3Qgc3VwcG9ydCBuZWdvdGlhdGlvbiwgaXQgY2FuIGp1c3QNCj4gc2Vu ZCBiYWNrIGEgZmFpbHVyZS4gIFdoaWNoIGlzIHdoeSB0aGUgcmVxdWlyZW1lbnQgaXMgb25seSBh IFNIT1VMRC4NCj4NCj4gU0hPVUxEIGlzIHRvbyBzdHJvbmcuICBBbmQgZXZlbiBzbywgdGhpcyBq dXN0IGFkZHMgY29tcGxleGl0eSB0byB0aGUNCj4gc3BlY2lmaWNhdGlvbi4gIEkgdGhpbmsgdGhp cyBzaG91bGQgYmUgcmVtb3ZlZC4NCg0KUkZDNzkyMyBoYXMgaXQgYXMgYSBNVVNUIChzZWUgc2Vj dGlvbiA0LjIuMi4pICBHb2luZyB0byBTSE9VTEQgaXMgYWxyZWFkeSBlYXNpbmcgb2ZmIHRoZSBy ZXF1aXJlbWVudC4NCg0KPiA+IEEgd29yc2Ugb3V0Y29tZSB3b3VsZCBiZSBpZiBhIFN1YnNjcmli ZXIga2VwdCBndWVzc2luZyBhdCBhY2NlcHRhYmxlDQo+IHBhcmFtZXRlcnMgYW5kIHBvdW5kaW5n IHRoZSBQdWJsaXNoZXIgd2l0aCBsb2FkIG9uIHRoaXMuICBUaGlzIHdvdWxkIHRha2UNCj4gbW9y ZSByZXNvdXJjZXMgdGhhbiBwcm92aWRpbmcgaGludHMuDQo+DQo+IFRoYXQgd291bGQgYWxzbyBi ZSBxdWl0ZSB3ZWlyZC4gIEJ1dCBJIGNhbid0IGltYWdpbmUgYSB1c2UgY2FzZSB3aGVyZSBhIGNs aWVudA0KPiBuZWVkcyBhIGNlcnRhaW4gY29tYmluYXRpb24gb2YgcGFyYW1ldGVycywgdGhlIHNl cnZlciByZWpjZXRzIHRoZW0gYnV0IHN1Z2dlc3QNCj4gc29tZSBvdGhlciBwYXJhbWV0ZXJzIHRo YXQgd2lsbCBnaXZlIHRoZSBzYW1lIHJlc3VsdCwgYW5kIHRoZW4gdGhlIGNsaWVudA0KPiB3b3Vs ZCB1c2UgdGhlbT8gIE9yIHdvcnNlLCB0aGUgc2VydmVyIHN1Z2dlc3Qgc29tZXRoaW5nIHRoYXQg Z2l2ZXMgYW5vdGhlcg0KPiByZXN1bHQgYW5kIHRoZSBjbGllbnQgc29tZWhvdyBhZGp1c3QgdG8g dGhlbT8NCg0KV2hlbiBhIHN1YnNjcmlwdGlvbiBpcyByZWplY3RlZCwgd2UgY2FuIHByb3ZpZGUg YSBoaW50IGF0IHdoeS4gIFRoaXMgaXMgYSBuZXcgZGFtcGVuaW5nIHBlcmlvZCwgYSBzdWdnZXN0 aW9uIHRvIHVzZSBvbi1jaGFuZ2UsIGV0Yy4gIFdpdGhvdXQgdGhpcyBoaW50LCBhIHN1YnNjcmli ZXIgY291bGQganVzdCBrZWVwIGd1ZXNzaW5nIGF0IHBhcmFtZXRlcnMgd2l0aG91dCBndWlkYW5j ZS4gIFRoYXQgaXMgYWxsIG5lZ290aWF0aW9uIGlzLg0KDQo+ID4gPm8gIFNlY3Rpb24gNg0KPiA+ ID4NCj4gPiA+ICBUaGUgdGV4dCBzYXlzOg0KPiA+ID4NCj4gPiA+ICAgVGhlIGV2ZW50IG5vdGlm aWNhdGlvbnMgbXVzdCBhbHNvIGluY2x1ZGUgdGhlIHN1YnNjcmlwdGlvbi1pZCBpZiB0aGUNCj4g PiA+ICAgZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiB3YXMgdXNlZCBpbiBpdHMgZXN0YWJsaXNobWVu dCwgb3IgaWYgaXQgd2FzDQo+ID4gPiAgIGNvbmZpZ3VyZWQgdmlhIGFuIG9wZXJhdGlvbmFsIGlu dGVyZmFjZS4NCj4gPiA+DQo+ID4gPiAgSG93IGlzIHRoaXMgInN1Y2JzY3JpcHRpb24taWQiIHN1 cHBvc2VkIHRvIGJlIGluY2x1ZGVkPyAgV2hlcmU/DQo+ID4gPiAgVGhlcmUgaXMgbm8gc3VjaCBm aWVsZCBkZWZpbmVkIGluIGEgPG5vdGlmaWNhdGlvbj4uDQo+ID4NCj4gPiA8ZXY+IFVubGlrZSB5 YW5nLXB1c2gsIHRoZSBOb3RpZmljYXRpb24gZXZlbnRzIGFyZSBub3Qgc3BlY2lmaWVkIHZpYSB0 aGUNCj4gZG9jdW1lbnQuICAgVGhlIGV4YW1wbGVzIGZvbGxvd2luZyB0aGUgcmVxdWlyZW1lbnQg ZG8gbm90IGluY2x1ZGUgYQ0KPiBzdWJzY3JpcHRpb24taWQgd2hlbiB0aGV5IGFic29sdXRlbHkg c2hvdWxkLiAgKEFuZCB0aGlzIHByb3ZlcyB0aGUgcG9pbnQgdGhhdA0KPiB0aGVzZSBhcmUgbmVl ZGVkIDotKS4gICBXZSB3aWxsIHVwZGF0ZSB0aGUgZXhhbXBsZXMuDQo+DQo+IFdlbGwsIGV4YW1w bGVzIGFyZSBnb29kLCBidXQgeW91IGFsc28gbmVlZCBhIG5vcm1hdGl2ZSBkZWZpbml0aW9uLg0K DQpXaWxsIGRvLg0KDQpFcmljDQoNCj4gL21hcnRpbg0KPg0KPg0KPiA+DQo+ID4gVGhhbmtzIGFn YWluLA0KPiA+IEVyaWMNCg0KDQo= --_000_4fab79c122c24e0ab2300d47d7f72b3eXCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubS01MzUxNDI2MzQ2OTAxOTYzOTc0bXNvbGlzdHBhcmFn cmFwaCwgbGkubS01MzUxNDI2MzQ2OTAxOTYzOTc0bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm0tNTM1 MTQyNjM0NjkwMTk2Mzk3NG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8tNTM1 MTQyNjM0NjkwMTk2Mzk3NG1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjUyMjcyOTkyOw0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDQ2ODEzMzcwIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE4MDIxODU1MzE7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTkxNDUzODA0IDU0ODQyMzYy NiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6Ilwo JTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFuZHksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgaXMgYSBsb3QgaW50ZXJlc3RpbmcgaW4geW91ciBm aWx0ZXIueWFuZyBmaWxlLiZuYnNwOyBJZiB0aGUgV0cgZGVzaXJlcyB0byBnbyBiZXlvbmQgdGhl IGV4aXN0aW5nIHN1YnRyZWUgZmlsdGVyaW5nICZhbXA7IHhwYXRoIG1lY2hhbmlzbXMsIHdlIHNo b3VsZCBkZXRlcm1pbmUgaWYgd2UNCiBjYW4gdXNlIHRoaXMgYXMgYSBiYXNlLiZuYnNwOyBCdXQg aWYgd2UgZ28gZG93biB0aGlzIHBhdGggaXQgd2lsbCB0YWtlIHNvbWUgdGltZSB0byBnZXQgdGhp cyByaWdodC4mbmJzcDsgQW5kIGlmIHdlIGRvIHRoaXMsIHdlIHNob3VsZCBzdHJ1Y3R1cmUgYWxs IGRyYWZ0cyBzbyB0aGF0IGZpbHRlcnMgY2FuIGJlIGV4dGVuZGVkIG92ZXIgdGltZSB3aXRob3V0 IG5lZWRpbmcgdG8gbW9ycGggdGhlIHN1YnNjcmlwdGlvbnMgZHJhZnRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TXkgaW5pdGlhbCB0YWtlIG9uIHRoaXMgaXMg dGhhdCBpZiB3ZSBjaG9vc2UgdG8gcHVyc3VlIGZpbHRlci55YW5nLCBsYW5kaW5nIGZpbHRlcnMu eWFuZyBhcyBhIHNlcGFyYXRlIG1vZGVsL2RyYWZ0IG1ha2VzIHNlbnNlLiAmbmJzcDtQdXQgc2lt cGx5LCBmaWx0ZXJzIG5lZWQgbm90DQogYmUgc3Vic2NyaXB0aW9uIHNwZWNpZmljLiZuYnNwOyAm bmJzcDtJbiBmYWN0LCBoYXZpbmcgcHJlZGVmaW5lZCwgZGVjb3VwbGVkIGZpbHRlcnMgb24gZGV2 aWNlIGV2ZW4gZm9yIGEgbm9ybWFsIEdFVCBjYW4gZ28gYSBsb25nIHdheSB0byBlbnN1cmluZyB0 aGF0IGFueSBzcGVjaWZpYyBmaWx0ZXIgaGFzIGJlZW4gcHJlcXVhbGlmaWVkIGFzIG5vdCBiZWlu ZyByZXNvdXJjZS1wcm9oaWJpdGl2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlNvIGhvdyBtaWdodCB3ZSBpbnRlZ3JhdGUgc3Vic2NyaXB0aW9ucyBhbmQgZmls dGVycy55YW5nPzoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tIGZvciBwZXJzaXN0ZW50IGZpbHRlcnMg dGhhdCBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlIHN1YnNjcmlwdGlvbiBsaWZlY3ljbGU6IHRoZSBz dWJzY3JpcHRpb27igJlzIGZpbHRlci1yZWYgY2FuIHBvaW50IHRvIGEgc3RhbmQtYWxvbmUgeWFu ZyBmaWx0ZXIgbW9kZWwgaW4gYW4NCiBpbXBvcnRlZCBmaWx0ZXIueWFuZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4tIGZvciBmaWx0ZXJzIHdoaWNoIHNob3VsZCBvbmx5IGV4aXN0IGFzIHBhcnQgb2YgdGhl IGxpZmVjeWNsZSBvZiBhIHN1YnNjcmlwdGlvbjogcGVyaGFwcyBkbyBhIHNjaGVtYSBtb3VudCBv ZiBmaWx0ZXIueWFuZz8gVGhlIG1vdW50ZWQgc2NoZW1hIGNhbiBiZSB1c2VkIHRvDQogYWNjZXB0 IGlucHV0IGZyb20gYW4gUlBDIGFuZCBzdG9yZSBpdCBhcyBhIHRyYW5zaWVudCBpbi1saW5lIGZp bHRlci4mbmJzcDsgSS5lLiwgdGhpcyB3YXkgdGhlIGNvbnRlbnRzIG9mIHRoZSBpbmxpbmUgZmls dGVycyB3aWxsIG5vdCBwZXJzaXN0IGxvbmdlciB0aGFuIHRoZSBzdWJzY3JpcHRpb24uJm5ic3A7 IChJcyB0aGVyZSBhIHdheSB0byBkbyB0aGlzIHdpdGggZ3JvdXBpbmdzL2F1Z21lbnRhdGlvbnMg c28gdGhhdCBzY2hlbWEgbW91bnQgaXNu4oCZdCBuZWVkZWQ/KTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBzdXNwZWN0IGJ5IGFwcHJvYWNoaW5nIHRoZSBpbnRl Z3JhdGlvbiBpbiB0aGlzIHdheSwgaXQgaXMgcG9zc2libGUgdG8gZXZvbHZlIGZpbHRlci55YW5n IHdpdGhvdXQgZGlyZWN0bHkgY2hhbmdpbmcgdGhlIHN1YnNjcmlwdGlvbiBtb2RlbC4mbmJzcDsg KFRoZSBvbmx5IHRoaW5nDQogd291bGQgYmUgdGhhdCB5b3UgaGF2ZSB0byByZXYgaXMgdG8gYSBu ZXcgbW9kZWwgdmVyc2lvbi4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5CZXlvbmQgdGhpcyBpbnRlZ3JhdGlvbiBzcGVjdWxhdGlvbiwgYmVsb3cgYXJlIHNvbWUg dGhvdWdodHMgb24gc3BlY2lmaWMgZWxlbWVudHMgb2YgeW91ciDigJxmaWx0ZXJzLnlhbmfigJkg YXR0YWNobWVudDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TGluZSAyOTogaWYtZmVh dHVyZS1zdG10LXN0ciBzaG91bGQgYmUgaWYtZmVhdHVyZS1zdG10LCBjb3JyZWN0PzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6 IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5MaW5lIDQxOiBpZi1maWx0ZXItZmFjdG9yIHNob3VsZCBi ZSBmaWx0ZXItZmFjdG9yLCBjb3JyZWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5M aW5lIDU2OiBtaXhlZCBtZXRhcGhvciBvZiBhL2IvYyBhbmQgMS8yLzMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdE Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkxpbmUgMjA6IHdlIGxpa2VseSBuZWVkIGFuIGlkZW50aXR5IGZvciBh IHN0cmVhbSBzbyB0aGF0IGl0IGNhbiBiZSB1c2VkIGFzIGEgZmlsdGVyLXRlcm08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIHNldCBvZiBvcGVyYXRvcnMgaXMg4oCYYW5k4oCZLCDi gJhvcuKAmS4mbmJzcDsgVGhlcmUgaXMgYWxzbyBmYWN0b3Jpbmcgd2l0aCDigJgo4oCYIGFuZCDi gJgp4oCZLiZuYnNwOyBCdXQgdGhlIG1ham9yaXR5IG9mIHhwYXRoIG9wZXJhdG9ycyBhbmQgc3lu dGF4IGlzIG5vdCBpbmNsdWRlZC4mbmJzcDsgV2hpY2gNCiBpcyBhIGdvb2QgdGhpbmcuJm5ic3A7 IEFzIGZpbHRlcnMgYXJlIG5vdCBuZWNlc3NhcmlseSBib29sZWFuIGl0IG1pZ2h0IGJlIGludGVy ZXN0aW5nIHRvIGZpZ3VyZSBvdXQgd2hhdCBvdGhlciBlbGVtZW50cyBtaWdodCBiZSBuZWVkZWQu Jm5ic3A7IFRoaXMgd2lsbCB0YWtlIHNvbWUgdGltZSB0byBkbyByaWdodC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5 N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SSBhbSBub3QgY2F0Y2hpbmcgYWxsIHRoZSBzdWJ0bHRpZXMgaGVy ZS4mbmJzcDsgQ291bGQgeW91IHJldmlldyB0aGlzIG9uIHRoZSBuZXh0IERlemlnbiB0ZWFtIGNh bGw/Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgcHJvYmFi bHkgZGlzY3VzcyB3aGV0aGVyIHdlIHdhbnQgdG8gbGltaXQgdGhlIGFsbG93YWJsZSBhbW91bnQg b2YgbmVzdGluZyB3aXRoaW4gdGhlIGZpbHRlcmluZyBzeW50YXguJm5ic3A7IFJGQyA1Mjc3IGRp ZG7igJl0IGRvIHN1Y2ggbGltaXRpbmcuJm5ic3A7IEFuZCB3aXRob3V0DQoga25vd2luZyB0aGUg YSBkZXNpcmVkIGZpbHRlciBjcml0ZXJpYSB3aGljaCBjYW4gYmUgYXBwbGllZCBhZ2FpbnN0IHJh bmRvbSBjb2xsZWN0aW9ucyBvZiBvYmplY3RzLCBJIHN1Z2dlc3Qgd2UgZG9u4oCZdCBhdHRlbXB0 IHRoaXMgZWl0aGVyLiZuYnNwOyBQZXJoYXBzIHNvbWVvbmUgaW4gdGhlIGZ1dHVyZSBjYW4gZGVm aW5lIGEgbWluaW1hbCBzZXQgb2YgbmVzdGluZyB3aGljaCBtdXN0IGJlIHN1cHBvcnRlZCBpZiBz b21lb25lIGRlc2lyZXMgZm9yIHRoZQ0KIGZpbHRlcnMgdGhlbXNlbHZlcyB0byBiZSBwb3J0YWJs ZSBhY3Jvc3MgaW1wbGVtZW50YXRpb25zLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Rm9yIHRoZSBpZGVudGl0eSBuZXRjb25mLXN0cmVhbSwgeW91IHJlZmVyIHRvIFJGQzUyNzcgc2Vj IDMuMi4mbmJzcDsgSWYgdGhpcyBpcyBiZWluZyBvYnNvbGV0ZWQsIGRvIHdlIG5lZWQgYW5vdGhl ciBkZWZpbml0aW9uIHNvdXJjZT8gKEFzIHRoZSDigJhvYnNvbGV0ZeKAmQ0KIGRpc2N1c3Npb24g aGFwcGVuZWQgYWZ0ZXIgeW91IHdyb3RlIHRoZSBmaWx0ZXIueWFuZywgcGVyaGFwcyB0aGlzIGNh biBqdXN0IGJlIHJlbW92ZWQgaWYgd2UgZ28gdG8g4oCYb2Jzb2xldGXigJk/KTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW55d2F5IHRoZXJlIGlzIHRoZSBzdGFy dGVyIHRoaW5raW5nIEkgcHJvbWlzZWQuJm5ic3A7IExldOKAmXMgY2hhdCBtb3JlIGlmIHlvdSBh cmUgd2lsbGluZyB0byByZXZpZXcgdGhpcyBvbiB0aGUgV2VkIGNhbGwuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FcmljPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5keSBCaWVybWFu IFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBEZWNlbWJlciAxLCAyMDE2IDE6NDEgUE08YnI+DQo8Yj5Ubzo8L2I+IEVyaWMgVm9pdCAoZXZv aXQpICZsdDtldm9pdEBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBCYWxhenMgTGVuZ3ll bCAmbHQ7YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tJmd0OyAoYmFsYXpzLmxlbmd5ZWxAZXJp Y3Nzb24uY29tKSAmbHQ7YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tJmd0OzsgYWxleEBjbGVt bS5vcmc7IE1hcnRpbiBCam9ya2x1bmQgJmx0O21iakB0YWlsLWYuY29tJmd0OzsgQWxiZXJ0byBH b256YWxleiBQcmlldG8gKGFsYmVydGdvKSAmbHQ7YWxiZXJ0Z29AY2lzY28uY29tJmd0OzsgbmV0 Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIHJldmlldyBv ZiAmcXVvdDtldmVudC1ub3RpZmljYXRpb24mcXVvdDsgZG9jdW1lbnRzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3JrZWQgb24gdGhlIGZpbHRlcmlu ZyBwcm9ibGVtIGEgYml0IG1vcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IZXJlIGlzIGZpbHRlci55YW5nLCBhIGZpbHRlcmluZyBmcmFtZXdv cmssIGFuZCB0b3BpYy55YW5nLCBhbmQgZXhhbXBsZSBvZiBhIGZpbHRlciB0eXBlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGF0IGNhbiBiZSB1 c2VkIGluIGZpbHRlci55YW5nLiBUb3BpYy1iYXNlZCBmaWx0ZXJpbmcgd2FzIGJyaWVmbHkgZGlz Y3Vzc2VkIGluIFNlb3VsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JTU8gZmlsdGVycyB3aWxsIGNvbnRpbnVlIHRvIGV2b2x2ZSBvdmVyIHRp bWUgc28gdGhlIHNvbHV0aW9uIG5lZWRzIHRvIGFsbG93PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGVtIHRvIGJlIGFkZGVkIGFuZCBjb21iaW5l ZCB3aXRoIG90aGVyIGZpbHRlcnMuJm5ic3A7IFRoZSBjdXJyZW50IFlBTkcgY2hvaWNlLXN0bXQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlzIG5v dCBleHRlbnNpYmxlIGVub3VnaCBvciBwb3dlcmZ1bCBlbm91Z2guPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTm92IDI5 LCAyMDE2IGF0IDc6MTEgUE0sIEVyaWMgVm9pdCAoZXZvaXQpICZsdDs8YSBocmVmPSJtYWlsdG86 ZXZvaXRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXZvaXRAY2lzY28uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFuZHkgQmllcm1h biwgTm92ZW1iZXIgMjksIDIwMTYgODozMA0KIFBNPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBOb3YgMjksIDIwMTYgYXQgODowNSBB TSwgRXJpYyBWb2l0IChldm9pdCkgJmx0OzxhIGhyZWY9Im1haWx0bzpldm9pdEBjaXNjby5jb20i IHRhcmdldD0iX2JsYW5rIj5ldm9pdEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij5UaGFua3MgTWFydGluLDxicj4NCjxicj4NCk1vcmUgaW4gbGluZS4m bmJzcDsgJm5ic3A7QWxzbyBJIGV4dHJhY3RlZCBhcmVhcyB3aGVyZSB3ZSBhbHJlYWR5IGFncmVl IHRvIG1ha2UgdGhpcyBlYXNpZXIgdG8gZm9sbG93Ljxicj4NCjxicj4NCiZndDsgRnJvbTogTWFy dGluIEJqb3JrbHVuZCwgTm92ZW1iZXIgMjksIDIwMTYgNjo0MCBBTTxicj4NCiZndDsgJmd0OyAm Z3Q7SWYgSSB1bmRlcnN0YW5kIHRoZSBpbnRlbnRpb24gY29ycmVjdGx5LCB0aGlzIGRvY3VtZW50 IGlzIHN1cHBvc2VkIHRvPGJyPg0KJmd0OyAmZ3Q7ICZndDsqZGVmaW5lKiBob3cgbm90aWZpY2F0 aW9ucyBhcmUgc2VudCBvdmVyIE5FVENPTkYuJm5ic3A7IEJ1dCB0aGVyZSBpcyBubzxicj4NCiZn dDsgJmd0OyAmZ3Q7c3VjaCBkZWZpbml0aW9uIGluIHRoaXMgZG9jdW1lbnQuJm5ic3A7IEluc3Rl YWQgaXQgc2ltcGx5IHJlcGVhdHM8YnI+DQomZ3Q7ICZndDsgJmd0O2luZm9ybWF0aW9uIGFscmVh ZHkgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTI3N2Jpcy0wMS50eHQsPGJyPg0K Jmd0OyAmZ3Q7ICZndDthbmQgcHJvdmlkZXMgbG90cyBvZiBleGFtcGxlcyBvZiBob3cgdGhlIFlB Tkcgb3BlcmF0aW9ucyBkZWZpbmVkIGluPGJyPg0KJmd0OyAmZ3Q7ICZndDtyZmM1Mjc3YmlzIGFy ZSBlbmNvZGVkIGluIFhNTCBhbmQgc2VudCBvdmVyIE5FVENPTkYuPGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0O0kgc3VnZ2VzdCB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgcmV3 cml0dGVuLiZuYnNwOyBTaW5jZSB0aGUgaWRlYSBpcyB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7cmVw bGFjZSBSRkMgNTI3NywgaXQgbmVlZHMgdG8gZm9jdXMgb24gaG93IG5vdGlmaWNhdGlvbnMgYXJl IHNlbnQ8YnI+DQomZ3Q7ICZndDsgJmd0O292ZXIgTkVUQ09ORiwgYW5kIG5vdCBob3cgUlBDcyBh cmUgZW5jb2RlZCBpbiBYTUwuPGJyPg0KJmd0OyAmZ3Q7IEkgYWdyZWUgLS0gbWF5YmUgZ2V0IHJp ZCBvZiBpdCBhbmQganVzdCBoYXZlIHJmYzUyNzdiaXMgY29udGFpbiB0aGlzPGJyPg0KJmd0OyAm Z3Q7IHRleHQ8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmx0O2V2Jmd0OyA1Mjc3Ymlz IGlzIHN1cHBvc2VkIHRvIGFsbG93IHRyYW5zcG9ydHMgb3RoZXIgdGhhbiBORVRDT05GLiZuYnNw OyBJZiB3ZSBwdXQ8YnI+DQomZ3Q7IHRoZSBORVRDT05GIHNwZWNpZmljIHN0dWZmIGluIGhlcmUg d2UgbG9zZSB0aGF0IHNlcGFyYXRpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgV2UgbmVlZCAqc29t ZSogZG9jdW1lbnQgdGhhdCBkZWZpbmVzIGhvdyBub3RpZmljYXRpb25zIGFyZSBzZW50IG92ZXI8 YnI+DQomZ3Q7IE5FVENPTkYuJm5ic3A7IFRoaXMgZG9jdW1lbnQgbmVlZHMgdG8gaGF2ZSB0aGUg c3BlY2lmaWNhdGlvbiBmb3IgdGhlICZsdDtub3RpZmljYXRpb24mZ3Q7PGJyPg0KJmd0OyBlbGVt ZW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZW4gd2UgbmVlZCBhIHByb3RvY29sLWluZGVwZW5k ZW50IGRvY3VtZW50IHRoYXQgZGVmaW5lcyB0aGUgY29uY2VwdCBvZjxicj4NCiZndDsgc3RyZWFt cyBhbmQgc3Vic2NyaXB0aW9ucywgc3RyZWFtIGRpc2NvdmVyeSwgZXRjLjxicj4NCiZndDs8YnI+ DQomZ3Q7IEkgKnRoaW5rKiB0aGF0IHlvdXIgaW50ZW50aW9uIGlzIHRoYXQgbmV3IGNsaWVudHMg cmVhbGx5IHNob3VsZCBiZSB1c2luZzxicj4NCiZndDsgJmx0O2VzdGFibGlzaC1zdWJzY3JpcHRp b24mZ3Q7IGluc3RlYWQgb2YgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7LCBzaW5jZSBpdCBp cyBwcm90b2NvbC08YnI+DQomZ3Q7IGluZGVwZW5kZW50IGFuZCBzdXBwb3J0IG1vZGlmaWNhdGlv biBhbmQgZGVsZXRpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgd2UgYWxzbyB3YW50IHRvIGJl IGZ1bGx5IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggNTI3NywgSSB0aGluayB3ZSBzaG91bGQ8 YnI+DQomZ3Q7IGNyZWF0ZSBhIGRvY3VtZW50IHRoYXQgaXMgbXVjaCBjbG9zZXIgdG8gdGhlIGN1 cnJlbnQgNTI3NyAtIGVzc2VudGlhbGx5IGp1c3Q8YnI+DQomZ3Q7IGNyZWF0aW5nIGEgWUFORyBt b2RlbCBmb3IgdGhlIGNvbmZpZyBmYWxzZSBkYXRhIGFuZCBmb3IgdGhlICZxdW90O29sZCZxdW90 OyAmbHQ7Y3JlYXRlLTxicj4NCiZndDsgc3Vic2NyaXB0aW9uJmd0Oy48YnI+DQo8YnI+DQpXZSBh YnNvbHV0ZWx5IHdhbnQgdG8gaGF2ZSBhIGZ1bGwgYmFja3dhcmRzIGNvbXBhdGlibGUgY2FwYWJp bGl0eS4mbmJzcDsgVGhlIHF1ZXN0aW9uIGlzIGhvdyB0byBiZXN0IGZyYW1lIHRoaXMgaW4gZG9j dW1lbnRzLiZuYnNwOyBJdCBpcyBwb3NzaWJsZSB0byByZWJ1aWxkIFJGQy01Mjc3IHdpdGggYSBZ QU5HIG1vZGVsLiZuYnNwOyBCdXQgdGhlbiB5b3UgY2FuJ3QganVzdCBsYXllciBvbiBuZXcgY2Fw YWJpbGl0aWVzIGRyaXZpbmcgdGhpcyB3b3JrLiZuYnNwOyAoQW5kIHRoaXMNCiBpcyB3aHkgd2Ug bmVlZCBzZXBhcmF0ZSBuYW1lc3BhY2VzLik8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgbmVlZCB0byBwYXJzZSBh bmQgdW5kZXJzdGFuZCAmcXVvdDtmdWxsIGJhY2t3YXJkcyBjb21wYXRpYmxlJnF1b3Q7LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RG8g d2Ugd2FudCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgdG8gYmUgbGV2ZXJhZ2VkIGludG8gdGhl IG5ldyBzb2x1dGlvbj8mbmJzcDsgWWVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkEgc2VydmVyIHNob3VsZCBiZSBjYXBhYmxlIG9mIHN1cHBv cnRpbmcgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IGZvcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5vbGQsIGRlcHJlY2F0ZWQgc3Vic2Ny aXB0aW9ucywgYW5kICZsdDtlc3RhYmxpc2gtc3Vic2NyaXB0aW9uJmd0OyBmb3IgdGhlIG5ldyBj dXJyZW50IHN1YnNjcmlwdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5EbyB3ZSBuZWVkIHRvIHVwZGF0ZSBSRkMgNTI3NyBvciBy ZXBsYWNlIGl0PyBJTU8sIHJlcGxhY2UgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNpbmNlIHRoZSAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlv biZndDsgUlBDIHdhcyBuZXZlciBpbiBhIFlBTkcgbW9kdWxlLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5pdCBjYW4gYmUgbGVmdCBvdXQgb2Yg dGhlIG5ldyBtb2R1bGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbHQ7ZXYmZ3Q7IEkgYmVsaWV2ZSBhdCBtaW5pbXVtIHRoYXQgJmx0O2NyZWF0ZSBzdWJz Y3JpcHRpb24mZ3Q7IHNob3VsZCBiZSBwdWxsZWQgb3V0IG9mIHRoZSBuZXcgbW9kdWxlLiZuYnNw OyBJdCBuZWVkcw0KIGl0cyBzZXBhcmF0ZSBuYW1lc3BhY2UuJm5ic3A7ICZuYnNwO1BlcmhhcHMg bm9ib2R5IGlzIHJlYWR5IHRvIGFkdm9jYXRlIGZvciBhIHBhcmFsbGVsIDUyNzctbGVnYWN5IFlB TkcgbW9kZWwgc2luY2UgbmV3IGRldmVsb3BtZW50IHNob3VsZCBnbyB0byB0aGUgbmV3IHBhcmFk aWdtIGFueXdheS4mbmJzcDsgSW4gdGhpcyBjYXNlLCB3ZSBjb3VsZCBqdXN0IGhhdmUgYSBzdGFu ZGFsb25lIGxlZ2FjeSA1Mjc3IHNlY3Rpb24gaW4gdGhlIGRvY3VtZW50IGZvciBhbnl0aGluZw0K IG5lZWRlZC4mbmJzcDsgVGhpcyB3b3VsZCBtYWtlIHRoaW5ncyBzaW1wbGVyIGFuZCBlYXNpZXIg dG8gdGVhc2UgYXBhcnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RXZlbiBtb3JlIHJhZGljYWwsIEkgdGhpbmsgc3RyZWFt cyBzaG91bGQgYmUgcmVtb3ZlZCwgZXZlbiB0aGUgTkVUQ09ORiBzdHJlYW0uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXkgcmVhbGx5IHNl cnZlIG5vIHB1cnBvc2Ugbm93IHRoYXQgc3Vic2NyaXB0aW9ucyBhcmUgZm9ybWFsaXplZCBhbmQg Y2FuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PmV2ZW4gYmUgY29uZmlndXJlZC4mbmJzcDsgSXQgaXMgYWxzbyBiYWQgZGVzaWduIHRvIGNvdXBs ZSB0aGUgb3V0cHV0IG1lc3NhZ2UgZW5jb2Rpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aW50byB0aGUgaW5wdXQgc3RyZWFtLiAoZS5nLiwg TkVUQ09ORiBzdHJlYW0gTVVTVCBiZSBYTUwgZW5jb2RlZCkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbHQ7ZXYmZ3Q7IEV2ZW4gYXMgd2UgbW92 ZSBhd2F5IGZyb20gc3RyZWFtcywgSSBzdGlsbCBjYW4gc2VlIHJlYXNvbnMgZm9yIGl0LiZuYnNw OyAoQWRkaW5nIEJhbGF6cyAmYW1wOyBBbGV4IGFzIHRoZXkNCiBoYXZlIGJlZW4gcHJvcG9uZW50 cy4pJm5ic3A7IFRoZSBiaWdnZXN0IHJlYXNvbiBmb3Igc3RyZWFtcyBpcyB0aGF0IGEgcm9idXN0 IGN1c3RvbWVyIGRlc2lnbmVkIGZpbHRlcnMgYXJlIGhhcmQuJm5ic3A7IElmIGEgdmVuZG9yL2N1 c3RvbWVyL2V0Yy4gaXMgYWJsZSB0byBwcmUtZmlsdGVyIG5vdGlmaWNhdGlvbnMgb3IgZGF0YXN0 b3JlIGluIGFuIGludGVyZXN0aW5nIGFuZCB1c2VmdWwgd2F5IG5vdCBzdXBwb3J0YWJsZSBieSBv dXIgZmlsdGVyaW5nIHNlbWFudGljcywNCiB0aGlzIGlzIGEgZ29vZCB3YXkgdG8gYWxsb3cgdGhl IHByZS1maWx0ZXJpbmcuIFNvbWUgZXhhbXBsZXMgd2hpY2ggY291bGQgYmUgaW50ZXJlc3Rpbmc6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tNTM1MTQyNjM0NjkwMTk2Mzk3NG1z b2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OlN5bWJvbDtjb2xvcjojMUY0OTdEIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FdmVudCBub3RpZmljYXRpb25z IHdoZW4gbmV3IGRldmljZXMgY29ubmVjdCB0byBhIG5ldHdvcms8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibS01MzUxNDI2MzQ2OTAxOTYzOTc0bXNvbGlzdHBhcmFncmFwaCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5 N0QiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkFsYXJtcyBwb3RlbnRpYWxseSBzZXQgYWNyb3NzIG11bHRpcGxl IFlBTkcgbW9kZWxzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DdXJyZW50bHksIGZp bHRlcnMgYXJlIGRlZmluZWQgYXMgYSBjaG9pY2Utc3RtdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBpbXBsaWVkIE9SLWV4cHIgaXMg dG9vIHNpbXBsaXN0aWMuIEFuIGV4cGxpY2l0IGNvbWJpbmF0aW9uIG9mIE9SLCBBTkQsIGFuZCBO T1QgaXMgcmVxdWlyZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Zm9yIGRpZmZlcmVudCB0eXBlcyBvZiBmaWx0ZXJzLiAmbmJzcDsoc2ltaWxh ciB0byBZQU5HIDEuMSBpZi1mZWF0dXJlLXN0bXQgc3ludGF4KS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZsdDtldiZndDsgVG90YWxseSBhZ3Jl ZSB0aGF0IHdlIG5lZWQgcm9idXN0IGZpbHRlcnMuJm5ic3A7IEZpZ3VyaW5nIHRoaXMgcHJvYmxl bSBzcGFjZSBvdXQgaXMgYSBmdWxsIHRpbWUgam9iLiZuYnNwOw0KIEZpZ3VyaW5nIG91dCBob3cg dG8gZW5jb2RpbmcgZmlsdGVyaW5nIGNhcGFiaWxpdGllcyBzdXBwb3J0ZWQgb24gZGlmZmVyZW50 IHR5cGVzIG9mIGNvbnN0cmFpbmVkIHBsYXRmb3JtcyBpcyBub24tdHJpdmlhbC4mbmJzcDsgSSB3 b3VsZCBsb3ZlIHRvIHNlZSBzb21lb25lIHRha2UgdGhpcyBvbiBmb3IgdGhlIGluZHVzdHJ5LiZu YnNwOyBBbnkgdGFrZXJzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkVyaWM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkFzIGxheWVyaW5nIHVwb24gUkZDLTUyNzcgY2Fubm90IGdpdmUgdGhl IG5ldyBjYXBhYmlsaXRpZXMgYmVpbmcgcmVxdWVzdGVkIG9mIHVzIGluIHBsYWNlcyBsaWtlIFJG Qy03OTIzIChlLmcuLCBtdWx0aXBsZSBzdWJzY3JpcHRpb25zL3Nlc3Npb24pLCB3ZSBhcmUgbW92 aW5nIG5vdyB0byBwdXQgYWxsIGVsZW1lbnRzDQoganVzdCBuZWVkZWQgZm9yIGJhY2t3YXJkcyBj b21wYXRpYmlsaXR5IGluIHRoZSBuZXRjb25mIHRyYW5zcG9ydCBkcmFmdC4mbmJzcDsgV2UgY291 bGQgYWxzbyBzZXBhcmF0ZSBhbGwgdGhpcyBvdXQgaW50byBhbm90aGVyIGluZGVwZW5kZW50IGJh Y2t3YXJkcyBjb21wYXRpYmlsaXR5IGV4dGVuc2lvbi4mbmJzcDsgQnV0IHdlIGZlbHQgd2UgaGFk IGVub3VnaCBkcmFmdHMgaW4gcHJvZ3Jlc3Mgd2hlcmUgd2UgZGlkbid0IHdhbnQvbmVlZCBhIGZp ZnRoIG9uZS48YnI+DQo8YnI+DQomZ3Q7ICZndDsgW0FHXSBGV0lXLCB0aGUgc2NvcGUgb2YgZWFj aCBkb2MgaXMgc3VtbWFyaXplZCBvbjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LW5ldGNvbmYtNS5wZGYi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L3Ns aWRlcy9zbGlkZXMtOTYtbmV0Y29uZi01LnBkZjwvYT48YnI+DQomZ3Q7ICZndDsgKHNsaWRlPGJy Pg0KJmd0OyAmZ3Q7ICM1KTxicj4NCiZndDsgJmd0OyBbQUddIFRoZSBrZXkgaXMgdGhhdCB0aGUg c3BlYyBmb3IgTkMgY29tZXMgZnJvbSB0aGUgdW5pb24gb2YgNTI3Ny1iaXM8YnI+DQomZ3Q7ICZn dDsgYW5kIHRoZSBOQyB0cmFuc3BvcnQgZG9jPGJyPg0KJmd0OyAmZ3Q7IChkcmFmdC1pZXRmLW5l dGNvbmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zLTAxLnR4dCkgVGhlIE5DPGJyPg0KJmd0 OyAmZ3Q7IHRyYW5zcG9ydCBkb2MgaXMgbm90IG1lYW50IHRvIHN0YW5kIGFsb25lLjxicj4NCiZn dDsgJmd0OyBUaGUgZG9jIGNvbnRhaW5zIGhvdyA1Mjc3LWJpcyBjb25jZXB0cyBhcmUgcmVhbGl6 ZWQgd2hlbiB1c2luZyBOQyBhbmQ8YnI+DQomZ3Q7ICZndDsgTkMtc3BlY2lmaWMgYXNwZWN0cy4g RS5nLjo8YnI+DQomZ3Q7ICZndDsgLSB0aGUgdXNlIG9mIE5DIGNhbGwtaG9tZSBmb3IgY29uZmln dXJlZCBzdWJzY3JpcHRpb25zPGJyPg0KJmd0OyAmZ3Q7IC0gYmFja3dhcmRzIGNvbXBhdGliaWxp dHk8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IC0gdGhlIGV4aXN0ZW5jZSBvZiBhIE5FVENP TkYgc3RyZWFtPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAtIHN1cHBvcnQgb2YgL25ldGNv bmYvc3RyZWFtczxicj4NCiZndDsgJmd0OyAmbHQ7ZXYmZ3Q7IFllcywgYW55IDUyNzdiaXMgdG9w aWMgc3BlY2lmaWMgdG8gb25seSBORVRDT05GIHRyYW5zcG9ydCBzaG91bGQ8YnI+DQomZ3Q7ICZn dDsgYmUgaW4gbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IEkgYWdyZWUgd2l0aCBNYXJ0aW4gdGhhdCBkdXBsaWNhdGluZyBub3JtYXRpdmUg dGV4dCBpcyBiYWQuPGJyPg0KJmd0OyAmZ3Q7IE5vdCBoYXZpbmcgYW55IG5vcm1hdGl2ZSB0ZXh0 IGlzIGV2ZW4gd29yc2UuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZsdDtldiZndDsg JiM0MzsxLiZuYnNwOyBUbyBoZWxwIGFkZHJlc3MgdGhhdCwgSSBqdXN0IGJ1aWx0IGEgd2hvbGUg bGlzdCBvZiBwZW5kaW5nIGNoYW5nZXM8YnI+DQomZ3Q7IGFjcm9zcyB0aGUgZm91ciBkcmFmdHMu Jm5ic3A7IEFuZCBpbiBxdWl0ZSBhIGZldyBwbGFjZXMgSSBwdWxsZWQgb3V0IGR1cGxpY2F0aXZl IHRleHQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0gdGhlIGRlZmluaXRpb24gb2Yg Y3JlYXRlLXN1YnNjcmlwdGlvbiBtYXkgYmUgbW92ZWQgdG8gdGhpcyBkb2Mgc288YnI+DQomZ3Q7 ICZndDsgdGhhdCBvdGhlciB0cmFuc3BvcnRzIHdvdWxkIGlnbm9yZSBjcmVhdGUtc3Vic2NyaXB0 aW9uIGFuZCB1c2Ugb25seTxicj4NCiZndDsgJmd0OyBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uLCBz aW1wbGlmeWluZyB0aGUgc29sdXRpb248YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgVGhhdCBzZWVtcyB3cm9uZyBzaW5jZSA1Mjc3IGhhZCBjcmVhdGUtc3Vic2Ny aXB0aW9uIHNvIGl0IHNob3VsZCBzdGF5PGJyPg0KJmd0OyAmZ3Q7IGluIDUyNzdiaXM8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmx0O2V2Jmd0OyBJdCBpcyByZWFsbHkgYSBzdHlsZSB0 aGluZyBzbyBpdCBkb2VzbuKAmXQgbWF0dGVyIHRoYXQgbXVjaCBlaXRoZXIgd2F5Ljxicj4NCiZn dDsgQ3VycmVudCB0aGlua2luZyBpcyB0aGF0IGFzIHdlIG5lZWQgYm90aCB0aGUgbmV3IGFuZCBv bGQgbmFtZXNwYWNlcy48YnI+DQomZ3Q7IFRoZXJlZm9yZSBpdCBzZWVtcyBzaW1wbGVyIHRvIGhh dmUgYW55dGhpbmcgaW4gdGhlIG9sZCBuYW1lc3BhY2UgKOKAnGNyZWF0ZS08YnI+DQomZ3Q7IHN1 YnNjcmlwdGlvbuKAnSkgaW4gbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb24gZHJhZnQuPGJyPg0K Jmd0Ozxicj4NCiZndDsgSSBhZ3JlZSB3aXRoIEFuZHkgdGhhdCBhbnl0aGluZyB0aGF0IGNvbWVz IGZyb20gNTI3NyB0aGF0IHlvdSBuZWVkIHRvIGtlZXA8YnI+DQomZ3Q7IGZvciBiYWNrd2FyZHMg Y29tcGF0aWJpbGl0eSByZWFzb25zIHNob3VsZCBnbyBpbnRvIDUyNzdiaXMuPGJyPg0KPGJyPg0K UmlnaHQgbm93IGl0IGlzIGluIDUyNzdiaXMuJm5ic3A7IEJ1dCB3ZSBhbHJlYWR5IGNhbid0IGhh dmUgZXZlcnl0aGluZyBuZWVkZWQgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHNpbmNlIHRo ZSA1Mjc3YmlzIGlzIHRyYW5zcG9ydCAoTkVUQ09ORikgaW5kZXBlbmRlbnQuJm5ic3A7IFNvIGl0 IHNlZW1lZCBsb2dpY2FsIHRvIHB1dCBpdCBORVRDT05GIHRyYW5zcG9ydCBkcmFmdC4mbmJzcDsg KEFnYWluIHdlIHdlcmUgdHJ5aW5nIHRvIGxpbWl0IHRoZSBwcm9saWZlcmF0aW9uDQogb2YgZHJh ZnRzLik8YnI+DQo8YnI+DQpJbiB0aGUgZW5kLCBJIGFtIG9rIGFzIGxvbmcgYXMgaXQgbGFuZHMg c29tZXdoZXJlLiZuYnNwOyBTbyBpZiBwZW9wbGUgcHJlZmVyLCB3ZSBjb3VsZCBhbHNvIGhhdmUg dGhpcyBhcyBhIGNvbXBsZXRlbHkgc2VwYXJhdGUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgc2Vj dGlvbiAmIzQzOyBZQU5HIG1vZGVsIGluIDUyNzdiaXMuPGJyPg0KPGJyPg0KJmd0OyAmZ3Q7IC0g aG93IHRvIGlzc3VlIG5vdGlmaWNhdGlvbnMgaW4gSlNPTiBhcmUgc2VudCB1c2luZyBOQyAodGhp cyBpcyBhbHNvPGJyPg0KJmd0OyAmZ3Q7IGluIDUyNzctYmlzKS4gQXJndWFibHksIGl0IGJlbG9u Z3MgaW4gdGhlIE5DIHRyYW5zcG9ydCBkb2M8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhpcyBpcyBwb29ybHkgZGVmaW5lZC48YnI+ DQomZ3Q7ICZndDsgTkVUQ09ORiBkb2VzIG5vdCBzdXBwb3J0IEpTT04gZW5jb2RpbmcgYW5kIElN TyBzaG91bGQgbm90IGRlZmluZSBKU09OPGJyPg0KJmd0OyAmZ3Q7IGVuY29kaW5nIHVubGVzcyB0 aGUgZW50aXJlIHByb3RvY29sIHN1cHBvcnRzIGl0IGNsZWFubHkuPGJyPg0KJmd0OyAmZ3Q7IFRo ZSBwcm9wb3NhbCBzZWVtcyB0byBiZSB0byB1c2UgWE1MIGZvciAmbHQ7cnBjJmd0OyBhbmQgJmx0 O3JwYy1yZXBseSZndDssIGJ1dDxicj4NCiZndDsgJmd0OyBhbGxvdyBzb21lIHNwZWNpYWwgbW9k ZSB3aGVyZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyBpcyBzZW50IGluIEpTT04uPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0O28mbmJzcDsgU2VjdGlv biAyLjE8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7IFRoZSB0 ZXh0IHNheXM6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAm bmJzcDtUaGUgTkVUQ09ORiBldmVudCBzdHJlYW0gY29udGFpbnMgYWxsPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7TkVUQ09ORiBYTUwgZXZlbnQgbm90aWZpY2F0aW9ucyBzdXBwb3J0 ZWQgYnkgdGhlIHB1Ymxpc2hlciw8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7Jm5ic3A7IEZpcnN0IG9mIGFsbCwgc2luY2UgdGhpcyBkb2N1bWVudCBpcyBwcm90b2NvbC1h Z25vc3RpYywgc2hvdWxkIGl0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmVhbGx5IGRlZmluZSB0aGUg c3RyZWFtICZxdW90O05FVENPTkYmcXVvdDs/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZsdDtldiZndDsgQWdyZWUsIHdoaWNoIGlzIHdoeSB0aGlzIGlzIGdvaW5nIHRvIG5ldGNvbmYt ZXZlbnQtbm90aWZpY2F0aW9uLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5i c3A7IFNlY29uZGx5LCB0aGlzIHdvdWxkIGJlIGEgbmV3IHJlcXVpcmVtZW50LiZuYnNwOyBUaGVy ZSBpcyBub3RoaW5nIGluIFJGQzxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7IDUyNzcgdGhhdCBz YXlzIHRoYXQgYSBub3RpZmljYXRpb24gaXMgc2VudCBvbiAmcXVvdDtORVRDT05GJnF1b3Q7IGJl IGRlZmF1bHQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZsdDtldiZndDsgNTI3NyBz ZWN0aW9uIDMuMi4zIHRhbGtzIGFib3V0IHRoZSBkZWZhdWx0IGV2ZW50IHN0cmVhbSB3aGljaCBo YXM8YnI+DQomZ3Q7ICZndDsgYWxsIE5FVENPTkYgZXZlbnQgbm90aWZpY2F0aW9uczxicj4NCiZn dDs8YnI+DQomZ3Q7IFlvdSdyZSByaWdodC4mbmJzcDsgVGhlIHF1ZXN0aW9uIGlzIHRoZW4gd2hh dCBpcyBhbiAmcXVvdDtORVRDT05GIFhNTCBldmVudDxicj4NCiZndDsgbm90aWZpY2F0aW9uJnF1 b3Q7PyZuYnNwOyBJIHRoaW5rIHRoZSBpbnRlbnRpb24gd2FzIHRoYXQgdGhlc2Ugd291bGQgYmUg JnF1b3Q7bm90aWZpY2F0aW9uczxicj4NCiZndDsgcmVsYXRlZCB0byBORVRDT05GJnF1b3Q7LCBy YXRoZXIgdGhhbiAmcXVvdDthbGwgWUFORy1kZWZpbmVkIG5vdGlmaWNhdGlvbnMmcXVvdDsuJm5i c3A7IFRoaXMgbmVlZHM8YnI+DQomZ3Q7IHNvbWUgZGlzdWNzc2lvbi48YnI+DQo8YnI+DQpBZ3Jl ZTxicj4NCjxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7IEkgdGhpbmsgdGhpcyB0ZXh0IHNob3Vs ZCBiZSByZW1vdmVkLiZuYnNwOyBIb3cgbm90aWZpY2F0aW9ucyBhcmUgbWFwcGVkPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgdG8gc3RyZWFtcyBpcyBzaG91bGQgYmUgb3V0IG9mIHNjb3BlIGZvciB0aGlz IGRvY3VtZW50Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbHQ7ZXYmZ3Q7IFllcywg c3RyZWFtcyBhcyBhIHdob2xlIHdlcmUgc29tZXRoaW5nIHdlIGRlZmVycmVkIGZvciBhIHdoaWxl LiZuYnNwOyBMYXRlc3Q8YnI+DQomZ3Q7IHRoaW5raW5nIGlzIHdlIG1pbmltaXplIHN0cmVhbXMg dG8gdGhlIGRlZ3JlZSBwb3NzaWJsZS4mbmJzcDsgTG9vayBmb3IgbGVnYWN5IHN0dWZmIHRvPGJy Pg0KJmd0OyBiZSBpbiBuZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbi48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBEbyB5b3UgbWVhbiB0aGF0IHlvdSBwbGFuIHRvIHVwZGF0ZSB0aGUgdGV4dCBhcm91bmQg c3RyZWFtcz8mbmJzcDsgSWYgc28sIHRoYXQnczxicj4NCiZndDsgZmluZS48YnI+DQo8YnI+DQpZ ZXM8YnI+DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyBJbiBsaXN0ICZxdW90O2ZpbHRlciZx dW90OywgY2hhbmdlICZxdW90O2ZpbHRlci1pZCZxdW90OyB0byAmcXVvdDtpZCZxdW90Oy48YnI+ DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7IEluIGxpc3QgJnF1b3Q7 c3Vic2NyaXB0aW9uJnF1b3Q7LCBjaGFuZ2UgJnF1b3Q7c3Vic2NyaXB0aW9uLWlkJnF1b3Q7IHRv ICZxdW90O2lkJnF1b3Q7Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbHQ7ZXYmZ3Q7 IE1vZGVsIHB1cml0eS13aXNlIHlvdSBhcmUgY29ycmVjdC4mbmJzcDsgV2l0aCBib3RoIHN1YnNj cmlwdGlvbiBpZCBhbmQgZmlsdGVyPGJyPg0KJmd0OyBpZCwgc2V2ZXJhbCBwZW9wbGUgZXhwcmVz c2VkIHRoZXkgd2FudGVkIHRoZSBvYmplY3RzIHRvIGJlIGltbWVkaWF0ZWx5IGFuZDxicj4NCiZn dDsgb2J2aW91c2x5IGRpZmZlcmVudGlhYmxlLiZuYnNwOyAmbmJzcDtIb3BlZnVsbHkgb3RoZXJz IHdpbGwgY2hpbWUgaW4gaGVyZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHRoaW5rIHdlIHNob3Vs ZCB0cnkgdG8ga2VlcCB0aGUgc2FtZSBzdHlsZSBhY3Jvc3MgSUVURiBkb2N1bWVudHMuPGJyPg0K Jmd0OyBNb3N0IG1vZGVscyBkbyBub3QgdXNlIHJlZHVuZGFudCBxdWFsaWZpZXJzLCBlc3BlY2lh bGx5IG5vdCBmb3IgZ2VuZXJpYyBuYW1lczxicj4NCiZndDsgbGlrZSAnaWQnIG9yICduYW1lJyB3 aGVuIHVzZWQgYXMgYSBrZXkuPGJyPg0KPGJyPg0KSSBhbSBoYXBweSB3aXRoIHdoYXRldmVyIGNv bnZlbnRpb24gdGhlIFdHIGNob29zZXMuPGJyPg0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsg SW4gbGlzdCAmcXVvdDtzdWJzY3JpcHRpb24mcXVvdDssIGNoYW5nZSAmcXVvdDtzdGFydFRpbWUm cXVvdDsgdG8gJnF1b3Q7c3RhcnQtdGltZSZxdW90OyBhbmQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAm cXVvdDtzdG9wVGltZSZxdW90OyB0byAmcXVvdDtzdG9wLXRpbWUmcXVvdDssIGZvciBjb25zaXN0 ZW5jeS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmx0O2V2Jmd0OyB3ZSBrZXB0IHRo ZSBvbGQgbmFtZXMgZm9yIGJhY2t3YXJkcyBlcXVpdmFsZW5jeSB0byA1Mjc3Ljxicj4NCiZndDs8 YnI+DQomZ3Q7IEJ1dCB0aGVyZSBpcyBub3RoaW5nIHRvIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxl IHdpdGggaW4gdGhpcyBjYXNlLjxicj4NCiZndDsgVGhlIGlucHV0IHBhcmFtdGVycyB0byB0aGUg ZXhpc3RpbmcgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IGNhbm5vdCBiZSBjaGFuZ2VkLDxi cj4NCiZndDsgYnV0IG5ldyBub2RlcyBzaG91bGQgYmUga2VwdCBjb25zaXN0ZW50Ljxicj4NCjxi cj4NCk9rLiZuYnNwOyBTbyB5b3Ugd2FudCBzdGFydC10aW1lIGluIHRoZSBZQU5HIG1vZGVsLCBh bmQgc3RhcnRUaW1lIGluIHRoZSBSUEMuJm5ic3A7IFRoYXQgY2FuIGJlIGRvbmUuPGJyPg0KPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgSW4gbGlzdCAmcXVvdDtzdWJzY3JpcHRpb24mcXVvdDss IGNoYW5nZSBjaG9pY2UgJnF1b3Q7cHVzaC1zb3VyY2UmcXVvdDsgdG8gYSBiZXR0ZXI8YnI+DQom Z3Q7ICZndDsgJmd0OyBuYW1lLCBtYXliZSAmcXVvdDtlZ3Jlc3MtaW50ZXJmYWNlJnF1b3Q7ICh0 aGlzIGlzIGhvdyBpdCBpcyBkZXNjcmliZWQpLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmbHQ7ZXYmZ3Q7IHB1c2gtc291cmNlIGNhbiBhbHNvIGJlIGFuIElQIEFkZHJlc3MuJm5ic3A7 IEFub3RoZXIgbmFtZSBwb3NzaWJpbGl0eSBmb3IgdGhpczxicj4NCiZndDsgbWlnaHQgYmUg4oCc T3JpZ2luYXRlcy1mcm9t4oCdLCB0aGF0IGlzIHRoZSBiYXNpYyBpZGVhLjxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoZSBjdXJyZW50IGRyYWZ0IGhhczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBjaG9pY2UgcHVzaC1zb3VyY2Ugezxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlc2NyaXB0aW9uPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O0lkZW50aWZpZXMgdGhlIGVn cmVzcyBpbnRlcmZhY2Ugb24gdGhlIFB1Ymxpc2hlciBmcm9tPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3doaWNoIG5vdGlmaWNhdGlvbnMg d2lsbCBvciBhcmUgYmVpbmcgc2VudC4mcXVvdDs7PGJyPg0KJmd0Ozxicj4NCiZndDsgWW91IHBy b2JhYmx5IG5lZWQgdG8gYWRqdXN0IHRoaXMsIGFuZCBtYWtlIGl0IGNsZWFyIHdoYXQgdGhlIGlw LWFkZHJlc3MgY2FzZTxicj4NCiZndDsgcmVhbGx5IG1lYW5zLjxicj4NCjxicj4NCmFncmVlPGJy Pg0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgSW4gbGlzdCAmcXVvdDtyZWNlaXZlciZxdW90 Oywgd2hhdCBpcyBhICZxdW90O211bHRpcG9pbnQgYWRkcmVzcyZxdW90Oz88YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmx0O2V2Jmd0OyB3ZSBhcmUgdHJ5aW5nIG5vdCB0byBsaW1pdCBy ZWNlaXZlcnMgdG8gaG9zdHMuIFBlcmhhcHMgbXVsdGljYXN0IGFkZHJlc3MgaXM8YnI+DQomZ3Q7 IG9rLiZuYnNwOyBSZWFsbHkgd2Ugd291bGQgYmUgZ29vZCB3aXRoIHR5cGU6IGluZXQ6aG9zdC48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgdHlwZSBpcyBpbmV0Omhvc3QgYWxyZWFkeS48YnI+DQom Z3Q7PGJyPg0KJmd0OyBZb3Ugc2hvdWxkIHByb2JhYmx5IGNsYXJpZnkgdGhlIGRlc2NyaXB0aW9u cy48YnI+DQo8YnI+DQphZ3JlZTxicj4NCjxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7IFJlbW92 ZSB0aGUgbGVhZiAmcXVvdDtzb3VyY2UtdnJmJnF1b3Q7OyB0aGlzIHNob3VsZCBldmVudHVhbGx5 IGJlIGFsaWduZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyB3aXRoJm5ic3A7IGRyYWZ0LWlldGYtcnRn d2ctbmktbW9kZWwuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFBlcmhhcHMgYSBwbGFj ZSBmb3Igc2NoZW1hLW1vdW50Pzxicj4NCiZndDs8YnI+DQomZ3Q7IE5vdCByZWFsbHksIHJhdGhl ciBhbiBhdWdtZW50Ljxicj4NCjxicj4NCkhhcHB5IHRvIGdvIHdpdGggd2hhdGV2ZXIgY29udmVu dGlvbiBwZW9wbGUgd2FudCB0byB1c2UuPGJyPg0KPGJyPg0KJmd0OyAmZ3Q7IFdlIHNob3VsZCBs ZWF2ZSBzb3VyY2UtdnJmIGluPGJyPg0KJmd0OyAmZ3Q7IHBsYWNlIHVudGlsIHdlIGhhdmUgdGhl IHByb3BlciBkZWZpbml0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IE5vIEkgc2F5IHJlbW92ZSBp dCB1bnRpbCB5b3UgaGF2ZSBhIHByb3BlciBkZWZpbml0aW9uLiZuYnNwOyBJZiB5b3Uga2VlcCBp dCB5b3UgbmVlZCB0bzxicj4NCiZndDsgaGF2ZSBhIHByb3BlciBkZWZpbml0aW9uIG9mIHdoYXQg aXQgaXMsIGFuZCBpdCBuZWVkcyB0byBiZSBpbnRlcm9wZXJhYmxlIGFjcm9zczxicj4NCiZndDsg aW1wbGVtZW50YXRpb25zLjxicj4NCjxicj4NCldlIHdpbGwgYWRkcmVzcyB3aXRoIHRoZSBwcm9w ZXIgY29udmVudGlvbiBpbiB0aGUgbmV4dCBkcmFmdDxicj4NCjxicj4NCiZndDsgJmd0OyBCdXQg d2UgY291bGQgdXBkYXRlIHRoZSB0ZXh0IHNob3dpbmcgdGhlcmUgaXMgYSBwZW5kaW5nIGRlY2lz aW9uLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7IFlvdSBoYXZlIG1h ZGUgdGhlIHN0cmVhbSBuYW1lIGFuIGlkZW50aXR5LiZuYnNwOyBJbiBSRkMgNTI3NyBpdCB3YXMg YTxicj4NCiZndDsgJmd0OyAmZ3Q7IHN0cmluZy4mbmJzcDsgQnkgdXNpbmcgYW4gaWRlbnRpdHks IHlvdSBzZXZlcmx5IGxpbWl0IGhvdyBpdCBjYW4gYmUgdXNlZDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyB3aXRoIGEgc3RyaW5nIG5ldyBzdHJlYW1zIGNhbiBiZSBkeW5hbWljYWxseSBjcmVhdGVkIGF0 IHJ1bi10aW1lLDxicj4NCiZndDsgJmd0OyAmZ3Q7IGJ1dCB3aXRoIGFuIGlkZW50aXR5IHN0cmVh bSBuYW1lcyBtdXN0IGJlIGtub3duIGF0IGRlc2lnbi10aW1lLjxicj4NCiZndDsgJmd0OyAmZ3Q7 Jm5ic3A7IEkgdGhpbmsgdGhlIHN0cmVhbSBuYW1lIHNob3VsZCBiZSBjaGFuZ2VkIGJhY2sgdG8g YSBzdHJpbmcuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZsdDtldiZndDsgYXMgdGhl IG1ham9yaXR5IG9mIHRoZSBwZW9wbGUgaW4gdGhlIGluZm9ybWFsIGRlc2lnbiB0ZWFtIHdlcmUg YWdhaW5zdDxicj4NCiZndDsgdGhlIGV4cGFuc2lvbiBvZiBzdHJlYW1zLCB0aGlzIGlzIGxpa2Vs eSBhIG1vb3QgcG9pbnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBkb24ndCBrbm93IHdoYXQgJnF1 b3Q7ZXhwYW5zaW9uIG9mIHN0cmVhbXMmcXVvdDsgbWVhbnMsIGFuZCBJIGRvbid0IHVuZGVyc3Rh bmQgd2hhdDxicj4NCiZndDsgJnF1b3Q7dGhpcyZxdW90OyByZWZlcnMgdG8gaW4gJnF1b3Q7dGhp cyBpcyBsaWtlbHkgYSBtb290IHBvaW50JnF1b3Q7Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEJ1dCBp ZiB3ZSBrZWVwIHRoZSBzdHJlYW0gbmFtZSBhcyBhbiBpZGVudGl0eSB3ZSdyZSBubyBsb25nZXIg YmFja3dhcmRzPGJyPg0KJmd0OyBjb21wYXRpYmxlIHdpdGggUkZDIDUyNzcsIGFuZCB3ZSBzZXZl cmx5IGxpbWl0IHRoZSBmdW5jdGlvbmFsaXR5LiZuYnNwOyBJIHN0cm9uZ2x5PGJyPg0KJmd0OyBv YmplY3QgdG8gc3VjaCBhIGNoYW5nZS48YnI+DQo8YnI+DQpJIGFtIGZpbmUgd2l0aCBzdHJpbmcs IGVzcGVjaWFsbHkgYXM6PGJyPg0KKGEpIHdlIGFyZSBtb3ZpbmcgYXdheSBmcm9tIHN0cmluZ3Mg aW4gZmF2b3Igb2YgZmlsdGVyczxicj4NCihiKSBjdXN0b20gc3RyZWFtcyBhcmUgbGlrZWx5IHRv IGJlIHRoZSBkb21pbmFudCB1c2UuPGJyPg0KQW55b25lIGhhdmUgYW4gb2JqZWN0aW9uJm5ic3A7 IHRvIHRoaXMgY2hhbmdlPzxicj4NCjxicj4NCiZndDsgJmd0OyAmZ3Q7byZuYnNwOyBTZWN0aW9u IDQuMTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgVGhlIHRl eHQgc2F5czo8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwO0lmIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO3JlcXVlc3QgaXMgcmVq ZWN0ZWQgYmVjYXVzZSB0aGUgcHVibGlzaGVyIGlzIG5vdCBhYmxlIHRvIHNlcnZlIGl0LDxicj4N CiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO3RoZSBwdWJsaXNoZXIgU0hPVUxEIGluY2x1ZGUg aW4gdGhlIHJldHVybmVkIGVycm9yIHdoYXQgc3Vic2NyaXB0aW9uPGJyPg0KJmd0OyAmZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7cGFyYW1ldGVycyB3b3VsZCBoYXZlIGJlZW4gYWNjZXB0ZWQgZm9yIHRo ZSByZXF1ZXN0IHdoZW4gaXQgd2FzPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7cHJv Y2Vzc2VkLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgSSB0 aGluayB0aGlzIGlzIGEgcHJldHR5IHdlaXJkIGlkZWEuJm5ic3A7IEl0IHNlZW1zIGV4dHJlbWVs eSBkaWZmaWN1bHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyB0byBpbXBsZW1lbnQsIGFuZCB0aGUgdXNl IGNhc2UgaXMgbm90IGNsZWFyIGF0IGFsbC4mbmJzcDsgSW4gYW48YnI+DQomZ3Q7ICZndDsgJmd0 OyBhdXRvbWF0aW9uIGRlcGxveW1lbnQsIGRvIHdlIGV4cGVjdCB0aGF0IHRoZSBjbGllbnQgYXBw bGljYXRpb24gY29kZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGNvbnRhaW5zIGxvZ2ljIHRvIHJld3Jp dGUgaXRzZWxmIHRvIHNlbmQgcHJvcGVyIHJlcXVlc3RzIHRoZSBuZXh0PGJyPg0KJmd0OyAmZ3Q7 ICZndDsmbmJzcDsgdGltZT8mbmJzcDsgJm5ic3A7SWYgaXQgaXMgZm9yIGRlYnVnZ2luZyBwdXJw b3NlcyBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIHVwIHRvPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJz cDsgaW1wbGVtZW50YXRpb25zIHRvIGZpZ3VyZSBvdXQuJm5ic3A7IFdlIHNob3VsZG4ndCBhZGQg c3VjaCB0aGluZ3MgdG88YnI+DQomZ3Q7ICZndDsgJmd0OyBzdGFuZGFyZCBSUENzLjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbHQ7ZXYmZ3Q7IHRoZXJlIGhhcyBiZWVuIGxvdHMgb2Yg ZGlzY3Vzc2lvbiBvbiB0aGlzIG9uZS4mbmJzcDsgVGhlIGJpZ2dlc3QgaXNzdWUgaGFzIGJlZW48 YnI+DQomZ3Q7IHRoYXQgdGhlcmUgYXJlIGVub3VnaCB2YXJpYXRpb25zIG9mIHBhcmFtZXRlcnMg d2hlcmUgdGhlIGd1aWRhbmNlIG9uIHdoYXQ8YnI+DQomZ3Q7IG1pZ2h0IGJlIGFjY2VwdGFibGUg aXMgdGhlIG9ubHkgd2F5IHRvIG1ha2Ugc29tZSBzY2VuYXJpb3Mgd29yay4mbmJzcDsgKFdhcyBp dCB0aGU8YnI+DQomZ3Q7IHBlcmlvZCB3aGljaCB3YXMgYSBwcm9ibGVtPyZuYnNwOyBXYXMgaXQg dGhlIGNvbXBsZXhpdHkgb2YgdGhlIGZpbHRlcj8pJm5ic3A7IE9idmlvdXNseTxicj4NCiZndDsg d2UgZG8gbmVlZCB0byBib3VuZCB3aGF0IGNvdWxkIGJlIHByb3ZpZGVkIGJhY2sgdG8gdGhlIHN1 YnNjcmliZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgU28gdGhlbiB0aGUgdGV4dCBzaG91bGQgZW5j b3VyYWdlIGltcGxlbWVudGF0aW9ucyB0byBwcm92aWRlIGdvb2QgZXJyb3I8YnI+DQomZ3Q7IG1l c3NhZ2VzLjxicj4NCjxicj4NCnllczxicj4NCjxicj4NCiZndDsgJmd0OyBUaGUgZ29vZCBuZXdz IGlzIHRoYXQgaWYgYSBwdWJsaXNoZXIgY2Fubm90IHN1cHBvcnQgbmVnb3RpYXRpb24sIGl0IGNh biBqdXN0PGJyPg0KJmd0OyBzZW5kIGJhY2sgYSBmYWlsdXJlLiZuYnNwOyBXaGljaCBpcyB3aHkg dGhlIHJlcXVpcmVtZW50IGlzIG9ubHkgYSBTSE9VTEQuPGJyPg0KJmd0Ozxicj4NCiZndDsgU0hP VUxEIGlzIHRvbyBzdHJvbmcuJm5ic3A7IEFuZCBldmVuIHNvLCB0aGlzIGp1c3QgYWRkcyBjb21w bGV4aXR5IHRvIHRoZTxicj4NCiZndDsgc3BlY2lmaWNhdGlvbi4mbmJzcDsgSSB0aGluayB0aGlz IHNob3VsZCBiZSByZW1vdmVkLjxicj4NCjxicj4NClJGQzc5MjMgaGFzIGl0IGFzIGEgTVVTVCAo c2VlIHNlY3Rpb24gNC4yLjIuKSZuYnNwOyBHb2luZyB0byBTSE9VTEQgaXMgYWxyZWFkeSBlYXNp bmcgb2ZmIHRoZSByZXF1aXJlbWVudC48YnI+DQo8YnI+DQomZ3Q7ICZndDsgQSB3b3JzZSBvdXRj b21lIHdvdWxkIGJlIGlmIGEgU3Vic2NyaWJlciBrZXB0IGd1ZXNzaW5nIGF0IGFjY2VwdGFibGU8 YnI+DQomZ3Q7IHBhcmFtZXRlcnMgYW5kIHBvdW5kaW5nIHRoZSBQdWJsaXNoZXIgd2l0aCBsb2Fk IG9uIHRoaXMuJm5ic3A7IFRoaXMgd291bGQgdGFrZTxicj4NCiZndDsgbW9yZSByZXNvdXJjZXMg dGhhbiBwcm92aWRpbmcgaGludHMuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhdCB3b3VsZCBhbHNv IGJlIHF1aXRlIHdlaXJkLiZuYnNwOyBCdXQgSSBjYW4ndCBpbWFnaW5lIGEgdXNlIGNhc2Ugd2hl cmUgYSBjbGllbnQ8YnI+DQomZ3Q7IG5lZWRzIGEgY2VydGFpbiBjb21iaW5hdGlvbiBvZiBwYXJh bWV0ZXJzLCB0aGUgc2VydmVyIHJlamNldHMgdGhlbSBidXQgc3VnZ2VzdDxicj4NCiZndDsgc29t ZSBvdGhlciBwYXJhbWV0ZXJzIHRoYXQgd2lsbCBnaXZlIHRoZSBzYW1lIHJlc3VsdCwgYW5kIHRo ZW4gdGhlIGNsaWVudDxicj4NCiZndDsgd291bGQgdXNlIHRoZW0/Jm5ic3A7IE9yIHdvcnNlLCB0 aGUgc2VydmVyIHN1Z2dlc3Qgc29tZXRoaW5nIHRoYXQgZ2l2ZXMgYW5vdGhlcjxicj4NCiZndDsg cmVzdWx0IGFuZCB0aGUgY2xpZW50IHNvbWVob3cgYWRqdXN0IHRvIHRoZW0/PGJyPg0KPGJyPg0K V2hlbiBhIHN1YnNjcmlwdGlvbiBpcyByZWplY3RlZCwgd2UgY2FuIHByb3ZpZGUgYSBoaW50IGF0 IHdoeS4mbmJzcDsgVGhpcyBpcyBhIG5ldyBkYW1wZW5pbmcgcGVyaW9kLCBhIHN1Z2dlc3Rpb24g dG8gdXNlIG9uLWNoYW5nZSwgZXRjLiZuYnNwOyBXaXRob3V0IHRoaXMgaGludCwgYSBzdWJzY3Jp YmVyIGNvdWxkIGp1c3Qga2VlcCBndWVzc2luZyBhdCBwYXJhbWV0ZXJzIHdpdGhvdXQgZ3VpZGFu Y2UuJm5ic3A7IFRoYXQgaXMgYWxsIG5lZ290aWF0aW9uIGlzLjxicj4NCjxicj4NCiZndDsgJmd0 OyAmZ3Q7byZuYnNwOyBTZWN0aW9uIDY8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7Jm5ic3A7IFRoZSB0ZXh0IHNheXM6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyZuYnNwOyAmbmJzcDtUaGUgZXZlbnQgbm90aWZpY2F0aW9ucyBtdXN0IGFsc28g aW5jbHVkZSB0aGUgc3Vic2NyaXB0aW9uLWlkIGlmIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5i c3A7ICZuYnNwO2VzdGFibGlzaC1zdWJzY3JpcHRpb24gd2FzIHVzZWQgaW4gaXRzIGVzdGFibGlz aG1lbnQsIG9yIGlmIGl0IHdhczxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO2NvbmZp Z3VyZWQgdmlhIGFuIG9wZXJhdGlvbmFsIGludGVyZmFjZS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7IEhvdyBpcyB0aGlzICZxdW90O3N1Y2JzY3JpcHRpb24t aWQmcXVvdDsgc3VwcG9zZWQgdG8gYmUgaW5jbHVkZWQ/Jm5ic3A7IFdoZXJlPzxicj4NCiZndDsg Jmd0OyAmZ3Q7Jm5ic3A7IFRoZXJlIGlzIG5vIHN1Y2ggZmllbGQgZGVmaW5lZCBpbiBhICZsdDtu b3RpZmljYXRpb24mZ3Q7Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbHQ7ZXYmZ3Q7 IFVubGlrZSB5YW5nLXB1c2gsIHRoZSBOb3RpZmljYXRpb24gZXZlbnRzIGFyZSBub3Qgc3BlY2lm aWVkIHZpYSB0aGU8YnI+DQomZ3Q7IGRvY3VtZW50LiZuYnNwOyAmbmJzcDtUaGUgZXhhbXBsZXMg Zm9sbG93aW5nIHRoZSByZXF1aXJlbWVudCBkbyBub3QgaW5jbHVkZSBhPGJyPg0KJmd0OyBzdWJz Y3JpcHRpb24taWQgd2hlbiB0aGV5IGFic29sdXRlbHkgc2hvdWxkLiZuYnNwOyAoQW5kIHRoaXMg cHJvdmVzIHRoZSBwb2ludCB0aGF0PGJyPg0KJmd0OyB0aGVzZSBhcmUgbmVlZGVkIDotKS4mbmJz cDsgJm5ic3A7V2Ugd2lsbCB1cGRhdGUgdGhlIGV4YW1wbGVzLjxicj4NCiZndDs8YnI+DQomZ3Q7 IFdlbGwsIGV4YW1wbGVzIGFyZSBnb29kLCBidXQgeW91IGFsc28gbmVlZCBhIG5vcm1hdGl2ZSBk ZWZpbml0aW9uLjxicj4NCjxicj4NCldpbGwgZG8uPGJyPg0KPGJyPg0KRXJpYzxicj4NCjxicj4N CiZndDsgL21hcnRpbjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IFRoYW5rcyBhZ2Fpbiw8YnI+DQomZ3Q7ICZndDsgRXJpYzxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4fab79c122c24e0ab2300d47d7f72b3eXCHRTP013ciscocom_-- From nobody Fri Dec 9 15:51:16 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F33129409 for ; Fri, 9 Dec 2016 15:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O4l1CABPLDj for ; Fri, 9 Dec 2016 15:51:11 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BC51279EB for ; Fri, 9 Dec 2016 15:51:11 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id x190so33513516qkb.0 for ; Fri, 09 Dec 2016 15:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/TBcSp4oPWBflorxYv5q4TVGsqIRpuTKzdbgfxTfdCw=; b=rPNhEcS1olzuOdrsw+F3jRejgyczyAAkwCgoW+I+e38LTDswzdr6OHDNFbw/UTXA/v RQUqZ5ISqvvMywy4ZWMUiH+31lHNJmX9wVsNV2XEKJTbtcyihSnq/IrJVGXEqmgGZZFr cxMs7RCkpWcTxGkJqZT2x0iatPkiemWb4hkexKGrHaj0aq1EUXldTJ5FFL+SlD+PBBft CfFOg8P0wjr3iP25j5RgWN1KaNqjv6dfwKXpO3xkdSZsq0Q0ZrMlsdf4wdNhQFncoUbN KewJiQORB8Uzp4ANJxRu3pkjrfWb2C1gs2Hhwh2ZfAVAIjTqkU98JOYgGrH6fAmP4ch2 XpKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/TBcSp4oPWBflorxYv5q4TVGsqIRpuTKzdbgfxTfdCw=; b=ZFr9RID5J1HjnaArbGtFURhHmsloIDXxwRlgnCjDD3yvl6eDj+cRDSgxizSpI5OBDB OvzLIpZ396DRhMWZZS4M14wLyMAHQ5Ns1GHQRJwzbHpDYfrM736w5iqQR8KKRcvh80SZ NqnNSJTeKJnKAEH4S5ig9rbtUAL0JrfFFhH1LQNo3HGSoNWmum6wesfNF0LgMPonv3s1 d2GuinMoGHPbljWUjXbmpXmsBehvX+5oYQwP7HX64zfsU5vLRmeUocO6INMbVUpixYZJ ldasRZWtc4QFEXCOgsqhDSpTDmIcltoBKGWFAWjv+Pbh/5obGDu0d+L2uzVeqZHw5qBO hj/g== X-Gm-Message-State: AKaTC01F5EHrgfVMM89PwIltOG+QwiZSz42i3QEd/b2CZJQt/Xq0xjUGWr1ifSyqYbwsjGsAMlp6PwPA2eEP2w== X-Received: by 10.55.21.81 with SMTP id f78mr78593676qkh.210.1481327470077; Fri, 09 Dec 2016 15:51:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Fri, 9 Dec 2016 15:51:09 -0800 (PST) In-Reply-To: <4fab79c122c24e0ab2300d47d7f72b3e@XCH-RTP-013.cisco.com> References: <4fab79c122c24e0ab2300d47d7f72b3e@XCH-RTP-013.cisco.com> From: Andy Bierman Date: Fri, 9 Dec 2016 15:51:09 -0800 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a114626eaa67a570543426d62 Archived-At: Cc: "netconf@ietf.org" , "alex@clemm.org" Subject: Re: [Netconf] Filter construction (was RE: review of "event-notification" documents) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 23:51:15 -0000 --001a114626eaa67a570543426d62 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 9, 2016 at 3:30 PM, Eric Voit (evoit) wrote: > Hi Andy, > > > > The is a lot interesting in your filter.yang file. If the WG desires to > go beyond the existing subtree filtering & xpath mechanisms, we should > determine if we can use this as a base. But if we go down this path it > will take some time to get this right. And if we do this, we should > structure all drafts so that filters can be extended over time without > needing to morph the subscriptions drafts. > > > > My initial take on this is that if we choose to pursue filter.yang, > landing filters.yang as a separate model/draft makes sense. Put simply, > filters need not be subscription specific. In fact, having predefined, > decoupled filters on device even for a normal GET can go a long way to > ensuring that any specific filter has been prequalified as not being > resource-prohibitive. > > > I would like to use this approach for and filtering, not just notifications. My concern with the choice-stmt approach is that filters will not really be shared or easy to write. With named filter parts that are combined in a a filter expression, the server can optimize the filter processing. Each filter part needs to be evaluated at most once per notification, no matter how many subscriptions are active at once. It is just a framework, very similar to the interfaces table. Using YANG identities to specify the filter type allows extensions without updating any other documents. There is a general problem with identities that also affects filter.yang. Just because a server advertises a YANG module with identities in it does not mean every identity is supported. A filter-capabilities table is needed. IMO there should be a common solution for identities. So how might we integrate subscriptions and filters.yang?: > > - for persistent filters that are independent of the subscription > lifecycle: the subscription=E2=80=99s filter-ref can point to a stand-alo= ne yang > filter model in an imported filter.yang > > - for filters which should only exist as part of the lifecycle of a > subscription: perhaps do a schema mount of filter.yang? The mounted schem= a > can be used to accept input from an RPC and store it as a transient in-li= ne > filter. I.e., this way the contents of the inline filters will not persi= st > longer than the subscription. (Is there a way to do this with > groupings/augmentations so that schema mount isn=E2=80=99t needed?) > > > > I suspect by approaching the integration in this way, it is possible to > evolve filter.yang without directly changing the subscription model. (Th= e > only thing would be that you have to rev is to a new model version.) > > > > Beyond this integration speculation, below are some thoughts on specific > elements of your =E2=80=9Cfilters.yang=E2=80=99 attachment: > > =C2=B7 Line 29: if-feature-stmt-str should be if-feature-stmt, corr= ect? > no -- that ABNF is for if-feature . I wanted just the part. > =C2=B7 Line 41: if-filter-factor should be filter-factor, correct? > probably -- will fix > =C2=B7 Line 56: mixed metaphor of a/b/c and 1/2/3. > ok -- will fix > =C2=B7 Line 20: we likely need an identity for a stream so that it = can > be used as a filter-term > agreed > =C2=B7 The set of operators is =E2=80=98and=E2=80=99, =E2=80=98or= =E2=80=99. There is also factoring > with =E2=80=98(=E2=80=98 and =E2=80=98)=E2=80=99. But the majority of xp= ath operators and syntax is not > included. Which is a good thing. As filters are not necessarily boolean > it might be interesting to figure out what other elements might be needed= . > This will take some time to do right. > I think the if-feature syntax is good enough. Restricted XPath is too much= . I wanted to avoid types and type conversion and floating point, etc. (filter-1 and filter-2 and not filter-3) These are very easy strings to construct by hand or by program. The general template of the filter needs a bit of work, such as defining the requirements for a filter definition: - which contexts the filter can be used - document root - context node - evaluation procedures It is up to each filter definition to describe how the "true or false" return value is derived. That is all that matters to the filter engine. Andy > =C2=B7 I am not catching all the subtlties here. Could you review = this > on the next Dezign team call? > > =C2=B7 We probably discuss whether we want to limit the allowable a= mount > of nesting within the filtering syntax. RFC 5277 didn=E2=80=99t do such = limiting. > And without knowing the a desired filter criteria which can be applied > against random collections of objects, I suggest we don=E2=80=99t attempt= this > either. Perhaps someone in the future can define a minimal set of nestin= g > which must be supported if someone desires for the filters themselves to = be > portable across implementations. > > =C2=B7 For the identity netconf-stream, you refer to RFC5277 sec 3.= 2. > If this is being obsoleted, do we need another definition source? (As the > =E2=80=98obsolete=E2=80=99 discussion happened after you wrote the filter= .yang, perhaps > this can just be removed if we go to =E2=80=98obsolete=E2=80=99?) > > > > Anyway there is the starter thinking I promised. Let=E2=80=99s chat more= if you > are willing to review this on the Wed call. > > > > Eric > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, December 1, 2016 1:41 PM > *To:* Eric Voit (evoit) > *Cc:* Balazs Lengyel ( > balazs.lengyel@ericsson.com) ; alex@clemm.or= g; > Martin Bjorklund ; Alberto Gonzalez Prieto (albertgo) < > albertgo@cisco.com>; netconf@ietf.org > *Subject:* Re: [Netconf] review of "event-notification" documents > > > > Hi, > > > > I worked on the filtering problem a bit more. > > Here is filter.yang, a filtering framework, and topic.yang, and example o= f > a filter type > > that can be used in filter.yang. Topic-based filtering was briefly > discussed in Seoul. > > > > IMO filters will continue to evolve over time so the solution needs to > allow > > them to be added and combined with other filters. The current YANG > choice-stmt > > is not extensible enough or powerful enough. > > > > > > Andy > > > > > > On Tue, Nov 29, 2016 at 7:11 PM, Eric Voit (evoit) > wrote: > > *From:* Andy Bierman, November 29, 2016 8:30 PM > > On Tue, Nov 29, 2016 at 8:05 AM, Eric Voit (evoit) > wrote: > > Thanks Martin, > > More in line. Also I extracted areas where we already agree to make thi= s > easier to follow. > > > From: Martin Bjorklund, November 29, 2016 6:40 AM > > > >If I understand the intention correctly, this document is supposed t= o > > > >*define* how notifications are sent over NETCONF. But there is no > > > >such definition in this document. Instead it simply repeats > > > >information already defined in draft-ietf-netconf-rfc5277bis-01.txt, > > > >and provides lots of examples of how the YANG operations defined in > > > >rfc5277bis are encoded in XML and sent over NETCONF. > > > > > > > >I suggest that this document is rewritten. Since the idea is to > > > >replace RFC 5277, it needs to focus on how notifications are sent > > > >over NETCONF, and not how RPCs are encoded in XML. > > > I agree -- maybe get rid of it and just have rfc5277bis contain this > > > text > > > > > > 5277bis is supposed to allow transports other than NETCONF. If > we put > > the NETCONF specific stuff in here we lose that separation. > > > > We need *some* document that defines how notifications are sent over > > NETCONF. This document needs to have the specification for the > > > element. > > > > Then we need a protocol-independent document that defines the concept o= f > > streams and subscriptions, stream discovery, etc. > > > > I *think* that your intention is that new clients really should be usin= g > > instead of , since it is > protocol- > > independent and support modification and deletion. > > > > If we also want to be fully backwards compatible with 5277, I think we > should > > create a document that is much closer to the current 5277 - essentially > just > > creating a YANG model for the config false data and for the "old" > > subscription>. > > We absolutely want to have a full backwards compatible capability. The > question is how to best frame this in documents. It is possible to rebui= ld > RFC-5277 with a YANG model. But then you can't just layer on new > capabilities driving this work. (And this is why we need separate > namespaces.) > > > > > > We need to parse and understand "full backwards compatible". > > > > Do we want existing implementations to be leveraged into the new > solution? Yes > > A server should be capable of supporting for > > old, deprecated subscriptions, and for the new > current subscriptions. > > > > Do we need to update RFC 5277 or replace it? IMO, replace it. > > Since the RPC was never in a YANG module, > > it can be left out of the new module. > > > > I believe at minimum that should be pulled out > of the new module. It needs its separate namespace. Perhaps nobody is > ready to advocate for a parallel 5277-legacy YANG model since new > development should go to the new paradigm anyway. In this case, we could > just have a standalone legacy 5277 section in the document for anything > needed. This would make things simpler and easier to tease apart. > > > > Even more radical, I think streams should be removed, even the NETCONF > stream. > > They really serve no purpose now that subscriptions are formalized and ca= n > > even be configured. It is also bad design to couple the output message > encoding > > into the input stream. (e.g., NETCONF stream MUST be XML encoded). > > > > Even as we move away from streams, I still can see reasons for it. > (Adding Balazs & Alex as they have been proponents.) The biggest reason > for streams is that a robust customer designed filters are hard. If a > vendor/customer/etc. is able to pre-filter notifications or datastore in = an > interesting and useful way not supportable by our filtering semantics, th= is > is a good way to allow the pre-filtering. Some examples which could be > interesting: > > =C2=B7 Event notifications when new devices connect to a network > > =C2=B7 Alarms potentially set across multiple YANG models > > > > Currently, filters are defined as a choice-stmt. > > This implied OR-expr is too simplistic. An explicit combination of OR, > AND, and NOT is required > > for different types of filters. (similar to YANG 1.1 if-feature-stmt > syntax). > > > > Totally agree that we need robust filters. Figuring this problem > space out is a full time job. Figuring out how to encoding filtering > capabilities supported on different types of constrained platforms is > non-trivial. I would love to see someone take this on for the industry. > Any takers? > > > > Eric > > > > Andy > > > > > > As layering upon RFC-5277 cannot give the new capabilities being requeste= d > of us in places like RFC-7923 (e.g., multiple subscriptions/session), we > are moving now to put all elements just needed for backwards compatibilit= y > in the netconf transport draft. We could also separate all this out into > another independent backwards compatibility extension. But we felt we ha= d > enough drafts in progress where we didn't want/need a fifth one. > > > > [AG] FWIW, the scope of each doc is summarized on > > > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf > > > (slide > > > #5) > > > [AG] The key is that the spec for NC comes from the union of 5277-bis > > > and the NC transport doc > > > (draft-ietf-netconf-netconf-event-notifications-01.txt) The NC > > > transport doc is not meant to stand alone. > > > The doc contains how 5277-bis concepts are realized when using NC and > > > NC-specific aspects. E.g.: > > > - the use of NC call-home for configured subscriptions > > > - backwards compatibility > > > - the existence of a NETCONF stream > > > - support of /netconf/streams > > > Yes, any 5277bis topic specific to only NETCONF transport should > > > be in netconf-event-notifications > > > > > > I agree with Martin that duplicating normative text is bad. > > > Not having any normative text is even worse. > > > > > > +1. To help address that, I just built a whole list of pending > changes > > across the four drafts. And in quite a few places I pulled out > duplicative text. > > > > > > - the definition of create-subscription may be moved to this doc so > > > that other transports would ignore create-subscription and use only > > > establish-subscription, simplifying the solution > > > > > > > > > That seems wrong since 5277 had create-subscription so it should stay > > > in 5277bis > > > > > > It is really a style thing so it doesn=E2=80=99t matter that muc= h either > way. > > Current thinking is that as we need both the new and old namespaces. > > Therefore it seems simpler to have anything in the old namespace > (=E2=80=9Ccreate- > > subscription=E2=80=9D) in netconf-event-notification draft. > > > > I agree with Andy that anything that comes from 5277 that you need to > keep > > for backwards compatibility reasons should go into 5277bis. > > Right now it is in 5277bis. But we already can't have everything needed > for backwards compatibility since the 5277bis is transport (NETCONF) > independent. So it seemed logical to put it NETCONF transport draft. > (Again we were trying to limit the proliferation of drafts.) > > In the end, I am ok as long as it lands somewhere. So if people prefer, > we could also have this as a completely separate backwards compatibility > section + YANG model in 5277bis. > > > > - how to issue notifications in JSON are sent using NC (this is also > > > in 5277-bis). Arguably, it belongs in the NC transport doc > > > > > > > > > > > > This is poorly defined. > > > NETCONF does not support JSON encoding and IMO should not define JSON > > > encoding unless the entire protocol supports it cleanly. > > > The proposal seems to be to use XML for and , but > > > allow some special mode where is sent in JSON. > > > > > > > > > > >o Section 2.1 > > > > > > > > The text says: > > > > > > > > The NETCONF event stream contains all > > > > NETCONF XML event notifications supported by the publisher, > > > > > > > > First of all, since this document is protocol-agnostic, should it > > > > really define the stream "NETCONF"? > > > > > > Agree, which is why this is going to netconf-event-notification. > > > > > > > Secondly, this would be a new requirement. There is nothing in RF= C > > > > 5277 that says that a notification is sent on "NETCONF" be default= . > > > > > > 5277 section 3.2.3 talks about the default event stream which ha= s > > > all NETCONF event notifications > > > > You're right. The question is then what is an "NETCONF XML event > > notification"? I think the intention was that these would be > "notifications > > related to NETCONF", rather than "all YANG-defined notifications". Thi= s > needs > > some disucssion. > > Agree > > > > > I think this text should be removed. How notifications are mapped > > > > to streams is should be out of scope for this document. > > > > > > Yes, streams as a whole were something we deferred for a while. > Latest > > thinking is we minimize streams to the degree possible. Look for legac= y > stuff to > > be in netconf-event-notification. > > > > Do you mean that you plan to update the text around streams? If so, > that's > > fine. > > Yes > > > > > In list "filter", change "filter-id" to "id". > > > > > > > > In list "subscription", change "subscription-id" to "id". > > > > > > Model purity-wise you are correct. With both subscription id an= d > filter > > id, several people expressed they wanted the objects to be immediately > and > > obviously differentiable. Hopefully others will chime in here. > > > > I think we should try to keep the same style across IETF documents. > > Most models do not use redundant qualifiers, especially not for generic > names > > like 'id' or 'name' when used as a key. > > I am happy with whatever convention the WG chooses. > > > > > In list "subscription", change "startTime" to "start-time" and > > > > "stopTime" to "stop-time", for consistency. > > > > > > we kept the old names for backwards equivalency to 5277. > > > > But there is nothing to be backwards compatible with in this case. > > The input paramters to the existing cannot be > changed, > > but new nodes should be kept consistent. > > Ok. So you want start-time in the YANG model, and startTime in the RPC. > That can be done. > > > > > In list "subscription", change choice "push-source" to a better > > > > name, maybe "egress-interface" (this is how it is described). > > > > > > push-source can also be an IP Address. Another name possibility > for this > > might be =E2=80=9COriginates-from=E2=80=9D, that is the basic idea. > > > > The current draft has: > > > > choice push-source { > > description > > "Identifies the egress interface on the Publisher from > > which notifications will or are being sent."; > > > > You probably need to adjust this, and make it clear what the ip-address > case > > really means. > > agree > > > > > In list "receiver", what is a "multipoint address"? > > > > > > we are trying not to limit receivers to hosts. Perhaps multicast > address is > > ok. Really we would be good with type: inet:host. > > > > The type is inet:host already. > > > > You should probably clarify the descriptions. > > agree > > > > > Remove the leaf "source-vrf"; this should eventually be aligned > > > > with draft-ietf-rtgwg-ni-model. > > > > > > Perhaps a place for schema-mount? > > > > Not really, rather an augment. > > Happy to go with whatever convention people want to use. > > > > We should leave source-vrf in > > > place until we have the proper definition. > > > > No I say remove it until you have a proper definition. If you keep it > you need to > > have a proper definition of what it is, and it needs to be interoperabl= e > across > > implementations. > > We will address with the proper convention in the next draft > > > > But we could update the text showing there is a pending decision. > > > > > > > You have made the stream name an identity. In RFC 5277 it was a > > > > string. By using an identity, you severly limit how it can be used= ; > > > > with a string new streams can be dynamically created at run-time, > > > > but with an identity stream names must be known at design-time. > > > > I think the stream name should be changed back to a string. > > > > > > as the majority of the people in the informal design team were > against > > the expansion of streams, this is likely a moot point. > > > > I don't know what "expansion of streams" means, and I don't understand > what > > "this" refers to in "this is likely a moot point". > > > > But if we keep the stream name as an identity we're no longer backwards > > compatible with RFC 5277, and we severly limit the functionality. I > strongly > > object to such a change. > > I am fine with string, especially as: > (a) we are moving away from strings in favor of filters > (b) custom streams are likely to be the dominant use. > Anyone have an objection to this change? > > > > >o Section 4.1 > > > > > > > > The text says: > > > > > > > > If the > > > > request is rejected because the publisher is not able to serve it= , > > > > the publisher SHOULD include in the returned error what > subscription > > > > parameters would have been accepted for the request when it was > > > > processed. > > > > > > > > I think this is a pretty weird idea. It seems extremely difficult > > > > to implement, and the use case is not clear at all. In an > > > > automation deployment, do we expect that the client application cod= e > > > > contains logic to rewrite itself to send proper requests the next > > > > time? If it is for debugging purposes I think this should be up = to > > > > implementations to figure out. We shouldn't add such things to > > > > standard RPCs. > > > > > > there has been lots of discussion on this one. The biggest issu= e > has been > > that there are enough variations of parameters where the guidance on wh= at > > might be acceptable is the only way to make some scenarios work. (Was > it the > > period which was a problem? Was it the complexity of the filter?) > Obviously > > we do need to bound what could be provided back to the subscriber. > > > > So then the text should encourage implementations to provide good error > > messages. > > yes > > > > The good news is that if a publisher cannot support negotiation, it > can just > > send back a failure. Which is why the requirement is only a SHOULD. > > > > SHOULD is too strong. And even so, this just adds complexity to the > > specification. I think this should be removed. > > RFC7923 has it as a MUST (see section 4.2.2.) Going to SHOULD is already > easing off the requirement. > > > > A worse outcome would be if a Subscriber kept guessing at acceptable > > parameters and pounding the Publisher with load on this. This would ta= ke > > more resources than providing hints. > > > > That would also be quite weird. But I can't imagine a use case where a > client > > needs a certain combination of parameters, the server rejcets them but > suggest > > some other parameters that will give the same result, and then the clie= nt > > would use them? Or worse, the server suggest something that gives > another > > result and the client somehow adjust to them? > > When a subscription is rejected, we can provide a hint at why. This is a > new dampening period, a suggestion to use on-change, etc. Without this > hint, a subscriber could just keep guessing at parameters without > guidance. That is all negotiation is. > > > > >o Section 6 > > > > > > > > The text says: > > > > > > > > The event notifications must also include the subscription-id if > the > > > > establish-subscription was used in its establishment, or if it wa= s > > > > configured via an operational interface. > > > > > > > > How is this "sucbscription-id" supposed to be included? Where? > > > > There is no such field defined in a . > > > > > > Unlike yang-push, the Notification events are not specified via > the > > document. The examples following the requirement do not include a > > subscription-id when they absolutely should. (And this proves the poin= t > that > > these are needed :-). We will update the examples. > > > > Well, examples are good, but you also need a normative definition. > > Will do. > > Eric > > > /martin > > > > > > > > > > Thanks again, > > > Eric > > > > > --001a114626eaa67a570543426d62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 9, 2016 at 3:30 PM, Eric Voit (evoit) <= ;evoit@cisco.com&g= t; wrote:

Hi Andy,

=C2=A0

The is a lot interesting in your filt= er.yang file.=C2=A0 If the WG desires to go beyond the existing subtree fil= tering & xpath mechanisms, we should determine if we can use this as a base.=C2=A0 But if we go down this path it will take som= e time to get this right.=C2=A0 And if we do this, we should structure all = drafts so that filters can be extended over time without needing to morph t= he subscriptions drafts.

=C2=A0

My initial take on this is that if we= choose to pursue filter.yang, landing filters.yang as a separate model/dra= ft makes sense.=C2=A0 Put simply, filters need not be subscription specific.=C2=A0 =C2=A0In fact, having predefined, decouple= d filters on device even for a normal GET can go a long way to ensuring tha= t any specific filter has been prequalified as not being resource-prohibiti= ve.

=C2=A0

<= /blockquote>

I would like to use this approach for <g= et-config> and <get> filtering, not just notifications.
=
My concern with the choice-stmt approach is that filters wil= l not really be shared or easy to write.
With named filter parts = that are combined in a a filter expression, the server can
optimi= ze the filter processing.=C2=A0 Each filter part needs to be evaluated at m= ost once per notification,
no matter how many subscriptions are a= ctive at once.

It is just a framework, very simila= r to the interfaces table.
Using YANG identities to specify the f= ilter type allows extensions
without updating any other documents= .

There is a general problem with identities that = also affects filter.yang.
Just because a server advertises a YANG= module with identities in it does not
mean every identity is sup= ported.=C2=A0 A filter-capabilities table is needed.
IMO there sh= ould be a common solution for identities.


=

So how might we integrate subscriptio= ns and filters.yang?:

- for persistent filters that are ind= ependent of the subscription lifecycle: the subscription=E2=80=99s filter-r= ef can point to a stand-alone yang filter model in an imported filter.yang

- for filters which should only exist= as part of the lifecycle of a subscription: perhaps do a schema mount of f= ilter.yang? The mounted schema can be used to accept input from an RPC and store it as a transient in-line filter.=C2=A0= I.e., this way the contents of the inline filters will not persist longer = than the subscription.=C2=A0 (Is there a way to do this with groupings/augm= entations so that schema mount isn=E2=80=99t needed?)<= /p>

=C2=A0

I suspect by approaching the integrat= ion in this way, it is possible to evolve filter.yang without directly chan= ging the subscription model.=C2=A0 (The only thing would be that you have to rev is to a new model version.)

=C2=A0

Beyond this integration speculation, = below are some thoughts on specific elements of your =E2=80=9Cfilters.yang= =E2=80=99 attachment:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Line 29: if-feature-stmt-str sho= uld be if-feature-stmt, correct?

no -- that ABNF is for if-feature <expr>.=C2=A0 I wanted= just the <expr> part.
=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Line 41: if-filter-factor should= be filter-factor, correct?


probably -- will fix


=C2=A0=

<= /p>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Line 56: mixed metaphor of a/b/c= and 1/2/3.


ok -- wi= ll fix
=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Line 20: we likely need an ident= ity for a stream so that it can be used as a filter-term


agreed
=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The set of operators is =E2=80= =98and=E2=80=99, =E2=80=98or=E2=80=99.=C2=A0 There is also factoring with = =E2=80=98(=E2=80=98 and =E2=80=98)=E2=80=99.=C2=A0 But the majority of xpat= h operators and syntax is not included.=C2=A0 Which is a good thing.=C2=A0 As filters are not necessarily boolean it might be = interesting to figure out what other elements might be needed.=C2=A0 This w= ill take some time to do right.

I think the if-feature syntax is good enough.=C2=A0 Restricted = XPath is too much.
I wanted to avoid types and type conversion an= d floating point, etc.

=C2=A0 (filter-1 and filter= -2 and not filter-3)

These are very easy strings t= o construct by hand or by program.
The general template of the fi= lter needs a bit of work, such as
defining the requirements for a= filter definition:

=C2=A0 - which contexts the fi= lter can be used
=C2=A0 - document root
=C2=A0 - contex= t node
=C2=A0 - evaluation procedures

It= is up to each filter definition to describe how the "true or false&qu= ot; return value
is derived.=C2=A0 That is all that matters to th= e filter engine.


Andy

=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 I am not catching all the subtlt= ies here.=C2=A0 Could you review this on the next Dezign team call?=C2=A0= =C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 We probably discuss whether we w= ant to limit the allowable amount of nesting within the filtering syntax.= =C2=A0 RFC 5277 didn=E2=80=99t do such limiting.=C2=A0 And without knowing the a desired filter criteria which can be applied against random = collections of objects, I suggest we don=E2=80=99t attempt this either.=C2= =A0 Perhaps someone in the future can define a minimal set of nesting which= must be supported if someone desires for the filters themselves to be portable across implementations.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 For the identity netconf-stream,= you refer to RFC5277 sec 3.2.=C2=A0 If this is being obsoleted, do we need= another definition source? (As the =E2=80=98obsolete=E2=80=99 discussion happened after you wrote the filter.yang, perhaps this can just= be removed if we go to =E2=80=98obsolete=E2=80=99?)

=C2=A0

Anyway there is the starter thinking = I promised.=C2=A0 Let=E2=80=99s chat more if you are willing to review this= on the Wed call.

=C2=A0

Eric

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, December 1, 2016 1:41 PM
To: Eric Voit (evoit) <evoit@cisco.com>
Cc: Balazs Lengyel <balazs.lengyel@ericsson.com> (balazs.lengyel@ericsson.com<= /a>) <b= alazs.lengyel@ericsson.com>; alex@clemm.org; Martin Bjorklund <mbj@tail-f.com>; Alberto Gonzalez Pri= eto (albertgo) <= albertgo@cisco.com>; netconf@ietf.org
Subject: Re: [Netconf] review of "event-notification" docu= ments

=C2=A0

Hi,

=C2=A0

I worked on the filtering problem a bit more.=

Here is filter.yang, a filtering framework, and topi= c.yang, and example of a filter type

that can be used in filter.yang. Topic-based filteri= ng was briefly discussed in Seoul.

=C2=A0

IMO filters will continue to evolve over time so the= solution needs to allow

them to be added and combined with other filters.=C2= =A0 The current YANG choice-stmt

is not extensible enough or powerful enough.<= u>

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

On Tue, Nov 29, 2016 at 7:11 PM, Eric Voit (evoit) &= lt;evoit@cisco.com= > wrote:

From:<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= Andy Bierman, November 29, 2016 8:30 PM

On Tue, Nov 29, 2016 at 8:05 AM, Eric Voit (evoit) &= lt;evoit@cisco.com= > wrote:

Thanks Martin,

More in line.=C2=A0 =C2=A0Also I extracted areas where we already agree to = make this easier to follow.

> From: Martin Bjorklund, November 29, 2016 6:40 AM
> > >If I understand the intention correctly, this document is sup= posed to
> > >*define* how notifications are sent over NETCONF.=C2=A0 But t= here is no
> > >such definition in this document.=C2=A0 Instead it simply rep= eats
> > >information already defined in draft-ietf-netconf-rfc5277bis-= 01.txt,
> > >and provides lots of examples of how the YANG operations defi= ned in
> > >rfc5277bis are encoded in XML and sent over NETCONF.
> > >
> > >I suggest that this document is rewritten.=C2=A0 Since the id= ea is to
> > >replace RFC 5277, it needs to focus on how notifications are = sent
> > >over NETCONF, and not how RPCs are encoded in XML.
> > I agree -- maybe get rid of it and just have rfc5277bis contain t= his
> > text
> >
> > <ev> 5277bis is supposed to allow transports other than NET= CONF.=C2=A0 If we put
> the NETCONF specific stuff in here we lose that separation.
>
> We need *some* document that defines how notifications are sent over > NETCONF.=C2=A0 This document needs to have the specification for the &= lt;notification>
> element.
>
> Then we need a protocol-independent document that defines the concept = of
> streams and subscriptions, stream discovery, etc.
>
> I *think* that your intention is that new clients really should be usi= ng
> <establish-subscription> instead of <create-subscription>,= since it is protocol-
> independent and support modification and deletion.
>
> If we also want to be fully backwards compatible with 5277, I think we= should
> create a document that is much closer to the current 5277 - essentiall= y just
> creating a YANG model for the config false data and for the "old&= quot; <create-
> subscription>.

We absolutely want to have a full backwards compatible capability.=C2=A0 Th= e question is how to best frame this in documents.=C2=A0 It is possible to = rebuild RFC-5277 with a YANG model.=C2=A0 But then you can't just layer= on new capabilities driving this work.=C2=A0 (And this is why we need separate namespaces.)

=C2=A0

=C2=A0

We need to parse and understand "full backwards= compatible".

=C2=A0

Do we want existing implementations to be leveraged = into the new solution?=C2=A0 Yes

A server should be capable of supporting <create-= subscription> for

old, deprecated subscriptions, and <establish-sub= scription> for the new current subscriptions.

=C2=A0

Do we need to update RFC 5277 or replace it? IMO, re= place it.

Since the <create-subscription> RPC was never = in a YANG module,

it can be left out of the new module.=C2=A0

=C2=A0

<ev> I believe at minimum that = <create subscription> should be pulled out of the new module.=C2=A0 I= t needs its separate namespace.=C2=A0 =C2=A0Perhaps nobody is ready to advocate fo= r a parallel 5277-legacy YANG model since new development should go to the = new paradigm anyway.=C2=A0 In this case, we could just have a standalone le= gacy 5277 section in the document for anything needed.=C2=A0 This would make things simpler and easier to tease apart.

=C2=A0

Even more radical, I think streams should be removed= , even the NETCONF stream.

They really serve no purpose now that subscriptions = are formalized and can

even be configured.=C2=A0 It is also bad design to c= ouple the output message encoding

into the input stream. (e.g., NETCONF stream MUST be= XML encoded).

=C2=A0

<ev> Even as we move away from = streams, I still can see reasons for it.=C2=A0 (Adding Balazs & Alex as= they have been proponents.)=C2=A0 The biggest reason for streams is that a robu= st customer designed filters are hard.=C2=A0 If a vendor/customer/etc. is a= ble to pre-filter notifications or datastore in an interesting and useful w= ay not supportable by our filtering semantics, this is a good way to allow the pre-filtering. Some examples which could b= e interesting:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Event notifications when new devices connect to a net= work

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Alarms potentially set across multiple YANG models

=C2=A0

Currently, filters are defined as a choice-stmt.<= /u>

This implied OR-expr is too simplistic. An explicit = combination of OR, AND, and NOT is required

for different types of filters. =C2=A0(similar to YA= NG 1.1 if-feature-stmt syntax).

=C2=A0

<ev> Totally agree that we need= robust filters.=C2=A0 Figuring this problem space out is a full time job.= =C2=A0 Figuring out how to encoding filtering capabilities supported on different= types of constrained platforms is non-trivial.=C2=A0 I would love to see s= omeone take this on for the industry.=C2=A0 Any takers?

=C2=A0

Eric

=C2=A0

Andy

=C2=A0

=C2=A0

As layering upon RFC-5277 cannot give the new capabi= lities being requested of us in places like RFC-7923 (e.g., multiple subscr= iptions/session), we are moving now to put all elements just needed for backwards compatibility in the netconf transport draft.=C2= =A0 We could also separate all this out into another independent backwards = compatibility extension.=C2=A0 But we felt we had enough drafts in progress= where we didn't want/need a fifth one.

> > [AG] FWIW, the scope of each doc is summarized on
> > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pd= f
> > (slide
> > #5)
> > [AG] The key is that the spec for NC comes from the union of 5277= -bis
> > and the NC transport doc
> > (draft-ietf-netconf-netconf-event-notifications-01.txt) The = NC
> > transport doc is not meant to stand alone.
> > The doc contains how 5277-bis concepts are realized when using NC= and
> > NC-specific aspects. E.g.:
> > - the use of NC call-home for configured subscriptions
> > - backwards compatibility
> >=C2=A0 =C2=A0 - the existence of a NETCONF stream
> >=C2=A0 =C2=A0 - support of /netconf/streams
> > <ev> Yes, any 5277bis topic specific to only NETCONF transp= ort should
> > be in netconf-event-notifications
> >
> > I agree with Martin that duplicating normative text is bad.
> > Not having any normative text is even worse.
> >
> > <ev> +1.=C2=A0 To help address that, I just built a whole l= ist of pending changes
> across the four drafts.=C2=A0 And in quite a few places I pulled out d= uplicative text.
> >
> > - the definition of create-subscription may be moved to this doc = so
> > that other transports would ignore create-subscription and use on= ly
> > establish-subscription, simplifying the solution
> >
> >
> > That seems wrong since 5277 had create-subscription so it should = stay
> > in 5277bis
> >
> > <ev> It is really a style thing so it doesn=E2=80=99t matte= r that much either way.
> Current thinking is that as we need both the new and old namespaces. > Therefore it seems simpler to have anything in the old namespace (=E2= =80=9Ccreate-
> subscription=E2=80=9D) in netconf-event-notification draft.
>
> I agree with Andy that anything that comes from 5277 that you need to = keep
> for backwards compatibility reasons should go into 5277bis.

Right now it is in 5277bis.=C2=A0 But we already can't have everything = needed for backwards compatibility since the 5277bis is transport (NETCONF)= independent.=C2=A0 So it seemed logical to put it NETCONF transport draft.= =C2=A0 (Again we were trying to limit the proliferation of drafts.)

In the end, I am ok as long as it lands somewhere.=C2=A0 So if people prefe= r, we could also have this as a completely separate backwards compatibility= section + YANG model in 5277bis.

> > - how to issue notifications in JSON are sent using NC (this is a= lso
> > in 5277-bis). Arguably, it belongs in the NC transport doc
> >
> >
> >
> > This is poorly defined.
> > NETCONF does not support JSON encoding and IMO should not define = JSON
> > encoding unless the entire protocol supports it cleanly.
> > The proposal seems to be to use XML for <rpc> and <rpc-r= eply>, but
> > allow some special mode where <notification> is sent in JSO= N.
> >
> > >
> > >o=C2=A0 Section 2.1
> > >
> > >=C2=A0 The text says:
> > >
> > >=C2=A0 =C2=A0The NETCONF event stream contains all
> > >=C2=A0 =C2=A0NETCONF XML event notifications supported by the= publisher,
> > >
> > >=C2=A0 First of all, since this document is protocol-agnostic= , should it
> > > really define the stream "NETCONF"?
> >
> > <ev> Agree, which is why this is going to netconf-event-not= ification.
> >
> > >=C2=A0 Secondly, this would be a new requirement.=C2=A0 There= is nothing in RFC
> > >=C2=A0 5277 that says that a notification is sent on "NE= TCONF" be default.
> >
> > <ev> 5277 section 3.2.3 talks about the default event strea= m which has
> > all NETCONF event notifications
>
> You're right.=C2=A0 The question is then what is an "NETCONF = XML event
> notification"?=C2=A0 I think the intention was that these would b= e "notifications
> related to NETCONF", rather than "all YANG-defined notificat= ions".=C2=A0 This needs
> some disucssion.

Agree

> > >=C2=A0 I think this text should be removed.=C2=A0 How notific= ations are mapped
> > > to streams is should be out of scope for this document.
> >
> > <ev> Yes, streams as a whole were something we deferred for= a while.=C2=A0 Latest
> thinking is we minimize streams to the degree possible.=C2=A0 Look for= legacy stuff to
> be in netconf-event-notification.
>
> Do you mean that you plan to update the text around streams?=C2=A0 If = so, that's
> fine.

Yes

> > >=C2=A0 In list "filter", change "filter-id&quo= t; to "id".
> > >
> > >=C2=A0 In list "subscription", change "subscri= ption-id" to "id".
> >
> > <ev> Model purity-wise you are correct.=C2=A0 With both sub= scription id and filter
> id, several people expressed they wanted the objects to be immediately= and
> obviously differentiable.=C2=A0 =C2=A0Hopefully others will chime in h= ere.
>
> I think we should try to keep the same style across IETF documents. > Most models do not use redundant qualifiers, especially not for generi= c names
> like 'id' or 'name' when used as a key.

I am happy with whatever convention the WG chooses.

> > >=C2=A0 In list "subscription", change "startTi= me" to "start-time" and
> > > "stopTime" to "stop-time", for consisten= cy.
> >
> > <ev> we kept the old names for backwards equivalency to 527= 7.
>
> But there is nothing to be backwards compatible with in this case.
> The input paramters to the existing <create-subscription> cannot= be changed,
> but new nodes should be kept consistent.

Ok.=C2=A0 So you want start-time in the YANG model, and startTime in the RP= C.=C2=A0 That can be done.

> > >=C2=A0 In list "subscription", change choice "= push-source" to a better
> > > name, maybe "egress-interface" (this is how it is = described).
> >
> > <ev> push-source can also be an IP Address.=C2=A0 Another n= ame possibility for this
> might be =E2=80=9COriginates-from=E2=80=9D, that is the basic idea. >
> The current draft has:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 choice push-source {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Identifies the egress i= nterface on the Publisher from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which notifications wil= l or are being sent.";
>
> You probably need to adjust this, and make it clear what the ip-addres= s case
> really means.

agree

> > >=C2=A0 In list "receiver", what is a "multipoi= nt address"?
> >
> > <ev> we are trying not to limit receivers to hosts. Perhaps= multicast address is
> ok.=C2=A0 Really we would be good with type: inet:host.
>
> The type is inet:host already.
>
> You should probably clarify the descriptions.

agree

> > >=C2=A0 Remove the leaf "source-vrf"; this should ev= entually be aligned
> > > with=C2=A0 draft-ietf-rtgwg-ni-model.
> >
> > Perhaps a place for schema-mount?
>
> Not really, rather an augment.

Happy to go with whatever convention people want to use.

> > We should leave source-vrf in
> > place until we have the proper definition.
>
> No I say remove it until you have a proper definition.=C2=A0 If you ke= ep it you need to
> have a proper definition of what it is, and it needs to be interoperab= le across
> implementations.

We will address with the proper convention in the next draft

> > But we could update the text showing there is a pending decision.=
> >
> > >=C2=A0 You have made the stream name an identity.=C2=A0 In RF= C 5277 it was a
> > > string.=C2=A0 By using an identity, you severly limit how it= can be used;
> > > with a string new streams can be dynamically created at run-= time,
> > > but with an identity stream names must be known at design-ti= me.
> > >=C2=A0 I think the stream name should be changed back to a st= ring.
> >
> > <ev> as the majority of the people in the informal design t= eam were against
> the expansion of streams, this is likely a moot point.
>
> I don't know what "expansion of streams" means, and I do= n't understand what
> "this" refers to in "this is likely a moot point".=
>
> But if we keep the stream name as an identity we're no longer back= wards
> compatible with RFC 5277, and we severly limit the functionality.=C2= =A0 I strongly
> object to such a change.

I am fine with string, especially as:
(a) we are moving away from strings in favor of filters
(b) custom streams are likely to be the dominant use.
Anyone have an objection=C2=A0 to this change?

> > >o=C2=A0 Section 4.1
> > >
> > >=C2=A0 The text says:
> > >
> > >=C2=A0 =C2=A0If the
> > >=C2=A0 =C2=A0request is rejected because the publisher is not= able to serve it,
> > >=C2=A0 =C2=A0the publisher SHOULD include in the returned err= or what subscription
> > >=C2=A0 =C2=A0parameters would have been accepted for the requ= est when it was
> > >=C2=A0 =C2=A0processed.
> > >
> > >=C2=A0 I think this is a pretty weird idea.=C2=A0 It seems ex= tremely difficult
> > > to implement, and the use case is not clear at all.=C2=A0 In= an
> > > automation deployment, do we expect that the client applicat= ion code
> > > contains logic to rewrite itself to send proper requests the= next
> > >=C2=A0 time?=C2=A0 =C2=A0If it is for debugging purposes I th= ink this should be up to
> > >=C2=A0 implementations to figure out.=C2=A0 We shouldn't = add such things to
> > > standard RPCs.
> >
> > <ev> there has been lots of discussion on this one.=C2=A0 T= he biggest issue has been
> that there are enough variations of parameters where the guidance on w= hat
> might be acceptable is the only way to make some scenarios work.=C2=A0= (Was it the
> period which was a problem?=C2=A0 Was it the complexity of the filter?= )=C2=A0 Obviously
> we do need to bound what could be provided back to the subscriber.
>
> So then the text should encourage implementations to provide good erro= r
> messages.

yes

> > The good news is that if a publisher cannot support negotiation, = it can just
> send back a failure.=C2=A0 Which is why the requirement is only a SHOU= LD.
>
> SHOULD is too strong.=C2=A0 And even so, this just adds complexity to = the
> specification.=C2=A0 I think this should be removed.

RFC7923 has it as a MUST (see section 4.2.2.)=C2=A0 Going to SHOULD is alre= ady easing off the requirement.

> > A worse outcome would be if a Subscriber kept guessing at accepta= ble
> parameters and pounding the Publisher with load on this.=C2=A0 This wo= uld take
> more resources than providing hints.
>
> That would also be quite weird.=C2=A0 But I can't imagine a use ca= se where a client
> needs a certain combination of parameters, the server rejcets them but= suggest
> some other parameters that will give the same result, and then the cli= ent
> would use them?=C2=A0 Or worse, the server suggest something that give= s another
> result and the client somehow adjust to them?

When a subscription is rejected, we can provide a hint at why.=C2=A0 This i= s a new dampening period, a suggestion to use on-change, etc.=C2=A0 Without= this hint, a subscriber could just keep guessing at parameters without gui= dance.=C2=A0 That is all negotiation is.

> > >o=C2=A0 Section 6
> > >
> > >=C2=A0 The text says:
> > >
> > >=C2=A0 =C2=A0The event notifications must also include the su= bscription-id if the
> > >=C2=A0 =C2=A0establish-subscription was used in its establish= ment, or if it was
> > >=C2=A0 =C2=A0configured via an operational interface.
> > >
> > >=C2=A0 How is this "sucbscription-id" supposed to b= e included?=C2=A0 Where?
> > >=C2=A0 There is no such field defined in a <notification&g= t;.
> >
> > <ev> Unlike yang-push, the Notification events are not spec= ified via the
> document.=C2=A0 =C2=A0The examples following the requirement do not in= clude a
> subscription-id when they absolutely should.=C2=A0 (And this proves th= e point that
> these are needed :-).=C2=A0 =C2=A0We will update the examples.
>
> Well, examples are good, but you also need a normative definition.

Will do.

Eric

> /martin
>
>
> >
> > Thanks again,
> > Eric

=C2=A0

=C2=A0


--001a114626eaa67a570543426d62-- From nobody Fri Dec 9 16:39:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30758129568 for ; Fri, 9 Dec 2016 16:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79g7-J1HaV-F for ; Fri, 9 Dec 2016 16:39:19 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0581294B0 for ; Fri, 9 Dec 2016 16:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=99774; q=dns/txt; s=iport; t=1481330358; x=1482539958; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qx/BiM6Ye30xV+kOgY5vcpeoUFDfwdx3HRhmfFh0hiE=; b=EE9M/vcidGcZmhbMtKgZZiN1LCzDyLoNb+tu2NONzRLkfdZVislf70ZG 1OacwlgRyuTBAufX4ijOfBUWYoDXlCygBza3255cK+zKpg+pWZFh5AIrK zRkGw/9iMbaH7vpVYX2v/H8tc0UZ9VV0xNPNLePuCcVpqy3sdkLPLQaCH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQAZTktY/51dJa1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJzRAEBAQEBH1qBBgeNQpcUlQKCCimFeAIagUw/FAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQECAQEaAQgKSgIFCwIBBgIRBAEBDhMBBgMCAgIwFAkIAgQOBQgSA?= =?us-ascii?q?YhICA6NbJ1KgimLIwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhj6DU4EIhBgJBA1?= =?us-ascii?q?Mgk6CPx4FiHSGDYFChD2FawGRF4F8jlKHZoYlhA0BHzcwcSSDPBwYgUVyAYYZA?= =?us-ascii?q?SWBCoENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="scan'208,217";a="359030184" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Dec 2016 00:39:16 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uBA0dFJ2010768 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 10 Dec 2016 00:39:15 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 19:39:15 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 9 Dec 2016 19:39:14 -0500 From: "Eric Voit (evoit)" To: Andy Bierman Thread-Topic: Filter construction (was RE: [Netconf] review of "event-notification" documents) Thread-Index: AQHSUncmr92m/26fzkqflYO/WsBE9KEAVlwg Date: Sat, 10 Dec 2016 00:39:14 +0000 Message-ID: <0ff12bf034b549e1b5f6ebab4596917d@XCH-RTP-013.cisco.com> References: <4fab79c122c24e0ab2300d47d7f72b3e@XCH-RTP-013.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_0ff12bf034b549e1b5f6ebab4596917dXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , "alex@clemm.org" Subject: Re: [Netconf] Filter construction (was RE: review of "event-notification" documents) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 00:39:24 -0000 --_000_0ff12bf034b549e1b5f6ebab4596917dXCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEFuZHksIHRoaXMgbWFrZXMgc2Vuc2UuICBXaWxsaW5nIHRvIHdhbGsgdGhyb3VnaCBp dCBvZiBvdGhlcnMgb24gdGhlIFdlZCBzdWJzY3JpcHRpb25zIGNhbGw/DQoNCkVyaWMNCg0KRnJv bTogQW5keSBCaWVybWFuLCBEZWNlbWJlciA5LCAyMDE2IDY6NTEgUE0NCg0KDQpPbiBGcmksIERl YyA5LCAyMDE2IGF0IDM6MzAgUE0sIEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb208 bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgQW5keSwNCg0KVGhlIGlzIGEgbG90 IGludGVyZXN0aW5nIGluIHlvdXIgZmlsdGVyLnlhbmcgZmlsZS4gIElmIHRoZSBXRyBkZXNpcmVz IHRvIGdvIGJleW9uZCB0aGUgZXhpc3Rpbmcgc3VidHJlZSBmaWx0ZXJpbmcgJiB4cGF0aCBtZWNo YW5pc21zLCB3ZSBzaG91bGQgZGV0ZXJtaW5lIGlmIHdlIGNhbiB1c2UgdGhpcyBhcyBhIGJhc2Uu ICBCdXQgaWYgd2UgZ28gZG93biB0aGlzIHBhdGggaXQgd2lsbCB0YWtlIHNvbWUgdGltZSB0byBn ZXQgdGhpcyByaWdodC4gIEFuZCBpZiB3ZSBkbyB0aGlzLCB3ZSBzaG91bGQgc3RydWN0dXJlIGFs bCBkcmFmdHMgc28gdGhhdCBmaWx0ZXJzIGNhbiBiZSBleHRlbmRlZCBvdmVyIHRpbWUgd2l0aG91 dCBuZWVkaW5nIHRvIG1vcnBoIHRoZSBzdWJzY3JpcHRpb25zIGRyYWZ0cy4NCg0KTXkgaW5pdGlh bCB0YWtlIG9uIHRoaXMgaXMgdGhhdCBpZiB3ZSBjaG9vc2UgdG8gcHVyc3VlIGZpbHRlci55YW5n LCBsYW5kaW5nIGZpbHRlcnMueWFuZyBhcyBhIHNlcGFyYXRlIG1vZGVsL2RyYWZ0IG1ha2VzIHNl bnNlLiAgUHV0IHNpbXBseSwgZmlsdGVycyBuZWVkIG5vdCBiZSBzdWJzY3JpcHRpb24gc3BlY2lm aWMuICAgSW4gZmFjdCwgaGF2aW5nIHByZWRlZmluZWQsIGRlY291cGxlZCBmaWx0ZXJzIG9uIGRl dmljZSBldmVuIGZvciBhIG5vcm1hbCBHRVQgY2FuIGdvIGEgbG9uZyB3YXkgdG8gZW5zdXJpbmcg dGhhdCBhbnkgc3BlY2lmaWMgZmlsdGVyIGhhcyBiZWVuIHByZXF1YWxpZmllZCBhcyBub3QgYmVp bmcgcmVzb3VyY2UtcHJvaGliaXRpdmUuDQoNCg0KSSB3b3VsZCBsaWtlIHRvIHVzZSB0aGlzIGFw cHJvYWNoIGZvciA8Z2V0LWNvbmZpZz4gYW5kIDxnZXQ+IGZpbHRlcmluZywgbm90IGp1c3Qgbm90 aWZpY2F0aW9ucy4NCg0KTXkgY29uY2VybiB3aXRoIHRoZSBjaG9pY2Utc3RtdCBhcHByb2FjaCBp cyB0aGF0IGZpbHRlcnMgd2lsbCBub3QgcmVhbGx5IGJlIHNoYXJlZCBvciBlYXN5IHRvIHdyaXRl Lg0KV2l0aCBuYW1lZCBmaWx0ZXIgcGFydHMgdGhhdCBhcmUgY29tYmluZWQgaW4gYSBhIGZpbHRl ciBleHByZXNzaW9uLCB0aGUgc2VydmVyIGNhbg0Kb3B0aW1pemUgdGhlIGZpbHRlciBwcm9jZXNz aW5nLiAgRWFjaCBmaWx0ZXIgcGFydCBuZWVkcyB0byBiZSBldmFsdWF0ZWQgYXQgbW9zdCBvbmNl IHBlciBub3RpZmljYXRpb24sDQpubyBtYXR0ZXIgaG93IG1hbnkgc3Vic2NyaXB0aW9ucyBhcmUg YWN0aXZlIGF0IG9uY2UuDQoNCkl0IGlzIGp1c3QgYSBmcmFtZXdvcmssIHZlcnkgc2ltaWxhciB0 byB0aGUgaW50ZXJmYWNlcyB0YWJsZS4NClVzaW5nIFlBTkcgaWRlbnRpdGllcyB0byBzcGVjaWZ5 IHRoZSBmaWx0ZXIgdHlwZSBhbGxvd3MgZXh0ZW5zaW9ucw0Kd2l0aG91dCB1cGRhdGluZyBhbnkg b3RoZXIgZG9jdW1lbnRzLg0KDQpUaGVyZSBpcyBhIGdlbmVyYWwgcHJvYmxlbSB3aXRoIGlkZW50 aXRpZXMgdGhhdCBhbHNvIGFmZmVjdHMgZmlsdGVyLnlhbmcuDQpKdXN0IGJlY2F1c2UgYSBzZXJ2 ZXIgYWR2ZXJ0aXNlcyBhIFlBTkcgbW9kdWxlIHdpdGggaWRlbnRpdGllcyBpbiBpdCBkb2VzIG5v dA0KbWVhbiBldmVyeSBpZGVudGl0eSBpcyBzdXBwb3J0ZWQuICBBIGZpbHRlci1jYXBhYmlsaXRp ZXMgdGFibGUgaXMgbmVlZGVkLg0KSU1PIHRoZXJlIHNob3VsZCBiZSBhIGNvbW1vbiBzb2x1dGlv biBmb3IgaWRlbnRpdGllcy4NCg0KDQpTbyBob3cgbWlnaHQgd2UgaW50ZWdyYXRlIHN1YnNjcmlw dGlvbnMgYW5kIGZpbHRlcnMueWFuZz86DQotIGZvciBwZXJzaXN0ZW50IGZpbHRlcnMgdGhhdCBh cmUgaW5kZXBlbmRlbnQgb2YgdGhlIHN1YnNjcmlwdGlvbiBsaWZlY3ljbGU6IHRoZSBzdWJzY3Jp cHRpb27igJlzIGZpbHRlci1yZWYgY2FuIHBvaW50IHRvIGEgc3RhbmQtYWxvbmUgeWFuZyBmaWx0 ZXIgbW9kZWwgaW4gYW4gaW1wb3J0ZWQgZmlsdGVyLnlhbmcNCi0gZm9yIGZpbHRlcnMgd2hpY2gg c2hvdWxkIG9ubHkgZXhpc3QgYXMgcGFydCBvZiB0aGUgbGlmZWN5Y2xlIG9mIGEgc3Vic2NyaXB0 aW9uOiBwZXJoYXBzIGRvIGEgc2NoZW1hIG1vdW50IG9mIGZpbHRlci55YW5nPyBUaGUgbW91bnRl ZCBzY2hlbWEgY2FuIGJlIHVzZWQgdG8gYWNjZXB0IGlucHV0IGZyb20gYW4gUlBDIGFuZCBzdG9y ZSBpdCBhcyBhIHRyYW5zaWVudCBpbi1saW5lIGZpbHRlci4gIEkuZS4sIHRoaXMgd2F5IHRoZSBj b250ZW50cyBvZiB0aGUgaW5saW5lIGZpbHRlcnMgd2lsbCBub3QgcGVyc2lzdCBsb25nZXIgdGhh biB0aGUgc3Vic2NyaXB0aW9uLiAgKElzIHRoZXJlIGEgd2F5IHRvIGRvIHRoaXMgd2l0aCBncm91 cGluZ3MvYXVnbWVudGF0aW9ucyBzbyB0aGF0IHNjaGVtYSBtb3VudCBpc27igJl0IG5lZWRlZD8p DQoNCkkgc3VzcGVjdCBieSBhcHByb2FjaGluZyB0aGUgaW50ZWdyYXRpb24gaW4gdGhpcyB3YXks IGl0IGlzIHBvc3NpYmxlIHRvIGV2b2x2ZSBmaWx0ZXIueWFuZyB3aXRob3V0IGRpcmVjdGx5IGNo YW5naW5nIHRoZSBzdWJzY3JpcHRpb24gbW9kZWwuICAoVGhlIG9ubHkgdGhpbmcgd291bGQgYmUg dGhhdCB5b3UgaGF2ZSB0byByZXYgaXMgdG8gYSBuZXcgbW9kZWwgdmVyc2lvbi4pDQoNCkJleW9u ZCB0aGlzIGludGVncmF0aW9uIHNwZWN1bGF0aW9uLCBiZWxvdyBhcmUgc29tZSB0aG91Z2h0cyBv biBzcGVjaWZpYyBlbGVtZW50cyBvZiB5b3VyIOKAnGZpbHRlcnMueWFuZ+KAmSBhdHRhY2htZW50 Og0KDQrigKIgICAgICAgTGluZSAyOTogaWYtZmVhdHVyZS1zdG10LXN0ciBzaG91bGQgYmUgaWYt ZmVhdHVyZS1zdG10LCBjb3JyZWN0Pw0KDQpubyAtLSB0aGF0IEFCTkYgaXMgZm9yIGlmLWZlYXR1 cmUgPGV4cHI+LiAgSSB3YW50ZWQganVzdCB0aGUgPGV4cHI+IHBhcnQuDQoNCg0K4oCiICAgICAg IExpbmUgNDE6IGlmLWZpbHRlci1mYWN0b3Igc2hvdWxkIGJlIGZpbHRlci1mYWN0b3IsIGNvcnJl Y3Q/DQoNCnByb2JhYmx5IC0tIHdpbGwgZml4DQoNCg0KDQoNCuKAoiAgICAgICBMaW5lIDU2OiBt aXhlZCBtZXRhcGhvciBvZiBhL2IvYyBhbmQgMS8yLzMuDQoNCm9rIC0tIHdpbGwgZml4DQoNCg0K 4oCiICAgICAgIExpbmUgMjA6IHdlIGxpa2VseSBuZWVkIGFuIGlkZW50aXR5IGZvciBhIHN0cmVh bSBzbyB0aGF0IGl0IGNhbiBiZSB1c2VkIGFzIGEgZmlsdGVyLXRlcm0NCg0KYWdyZWVkDQoNCg0K 4oCiICAgICAgIFRoZSBzZXQgb2Ygb3BlcmF0b3JzIGlzIOKAmGFuZOKAmSwg4oCYb3LigJkuICBU aGVyZSBpcyBhbHNvIGZhY3RvcmluZyB3aXRoIOKAmCjigJggYW5kIOKAmCnigJkuICBCdXQgdGhl IG1ham9yaXR5IG9mIHhwYXRoIG9wZXJhdG9ycyBhbmQgc3ludGF4IGlzIG5vdCBpbmNsdWRlZC4g IFdoaWNoIGlzIGEgZ29vZCB0aGluZy4gIEFzIGZpbHRlcnMgYXJlIG5vdCBuZWNlc3NhcmlseSBi b29sZWFuIGl0IG1pZ2h0IGJlIGludGVyZXN0aW5nIHRvIGZpZ3VyZSBvdXQgd2hhdCBvdGhlciBl bGVtZW50cyBtaWdodCBiZSBuZWVkZWQuICBUaGlzIHdpbGwgdGFrZSBzb21lIHRpbWUgdG8gZG8g cmlnaHQuDQoNCkkgdGhpbmsgdGhlIGlmLWZlYXR1cmUgc3ludGF4IGlzIGdvb2QgZW5vdWdoLiAg UmVzdHJpY3RlZCBYUGF0aCBpcyB0b28gbXVjaC4NCkkgd2FudGVkIHRvIGF2b2lkIHR5cGVzIGFu ZCB0eXBlIGNvbnZlcnNpb24gYW5kIGZsb2F0aW5nIHBvaW50LCBldGMuDQoNCiAgKGZpbHRlci0x IGFuZCBmaWx0ZXItMiBhbmQgbm90IGZpbHRlci0zKQ0KDQpUaGVzZSBhcmUgdmVyeSBlYXN5IHN0 cmluZ3MgdG8gY29uc3RydWN0IGJ5IGhhbmQgb3IgYnkgcHJvZ3JhbS4NClRoZSBnZW5lcmFsIHRl bXBsYXRlIG9mIHRoZSBmaWx0ZXIgbmVlZHMgYSBiaXQgb2Ygd29yaywgc3VjaCBhcw0KZGVmaW5p bmcgdGhlIHJlcXVpcmVtZW50cyBmb3IgYSBmaWx0ZXIgZGVmaW5pdGlvbjoNCg0KICAtIHdoaWNo IGNvbnRleHRzIHRoZSBmaWx0ZXIgY2FuIGJlIHVzZWQNCiAgLSBkb2N1bWVudCByb290DQogIC0g Y29udGV4dCBub2RlDQogIC0gZXZhbHVhdGlvbiBwcm9jZWR1cmVzDQoNCkl0IGlzIHVwIHRvIGVh Y2ggZmlsdGVyIGRlZmluaXRpb24gdG8gZGVzY3JpYmUgaG93IHRoZSAidHJ1ZSBvciBmYWxzZSIg cmV0dXJuIHZhbHVlDQppcyBkZXJpdmVkLiAgVGhhdCBpcyBhbGwgdGhhdCBtYXR0ZXJzIHRvIHRo ZSBmaWx0ZXIgZW5naW5lLg0KDQoNCkFuZHkNCg0KDQoNCg0K4oCiICAgICAgIEkgYW0gbm90IGNh dGNoaW5nIGFsbCB0aGUgc3VidGx0aWVzIGhlcmUuICBDb3VsZCB5b3UgcmV2aWV3IHRoaXMgb24g dGhlIG5leHQgRGV6aWduIHRlYW0gY2FsbD8NCg0K4oCiICAgICAgIFdlIHByb2JhYmx5IGRpc2N1 c3Mgd2hldGhlciB3ZSB3YW50IHRvIGxpbWl0IHRoZSBhbGxvd2FibGUgYW1vdW50IG9mIG5lc3Rp bmcgd2l0aGluIHRoZSBmaWx0ZXJpbmcgc3ludGF4LiAgUkZDIDUyNzcgZGlkbuKAmXQgZG8gc3Vj aCBsaW1pdGluZy4gIEFuZCB3aXRob3V0IGtub3dpbmcgdGhlIGEgZGVzaXJlZCBmaWx0ZXIgY3Jp dGVyaWEgd2hpY2ggY2FuIGJlIGFwcGxpZWQgYWdhaW5zdCByYW5kb20gY29sbGVjdGlvbnMgb2Yg b2JqZWN0cywgSSBzdWdnZXN0IHdlIGRvbuKAmXQgYXR0ZW1wdCB0aGlzIGVpdGhlci4gIFBlcmhh cHMgc29tZW9uZSBpbiB0aGUgZnV0dXJlIGNhbiBkZWZpbmUgYSBtaW5pbWFsIHNldCBvZiBuZXN0 aW5nIHdoaWNoIG11c3QgYmUgc3VwcG9ydGVkIGlmIHNvbWVvbmUgZGVzaXJlcyBmb3IgdGhlIGZp bHRlcnMgdGhlbXNlbHZlcyB0byBiZSBwb3J0YWJsZSBhY3Jvc3MgaW1wbGVtZW50YXRpb25zLg0K DQrigKIgICAgICAgRm9yIHRoZSBpZGVudGl0eSBuZXRjb25mLXN0cmVhbSwgeW91IHJlZmVyIHRv IFJGQzUyNzcgc2VjIDMuMi4gIElmIHRoaXMgaXMgYmVpbmcgb2Jzb2xldGVkLCBkbyB3ZSBuZWVk IGFub3RoZXIgZGVmaW5pdGlvbiBzb3VyY2U/IChBcyB0aGUg4oCYb2Jzb2xldGXigJkgZGlzY3Vz c2lvbiBoYXBwZW5lZCBhZnRlciB5b3Ugd3JvdGUgdGhlIGZpbHRlci55YW5nLCBwZXJoYXBzIHRo aXMgY2FuIGp1c3QgYmUgcmVtb3ZlZCBpZiB3ZSBnbyB0byDigJhvYnNvbGV0ZeKAmT8pDQoNCkFu eXdheSB0aGVyZSBpcyB0aGUgc3RhcnRlciB0aGlua2luZyBJIHByb21pc2VkLiAgTGV04oCZcyBj aGF0IG1vcmUgaWYgeW91IGFyZSB3aWxsaW5nIHRvIHJldmlldyB0aGlzIG9uIHRoZSBXZWQgY2Fs bC4NCg0KRXJpYw0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5j b208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIg MSwgMjAxNiAxOjQxIFBNDQpUbzogRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbTxt YWlsdG86ZXZvaXRAY2lzY28uY29tPj4NCkNjOiBCYWxhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5 ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+PiAoYmFs YXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5j b20+KSA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpiYWxhenMubGVuZ3llbEBl cmljc3Nvbi5jb20+PjsgYWxleEBjbGVtbS5vcmc8bWFpbHRvOmFsZXhAY2xlbW0ub3JnPjsgTWFy dGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj47IEFs YmVydG8gR29uemFsZXogUHJpZXRvIChhbGJlcnRnbykgPGFsYmVydGdvQGNpc2NvLmNvbTxtYWls dG86YWxiZXJ0Z29AY2lzY28uY29tPj47IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIHJldmlldyBvZiAiZXZlbnQtbm90aWZp Y2F0aW9uIiBkb2N1bWVudHMNCg0KSGksDQoNCkkgd29ya2VkIG9uIHRoZSBmaWx0ZXJpbmcgcHJv YmxlbSBhIGJpdCBtb3JlLg0KSGVyZSBpcyBmaWx0ZXIueWFuZywgYSBmaWx0ZXJpbmcgZnJhbWV3 b3JrLCBhbmQgdG9waWMueWFuZywgYW5kIGV4YW1wbGUgb2YgYSBmaWx0ZXIgdHlwZQ0KdGhhdCBj YW4gYmUgdXNlZCBpbiBmaWx0ZXIueWFuZy4gVG9waWMtYmFzZWQgZmlsdGVyaW5nIHdhcyBicmll Zmx5IGRpc2N1c3NlZCBpbiBTZW91bC4NCg0KSU1PIGZpbHRlcnMgd2lsbCBjb250aW51ZSB0byBl dm9sdmUgb3ZlciB0aW1lIHNvIHRoZSBzb2x1dGlvbiBuZWVkcyB0byBhbGxvdw0KdGhlbSB0byBi ZSBhZGRlZCBhbmQgY29tYmluZWQgd2l0aCBvdGhlciBmaWx0ZXJzLiAgVGhlIGN1cnJlbnQgWUFO RyBjaG9pY2Utc3RtdA0KaXMgbm90IGV4dGVuc2libGUgZW5vdWdoIG9yIHBvd2VyZnVsIGVub3Vn aC4NCg0KDQpBbmR5DQoNCg0KT24gVHVlLCBOb3YgMjksIDIwMTYgYXQgNzoxMSBQTSwgRXJpYyBW b2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbTxtYWlsdG86ZXZvaXRAY2lzY28uY29tPj4gd3Jv dGU6DQpGcm9tOiBBbmR5IEJpZXJtYW4sIE5vdmVtYmVyIDI5LCAyMDE2IDg6MzAgUE0NCk9uIFR1 ZSwgTm92IDI5LCAyMDE2IGF0IDg6MDUgQU0sIEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNj by5jb208bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+IHdyb3RlOg0KVGhhbmtzIE1hcnRpbiwNCg0K TW9yZSBpbiBsaW5lLiAgIEFsc28gSSBleHRyYWN0ZWQgYXJlYXMgd2hlcmUgd2UgYWxyZWFkeSBh Z3JlZSB0byBtYWtlIHRoaXMgZWFzaWVyIHRvIGZvbGxvdy4NCg0KPiBGcm9tOiBNYXJ0aW4gQmpv cmtsdW5kLCBOb3ZlbWJlciAyOSwgMjAxNiA2OjQwIEFNDQo+ID4gPklmIEkgdW5kZXJzdGFuZCB0 aGUgaW50ZW50aW9uIGNvcnJlY3RseSwgdGhpcyBkb2N1bWVudCBpcyBzdXBwb3NlZCB0bw0KPiA+ ID4qZGVmaW5lKiBob3cgbm90aWZpY2F0aW9ucyBhcmUgc2VudCBvdmVyIE5FVENPTkYuICBCdXQg dGhlcmUgaXMgbm8NCj4gPiA+c3VjaCBkZWZpbml0aW9uIGluIHRoaXMgZG9jdW1lbnQuICBJbnN0 ZWFkIGl0IHNpbXBseSByZXBlYXRzDQo+ID4gPmluZm9ybWF0aW9uIGFscmVhZHkgZGVmaW5lZCBp biBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTI3N2Jpcy0wMS50eHQsDQo+ID4gPmFuZCBwcm92aWRl cyBsb3RzIG9mIGV4YW1wbGVzIG9mIGhvdyB0aGUgWUFORyBvcGVyYXRpb25zIGRlZmluZWQgaW4N Cj4gPiA+cmZjNTI3N2JpcyBhcmUgZW5jb2RlZCBpbiBYTUwgYW5kIHNlbnQgb3ZlciBORVRDT05G Lg0KPiA+ID4NCj4gPiA+SSBzdWdnZXN0IHRoYXQgdGhpcyBkb2N1bWVudCBpcyByZXdyaXR0ZW4u ICBTaW5jZSB0aGUgaWRlYSBpcyB0bw0KPiA+ID5yZXBsYWNlIFJGQyA1Mjc3LCBpdCBuZWVkcyB0 byBmb2N1cyBvbiBob3cgbm90aWZpY2F0aW9ucyBhcmUgc2VudA0KPiA+ID5vdmVyIE5FVENPTkYs IGFuZCBub3QgaG93IFJQQ3MgYXJlIGVuY29kZWQgaW4gWE1MLg0KPiA+IEkgYWdyZWUgLS0gbWF5 YmUgZ2V0IHJpZCBvZiBpdCBhbmQganVzdCBoYXZlIHJmYzUyNzdiaXMgY29udGFpbiB0aGlzDQo+ ID4gdGV4dA0KPiA+DQo+ID4gPGV2PiA1Mjc3YmlzIGlzIHN1cHBvc2VkIHRvIGFsbG93IHRyYW5z cG9ydHMgb3RoZXIgdGhhbiBORVRDT05GLiAgSWYgd2UgcHV0DQo+IHRoZSBORVRDT05GIHNwZWNp ZmljIHN0dWZmIGluIGhlcmUgd2UgbG9zZSB0aGF0IHNlcGFyYXRpb24uDQo+DQo+IFdlIG5lZWQg KnNvbWUqIGRvY3VtZW50IHRoYXQgZGVmaW5lcyBob3cgbm90aWZpY2F0aW9ucyBhcmUgc2VudCBv dmVyDQo+IE5FVENPTkYuICBUaGlzIGRvY3VtZW50IG5lZWRzIHRvIGhhdmUgdGhlIHNwZWNpZmlj YXRpb24gZm9yIHRoZSA8bm90aWZpY2F0aW9uPg0KPiBlbGVtZW50Lg0KPg0KPiBUaGVuIHdlIG5l ZWQgYSBwcm90b2NvbC1pbmRlcGVuZGVudCBkb2N1bWVudCB0aGF0IGRlZmluZXMgdGhlIGNvbmNl cHQgb2YNCj4gc3RyZWFtcyBhbmQgc3Vic2NyaXB0aW9ucywgc3RyZWFtIGRpc2NvdmVyeSwgZXRj Lg0KPg0KPiBJICp0aGluayogdGhhdCB5b3VyIGludGVudGlvbiBpcyB0aGF0IG5ldyBjbGllbnRz IHJlYWxseSBzaG91bGQgYmUgdXNpbmcNCj4gPGVzdGFibGlzaC1zdWJzY3JpcHRpb24+IGluc3Rl YWQgb2YgPGNyZWF0ZS1zdWJzY3JpcHRpb24+LCBzaW5jZSBpdCBpcyBwcm90b2NvbC0NCj4gaW5k ZXBlbmRlbnQgYW5kIHN1cHBvcnQgbW9kaWZpY2F0aW9uIGFuZCBkZWxldGlvbi4NCj4NCj4gSWYg d2UgYWxzbyB3YW50IHRvIGJlIGZ1bGx5IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggNTI3Nywg SSB0aGluayB3ZSBzaG91bGQNCj4gY3JlYXRlIGEgZG9jdW1lbnQgdGhhdCBpcyBtdWNoIGNsb3Nl ciB0byB0aGUgY3VycmVudCA1Mjc3IC0gZXNzZW50aWFsbHkganVzdA0KPiBjcmVhdGluZyBhIFlB TkcgbW9kZWwgZm9yIHRoZSBjb25maWcgZmFsc2UgZGF0YSBhbmQgZm9yIHRoZSAib2xkIiA8Y3Jl YXRlLQ0KPiBzdWJzY3JpcHRpb24+Lg0KDQpXZSBhYnNvbHV0ZWx5IHdhbnQgdG8gaGF2ZSBhIGZ1 bGwgYmFja3dhcmRzIGNvbXBhdGlibGUgY2FwYWJpbGl0eS4gIFRoZSBxdWVzdGlvbiBpcyBob3cg dG8gYmVzdCBmcmFtZSB0aGlzIGluIGRvY3VtZW50cy4gIEl0IGlzIHBvc3NpYmxlIHRvIHJlYnVp bGQgUkZDLTUyNzcgd2l0aCBhIFlBTkcgbW9kZWwuICBCdXQgdGhlbiB5b3UgY2FuJ3QganVzdCBs YXllciBvbiBuZXcgY2FwYWJpbGl0aWVzIGRyaXZpbmcgdGhpcyB3b3JrLiAgKEFuZCB0aGlzIGlz IHdoeSB3ZSBuZWVkIHNlcGFyYXRlIG5hbWVzcGFjZXMuKQ0KDQoNCldlIG5lZWQgdG8gcGFyc2Ug YW5kIHVuZGVyc3RhbmQgImZ1bGwgYmFja3dhcmRzIGNvbXBhdGlibGUiLg0KDQpEbyB3ZSB3YW50 IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyB0byBiZSBsZXZlcmFnZWQgaW50byB0aGUgbmV3IHNv bHV0aW9uPyAgWWVzDQpBIHNlcnZlciBzaG91bGQgYmUgY2FwYWJsZSBvZiBzdXBwb3J0aW5nIDxj cmVhdGUtc3Vic2NyaXB0aW9uPiBmb3INCm9sZCwgZGVwcmVjYXRlZCBzdWJzY3JpcHRpb25zLCBh bmQgPGVzdGFibGlzaC1zdWJzY3JpcHRpb24+IGZvciB0aGUgbmV3IGN1cnJlbnQgc3Vic2NyaXB0 aW9ucy4NCg0KRG8gd2UgbmVlZCB0byB1cGRhdGUgUkZDIDUyNzcgb3IgcmVwbGFjZSBpdD8gSU1P LCByZXBsYWNlIGl0Lg0KU2luY2UgdGhlIDxjcmVhdGUtc3Vic2NyaXB0aW9uPiBSUEMgd2FzIG5l dmVyIGluIGEgWUFORyBtb2R1bGUsDQppdCBjYW4gYmUgbGVmdCBvdXQgb2YgdGhlIG5ldyBtb2R1 bGUuDQoNCjxldj4gSSBiZWxpZXZlIGF0IG1pbmltdW0gdGhhdCA8Y3JlYXRlIHN1YnNjcmlwdGlv bj4gc2hvdWxkIGJlIHB1bGxlZCBvdXQgb2YgdGhlIG5ldyBtb2R1bGUuICBJdCBuZWVkcyBpdHMg c2VwYXJhdGUgbmFtZXNwYWNlLiAgIFBlcmhhcHMgbm9ib2R5IGlzIHJlYWR5IHRvIGFkdm9jYXRl IGZvciBhIHBhcmFsbGVsIDUyNzctbGVnYWN5IFlBTkcgbW9kZWwgc2luY2UgbmV3IGRldmVsb3Bt ZW50IHNob3VsZCBnbyB0byB0aGUgbmV3IHBhcmFkaWdtIGFueXdheS4gIEluIHRoaXMgY2FzZSwg d2UgY291bGQganVzdCBoYXZlIGEgc3RhbmRhbG9uZSBsZWdhY3kgNTI3NyBzZWN0aW9uIGluIHRo ZSBkb2N1bWVudCBmb3IgYW55dGhpbmcgbmVlZGVkLiAgVGhpcyB3b3VsZCBtYWtlIHRoaW5ncyBz aW1wbGVyIGFuZCBlYXNpZXIgdG8gdGVhc2UgYXBhcnQuDQoNCkV2ZW4gbW9yZSByYWRpY2FsLCBJ IHRoaW5rIHN0cmVhbXMgc2hvdWxkIGJlIHJlbW92ZWQsIGV2ZW4gdGhlIE5FVENPTkYgc3RyZWFt Lg0KVGhleSByZWFsbHkgc2VydmUgbm8gcHVycG9zZSBub3cgdGhhdCBzdWJzY3JpcHRpb25zIGFy ZSBmb3JtYWxpemVkIGFuZCBjYW4NCmV2ZW4gYmUgY29uZmlndXJlZC4gIEl0IGlzIGFsc28gYmFk IGRlc2lnbiB0byBjb3VwbGUgdGhlIG91dHB1dCBtZXNzYWdlIGVuY29kaW5nDQppbnRvIHRoZSBp bnB1dCBzdHJlYW0uIChlLmcuLCBORVRDT05GIHN0cmVhbSBNVVNUIGJlIFhNTCBlbmNvZGVkKS4N Cg0KPGV2PiBFdmVuIGFzIHdlIG1vdmUgYXdheSBmcm9tIHN0cmVhbXMsIEkgc3RpbGwgY2FuIHNl ZSByZWFzb25zIGZvciBpdC4gIChBZGRpbmcgQmFsYXpzICYgQWxleCBhcyB0aGV5IGhhdmUgYmVl biBwcm9wb25lbnRzLikgIFRoZSBiaWdnZXN0IHJlYXNvbiBmb3Igc3RyZWFtcyBpcyB0aGF0IGEg cm9idXN0IGN1c3RvbWVyIGRlc2lnbmVkIGZpbHRlcnMgYXJlIGhhcmQuICBJZiBhIHZlbmRvci9j dXN0b21lci9ldGMuIGlzIGFibGUgdG8gcHJlLWZpbHRlciBub3RpZmljYXRpb25zIG9yIGRhdGFz dG9yZSBpbiBhbiBpbnRlcmVzdGluZyBhbmQgdXNlZnVsIHdheSBub3Qgc3VwcG9ydGFibGUgYnkg b3VyIGZpbHRlcmluZyBzZW1hbnRpY3MsIHRoaXMgaXMgYSBnb29kIHdheSB0byBhbGxvdyB0aGUg cHJlLWZpbHRlcmluZy4gU29tZSBleGFtcGxlcyB3aGljaCBjb3VsZCBiZSBpbnRlcmVzdGluZzoN Cg0K4oCiICAgICAgIEV2ZW50IG5vdGlmaWNhdGlvbnMgd2hlbiBuZXcgZGV2aWNlcyBjb25uZWN0 IHRvIGEgbmV0d29yaw0KDQrigKIgICAgICAgQWxhcm1zIHBvdGVudGlhbGx5IHNldCBhY3Jvc3Mg bXVsdGlwbGUgWUFORyBtb2RlbHMNCg0KQ3VycmVudGx5LCBmaWx0ZXJzIGFyZSBkZWZpbmVkIGFz IGEgY2hvaWNlLXN0bXQuDQpUaGlzIGltcGxpZWQgT1ItZXhwciBpcyB0b28gc2ltcGxpc3RpYy4g QW4gZXhwbGljaXQgY29tYmluYXRpb24gb2YgT1IsIEFORCwgYW5kIE5PVCBpcyByZXF1aXJlZA0K Zm9yIGRpZmZlcmVudCB0eXBlcyBvZiBmaWx0ZXJzLiAgKHNpbWlsYXIgdG8gWUFORyAxLjEgaWYt ZmVhdHVyZS1zdG10IHN5bnRheCkuDQoNCjxldj4gVG90YWxseSBhZ3JlZSB0aGF0IHdlIG5lZWQg cm9idXN0IGZpbHRlcnMuICBGaWd1cmluZyB0aGlzIHByb2JsZW0gc3BhY2Ugb3V0IGlzIGEgZnVs bCB0aW1lIGpvYi4gIEZpZ3VyaW5nIG91dCBob3cgdG8gZW5jb2RpbmcgZmlsdGVyaW5nIGNhcGFi aWxpdGllcyBzdXBwb3J0ZWQgb24gZGlmZmVyZW50IHR5cGVzIG9mIGNvbnN0cmFpbmVkIHBsYXRm b3JtcyBpcyBub24tdHJpdmlhbC4gIEkgd291bGQgbG92ZSB0byBzZWUgc29tZW9uZSB0YWtlIHRo aXMgb24gZm9yIHRoZSBpbmR1c3RyeS4gIEFueSB0YWtlcnM/DQoNCkVyaWMNCg0KQW5keQ0KDQoN CkFzIGxheWVyaW5nIHVwb24gUkZDLTUyNzcgY2Fubm90IGdpdmUgdGhlIG5ldyBjYXBhYmlsaXRp ZXMgYmVpbmcgcmVxdWVzdGVkIG9mIHVzIGluIHBsYWNlcyBsaWtlIFJGQy03OTIzIChlLmcuLCBt dWx0aXBsZSBzdWJzY3JpcHRpb25zL3Nlc3Npb24pLCB3ZSBhcmUgbW92aW5nIG5vdyB0byBwdXQg YWxsIGVsZW1lbnRzIGp1c3QgbmVlZGVkIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBpbiB0 aGUgbmV0Y29uZiB0cmFuc3BvcnQgZHJhZnQuICBXZSBjb3VsZCBhbHNvIHNlcGFyYXRlIGFsbCB0 aGlzIG91dCBpbnRvIGFub3RoZXIgaW5kZXBlbmRlbnQgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkg ZXh0ZW5zaW9uLiAgQnV0IHdlIGZlbHQgd2UgaGFkIGVub3VnaCBkcmFmdHMgaW4gcHJvZ3Jlc3Mg d2hlcmUgd2UgZGlkbid0IHdhbnQvbmVlZCBhIGZpZnRoIG9uZS4NCg0KPiA+IFtBR10gRldJVywg dGhlIHNjb3BlIG9mIGVhY2ggZG9jIGlzIHN1bW1hcml6ZWQgb24NCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LW5ldGNvbmYtNS5wZGYNCj4g PiAoc2xpZGUNCj4gPiAjNSkNCj4gPiBbQUddIFRoZSBrZXkgaXMgdGhhdCB0aGUgc3BlYyBmb3Ig TkMgY29tZXMgZnJvbSB0aGUgdW5pb24gb2YgNTI3Ny1iaXMNCj4gPiBhbmQgdGhlIE5DIHRyYW5z cG9ydCBkb2MNCj4gPiAoZHJhZnQtaWV0Zi1uZXRjb25mLW5ldGNvbmYtZXZlbnQtbm90aWZpY2F0 aW9ucy0wMS50eHQpIFRoZSBOQw0KPiA+IHRyYW5zcG9ydCBkb2MgaXMgbm90IG1lYW50IHRvIHN0 YW5kIGFsb25lLg0KPiA+IFRoZSBkb2MgY29udGFpbnMgaG93IDUyNzctYmlzIGNvbmNlcHRzIGFy ZSByZWFsaXplZCB3aGVuIHVzaW5nIE5DIGFuZA0KPiA+IE5DLXNwZWNpZmljIGFzcGVjdHMuIEUu Zy46DQo+ID4gLSB0aGUgdXNlIG9mIE5DIGNhbGwtaG9tZSBmb3IgY29uZmlndXJlZCBzdWJzY3Jp cHRpb25zDQo+ID4gLSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eQ0KPiA+ICAgIC0gdGhlIGV4aXN0 ZW5jZSBvZiBhIE5FVENPTkYgc3RyZWFtDQo+ID4gICAgLSBzdXBwb3J0IG9mIC9uZXRjb25mL3N0 cmVhbXMNCj4gPiA8ZXY+IFllcywgYW55IDUyNzdiaXMgdG9waWMgc3BlY2lmaWMgdG8gb25seSBO RVRDT05GIHRyYW5zcG9ydCBzaG91bGQNCj4gPiBiZSBpbiBuZXRjb25mLWV2ZW50LW5vdGlmaWNh dGlvbnMNCj4gPg0KPiA+IEkgYWdyZWUgd2l0aCBNYXJ0aW4gdGhhdCBkdXBsaWNhdGluZyBub3Jt YXRpdmUgdGV4dCBpcyBiYWQuDQo+ID4gTm90IGhhdmluZyBhbnkgbm9ybWF0aXZlIHRleHQgaXMg ZXZlbiB3b3JzZS4NCj4gPg0KPiA+IDxldj4gKzEuICBUbyBoZWxwIGFkZHJlc3MgdGhhdCwgSSBq dXN0IGJ1aWx0IGEgd2hvbGUgbGlzdCBvZiBwZW5kaW5nIGNoYW5nZXMNCj4gYWNyb3NzIHRoZSBm b3VyIGRyYWZ0cy4gIEFuZCBpbiBxdWl0ZSBhIGZldyBwbGFjZXMgSSBwdWxsZWQgb3V0IGR1cGxp Y2F0aXZlIHRleHQuDQo+ID4NCj4gPiAtIHRoZSBkZWZpbml0aW9uIG9mIGNyZWF0ZS1zdWJzY3Jp cHRpb24gbWF5IGJlIG1vdmVkIHRvIHRoaXMgZG9jIHNvDQo+ID4gdGhhdCBvdGhlciB0cmFuc3Bv cnRzIHdvdWxkIGlnbm9yZSBjcmVhdGUtc3Vic2NyaXB0aW9uIGFuZCB1c2Ugb25seQ0KPiA+IGVz dGFibGlzaC1zdWJzY3JpcHRpb24sIHNpbXBsaWZ5aW5nIHRoZSBzb2x1dGlvbg0KPiA+DQo+ID4N Cj4gPiBUaGF0IHNlZW1zIHdyb25nIHNpbmNlIDUyNzcgaGFkIGNyZWF0ZS1zdWJzY3JpcHRpb24g c28gaXQgc2hvdWxkIHN0YXkNCj4gPiBpbiA1Mjc3YmlzDQo+ID4NCj4gPiA8ZXY+IEl0IGlzIHJl YWxseSBhIHN0eWxlIHRoaW5nIHNvIGl0IGRvZXNu4oCZdCBtYXR0ZXIgdGhhdCBtdWNoIGVpdGhl ciB3YXkuDQo+IEN1cnJlbnQgdGhpbmtpbmcgaXMgdGhhdCBhcyB3ZSBuZWVkIGJvdGggdGhlIG5l dyBhbmQgb2xkIG5hbWVzcGFjZXMuDQo+IFRoZXJlZm9yZSBpdCBzZWVtcyBzaW1wbGVyIHRvIGhh dmUgYW55dGhpbmcgaW4gdGhlIG9sZCBuYW1lc3BhY2UgKOKAnGNyZWF0ZS0NCj4gc3Vic2NyaXB0 aW9u4oCdKSBpbiBuZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbiBkcmFmdC4NCj4NCj4gSSBhZ3Jl ZSB3aXRoIEFuZHkgdGhhdCBhbnl0aGluZyB0aGF0IGNvbWVzIGZyb20gNTI3NyB0aGF0IHlvdSBu ZWVkIHRvIGtlZXANCj4gZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHJlYXNvbnMgc2hvdWxk IGdvIGludG8gNTI3N2Jpcy4NCg0KUmlnaHQgbm93IGl0IGlzIGluIDUyNzdiaXMuICBCdXQgd2Ug YWxyZWFkeSBjYW4ndCBoYXZlIGV2ZXJ5dGhpbmcgbmVlZGVkIGZvciBiYWNrd2FyZHMgY29tcGF0 aWJpbGl0eSBzaW5jZSB0aGUgNTI3N2JpcyBpcyB0cmFuc3BvcnQgKE5FVENPTkYpIGluZGVwZW5k ZW50LiAgU28gaXQgc2VlbWVkIGxvZ2ljYWwgdG8gcHV0IGl0IE5FVENPTkYgdHJhbnNwb3J0IGRy YWZ0LiAgKEFnYWluIHdlIHdlcmUgdHJ5aW5nIHRvIGxpbWl0IHRoZSBwcm9saWZlcmF0aW9uIG9m IGRyYWZ0cy4pDQoNCkluIHRoZSBlbmQsIEkgYW0gb2sgYXMgbG9uZyBhcyBpdCBsYW5kcyBzb21l d2hlcmUuICBTbyBpZiBwZW9wbGUgcHJlZmVyLCB3ZSBjb3VsZCBhbHNvIGhhdmUgdGhpcyBhcyBh IGNvbXBsZXRlbHkgc2VwYXJhdGUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgc2VjdGlvbiArIFlB TkcgbW9kZWwgaW4gNTI3N2Jpcy4NCg0KPiA+IC0gaG93IHRvIGlzc3VlIG5vdGlmaWNhdGlvbnMg aW4gSlNPTiBhcmUgc2VudCB1c2luZyBOQyAodGhpcyBpcyBhbHNvDQo+ID4gaW4gNTI3Ny1iaXMp LiBBcmd1YWJseSwgaXQgYmVsb25ncyBpbiB0aGUgTkMgdHJhbnNwb3J0IGRvYw0KPiA+DQo+ID4N Cj4gPg0KPiA+IFRoaXMgaXMgcG9vcmx5IGRlZmluZWQuDQo+ID4gTkVUQ09ORiBkb2VzIG5vdCBz dXBwb3J0IEpTT04gZW5jb2RpbmcgYW5kIElNTyBzaG91bGQgbm90IGRlZmluZSBKU09ODQo+ID4g ZW5jb2RpbmcgdW5sZXNzIHRoZSBlbnRpcmUgcHJvdG9jb2wgc3VwcG9ydHMgaXQgY2xlYW5seS4N Cj4gPiBUaGUgcHJvcG9zYWwgc2VlbXMgdG8gYmUgdG8gdXNlIFhNTCBmb3IgPHJwYz4gYW5kIDxy cGMtcmVwbHk+LCBidXQNCj4gPiBhbGxvdyBzb21lIHNwZWNpYWwgbW9kZSB3aGVyZSA8bm90aWZp Y2F0aW9uPiBpcyBzZW50IGluIEpTT04uDQo+ID4NCj4gPiA+DQo+ID4gPm8gIFNlY3Rpb24gMi4x DQo+ID4gPg0KPiA+ID4gIFRoZSB0ZXh0IHNheXM6DQo+ID4gPg0KPiA+ID4gICBUaGUgTkVUQ09O RiBldmVudCBzdHJlYW0gY29udGFpbnMgYWxsDQo+ID4gPiAgIE5FVENPTkYgWE1MIGV2ZW50IG5v dGlmaWNhdGlvbnMgc3VwcG9ydGVkIGJ5IHRoZSBwdWJsaXNoZXIsDQo+ID4gPg0KPiA+ID4gIEZp cnN0IG9mIGFsbCwgc2luY2UgdGhpcyBkb2N1bWVudCBpcyBwcm90b2NvbC1hZ25vc3RpYywgc2hv dWxkIGl0DQo+ID4gPiByZWFsbHkgZGVmaW5lIHRoZSBzdHJlYW0gIk5FVENPTkYiPw0KPiA+DQo+ ID4gPGV2PiBBZ3JlZSwgd2hpY2ggaXMgd2h5IHRoaXMgaXMgZ29pbmcgdG8gbmV0Y29uZi1ldmVu dC1ub3RpZmljYXRpb24uDQo+ID4NCj4gPiA+ICBTZWNvbmRseSwgdGhpcyB3b3VsZCBiZSBhIG5l dyByZXF1aXJlbWVudC4gIFRoZXJlIGlzIG5vdGhpbmcgaW4gUkZDDQo+ID4gPiAgNTI3NyB0aGF0 IHNheXMgdGhhdCBhIG5vdGlmaWNhdGlvbiBpcyBzZW50IG9uICJORVRDT05GIiBiZSBkZWZhdWx0 Lg0KPiA+DQo+ID4gPGV2PiA1Mjc3IHNlY3Rpb24gMy4yLjMgdGFsa3MgYWJvdXQgdGhlIGRlZmF1 bHQgZXZlbnQgc3RyZWFtIHdoaWNoIGhhcw0KPiA+IGFsbCBORVRDT05GIGV2ZW50IG5vdGlmaWNh dGlvbnMNCj4NCj4gWW91J3JlIHJpZ2h0LiAgVGhlIHF1ZXN0aW9uIGlzIHRoZW4gd2hhdCBpcyBh biAiTkVUQ09ORiBYTUwgZXZlbnQNCj4gbm90aWZpY2F0aW9uIj8gIEkgdGhpbmsgdGhlIGludGVu dGlvbiB3YXMgdGhhdCB0aGVzZSB3b3VsZCBiZSAibm90aWZpY2F0aW9ucw0KPiByZWxhdGVkIHRv IE5FVENPTkYiLCByYXRoZXIgdGhhbiAiYWxsIFlBTkctZGVmaW5lZCBub3RpZmljYXRpb25zIi4g IFRoaXMgbmVlZHMNCj4gc29tZSBkaXN1Y3NzaW9uLg0KDQpBZ3JlZQ0KDQo+ID4gPiAgSSB0aGlu ayB0aGlzIHRleHQgc2hvdWxkIGJlIHJlbW92ZWQuICBIb3cgbm90aWZpY2F0aW9ucyBhcmUgbWFw cGVkDQo+ID4gPiB0byBzdHJlYW1zIGlzIHNob3VsZCBiZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMg ZG9jdW1lbnQuDQo+ID4NCj4gPiA8ZXY+IFllcywgc3RyZWFtcyBhcyBhIHdob2xlIHdlcmUgc29t ZXRoaW5nIHdlIGRlZmVycmVkIGZvciBhIHdoaWxlLiAgTGF0ZXN0DQo+IHRoaW5raW5nIGlzIHdl IG1pbmltaXplIHN0cmVhbXMgdG8gdGhlIGRlZ3JlZSBwb3NzaWJsZS4gIExvb2sgZm9yIGxlZ2Fj eSBzdHVmZiB0bw0KPiBiZSBpbiBuZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbi4NCj4NCj4gRG8g eW91IG1lYW4gdGhhdCB5b3UgcGxhbiB0byB1cGRhdGUgdGhlIHRleHQgYXJvdW5kIHN0cmVhbXM/ ICBJZiBzbywgdGhhdCdzDQo+IGZpbmUuDQoNClllcw0KDQo+ID4gPiAgSW4gbGlzdCAiZmlsdGVy IiwgY2hhbmdlICJmaWx0ZXItaWQiIHRvICJpZCIuDQo+ID4gPg0KPiA+ID4gIEluIGxpc3QgInN1 YnNjcmlwdGlvbiIsIGNoYW5nZSAic3Vic2NyaXB0aW9uLWlkIiB0byAiaWQiLg0KPiA+DQo+ID4g PGV2PiBNb2RlbCBwdXJpdHktd2lzZSB5b3UgYXJlIGNvcnJlY3QuICBXaXRoIGJvdGggc3Vic2Ny aXB0aW9uIGlkIGFuZCBmaWx0ZXINCj4gaWQsIHNldmVyYWwgcGVvcGxlIGV4cHJlc3NlZCB0aGV5 IHdhbnRlZCB0aGUgb2JqZWN0cyB0byBiZSBpbW1lZGlhdGVseSBhbmQNCj4gb2J2aW91c2x5IGRp ZmZlcmVudGlhYmxlLiAgIEhvcGVmdWxseSBvdGhlcnMgd2lsbCBjaGltZSBpbiBoZXJlLg0KPg0K PiBJIHRoaW5rIHdlIHNob3VsZCB0cnkgdG8ga2VlcCB0aGUgc2FtZSBzdHlsZSBhY3Jvc3MgSUVU RiBkb2N1bWVudHMuDQo+IE1vc3QgbW9kZWxzIGRvIG5vdCB1c2UgcmVkdW5kYW50IHF1YWxpZmll cnMsIGVzcGVjaWFsbHkgbm90IGZvciBnZW5lcmljIG5hbWVzDQo+IGxpa2UgJ2lkJyBvciAnbmFt ZScgd2hlbiB1c2VkIGFzIGEga2V5Lg0KDQpJIGFtIGhhcHB5IHdpdGggd2hhdGV2ZXIgY29udmVu dGlvbiB0aGUgV0cgY2hvb3Nlcy4NCg0KPiA+ID4gIEluIGxpc3QgInN1YnNjcmlwdGlvbiIsIGNo YW5nZSAic3RhcnRUaW1lIiB0byAic3RhcnQtdGltZSIgYW5kDQo+ID4gPiAic3RvcFRpbWUiIHRv ICJzdG9wLXRpbWUiLCBmb3IgY29uc2lzdGVuY3kuDQo+ID4NCj4gPiA8ZXY+IHdlIGtlcHQgdGhl IG9sZCBuYW1lcyBmb3IgYmFja3dhcmRzIGVxdWl2YWxlbmN5IHRvIDUyNzcuDQo+DQo+IEJ1dCB0 aGVyZSBpcyBub3RoaW5nIHRvIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggaW4gdGhpcyBj YXNlLg0KPiBUaGUgaW5wdXQgcGFyYW10ZXJzIHRvIHRoZSBleGlzdGluZyA8Y3JlYXRlLXN1YnNj cmlwdGlvbj4gY2Fubm90IGJlIGNoYW5nZWQsDQo+IGJ1dCBuZXcgbm9kZXMgc2hvdWxkIGJlIGtl cHQgY29uc2lzdGVudC4NCg0KT2suICBTbyB5b3Ugd2FudCBzdGFydC10aW1lIGluIHRoZSBZQU5H IG1vZGVsLCBhbmQgc3RhcnRUaW1lIGluIHRoZSBSUEMuICBUaGF0IGNhbiBiZSBkb25lLg0KDQo+ ID4gPiAgSW4gbGlzdCAic3Vic2NyaXB0aW9uIiwgY2hhbmdlIGNob2ljZSAicHVzaC1zb3VyY2Ui IHRvIGEgYmV0dGVyDQo+ID4gPiBuYW1lLCBtYXliZSAiZWdyZXNzLWludGVyZmFjZSIgKHRoaXMg aXMgaG93IGl0IGlzIGRlc2NyaWJlZCkuDQo+ID4NCj4gPiA8ZXY+IHB1c2gtc291cmNlIGNhbiBh bHNvIGJlIGFuIElQIEFkZHJlc3MuICBBbm90aGVyIG5hbWUgcG9zc2liaWxpdHkgZm9yIHRoaXMN Cj4gbWlnaHQgYmUg4oCcT3JpZ2luYXRlcy1mcm9t4oCdLCB0aGF0IGlzIHRoZSBiYXNpYyBpZGVh Lg0KPg0KPiBUaGUgY3VycmVudCBkcmFmdCBoYXM6DQo+DQo+ICAgICAgICBjaG9pY2UgcHVzaC1z b3VyY2Ugew0KPiAgICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAgICJJZGVudGlmaWVz IHRoZSBlZ3Jlc3MgaW50ZXJmYWNlIG9uIHRoZSBQdWJsaXNoZXIgZnJvbQ0KPiAgICAgICAgICAg ICB3aGljaCBub3RpZmljYXRpb25zIHdpbGwgb3IgYXJlIGJlaW5nIHNlbnQuIjsNCj4NCj4gWW91 IHByb2JhYmx5IG5lZWQgdG8gYWRqdXN0IHRoaXMsIGFuZCBtYWtlIGl0IGNsZWFyIHdoYXQgdGhl IGlwLWFkZHJlc3MgY2FzZQ0KPiByZWFsbHkgbWVhbnMuDQoNCmFncmVlDQoNCj4gPiA+ICBJbiBs aXN0ICJyZWNlaXZlciIsIHdoYXQgaXMgYSAibXVsdGlwb2ludCBhZGRyZXNzIj8NCj4gPg0KPiA+ IDxldj4gd2UgYXJlIHRyeWluZyBub3QgdG8gbGltaXQgcmVjZWl2ZXJzIHRvIGhvc3RzLiBQZXJo YXBzIG11bHRpY2FzdCBhZGRyZXNzIGlzDQo+IG9rLiAgUmVhbGx5IHdlIHdvdWxkIGJlIGdvb2Qg d2l0aCB0eXBlOiBpbmV0Omhvc3QuDQo+DQo+IFRoZSB0eXBlIGlzIGluZXQ6aG9zdCBhbHJlYWR5 Lg0KPg0KPiBZb3Ugc2hvdWxkIHByb2JhYmx5IGNsYXJpZnkgdGhlIGRlc2NyaXB0aW9ucy4NCg0K YWdyZWUNCg0KPiA+ID4gIFJlbW92ZSB0aGUgbGVhZiAic291cmNlLXZyZiI7IHRoaXMgc2hvdWxk IGV2ZW50dWFsbHkgYmUgYWxpZ25lZA0KPiA+ID4gd2l0aCAgZHJhZnQtaWV0Zi1ydGd3Zy1uaS1t b2RlbC4NCj4gPg0KPiA+IFBlcmhhcHMgYSBwbGFjZSBmb3Igc2NoZW1hLW1vdW50Pw0KPg0KPiBO b3QgcmVhbGx5LCByYXRoZXIgYW4gYXVnbWVudC4NCg0KSGFwcHkgdG8gZ28gd2l0aCB3aGF0ZXZl ciBjb252ZW50aW9uIHBlb3BsZSB3YW50IHRvIHVzZS4NCg0KPiA+IFdlIHNob3VsZCBsZWF2ZSBz b3VyY2UtdnJmIGluDQo+ID4gcGxhY2UgdW50aWwgd2UgaGF2ZSB0aGUgcHJvcGVyIGRlZmluaXRp b24uDQo+DQo+IE5vIEkgc2F5IHJlbW92ZSBpdCB1bnRpbCB5b3UgaGF2ZSBhIHByb3BlciBkZWZp bml0aW9uLiAgSWYgeW91IGtlZXAgaXQgeW91IG5lZWQgdG8NCj4gaGF2ZSBhIHByb3BlciBkZWZp bml0aW9uIG9mIHdoYXQgaXQgaXMsIGFuZCBpdCBuZWVkcyB0byBiZSBpbnRlcm9wZXJhYmxlIGFj cm9zcw0KPiBpbXBsZW1lbnRhdGlvbnMuDQoNCldlIHdpbGwgYWRkcmVzcyB3aXRoIHRoZSBwcm9w ZXIgY29udmVudGlvbiBpbiB0aGUgbmV4dCBkcmFmdA0KDQo+ID4gQnV0IHdlIGNvdWxkIHVwZGF0 ZSB0aGUgdGV4dCBzaG93aW5nIHRoZXJlIGlzIGEgcGVuZGluZyBkZWNpc2lvbi4NCj4gPg0KPiA+ ID4gIFlvdSBoYXZlIG1hZGUgdGhlIHN0cmVhbSBuYW1lIGFuIGlkZW50aXR5LiAgSW4gUkZDIDUy NzcgaXQgd2FzIGENCj4gPiA+IHN0cmluZy4gIEJ5IHVzaW5nIGFuIGlkZW50aXR5LCB5b3Ugc2V2 ZXJseSBsaW1pdCBob3cgaXQgY2FuIGJlIHVzZWQ7DQo+ID4gPiB3aXRoIGEgc3RyaW5nIG5ldyBz dHJlYW1zIGNhbiBiZSBkeW5hbWljYWxseSBjcmVhdGVkIGF0IHJ1bi10aW1lLA0KPiA+ID4gYnV0 IHdpdGggYW4gaWRlbnRpdHkgc3RyZWFtIG5hbWVzIG11c3QgYmUga25vd24gYXQgZGVzaWduLXRp bWUuDQo+ID4gPiAgSSB0aGluayB0aGUgc3RyZWFtIG5hbWUgc2hvdWxkIGJlIGNoYW5nZWQgYmFj ayB0byBhIHN0cmluZy4NCj4gPg0KPiA+IDxldj4gYXMgdGhlIG1ham9yaXR5IG9mIHRoZSBwZW9w bGUgaW4gdGhlIGluZm9ybWFsIGRlc2lnbiB0ZWFtIHdlcmUgYWdhaW5zdA0KPiB0aGUgZXhwYW5z aW9uIG9mIHN0cmVhbXMsIHRoaXMgaXMgbGlrZWx5IGEgbW9vdCBwb2ludC4NCj4NCj4gSSBkb24n dCBrbm93IHdoYXQgImV4cGFuc2lvbiBvZiBzdHJlYW1zIiBtZWFucywgYW5kIEkgZG9uJ3QgdW5k ZXJzdGFuZCB3aGF0DQo+ICJ0aGlzIiByZWZlcnMgdG8gaW4gInRoaXMgaXMgbGlrZWx5IGEgbW9v dCBwb2ludCIuDQo+DQo+IEJ1dCBpZiB3ZSBrZWVwIHRoZSBzdHJlYW0gbmFtZSBhcyBhbiBpZGVu dGl0eSB3ZSdyZSBubyBsb25nZXIgYmFja3dhcmRzDQo+IGNvbXBhdGlibGUgd2l0aCBSRkMgNTI3 NywgYW5kIHdlIHNldmVybHkgbGltaXQgdGhlIGZ1bmN0aW9uYWxpdHkuICBJIHN0cm9uZ2x5DQo+ IG9iamVjdCB0byBzdWNoIGEgY2hhbmdlLg0KDQpJIGFtIGZpbmUgd2l0aCBzdHJpbmcsIGVzcGVj aWFsbHkgYXM6DQooYSkgd2UgYXJlIG1vdmluZyBhd2F5IGZyb20gc3RyaW5ncyBpbiBmYXZvciBv ZiBmaWx0ZXJzDQooYikgY3VzdG9tIHN0cmVhbXMgYXJlIGxpa2VseSB0byBiZSB0aGUgZG9taW5h bnQgdXNlLg0KQW55b25lIGhhdmUgYW4gb2JqZWN0aW9uICB0byB0aGlzIGNoYW5nZT8NCg0KPiA+ ID5vICBTZWN0aW9uIDQuMQ0KPiA+ID4NCj4gPiA+ICBUaGUgdGV4dCBzYXlzOg0KPiA+ID4NCj4g PiA+ICAgSWYgdGhlDQo+ID4gPiAgIHJlcXVlc3QgaXMgcmVqZWN0ZWQgYmVjYXVzZSB0aGUgcHVi bGlzaGVyIGlzIG5vdCBhYmxlIHRvIHNlcnZlIGl0LA0KPiA+ID4gICB0aGUgcHVibGlzaGVyIFNI T1VMRCBpbmNsdWRlIGluIHRoZSByZXR1cm5lZCBlcnJvciB3aGF0IHN1YnNjcmlwdGlvbg0KPiA+ ID4gICBwYXJhbWV0ZXJzIHdvdWxkIGhhdmUgYmVlbiBhY2NlcHRlZCBmb3IgdGhlIHJlcXVlc3Qg d2hlbiBpdCB3YXMNCj4gPiA+ICAgcHJvY2Vzc2VkLg0KPiA+ID4NCj4gPiA+ICBJIHRoaW5rIHRo aXMgaXMgYSBwcmV0dHkgd2VpcmQgaWRlYS4gIEl0IHNlZW1zIGV4dHJlbWVseSBkaWZmaWN1bHQN Cj4gPiA+IHRvIGltcGxlbWVudCwgYW5kIHRoZSB1c2UgY2FzZSBpcyBub3QgY2xlYXIgYXQgYWxs LiAgSW4gYW4NCj4gPiA+IGF1dG9tYXRpb24gZGVwbG95bWVudCwgZG8gd2UgZXhwZWN0IHRoYXQg dGhlIGNsaWVudCBhcHBsaWNhdGlvbiBjb2RlDQo+ID4gPiBjb250YWlucyBsb2dpYyB0byByZXdy aXRlIGl0c2VsZiB0byBzZW5kIHByb3BlciByZXF1ZXN0cyB0aGUgbmV4dA0KPiA+ID4gIHRpbWU/ ICAgSWYgaXQgaXMgZm9yIGRlYnVnZ2luZyBwdXJwb3NlcyBJIHRoaW5rIHRoaXMgc2hvdWxkIGJl IHVwIHRvDQo+ID4gPiAgaW1wbGVtZW50YXRpb25zIHRvIGZpZ3VyZSBvdXQuICBXZSBzaG91bGRu J3QgYWRkIHN1Y2ggdGhpbmdzIHRvDQo+ID4gPiBzdGFuZGFyZCBSUENzLg0KPiA+DQo+ID4gPGV2 PiB0aGVyZSBoYXMgYmVlbiBsb3RzIG9mIGRpc2N1c3Npb24gb24gdGhpcyBvbmUuICBUaGUgYmln Z2VzdCBpc3N1ZSBoYXMgYmVlbg0KPiB0aGF0IHRoZXJlIGFyZSBlbm91Z2ggdmFyaWF0aW9ucyBv ZiBwYXJhbWV0ZXJzIHdoZXJlIHRoZSBndWlkYW5jZSBvbiB3aGF0DQo+IG1pZ2h0IGJlIGFjY2Vw dGFibGUgaXMgdGhlIG9ubHkgd2F5IHRvIG1ha2Ugc29tZSBzY2VuYXJpb3Mgd29yay4gIChXYXMg aXQgdGhlDQo+IHBlcmlvZCB3aGljaCB3YXMgYSBwcm9ibGVtPyAgV2FzIGl0IHRoZSBjb21wbGV4 aXR5IG9mIHRoZSBmaWx0ZXI/KSAgT2J2aW91c2x5DQo+IHdlIGRvIG5lZWQgdG8gYm91bmQgd2hh dCBjb3VsZCBiZSBwcm92aWRlZCBiYWNrIHRvIHRoZSBzdWJzY3JpYmVyLg0KPg0KPiBTbyB0aGVu IHRoZSB0ZXh0IHNob3VsZCBlbmNvdXJhZ2UgaW1wbGVtZW50YXRpb25zIHRvIHByb3ZpZGUgZ29v ZCBlcnJvcg0KPiBtZXNzYWdlcy4NCg0KeWVzDQoNCj4gPiBUaGUgZ29vZCBuZXdzIGlzIHRoYXQg aWYgYSBwdWJsaXNoZXIgY2Fubm90IHN1cHBvcnQgbmVnb3RpYXRpb24sIGl0IGNhbiBqdXN0DQo+ IHNlbmQgYmFjayBhIGZhaWx1cmUuICBXaGljaCBpcyB3aHkgdGhlIHJlcXVpcmVtZW50IGlzIG9u bHkgYSBTSE9VTEQuDQo+DQo+IFNIT1VMRCBpcyB0b28gc3Ryb25nLiAgQW5kIGV2ZW4gc28sIHRo aXMganVzdCBhZGRzIGNvbXBsZXhpdHkgdG8gdGhlDQo+IHNwZWNpZmljYXRpb24uICBJIHRoaW5r IHRoaXMgc2hvdWxkIGJlIHJlbW92ZWQuDQoNClJGQzc5MjMgaGFzIGl0IGFzIGEgTVVTVCAoc2Vl IHNlY3Rpb24gNC4yLjIuKSAgR29pbmcgdG8gU0hPVUxEIGlzIGFscmVhZHkgZWFzaW5nIG9mZiB0 aGUgcmVxdWlyZW1lbnQuDQoNCj4gPiBBIHdvcnNlIG91dGNvbWUgd291bGQgYmUgaWYgYSBTdWJz Y3JpYmVyIGtlcHQgZ3Vlc3NpbmcgYXQgYWNjZXB0YWJsZQ0KPiBwYXJhbWV0ZXJzIGFuZCBwb3Vu ZGluZyB0aGUgUHVibGlzaGVyIHdpdGggbG9hZCBvbiB0aGlzLiAgVGhpcyB3b3VsZCB0YWtlDQo+ IG1vcmUgcmVzb3VyY2VzIHRoYW4gcHJvdmlkaW5nIGhpbnRzLg0KPg0KPiBUaGF0IHdvdWxkIGFs c28gYmUgcXVpdGUgd2VpcmQuICBCdXQgSSBjYW4ndCBpbWFnaW5lIGEgdXNlIGNhc2Ugd2hlcmUg YSBjbGllbnQNCj4gbmVlZHMgYSBjZXJ0YWluIGNvbWJpbmF0aW9uIG9mIHBhcmFtZXRlcnMsIHRo ZSBzZXJ2ZXIgcmVqY2V0cyB0aGVtIGJ1dCBzdWdnZXN0DQo+IHNvbWUgb3RoZXIgcGFyYW1ldGVy cyB0aGF0IHdpbGwgZ2l2ZSB0aGUgc2FtZSByZXN1bHQsIGFuZCB0aGVuIHRoZSBjbGllbnQNCj4g d291bGQgdXNlIHRoZW0/ICBPciB3b3JzZSwgdGhlIHNlcnZlciBzdWdnZXN0IHNvbWV0aGluZyB0 aGF0IGdpdmVzIGFub3RoZXINCj4gcmVzdWx0IGFuZCB0aGUgY2xpZW50IHNvbWVob3cgYWRqdXN0 IHRvIHRoZW0/DQoNCldoZW4gYSBzdWJzY3JpcHRpb24gaXMgcmVqZWN0ZWQsIHdlIGNhbiBwcm92 aWRlIGEgaGludCBhdCB3aHkuICBUaGlzIGlzIGEgbmV3IGRhbXBlbmluZyBwZXJpb2QsIGEgc3Vn Z2VzdGlvbiB0byB1c2Ugb24tY2hhbmdlLCBldGMuICBXaXRob3V0IHRoaXMgaGludCwgYSBzdWJz Y3JpYmVyIGNvdWxkIGp1c3Qga2VlcCBndWVzc2luZyBhdCBwYXJhbWV0ZXJzIHdpdGhvdXQgZ3Vp ZGFuY2UuICBUaGF0IGlzIGFsbCBuZWdvdGlhdGlvbiBpcy4NCg0KPiA+ID5vICBTZWN0aW9uIDYN Cj4gPiA+DQo+ID4gPiAgVGhlIHRleHQgc2F5czoNCj4gPiA+DQo+ID4gPiAgIFRoZSBldmVudCBu b3RpZmljYXRpb25zIG11c3QgYWxzbyBpbmNsdWRlIHRoZSBzdWJzY3JpcHRpb24taWQgaWYgdGhl DQo+ID4gPiAgIGVzdGFibGlzaC1zdWJzY3JpcHRpb24gd2FzIHVzZWQgaW4gaXRzIGVzdGFibGlz aG1lbnQsIG9yIGlmIGl0IHdhcw0KPiA+ID4gICBjb25maWd1cmVkIHZpYSBhbiBvcGVyYXRpb25h bCBpbnRlcmZhY2UuDQo+ID4gPg0KPiA+ID4gIEhvdyBpcyB0aGlzICJzdWNic2NyaXB0aW9uLWlk IiBzdXBwb3NlZCB0byBiZSBpbmNsdWRlZD8gIFdoZXJlPw0KPiA+ID4gIFRoZXJlIGlzIG5vIHN1 Y2ggZmllbGQgZGVmaW5lZCBpbiBhIDxub3RpZmljYXRpb24+Lg0KPiA+DQo+ID4gPGV2PiBVbmxp a2UgeWFuZy1wdXNoLCB0aGUgTm90aWZpY2F0aW9uIGV2ZW50cyBhcmUgbm90IHNwZWNpZmllZCB2 aWEgdGhlDQo+IGRvY3VtZW50LiAgIFRoZSBleGFtcGxlcyBmb2xsb3dpbmcgdGhlIHJlcXVpcmVt ZW50IGRvIG5vdCBpbmNsdWRlIGENCj4gc3Vic2NyaXB0aW9uLWlkIHdoZW4gdGhleSBhYnNvbHV0 ZWx5IHNob3VsZC4gIChBbmQgdGhpcyBwcm92ZXMgdGhlIHBvaW50IHRoYXQNCj4gdGhlc2UgYXJl IG5lZWRlZCA6LSkuICAgV2Ugd2lsbCB1cGRhdGUgdGhlIGV4YW1wbGVzLg0KPg0KPiBXZWxsLCBl eGFtcGxlcyBhcmUgZ29vZCwgYnV0IHlvdSBhbHNvIG5lZWQgYSBub3JtYXRpdmUgZGVmaW5pdGlv bi4NCg0KV2lsbCBkby4NCg0KRXJpYw0KDQo+IC9tYXJ0aW4NCj4NCj4NCj4gPg0KPiA+IFRoYW5r cyBhZ2FpbiwNCj4gPiBFcmljDQoNCg0KDQo= --_000_0ff12bf034b549e1b5f6ebab4596917dXCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTYzNzUzMzM5NjU4MDE4 MzE1MTFtc29saXN0cGFyYWdyYXBoLCBsaS5tNjM3NTMzMzk2NTgwMTgzMTUxMW1zb2xpc3RwYXJh Z3JhcGgsIGRpdi5tNjM3NTMzMzk2NTgwMTgzMTUxMW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLW5hbWU6bV82Mzc1MzMzOTY1ODAxODMxNTExbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTYzNzUzMzM5NjU4MDE4MzE1MTFt LTUzNTE0MjYzNDY5MDE5NjM5NzRtc29saXN0cGFyYWdyYXBoLCBsaS5tNjM3NTMzMzk2NTgwMTgz MTUxMW0tNTM1MTQyNjM0NjkwMTk2Mzk3NG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tNjM3NTMzMzk2 NTgwMTgzMTUxMW0tNTM1MTQyNjM0NjkwMTk2Mzk3NG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLW5hbWU6bV82Mzc1MzMzOTY1ODAxODMxNTExbS01MzUxNDI2MzQ2OTAxOTYzOTc0bXNvbGlz dHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIEFu ZHksIHRoaXMgbWFrZXMgc2Vuc2UuJm5ic3A7IFdpbGxpbmcgdG8gd2FsayB0aHJvdWdoIGl0IG9m IG90aGVycyBvbiB0aGUgV2VkIHN1YnNjcmlwdGlvbnMgY2FsbD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4sIERlY2VtYmVyIDksIDIwMTYgNjo1MSBQTTxicj4N Cjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBG cmksIERlYyA5LCAyMDE2IGF0IDM6MzAgUE0sIEVyaWMgVm9pdCAoZXZvaXQpICZsdDs8YSBocmVm PSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXZvaXRAY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I aSBBbmR5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo ZSBpcyBhIGxvdCBpbnRlcmVzdGluZyBpbiB5b3VyIGZpbHRlci55YW5nIGZpbGUuJm5ic3A7IElm IHRoZSBXRyBkZXNpcmVzIHRvIGdvIGJleW9uZCB0aGUgZXhpc3Rpbmcgc3VidHJlZQ0KIGZpbHRl cmluZyAmYW1wOyB4cGF0aCBtZWNoYW5pc21zLCB3ZSBzaG91bGQgZGV0ZXJtaW5lIGlmIHdlIGNh biB1c2UgdGhpcyBhcyBhIGJhc2UuJm5ic3A7IEJ1dCBpZiB3ZSBnbyBkb3duIHRoaXMgcGF0aCBp dCB3aWxsIHRha2Ugc29tZSB0aW1lIHRvIGdldCB0aGlzIHJpZ2h0LiZuYnNwOyBBbmQgaWYgd2Ug ZG8gdGhpcywgd2Ugc2hvdWxkIHN0cnVjdHVyZSBhbGwgZHJhZnRzIHNvIHRoYXQgZmlsdGVycyBj YW4gYmUgZXh0ZW5kZWQgb3ZlciB0aW1lIHdpdGhvdXQgbmVlZGluZw0KIHRvIG1vcnBoIHRoZSBz dWJzY3JpcHRpb25zIGRyYWZ0cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5NeSBpbml0aWFsIHRha2Ugb24gdGhpcyBpcyB0aGF0IGlmIHdlIGNob29zZSB0 byBwdXJzdWUgZmlsdGVyLnlhbmcsIGxhbmRpbmcgZmlsdGVycy55YW5nIGFzIGEgc2VwYXJhdGUN CiBtb2RlbC9kcmFmdCBtYWtlcyBzZW5zZS4mbmJzcDsgUHV0IHNpbXBseSwgZmlsdGVycyBuZWVk IG5vdCBiZSBzdWJzY3JpcHRpb24gc3BlY2lmaWMuJm5ic3A7ICZuYnNwO0luIGZhY3QsIGhhdmlu ZyBwcmVkZWZpbmVkLCBkZWNvdXBsZWQgZmlsdGVycyBvbiBkZXZpY2UgZXZlbiBmb3IgYSBub3Jt YWwgR0VUIGNhbiBnbyBhIGxvbmcgd2F5IHRvIGVuc3VyaW5nIHRoYXQgYW55IHNwZWNpZmljIGZp bHRlciBoYXMgYmVlbiBwcmVxdWFsaWZpZWQgYXMgbm90IGJlaW5nIHJlc291cmNlLXByb2hpYml0 aXZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIHdvdWxkIGxpa2UgdG8gdXNlIHRoaXMgYXBwcm9hY2ggZm9yICZsdDtnZXQtY29uZmlnJmd0 OyBhbmQgJmx0O2dldCZndDsgZmlsdGVyaW5nLCBub3QganVzdCBub3RpZmljYXRpb25zLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBjb25j ZXJuIHdpdGggdGhlIGNob2ljZS1zdG10IGFwcHJvYWNoIGlzIHRoYXQgZmlsdGVycyB3aWxsIG5v dCByZWFsbHkgYmUgc2hhcmVkIG9yIGVhc3kgdG8gd3JpdGUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIG5hbWVkIGZpbHRlciBwYXJ0cyB0 aGF0IGFyZSBjb21iaW5lZCBpbiBhIGEgZmlsdGVyIGV4cHJlc3Npb24sIHRoZSBzZXJ2ZXIgY2Fu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vcHRp bWl6ZSB0aGUgZmlsdGVyIHByb2Nlc3NpbmcuJm5ic3A7IEVhY2ggZmlsdGVyIHBhcnQgbmVlZHMg dG8gYmUgZXZhbHVhdGVkIGF0IG1vc3Qgb25jZSBwZXIgbm90aWZpY2F0aW9uLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bm8gbWF0dGVyIGhvdyBt YW55IHN1YnNjcmlwdGlvbnMgYXJlIGFjdGl2ZSBhdCBvbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBqdXN0IGEgZnJhbWV3b3Jr LCB2ZXJ5IHNpbWlsYXIgdG8gdGhlIGludGVyZmFjZXMgdGFibGUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Vc2luZyBZQU5HIGlkZW50aXRpZXMg dG8gc3BlY2lmeSB0aGUgZmlsdGVyIHR5cGUgYWxsb3dzIGV4dGVuc2lvbnM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpdGhvdXQgdXBkYXRpbmcg YW55IG90aGVyIGRvY3VtZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgYSBnZW5lcmFsIHByb2JsZW0gd2l0aCBpZGVudGl0 aWVzIHRoYXQgYWxzbyBhZmZlY3RzIGZpbHRlci55YW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBiZWNhdXNlIGEgc2VydmVyIGFkdmVy dGlzZXMgYSBZQU5HIG1vZHVsZSB3aXRoIGlkZW50aXRpZXMgaW4gaXQgZG9lcyBub3Q8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1lYW4gZXZlcnkg aWRlbnRpdHkgaXMgc3VwcG9ydGVkLiZuYnNwOyBBIGZpbHRlci1jYXBhYmlsaXRpZXMgdGFibGUg aXMgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SU1PIHRoZXJlIHNob3VsZCBiZSBhIGNvbW1vbiBzb2x1dGlvbiBmb3IgaWRlbnRpdGll cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNv IGhvdyBtaWdodCB3ZSBpbnRlZ3JhdGUgc3Vic2NyaXB0aW9ucyBhbmQgZmlsdGVycy55YW5nPzoN Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0gZm9yIHBlcnNpc3RlbnQgZmlsdGVycyB0aGF0IGFyZSBp bmRlcGVuZGVudCBvZiB0aGUgc3Vic2NyaXB0aW9uIGxpZmVjeWNsZTogdGhlIHN1YnNjcmlwdGlv buKAmXMgZmlsdGVyLXJlZg0KIGNhbiBwb2ludCB0byBhIHN0YW5kLWFsb25lIHlhbmcgZmlsdGVy IG1vZGVsIGluIGFuIGltcG9ydGVkIGZpbHRlci55YW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LSBm b3IgZmlsdGVycyB3aGljaCBzaG91bGQgb25seSBleGlzdCBhcyBwYXJ0IG9mIHRoZSBsaWZlY3lj bGUgb2YgYSBzdWJzY3JpcHRpb246IHBlcmhhcHMgZG8gYSBzY2hlbWENCiBtb3VudCBvZiBmaWx0 ZXIueWFuZz8gVGhlIG1vdW50ZWQgc2NoZW1hIGNhbiBiZSB1c2VkIHRvIGFjY2VwdCBpbnB1dCBm cm9tIGFuIFJQQyBhbmQgc3RvcmUgaXQgYXMgYSB0cmFuc2llbnQgaW4tbGluZSBmaWx0ZXIuJm5i c3A7IEkuZS4sIHRoaXMgd2F5IHRoZSBjb250ZW50cyBvZiB0aGUgaW5saW5lIGZpbHRlcnMgd2ls bCBub3QgcGVyc2lzdCBsb25nZXIgdGhhbiB0aGUgc3Vic2NyaXB0aW9uLiZuYnNwOyAoSXMgdGhl cmUgYSB3YXkgdG8gZG8gdGhpcyB3aXRoDQogZ3JvdXBpbmdzL2F1Z21lbnRhdGlvbnMgc28gdGhh dCBzY2hlbWEgbW91bnQgaXNu4oCZdCBuZWVkZWQ/KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgc3VzcGVjdCBieSBhcHByb2FjaGluZyB0aGUgaW50ZWdy YXRpb24gaW4gdGhpcyB3YXksIGl0IGlzIHBvc3NpYmxlIHRvIGV2b2x2ZSBmaWx0ZXIueWFuZyB3 aXRob3V0DQogZGlyZWN0bHkgY2hhbmdpbmcgdGhlIHN1YnNjcmlwdGlvbiBtb2RlbC4mbmJzcDsg KFRoZSBvbmx5IHRoaW5nIHdvdWxkIGJlIHRoYXQgeW91IGhhdmUgdG8gcmV2IGlzIHRvIGEgbmV3 IG1vZGVsIHZlcnNpb24uKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkJleW9uZCB0aGlzIGludGVncmF0aW9uIHNwZWN1bGF0aW9uLCBiZWxvdyBhcmUgc29t ZSB0aG91Z2h0cyBvbiBzcGVjaWZpYyBlbGVtZW50cyBvZiB5b3VyIOKAnGZpbHRlcnMueWFuZ+KA mQ0KIGF0dGFjaG1lbnQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im02Mzc1MzMz OTY1ODAxODMxNTExbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPsK3PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkxpbmUg Mjk6IGlmLWZlYXR1cmUtc3RtdC1zdHIgc2hvdWxkIGJlIGlmLWZlYXR1cmUtc3RtdCwgY29ycmVj dD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bm8gLS0gdGhhdCBBQk5GIGlzIGZvciBpZi1m ZWF0dXJlICZsdDtleHByJmd0Oy4mbmJzcDsgSSB3YW50ZWQganVzdCB0aGUgJmx0O2V4cHImZ3Q7 IHBhcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Im02Mzc1MzMzOTY1ODAxODMxNTExbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0Qi PsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkxpbmUgNDE6IGlmLWZpbHRlci1mYWN0b3Igc2hvdWxkIGJlIGZpbHRl ci1mYWN0b3IsIGNvcnJlY3Q/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnByb2JhYmx5IC0t IHdpbGwgZml4PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJtNjM3NTMzMzk2NTgwMTgzMTUxMW1zb2xpc3RwYXJhZ3JhcGgi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjoj MUY0OTdEIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5MaW5lIDU2OiBtaXhlZCBtZXRhcGhvciBvZiBhL2IvYyBh bmQgMS8yLzMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9rIC0tIHdpbGwgZml4PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Im02Mzc1MzMzOTY1ODAxODMxNTExbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPsK3PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkxpbmUgMjA6IHdlIGxpa2VseSBuZWVkIGFuIGlkZW50aXR5IGZvciBhIHN0cmVhbSBzbyB0 aGF0IGl0IGNhbiBiZSB1c2VkIGFzIGEgZmlsdGVyLXRlcm08L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+YWdyZWVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Im02Mzc1MzMzOTY1ODAxODMxNTExbXNvbGlzdHBhcmFncmFwaCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMx RjQ5N0QiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBzZXQgb2Ygb3BlcmF0b3JzIGlzIOKAmGFuZOKAmSwg 4oCYb3LigJkuJm5ic3A7IFRoZXJlIGlzIGFsc28gZmFjdG9yaW5nIHdpdGgg4oCYKOKAmCBhbmQg 4oCYKeKAmS4mbmJzcDsgQnV0IHRoZSBtYWpvcml0eSBvZiB4cGF0aCBvcGVyYXRvcnMgYW5kIHN5 bnRheCBpcyBub3QgaW5jbHVkZWQuJm5ic3A7IFdoaWNoIGlzIGEgZ29vZCB0aGluZy4mbmJzcDsg QXMNCiBmaWx0ZXJzIGFyZSBub3QgbmVjZXNzYXJpbHkgYm9vbGVhbiBpdCBtaWdodCBiZSBpbnRl cmVzdGluZyB0byBmaWd1cmUgb3V0IHdoYXQgb3RoZXIgZWxlbWVudHMgbWlnaHQgYmUgbmVlZGVk LiZuYnNwOyBUaGlzIHdpbGwgdGFrZSBzb21lIHRpbWUgdG8gZG8gcmlnaHQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIGlmLWZlYXR1cmUgc3ludGF4IGlzIGdvb2QgZW5v dWdoLiZuYnNwOyBSZXN0cmljdGVkIFhQYXRoIGlzIHRvbyBtdWNoLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YW50ZWQgdG8gYXZvaWQgdHlw ZXMgYW5kIHR5cGUgY29udmVyc2lvbiBhbmQgZmxvYXRpbmcgcG9pbnQsIGV0Yy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IChmaWx0 ZXItMSBhbmQgZmlsdGVyLTIgYW5kIG5vdCBmaWx0ZXItMyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlc2UgYXJlIHZlcnkgZWFzeSBzdHJp bmdzIHRvIGNvbnN0cnVjdCBieSBoYW5kIG9yIGJ5IHByb2dyYW0uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZ2VuZXJhbCB0ZW1wbGF0ZSBv ZiB0aGUgZmlsdGVyIG5lZWRzIGEgYml0IG9mIHdvcmssIHN1Y2ggYXM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRlZmluaW5nIHRoZSByZXF1aXJl bWVudHMgZm9yIGEgZmlsdGVyIGRlZmluaXRpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAtIHdoaWNoIGNvbnRleHRzIHRoZSBm aWx0ZXIgY2FuIGJlIHVzZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAtIGRvY3VtZW50IHJvb3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAtIGNvbnRleHQgbm9kZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0g ZXZhbHVhdGlvbiBwcm9jZWR1cmVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIHVwIHRvIGVhY2ggZmlsdGVyIGRlZmluaXRpb24gdG8g ZGVzY3JpYmUgaG93IHRoZSAmcXVvdDt0cnVlIG9yIGZhbHNlJnF1b3Q7IHJldHVybiB2YWx1ZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXMgZGVy aXZlZC4mbmJzcDsgVGhhdCBpcyBhbGwgdGhhdCBtYXR0ZXJzIHRvIHRoZSBmaWx0ZXIgZW5naW5l LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Im02Mzc1MzMzOTY1ODAxODMxNTExbXNvbGlzdHBhcmFncmFwaCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5 N0QiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gbm90IGNhdGNoaW5nIGFsbCB0aGUgc3VidGx0aWVzIGhl cmUuJm5ic3A7IENvdWxkIHlvdSByZXZpZXcgdGhpcyBvbiB0aGUgbmV4dCBEZXppZ24gdGVhbSBj YWxsPyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im02Mzc1 MzMzOTY1ODAxODMxNTExbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPsK3PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldl IHByb2JhYmx5IGRpc2N1c3Mgd2hldGhlciB3ZSB3YW50IHRvIGxpbWl0IHRoZSBhbGxvd2FibGUg YW1vdW50IG9mIG5lc3Rpbmcgd2l0aGluIHRoZSBmaWx0ZXJpbmcgc3ludGF4LiZuYnNwOyBSRkMg NTI3NyBkaWRu4oCZdCBkbyBzdWNoIGxpbWl0aW5nLiZuYnNwOyBBbmQgd2l0aG91dCBrbm93aW5n IHRoZSBhIGRlc2lyZWQNCiBmaWx0ZXIgY3JpdGVyaWEgd2hpY2ggY2FuIGJlIGFwcGxpZWQgYWdh aW5zdCByYW5kb20gY29sbGVjdGlvbnMgb2Ygb2JqZWN0cywgSSBzdWdnZXN0IHdlIGRvbuKAmXQg YXR0ZW1wdCB0aGlzIGVpdGhlci4mbmJzcDsgUGVyaGFwcyBzb21lb25lIGluIHRoZSBmdXR1cmUg Y2FuIGRlZmluZSBhIG1pbmltYWwgc2V0IG9mIG5lc3Rpbmcgd2hpY2ggbXVzdCBiZSBzdXBwb3J0 ZWQgaWYgc29tZW9uZSBkZXNpcmVzIGZvciB0aGUgZmlsdGVycyB0aGVtc2VsdmVzIHRvDQogYmUg cG9ydGFibGUgYWNyb3NzIGltcGxlbWVudGF0aW9ucy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Im02Mzc1MzMzOTY1ODAxODMxNTExbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPsK3 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkZvciB0aGUgaWRlbnRpdHkgbmV0Y29uZi1zdHJlYW0sIHlvdSByZWZlciB0 byBSRkM1Mjc3IHNlYyAzLjIuJm5ic3A7IElmIHRoaXMgaXMgYmVpbmcgb2Jzb2xldGVkLCBkbyB3 ZSBuZWVkIGFub3RoZXIgZGVmaW5pdGlvbiBzb3VyY2U/IChBcyB0aGUg4oCYb2Jzb2xldGXigJkg ZGlzY3Vzc2lvbiBoYXBwZW5lZCBhZnRlcg0KIHlvdSB3cm90ZSB0aGUgZmlsdGVyLnlhbmcsIHBl cmhhcHMgdGhpcyBjYW4ganVzdCBiZSByZW1vdmVkIGlmIHdlIGdvIHRvIOKAmG9ic29sZXRl4oCZ Pyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Bbnl3YXkg dGhlcmUgaXMgdGhlIHN0YXJ0ZXIgdGhpbmtpbmcgSSBwcm9taXNlZC4mbmJzcDsgTGV04oCZcyBj aGF0IG1vcmUgaWYgeW91IGFyZSB3aWxsaW5nIHRvIHJldmlldyB0aGlzDQogb24gdGhlIFdlZCBj YWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVyaWM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gQW5keSBCaWVybWFuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFuZHlA eXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDEsIDIwMTYgMTo0MSBQTTxicj4N CjxiPlRvOjwvYj4gRXJpYyBWb2l0IChldm9pdCkgJmx0OzxhIGhyZWY9Im1haWx0bzpldm9pdEBj aXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5ldm9pdEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxi PkNjOjwvYj4gQmFsYXpzIExlbmd5ZWwgJmx0OzxhIGhyZWY9Im1haWx0bzpiYWxhenMubGVuZ3ll bEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5iYWxhenMubGVuZ3llbEBlcmljc3Nvbi5j b208L2E+Jmd0OyAoPGEgaHJlZj0ibWFpbHRvOmJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTwvYT4pICZsdDs8YSBo cmVmPSJtYWlsdG86YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86YWxl eEBjbGVtbS5vcmciIHRhcmdldD0iX2JsYW5rIj5hbGV4QGNsZW1tLm9yZzwvYT47IE1hcnRpbiBC am9ya2x1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1iakB0YWlsLWYuY29tPC9hPiZndDs7IEFsYmVydG8gR29uemFsZXogUHJpZXRvIChhbGJl cnRnbykgJmx0OzxhIGhyZWY9Im1haWx0bzphbGJlcnRnb0BjaXNjby5jb20iIHRhcmdldD0iX2Js YW5rIj5hbGJlcnRnb0BjaXNjby5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpuZXRjb25m QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSByZXZpZXcgb2YgJnF1b3Q7ZXZlbnQtbm90aWZpY2F0 aW9uJnF1b3Q7IGRvY3VtZW50czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSB3b3JrZWQgb24gdGhlIGZpbHRlcmluZyBwcm9ibGVtIGEgYml0 IG1vcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkhlcmUgaXMgZmlsdGVyLnlhbmcsIGEgZmlsdGVyaW5nIGZyYW1ld29yaywgYW5kIHRvcGlj LnlhbmcsIGFuZCBleGFtcGxlIG9mIGEgZmlsdGVyIHR5cGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGhhdCBjYW4gYmUgdXNlZCBpbiBmaWx0 ZXIueWFuZy4gVG9waWMtYmFzZWQgZmlsdGVyaW5nIHdhcyBicmllZmx5IGRpc2N1c3NlZCBpbiBT ZW91bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPklNTyBmaWx0ZXJzIHdpbGwgY29udGludWUgdG8gZXZvbHZlIG92ZXIgdGltZSBzbyB0 aGUgc29sdXRpb24gbmVlZHMgdG8gYWxsb3c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGhlbSB0byBiZSBhZGRlZCBhbmQgY29tYmluZWQgd2l0 aCBvdGhlciBmaWx0ZXJzLiZuYnNwOyBUaGUgY3VycmVudCBZQU5HIGNob2ljZS1zdG10PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmlzIG5vdCBl eHRlbnNpYmxlIGVub3VnaCBvciBwb3dlcmZ1bCBlbm91Z2guPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5keTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1 ZSwgTm92IDI5LCAyMDE2IGF0IDc6MTEgUE0sIEVyaWMgVm9pdCAoZXZvaXQpICZsdDs8YSBocmVm PSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXZvaXRAY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4sIE5vdmVtYmVy IDI5LCAyMDE2IDg6MzANCiBQTTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgTm92IDI5LCAyMDE2IGF0IDg6MDUgQU0sIEVyaWMgVm9p dCAoZXZvaXQpICZsdDs8YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+ZXZvaXRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+VGhhbmtzIE1hcnRpbiw8YnI+DQo8YnI+DQpNb3JlIGluIGxpbmUuJm5ic3A7ICZuYnNw O0Fsc28gSSBleHRyYWN0ZWQgYXJlYXMgd2hlcmUgd2UgYWxyZWFkeSBhZ3JlZSB0byBtYWtlIHRo aXMgZWFzaWVyIHRvIGZvbGxvdy48YnI+DQo8YnI+DQomZ3Q7IEZyb206IE1hcnRpbiBCam9ya2x1 bmQsIE5vdmVtYmVyIDI5LCAyMDE2IDY6NDAgQU08YnI+DQomZ3Q7ICZndDsgJmd0O0lmIEkgdW5k ZXJzdGFuZCB0aGUgaW50ZW50aW9uIGNvcnJlY3RseSwgdGhpcyBkb2N1bWVudCBpcyBzdXBwb3Nl ZCB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7KmRlZmluZSogaG93IG5vdGlmaWNhdGlvbnMgYXJlIHNl bnQgb3ZlciBORVRDT05GLiZuYnNwOyBCdXQgdGhlcmUgaXMgbm88YnI+DQomZ3Q7ICZndDsgJmd0 O3N1Y2ggZGVmaW5pdGlvbiBpbiB0aGlzIGRvY3VtZW50LiZuYnNwOyBJbnN0ZWFkIGl0IHNpbXBs eSByZXBlYXRzPGJyPg0KJmd0OyAmZ3Q7ICZndDtpbmZvcm1hdGlvbiBhbHJlYWR5IGRlZmluZWQg aW4gZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzUyNzdiaXMtMDEudHh0LDxicj4NCiZndDsgJmd0OyAm Z3Q7YW5kIHByb3ZpZGVzIGxvdHMgb2YgZXhhbXBsZXMgb2YgaG93IHRoZSBZQU5HIG9wZXJhdGlv bnMgZGVmaW5lZCBpbjxicj4NCiZndDsgJmd0OyAmZ3Q7cmZjNTI3N2JpcyBhcmUgZW5jb2RlZCBp biBYTUwgYW5kIHNlbnQgb3ZlciBORVRDT05GLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDtJIHN1Z2dlc3QgdGhhdCB0aGlzIGRvY3VtZW50IGlzIHJld3JpdHRlbi4mbmJz cDsgU2luY2UgdGhlIGlkZWEgaXMgdG88YnI+DQomZ3Q7ICZndDsgJmd0O3JlcGxhY2UgUkZDIDUy NzcsIGl0IG5lZWRzIHRvIGZvY3VzIG9uIGhvdyBub3RpZmljYXRpb25zIGFyZSBzZW50PGJyPg0K Jmd0OyAmZ3Q7ICZndDtvdmVyIE5FVENPTkYsIGFuZCBub3QgaG93IFJQQ3MgYXJlIGVuY29kZWQg aW4gWE1MLjxicj4NCiZndDsgJmd0OyBJIGFncmVlIC0tIG1heWJlIGdldCByaWQgb2YgaXQgYW5k IGp1c3QgaGF2ZSByZmM1Mjc3YmlzIGNvbnRhaW4gdGhpczxicj4NCiZndDsgJmd0OyB0ZXh0PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZsdDtldiZndDsgNTI3N2JpcyBpcyBzdXBwb3Nl ZCB0byBhbGxvdyB0cmFuc3BvcnRzIG90aGVyIHRoYW4gTkVUQ09ORi4mbmJzcDsgSWYgd2UgcHV0 PGJyPg0KJmd0OyB0aGUgTkVUQ09ORiBzcGVjaWZpYyBzdHVmZiBpbiBoZXJlIHdlIGxvc2UgdGhh dCBzZXBhcmF0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIG5lZWQgKnNvbWUqIGRvY3VtZW50 IHRoYXQgZGVmaW5lcyBob3cgbm90aWZpY2F0aW9ucyBhcmUgc2VudCBvdmVyPGJyPg0KJmd0OyBO RVRDT05GLiZuYnNwOyBUaGlzIGRvY3VtZW50IG5lZWRzIHRvIGhhdmUgdGhlIHNwZWNpZmljYXRp b24gZm9yIHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0Ozxicj4NCiZndDsgZWxlbWVudC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBUaGVuIHdlIG5lZWQgYSBwcm90b2NvbC1pbmRlcGVuZGVudCBkb2N1bWVu dCB0aGF0IGRlZmluZXMgdGhlIGNvbmNlcHQgb2Y8YnI+DQomZ3Q7IHN0cmVhbXMgYW5kIHN1YnNj cmlwdGlvbnMsIHN0cmVhbSBkaXNjb3ZlcnksIGV0Yy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJICp0 aGluayogdGhhdCB5b3VyIGludGVudGlvbiBpcyB0aGF0IG5ldyBjbGllbnRzIHJlYWxseSBzaG91 bGQgYmUgdXNpbmc8YnI+DQomZ3Q7ICZsdDtlc3RhYmxpc2gtc3Vic2NyaXB0aW9uJmd0OyBpbnN0 ZWFkIG9mICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0Oywgc2luY2UgaXQgaXMgcHJvdG9jb2wt PGJyPg0KJmd0OyBpbmRlcGVuZGVudCBhbmQgc3VwcG9ydCBtb2RpZmljYXRpb24gYW5kIGRlbGV0 aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHdlIGFsc28gd2FudCB0byBiZSBmdWxseSBiYWNr d2FyZHMgY29tcGF0aWJsZSB3aXRoIDUyNzcsIEkgdGhpbmsgd2Ugc2hvdWxkPGJyPg0KJmd0OyBj cmVhdGUgYSBkb2N1bWVudCB0aGF0IGlzIG11Y2ggY2xvc2VyIHRvIHRoZSBjdXJyZW50IDUyNzcg LSBlc3NlbnRpYWxseSBqdXN0PGJyPg0KJmd0OyBjcmVhdGluZyBhIFlBTkcgbW9kZWwgZm9yIHRo ZSBjb25maWcgZmFsc2UgZGF0YSBhbmQgZm9yIHRoZSAmcXVvdDtvbGQmcXVvdDsgJmx0O2NyZWF0 ZS08YnI+DQomZ3Q7IHN1YnNjcmlwdGlvbiZndDsuPGJyPg0KPGJyPg0KV2UgYWJzb2x1dGVseSB3 YW50IHRvIGhhdmUgYSBmdWxsIGJhY2t3YXJkcyBjb21wYXRpYmxlIGNhcGFiaWxpdHkuJm5ic3A7 IFRoZSBxdWVzdGlvbiBpcyBob3cgdG8gYmVzdCBmcmFtZSB0aGlzIGluIGRvY3VtZW50cy4mbmJz cDsgSXQgaXMgcG9zc2libGUgdG8gcmVidWlsZCBSRkMtNTI3NyB3aXRoIGEgWUFORyBtb2RlbC4m bmJzcDsgQnV0IHRoZW4geW91IGNhbid0IGp1c3QgbGF5ZXIgb24gbmV3IGNhcGFiaWxpdGllcyBk cml2aW5nIHRoaXMgd29yay4mbmJzcDsgKEFuZCB0aGlzDQogaXMgd2h5IHdlIG5lZWQgc2VwYXJh dGUgbmFtZXNwYWNlcy4pPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIG5lZWQgdG8gcGFyc2UgYW5kIHVuZGVyc3Rh bmQgJnF1b3Q7ZnVsbCBiYWNrd2FyZHMgY29tcGF0aWJsZSZxdW90Oy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRvIHdlIHdhbnQgZXhp c3RpbmcgaW1wbGVtZW50YXRpb25zIHRvIGJlIGxldmVyYWdlZCBpbnRvIHRoZSBuZXcgc29sdXRp b24/Jm5ic3A7IFllczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5BIHNlcnZlciBzaG91bGQgYmUgY2FwYWJsZSBvZiBzdXBwb3J0aW5nICZsdDtj cmVhdGUtc3Vic2NyaXB0aW9uJmd0OyBmb3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+b2xkLCBkZXByZWNhdGVkIHN1YnNjcmlwdGlvbnMsIGFu ZCAmbHQ7ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiZndDsgZm9yIHRoZSBuZXcgY3VycmVudCBzdWJz Y3JpcHRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+RG8gd2UgbmVlZCB0byB1cGRhdGUgUkZDIDUyNzcgb3IgcmVwbGFjZSBpdD8g SU1PLCByZXBsYWNlIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5TaW5jZSB0aGUgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IFJQQyB3 YXMgbmV2ZXIgaW4gYSBZQU5HIG1vZHVsZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aXQgY2FuIGJlIGxlZnQgb3V0IG9mIHRoZSBuZXcgbW9k dWxlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmx0O2V2 Jmd0OyBJIGJlbGlldmUgYXQgbWluaW11bSB0aGF0ICZsdDtjcmVhdGUgc3Vic2NyaXB0aW9uJmd0 OyBzaG91bGQgYmUgcHVsbGVkIG91dCBvZiB0aGUgbmV3IG1vZHVsZS4mbmJzcDsgSXQgbmVlZHMN CiBpdHMgc2VwYXJhdGUgbmFtZXNwYWNlLiZuYnNwOyAmbmJzcDtQZXJoYXBzIG5vYm9keSBpcyBy ZWFkeSB0byBhZHZvY2F0ZSBmb3IgYSBwYXJhbGxlbCA1Mjc3LWxlZ2FjeSBZQU5HIG1vZGVsIHNp bmNlIG5ldyBkZXZlbG9wbWVudCBzaG91bGQgZ28gdG8gdGhlIG5ldyBwYXJhZGlnbSBhbnl3YXku Jm5ic3A7IEluIHRoaXMgY2FzZSwgd2UgY291bGQganVzdCBoYXZlIGEgc3RhbmRhbG9uZSBsZWdh Y3kgNTI3NyBzZWN0aW9uIGluIHRoZSBkb2N1bWVudCBmb3IgYW55dGhpbmcNCiBuZWVkZWQuJm5i c3A7IFRoaXMgd291bGQgbWFrZSB0aGluZ3Mgc2ltcGxlciBhbmQgZWFzaWVyIHRvIHRlYXNlIGFw YXJ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkV2ZW4gbW9yZSByYWRpY2FsLCBJIHRoaW5rIHN0cmVhbXMgc2hvdWxkIGJl IHJlbW92ZWQsIGV2ZW4gdGhlIE5FVENPTkYgc3RyZWFtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGV5IHJlYWxseSBzZXJ2ZSBubyBwdXJw b3NlIG5vdyB0aGF0IHN1YnNjcmlwdGlvbnMgYXJlIGZvcm1hbGl6ZWQgYW5kIGNhbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ldmVuIGJlIGNv bmZpZ3VyZWQuJm5ic3A7IEl0IGlzIGFsc28gYmFkIGRlc2lnbiB0byBjb3VwbGUgdGhlIG91dHB1 dCBtZXNzYWdlIGVuY29kaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPmludG8gdGhlIGlucHV0IHN0cmVhbS4gKGUuZy4sIE5FVENPTkYgc3Ry ZWFtIE1VU1QgYmUgWE1MIGVuY29kZWQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmx0O2V2Jmd0OyBFdmVuIGFzIHdlIG1vdmUgYXdheSBmcm9t IHN0cmVhbXMsIEkgc3RpbGwgY2FuIHNlZSByZWFzb25zIGZvciBpdC4mbmJzcDsgKEFkZGluZyBC YWxhenMgJmFtcDsgQWxleCBhcyB0aGV5DQogaGF2ZSBiZWVuIHByb3BvbmVudHMuKSZuYnNwOyBU aGUgYmlnZ2VzdCByZWFzb24gZm9yIHN0cmVhbXMgaXMgdGhhdCBhIHJvYnVzdCBjdXN0b21lciBk ZXNpZ25lZCBmaWx0ZXJzIGFyZSBoYXJkLiZuYnNwOyBJZiBhIHZlbmRvci9jdXN0b21lci9ldGMu IGlzIGFibGUgdG8gcHJlLWZpbHRlciBub3RpZmljYXRpb25zIG9yIGRhdGFzdG9yZSBpbiBhbiBp bnRlcmVzdGluZyBhbmQgdXNlZnVsIHdheSBub3Qgc3VwcG9ydGFibGUgYnkgb3VyIGZpbHRlcmlu ZyBzZW1hbnRpY3MsDQogdGhpcyBpcyBhIGdvb2Qgd2F5IHRvIGFsbG93IHRoZSBwcmUtZmlsdGVy aW5nLiBTb21lIGV4YW1wbGVzIHdoaWNoIGNvdWxkIGJlIGludGVyZXN0aW5nOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtNjM3NTMzMzk2NTgwMTgzMTUxMW0tNTM1MTQyNjM0Njkw MTk2Mzk3NG1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FdmVudCBub3Rp ZmljYXRpb25zIHdoZW4gbmV3IGRldmljZXMgY29ubmVjdCB0byBhIG5ldHdvcms8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTYzNzUzMzM5NjU4MDE4MzE1MTFtLTUzNTE0MjYzNDY5 MDE5NjM5NzRtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWxhcm1zIHBv dGVudGlhbGx5IHNldCBhY3Jvc3MgbXVsdGlwbGUgWUFORyBtb2RlbHM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkN1cnJlbnRseSwgZmlsdGVycyBhcmUgZGVmaW5lZCBhcyBhIGNob2lj ZS1zdG10LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGlzIGltcGxpZWQgT1ItZXhwciBpcyB0b28gc2ltcGxpc3RpYy4gQW4gZXhwbGljaXQg Y29tYmluYXRpb24gb2YgT1IsIEFORCwgYW5kIE5PVCBpcyByZXF1aXJlZDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5mb3IgZGlmZmVyZW50IHR5 cGVzIG9mIGZpbHRlcnMuICZuYnNwOyhzaW1pbGFyIHRvIFlBTkcgMS4xIGlmLWZlYXR1cmUtc3Rt dCBzeW50YXgpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jmx0O2V2Jmd0OyBUb3RhbGx5IGFncmVlIHRoYXQgd2UgbmVlZCByb2J1c3QgZmlsdGVy cy4mbmJzcDsgRmlndXJpbmcgdGhpcyBwcm9ibGVtIHNwYWNlIG91dCBpcyBhIGZ1bGwgdGltZSBq b2IuJm5ic3A7DQogRmlndXJpbmcgb3V0IGhvdyB0byBlbmNvZGluZyBmaWx0ZXJpbmcgY2FwYWJp bGl0aWVzIHN1cHBvcnRlZCBvbiBkaWZmZXJlbnQgdHlwZXMgb2YgY29uc3RyYWluZWQgcGxhdGZv cm1zIGlzIG5vbi10cml2aWFsLiZuYnNwOyBJIHdvdWxkIGxvdmUgdG8gc2VlIHNvbWVvbmUgdGFr ZSB0aGlzIG9uIGZvciB0aGUgaW5kdXN0cnkuJm5ic3A7IEFueSB0YWtlcnM/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RXJpYzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZHk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgbGF5ZXJpbmcg dXBvbiBSRkMtNTI3NyBjYW5ub3QgZ2l2ZSB0aGUgbmV3IGNhcGFiaWxpdGllcyBiZWluZyByZXF1 ZXN0ZWQgb2YgdXMgaW4gcGxhY2VzIGxpa2UgUkZDLTc5MjMgKGUuZy4sIG11bHRpcGxlIHN1YnNj cmlwdGlvbnMvc2Vzc2lvbiksIHdlIGFyZSBtb3Zpbmcgbm93IHRvIHB1dCBhbGwgZWxlbWVudHMN CiBqdXN0IG5lZWRlZCBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgaW4gdGhlIG5ldGNvbmYg dHJhbnNwb3J0IGRyYWZ0LiZuYnNwOyBXZSBjb3VsZCBhbHNvIHNlcGFyYXRlIGFsbCB0aGlzIG91 dCBpbnRvIGFub3RoZXIgaW5kZXBlbmRlbnQgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgZXh0ZW5z aW9uLiZuYnNwOyBCdXQgd2UgZmVsdCB3ZSBoYWQgZW5vdWdoIGRyYWZ0cyBpbiBwcm9ncmVzcyB3 aGVyZSB3ZSBkaWRuJ3Qgd2FudC9uZWVkIGEgZmlmdGggb25lLjxicj4NCjxicj4NCiZndDsgJmd0 OyBbQUddIEZXSVcsIHRoZSBzY29wZSBvZiBlYWNoIGRvYyBpcyBzdW1tYXJpemVkIG9uPGJyPg0K Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L3Ns aWRlcy9zbGlkZXMtOTYtbmV0Y29uZi01LnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni1uZXRjb25mLTUucGRm PC9hPjxicj4NCiZndDsgJmd0OyAoc2xpZGU8YnI+DQomZ3Q7ICZndDsgIzUpPGJyPg0KJmd0OyAm Z3Q7IFtBR10gVGhlIGtleSBpcyB0aGF0IHRoZSBzcGVjIGZvciBOQyBjb21lcyBmcm9tIHRoZSB1 bmlvbiBvZiA1Mjc3LWJpczxicj4NCiZndDsgJmd0OyBhbmQgdGhlIE5DIHRyYW5zcG9ydCBkb2M8 YnI+DQomZ3Q7ICZndDsgKGRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNh dGlvbnMtMDEudHh0KSBUaGUgTkM8YnI+DQomZ3Q7ICZndDsgdHJhbnNwb3J0IGRvYyBpcyBub3Qg bWVhbnQgdG8gc3RhbmQgYWxvbmUuPGJyPg0KJmd0OyAmZ3Q7IFRoZSBkb2MgY29udGFpbnMgaG93 IDUyNzctYmlzIGNvbmNlcHRzIGFyZSByZWFsaXplZCB3aGVuIHVzaW5nIE5DIGFuZDxicj4NCiZn dDsgJmd0OyBOQy1zcGVjaWZpYyBhc3BlY3RzLiBFLmcuOjxicj4NCiZndDsgJmd0OyAtIHRoZSB1 c2Ugb2YgTkMgY2FsbC1ob21lIGZvciBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnM8YnI+DQomZ3Q7 ICZndDsgLSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDsgLSB0aGUgZXhpc3RlbmNlIG9mIGEgTkVUQ09ORiBzdHJlYW08YnI+DQomZ3Q7ICZndDsmbmJz cDsgJm5ic3A7IC0gc3VwcG9ydCBvZiAvbmV0Y29uZi9zdHJlYW1zPGJyPg0KJmd0OyAmZ3Q7ICZs dDtldiZndDsgWWVzLCBhbnkgNTI3N2JpcyB0b3BpYyBzcGVjaWZpYyB0byBvbmx5IE5FVENPTkYg dHJhbnNwb3J0IHNob3VsZDxicj4NCiZndDsgJmd0OyBiZSBpbiBuZXRjb25mLWV2ZW50LW5vdGlm aWNhdGlvbnM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBhZ3JlZSB3aXRoIE1hcnRp biB0aGF0IGR1cGxpY2F0aW5nIG5vcm1hdGl2ZSB0ZXh0IGlzIGJhZC48YnI+DQomZ3Q7ICZndDsg Tm90IGhhdmluZyBhbnkgbm9ybWF0aXZlIHRleHQgaXMgZXZlbiB3b3JzZS48YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmx0O2V2Jmd0OyAmIzQzOzEuJm5ic3A7IFRvIGhlbHAgYWRkcmVz cyB0aGF0LCBJIGp1c3QgYnVpbHQgYSB3aG9sZSBsaXN0IG9mIHBlbmRpbmcgY2hhbmdlczxicj4N CiZndDsgYWNyb3NzIHRoZSBmb3VyIGRyYWZ0cy4mbmJzcDsgQW5kIGluIHF1aXRlIGEgZmV3IHBs YWNlcyBJIHB1bGxlZCBvdXQgZHVwbGljYXRpdmUgdGV4dC48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgLSB0aGUgZGVmaW5pdGlvbiBvZiBjcmVhdGUtc3Vic2NyaXB0aW9uIG1heSBiZSBt b3ZlZCB0byB0aGlzIGRvYyBzbzxicj4NCiZndDsgJmd0OyB0aGF0IG90aGVyIHRyYW5zcG9ydHMg d291bGQgaWdub3JlIGNyZWF0ZS1zdWJzY3JpcHRpb24gYW5kIHVzZSBvbmx5PGJyPg0KJmd0OyAm Z3Q7IGVzdGFibGlzaC1zdWJzY3JpcHRpb24sIHNpbXBsaWZ5aW5nIHRoZSBzb2x1dGlvbjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGF0IHNlZW1zIHdyb25n IHNpbmNlIDUyNzcgaGFkIGNyZWF0ZS1zdWJzY3JpcHRpb24gc28gaXQgc2hvdWxkIHN0YXk8YnI+ DQomZ3Q7ICZndDsgaW4gNTI3N2Jpczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbHQ7 ZXYmZ3Q7IEl0IGlzIHJlYWxseSBhIHN0eWxlIHRoaW5nIHNvIGl0IGRvZXNu4oCZdCBtYXR0ZXIg dGhhdCBtdWNoIGVpdGhlciB3YXkuPGJyPg0KJmd0OyBDdXJyZW50IHRoaW5raW5nIGlzIHRoYXQg YXMgd2UgbmVlZCBib3RoIHRoZSBuZXcgYW5kIG9sZCBuYW1lc3BhY2VzLjxicj4NCiZndDsgVGhl cmVmb3JlIGl0IHNlZW1zIHNpbXBsZXIgdG8gaGF2ZSBhbnl0aGluZyBpbiB0aGUgb2xkIG5hbWVz cGFjZSAo4oCcY3JlYXRlLTxicj4NCiZndDsgc3Vic2NyaXB0aW9u4oCdKSBpbiBuZXRjb25mLWV2 ZW50LW5vdGlmaWNhdGlvbiBkcmFmdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGFncmVlIHdpdGgg QW5keSB0aGF0IGFueXRoaW5nIHRoYXQgY29tZXMgZnJvbSA1Mjc3IHRoYXQgeW91IG5lZWQgdG8g a2VlcDxicj4NCiZndDsgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHJlYXNvbnMgc2hvdWxk IGdvIGludG8gNTI3N2Jpcy48YnI+DQo8YnI+DQpSaWdodCBub3cgaXQgaXMgaW4gNTI3N2Jpcy4m bmJzcDsgQnV0IHdlIGFscmVhZHkgY2FuJ3QgaGF2ZSBldmVyeXRoaW5nIG5lZWRlZCBmb3IgYmFj a3dhcmRzIGNvbXBhdGliaWxpdHkgc2luY2UgdGhlIDUyNzdiaXMgaXMgdHJhbnNwb3J0IChORVRD T05GKSBpbmRlcGVuZGVudC4mbmJzcDsgU28gaXQgc2VlbWVkIGxvZ2ljYWwgdG8gcHV0IGl0IE5F VENPTkYgdHJhbnNwb3J0IGRyYWZ0LiZuYnNwOyAoQWdhaW4gd2Ugd2VyZSB0cnlpbmcgdG8gbGlt aXQgdGhlIHByb2xpZmVyYXRpb24NCiBvZiBkcmFmdHMuKTxicj4NCjxicj4NCkluIHRoZSBlbmQs IEkgYW0gb2sgYXMgbG9uZyBhcyBpdCBsYW5kcyBzb21ld2hlcmUuJm5ic3A7IFNvIGlmIHBlb3Bs ZSBwcmVmZXIsIHdlIGNvdWxkIGFsc28gaGF2ZSB0aGlzIGFzIGEgY29tcGxldGVseSBzZXBhcmF0 ZSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBzZWN0aW9uICYjNDM7IFlBTkcgbW9kZWwgaW4gNTI3 N2Jpcy48YnI+DQo8YnI+DQomZ3Q7ICZndDsgLSBob3cgdG8gaXNzdWUgbm90aWZpY2F0aW9ucyBp biBKU09OIGFyZSBzZW50IHVzaW5nIE5DICh0aGlzIGlzIGFsc288YnI+DQomZ3Q7ICZndDsgaW4g NTI3Ny1iaXMpLiBBcmd1YWJseSwgaXQgYmVsb25ncyBpbiB0aGUgTkMgdHJhbnNwb3J0IGRvYzxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBUaGlzIGlzIHBvb3JseSBkZWZpbmVkLjxicj4NCiZndDsgJmd0OyBORVRDT05GIGRvZXMgbm90 IHN1cHBvcnQgSlNPTiBlbmNvZGluZyBhbmQgSU1PIHNob3VsZCBub3QgZGVmaW5lIEpTT048YnI+ DQomZ3Q7ICZndDsgZW5jb2RpbmcgdW5sZXNzIHRoZSBlbnRpcmUgcHJvdG9jb2wgc3VwcG9ydHMg aXQgY2xlYW5seS48YnI+DQomZ3Q7ICZndDsgVGhlIHByb3Bvc2FsIHNlZW1zIHRvIGJlIHRvIHVz ZSBYTUwgZm9yICZsdDtycGMmZ3Q7IGFuZCAmbHQ7cnBjLXJlcGx5Jmd0OywgYnV0PGJyPg0KJmd0 OyAmZ3Q7IGFsbG93IHNvbWUgc3BlY2lhbCBtb2RlIHdoZXJlICZsdDtub3RpZmljYXRpb24mZ3Q7 IGlzIHNlbnQgaW4gSlNPTi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7byZuYnNwOyBTZWN0aW9uIDIuMTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgVGhlIHRleHQgc2F5czo8YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO1RoZSBORVRDT05GIGV2ZW50IHN0cmVh bSBjb250YWlucyBhbGw8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDtORVRDT05GIFhN TCBldmVudCBub3RpZmljYXRpb25zIHN1cHBvcnRlZCBieSB0aGUgcHVibGlzaGVyLDxicj4NCiZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgRmlyc3Qgb2YgYWxsLCBzaW5j ZSB0aGlzIGRvY3VtZW50IGlzIHByb3RvY29sLWFnbm9zdGljLCBzaG91bGQgaXQ8YnI+DQomZ3Q7 ICZndDsgJmd0OyByZWFsbHkgZGVmaW5lIHRoZSBzdHJlYW0gJnF1b3Q7TkVUQ09ORiZxdW90Oz88 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmx0O2V2Jmd0OyBBZ3JlZSwgd2hpY2ggaXMg d2h5IHRoaXMgaXMgZ29pbmcgdG8gbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb24uPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgU2Vjb25kbHksIHRoaXMgd291bGQgYmUg YSBuZXcgcmVxdWlyZW1lbnQuJm5ic3A7IFRoZXJlIGlzIG5vdGhpbmcgaW4gUkZDPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmbmJzcDsgNTI3NyB0aGF0IHNheXMgdGhhdCBhIG5vdGlmaWNhdGlvbiBpcyBz ZW50IG9uICZxdW90O05FVENPTkYmcXVvdDsgYmUgZGVmYXVsdC48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmx0O2V2Jmd0OyA1Mjc3IHNlY3Rpb24gMy4yLjMgdGFsa3MgYWJvdXQgdGhl IGRlZmF1bHQgZXZlbnQgc3RyZWFtIHdoaWNoIGhhczxicj4NCiZndDsgJmd0OyBhbGwgTkVUQ09O RiBldmVudCBub3RpZmljYXRpb25zPGJyPg0KJmd0Ozxicj4NCiZndDsgWW91J3JlIHJpZ2h0LiZu YnNwOyBUaGUgcXVlc3Rpb24gaXMgdGhlbiB3aGF0IGlzIGFuICZxdW90O05FVENPTkYgWE1MIGV2 ZW50PGJyPg0KJmd0OyBub3RpZmljYXRpb24mcXVvdDs/Jm5ic3A7IEkgdGhpbmsgdGhlIGludGVu dGlvbiB3YXMgdGhhdCB0aGVzZSB3b3VsZCBiZSAmcXVvdDtub3RpZmljYXRpb25zPGJyPg0KJmd0 OyByZWxhdGVkIHRvIE5FVENPTkYmcXVvdDssIHJhdGhlciB0aGFuICZxdW90O2FsbCBZQU5HLWRl ZmluZWQgbm90aWZpY2F0aW9ucyZxdW90Oy4mbmJzcDsgVGhpcyBuZWVkczxicj4NCiZndDsgc29t ZSBkaXN1Y3NzaW9uLjxicj4NCjxicj4NCkFncmVlPGJyPg0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsm bmJzcDsgSSB0aGluayB0aGlzIHRleHQgc2hvdWxkIGJlIHJlbW92ZWQuJm5ic3A7IEhvdyBub3Rp ZmljYXRpb25zIGFyZSBtYXBwZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyB0byBzdHJlYW1zIGlzIHNo b3VsZCBiZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQuPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZsdDtldiZndDsgWWVzLCBzdHJlYW1zIGFzIGEgd2hvbGUgd2VyZSBzb21l dGhpbmcgd2UgZGVmZXJyZWQgZm9yIGEgd2hpbGUuJm5ic3A7IExhdGVzdDxicj4NCiZndDsgdGhp bmtpbmcgaXMgd2UgbWluaW1pemUgc3RyZWFtcyB0byB0aGUgZGVncmVlIHBvc3NpYmxlLiZuYnNw OyBMb29rIGZvciBsZWdhY3kgc3R1ZmYgdG88YnI+DQomZ3Q7IGJlIGluIG5ldGNvbmYtZXZlbnQt bm90aWZpY2F0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IERvIHlvdSBtZWFuIHRoYXQgeW91IHBs YW4gdG8gdXBkYXRlIHRoZSB0ZXh0IGFyb3VuZCBzdHJlYW1zPyZuYnNwOyBJZiBzbywgdGhhdCdz PGJyPg0KJmd0OyBmaW5lLjxicj4NCjxicj4NClllczxicj4NCjxicj4NCiZndDsgJmd0OyAmZ3Q7 Jm5ic3A7IEluIGxpc3QgJnF1b3Q7ZmlsdGVyJnF1b3Q7LCBjaGFuZ2UgJnF1b3Q7ZmlsdGVyLWlk JnF1b3Q7IHRvICZxdW90O2lkJnF1b3Q7Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsmbmJzcDsgSW4gbGlzdCAmcXVvdDtzdWJzY3JpcHRpb24mcXVvdDssIGNoYW5nZSAm cXVvdDtzdWJzY3JpcHRpb24taWQmcXVvdDsgdG8gJnF1b3Q7aWQmcXVvdDsuPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZsdDtldiZndDsgTW9kZWwgcHVyaXR5LXdpc2UgeW91IGFyZSBj b3JyZWN0LiZuYnNwOyBXaXRoIGJvdGggc3Vic2NyaXB0aW9uIGlkIGFuZCBmaWx0ZXI8YnI+DQom Z3Q7IGlkLCBzZXZlcmFsIHBlb3BsZSBleHByZXNzZWQgdGhleSB3YW50ZWQgdGhlIG9iamVjdHMg dG8gYmUgaW1tZWRpYXRlbHkgYW5kPGJyPg0KJmd0OyBvYnZpb3VzbHkgZGlmZmVyZW50aWFibGUu Jm5ic3A7ICZuYnNwO0hvcGVmdWxseSBvdGhlcnMgd2lsbCBjaGltZSBpbiBoZXJlLjxicj4NCiZn dDs8YnI+DQomZ3Q7IEkgdGhpbmsgd2Ugc2hvdWxkIHRyeSB0byBrZWVwIHRoZSBzYW1lIHN0eWxl IGFjcm9zcyBJRVRGIGRvY3VtZW50cy48YnI+DQomZ3Q7IE1vc3QgbW9kZWxzIGRvIG5vdCB1c2Ug cmVkdW5kYW50IHF1YWxpZmllcnMsIGVzcGVjaWFsbHkgbm90IGZvciBnZW5lcmljIG5hbWVzPGJy Pg0KJmd0OyBsaWtlICdpZCcgb3IgJ25hbWUnIHdoZW4gdXNlZCBhcyBhIGtleS48YnI+DQo8YnI+ DQpJIGFtIGhhcHB5IHdpdGggd2hhdGV2ZXIgY29udmVudGlvbiB0aGUgV0cgY2hvb3Nlcy48YnI+ DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyBJbiBsaXN0ICZxdW90O3N1YnNjcmlwdGlvbiZx dW90OywgY2hhbmdlICZxdW90O3N0YXJ0VGltZSZxdW90OyB0byAmcXVvdDtzdGFydC10aW1lJnF1 b3Q7IGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZxdW90O3N0b3BUaW1lJnF1b3Q7IHRvICZxdW90 O3N0b3AtdGltZSZxdW90OywgZm9yIGNvbnNpc3RlbmN5Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmbHQ7ZXYmZ3Q7IHdlIGtlcHQgdGhlIG9sZCBuYW1lcyBmb3IgYmFja3dhcmRzIGVx dWl2YWxlbmN5IHRvIDUyNzcuPGJyPg0KJmd0Ozxicj4NCiZndDsgQnV0IHRoZXJlIGlzIG5vdGhp bmcgdG8gYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBpbiB0aGlzIGNhc2UuPGJyPg0KJmd0 OyBUaGUgaW5wdXQgcGFyYW10ZXJzIHRvIHRoZSBleGlzdGluZyAmbHQ7Y3JlYXRlLXN1YnNjcmlw dGlvbiZndDsgY2Fubm90IGJlIGNoYW5nZWQsPGJyPg0KJmd0OyBidXQgbmV3IG5vZGVzIHNob3Vs ZCBiZSBrZXB0IGNvbnNpc3RlbnQuPGJyPg0KPGJyPg0KT2suJm5ic3A7IFNvIHlvdSB3YW50IHN0 YXJ0LXRpbWUgaW4gdGhlIFlBTkcgbW9kZWwsIGFuZCBzdGFydFRpbWUgaW4gdGhlIFJQQy4mbmJz cDsgVGhhdCBjYW4gYmUgZG9uZS48YnI+DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyBJbiBs aXN0ICZxdW90O3N1YnNjcmlwdGlvbiZxdW90OywgY2hhbmdlIGNob2ljZSAmcXVvdDtwdXNoLXNv dXJjZSZxdW90OyB0byBhIGJldHRlcjxicj4NCiZndDsgJmd0OyAmZ3Q7IG5hbWUsIG1heWJlICZx dW90O2VncmVzcy1pbnRlcmZhY2UmcXVvdDsgKHRoaXMgaXMgaG93IGl0IGlzIGRlc2NyaWJlZCku PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZsdDtldiZndDsgcHVzaC1zb3VyY2UgY2Fu IGFsc28gYmUgYW4gSVAgQWRkcmVzcy4mbmJzcDsgQW5vdGhlciBuYW1lIHBvc3NpYmlsaXR5IGZv ciB0aGlzPGJyPg0KJmd0OyBtaWdodCBiZSDigJxPcmlnaW5hdGVzLWZyb23igJ0sIHRoYXQgaXMg dGhlIGJhc2ljIGlkZWEuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGN1cnJlbnQgZHJhZnQgaGFz Ojxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNob2ljZSBw dXNoLXNvdXJjZSB7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg ZGVzY3JpcHRpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJnF1b3Q7SWRlbnRpZmllcyB0aGUgZWdyZXNzIGludGVyZmFjZSBvbiB0aGUgUHVibGlz aGVyIGZyb208YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7d2hpY2ggbm90aWZpY2F0aW9ucyB3aWxsIG9yIGFyZSBiZWluZyBzZW50LiZxdW90 Ozs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBZb3UgcHJvYmFibHkgbmVlZCB0byBhZGp1c3QgdGhpcywg YW5kIG1ha2UgaXQgY2xlYXIgd2hhdCB0aGUgaXAtYWRkcmVzcyBjYXNlPGJyPg0KJmd0OyByZWFs bHkgbWVhbnMuPGJyPg0KPGJyPg0KYWdyZWU8YnI+DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNw OyBJbiBsaXN0ICZxdW90O3JlY2VpdmVyJnF1b3Q7LCB3aGF0IGlzIGEgJnF1b3Q7bXVsdGlwb2lu dCBhZGRyZXNzJnF1b3Q7Pzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbHQ7ZXYmZ3Q7 IHdlIGFyZSB0cnlpbmcgbm90IHRvIGxpbWl0IHJlY2VpdmVycyB0byBob3N0cy4gUGVyaGFwcyBt dWx0aWNhc3QgYWRkcmVzcyBpczxicj4NCiZndDsgb2suJm5ic3A7IFJlYWxseSB3ZSB3b3VsZCBi ZSBnb29kIHdpdGggdHlwZTogaW5ldDpob3N0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSB0eXBl IGlzIGluZXQ6aG9zdCBhbHJlYWR5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFlvdSBzaG91bGQgcHJv YmFibHkgY2xhcmlmeSB0aGUgZGVzY3JpcHRpb25zLjxicj4NCjxicj4NCmFncmVlPGJyPg0KPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgUmVtb3ZlIHRoZSBsZWFmICZxdW90O3NvdXJjZS12cmYm cXVvdDs7IHRoaXMgc2hvdWxkIGV2ZW50dWFsbHkgYmUgYWxpZ25lZDxicj4NCiZndDsgJmd0OyAm Z3Q7IHdpdGgmbmJzcDsgZHJhZnQtaWV0Zi1ydGd3Zy1uaS1tb2RlbC48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgUGVyaGFwcyBhIHBsYWNlIGZvciBzY2hlbWEtbW91bnQ/PGJyPg0KJmd0 Ozxicj4NCiZndDsgTm90IHJlYWxseSwgcmF0aGVyIGFuIGF1Z21lbnQuPGJyPg0KPGJyPg0KSGFw cHkgdG8gZ28gd2l0aCB3aGF0ZXZlciBjb252ZW50aW9uIHBlb3BsZSB3YW50IHRvIHVzZS48YnI+ DQo8YnI+DQomZ3Q7ICZndDsgV2Ugc2hvdWxkIGxlYXZlIHNvdXJjZS12cmYgaW48YnI+DQomZ3Q7 ICZndDsgcGxhY2UgdW50aWwgd2UgaGF2ZSB0aGUgcHJvcGVyIGRlZmluaXRpb24uPGJyPg0KJmd0 Ozxicj4NCiZndDsgTm8gSSBzYXkgcmVtb3ZlIGl0IHVudGlsIHlvdSBoYXZlIGEgcHJvcGVyIGRl ZmluaXRpb24uJm5ic3A7IElmIHlvdSBrZWVwIGl0IHlvdSBuZWVkIHRvPGJyPg0KJmd0OyBoYXZl IGEgcHJvcGVyIGRlZmluaXRpb24gb2Ygd2hhdCBpdCBpcywgYW5kIGl0IG5lZWRzIHRvIGJlIGlu dGVyb3BlcmFibGUgYWNyb3NzPGJyPg0KJmd0OyBpbXBsZW1lbnRhdGlvbnMuPGJyPg0KPGJyPg0K V2Ugd2lsbCBhZGRyZXNzIHdpdGggdGhlIHByb3BlciBjb252ZW50aW9uIGluIHRoZSBuZXh0IGRy YWZ0PGJyPg0KPGJyPg0KJmd0OyAmZ3Q7IEJ1dCB3ZSBjb3VsZCB1cGRhdGUgdGhlIHRleHQgc2hv d2luZyB0aGVyZSBpcyBhIHBlbmRpbmcgZGVjaXNpb24uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsmbmJzcDsgWW91IGhhdmUgbWFkZSB0aGUgc3RyZWFtIG5hbWUgYW4gaWRlbnRp dHkuJm5ic3A7IEluIFJGQyA1Mjc3IGl0IHdhcyBhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc3RyaW5n LiZuYnNwOyBCeSB1c2luZyBhbiBpZGVudGl0eSwgeW91IHNldmVybHkgbGltaXQgaG93IGl0IGNh biBiZSB1c2VkOzxicj4NCiZndDsgJmd0OyAmZ3Q7IHdpdGggYSBzdHJpbmcgbmV3IHN0cmVhbXMg Y2FuIGJlIGR5bmFtaWNhbGx5IGNyZWF0ZWQgYXQgcnVuLXRpbWUsPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgYnV0IHdpdGggYW4gaWRlbnRpdHkgc3RyZWFtIG5hbWVzIG11c3QgYmUga25vd24gYXQgZGVz aWduLXRpbWUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgSSB0aGluayB0aGUgc3RyZWFtIG5h bWUgc2hvdWxkIGJlIGNoYW5nZWQgYmFjayB0byBhIHN0cmluZy48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmx0O2V2Jmd0OyBhcyB0aGUgbWFqb3JpdHkgb2YgdGhlIHBlb3BsZSBpbiB0 aGUgaW5mb3JtYWwgZGVzaWduIHRlYW0gd2VyZSBhZ2FpbnN0PGJyPg0KJmd0OyB0aGUgZXhwYW5z aW9uIG9mIHN0cmVhbXMsIHRoaXMgaXMgbGlrZWx5IGEgbW9vdCBwb2ludC48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJIGRvbid0IGtub3cgd2hhdCAmcXVvdDtleHBhbnNpb24gb2Ygc3RyZWFtcyZxdW90 OyBtZWFucywgYW5kIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0PGJyPg0KJmd0OyAmcXVvdDt0aGlz JnF1b3Q7IHJlZmVycyB0byBpbiAmcXVvdDt0aGlzIGlzIGxpa2VseSBhIG1vb3QgcG9pbnQmcXVv dDsuPGJyPg0KJmd0Ozxicj4NCiZndDsgQnV0IGlmIHdlIGtlZXAgdGhlIHN0cmVhbSBuYW1lIGFz IGFuIGlkZW50aXR5IHdlJ3JlIG5vIGxvbmdlciBiYWNrd2FyZHM8YnI+DQomZ3Q7IGNvbXBhdGli bGUgd2l0aCBSRkMgNTI3NywgYW5kIHdlIHNldmVybHkgbGltaXQgdGhlIGZ1bmN0aW9uYWxpdHku Jm5ic3A7IEkgc3Ryb25nbHk8YnI+DQomZ3Q7IG9iamVjdCB0byBzdWNoIGEgY2hhbmdlLjxicj4N Cjxicj4NCkkgYW0gZmluZSB3aXRoIHN0cmluZywgZXNwZWNpYWxseSBhczo8YnI+DQooYSkgd2Ug YXJlIG1vdmluZyBhd2F5IGZyb20gc3RyaW5ncyBpbiBmYXZvciBvZiBmaWx0ZXJzPGJyPg0KKGIp IGN1c3RvbSBzdHJlYW1zIGFyZSBsaWtlbHkgdG8gYmUgdGhlIGRvbWluYW50IHVzZS48YnI+DQpB bnlvbmUgaGF2ZSBhbiBvYmplY3Rpb24mbmJzcDsgdG8gdGhpcyBjaGFuZ2U/PGJyPg0KPGJyPg0K Jmd0OyAmZ3Q7ICZndDtvJm5ic3A7IFNlY3Rpb24gNC4xPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyBUaGUgdGV4dCBzYXlzOjxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7SWYgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7cmVxdWVzdCBpcyByZWplY3RlZCBiZWNhdXNlIHRoZSBwdWJsaXNoZXIg aXMgbm90IGFibGUgdG8gc2VydmUgaXQsPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 dGhlIHB1Ymxpc2hlciBTSE9VTEQgaW5jbHVkZSBpbiB0aGUgcmV0dXJuZWQgZXJyb3Igd2hhdCBz dWJzY3JpcHRpb248YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDtwYXJhbWV0ZXJzIHdv dWxkIGhhdmUgYmVlbiBhY2NlcHRlZCBmb3IgdGhlIHJlcXVlc3Qgd2hlbiBpdCB3YXM8YnI+DQom Z3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDtwcm9jZXNzZWQuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyBJIHRoaW5rIHRoaXMgaXMgYSBwcmV0dHkgd2VpcmQg aWRlYS4mbmJzcDsgSXQgc2VlbXMgZXh0cmVtZWx5IGRpZmZpY3VsdDxicj4NCiZndDsgJmd0OyAm Z3Q7IHRvIGltcGxlbWVudCwgYW5kIHRoZSB1c2UgY2FzZSBpcyBub3QgY2xlYXIgYXQgYWxsLiZu YnNwOyBJbiBhbjxicj4NCiZndDsgJmd0OyAmZ3Q7IGF1dG9tYXRpb24gZGVwbG95bWVudCwgZG8g d2UgZXhwZWN0IHRoYXQgdGhlIGNsaWVudCBhcHBsaWNhdGlvbiBjb2RlPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgY29udGFpbnMgbG9naWMgdG8gcmV3cml0ZSBpdHNlbGYgdG8gc2VuZCBwcm9wZXIgcmVx dWVzdHMgdGhlIG5leHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyB0aW1lPyZuYnNwOyAmbmJz cDtJZiBpdCBpcyBmb3IgZGVidWdnaW5nIHB1cnBvc2VzIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUg dXAgdG88YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyBpbXBsZW1lbnRhdGlvbnMgdG8gZmlndXJl IG91dC4mbmJzcDsgV2Ugc2hvdWxkbid0IGFkZCBzdWNoIHRoaW5ncyB0bzxicj4NCiZndDsgJmd0 OyAmZ3Q7IHN0YW5kYXJkIFJQQ3MuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZsdDtl diZndDsgdGhlcmUgaGFzIGJlZW4gbG90cyBvZiBkaXNjdXNzaW9uIG9uIHRoaXMgb25lLiZuYnNw OyBUaGUgYmlnZ2VzdCBpc3N1ZSBoYXMgYmVlbjxicj4NCiZndDsgdGhhdCB0aGVyZSBhcmUgZW5v dWdoIHZhcmlhdGlvbnMgb2YgcGFyYW1ldGVycyB3aGVyZSB0aGUgZ3VpZGFuY2Ugb24gd2hhdDxi cj4NCiZndDsgbWlnaHQgYmUgYWNjZXB0YWJsZSBpcyB0aGUgb25seSB3YXkgdG8gbWFrZSBzb21l IHNjZW5hcmlvcyB3b3JrLiZuYnNwOyAoV2FzIGl0IHRoZTxicj4NCiZndDsgcGVyaW9kIHdoaWNo IHdhcyBhIHByb2JsZW0/Jm5ic3A7IFdhcyBpdCB0aGUgY29tcGxleGl0eSBvZiB0aGUgZmlsdGVy PykmbmJzcDsgT2J2aW91c2x5PGJyPg0KJmd0OyB3ZSBkbyBuZWVkIHRvIGJvdW5kIHdoYXQgY291 bGQgYmUgcHJvdmlkZWQgYmFjayB0byB0aGUgc3Vic2NyaWJlci48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBTbyB0aGVuIHRoZSB0ZXh0IHNob3VsZCBlbmNvdXJhZ2UgaW1wbGVtZW50YXRpb25zIHRvIHBy b3ZpZGUgZ29vZCBlcnJvcjxicj4NCiZndDsgbWVzc2FnZXMuPGJyPg0KPGJyPg0KeWVzPGJyPg0K PGJyPg0KJmd0OyAmZ3Q7IFRoZSBnb29kIG5ld3MgaXMgdGhhdCBpZiBhIHB1Ymxpc2hlciBjYW5u b3Qgc3VwcG9ydCBuZWdvdGlhdGlvbiwgaXQgY2FuIGp1c3Q8YnI+DQomZ3Q7IHNlbmQgYmFjayBh IGZhaWx1cmUuJm5ic3A7IFdoaWNoIGlzIHdoeSB0aGUgcmVxdWlyZW1lbnQgaXMgb25seSBhIFNI T1VMRC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTSE9VTEQgaXMgdG9vIHN0cm9uZy4mbmJzcDsgQW5k IGV2ZW4gc28sIHRoaXMganVzdCBhZGRzIGNvbXBsZXhpdHkgdG8gdGhlPGJyPg0KJmd0OyBzcGVj aWZpY2F0aW9uLiZuYnNwOyBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIHJlbW92ZWQuPGJyPg0KPGJy Pg0KUkZDNzkyMyBoYXMgaXQgYXMgYSBNVVNUIChzZWUgc2VjdGlvbiA0LjIuMi4pJm5ic3A7IEdv aW5nIHRvIFNIT1VMRCBpcyBhbHJlYWR5IGVhc2luZyBvZmYgdGhlIHJlcXVpcmVtZW50Ljxicj4N Cjxicj4NCiZndDsgJmd0OyBBIHdvcnNlIG91dGNvbWUgd291bGQgYmUgaWYgYSBTdWJzY3JpYmVy IGtlcHQgZ3Vlc3NpbmcgYXQgYWNjZXB0YWJsZTxicj4NCiZndDsgcGFyYW1ldGVycyBhbmQgcG91 bmRpbmcgdGhlIFB1Ymxpc2hlciB3aXRoIGxvYWQgb24gdGhpcy4mbmJzcDsgVGhpcyB3b3VsZCB0 YWtlPGJyPg0KJmd0OyBtb3JlIHJlc291cmNlcyB0aGFuIHByb3ZpZGluZyBoaW50cy48YnI+DQom Z3Q7PGJyPg0KJmd0OyBUaGF0IHdvdWxkIGFsc28gYmUgcXVpdGUgd2VpcmQuJm5ic3A7IEJ1dCBJ IGNhbid0IGltYWdpbmUgYSB1c2UgY2FzZSB3aGVyZSBhIGNsaWVudDxicj4NCiZndDsgbmVlZHMg YSBjZXJ0YWluIGNvbWJpbmF0aW9uIG9mIHBhcmFtZXRlcnMsIHRoZSBzZXJ2ZXIgcmVqY2V0cyB0 aGVtIGJ1dCBzdWdnZXN0PGJyPg0KJmd0OyBzb21lIG90aGVyIHBhcmFtZXRlcnMgdGhhdCB3aWxs IGdpdmUgdGhlIHNhbWUgcmVzdWx0LCBhbmQgdGhlbiB0aGUgY2xpZW50PGJyPg0KJmd0OyB3b3Vs ZCB1c2UgdGhlbT8mbmJzcDsgT3Igd29yc2UsIHRoZSBzZXJ2ZXIgc3VnZ2VzdCBzb21ldGhpbmcg dGhhdCBnaXZlcyBhbm90aGVyPGJyPg0KJmd0OyByZXN1bHQgYW5kIHRoZSBjbGllbnQgc29tZWhv dyBhZGp1c3QgdG8gdGhlbT88YnI+DQo8YnI+DQpXaGVuIGEgc3Vic2NyaXB0aW9uIGlzIHJlamVj dGVkLCB3ZSBjYW4gcHJvdmlkZSBhIGhpbnQgYXQgd2h5LiZuYnNwOyBUaGlzIGlzIGEgbmV3IGRh bXBlbmluZyBwZXJpb2QsIGEgc3VnZ2VzdGlvbiB0byB1c2Ugb24tY2hhbmdlLCBldGMuJm5ic3A7 IFdpdGhvdXQgdGhpcyBoaW50LCBhIHN1YnNjcmliZXIgY291bGQganVzdCBrZWVwIGd1ZXNzaW5n IGF0IHBhcmFtZXRlcnMgd2l0aG91dCBndWlkYW5jZS4mbmJzcDsgVGhhdCBpcyBhbGwgbmVnb3Rp YXRpb24gaXMuPGJyPg0KPGJyPg0KJmd0OyAmZ3Q7ICZndDtvJm5ic3A7IFNlY3Rpb24gNjxicj4N CiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgVGhlIHRleHQgc2F5czo8 YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO1RoZSBl dmVudCBub3RpZmljYXRpb25zIG11c3QgYWxzbyBpbmNsdWRlIHRoZSBzdWJzY3JpcHRpb24taWQg aWYgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ZXN0YWJsaXNoLXN1YnNjcmlw dGlvbiB3YXMgdXNlZCBpbiBpdHMgZXN0YWJsaXNobWVudCwgb3IgaWYgaXQgd2FzPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Y29uZmlndXJlZCB2aWEgYW4gb3BlcmF0aW9uYWwgaW50 ZXJmYWNlLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgSG93 IGlzIHRoaXMgJnF1b3Q7c3VjYnNjcmlwdGlvbi1pZCZxdW90OyBzdXBwb3NlZCB0byBiZSBpbmNs dWRlZD8mbmJzcDsgV2hlcmU/PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgVGhlcmUgaXMgbm8g c3VjaCBmaWVsZCBkZWZpbmVkIGluIGEgJmx0O25vdGlmaWNhdGlvbiZndDsuPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZsdDtldiZndDsgVW5saWtlIHlhbmctcHVzaCwgdGhlIE5vdGlm aWNhdGlvbiBldmVudHMgYXJlIG5vdCBzcGVjaWZpZWQgdmlhIHRoZTxicj4NCiZndDsgZG9jdW1l bnQuJm5ic3A7ICZuYnNwO1RoZSBleGFtcGxlcyBmb2xsb3dpbmcgdGhlIHJlcXVpcmVtZW50IGRv IG5vdCBpbmNsdWRlIGE8YnI+DQomZ3Q7IHN1YnNjcmlwdGlvbi1pZCB3aGVuIHRoZXkgYWJzb2x1 dGVseSBzaG91bGQuJm5ic3A7IChBbmQgdGhpcyBwcm92ZXMgdGhlIHBvaW50IHRoYXQ8YnI+DQom Z3Q7IHRoZXNlIGFyZSBuZWVkZWQgOi0pLiZuYnNwOyAmbmJzcDtXZSB3aWxsIHVwZGF0ZSB0aGUg ZXhhbXBsZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2VsbCwgZXhhbXBsZXMgYXJlIGdvb2QsIGJ1 dCB5b3UgYWxzbyBuZWVkIGEgbm9ybWF0aXZlIGRlZmluaXRpb24uPGJyPg0KPGJyPg0KV2lsbCBk by48YnI+DQo8YnI+DQpFcmljPGJyPg0KPGJyPg0KJmd0OyAvbWFydGluPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhhbmtzIGFnYWluLDxicj4NCiZn dDsgJmd0OyBFcmljPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_0ff12bf034b549e1b5f6ebab4596917dXCHRTP013ciscocom_-- From nobody Fri Dec 9 19:48:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F101295E9 for ; Fri, 9 Dec 2016 19:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvJGuoNnWLi2 for ; Fri, 9 Dec 2016 19:48:07 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFA51294C0 for ; Fri, 9 Dec 2016 19:48:05 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id n204so36704348qke.2 for ; Fri, 09 Dec 2016 19:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mSVD75Drgw2uNjAHGfsbwhyrVyraW3YtqQMB3AGMtgM=; b=GbCT8JjJc2HGvh68/5oXE6pInlAk6ySEsVJvPH/ZEaBcAFM3JBSZI3Nxqv1npV0JEx YVldekM0Tiak2w2tN1rEaogOwmZhLgXO8s6O9QI6ea5DwXqSzQ5z/ffDmQKSb5hTaYfs ZKlOuZ3vqiJh/sjyqut0ma2aDY/lxo6TNNP0CKVe6nTg99xa4PCSWnvckJTNGBsW/WEk CVzpf/TkhnGzE2mOtEKX6uWZw5RP9qSQvVIgqzDfNqALpw8+CIAR/fO2SKL1cM7RREtN X8cNJiMlq3Qxlq1BloA3fnu4nvtO1X9OPYLw0FXLF7NmHoKAB60uFydbeuLpuEZpgzLw pDlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mSVD75Drgw2uNjAHGfsbwhyrVyraW3YtqQMB3AGMtgM=; b=CMqrDDXMBeol8ekt2Yxt3tdWM4s8eXtT8WynfDw1gd9HrmvLqgdQTiFSqpehlpBh9Z OfBsJ3KFzu9SCOk7xb7s6DogeD+af4FKdGD/xOwymdvs5uqiwG62p2L6d87wjbYpPoM9 Qu40G0XUH4RLhYGGKf1fLciCqrgB6qRE9Sl/AvFBuQQhZdvQG3FSj2h3OV3joOPQHoOn 8FSyy5VR4etCiPHVdsBZpc4urYt3bcgZy1smCPqBXpRhTMxEY6MQJkofcn3kGc24ybh2 faU85R4nTMR2HeidMAIPLzhuFmfNBdTzzf9WYwyQrO4Tl24sVC0i/l7NyMTgDLbMzaSf XWFw== X-Gm-Message-State: AKaTC015HG661GYIkiQ6a36ky5ZplyG0n99T4/Ylqbdio1BSFLKx9WVa3XRzHEXGtrNVoF9d5WvzSjTPrhK8yA== X-Received: by 10.55.155.206 with SMTP id d197mr18787505qke.127.1481341684198; Fri, 09 Dec 2016 19:48:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Fri, 9 Dec 2016 19:48:03 -0800 (PST) In-Reply-To: <20161209.143306.1544319624979225814.mbj@tail-f.com> References: <20161209.092651.1622778603139515958.mbj@tail-f.com> <5e06ffa5d92a4227ae1d64bc8531ac40@XCH-RTP-013.cisco.com> <20161209.143306.1544319624979225814.mbj@tail-f.com> From: Andy Bierman Date: Fri, 9 Dec 2016 19:48:03 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=94eb2c075bace145eb054345bc6e Archived-At: Cc: Netconf Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:48:09 -0000 --94eb2c075bace145eb054345bc6e Content-Type: text/plain; charset=UTF-8 On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund wrote: > "Eric Voit (evoit)" wrote: > > > From: Martin Bjorklund, December 9, 2016 3:27 AM > > > > > > "Eric Voit (evoit)" wrote: > > > > Hi Martin, > > > > > > > > > From: Martin Bjorklund, December 8, 2016 4:08 AM > > > > > > > > > > I think your requirements below are more like driving forces for > > > > > YANG push, right? Is there any of these that affects the solution > > > > > in RFC 5277? > > > > > > > > The majority of these cases need yang-push. But yang push is only > > > > possible when the information is yang modeled. > > > > > > Sure, but that's a completely different thing. > > > > > > This discussion is about what needs to be done with RFC 5277. I'll > re-iterate > > > what Andy wrote once more: > > > > > > What are the must-have, should-have, and nice-to-have features that > are > > > missing from RFC 5277? > > > > At a high level incremental functionality we have been discussing since > IETF 94, 95, 96, 97 includes: > > - configured subscriptions > > - many subscriptions per transport > > - modify and delete subscriptions > > - control plane notifications > > - Restconf & HTTP support > > - Data plan notification including subscription-id > > > > At a medium level, existing documentation detailing these requirements > can be seen in places like: > > https://www.ietf.org/proceedings/95/slides/slides-95-netconf-7.pdf > Slide 5 > > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf > Slides 5, 28 > > https://www.ietf.org/proceedings/97/slides/slides- > 97-netconf-draft-ietf-netconf-yang-push-01.pdf Slides 20 & 21 > > I think the list above summarizes what's in the slides. > > So, let me re-order this list a bit: > > - configured subscriptions > - many subscriptions per transport > - Data plan notification including subscription-id > - modify and delete subscriptions > > I don't view "control plane notifications" as a deficiency of 5277; it > already has a few, and if new functionality requires us to define more > control plane notifications, that's not a problem. > > As for "Restconf & HTTP support", RESTCONF already supports > notifications, and there need to be a RESTCONF-specific solution in > place. I do agree that if we open 5277, we should make sure we have a > small protocol-dependent part, and a generic, protocol-independent > part. > I agree with this approach. The feature list above is ready a solution list, not a feature list. Can we describe new functionality in terms of the problem being solved? subscription-id is a solution to some undisclosed problem. must-have: - extensible filtering framework that can be shared by multiple protocols and operations - mandatory-to-implement set of RPCs (create, modify, cancel) for subscription mgmt - integration with Call-home and netconf-client-server drafts - subscription diagnostics (filter, network, etc.) should-have: - configured subscriptions that connect at boot-time to configured receivers - extensible framework that allows multiple protocol, message encoding, and transport configurations; pick small set of mandatory-to-implement combinations - augmentable notification header that can be used by standard protocols and vendor extensions to send control-plane data - efficiency mechanisms to support large-scale subscription aggregation clients - binary encoding and message framing for NETCONF and RESTCONF to reduce NM network usage Andy > So there are really two (major) requirements: > > 1. configured subscriptions > 2. many subscriptions per transport session > > Do you agree, or did I miss anything? > > (1) can be done completely backwards compatible; in fact it might not > even require an update to 5277. > > (2) requires an update to the element, as discussed > earlier. > > Did you want to make support for (2) mandatory to implement? If so, > we need to make :interleave mandatory, or remove it. > > Maybe it should be noted that when SSH is used, there really is no > need for (2), since it is trivial and cheap to open new SSH channels. > I thus assume that the reason for wanting to do (2) is that sessions > are expensive when SSH is not used. > > > > /martin > > > > > > > At a detailed level, I2RS's RFC-7923 has functional requirements for > yang subscriptions. This is what was requested by the WG to be made > available for event notifications. > > as well as various WG meeting minutes. > > > > And of course the existing WG minutes, the four draft document > appendices, and the Dezign team minutes at: > > https://github.com/netconf-wg/yang-push/wiki/Minutes > > Attempts to keep a running list of to-be-resolved dialogs. Of course > there is a lag between dialogs and embodiment in the drafts. > > > > If anyone wants to propose a revision to the requirements, I propose > they do this as deltas from the existing documentation. > > > > Or course we in the WG can and should discuss and tweak any specific > requirement on this mailer based on ongoing learnings over time. > > > > Eric > > > > > /martin > > > --94eb2c075bace145eb054345bc6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
"Eric Voit (evoit)&quo= t; <evoit@cisco.com> wrote: > > From: Martin Bjorklund, December 9, 2016 3:27 AM
> >
> > "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > Hi Martin,
> > >
> > > > From: Martin Bjorklund, December 8, 2016 4:08 AM
> > > >
> > > > I think your requirements below are more like driving f= orces for
> > > > YANG push, right?=C2=A0 Is there any of these that affe= cts the solution
> > > > in RFC 5277?
> > >
> > > The majority of these cases need yang-push.=C2=A0 But yang p= ush is only
> > > possible when the information is yang modeled.
> >
> > Sure, but that's a completely different thing.
> >
> > This discussion is about what needs to be done with RFC 5277.=C2= =A0 I'll re-iterate
> > what Andy wrote once more:
> >
> >=C2=A0 =C2=A0What are the must-have, should-have, and nice-to-have= features that are
> >=C2=A0 =C2=A0missing from RFC 5277?
>
> At a high level incremental functionality we have been discussing sinc= e IETF 94, 95, 96, 97 includes:
> - configured subscriptions
> - many subscriptions per transport
> - modify and delete subscriptions
> - control plane notifications
> - Restconf & HTTP support
> - Data plan notification including subscription-id
>
> At a medium level, existing documentation detailing these requirements= can be seen in places like:
> https://www.ietf.org/pro= ceedings/95/slides/slides-95-netconf-7.pdf=C2=A0 =C2=A0Slide 5
> https://www.ietf.org/pro= ceedings/96/slides/slides-96-netconf-5.pdf=C2=A0 =C2=A0Slides 5, 2= 8
> https://www.ietf.org/proceedings/97/slides/slides-97-netconf-dra= ft-ietf-netconf-yang-push-01.pdf=C2=A0 Slides 20 & 21

I think the list above summarizes what's in the slides.

So, let me re-order this list a bit:

- configured subscriptions
- many subscriptions per transport
=C2=A0 - Data plan notification including subscription-id
=C2=A0 - modify and delete subscriptions

I don't view "control plane notifications" as a deficiency of= 5277; it
already has a few, and if new functionality requires us to define more
control plane notifications, that's not a problem.

As for "Restconf & HTTP support", RESTCONF already supports notifications, and there need to be a RESTCONF-specific solution in
place.=C2=A0 I do agree that if we open 5277, we should make sure we have a=
small protocol-dependent part, and a generic, protocol-independent
part.


I agree with this = approach.

The feature list above is ready a soluti= on list, not a feature list.
Can we describe new functionality in= terms of the problem being solved?
subscription-id is a solution= to some undisclosed problem.

must-have:
=C2=A0 - extensible filtering framework that can be shared by multiple pro= tocols and operations
=C2=A0 - mandatory-to-implement set of RPCs= (create, modify, cancel) for subscription mgmt
=C2=A0 - integrat= ion with Call-home and netconf-client-server drafts
=C2=A0 - subs= cription diagnostics (filter, network, etc.)

shoul= d-have:
=C2=A0 - configured subscriptions that connect at boot-ti= me to configured receivers
=C2=A0 - extensible framework that all= ows multiple protocol, message encoding, and transport
=C2=A0 =C2= =A0 configurations; pick small set of mandatory-to-implement combinations
=C2=A0 - augmentable notification header that can be used by stand= ard protocols and vendor extensions
=C2=A0 =C2=A0 to send control= -plane data
=C2=A0 - efficiency mechanisms to support large-scale= subscription aggregation clients
=C2=A0 - binary encoding and me= ssage framing for NETCONF and RESTCONF to reduce NM
=C2=A0 =C2=A0= network usage



Andy<= /div>



So there are really two (major) requirements:

=C2=A0 1.=C2=A0 configured subscriptions
=C2=A0 2.=C2=A0 many subscriptions per transport session

Do you agree, or did I miss anything?

(1) can be done completely backwards compatible; in fact it might not
even require an update to 5277.

(2) requires an update to the <notification> element, as discussed earlier.

Did you want to make support for (2) mandatory to implement?=C2=A0 If so, we need to make :interleave mandatory, or remove it.

Maybe it should be noted that when SSH is used, there really is no
need for (2), since it is trivial and cheap to open new SSH channels.
I thus assume that the reason for wanting to do (2) is that sessions
are expensive when SSH is not used.



/martin



>
> At a detailed level, I2RS's RFC-7923 has functional requirements f= or yang subscriptions. This is what was requested by the WG to be made avai= lable for event notifications.
> as well as various WG meeting minutes.
>
> And of course the existing WG minutes, the four draft document appendi= ces, and the Dezign team minutes at:
> https://github.com/netconf-wg/yang-p= ush/wiki/Minutes
> Attempts to keep a running list of to-be-resolved dialogs.=C2=A0 Of co= urse there is a lag between dialogs and embodiment in the drafts.
>
> If anyone wants to propose a revision to the requirements, I propose t= hey do this as deltas from the existing documentation.
>
> Or course we in the WG can and should discuss and tweak any specific r= equirement on this mailer based on ongoing learnings over time.
>
> Eric
>
> > /martin
>

--94eb2c075bace145eb054345bc6e-- From nobody Fri Dec 9 23:21:27 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5087F129652 for ; Fri, 9 Dec 2016 23:21:26 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] 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 2srjwy740YDS for ; Fri, 9 Dec 2016 23:21:24 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111161295B5 for ; Fri, 9 Dec 2016 23:21:23 -0800 (PST) Received: from LAPTOPR7T053C2 ([47.143.86.36]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LpeF6-1ctdUI08EI-00fOLk; Sat, 10 Dec 2016 08:21:16 +0100 From: To: "'Andy Bierman'" , "'Martin Bjorklund'" References: <20161209.092651.1622778603139515958.mbj@tail-f.com> <5e06ffa5d92a4227ae1d64bc8531ac40@XCH-RTP-013.cisco.com> <20161209.143306.1544319624979225814.mbj@tail-f.com> In-Reply-To: Date: Fri, 9 Dec 2016 23:21:14 -0800 Message-ID: <02b701d252b5$ff631f10$fe295d30$@clemm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B8_01D25272.F141B3D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE9dcCGCSykY+3YNO2HRG8yxOnrzAJXM9UpApoIEhwBlvqPRAJFmSC6oeQM/cA= Content-Language: en-us X-Provags-ID: V03:K0:eRFiVxP6fSOt+1Ozsc6fZ0+cKAEfTRcZcRuv0p03bj8hNN/wh1r uB8dsAnOe/C4Or37QQrm3O/ND521Mf7O3aOVDHq7dQCOStZXtzhNQ/MKlUy2tT+XppV+PMV YPK0XH1W1EK4imp/Yf+1ksJ8qM73Sg4XrSMBruUC0PlTRd50zuLGFJmR0hUbGDbwh6mgGf7 S770++hOitgueAP0c6cvg== X-UI-Out-Filterresults: notjunk:1;V01:K0:6r/ZiOpUNzc=:41/yc0vlufjxyDFk1KbDIZ o188nNtS1doOKIufyzJS6bPDjwA7I25gJhoX2kUp+/7WwRWL9vnChKN+DYH8L22MGScqZHu2W vjm0C1vS54upxKtyKttCVSLh2kr+8nCpM2cOwbZJ/8g96MkuSdeblc9azUGv0ETZmMA7EuV8f Z5F9lcQuD964aASpBqeiZbpkT/3URiZgHjjYdwr2uR/LWGkxA9vzMQNPu1Lfkh/NxyhWV9nmb 7K/nEzEdjdpcQnveHg8U3Mip49d47gruG+yJTBDjDVZI5w5Ms9d54mYH2kDD/57aswLavmqTh 4Tq96h4TMXUw6gBSusiMjglEDHxxhAvo418gxQusTq0uyd3sblXQuTSnfDT3LyFQhzapYp/0X 9/E4jsjuFW6z854HhigiYkFORKM+Xb3UtcOr/Sg/a+44lQOj4eXVmXy9kVKQgIFMCx8WZi4/c qEGUrHU0UAgPuI6+Q5hMXonjJ25Q7yLjM2nyaI/Q5Mj+eTG24s6KG0nYVu2/FXiWYE7X+/5+v 7bYH4Nf9gEqZ6cCob7BmklLMAgjDqBky6tctYRNv3jE6VH05TjhFBaS+mQJzsjl4Wt0cKbV9x bZsTy8kCkPbhbPysQMpVHENNcyAzQP6XakOO0tApoV0OkV7TwNqcdxpDmGlnndoaKoIBId8b0 iVH/MQ+wT1pVO40b0B44vDw240J4zXvY4dfLtlt9sa0yz8ST0oDqrM5AQCQpAkqYxct/9aqjT 0ou+trw/uxdmr4GY Archived-At: Cc: 'Netconf' Subject: Re: [Netconf] Subscription Use Cases X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 07:21:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02B8_01D25272.F141B3D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 Originally, we were working within the confines of RFC 5277 for = YANG-Push, but it was clear that were a couple of items that came up as = limitations. As stated, these include configurable subscriptions, the = ability to maintain multiple subscriptions, to modify and delete = subscriptions. =20 =20 I would add that another important requirement concerned the ability to = separate subscription control from subscription transport and thus be = able to leverage multiple transports. (We can discuss if this should be = strictly a YANG-push requirement, not an RFC 5277 requirements =E2=80=93 = but in that case it would imply departing from the concept of layering = YANG-Push on top of event notifications.) I would also think that the = ability to support control notifications is a requirement; I do not see = it well supported with existing mechanisms. =20 =20 The ability to associated updates with subscriptions was originally a = requirement for YANG-Push, not for event notifications. This is the = reason why subscription ID is included in YANG-Push updates (but only = there). The ability to associate event notifications with a particular = subscription is a new requirement; if we decide to support (and there = are clearly some use cases) this one will have architectural = ramifications as noted (since it means event notifications now need to = have a way to be associated with specific subscription, presumably = leading to a header that includes a subscription ID, and possibly = redundant sending of notifications that are subscribed multiple times.) = =20 --- Alex =20 From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman Sent: Friday, December 9, 2016 7:48 PM To: Martin Bjorklund Cc: Netconf Subject: Re: [Netconf] Subscription Use Cases =20 =20 =20 On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund > wrote: "Eric Voit (evoit)" > wrote: > > From: Martin Bjorklund, December 9, 2016 3:27 AM > > > > "Eric Voit (evoit)" > = wrote: > > > Hi Martin, > > > > > > > From: Martin Bjorklund, December 8, 2016 4:08 AM > > > > > > > > I think your requirements below are more like driving forces for > > > > YANG push, right? Is there any of these that affects the = solution > > > > in RFC 5277? > > > > > > The majority of these cases need yang-push. But yang push is only > > > possible when the information is yang modeled. > > > > Sure, but that's a completely different thing. > > > > This discussion is about what needs to be done with RFC 5277. I'll = re-iterate > > what Andy wrote once more: > > > > What are the must-have, should-have, and nice-to-have features = that are > > missing from RFC 5277? > > At a high level incremental functionality we have been discussing = since IETF 94, 95, 96, 97 includes: > - configured subscriptions > - many subscriptions per transport > - modify and delete subscriptions > - control plane notifications > - Restconf & HTTP support > - Data plan notification including subscription-id > > At a medium level, existing documentation detailing these requirements = can be seen in places like: > https://www.ietf.org/proceedings/95/slides/slides-95-netconf-7.pdf = Slide 5 > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf = Slides 5, 28 > = https://www.ietf.org/proceedings/97/slides/slides-97-netconf-draft-ietf-n= etconf-yang-push-01.pdf Slides 20 & 21 I think the list above summarizes what's in the slides. So, let me re-order this list a bit: - configured subscriptions - many subscriptions per transport - Data plan notification including subscription-id - modify and delete subscriptions I don't view "control plane notifications" as a deficiency of 5277; it already has a few, and if new functionality requires us to define more control plane notifications, that's not a problem. As for "Restconf & HTTP support", RESTCONF already supports notifications, and there need to be a RESTCONF-specific solution in place. I do agree that if we open 5277, we should make sure we have a small protocol-dependent part, and a generic, protocol-independent part. =20 =20 I agree with this approach. =20 The feature list above is ready a solution list, not a feature list. Can we describe new functionality in terms of the problem being solved? subscription-id is a solution to some undisclosed problem. =20 must-have: - extensible filtering framework that can be shared by multiple = protocols and operations - mandatory-to-implement set of RPCs (create, modify, cancel) for = subscription mgmt - integration with Call-home and netconf-client-server drafts - subscription diagnostics (filter, network, etc.) =20 should-have: - configured subscriptions that connect at boot-time to configured = receivers - extensible framework that allows multiple protocol, message = encoding, and transport configurations; pick small set of mandatory-to-implement = combinations - augmentable notification header that can be used by standard = protocols and vendor extensions to send control-plane data - efficiency mechanisms to support large-scale subscription = aggregation clients - binary encoding and message framing for NETCONF and RESTCONF to = reduce NM network usage =20 =20 =20 Andy =20 =20 So there are really two (major) requirements: 1. configured subscriptions 2. many subscriptions per transport session Do you agree, or did I miss anything? (1) can be done completely backwards compatible; in fact it might not even require an update to 5277. (2) requires an update to the element, as discussed earlier. Did you want to make support for (2) mandatory to implement? If so, we need to make :interleave mandatory, or remove it. Maybe it should be noted that when SSH is used, there really is no need for (2), since it is trivial and cheap to open new SSH channels. I thus assume that the reason for wanting to do (2) is that sessions are expensive when SSH is not used. /martin > > At a detailed level, I2RS's RFC-7923 has functional requirements for = yang subscriptions. This is what was requested by the WG to be made = available for event notifications. > as well as various WG meeting minutes. > > And of course the existing WG minutes, the four draft document = appendices, and the Dezign team minutes at: > https://github.com/netconf-wg/yang-push/wiki/Minutes > Attempts to keep a running list of to-be-resolved dialogs. Of course = there is a lag between dialogs and embodiment in the drafts. > > If anyone wants to propose a revision to the requirements, I propose = they do this as deltas from the existing documentation. > > Or course we in the WG can and should discuss and tweak any specific = requirement on this mailer based on ongoing learnings over time. > > Eric > > > /martin > =20 ------=_NextPart_000_02B8_01D25272.F141B3D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

Originally, = we were working within the confines of RFC 5277 for YANG-Push, but it = was clear that were a couple of items that came up as limitations.=C2=A0 = As stated, these include configurable subscriptions, the ability to = maintain multiple subscriptions, to modify and delete = subscriptions.=C2=A0

 

I would add = that another important requirement concerned the ability to separate = subscription control from subscription transport and thus be able to = leverage multiple transports. (We can discuss if this should be strictly = a YANG-push requirement, not an RFC 5277 requirements =E2=80=93 but in = that case it would imply departing from the concept of layering = YANG-Push on top of event notifications.)=C2=A0 I would also think that = the ability to support control notifications is a requirement; I do not = see it well supported with existing mechanisms.=C2=A0 =

 

The ability = to associated updates with subscriptions was originally a requirement = for YANG-Push, not for event notifications. =C2=A0This is the reason why = subscription ID is included in YANG-Push updates (but only there).=C2=A0 = The ability to associate event notifications with a particular = subscription is a new requirement; if we decide to support (and there = are clearly some use cases) this one will have architectural = ramifications as noted (since it means event notifications now need to = have a way to be associated with specific subscription, presumably = leading to a header that includes a subscription ID, and possibly = redundant sending of notifications that are subscribed multiple = times.)=C2=A0

 

--- = Alex

 

From:<= /b> = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Friday, December 9, 2016 7:48 PM
To: = Martin Bjorklund <mbj@tail-f.com>
Cc: Netconf = <netconf@ietf.org>
Subject: Re: [Netconf] Subscription = Use Cases

 

 

 

On Fri, = Dec 9, 2016 at 5:33 AM, Martin Bjorklund <mbj@tail-f.com> = wrote:

"Eric Voit (evoit)" <evoit@cisco.com> wrote:
> = > From: Martin Bjorklund, December 9, 2016 3:27 AM
> = >
> > "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> = > > Hi Martin,
> > >
> > > > From: = Martin Bjorklund, December 8, 2016 4:08 AM
> > > = >
> > > > I think your requirements below are more = like driving forces for
> > > > YANG push, right?  = Is there any of these that affects the solution
> > > > = in RFC 5277?
> > >
> > > The majority of these = cases need yang-push.  But yang push is only
> > > = possible when the information is yang modeled.
> >
> > = Sure, but that's a completely different thing.
> >
> > = This discussion is about what needs to be done with RFC 5277.  I'll = re-iterate
> > what Andy wrote once more:
> >
> = >   What are the must-have, should-have, and nice-to-have = features that are
> >   missing from RFC = 5277?
>
> At a high level incremental functionality we have = been discussing since IETF 94, 95, 96, 97 includes:
> - configured = subscriptions
> - many subscriptions per transport
> - = modify and delete subscriptions
> - control plane = notifications
> - Restconf & HTTP support
> - Data plan = notification including subscription-id
>
> At a medium = level, existing documentation detailing these requirements can be seen = in places like:
> https://www.ietf.org/proceedings/95/slides/slides-95-ne= tconf-7.pdf   Slide 5
> https://www.ietf.org/proceedings/96/slides/slides-96-ne= tconf-5.pdf   Slides 5, 28
> https://www.ietf.org/proceedings/97/slides/slides-97-ne= tconf-draft-ietf-netconf-yang-push-01.pdf  Slides 20 & = 21

I think the list above summarizes what's in the = slides.

So, let me re-order this list a bit:

- configured = subscriptions
- many subscriptions per transport
  - Data = plan notification including subscription-id
  - modify and = delete subscriptions

I don't view "control plane = notifications" as a deficiency of 5277; it
already has a few, = and if new functionality requires us to define more
control plane = notifications, that's not a problem.

As for "Restconf & = HTTP support", RESTCONF already supports
notifications, and = there need to be a RESTCONF-specific solution in
place.  I do = agree that if we open 5277, we should make sure we have a
small = protocol-dependent part, and a generic, = protocol-independent
part.

 

 

I = agree with this approach.

 

The feature list above is ready a solution list, not a = feature list.

Can we = describe new functionality in terms of the problem being = solved?

subscription-id is = a solution to some undisclosed problem.

 

must-have:

  - extensible filtering framework that can be = shared by multiple protocols and operations

  - mandatory-to-implement set of RPCs (create, = modify, cancel) for subscription mgmt

  - integration with Call-home and = netconf-client-server drafts

  - subscription diagnostics (filter, network, = etc.)

 

should-have:

  - configured subscriptions that connect at = boot-time to configured receivers

  - extensible framework that allows multiple = protocol, message encoding, and transport

    configurations; pick small set of = mandatory-to-implement combinations

  - augmentable notification header that can be = used by standard protocols and vendor = extensions

    = to send control-plane data

  - efficiency mechanisms to support large-scale = subscription aggregation clients

  - binary encoding and message framing for = NETCONF and RESTCONF to reduce NM

    network = usage

 

 

 

Andy

 

 


So = there are really two (major) requirements:

  1.  = configured subscriptions
  2.  many subscriptions per = transport session

Do you agree, or did I miss = anything?

(1) can be done completely backwards compatible; in = fact it might not
even require an update to 5277.

(2) requires = an update to the <notification> element, as = discussed
earlier.

Did you want to make support for (2) = mandatory to implement?  If so,
we need to make :interleave = mandatory, or remove it.

Maybe it should be noted that when SSH = is used, there really is no
need for (2), since it is trivial and = cheap to open new SSH channels.
I thus assume that the reason for = wanting to do (2) is that sessions
are expensive when SSH is not = used.



/martin



>
> At a detailed = level, I2RS's RFC-7923 has functional requirements for yang = subscriptions. This is what was requested by the WG to be made available = for event notifications.
> as well as various WG meeting = minutes.
>
> And of course the existing WG minutes, the four = draft document appendices, and the Dezign team minutes at:
> https://github.com/netconf-wg/yang-push/wiki/Minutes
> Attempts to keep a running list of to-be-resolved = dialogs.  Of course there is a lag between dialogs and embodiment = in the drafts.
>
> If anyone wants to propose a revision to = the requirements, I propose they do this as deltas from the existing = documentation.
>
> Or course we in the WG can and should = discuss and tweak any specific requirement on this mailer based on = ongoing learnings over time.
>
> Eric
>
> > = /martin
>

 

------=_NextPart_000_02B8_01D25272.F141B3D0-- From nobody Tue Dec 13 05:37:39 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2911296B7; Tue, 13 Dec 2016 05:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA_eNBk7qyNS; Tue, 13 Dec 2016 05:37:34 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5641293FC; Tue, 13 Dec 2016 05:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6729; q=dns/txt; s=iport; t=1481636254; x=1482845854; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7FjQPDUU51toszccJrS6iY4RreYwOStXyrSDPWeKM4A=; b=SWHUb90zdCJ19pGIoGTt4f116oHgbF+z8HCcrH5oSOOM8LWTLibPsfyA Dyfd2/98tXCzhGEo8wdroa2W1QGXD4pcoc5bPzyCn5zdqQ+fHTMYhoXEU 3Z8aDDF/SYEnALb+9mFvsx8xH5LhMXLYLjcj0eQXhH3AEN03Uwxz6T3oU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQAW+U9Y/5tdJa1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQEfWoEGB41DlxiHdY0RggkeC4UuSgKBdD8UAQIBAQE?= =?us-ascii?q?BAQEBYiiEaAEBAQMBAQE4NAsFCQICAQgQBQMeEBsGBgslAgQBDQUIE4g2Aw8ID?= =?us-ascii?q?q0QhzQNg1IBAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYY5hFuCSIIhJoUaBY8BizU?= =?us-ascii?q?1AY0/g2KBfY5Uh2uBcIQ3hA4BHzeBISeDTBwYgUVyh2CBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,341,1477958400"; d="scan'208";a="360108719" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2016 13:37:33 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBDDbWrF029048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Dec 2016 13:37:33 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 13 Dec 2016 08:37:32 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Tue, 13 Dec 2016 08:37:32 -0500 From: "Eric Voit (evoit)" To: Ladislav Lhotka , MehmetErsue Thread-Topic: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 Thread-Index: AQHSUhqXeTJ8fMsU6k2pIJNbJLJAMKEF49Ew Date: Tue, 13 Dec 2016 13:37:32 +0000 Message-ID: <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 13:37:37 -0000 I support adoption, and like Mehmet's thinking as well. Also worth focusing on is transport protocol independent yang filtering. S= o along with how to frame get operations against one of the datastores, how= do you know which subtrees/nodes should be included/excluded. Eric > From: Netconf, December 9, 2016 7:49 AM >=20 > Hi Mehmet, >=20 > I think I could just sign your text at the bottom. >=20 > Lada >=20 > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: > > > > Hi All, > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to a= dopt and > finalize the DT draft in NETMOD WG, which I still support. > > > > I believe the bigger issue is to agree on a plan concerning the related= work > and the re-organization of existing standards. As a matter of fact this p= lan will > lead to updating the charter of two WGs and the work we are going to star= t. > > > > I see the DT document as a datastore solution proposal. There are diffe= rent > gaps and issues which still need to be addressed and the solution proposa= l > needs yet to be discussed and finalized. The document is providing inform= ation > on the history, explaining the need for a generic solution as well as is = discussing > different scenarios. As such I believe the datastore solution proposal fr= om the > DT should be published with the intended status Informational RFC. > > > > Based on the finalized and agreed datastore solution we should do diffe= rent > updates to existing documents in NETCONF and NETMOD WGs. With this > action we can also fix well-known issues. > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > - a RFC6241bis draft removing the current datasore concept > > specification, and getting rid of well-known issues e.g. with the > > operation, > > - a new protocol- and language-independent standard document (RFC XYZ) > > defining the generic datastore concept and framework and describing > > its use (based on and following the DT solution draft), > > - adding potential extensions to RFC6241bis (following the DT draft > > and with a normative reference to RFC XYZ), > > - adding potential extensions to a RESTCONF-bis RFC (following the DT > > draft and with a normative reference to RFC XYZ), > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > - RFC7950bis deleting protocol-dependent details and specifying the > > datastore usage with YANG on a generic level (with a normative > > reference to RFC XYZ), > > - adding potential extensions to RFC7950bis, e.g. concerning the > > proposed element, > > - possibly an RFC 6244bis to describe architectural aspects. However RF= C6244 > is Informational and a RFC6244bis would be still Informational. I'm not s= ure > whether this is really necessary. The DT proposal does already describe s= uch a > solution and can be seen as an update to RFC 6244. > > - RFC6087bis giving guidelines on how to use YANG with the new datastor= e > concept. > > > > Referring to Lada's proposal concerning the spin off document from > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > provided in the corresponding protocol RFCs, i.e. > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > Hope this helps as a starting point on the way to a good plan. > > > > PS: As Benoit suggested some time ago we might also consider to rename > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > Regards, > > Mehmet > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > wrote: > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > wrote: > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > I disagree that the datastore model is a protocol specific aspect. > > > > I consider datastores an architectural component binding data > > > > models and protocols together. In fact, the 'traditional' > > > > datastore model > > > > > > I would agree with this if datastores were a general concept in YANG,= but > the revised-datastores draft explicitly introduces the "intended" and "ap= plied" > datastores that may be irrelevant to other protocols using YANG, and even > needn't be used in all NETCONF implementations. I wouldn't call this "an > architectural component" of YANG. > > > > > > > An architectural component of this new management framework (that does > > not have a name). The fact that not all protocols may expose all > > datastores is IMHO not a reason that the datastore model is not an > > architectural framework. > > > > > If you are saying that it will have nontrivial impact on YANG, I woul= d like to > see it explained in sec. 6.3. Without this information I am quite relucta= nt to > agree with the adoption. > > > > An operational state datastore has implications how one writes data > > models. It may not directly affect YANG itself but surely the usage of > > YANG. > > > > > See above - architectural aspects need to be relevant to all protocol= s. > > > > Yes, but relevant to all protocols does not mean every protocol needs > > to expose say all datastores. But every protocol should be clear about > > how what it exposes relates to the architectural framework. > > > > > > > > There is a "current solution" consisting of hard-wired object > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution does > > not require special protocols or datastores, but it is being replaced b= y a > generic solution. > > > > If the "generic" solution requires special procedures which differ on > > each protocol, then it might end up be worse than the hard-wired soluti= on > that works on every protocol. > > So I agree with Juergen that this is primarily an architectural issue. > > > > > > /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 > > -- > > Cheers, > > Mehmet >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Dec 13 07:16:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5831E12940E for ; Tue, 13 Dec 2016 07:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sedw3GUnbHTs for ; Tue, 13 Dec 2016 07:16:51 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61997129407 for ; Tue, 13 Dec 2016 07:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3611; q=dns/txt; s=iport; t=1481642211; x=1482851811; h=from:to:subject:date:message-id:mime-version; bh=UUmwYMh45Aqmh+0Lv0DG+pmx3i/tqRPHN1IPX9FDh4Q=; b=JNi720U8fSq1fVETzbETpzWF6cCyADfU6ZslZXFaqj9d/X95B1UmwJGR Uc0HmnEL0aDmS7cyUT++xkRBKw9ExaSjWo9ua09pp/Ww/KIjVUNesuEGB /wIFM3GWMI/RXtYDRiT05KY+WpfTGukhblALm+fjHjm5DYoQylo0ZypCk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BnAgBUEFBY/4sNJK1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgnNEAQEBAQEfWoENjUOmfYUjggmIGz8UAQIBAQEBAQEBYh0LhG8tXgEMYRM?= =?us-ascii?q?mAQQbiGOacZImixcBAQEBAQUBAQEBAQEBIZVCBZprARqRB5BRkiABHzcxcCeFR?= =?us-ascii?q?YckK4EDgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,342,1477958400"; d="scan'208,217";a="358794031" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2016 15:16:50 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uBDFGoda027567 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 Dec 2016 15:16:50 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 13 Dec 2016 09:16:49 -0600 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.1210.000; Tue, 13 Dec 2016 09:16:49 -0600 From: "Lukas Macko -X (lmacko - PANTHEON TECHNOLOGIES at Cisco)" To: "netconf@ietf.org" Thread-Topic: netconf-config-change target in case of delete operation Thread-Index: AdJVUzr72J7RTdDGR06/F3VB7JHOqA== Date: Tue, 13 Dec 2016 15:16:49 +0000 Message-ID: <58ad2f124ce14b77a71e799c23801acd@XCH-ALN-015.cisco.com> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.66.168] Content-Type: multipart/alternative; boundary="_000_58ad2f124ce14b77a71e799c23801acdXCHALN015ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] netconf-config-change target in case of delete operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 15:16:53 -0000 --_000_58ad2f124ce14b77a71e799c23801acdXCHALN015ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am trying to implement netconf-config-change notifications defined in RFC= 6470. The issue I came across is that I am not sure what instance id should be pr= ovided for leaf /netconf-config-change/list/target in case of delete or rem= ove operation. Since the target leaf doesn't specify require-instance false in schema, I c= an not specify instance id of deleted node to pass the validation. Thanks & Regards, Lukas --_000_58ad2f124ce14b77a71e799c23801acdXCHALN015ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am trying to implement netcon= f-config-change notifications defined in RFC6470.

 

The issue I came across is that= I am not sure what instance id should be provided for leaf /netconf-config= -change/list/target in case of delete or remove operation.

Since the target leaf doesnR= 17;t specify require-instance false in schema, I can not specify instance i= d of deleted node to pass the validation.

 

Thanks & Regards,

Lukas

--_000_58ad2f124ce14b77a71e799c23801acdXCHALN015ciscocom_-- From andy@yumaworks.com Tue Dec 13 09:38:04 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82891293DF for ; Tue, 13 Dec 2016 09:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7t8aVVnX3rs for ; Tue, 13 Dec 2016 09:38:02 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 57F821294F6 for ; Tue, 13 Dec 2016 09:37:59 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id n204so123808035qke.2 for ; Tue, 13 Dec 2016 09:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o8GQdzKNgzVj0wKzC+hgr6hgoXi7jC29Sblz00PiYGA=; b=oN37K1QuJxv3hotWr/zN6D8FJKzX2EQjwLDG4FGZB/M49teCwPqWI29EMTSsjPsblZ LWSOarqXvw75q8klCuHoE7eDMAyvnb/500ZDnptIFwQpfUpaajdxQU7vDN3Es5CGpCAW jg7ib7VSZ5hZ+q66eKoyCMVl8GqJxMqDeewT1NENk4lMKIphVCBJ5ACvBGi3do46atpE NKTxfwbWSY3amIlDLjab41ZudbX6qu1ZFKMPp0PPAYqqPPnQxEpxTR1a9Sn0M79o0r7I SGTzIMQhh/SRMCeU4KEttQLhihIMwLcFfCf7V0ZKQglwHmlt2vfWAzgwxrX2+eDWJSNF u9Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o8GQdzKNgzVj0wKzC+hgr6hgoXi7jC29Sblz00PiYGA=; b=CB3G6KCErgDv15GNUksvMVHNC4aJFI4vuDMeridAzigm86ffEhxlGyZtmDeueLLZia QeHhb9hbnRx1045qBaQZwVE1FvhssX3iBkGiuudEv3mSooSafeEZ+3rCV9w/06j9CNOs 1r2naC4tyakaRCXOTudYWeL2bLjYg7rklg6HuEkPFRsYvzZU1LHAHfb7gKRHCKEeZApD QViUfEnUWL0caSJeSHkRjH+TA2qnAvgZfUqLgYSlMqKwSEoM4cemCt+xPBUJIrQ0ViJF mz2EKMDAtvhmRfhDbHt+X/AT/N7RyEIOHyJ0h9/WrMIyPbnY8FDJLvs1s5ANPOWDYQu8 QXEg== X-Gm-Message-State: AKaTC0263gR5v9i5ze7vpYkePZjrO17BprCmP2qjzDHehhXyDr/3SHODMhJ33LxJne9mF6CQGVWCo8ctu6qtHg== X-Received: by 10.55.21.81 with SMTP id f78mr93471414qkh.210.1481650678417; Tue, 13 Dec 2016 09:37:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Tue, 13 Dec 2016 09:37:57 -0800 (PST) In-Reply-To: <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> From: Andy Bierman Date: Tue, 13 Dec 2016 09:37:57 -0800 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a114626ea5e792d05438daed5 Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 17:38:05 -0000 --001a114626ea5e792d05438daed5 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) wrote: > I support adoption, and like Mehmet's thinking as well. > > Also worth focusing on is transport protocol independent yang filtering. > So along with how to frame get operations against one of the datastores, > how do you know which subtrees/nodes should be included/excluded. > > This architectural change needs to be implemented in various protocols. I am not sure a 6241bis is the best approach because it is not clear which servers really need to implement the revised datastores. Since RD is purely optional to implement, it should not obsolete 6241 in any way. It should be possible to add new operations and/or new parameters to existing operations without needing to redefine what is already there. The new protocol features need to explain how to include/exclude subtrees. IMO we should only support YANG defined data. This allows the solutions to be generalized and reusable across protocols (e.g., using YANG extensions). Eric > Andy > > > From: Netconf, December 9, 2016 7:49 AM > > > > Hi Mehmet, > > > > I think I could just sign your text at the bottom. > > > > Lada > > > > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: > > > > > > Hi All, > > > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to > adopt and > > finalize the DT draft in NETMOD WG, which I still support. > > > > > > I believe the bigger issue is to agree on a plan concerning the > related work > > and the re-organization of existing standards. As a matter of fact this > plan will > > lead to updating the charter of two WGs and the work we are going to > start. > > > > > > I see the DT document as a datastore solution proposal. There are > different > > gaps and issues which still need to be addressed and the solution > proposal > > needs yet to be discussed and finalized. The document is providing > information > > on the history, explaining the need for a generic solution as well as is > discussing > > different scenarios. As such I believe the datastore solution proposal > from the > > DT should be published with the intended status Informational RFC. > > > > > > Based on the finalized and agreed datastore solution we should do > different > > updates to existing documents in NETCONF and NETMOD WGs. With this > > action we can also fix well-known issues. > > > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > > - a RFC6241bis draft removing the current datasore concept > > > specification, and getting rid of well-known issues e.g. with the > > > operation, > > > - a new protocol- and language-independent standard document (RFC XYZ) > > > defining the generic datastore concept and framework and describing > > > its use (based on and following the DT solution draft), > > > - adding potential extensions to RFC6241bis (following the DT draft > > > and with a normative reference to RFC XYZ), > > > - adding potential extensions to a RESTCONF-bis RFC (following the DT > > > draft and with a normative reference to RFC XYZ), > > > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > > - RFC7950bis deleting protocol-dependent details and specifying the > > > datastore usage with YANG on a generic level (with a normative > > > reference to RFC XYZ), > > > - adding potential extensions to RFC7950bis, e.g. concerning the > > > proposed element, > > > - possibly an RFC 6244bis to describe architectural aspects. However > RFC6244 > > is Informational and a RFC6244bis would be still Informational. I'm not > sure > > whether this is really necessary. The DT proposal does already describe > such a > > solution and can be seen as an update to RFC 6244. > > > - RFC6087bis giving guidelines on how to use YANG with the new > datastore > > concept. > > > > > > Referring to Lada's proposal concerning the spin off document from > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > > provided in the corresponding protocol RFCs, i.e. > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > > > Hope this helps as a starting point on the way to a good plan. > > > > > > PS: As Benoit suggested some time ago we might also consider to rename > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > > > Regards, > > > Mehmet > > > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > wrote: > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > wrote: > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > > > > I disagree that the datastore model is a protocol specific aspect. > > > > > I consider datastores an architectural component binding data > > > > > models and protocols together. In fact, the 'traditional' > > > > > datastore model > > > > > > > > I would agree with this if datastores were a general concept in > YANG, but > > the revised-datastores draft explicitly introduces the "intended" and > "applied" > > datastores that may be irrelevant to other protocols using YANG, and even > > needn't be used in all NETCONF implementations. I wouldn't call this "an > > architectural component" of YANG. > > > > > > > > > > An architectural component of this new management framework (that does > > > not have a name). The fact that not all protocols may expose all > > > datastores is IMHO not a reason that the datastore model is not an > > > architectural framework. > > > > > > > If you are saying that it will have nontrivial impact on YANG, I > would like to > > see it explained in sec. 6.3. Without this information I am quite > reluctant to > > agree with the adoption. > > > > > > An operational state datastore has implications how one writes data > > > models. It may not directly affect YANG itself but surely the usage of > > > YANG. > > > > > > > See above - architectural aspects need to be relevant to all > protocols. > > > > > > Yes, but relevant to all protocols does not mean every protocol needs > > > to expose say all datastores. But every protocol should be clear about > > > how what it exposes relates to the architectural framework. > > > > > > > > > > > > There is a "current solution" consisting of hard-wired object > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution does > > > not require special protocols or datastores, but it is being replaced > by a > > generic solution. > > > > > > If the "generic" solution requires special procedures which differ on > > > each protocol, then it might end up be worse than the hard-wired > solution > > that works on every protocol. > > > So I agree with Juergen that this is primarily an architectural issue. > > > > > > > > > /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 > > > -- > > > Cheers, > > > Mehmet > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114626ea5e792d05438daed5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) &l= t;evoit@cisco.com&= gt; wrote:
I support adoption, and= like Mehmet's thinking as well.

Also worth focusing on is transport protocol independent yang filtering.=C2= =A0 So along with how to frame get operations against one of the datastores= , how do you know which subtrees/nodes should be included/excluded.



This architectural chan= ge needs to be implemented in various protocols.
I am not sure a = 6241bis is the best approach because it is not clear which
server= s really need to implement the revised datastores.=C2=A0 Since RD is purely= optional
to implement, it should not obsolete 6241 in any way.= =C2=A0 It should be possible
to add new operations and/or new par= ameters to existing operations without
needing to redefine what i= s already there.

The new protocol features need to= explain how to include/exclude subtrees.
IMO we should only supp= ort YANG defined data.=C2=A0 This allows the solutions
to be gene= ralized and reusable across protocols (e.g., using YANG extensions).
<= div>

Eric


Andy
=C2= =A0

> From: Netconf, December 9, 2016 7:49 AM
>
> Hi Mehmet,
>
> I think I could just sign your text at the bottom.
>
> Lada
>
> > On 9 Dec 2016, at 13:25, MehmetErsue <mersue@gmail.com> wrote:
> >
> > Hi All,
> >
> > I think the adoption of the DT draft is fine. We agreed in IETF 9= 7 to adopt and
> finalize the DT draft in NETMOD WG, which I still support.
> >
> > I believe the bigger issue is to agree on a plan concerning the r= elated work
> and the re-organization of existing standards. As a matter of fact thi= s plan will
> lead to updating the charter of two WGs and the work we are going to s= tart.
> >
> > I see the DT document as a datastore solution proposal. There are= different
> gaps and issues which still need to be addressed and the solution prop= osal
> needs yet to be discussed and finalized. The document is providing inf= ormation
> on the history, explaining the need for a generic solution as well as = is discussing
> different scenarios. As such I believe the datastore solution proposal= from the
> DT should be published with the intended status Informational RFC.
> >
> > Based on the finalized and agreed datastore solution we should do= different
> updates to existing documents in NETCONF and NETMOD WGs. With this
> action we can also fix well-known issues.
> >
> > Concerning the NETCONF WG I would see it as valuable if we develo= p:
> > - a RFC6241bis draft removing the current datasore concept
> > specification, and getting rid of well-known issues e.g. with the=
> > <get> operation,
> > - a new protocol- and language-independent standard document (RFC= XYZ)
> > defining the generic datastore concept and framework and describi= ng
> > its use (based on and following the DT solution draft),
> > - adding potential extensions to RFC6241bis (following the DT dra= ft
> > and with a normative reference to RFC XYZ),
> > - adding potential extensions to a RESTCONF-bis RFC (following th= e DT
> > draft and with a normative reference to RFC XYZ),
> >
> > Concerning the NETMOD WG I would see it as valuable if we develop= :
> > - RFC7950bis deleting protocol-dependent details and specifying t= he
> > datastore usage with YANG on a generic level (with a normative > > reference to RFC XYZ),
> > - adding potential extensions to RFC7950bis, e.g. concerning the<= br> > > proposed <notification> element,
> > - possibly an RFC 6244bis to describe architectural aspects. Howe= ver RFC6244
> is Informational and a RFC6244bis would be still Informational. I'= m not sure
> whether this is really necessary. The DT proposal does already describ= e such a
> solution and can be seen as an update to RFC 6244.
> > - RFC6087bis giving guidelines on how to use YANG with the new da= tastore
> concept.
> >
> > Referring to Lada's proposal concerning the spin off document= from
> > RFC7950 ("Adapting NETCONF for use with YANG"), I think= this can be
> provided in the corresponding protocol RFCs, i.e.
> > for NETCONF a section on "Using NETCONF with YANG" in R= FC6241bis and
> for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC.=
> >
> > Hope this helps as a starting point on the way to a good plan. > >
> > PS: As Benoit suggested some time ago we might also consider to r= ename
> NETCONF WG as it is not only on NETCONF protocol anymore.
> >
> > Regards,
> > Mehmet
> >
> > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> wrote:
> > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
> <j.schoenwa= elder@jacobs-university.de> wrote:
> > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote:<= br> > > >
> > > >
> > > > I disagree that the datastore model is a protocol speci= fic aspect.
> > > > I consider datastores an architectural component bindin= g data
> > > > models and protocols together. In fact, the 'tradit= ional'
> > > > datastore model
> > >
> > > I would agree with this if datastores were a general concept= in YANG, but
> the revised-datastores draft explicitly introduces the "intended&= quot; and "applied"
> datastores that may be irrelevant to other protocols using YANG, and e= ven
> needn't be used in all NETCONF implementations. I wouldn't cal= l this "an
> architectural component" of YANG.
> > >
> >
> > An architectural component of this new management framework (that= does
> > not have a name). The fact that not all protocols may expose all<= br> > > datastores is IMHO not a reason that the datastore model is not a= n
> > architectural framework.
> >
> > > If you are saying that it will have nontrivial impact on YAN= G, I would like to
> see it explained in sec. 6.3. Without this information I am quite relu= ctant to
> agree with the adoption.
> >
> > An operational state datastore has implications how one writes da= ta
> > models. It may not directly affect YANG itself but surely the usa= ge of
> > YANG.
> >
> > > See above - architectural aspects need to be relevant to all= protocols.
> >
> > Yes, but relevant to all protocols does not mean every protocol n= eeds
> > to expose say all datastores. But every protocol should be clear = about
> > how what it exposes relates to the architectural framework.
> >
> >
> >
> > There is a "current solution" consisting of hard-wired = object
> > semantics (e.g., ifAdminStatus and ifOperStatus).=C2=A0 This solu= tion does
> > not require special protocols or datastores, but it is being repl= aced by a
> generic solution.
> >
> > If the "generic" solution requires special procedures w= hich differ on
> > each protocol, then it might end up be worse than the hard-wired = solution
> that works on every protocol.
> > So I agree with Juergen that this is primarily an architectural i= ssue.
> >
> >
> > /js
> >
> > Andy
> >
> >
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/net= mod
> > --
> > Cheers,
> > Mehmet
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf=

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

--001a114626ea5e792d05438daed5-- From nobody Tue Dec 13 13:41:51 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C109129BD9; Tue, 13 Dec 2016 13:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 wC7IknuGrHVS; Tue, 13 Dec 2016 13:41:46 -0800 (PST) Received: from mail-wj0-x242.google.com (mail-wj0-x242.google.com [IPv6:2a00:1450:400c:c01::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C526F129BCB; Tue, 13 Dec 2016 13:41:18 -0800 (PST) Received: by mail-wj0-x242.google.com with SMTP id xy5so41933wjc.1; Tue, 13 Dec 2016 13:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=BHwDmOr+18ufj1k4c3zM3JF+0WtS7uKdJzrUDKc3dfI=; b=gUbzxNmJ1m+F3ubAiRoKGOB+NEBqO6H1BvYn+uRVhl90atCT6AJLg+aar3REsVCzNL h9P7SKKIVI8Rtj8UU2GcWmclDI76uk4CizshSMo8vYXDZdQ6Fi+hycsH4vXNY+P1cCrH 4U2QPMljGtoC6SErycZ9yoQ67mXxmFFykQcOUmkaCZM+ILNGJcZ/ndp3mDQV3BE4xEcB Kzvm/mOj1mNDmAGNWPUus9dgmxNAjKExtWt1LGA+REc71C+GnpNyBIc7zCXzRjsrQQac gNrtkRbd1aJb67tzKLCoCteBU0f/iy8XTBHiWpfYOOqfJXvTmUcXFgs4bHTGbeShtn0I yz4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=BHwDmOr+18ufj1k4c3zM3JF+0WtS7uKdJzrUDKc3dfI=; b=kGXrq/XdTRU+QwxGoSh4JQqzlUVNDxLjcIjDTn2H3Gnzp3zngo8hrPRDA9Kgxq+Aj0 kyP4Rnu+0Mr6wqt80dmoDrZRssU7SoSHObcxz5u7JtNr5EFI+PzgnyxEeaimNKcYVSxq U4TIw5L5tG4HkEjRdwHZFAGLLuiezCVjF7VnNVsPyOq8GZQnpt79uGnR2loVQuaWv5HK 9/Qyv0aFkg8ZbO/ZA32gXCGoMv4c2cCAJy7fJH9DS3NmlaMr7U1LskM29rpAwqoE88NG DgULPy2vzOc+7qCnPxDefEPet79657v6l5yloPrJ2sJpWbCvahEMexOLzj3TU8eoPuVb Nttg== X-Gm-Message-State: AKaTC01Yg3Fg2ttV2q32Re/XIe9prWT24Lbsva12aLORaECi0HxYW8qyjqS/VyjqNkudsg== X-Received: by 10.194.157.165 with SMTP id wn5mr27147599wjb.8.1481665277117; Tue, 13 Dec 2016 13:41:17 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5DCC6EDC.dip0.t-ipconnect.de. [93.204.110.220]) by smtp.gmail.com with ESMTPSA id cl6sm64077712wjc.10.2016.12.13.13.41.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Dec 2016 13:41:16 -0800 (PST) From: "Mehmet Ersue" To: "'Andy Bierman'" , "'Eric Voit \(evoit\)'" References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> In-Reply-To: Date: Tue, 13 Dec 2016 22:41:12 +0100 Message-ID: <004101d25589$a0cd5f20$e2681d60$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01D25592.02974560" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJvIdnLcbPhtZVe/ZwhlJOAl849fwFrVtQ3AezV2tIA+5xlnwL4zh2sAk77YEwCCFzmZgJIVCHNAgcLeowB7aW4Zp89xbsQ Content-Language: de X-AVK-Virus-Check: AVA 25.9511;155A1E2 X-AVK-Spam-Check: 1; str=0001.0A0C0206.58506AFB.016A,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; F1206 Archived-At: Cc: 'NetMod WG Chairs' , 'Netconf' , 'NetMod WG' , 'NetConf WG Chairs' Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 21:41:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01D25592.02974560 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Andy, =20 > This architectural change needs to be implemented in various = protocols. > I am not sure a 6241bis is the best approach because it is not clear = which > servers really need to implement the revised datastores. =20 =20 I agree fully. This is the reason why I wrote in my mail: =20 >> - a new protocol- and language-independent standard document (RFC = XYZ) defining the generic datastore concept and framework and describing = its use (based on and following the DT solution draft), >> - a RFC6241bis draft removing the current datasore concept = specification, and getting rid of well-known issues e.g. with the = operation, Mehmet =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Dienstag, 13. Dezember 2016 18:38 To: Eric Voit (evoit) Cc: Ladislav Lhotka ; MehmetErsue ; = NetMod WG Chairs ; NetConf WG Chairs = ; NetMod WG ; Netconf = Subject: Re: [netmod] [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00 =20 =20 =20 On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > wrote: I support adoption, and like Mehmet's thinking as well. Also worth focusing on is transport protocol independent yang filtering. = So along with how to frame get operations against one of the = datastores, how do you know which subtrees/nodes should be = included/excluded. =20 =20 This architectural change needs to be implemented in various protocols. I am not sure a 6241bis is the best approach because it is not clear = which servers really need to implement the revised datastores. Since RD is = purely optional to implement, it should not obsolete 6241 in any way. It should be = possible to add new operations and/or new parameters to existing operations = without needing to redefine what is already there. =20 The new protocol features need to explain how to include/exclude = subtrees. IMO we should only support YANG defined data. This allows the solutions to be generalized and reusable across protocols (e.g., using YANG = extensions). =20 =20 Eric =20 =20 Andy =20 > From: Netconf, December 9, 2016 7:49 AM > > Hi Mehmet, > > I think I could just sign your text at the bottom. > > Lada > > > On 9 Dec 2016, at 13:25, MehmetErsue > wrote: > > > > Hi All, > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 = to adopt and > finalize the DT draft in NETMOD WG, which I still support. > > > > I believe the bigger issue is to agree on a plan concerning the = related work > and the re-organization of existing standards. As a matter of fact = this plan will > lead to updating the charter of two WGs and the work we are going to = start. > > > > I see the DT document as a datastore solution proposal. There are = different > gaps and issues which still need to be addressed and the solution = proposal > needs yet to be discussed and finalized. The document is providing = information > on the history, explaining the need for a generic solution as well as = is discussing > different scenarios. As such I believe the datastore solution proposal = from the > DT should be published with the intended status Informational RFC. > > > > Based on the finalized and agreed datastore solution we should do = different > updates to existing documents in NETCONF and NETMOD WGs. With this > action we can also fix well-known issues. > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > - a RFC6241bis draft removing the current datasore concept > > specification, and getting rid of well-known issues e.g. with the > > operation, > > - a new protocol- and language-independent standard document (RFC = XYZ) > > defining the generic datastore concept and framework and describing > > its use (based on and following the DT solution draft), > > - adding potential extensions to RFC6241bis (following the DT draft > > and with a normative reference to RFC XYZ), > > - adding potential extensions to a RESTCONF-bis RFC (following the = DT > > draft and with a normative reference to RFC XYZ), > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > - RFC7950bis deleting protocol-dependent details and specifying the > > datastore usage with YANG on a generic level (with a normative > > reference to RFC XYZ), > > - adding potential extensions to RFC7950bis, e.g. concerning the > > proposed element, > > - possibly an RFC 6244bis to describe architectural aspects. However = RFC6244 > is Informational and a RFC6244bis would be still Informational. I'm = not sure > whether this is really necessary. The DT proposal does already = describe such a > solution and can be seen as an update to RFC 6244. > > - RFC6087bis giving guidelines on how to use YANG with the new = datastore > concept. > > > > Referring to Lada's proposal concerning the spin off document from > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > provided in the corresponding protocol RFCs, i.e. > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > Hope this helps as a starting point on the way to a good plan. > > > > PS: As Benoit suggested some time ago we might also consider to = rename > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > Regards, > > Mehmet > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > wrote: > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > wrote: > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > I disagree that the datastore model is a protocol specific = aspect. > > > > I consider datastores an architectural component binding data > > > > models and protocols together. In fact, the 'traditional' > > > > datastore model > > > > > > I would agree with this if datastores were a general concept in = YANG, but > the revised-datastores draft explicitly introduces the "intended" and = "applied" > datastores that may be irrelevant to other protocols using YANG, and = even > needn't be used in all NETCONF implementations. I wouldn't call this = "an > architectural component" of YANG. > > > > > > > An architectural component of this new management framework (that = does > > not have a name). The fact that not all protocols may expose all > > datastores is IMHO not a reason that the datastore model is not an > > architectural framework. > > > > > If you are saying that it will have nontrivial impact on YANG, I = would like to > see it explained in sec. 6.3. Without this information I am quite = reluctant to > agree with the adoption. > > > > An operational state datastore has implications how one writes data > > models. It may not directly affect YANG itself but surely the usage = of > > YANG. > > > > > See above - architectural aspects need to be relevant to all = protocols. > > > > Yes, but relevant to all protocols does not mean every protocol = needs > > to expose say all datastores. But every protocol should be clear = about > > how what it exposes relates to the architectural framework. > > > > > > > > There is a "current solution" consisting of hard-wired object > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution = does > > not require special protocols or datastores, but it is being = replaced by a > generic solution. > > > > If the "generic" solution requires special procedures which differ = on > > each protocol, then it might end up be worse than the hard-wired = solution > that works on every protocol. > > So I agree with Juergen that this is primarily an architectural = issue. > > > > > > /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 =20 > > https://www.ietf.org/mailman/listinfo/netmod > > -- > > Cheers, > > Mehmet > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org =20 > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netmod mailing list netmod@ietf.org =20 https://www.ietf.org/mailman/listinfo/netmod =20 ------=_NextPart_000_0042_01D25592.02974560 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 

> This architectural change needs to be implemented in = various protocols.

> I am not sure a 6241bis is the best approach because = it is not clear which

> servers really need to implement the revised = datastores. 

 

I agree fully. This is the reason why I wrote in my = mail:

 

>> - a new protocol- and language-independent = standard document (RFC XYZ) defining the generic datastore concept and = framework and describing its use (based on and following the DT solution = draft),

>> - a RFC6241bis draft removing the current = datasore concept specification, and getting rid of well-known issues = e.g. with the <get> operation,

Mehmet

 

From:<= /b> Andy = Bierman [mailto:andy@yumaworks.com]
Sent: Dienstag, 13. = Dezember 2016 18:38
To: Eric Voit (evoit) = <evoit@cisco.com>
Cc: Ladislav Lhotka = <lhotka@nic.cz>; MehmetErsue <mersue@gmail.com>; NetMod WG = Chairs <netmod-chairs@ietf.org>; NetConf WG Chairs = <netconf-chairs@ietf.org>; NetMod WG <netmod@ietf.org>; = Netconf <netconf@ietf.org>
Subject: Re: [netmod] = [Netconf] WG adoption poll = draft-nmdsdt-netmod-revised-datastores-00

 

 

 

On Tue, = Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

I support adoption, and like Mehmet's = thinking as well.

Also worth focusing on is transport protocol = independent yang filtering.  So along with how to frame get = operations against one of the datastores, how do you know which = subtrees/nodes should be = included/excluded.

 

 

This architectural change needs to be implemented in = various protocols.

I am = not sure a 6241bis is the best approach because it is not clear = which

servers really need = to implement the revised datastores.  Since RD is purely = optional

to implement, it = should not obsolete 6241 in any way.  It should be = possible

to add new = operations and/or new parameters to existing operations = without

needing to = redefine what is already there.

 

The new protocol features need to explain how to = include/exclude subtrees.

IMO we should only support YANG defined data.  = This allows the solutions

to be generalized and reusable across protocols (e.g., = using YANG extensions).

 

 

Eric

 

 

Andy

 


> = From: Netconf, December 9, 2016 7:49 AM
>
> Hi = Mehmet,
>
> I think I could just sign your text at the = bottom.
>
> Lada
>
> > On 9 Dec 2016, at = 13:25, MehmetErsue <mersue@gmail.com> wrote:
> = >
> > Hi All,
> >
> > I think the adoption = of the DT draft is fine. We agreed in IETF 97 to adopt and
> = finalize the DT draft in NETMOD WG, which I still support.
> = >
> > I believe the bigger issue is to agree on a plan = concerning the related work
> and the re-organization of existing = standards. As a matter of fact this plan will
> lead to updating = the charter of two WGs and the work we are going to start.
> = >
> > I see the DT document as a datastore solution = proposal. There are different
> gaps and issues which still need = to be addressed and the solution proposal
> needs yet to be = discussed and finalized. The document is providing information
> = on the history, explaining the need for a generic solution as well as is = discussing
> different scenarios. As such I believe the datastore = solution proposal from the
> DT should be published with the = intended status Informational RFC.
> >
> > Based on = the finalized and agreed datastore solution we should do = different
> updates to existing documents in NETCONF and NETMOD = WGs. With this
> action we can also fix well-known issues.
> = >
> > Concerning the NETCONF WG I would see it as valuable = if we develop:
> > - a RFC6241bis draft removing the current = datasore concept
> > specification, and getting rid of = well-known issues e.g. with the
> > <get> = operation,
> > - a new protocol- and language-independent = standard document (RFC XYZ)
> > defining the generic datastore = concept and framework and describing
> > its use (based on and = following the DT solution draft),
> > - adding potential = extensions to RFC6241bis (following the DT draft
> > and with a = normative reference to RFC XYZ),
> > - adding potential = extensions to a RESTCONF-bis RFC (following the DT
> > draft = and with a normative reference to RFC XYZ),
> >
> > = Concerning the NETMOD WG I would see it as valuable if we = develop:
> > - RFC7950bis deleting protocol-dependent details = and specifying the
> > datastore usage with YANG on a generic = level (with a normative
> > reference to RFC XYZ),
> > = - adding potential extensions to RFC7950bis, e.g. concerning the
> = > proposed <notification> element,
> > - possibly an = RFC 6244bis to describe architectural aspects. However RFC6244
> = is Informational and a RFC6244bis would be still Informational. I'm not = sure
> whether this is really necessary. The DT proposal does = already describe such a
> solution and can be seen as an update to = RFC 6244.
> > - RFC6087bis giving guidelines on how to use YANG = with the new datastore
> concept.
> >
> > = Referring to Lada's proposal concerning the spin off document = from
> > RFC7950 ("Adapting NETCONF for use with = YANG"), I think this can be
> provided in the corresponding = protocol RFCs, i.e.
> > for NETCONF a section on "Using = NETCONF with YANG" in RFC6241bis and
> for RESTCONF = "Using RESTCONF with YANG" in RESTCONF-bis RFC.
> = >
> > Hope this helps as a starting point on the way to a = good plan.
> >
> > PS: As Benoit suggested some time = ago we might also consider to rename
> NETCONF WG as it is not = only on NETCONF protocol anymore.
> >
> > = Regards,
> > Mehmet
> >
> > On Mon, Dec 5, = 2016 at 6:19 PM Andy Bierman <andy@yumaworks.com>
> = wrote:
> > On Mon, Dec 5, 2016 at 4:02 AM, Juergen = Schoenwaelder
> <j.schoenwaelder@jaco= bs-university.de> wrote:
> > On Mon, Dec 05, 2016 at = 11:36:11AM +0100, Ladislav Lhotka wrote:
> > >
> > = > >
> > > > I disagree that the datastore model is = a protocol specific aspect.
> > > > I consider datastores = an architectural component binding data
> > > > models = and protocols together. In fact, the 'traditional'
> > > = > datastore model
> > >
> > > I would agree = with this if datastores were a general concept in YANG, but
> the = revised-datastores draft explicitly introduces the "intended" = and "applied"
> datastores that may be irrelevant to = other protocols using YANG, and even
> needn't be used in all = NETCONF implementations. I wouldn't call this "an
> = architectural component" of YANG.
> > >
> = >
> > An architectural component of this new management = framework (that does
> > not have a name). The fact that not = all protocols may expose all
> > datastores is IMHO not a = reason that the datastore model is not an
> > architectural = framework.
> >
> > > If you are saying that it will = have nontrivial impact on YANG, I would like to
> see it explained = in sec. 6.3. Without this information I am quite reluctant to
> = agree with the adoption.
> >
> > An operational state = datastore has implications how one writes data
> > models. It = may not directly affect YANG itself but surely the usage of
> > = YANG.
> >
> > > See above - architectural aspects = need to be relevant to all protocols.
> >
> > Yes, but = relevant to all protocols does not mean every protocol needs
> = > to expose say all datastores. But every protocol should be clear = about
> > how what it exposes relates to the architectural = framework.
> >
> >
> >
> > There is = a "current solution" consisting of hard-wired object
> = > semantics (e.g., ifAdminStatus and ifOperStatus).  This = solution does
> > not require special protocols or datastores, = but it is being replaced by a
> generic solution.
> = >
> > If the "generic" solution requires special = procedures which differ on
> > each protocol, then it might end = up be worse than the hard-wired solution
> that works on every = protocol.
> > So I agree with Juergen that this is primarily an = architectural issue.
> >
> >
> > /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
>= ; > --
> > Cheers,
> > Mehmet
>
> = --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: = E74E8C0C
>
>
>
>
> = _______________________________________________
> Netconf mailing = list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

------=_NextPart_000_0042_01D25592.02974560-- From nobody Tue Dec 13 13:52:00 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A89129AA2 for ; Tue, 13 Dec 2016 13:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZ3jsBBHuLPX for ; Tue, 13 Dec 2016 13:51:55 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D34129AC3 for ; Tue, 13 Dec 2016 13:51:52 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id c47so402390qtc.2 for ; Tue, 13 Dec 2016 13:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XmoRGMREoULTnILlYwqDFlZQFrc004c7jeFUNQJbjnU=; b=k0ueKacfxMM/fb18Bmdz1nT7qHcevK8DTPw4ieHgF0JSokmDo4Gq5C7PUA+yZH3EO7 9iptUe1CLFaKoC4cStptvrARdFUK3VthIye8a+sE4jjc2gX3K1LbeGQeMHjXUQmm/yEQ 3k0wpKQRFhHWFoKYwUjiHoJKa1xrN6RtKbcp3zn66eU4bh4aKRq3qnp9JrZRMQEBL6kM xSHckFTYKjO9DYuEie13XxqJLgNnhVJ1uJ0ylsF3CRsFFyT3F+7s19Q0qVapFeAkSS+Y AKg5b0MzT1GfJlJn7h1mvUeziyslTseHEdvkg+y1EbqLB4vlFg4Op76IugRx7f0bk7NE xfcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XmoRGMREoULTnILlYwqDFlZQFrc004c7jeFUNQJbjnU=; b=U8Xpx1cEv/iXrNViU7OLB6Cl2bE/JhNB14fEqYQ8D1HBWUBzQ95WFLAc4FYjrYxOr+ xKjiraF+uq05ZwT+ZIFyH4XtVU4dmUiCeyAqA5ZpRJlzvA2CFwwj4fkrQ2eeE5pdizgF rmCvlKXYyfFniOtxDYAYyZz+jC4aw74KWZdw0LwwvwIFl9nl/sc/KK3cLBO53wm8aS34 HvrJ2+M1Bo6HSGkk2sEjJ20wQ1ot6sN6U1+ZcySNMVA+7fCix4R7Ud/J9DGp10Tv7Y7e vjBzeZ/QHGtvDpZljbSYiqM27jldlqzBfnwDyWXG9MXJr7K2mmzNlU1s3AO4npgKboq8 uUdw== X-Gm-Message-State: AKaTC01U4VtFBsnD/DaQxiPW20zzKdn+BluN19w4eLLslWMzLfUtQBIo4WJigT1RoU3tPXIrzmToa19u2akcXw== X-Received: by 10.200.41.171 with SMTP id 40mr94780054qts.235.1481665911557; Tue, 13 Dec 2016 13:51:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.101.180 with HTTP; Tue, 13 Dec 2016 13:51:50 -0800 (PST) In-Reply-To: <004101d25589$a0cd5f20$e2681d60$@gmail.com> References: <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> From: Andy Bierman Date: Tue, 13 Dec 2016 13:51:50 -0800 Message-ID: To: Mehmet Ersue Content-Type: multipart/alternative; boundary=001a1140657855a4ad0543913a0c Archived-At: Cc: NetMod WG Chairs , NetConf WG Chairs , NetMod WG , Netconf Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 21:51:57 -0000 --001a1140657855a4ad0543913a0c Content-Type: text/plain; charset=UTF-8 On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue wrote: > Hi Andy, > > > > > This architectural change needs to be implemented in various protocols. > > > I am not sure a 6241bis is the best approach because it is not clear > which > > > servers really need to implement the revised datastores. > > > > I agree fully. This is the reason why I wrote in my mail: > > > > >> - a new protocol- and language-independent standard document (RFC XYZ) > defining the generic datastore concept and framework and describing its use > (based on and following the DT solution draft), > > >> - a RFC6241bis draft removing the current datasore concept > specification, and getting rid of well-known issues e.g. with the > operation, > > I do not agree with the text you wrote. I do not want to remove candidate, running, and startup from RFC 6241. IMO the new datastores can be defined in a new document that does not redefine the existing datastores. I also do not want to get rid of , It works as intended. It is not a problem on small devices. It is not a problem on large devices if sufficient filtering is used. It does not differentiate between intended and applied config or understand different types of config=false nodes. Use a new operation to add these features. > Mehmet > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Dienstag, 13. Dezember 2016 18:38 > *To:* Eric Voit (evoit) > *Cc:* Ladislav Lhotka ; MehmetErsue ; > NetMod WG Chairs ; NetConf WG Chairs < > netconf-chairs@ietf.org>; NetMod WG ; Netconf < > netconf@ietf.org> > *Subject:* Re: [netmod] [Netconf] WG adoption poll > draft-nmdsdt-netmod-revised-datastores-00 > > > > > > > > On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) > wrote: > > I support adoption, and like Mehmet's thinking as well. > > Also worth focusing on is transport protocol independent yang filtering. > So along with how to frame get operations against one of the datastores, > how do you know which subtrees/nodes should be included/excluded. > > > > > > This architectural change needs to be implemented in various protocols. > > I am not sure a 6241bis is the best approach because it is not clear which > > servers really need to implement the revised datastores. Since RD is > purely optional > > to implement, it should not obsolete 6241 in any way. It should be > possible > > to add new operations and/or new parameters to existing operations without > > needing to redefine what is already there. > > > > The new protocol features need to explain how to include/exclude subtrees. > > IMO we should only support YANG defined data. This allows the solutions > > to be generalized and reusable across protocols (e.g., using YANG > extensions). > > > > > > Eric > > > > > > Andy > > > > > > From: Netconf, December 9, 2016 7:49 AM > > > > Hi Mehmet, > > > > I think I could just sign your text at the bottom. > > > > Lada > > > > > On 9 Dec 2016, at 13:25, MehmetErsue wrote: > > > > > > Hi All, > > > > > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to > adopt and > > finalize the DT draft in NETMOD WG, which I still support. > > > > > > I believe the bigger issue is to agree on a plan concerning the > related work > > and the re-organization of existing standards. As a matter of fact this > plan will > > lead to updating the charter of two WGs and the work we are going to > start. > > > > > > I see the DT document as a datastore solution proposal. There are > different > > gaps and issues which still need to be addressed and the solution > proposal > > needs yet to be discussed and finalized. The document is providing > information > > on the history, explaining the need for a generic solution as well as is > discussing > > different scenarios. As such I believe the datastore solution proposal > from the > > DT should be published with the intended status Informational RFC. > > > > > > Based on the finalized and agreed datastore solution we should do > different > > updates to existing documents in NETCONF and NETMOD WGs. With this > > action we can also fix well-known issues. > > > > > > Concerning the NETCONF WG I would see it as valuable if we develop: > > > - a RFC6241bis draft removing the current datasore concept > > > specification, and getting rid of well-known issues e.g. with the > > > operation, > > > - a new protocol- and language-independent standard document (RFC XYZ) > > > defining the generic datastore concept and framework and describing > > > its use (based on and following the DT solution draft), > > > - adding potential extensions to RFC6241bis (following the DT draft > > > and with a normative reference to RFC XYZ), > > > - adding potential extensions to a RESTCONF-bis RFC (following the DT > > > draft and with a normative reference to RFC XYZ), > > > > > > Concerning the NETMOD WG I would see it as valuable if we develop: > > > - RFC7950bis deleting protocol-dependent details and specifying the > > > datastore usage with YANG on a generic level (with a normative > > > reference to RFC XYZ), > > > - adding potential extensions to RFC7950bis, e.g. concerning the > > > proposed element, > > > - possibly an RFC 6244bis to describe architectural aspects. However > RFC6244 > > is Informational and a RFC6244bis would be still Informational. I'm not > sure > > whether this is really necessary. The DT proposal does already describe > such a > > solution and can be seen as an update to RFC 6244. > > > - RFC6087bis giving guidelines on how to use YANG with the new > datastore > > concept. > > > > > > Referring to Lada's proposal concerning the spin off document from > > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be > > provided in the corresponding protocol RFCs, i.e. > > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and > > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC. > > > > > > Hope this helps as a starting point on the way to a good plan. > > > > > > PS: As Benoit suggested some time ago we might also consider to rename > > NETCONF WG as it is not only on NETCONF protocol anymore. > > > > > > Regards, > > > Mehmet > > > > > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman > > wrote: > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder > > wrote: > > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > > > > > > > I disagree that the datastore model is a protocol specific aspect. > > > > > I consider datastores an architectural component binding data > > > > > models and protocols together. In fact, the 'traditional' > > > > > datastore model > > > > > > > > I would agree with this if datastores were a general concept in > YANG, but > > the revised-datastores draft explicitly introduces the "intended" and > "applied" > > datastores that may be irrelevant to other protocols using YANG, and even > > needn't be used in all NETCONF implementations. I wouldn't call this "an > > architectural component" of YANG. > > > > > > > > > > An architectural component of this new management framework (that does > > > not have a name). The fact that not all protocols may expose all > > > datastores is IMHO not a reason that the datastore model is not an > > > architectural framework. > > > > > > > If you are saying that it will have nontrivial impact on YANG, I > would like to > > see it explained in sec. 6.3. Without this information I am quite > reluctant to > > agree with the adoption. > > > > > > An operational state datastore has implications how one writes data > > > models. It may not directly affect YANG itself but surely the usage of > > > YANG. > > > > > > > See above - architectural aspects need to be relevant to all > protocols. > > > > > > Yes, but relevant to all protocols does not mean every protocol needs > > > to expose say all datastores. But every protocol should be clear about > > > how what it exposes relates to the architectural framework. > > > > > > > > > > > > There is a "current solution" consisting of hard-wired object > > > semantics (e.g., ifAdminStatus and ifOperStatus). This solution does > > > not require special protocols or datastores, but it is being replaced > by a > > generic solution. > > > > > > If the "generic" solution requires special procedures which differ on > > > each protocol, then it might end up be worse than the hard-wired > solution > > that works on every protocol. > > > So I agree with Juergen that this is primarily an architectural issue. > > > > > > > > > /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 > > > -- > > > Cheers, > > > Mehmet > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --001a1140657855a4ad0543913a0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mersue@gmail.com>= wrote:

Hi Andy,

=C2=A0

> This architectural change needs to be impl= emented in various protocols.

> I am not sure a 6241bis is the best approach because= it is not clear which

> servers really need to implement the revised datastores.=C2= =A0

= =C2=A0

I agree fu= lly. This is the reason why I wrote in my mail:

=C2=A0

>> - a new protocol- and language-inde= pendent standard document (RFC XYZ) defining the generic datastore concept = and framework and describing its use (based on and following the DT solutio= n draft),

&g= t;> - a RFC6241bis draft removing the current datasore concept specifica= tion, and getting rid of well-known issues e.g. with the <get> operat= ion,


I do no= t agree with the text you wrote.
I do not want to remove candidat= e, running, and startup from RFC 6241.
IMO the new datastores can= be defined in a new document that does not redefine the existing datastore= s.

I also do not want to get rid of <get>, = =C2=A0It works as intended.
It is not a problem on small devices.= =C2=A0 It is not a problem on large devices if
sufficient filteri= ng is used.=C2=A0 It does not differentiate between intended and applied co= nfig
or understand different types of config=3Dfalse nodes.=C2=A0= Use a new operation to
add these features.

<= div>


=C2=A0

Mehme= t



And= y

=C2=A0

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Dienstag, 13. Dezember 2016 18= :38
To: Eric Voit (evoit) <evoit@cisco.com>
Cc: Ladislav Lhotka <= ;lhotka@nic.cz>; = MehmetErsue <mersu= e@gmail.com>; NetMod WG Chairs <netmod-chairs@ietf.org>; NetConf WG Chair= s <netconf-= chairs@ietf.org>; NetMod WG <netmod@ietf.org>; Netconf <netconf@ietf.org>
Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-= datastores-00

=C2=A0<= u>

=C2=A0

=C2=A0

On Tue, = Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:

I support adoption, and like Mehmet's thin= king as well.

Also worth focusing on is transport protocol independe= nt yang filtering.=C2=A0 So along with how to frame get operations against = one of the datastores, how do you know which subtrees/nodes should be inclu= ded/excluded.

= =C2=A0

=C2=A0=

This architectural change needs to be= implemented in various protocols.

I am not sure a 6241bis is the best approach because it is not c= lear which

servers reall= y need to implement the revised datastores.=C2=A0 Since RD is purely option= al

to implement, it shou= ld not obsolete 6241 in any way.=C2=A0 It should be possible<= /p>

to add new operations and/or new param= eters to existing operations without

needing to redefine what is already there.

=

=C2=A0

The new protocol features need to explain how to include/e= xclude subtrees.

IMO we = should only support YANG defined data.=C2=A0 This allows the solutions

to be generalized and reusab= le across protocols (e.g., using YANG extensions).

<= div>

=C2=A0

=C2=A0

Eric

=

=C2=A0

=C2=A0

Andy

=C2=A0

<= /div>


> From: Netconf, December 9, 2016 7:49 AM
>
> Hi Me= hmet,
>
> I think I could just sign your text at the bottom.>
> Lada
>
> > On 9 Dec 2016, at 13:25, MehmetErsu= e <mersue@gmail.co= m> wrote:
> >
> > Hi All,
> >
> >= ; I think the adoption of the DT draft is fine. We agreed in IETF 97 to ado= pt and
> finalize the DT draft in NETMOD WG, which I still support.> >
> > I believe the bigger issue is to agree on a plan c= oncerning the related work
> and the re-organization of existing stan= dards. As a matter of fact this plan will
> lead to updating the char= ter of two WGs and the work we are going to start.
> >
> >= ; I see the DT document as a datastore solution proposal. There are differe= nt
> gaps and issues which still need to be addressed and the solutio= n proposal
> needs yet to be discussed and finalized. The document is= providing information
> on the history, explaining the need for a ge= neric solution as well as is discussing
> different scenarios. As suc= h I believe the datastore solution proposal from the
> DT should be p= ublished with the intended status Informational RFC.
> >
> &= gt; Based on the finalized and agreed datastore solution we should do diffe= rent
> updates to existing documents in NETCONF and NETMOD WGs. With = this
> action we can also fix well-known issues.
> >
>= > Concerning the NETCONF WG I would see it as valuable if we develop:> > - a RFC6241bis draft removing the current datasore concept
&= gt; > specification, and getting rid of well-known issues e.g. with the<= br>> > <get> operation,
> > - a new protocol- and lang= uage-independent standard document (RFC XYZ)
> > defining the gene= ric datastore concept and framework and describing
> > its use (ba= sed on and following the DT solution draft),
> > - adding potentia= l extensions to RFC6241bis (following the DT draft
> > and with a = normative reference to RFC XYZ),
> > - adding potential extensions= to a RESTCONF-bis RFC (following the DT
> > draft and with a norm= ative reference to RFC XYZ),
> >
> > Concerning the NETMO= D WG I would see it as valuable if we develop:
> > - RFC7950bis de= leting protocol-dependent details and specifying the
> > datastore= usage with YANG on a generic level (with a normative
> > referenc= e to RFC XYZ),
> > - adding potential extensions to RFC7950bis, e.= g. concerning the
> > proposed <notification> element,
&g= t; > - possibly an RFC 6244bis to describe architectural aspects. Howeve= r RFC6244
> is Informational and a RFC6244bis would be still Informat= ional. I'm not sure
> whether this is really necessary. The DT pr= oposal does already describe such a
> solution and can be seen as an = update to RFC 6244.
> > - RFC6087bis giving guidelines on how to u= se YANG with the new datastore
> concept.
> >
> > R= eferring to Lada's proposal concerning the spin off document from
&g= t; > RFC7950 ("Adapting NETCONF for use with YANG"), I think t= his can be
> provided in the corresponding protocol RFCs, i.e.
>= ; > for NETCONF a section on "Using NETCONF with YANG" in RFC6= 241bis and
> for RESTCONF "Using RESTCONF with YANG" in RES= TCONF-bis RFC.
> >
> > Hope this helps as a starting poin= t on the way to a good plan.
> >
> > PS: As Benoit sugges= ted some time ago we might also consider to rename
> NETCONF WG as it= is not only on NETCONF protocol anymore.
> >
> > Regards= ,
> > Mehmet
> >
> > On Mon, Dec 5, 2016 at 6:19= PM Andy Bierman <andy@yumaworks.com>
> wrote:
> > On Mon, Dec 5, 201= 6 at 4:02 AM, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-= university.de> wrote:
> > On Mon, Dec 05, 2016 at 11:36:11A= M +0100, Ladislav Lhotka wrote:
> > >
> > > >> > > > I disagree that the datastore model is a protocol spec= ific aspect.
> > > > I consider datastores an architectural = component binding data
> > > > models and protocols together= . In fact, the 'traditional'
> > > > datastore model=
> > >
> > > I would agree with this if datastores = were a general concept in YANG, but
> the revised-datastores draft ex= plicitly introduces the "intended" and "applied"
>= ; datastores that may be irrelevant to other protocols using YANG, and even=
> needn't be used in all NETCONF implementations. I wouldn't= call this "an
> architectural component" of YANG.
> = > >
> >
> > An architectural component of this new = management framework (that does
> > not have a name). The fact tha= t not all protocols may expose all
> > datastores is IMHO not a re= ason that the datastore model is not an
> > architectural framewor= k.
> >
> > > If you are saying that it will have nontr= ivial impact on YANG, I would like to
> see it explained in sec. 6.3.= Without this information I am quite reluctant to
> agree with the ad= option.
> >
> > An operational state datastore has implic= ations how one writes data
> > models. It may not directly affect = YANG itself but surely the usage of
> > YANG.
> >
>= > > See above - architectural aspects need to be relevant to all pro= tocols.
> >
> > Yes, but relevant to all protocols does n= ot mean every protocol needs
> > to expose say all datastores. But= every protocol should be clear about
> > how what it exposes rela= tes to the architectural framework.
> >
> >
> ><= br>> > There is a "current solution" consisting of hard-wir= ed object
> > semantics (e.g., ifAdminStatus and ifOperStatus).=C2= =A0 This solution does
> > not require special protocols or datast= ores, but it is being replaced by a
> generic solution.
> ><= br>> > If the "generic" solution requires special procedure= s which differ on
> > each protocol, then it might end up be worse= than the hard-wired solution
> that works on every protocol.
>= > So I agree with Juergen that this is primarily an architectural issue= .
> >
> >
> > /js
> >
> > Andy=
> >
> >
> >
> > --
> > Juerge= n Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University B= remen 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-univers= ity.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> &= gt; https://www.ietf.org/mailman/listinfo/netmod
> > --> > Cheers,
> > Mehmet
>
> --
> Ladislav= Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>>
> _______________________________________________
>= Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/li= stinfo/netconf

____________________________________________= ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/n= etmod

=C2=A0