From nobody Fri May 1 02:44:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206CC1B2E65 for ; Fri, 1 May 2015 02:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Efgby12eI0o6 for ; Fri, 1 May 2015 02:44:17 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1BE1ACD52 for ; Fri, 1 May 2015 02:44:16 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 953D013F966; Fri, 1 May 2015 11:44:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1430473453; bh=0AQ523JAvxQ1snwqhu18oPvGkFy7cr81+zMhEnZhgg4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d7RGtvqi1H3bX1bNYAf0pjoXAOtvk1GUghlAAgqc6L+kkBOiRUafueHbM2j8km8TZ couoETUXRjTfaAAw1NT4c6qnkcERSItMgkPnUy5V+UU7SShHjoOJHcFi+qQY+1bPoA 3+BawfK7Fv0WsQmHdYDAaRWQZD/khh6wrztPRTx4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: <554266BB.4060603@seguesoft.com> Date: Fri, 1 May 2015 11:44:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150430102958.GB55253@elstar.local> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <5542457C.3040909@seguesoft.com> <55425A71.3060501@seguesoft.com> <7A79F368-080A-4070-8484-CCA375C4F526@nic.cz> <554266BB.4060603@seguesoft.com> To: Xiang Li X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 09:44:19 -0000 > On 30 Apr 2015, at 19:30, Xiang Li wrote: >=20 >=20 >=20 > On 4/30/2015 12:04 PM, Ladislav Lhotka wrote: >>> On 30 Apr 2015, at 18:38, Xiang Li wrote: >>>=20 >>>=20 >>>=20 >>> On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>>>> On 30 Apr 2015, at 17:08, Xiang Li wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>>>> On 30 Apr 2015, at 15:52, Xiang Li = wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder = wrote: >>>>>>>>>=20 >>>>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka = wrote: >>>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund = wrote: >>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I like to close Y45. It seems most people are fine with = Y45-04. Andy >>>>>>>>>>>>>> may not be fully convinced or he wants a slight change of = Y54-04 that >>>>>>>>>>>>>> turns import-by-revision semantically into = import-by-min-revision. >>>>>>>>>>>>>> Xiang Li seems to support a motion to make = import-by-revision mean >>>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is = to settle on >>>>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean = indeed >>>>>>>>>>>>>> import-by-min-revision. (We would have to write this = variation down >>>>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>>>> Two questions: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 1. Is import-by-revision supposed to mean = import-by-min-revision only >>>>>>>>>>>>> for augments? For groupings and typedefs it should IMO = mean an exact >>>>>>>>>>>>> revision. >>>>>>>>>>>> Yes. >>>>>>>>>>>>=20 >>>>>>>>>>> I guess this would be more than just augments. Essentially = any >>>>>>>>>>> reference to an 'object' defined in an external module, = irrespective >>>>>>>>>>> whether the reference is via augments or a must/when = statement or >>>>>>>>>>> anything else. >>>>>>>>>> For must/when a revision makes even less sense because XPath = expressions refer to an instance document rather than a module. >>>>>>>>>>=20 >>>>>>>>> But isn't the same is true for an augment that refers to a = target that >>>>>>>>> is a list of a container? The target instance must not only be >>>>>>>>> defined, it must also exist for the augment to have an effect. >>>>>>>> No, the target node is by definition a schema node, an augment = manipulates the schema - no instance is involved. >>>>>>>>=20 >>>>>>>>> Anyway, the main idea behind Y45-04 is to use imports to = handle schema >>>>>>>>> tree dependencies that need to be unambiguous at module = compile time >>>>>>>>> and to leave instance tree dependencies to future work (e.g. a = package >>>>>>>>> definition system like Andy once proposed). >>>>>>>> For augments the package is in fact given by the hello message = or other form of data model specification, because an augment makes = sense only if its target node is part of the schema. In fact, not only = revision of the imported module is important here: >>>>>>> "not only revision of the imported module is important..."? >>>>>>>=20 >>>>>>> I thought you have been arguing for the contrary? Did you mean = "not only revision of the advertised module is important=E2=80=A6"? >>>>>> Let=E2=80=99s go back to Andy=E2=80=99s example >>>>>>=20 >>>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>>>>=20 >>>>>> Andy wrote: =E2=80=9CThe 'aug1' developer clearly intends for the = server to support base@2015-01-01.=E2=80=9D >>>>>>=20 >>>>>> But let=E2=80=99s say the new enum in module =E2=80=9Cbase=E2=80=9D= is defined like so: >>>>>>=20 >>>>>> enum fastest { >>>>>> if-feature foo; >>>>>> } >>>>>>=20 >>>>>> Then I could argue that =E2=80=98aug1=E2=80=99 developer clearly = intends for the server to support not only base@2015-01-01 but also = feature foo. However, the latter requirement is not expressed in = import-by-revision. >>>>> Current YANG "enum" does not allow "if-feature" as its = substatement. >>>> Th one in YANG 1.1 proposal does. >>>> =20 >>>>> But in general if things depend on some 'features' implemented in = an augmented >>>>> base module then they are IMO by definition optional. In other = words, 'aug1' developer can't >>>>> demand a server to support feature 'foo', if it is not advertised. = I don't see that's relevant here. >>>> It is relevant - for the sake of this example, base@2015-01-01 = without feature foo is essentially the same as base@2014-01-01. In both = cases the augment from the aug1 module cannot be applied. >>> I think the two scenarios are different. >>>=20 >>> When a client processes anything that involves "if-feature", it = knows it must check if the server >>> advertised that feature. If the feature is not available then it = knows nodes in the aug1 will not be >> Still the same: When a client processes anything that involves data = defined in a new revision of a module, it knows it must check if the = server advertises that new revision (and the server must advertise it in = any case). >=20 > Scenario 1: > * we have enum fastest { if-feature foo; } > * a server advertises "aug1" and base@2015-01-01" (without feature = foo) >=20 > My point is that in this case the server's advertisement is = "consistent". A client > can not assume it can set the leaf to 'fastest' because that involves = a checking > to see feature "foo" is advertised. >=20 > Scenario 2: > * we have enum fastest (i.e. NOT based on feature foo) > * a server advertises "aug1" and base@2014-01-01" >=20 > In this case the advertisement is "inconsistent" because aug1 requires = at least > base@2015-01-01 and should be considered as an "error=E2=80=9D. In fact, it is not an error, it is just that the =E2=80=9Cwhen=E2=80=9D = expression can never be true, so the augment will never be applied. >=20 > When a client sees the server supports "aug1", it should be able to = assume > "base@2015-01-01" must also be supported without having to check the > base version in server's advertisement. How do the two situations differ with respect to applicability of = =E2=80=9Caug1=E2=80=9D? 1. Server doesn=E2=80=99t support base@2015-01-01. 2. Server supports base@2015-01-01 but doesn=E2=80=99t support feature = foo. Lada >=20 > --Xiang -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri May 1 03:25:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991981B30EB for ; Fri, 1 May 2015 03:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0wYYwLJhQLg for ; Fri, 1 May 2015 03:25:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AB81B30EA for ; Fri, 1 May 2015 03:25:01 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id C73A113FE27; Fri, 1 May 2015 12:24:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1430475899; bh=qNXfVipGF2d4a6OQhp6WistnZiZ1zMnAlkaKibzab6I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hqDu2DYXcxMUQl3co9Y98IJzZruR1/B0Y9jl3HP/HkFCLwFCHUtzQe39Pfiz+JgJX KI3gppPdTVFrHWzdXG8inF+h4OQ3OhkqKDCgJsRZJLIpsBkKs0pXOZgsOtQcLhky3S BMDejZdmr12w/j2SIusiFzXlWPkxfJ35LtgNGQHs= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 1 May 2015 12:25:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150430102958.GB55253@elstar.local> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <5542457C.3040909@seguesoft.com> <55425A71.3060501@seguesoft.com> <46CE075C-72CE-4E89-867F-3C751990967D@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 10:25:05 -0000 > On 30 Apr 2015, at 19:22, Andy Bierman wrote: >=20 > On Thu, Apr 30, 2015 at 10:13 AM, Ladislav Lhotka = wrote: >>=20 >>> On 30 Apr 2015, at 18:50, Andy Bierman wrote: >>>=20 >>> On Thu, Apr 30, 2015 at 9:38 AM, Xiang Li = wrote: >>>>=20 >>>>=20 >>>> On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>>>>>=20 >>>>>> On 30 Apr 2015, at 17:08, Xiang Li wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>> On 30 Apr 2015, at 15:52, Xiang Li = wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>>>>>=20 >>>>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund = wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I like to close Y45. It seems most people are fine with = Y45-04. >>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>> may not be fully convinced or he wants a slight change = of Y54-04 >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> turns import-by-revision semantically into >>>>>>>>>>>>>>> import-by-min-revision. >>>>>>>>>>>>>>> Xiang Li seems to support a motion to make = import-by-revision >>>>>>>>>>>>>>> mean >>>>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution = is to >>>>>>>>>>>>>>> settle on >>>>>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean = indeed >>>>>>>>>>>>>>> import-by-min-revision. (We would have to write this = variation >>>>>>>>>>>>>>> down >>>>>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Two questions: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 1. Is import-by-revision supposed to mean = import-by-min-revision >>>>>>>>>>>>>> only >>>>>>>>>>>>>> for augments? For groupings and typedefs it should IMO = mean an >>>>>>>>>>>>>> exact >>>>>>>>>>>>>> revision. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Yes. >>>>>>>>>>>>>=20 >>>>>>>>>>>> I guess this would be more than just augments. Essentially = any >>>>>>>>>>>> reference to an 'object' defined in an external module, >>>>>>>>>>>> irrespective >>>>>>>>>>>> whether the reference is via augments or a must/when = statement or >>>>>>>>>>>> anything else. >>>>>>>>>>>=20 >>>>>>>>>>> For must/when a revision makes even less sense because XPath >>>>>>>>>>> expressions refer to an instance document rather than a = module. >>>>>>>>>>>=20 >>>>>>>>>> But isn't the same is true for an augment that refers to a = target >>>>>>>>>> that >>>>>>>>>> is a list of a container? The target instance must not only = be >>>>>>>>>> defined, it must also exist for the augment to have an = effect. >>>>>>>>>=20 >>>>>>>>> No, the target node is by definition a schema node, an augment >>>>>>>>> manipulates the schema - no instance is involved. >>>>>>>>>=20 >>>>>>>>>> Anyway, the main idea behind Y45-04 is to use imports to = handle >>>>>>>>>> schema >>>>>>>>>> tree dependencies that need to be unambiguous at module = compile time >>>>>>>>>> and to leave instance tree dependencies to future work (e.g. = a >>>>>>>>>> package >>>>>>>>>> definition system like Andy once proposed). >>>>>>>>>=20 >>>>>>>>> For augments the package is in fact given by the hello message = or >>>>>>>>> other form of data model specification, because an augment = makes sense only >>>>>>>>> if its target node is part of the schema. In fact, not only = revision of the >>>>>>>>> imported module is important here: >>>>>>>>=20 >>>>>>>> "not only revision of the imported module is important..."? >>>>>>>>=20 >>>>>>>> I thought you have been arguing for the contrary? Did you mean = "not >>>>>>>> only revision of the advertised module is important=E2=80=A6"? >>>>>>>=20 >>>>>>> Let=E2=80=99s go back to Andy=E2=80=99s example >>>>>>>=20 >>>>>>> = http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>>>>>=20 >>>>>>> Andy wrote: =E2=80=9CThe 'aug1' developer clearly intends for = the server to >>>>>>> support base@2015-01-01.=E2=80=9D >>>>>>>=20 >>>>>>> But let=E2=80=99s say the new enum in module =E2=80=9Cbase=E2=80=9D= is defined like so: >>>>>>>=20 >>>>>>> enum fastest { >>>>>>> if-feature foo; >>>>>>> } >>>>>>>=20 >>>>>>> Then I could argue that =E2=80=98aug1=E2=80=99 developer clearly = intends for the server >>>>>>> to support not only base@2015-01-01 but also feature foo. = However, the >>>>>>> latter requirement is not expressed in import-by-revision. >>>>>>=20 >>>>>> Current YANG "enum" does not allow "if-feature" as its = substatement. >>>>>=20 >>>>>=20 >>>>> Th one in YANG 1.1 proposal does. >>>>>=20 >>>>>>=20 >>>>>> But in general if things depend on some 'features' implemented in = an >>>>>> augmented >>>>>> base module then they are IMO by definition optional. In other = words, >>>>>> 'aug1' developer can't >>>>>> demand a server to support feature 'foo', if it is not = advertised. I >>>>>> don't see that's relevant here. >>>>>=20 >>>>> It is relevant - for the sake of this example, base@2015-01-01 = without >>>>> feature foo is essentially the same as base@2014-01-01. In both = cases the >>>>> augment from the aug1 module cannot be applied. >>>>=20 >>>>=20 >>>> I think the two scenarios are different. >>>>=20 >>>=20 >>> quite different. >>>=20 >>> The original point is that the designer of "aug1" is using >>> definitions from the new "base" module. There is no way >>> that the server can implement this "aug1" module using the >>> old "base" module. >>>=20 >>> The server does not support the new "fastest" enum. It is a lie to >>> advertise that the leaf using this typedef is supported. >>=20 >> The server advertises the old revision of =E2=80=9Cbase, thus making = clear that is does *not* support the new =E2=80=9Cfastest=E2=80=9D enum. = Therefore, it doesn=E2=80=99t lie. Note that the fact that the augment = in =E2=80=98aug1=E2=80=99 doesn=E2=80=99t happen isn=E2=80=99t an error = from the YANG point of view - it just may or may not be what the server = implementer intended. >>=20 >=20 > If it advertises the old version of "base" then it cannot advertise = "aug1". > The client sees that advertisement and believes that the new revision > of the typedef is supported. It has no reason to suspect that setting If Y45-04 is accepted, the client can never believe the new revision is = supported because it is clearly stated that the revision of the import = is ignored for augments. That is: - if a module is imported only for referring to its nodes (augments, = leafrefs, must/when), then the =20 import should be without revision because revision-date would be = ignored anyway. - if groupings or typedefs from the imported module are used, then the = exact revision of each is always =20 known either from revision-date, if present, or from server=E2=80=99s = advertisement. I don=E2=80=99t think it it that complicated. > the leaf to 'fastest' is going to fail. >=20 > This is not typedef drift. > The requirements for "base" are quite clear for both revisions. > The server can advertise either one. > The server does not meet the requirements for "aug1" if > it only supports the old base module. If the client has such a requirement, it can immediately see from the = server=E2=80=99s advertisement that it is not fulfilled, and close the = session or whatever. It would be nice to have the ability to formally = state conformance, e.g. - module =E2=80=98aug1=E2=80=99 needs =E2=80=98base=E2=80=99 at the = minimum revision 2015-01-01, or - module =E2=80=98aug1=E2=80=99 needs =E2=80=98base=E2=80=99 at the = minimum revision 2015-01-01 && support for feature foo. Imports cannot really do this and, moreover, similar statements might = IMO be necessary even if neither module imports the other.=20 A big benefit of Y45-04 there it removes all ambiguity in the imported = revisions of typedefs and groupings. After reading Y45-05, I still prefer -04 with Juergen=E2=80=99s = commentary about future work on conformance - and I am willing to take = part in such a work after YANG 1.1 is done. Lada >=20 >=20 >=20 >> Lada >>=20 >=20 > Andy >=20 >>>=20 >>> Andy >>>=20 >>>=20 >>>=20 >>>> When a client processes anything that involves "if-feature", it = knows it >>>> must check if the server >>>> advertised that feature. If the feature is not available then it = knows nodes >>>> in the aug1 will not be >>>> available. The contract is not broken because in this case "aug1" = is >>>> *effectively*a conditional augment. >>>>=20 >>>>=20 >>>> --Xiang >>>>=20 >>>>=20 >>>>=20 >>>>> I am not saying it is a problem but the two situations are = effectively >>>>> identical. >>>>>=20 >>>>> My point is that for processing augments and leafrefs, a more = complete >>>>> conformance information has to be supplied anyway, so taking into = account >>>>> revisions in import statements is not really needed. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Lada >>>>>=20 >>>>>> --Xiang >>>>>=20 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri May 1 08:25:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD691A01F9 for ; Fri, 1 May 2015 08:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZItsO2tFR32t for ; Fri, 1 May 2015 08:25:03 -0700 (PDT) Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65B11ACD2E for ; Fri, 1 May 2015 08:25:03 -0700 (PDT) Received: from [192.168.2.33] ([73.8.162.228]) by p3plsmtpa12-10.prod.phx3.secureserver.net with id NfR21q00E4vySjM01fR2dM; Fri, 01 May 2015 08:25:03 -0700 Message-ID: <55439ACF.3020006@seguesoft.com> Date: Fri, 01 May 2015 10:25:03 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <20150430102958.GB55253@elstar.local> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <5542457C.3040909@seguesoft.com> <55425A71.3060501@seguesoft.com> <7A79F368-080A-4070-8484-CCA375C4F526@nic.cz> <554266BB.4060603@seguesoft.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 15:25:08 -0000 On 5/1/2015 4:44 AM, Ladislav Lhotka wrote: >> On 30 Apr 2015, at 19:30, Xiang Li wrote: >> >> >> >> On 4/30/2015 12:04 PM, Ladislav Lhotka wrote: >>>> On 30 Apr 2015, at 18:38, Xiang Li wrote: >>>> >>>> >>>> >>>> On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>>>>> On 30 Apr 2015, at 17:08, Xiang Li wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>>>>> On 30 Apr 2015, at 15:52, Xiang Li wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder wrote: >>>>>>>>>> >>>>>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote: >>>>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund wrote: >>>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I like to close Y45. It seems most people are fine with Y45-04. Andy >>>>>>>>>>>>>>> may not be fully convinced or he wants a slight change of Y54-04 that >>>>>>>>>>>>>>> turns import-by-revision semantically into import-by-min-revision. >>>>>>>>>>>>>>> Xiang Li seems to support a motion to make import-by-revision mean >>>>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is to settle on >>>>>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean indeed >>>>>>>>>>>>>>> import-by-min-revision. (We would have to write this variation down >>>>>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>>>>> Two questions: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Is import-by-revision supposed to mean import-by-min-revision only >>>>>>>>>>>>>> for augments? For groupings and typedefs it should IMO mean an exact >>>>>>>>>>>>>> revision. >>>>>>>>>>>>> Yes. >>>>>>>>>>>>> >>>>>>>>>>>> I guess this would be more than just augments. Essentially any >>>>>>>>>>>> reference to an 'object' defined in an external module, irrespective >>>>>>>>>>>> whether the reference is via augments or a must/when statement or >>>>>>>>>>>> anything else. >>>>>>>>>>> For must/when a revision makes even less sense because XPath expressions refer to an instance document rather than a module. >>>>>>>>>>> >>>>>>>>>> But isn't the same is true for an augment that refers to a target that >>>>>>>>>> is a list of a container? The target instance must not only be >>>>>>>>>> defined, it must also exist for the augment to have an effect. >>>>>>>>> No, the target node is by definition a schema node, an augment manipulates the schema - no instance is involved. >>>>>>>>> >>>>>>>>>> Anyway, the main idea behind Y45-04 is to use imports to handle schema >>>>>>>>>> tree dependencies that need to be unambiguous at module compile time >>>>>>>>>> and to leave instance tree dependencies to future work (e.g. a package >>>>>>>>>> definition system like Andy once proposed). >>>>>>>>> For augments the package is in fact given by the hello message or other form of data model specification, because an augment makes sense only if its target node is part of the schema. In fact, not only revision of the imported module is important here: >>>>>>>> "not only revision of the imported module is important..."? >>>>>>>> >>>>>>>> I thought you have been arguing for the contrary? Did you mean "not only revision of the advertised module is important…"? >>>>>>> Let’s go back to Andy’s example >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>>>>> >>>>>>> Andy wrote: “The 'aug1' developer clearly intends for the server to support base@2015-01-01.” >>>>>>> >>>>>>> But let’s say the new enum in module “base” is defined like so: >>>>>>> >>>>>>> enum fastest { >>>>>>> if-feature foo; >>>>>>> } >>>>>>> >>>>>>> Then I could argue that ‘aug1’ developer clearly intends for the server to support not only base@2015-01-01 but also feature foo. However, the latter requirement is not expressed in import-by-revision. >>>>>> Current YANG "enum" does not allow "if-feature" as its substatement. >>>>> Th one in YANG 1.1 proposal does. >>>>> >>>>>> But in general if things depend on some 'features' implemented in an augmented >>>>>> base module then they are IMO by definition optional. In other words, 'aug1' developer can't >>>>>> demand a server to support feature 'foo', if it is not advertised. I don't see that's relevant here. >>>>> It is relevant - for the sake of this example, base@2015-01-01 without feature foo is essentially the same as base@2014-01-01. In both cases the augment from the aug1 module cannot be applied. >>>> I think the two scenarios are different. >>>> >>>> When a client processes anything that involves "if-feature", it knows it must check if the server >>>> advertised that feature. If the feature is not available then it knows nodes in the aug1 will not be >>> Still the same: When a client processes anything that involves data defined in a new revision of a module, it knows it must check if the server advertises that new revision (and the server must advertise it in any case). >> Scenario 1: >> * we have enum fastest { if-feature foo; } >> * a server advertises "aug1" and base@2015-01-01" (without feature foo) >> >> My point is that in this case the server's advertisement is "consistent". A client >> can not assume it can set the leaf to 'fastest' because that involves a checking >> to see feature "foo" is advertised. >> >> Scenario 2: >> * we have enum fastest (i.e. NOT based on feature foo) >> * a server advertises "aug1" and base@2014-01-01" >> >> In this case the advertisement is "inconsistent" because aug1 requires at least >> base@2015-01-01 and should be considered as an "error”. > In fact, it is not an error, When the server advertises it supports "aug1", *currently, at them time, it is stating that it also supports base@2015-01-01. Bu then the server is advertising base@2014-01-01. So you see the server's advertisement is contradicting itself. In other words, the conformance requirement set by the module designer of "aug1" is not honored by the server at runtime. Because of that the server's implementation is not compliant to "aug1". ?it is just that the “when” expression can never be true, so the augment will never be >applied. The problem is the designer of "aug1" assumes that "when" must be able to be evaluated to "True". Thanks -Xiang From nobody Fri May 1 09:05:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0EE1A6EDE for ; Fri, 1 May 2015 09:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHGJrBIWoMkP for ; Fri, 1 May 2015 09:05:13 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 BDE841A877D for ; Fri, 1 May 2015 09:04:50 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so67426397lbc.1 for ; Fri, 01 May 2015 09:04:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qtCx4CV439cQQ/2/QzBpTlSLXkf/EIuQy5OpH/cwLPw=; b=C4HXxAiDb7mge5sZzHqcitwIcDEPuBKeUBx6rCc+Sjn6KUL0PzzwaRqxqM/HuH6Zcx sb9cqSewvO7syGPjDfjMJugBZqlmT9hFLKGRAChpqmZsFmZ3NuC9B6m91ptYYglc7LPM /E0cvjerTsnxHiGHVJ22+CFH6E/GW6k8lN8TZMLdodA5ssffYPSi57vQgxrTMRLmbnAl RqoGxGvSu3RsdbWJNu5XY95spYbvUxj0O21QiG9pqeO8MDE4cvUk18/0LBAdbr3a+hGB G9pHaOExvDGE/w6IKU1yyWq4XncgtKVkGHbvRU3+mSX0kLw6oon+hmVA2ukT+Oq82fzM QCBw== X-Gm-Message-State: ALoCoQlzFsNqIAdjyPrPV2vnv05PRNEc4AUeRU5ItT3YbmkyyE+3vkeeT2hDWluip0A99NXnG0uP MIME-Version: 1.0 X-Received: by 10.112.139.130 with SMTP id qy2mr8789202lbb.33.1430496289226; Fri, 01 May 2015 09:04:49 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 1 May 2015 09:04:49 -0700 (PDT) In-Reply-To: <55439ACF.3020006@seguesoft.com> References: <20150430102958.GB55253@elstar.local> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <5542457C.3040909@seguesoft.com> <55425A71.3060501@seguesoft.com> <7A79F368-080A-4070-8484-CCA375C4F526@nic.cz> <554266BB.4060603@seguesoft.com> <55439ACF.3020006@seguesoft.com> Date: Fri, 1 May 2015 09:04:49 -0700 Message-ID: From: Andy Bierman To: Xiang Li Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 16:05:16 -0000 On Fri, May 1, 2015 at 8:25 AM, Xiang Li wrote: > > > On 5/1/2015 4:44 AM, Ladislav Lhotka wrote: >>> >>> On 30 Apr 2015, at 19:30, Xiang Li wrote: >>> >>> >>> >>> On 4/30/2015 12:04 PM, Ladislav Lhotka wrote: >>>>> >>>>> On 30 Apr 2015, at 18:38, Xiang Li wrote: >>>>> >>>>> >>>>> >>>>> On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>>>>>> >>>>>>> On 30 Apr 2015, at 17:08, Xiang Li wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>>>>>> >>>>>>>>> On 30 Apr 2015, at 15:52, Xiang Li wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>>>>>> >>>>>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote= : >>>>>>>>>>>>> >>>>>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I like to close Y45. It seems most people are fine with >>>>>>>>>>>>>>>> Y45-04. Andy >>>>>>>>>>>>>>>> may not be fully convinced or he wants a slight change of >>>>>>>>>>>>>>>> Y54-04 that >>>>>>>>>>>>>>>> turns import-by-revision semantically into >>>>>>>>>>>>>>>> import-by-min-revision. >>>>>>>>>>>>>>>> Xiang Li seems to support a motion to make >>>>>>>>>>>>>>>> import-by-revision mean >>>>>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is = to >>>>>>>>>>>>>>>> settle on >>>>>>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean >>>>>>>>>>>>>>>> indeed >>>>>>>>>>>>>>>> import-by-min-revision. (We would have to write this >>>>>>>>>>>>>>>> variation down >>>>>>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Two questions: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Is import-by-revision supposed to mean >>>>>>>>>>>>>>> import-by-min-revision only >>>>>>>>>>>>>>> for augments? For groupings and typedefs it should IMO mean >>>>>>>>>>>>>>> an exact >>>>>>>>>>>>>>> revision. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>> >>>>>>>>>>>>> I guess this would be more than just augments. Essentially an= y >>>>>>>>>>>>> reference to an 'object' defined in an external module, >>>>>>>>>>>>> irrespective >>>>>>>>>>>>> whether the reference is via augments or a must/when statemen= t >>>>>>>>>>>>> or >>>>>>>>>>>>> anything else. >>>>>>>>>>>> >>>>>>>>>>>> For must/when a revision makes even less sense because XPath >>>>>>>>>>>> expressions refer to an instance document rather than a module= . >>>>>>>>>>>> >>>>>>>>>>> But isn't the same is true for an augment that refers to a targ= et >>>>>>>>>>> that >>>>>>>>>>> is a list of a container? The target instance must not only be >>>>>>>>>>> defined, it must also exist for the augment to have an effect. >>>>>>>>>> >>>>>>>>>> No, the target node is by definition a schema node, an augment >>>>>>>>>> manipulates the schema - no instance is involved. >>>>>>>>>> >>>>>>>>>>> Anyway, the main idea behind Y45-04 is to use imports to handle >>>>>>>>>>> schema >>>>>>>>>>> tree dependencies that need to be unambiguous at module compile >>>>>>>>>>> time >>>>>>>>>>> and to leave instance tree dependencies to future work (e.g. a >>>>>>>>>>> package >>>>>>>>>>> definition system like Andy once proposed). >>>>>>>>>> >>>>>>>>>> For augments the package is in fact given by the hello message o= r >>>>>>>>>> other form of data model specification, because an augment makes= sense only >>>>>>>>>> if its target node is part of the schema. In fact, not only revi= sion of the >>>>>>>>>> imported module is important here: >>>>>>>>> >>>>>>>>> "not only revision of the imported module is important..."? >>>>>>>>> >>>>>>>>> I thought you have been arguing for the contrary? Did you mean "n= ot >>>>>>>>> only revision of the advertised module is important=E2=80=A6"? >>>>>>>> >>>>>>>> Let=E2=80=99s go back to Andy=E2=80=99s example >>>>>>>> >>>>>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>>>>>> >>>>>>>> Andy wrote: =E2=80=9CThe 'aug1' developer clearly intends for the = server to >>>>>>>> support base@2015-01-01.=E2=80=9D >>>>>>>> >>>>>>>> But let=E2=80=99s say the new enum in module =E2=80=9Cbase=E2=80= =9D is defined like so: >>>>>>>> >>>>>>>> enum fastest { >>>>>>>> if-feature foo; >>>>>>>> } >>>>>>>> >>>>>>>> Then I could argue that =E2=80=98aug1=E2=80=99 developer clearly i= ntends for the >>>>>>>> server to support not only base@2015-01-01 but also feature foo. H= owever, >>>>>>>> the latter requirement is not expressed in import-by-revision. >>>>>>> >>>>>>> Current YANG "enum" does not allow "if-feature" as its substatemen= t. >>>>>> >>>>>> Th one in YANG 1.1 proposal does. >>>>>> >>>>>>> >>>>>>> But in general if things depend on some 'features' implemented in a= n >>>>>>> augmented >>>>>>> base module then they are IMO by definition optional. In other word= s, >>>>>>> 'aug1' developer can't >>>>>>> demand a server to support feature 'foo', if it is not advertised. = I >>>>>>> don't see that's relevant here. >>>>>> >>>>>> It is relevant - for the sake of this example, base@2015-01-01 witho= ut >>>>>> feature foo is essentially the same as base@2014-01-01. In both case= s the >>>>>> augment from the aug1 module cannot be applied. >>>>> >>>>> I think the two scenarios are different. >>>>> >>>>> When a client processes anything that involves "if-feature", it knows >>>>> it must check if the server >>>>> advertised that feature. If the feature is not available then it know= s >>>>> nodes in the aug1 will not be >>>> >>>> Still the same: When a client processes anything that involves data >>>> defined in a new revision of a module, it knows it must check if the s= erver >>>> advertises that new revision (and the server must advertise it in any = case). >>> >>> Scenario 1: >>> * we have enum fastest { if-feature foo; } >>> * a server advertises "aug1" and base@2015-01-01" (without feature fo= o) >>> >>> My point is that in this case the server's advertisement is >>> "consistent". A client >>> can not assume it can set the leaf to 'fastest' because that involves a >>> checking >>> to see feature "foo" is advertised. >>> >>> Scenario 2: >>> * we have enum fastest (i.e. NOT based on feature foo) >>> * a server advertises "aug1" and base@2014-01-01" >>> >>> In this case the advertisement is "inconsistent" because aug1 requires = at >>> least >>> base@2015-01-01 and should be considered as an "error=E2=80=9D. >> >> In fact, it is not an error, > > > When the server advertises it supports "aug1", *currently, at them time, = it > is stating that it > also supports base@2015-01-01. Bu then the server is advertising > base@2014-01-01. > So you see the server's advertisement is contradicting itself. > > In other words, the conformance requirement set by the module designer o= f > "aug1" is > not honored by the server at runtime. Because of that the server's > implementation is > not compliant to "aug1". > > ?it is just that the =E2=80=9Cwhen=E2=80=9D expression can never be true,= so the augment > will never be >applied. > > > The problem is the designer of "aug1" assumes that "when" must be able to= be > evaluated to "True". > The problem is also the other leaf: augment b:/port-knob { when "b:knob-type =3D 'faster'"; leaf alt-knob-type { type b:port-knob-type; } } According to the solution proposal, b:port-knob-type is the new typedef (that includes the new enum). Even though the server can implement 'faster', so the when-stmt might be true, it cannot augment the base object with a leaf using the new typedef. A client will assume that 'alt-knob-type' can be set to 'fastest', but it will fail. In other words, there isn't 1 single thing from "aug1" that the server can honor, so it cannot advertise this module unless it also advertises 'base@2015-01-01'. > Thanks > -Xiang Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri May 1 09:26:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4916D1A8935 for ; Fri, 1 May 2015 09:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7x7MbDkDxXN for ; Fri, 1 May 2015 09:26:08 -0700 (PDT) Received: from p3plsmtpa12-07.prod.phx3.secureserver.net (p3plsmtpa12-07.prod.phx3.secureserver.net [68.178.252.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EBE21A9152 for ; Fri, 1 May 2015 09:26:02 -0700 (PDT) Received: from [192.168.2.33] ([73.8.162.228]) by p3plsmtpa12-07.prod.phx3.secureserver.net with id NgS01q00D4vySjM01gS1X5; Fri, 01 May 2015 09:26:02 -0700 Message-ID: <5543A919.7000309@seguesoft.com> Date: Fri, 01 May 2015 11:26:01 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ladislav Lhotka , Andy Bierman References: <20150430102958.GB55253@elstar.local> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <5542457C.3040909@seguesoft.com> <55425A71.3060501@seguesoft.com> <46CE075C-72CE-4E89-867F-3C751990967D@nic.cz> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 16:26:10 -0000 On 5/1/2015 5:25 AM, Ladislav Lhotka wrote: >> On 30 Apr 2015, at 19:22, Andy Bierman wrote: >> >> On Thu, Apr 30, 2015 at 10:13 AM, Ladislav Lhotka wrote: >>>> On 30 Apr 2015, at 18:50, Andy Bierman wrote: >>>> >>>> On Thu, Apr 30, 2015 at 9:38 AM, Xiang Li wrote: >>>>> >>>>> On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>>>>>> On 30 Apr 2015, at 17:08, Xiang Li wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>>>>>> On 30 Apr 2015, at 15:52, Xiang Li wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote: >>>>>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund wrote: >>>>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I like to close Y45. It seems most people are fine with Y45-04. >>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>> may not be fully convinced or he wants a slight change of Y54-04 >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> turns import-by-revision semantically into >>>>>>>>>>>>>>>> import-by-min-revision. >>>>>>>>>>>>>>>> Xiang Li seems to support a motion to make import-by-revision >>>>>>>>>>>>>>>> mean >>>>>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is to >>>>>>>>>>>>>>>> settle on >>>>>>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean indeed >>>>>>>>>>>>>>>> import-by-min-revision. (We would have to write this variation >>>>>>>>>>>>>>>> down >>>>>>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>>>>>> Two questions: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Is import-by-revision supposed to mean import-by-min-revision >>>>>>>>>>>>>>> only >>>>>>>>>>>>>>> for augments? For groupings and typedefs it should IMO mean an >>>>>>>>>>>>>>> exact >>>>>>>>>>>>>>> revision. >>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>> >>>>>>>>>>>>> I guess this would be more than just augments. Essentially any >>>>>>>>>>>>> reference to an 'object' defined in an external module, >>>>>>>>>>>>> irrespective >>>>>>>>>>>>> whether the reference is via augments or a must/when statement or >>>>>>>>>>>>> anything else. >>>>>>>>>>>> For must/when a revision makes even less sense because XPath >>>>>>>>>>>> expressions refer to an instance document rather than a module. >>>>>>>>>>>> >>>>>>>>>>> But isn't the same is true for an augment that refers to a target >>>>>>>>>>> that >>>>>>>>>>> is a list of a container? The target instance must not only be >>>>>>>>>>> defined, it must also exist for the augment to have an effect. >>>>>>>>>> No, the target node is by definition a schema node, an augment >>>>>>>>>> manipulates the schema - no instance is involved. >>>>>>>>>> >>>>>>>>>>> Anyway, the main idea behind Y45-04 is to use imports to handle >>>>>>>>>>> schema >>>>>>>>>>> tree dependencies that need to be unambiguous at module compile time >>>>>>>>>>> and to leave instance tree dependencies to future work (e.g. a >>>>>>>>>>> package >>>>>>>>>>> definition system like Andy once proposed). >>>>>>>>>> For augments the package is in fact given by the hello message or >>>>>>>>>> other form of data model specification, because an augment makes sense only >>>>>>>>>> if its target node is part of the schema. In fact, not only revision of the >>>>>>>>>> imported module is important here: >>>>>>>>> "not only revision of the imported module is important..."? >>>>>>>>> >>>>>>>>> I thought you have been arguing for the contrary? Did you mean "not >>>>>>>>> only revision of the advertised module is important…"? >>>>>>>> Let’s go back to Andy’s example >>>>>>>> >>>>>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>>>>>> >>>>>>>> Andy wrote: “The 'aug1' developer clearly intends for the server to >>>>>>>> support base@2015-01-01.” >>>>>>>> >>>>>>>> But let’s say the new enum in module “base” is defined like so: >>>>>>>> >>>>>>>> enum fastest { >>>>>>>> if-feature foo; >>>>>>>> } >>>>>>>> >>>>>>>> Then I could argue that ‘aug1’ developer clearly intends for the server >>>>>>>> to support not only base@2015-01-01 but also feature foo. However, the >>>>>>>> latter requirement is not expressed in import-by-revision. >>>>>>> Current YANG "enum" does not allow "if-feature" as its substatement. >>>>>> >>>>>> Th one in YANG 1.1 proposal does. >>>>>> >>>>>>> But in general if things depend on some 'features' implemented in an >>>>>>> augmented >>>>>>> base module then they are IMO by definition optional. In other words, >>>>>>> 'aug1' developer can't >>>>>>> demand a server to support feature 'foo', if it is not advertised. I >>>>>>> don't see that's relevant here. >>>>>> It is relevant - for the sake of this example, base@2015-01-01 without >>>>>> feature foo is essentially the same as base@2014-01-01. In both cases the >>>>>> augment from the aug1 module cannot be applied. >>>>> >>>>> I think the two scenarios are different. >>>>> >>>> quite different. >>>> >>>> The original point is that the designer of "aug1" is using >>>> definitions from the new "base" module. There is no way >>>> that the server can implement this "aug1" module using the >>>> old "base" module. >>>> >>>> The server does not support the new "fastest" enum. It is a lie to >>>> advertise that the leaf using this typedef is supported. >>> The server advertises the old revision of “base, thus making clear that is does *not* support the new “fastest” enum. Therefore, it doesn’t lie. Note that the fact that the augment in ‘aug1’ doesn’t happen isn’t an error from the YANG point of view - it just may or may not be what the server implementer intended. >>> >> If it advertises the old version of "base" then it cannot advertise "aug1". >> The client sees that advertisement and believes that the new revision >> of the typedef is supported. It has no reason to suspect that setting > If Y45-04 is accepted, the client can never believe the new revision is supported because it is clearly stated that the revision of the import is ignored for augments. That is what I still have doubt whether it is a good thing to do. > That is: > > - if a module is imported only for referring to its nodes (augments, leafrefs, must/when), then the > import should be without revision because revision-date would be ignored anyway. Why "revision-date" in this case must be ignored completely? If we do this, the author of "aug1" can not decide the version where he/she wants to start. I think it makes sense for the author of "aug1" to be able to do that and set up some basic requirements for the implementer of "aug1", and that's why I said I prefer for "augment" to use "min-revision-rule", unless it's the intention of the working group to prevent the author of "agu1" from doing that for other legitimate reasons that I missed. > - if groupings or typedefs from the imported module are used, then the exact revision of each is always > known either from revision-date, if present, or from server’s advertisement. We already agreed on this. We are not ignoring "revision-date" in this case either. -Xiang > I don’t think it it that complicated. No... Indeed it's not... -Xiang From nobody Fri May 1 09:43:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9FD1A9239 for ; Fri, 1 May 2015 09:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-JswsvVFdTx for ; Fri, 1 May 2015 09:43:36 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (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 547191A9166 for ; Fri, 1 May 2015 09:43:36 -0700 (PDT) Received: by labbd9 with SMTP id bd9so67474771lab.2 for ; Fri, 01 May 2015 09:43:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D9BuFtJIKr4LFk4HVnvXQilUt87qTJo0lzKY7oYEbXs=; b=a1ia3NWoZMcxp8Pjozn3hc5nO+RCJOi3x92/gY5k/T18MXg26lnGp3DAA4PQ/xRYAc GrPpdBQBqgs9DTgRGIZI1xQZTeqlu8+4TrDRfhut563SsIUICbCsdw4FemLcoj0psW/A 9ELFT5ohRBRXQptbTjA+w3EJ9ZBqQjCkkxhuLtZLXO2k3NS5bzoT0TUBp28yaTBC0YI9 oEOfHRumM1e16y3sTKYsGcyi2sCM/3YmCMRlfFaGGu9I3aRDsOUUEd58/3ni9eVQ1FCR iYthu4fORRTZYPNdsJ22r/FOO1yT4Cyo/ej2ywUvaTwl7foLd45GjH/8XfTKgTFrh0RE ddqA== X-Gm-Message-State: ALoCoQnpaTgdKSqKs0hL+YrJ+0k4+Qd0pOH7s+eGA+7RYGiRwpRVr5tonRtLv9Srk37dmSHa7Fh6 MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr8901652laj.88.1430498614695; Fri, 01 May 2015 09:43:34 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 1 May 2015 09:43:34 -0700 (PDT) In-Reply-To: <5543A919.7000309@seguesoft.com> References: <20150430102958.GB55253@elstar.local> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <5542457C.3040909@seguesoft.com> <55425A71.3060501@seguesoft.com> <46CE075C-72CE-4E89-867F-3C751990967D@nic.cz> <5543A919.7000309@seguesoft.com> Date: Fri, 1 May 2015 09:43:34 -0700 Message-ID: From: Andy Bierman To: Xiang Li Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 16:43:39 -0000 On Fri, May 1, 2015 at 9:26 AM, Xiang Li wrote: > > > On 5/1/2015 5:25 AM, Ladislav Lhotka wrote: >>> >>> On 30 Apr 2015, at 19:22, Andy Bierman wrote: >>> >>> On Thu, Apr 30, 2015 at 10:13 AM, Ladislav Lhotka wrote= : >>>>> >>>>> On 30 Apr 2015, at 18:50, Andy Bierman wrote: >>>>> >>>>> On Thu, Apr 30, 2015 at 9:38 AM, Xiang Li >>>>> wrote: >>>>>> >>>>>> >>>>>> On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>>>>>>> >>>>>>>> On 30 Apr 2015, at 17:08, Xiang Li wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>>>>>>> >>>>>>>>>> On 30 Apr 2015, at 15:52, Xiang Li wrote= : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrot= e: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I like to close Y45. It seems most people are fine with >>>>>>>>>>>>>>>>> Y45-04. >>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>> may not be fully convinced or he wants a slight change of >>>>>>>>>>>>>>>>> Y54-04 >>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>> turns import-by-revision semantically into >>>>>>>>>>>>>>>>> import-by-min-revision. >>>>>>>>>>>>>>>>> Xiang Li seems to support a motion to make >>>>>>>>>>>>>>>>> import-by-revision >>>>>>>>>>>>>>>>> mean >>>>>>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> settle on >>>>>>>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean >>>>>>>>>>>>>>>>> indeed >>>>>>>>>>>>>>>>> import-by-min-revision. (We would have to write this >>>>>>>>>>>>>>>>> variation >>>>>>>>>>>>>>>>> down >>>>>>>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Two questions: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. Is import-by-revision supposed to mean >>>>>>>>>>>>>>>> import-by-min-revision >>>>>>>>>>>>>>>> only >>>>>>>>>>>>>>>> for augments? For groupings and typedefs it should IMO mea= n >>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>> exact >>>>>>>>>>>>>>>> revision. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> I guess this would be more than just augments. Essentially a= ny >>>>>>>>>>>>>> reference to an 'object' defined in an external module, >>>>>>>>>>>>>> irrespective >>>>>>>>>>>>>> whether the reference is via augments or a must/when stateme= nt >>>>>>>>>>>>>> or >>>>>>>>>>>>>> anything else. >>>>>>>>>>>>> >>>>>>>>>>>>> For must/when a revision makes even less sense because XPath >>>>>>>>>>>>> expressions refer to an instance document rather than a modul= e. >>>>>>>>>>>>> >>>>>>>>>>>> But isn't the same is true for an augment that refers to a >>>>>>>>>>>> target >>>>>>>>>>>> that >>>>>>>>>>>> is a list of a container? The target instance must not only be >>>>>>>>>>>> defined, it must also exist for the augment to have an effect. >>>>>>>>>>> >>>>>>>>>>> No, the target node is by definition a schema node, an augment >>>>>>>>>>> manipulates the schema - no instance is involved. >>>>>>>>>>> >>>>>>>>>>>> Anyway, the main idea behind Y45-04 is to use imports to handl= e >>>>>>>>>>>> schema >>>>>>>>>>>> tree dependencies that need to be unambiguous at module compil= e >>>>>>>>>>>> time >>>>>>>>>>>> and to leave instance tree dependencies to future work (e.g. a >>>>>>>>>>>> package >>>>>>>>>>>> definition system like Andy once proposed). >>>>>>>>>>> >>>>>>>>>>> For augments the package is in fact given by the hello message = or >>>>>>>>>>> other form of data model specification, because an augment make= s >>>>>>>>>>> sense only >>>>>>>>>>> if its target node is part of the schema. In fact, not only >>>>>>>>>>> revision of the >>>>>>>>>>> imported module is important here: >>>>>>>>>> >>>>>>>>>> "not only revision of the imported module is important..."? >>>>>>>>>> >>>>>>>>>> I thought you have been arguing for the contrary? Did you mean >>>>>>>>>> "not >>>>>>>>>> only revision of the advertised module is important=E2=80=A6"? >>>>>>>>> >>>>>>>>> Let=E2=80=99s go back to Andy=E2=80=99s example >>>>>>>>> >>>>>>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>>>>>>> >>>>>>>>> Andy wrote: =E2=80=9CThe 'aug1' developer clearly intends for the= server to >>>>>>>>> support base@2015-01-01.=E2=80=9D >>>>>>>>> >>>>>>>>> But let=E2=80=99s say the new enum in module =E2=80=9Cbase=E2=80= =9D is defined like so: >>>>>>>>> >>>>>>>>> enum fastest { >>>>>>>>> if-feature foo; >>>>>>>>> } >>>>>>>>> >>>>>>>>> Then I could argue that =E2=80=98aug1=E2=80=99 developer clearly = intends for the >>>>>>>>> server >>>>>>>>> to support not only base@2015-01-01 but also feature foo. However= , >>>>>>>>> the >>>>>>>>> latter requirement is not expressed in import-by-revision. >>>>>>>> >>>>>>>> Current YANG "enum" does not allow "if-feature" as its >>>>>>>> substatement. >>>>>>> >>>>>>> >>>>>>> Th one in YANG 1.1 proposal does. >>>>>>> >>>>>>>> But in general if things depend on some 'features' implemented in = an >>>>>>>> augmented >>>>>>>> base module then they are IMO by definition optional. In other >>>>>>>> words, >>>>>>>> 'aug1' developer can't >>>>>>>> demand a server to support feature 'foo', if it is not advertised.= I >>>>>>>> don't see that's relevant here. >>>>>>> >>>>>>> It is relevant - for the sake of this example, base@2015-01-01 >>>>>>> without >>>>>>> feature foo is essentially the same as base@2014-01-01. In both cas= es >>>>>>> the >>>>>>> augment from the aug1 module cannot be applied. >>>>>> >>>>>> >>>>>> I think the two scenarios are different. >>>>>> >>>>> quite different. >>>>> >>>>> The original point is that the designer of "aug1" is using >>>>> definitions from the new "base" module. There is no way >>>>> that the server can implement this "aug1" module using the >>>>> old "base" module. >>>>> >>>>> The server does not support the new "fastest" enum. It is a lie to >>>>> advertise that the leaf using this typedef is supported. >>>> >>>> The server advertises the old revision of =E2=80=9Cbase, thus making c= lear that >>>> is does *not* support the new =E2=80=9Cfastest=E2=80=9D enum. Therefor= e, it doesn=E2=80=99t lie. >>>> Note that the fact that the augment in =E2=80=98aug1=E2=80=99 doesn=E2= =80=99t happen isn=E2=80=99t an error >>>> from the YANG point of view - it just may or may not be what the serve= r >>>> implementer intended. >>>> >>> If it advertises the old version of "base" then it cannot advertise >>> "aug1". >>> The client sees that advertisement and believes that the new revision >>> of the typedef is supported. It has no reason to suspect that setting >> >> If Y45-04 is accepted, the client can never believe the new revision is >> supported because it is clearly stated that the revision of the import i= s >> ignored for augments. > > > That is what I still have doubt whether it is a good thing to do. > >> That is: >> >> - if a module is imported only for referring to its nodes (augments, >> leafrefs, must/when), then the >> import should be without revision because revision-date would be >> ignored anyway. > > > Why "revision-date" in this case must be ignored completely? > > If we do this, the author of "aug1" can not decide the version where he/s= he > wants to start. > I think it makes sense for the author of "aug1" to be able to do that and > set up some basic > requirements for the implementer of "aug1", and that's why I said I prefe= r > for "augment" > to use "min-revision-rule", unless it's the intention of the working grou= p > to prevent the author > of "agu1" from doing that for other legitimate reasons that I missed. > > >> - if groupings or typedefs from the imported module are used, then the >> exact revision of each is always >> known either from revision-date, if present, or from server=E2=80=99s >> advertisement. > > > We already agreed on this. We are not ignoring "revision-date" in this ca= se > either. > > -Xiang > >> I don=E2=80=99t think it it that complicated. > I think it is clearly broken. Using a fixed revision date for typedefs and groupings but a variable revision-date for everything else can be easily broken by mixing types/objects in must/when or augment statements. I noticed that the example given in Y45-04 for why we need multiple imports of each module is somewhat flawed: import ietf-inet-types { revision-date 2013-07-17; prefix inet; } import ietf-inet-types { revision-date 2010-09-24; prefix inet6021; } leaf foo { type inet:ip-address-no-zone; } leaf bar { type inet6021:ip-address; } This example shows that author wants to use the new ip-address-no-zone typedef that was added to RFC 6991, but is going to keep using the old version of ip-address. 1) ip-address did not change at all from RFC 6021, so there is no point in importing 2 revisions 2) even if the ip-address did change, is it really up the the author of the importing module to decide the standard ip-address type? Since the augmenting module is being updated anyway, it is OK to update the typedef. If it is the first version, then even worse to pick the out-of-date typedef. If a typedef gets corrected (e.g., the pattern-stmt is wrong in the old revision), then why do we want to let other modules keep using the broken version? Why make YANG complicated so the user can do the wrong thing? What if IPv7 gets added someday? Is it up to each WG, each module to decide "We have no interest in supporting the new IP version. We will stick with the current typedef forever". Is this OK, or should the set of IETF modules use consistent data types? > > No... Indeed it's not... > > -Xiang Andy From nobody Fri May 1 10:26:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829341AC3F5 for ; Fri, 1 May 2015 10:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS6AZOxl_esH for ; Fri, 1 May 2015 10:25:57 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFE51A8898 for ; Fri, 1 May 2015 10:25:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=N9vXwDniX5Q3BQONQSUdg9klaTsNETmsllAiYBgYUnSegyTdBj8lfiIuVfpWEsMD; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.45] (helo=elwamui-polski.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YoEhI-0000Tl-Ee for netmod@ietf.org; Fri, 01 May 2015 13:25:56 -0400 Received: from 76.254.51.223 by webmail.earthlink.net with HTTP; Fri, 1 May 2015 13:25:56 -0400 Message-ID: <10128464.1430501156476.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> Date: Fri, 1 May 2015 10:25:56 -0700 (GMT-07:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba091da804f37be4e754afb73d602db1049350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.45 Archived-At: Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 17:26:00 -0000 Hi - >From: Andy Bierman >Sent: May 1, 2015 9:43 AM >To: Xiang Li >Cc: "netmod@ietf.org" >Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? ... >I noticed that the example given in Y45-04 for why we need >multiple imports of each module is somewhat flawed: > >import ietf-inet-types { > revision-date 2013-07-17; > prefix inet; >} >import ietf-inet-types { > revision-date 2010-09-24; > prefix inet6021; >} >leaf foo { > type inet:ip-address-no-zone; >} >leaf bar { > type inet6021:ip-address; >} > > >This example shows that author wants to use the new ip-address-no-zone >typedef that was added to RFC 6991, but is going to keep using the >old version of ip-address. > > 1) ip-address did not change at all from RFC 6021, so there is no > point in importing 2 revisions > > 2) even if the ip-address did change, is it really up the the author > of the importing module to decide the standard ip-address type? > Since the augmenting module is being updated anyway, it is OK > to update the typedef. If it is the first version, then even worse > to pick the out-of-date typedef. > >If a typedef gets corrected (e.g., the pattern-stmt is wrong in the old >revision), then why do we want to let other modules keep using >the broken version? Why make YANG complicated so the user can >do the wrong thing? > >What if IPv7 gets added someday? Is it up to each WG, each module >to decide "We have no interest in supporting the new IP version. >We will stick with the current typedef forever". Is this OK, or >should the set of IETF modules use consistent data types? The design of the modeling language is entirely the wrong tool to use to enforce such a policy. As much as it is desirable for standards to be clean and consistent, fielded products are not, especially when there are add-ons from multiple vendors. If this modeling language and protocol are to be able to adequately represent whatever might be found in deployed systems, they must be capable of representing some pretty messy stuff. That's life. I have a feeling that there are differing understandings here of what a Yang augmentation really *means*. Are all of the versioning assumptions folks are making truly consequences of the semantics of augmentation, or are they consequences of specific implementation strategies? Randy From nobody Fri May 1 10:48:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391891B2B3D for ; Fri, 1 May 2015 10:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJtM-ckDweuS for ; Fri, 1 May 2015 10:48:50 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 73A341B2B8E for ; Fri, 1 May 2015 10:48:34 -0700 (PDT) Received: by labbd9 with SMTP id bd9so68465796lab.2 for ; Fri, 01 May 2015 10:48:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=C9BmmK876B258R03mG69JkkYcTqcfTjVG4+Bzj+gzvQ=; b=f7w2Kv9bAJf6f8GMPpFMHDip+8szztxtLzbUMwxb+PajtKsw3OrH+aAVw1yJscSpPT pZE45VTvUFEv4nF5p2o9aOJMIU2K8zS7dSDir0tOzH6ZG2j/Z4vYnCLK+Z7anVejFEYn RquaNQ5Uz6GB6vXcqrPJmqiK3on+pnnp0Teh8jZlunGuK3pLySrhgBKSsACfIQccX9zY Hw0XYAVXbdcN0GM8Z0HdQhbfSlQGGBDUGNlUapdn5NHWefZudXe3R8LfIIyo0teCOsPU K4i2r59e2FBc5N7sXhU5vHycdMrvOxHE1GbPiXV8FIo5dOGfwDvVFzPycZEvCQJgmSSu RdRQ== X-Gm-Message-State: ALoCoQnEghhIU2hg4yWw5Ggpbca1kRd6t42M75ThboBst4PNyKv/Y624xPilmKISOWJkPl1lHWxC MIME-Version: 1.0 X-Received: by 10.112.199.195 with SMTP id jm3mr9134185lbc.38.1430502512901; Fri, 01 May 2015 10:48:32 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 1 May 2015 10:48:32 -0700 (PDT) In-Reply-To: <10128464.1430501156476.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> References: <10128464.1430501156476.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> Date: Fri, 1 May 2015 10:48:32 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 17:48:52 -0000 On Fri, May 1, 2015 at 10:25 AM, Randy Presuhn wrote: > Hi - > >>From: Andy Bierman >>Sent: May 1, 2015 9:43 AM >>To: Xiang Li >>Cc: "netmod@ietf.org" >>Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? > ... >>I noticed that the example given in Y45-04 for why we need >>multiple imports of each module is somewhat flawed: >> >>import ietf-inet-types { >> revision-date 2013-07-17; >> prefix inet; >>} >>import ietf-inet-types { >> revision-date 2010-09-24; >> prefix inet6021; >>} >>leaf foo { >> type inet:ip-address-no-zone; >>} >>leaf bar { >> type inet6021:ip-address; >>} >> >> >>This example shows that author wants to use the new ip-address-no-zone >>typedef that was added to RFC 6991, but is going to keep using the >>old version of ip-address. >> >> 1) ip-address did not change at all from RFC 6021, so there is no >> point in importing 2 revisions >> >> 2) even if the ip-address did change, is it really up the the author >> of the importing module to decide the standard ip-address type? >> Since the augmenting module is being updated anyway, it is OK >> to update the typedef. If it is the first version, then even worse >> to pick the out-of-date typedef. >> >>If a typedef gets corrected (e.g., the pattern-stmt is wrong in the old >>revision), then why do we want to let other modules keep using >>the broken version? Why make YANG complicated so the user can >>do the wrong thing? >> >>What if IPv7 gets added someday? Is it up to each WG, each module >>to decide "We have no interest in supporting the new IP version. >>We will stick with the current typedef forever". Is this OK, or >>should the set of IETF modules use consistent data types? > > The design of the modeling language is entirely the wrong tool > to use to enforce such a policy. > > As much as it is desirable for standards to be clean and consistent, > fielded products are not, especially when there are add-ons from > multiple vendors. If this modeling language and protocol > are to be able to adequately represent whatever might be found in > deployed systems, they must be capable of representing some pretty > messy stuff. That's life. > > I have a feeling that there are differing understandings here of > what a Yang augmentation really *means*. Are all of the versioning > assumptions folks are making truly consequences of the semantics > of augmentation, or are they consequences of specific implementation > strategies? > I don't understand the confusion. Clearly, if new functionality has been added to rev N, then in order to use that functionality, rev N needs to be supported. The deployment is a separate matter. A vendor can add deviation-stmts as needed to specify the messy product details. Can the augmenting data assume any functionality in the augmented module at all? IMO it is not even possible to write a module that integrates with an existing module, unless a specific minimum version is selected. Obviously I cannot import definitions that have not been added yet. What is less obvious (I guess) is that the imported definitions can interact with various statements to produce version-specific dependencies. The simplistic logic of Y45-04 "it exists so it must be OK to use any version of it" is broken. > Randy > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri May 1 13:07:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842681A904C for ; Fri, 1 May 2015 13:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShNywmfLfGRX for ; Fri, 1 May 2015 13:06:58 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAFD1A8AB5 for ; Fri, 1 May 2015 13:06:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fKyMXFs8BRCZg2g9LD3GvG3CjG57/ZXzfoFAyJIOvbrXjwT4drw6R3of6G5JIo3x; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YoHD8-0003JY-3y for netmod@ietf.org; Fri, 01 May 2015 16:06:58 -0400 Received: from 76.254.51.223 by webmail.earthlink.net with HTTP; Fri, 1 May 2015 16:06:57 -0400 Message-ID: <15861641.1430510817938.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Fri, 1 May 2015 16:06:57 -0400 (EDT) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba0f81630c3f85b1b0fa73c57eb129480ec350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Archived-At: Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 20:07:00 -0000 Hi - >From: Andy Bierman >Sent: May 1, 2015 10:48 AM >To: Randy Presuhn >Cc: "netmod@ietf.org" >Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? > >On Fri, May 1, 2015 at 10:25 AM, Randy Presuhn > wrote: >> Hi - >> >>>From: Andy Bierman >>>Sent: May 1, 2015 9:43 AM >>>To: Xiang Li >>>Cc: "netmod@ietf.org" >>>Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? >> ... >>>I noticed that the example given in Y45-04 for why we need >>>multiple imports of each module is somewhat flawed: >>> >>>import ietf-inet-types { >>> revision-date 2013-07-17; >>> prefix inet; >>>} >>>import ietf-inet-types { >>> revision-date 2010-09-24; >>> prefix inet6021; >>>} >>>leaf foo { >>> type inet:ip-address-no-zone; >>>} >>>leaf bar { >>> type inet6021:ip-address; >>>} >>> >>> >>>This example shows that author wants to use the new ip-address-no-zone >>>typedef that was added to RFC 6991, but is going to keep using the >>>old version of ip-address. >>> >>> 1) ip-address did not change at all from RFC 6021, so there is no >>> point in importing 2 revisions >>> >>> 2) even if the ip-address did change, is it really up the the author >>> of the importing module to decide the standard ip-address type? >>> Since the augmenting module is being updated anyway, it is OK >>> to update the typedef. If it is the first version, then even worse >>> to pick the out-of-date typedef. >>> >>>If a typedef gets corrected (e.g., the pattern-stmt is wrong in the old >>>revision), then why do we want to let other modules keep using >>>the broken version? Why make YANG complicated so the user can >>>do the wrong thing? >>> >>>What if IPv7 gets added someday? Is it up to each WG, each module >>>to decide "We have no interest in supporting the new IP version. >>>We will stick with the current typedef forever". Is this OK, or >>>should the set of IETF modules use consistent data types? >> >> The design of the modeling language is entirely the wrong tool >> to use to enforce such a policy. >> >> As much as it is desirable for standards to be clean and consistent, >> fielded products are not, especially when there are add-ons from >> multiple vendors. If this modeling language and protocol >> are to be able to adequately represent whatever might be found in >> deployed systems, they must be capable of representing some pretty >> messy stuff. That's life. >> >> I have a feeling that there are differing understandings here of >> what a Yang augmentation really *means*. Are all of the versioning >> assumptions folks are making truly consequences of the semantics >> of augmentation, or are they consequences of specific implementation >> strategies? >> > >I don't understand the confusion. >Clearly, if new functionality has been added to rev N, >then in order to use that functionality, rev N needs to >be supported. > >The deployment is a separate matter. >A vendor can add deviation-stmts as needed >to specify the messy product details. > >Can the augmenting data assume any functionality in the augmented >module at all? IMO it is not even possible to write a module that >integrates with an existing module, unless a specific minimum version >is selected. > >Obviously I cannot import definitions that have not been added yet. >What is less obvious (I guess) is that the imported definitions >can interact with various statements to produce version-specific >dependencies. The simplistic logic of Y45-04 "it exists so it >must be OK to use any version of it" is broken. ... Though I agree the conclusion that any sort of non-determinism in version selection is broken, other parts of the reasoning to get to that conclusion give me heartburn. RFC 6020 describes augment in structural terms rather than semantic ones. Consequently, arguments about augment based on semantics rather than structure seem to me to be based on assumptions external to the specification. >From the perspective of *structure*, there's nothing wrong with admitting possibility that an instance of a datatype resulting from an augmentation might be of a different version from some other instance of that dataype in the augmented node. It's possible to figure out deterministically and unambiguously what version to use for each instance, so it seems to me that these objections must be based on an assumed tighter coupling between the underlying implementation of the augmented node and the augmentation than would be required by 6020. Randy From nobody Fri May 1 14:27:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086A71B2E6D for ; Fri, 1 May 2015 14:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tbx7fPA8PSBW for ; Fri, 1 May 2015 14:27:12 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 4BC981B2E58 for ; Fri, 1 May 2015 14:27:11 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so71917213lbb.3 for ; Fri, 01 May 2015 14:27:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xOb7aIsVGaV9ZXVjKiN5QIhN9SyPsyygA3Byhrh8khY=; b=GvJA9zTouNqSRs1sLPsZbz94u7Vn+7qsAwh2/AJQc15WaR5imgTbop/EK4mqJA08La I2H4dOUmOQU+hwvRUGdeV/B2+GCenhku1oOZhvcdkTIT7/u7OKnF/VqSq2rFTZ4wGTK4 NfzE8buRIw1MuG03Q8/00iqDTYFTR8SMB6DVhInu7dgT474mLTqqKSGhXjgJKS4R1z7s n8v4+3P2uLGm2WtmpZ5bZUTr0gwZ55laUlVMnNVrJ1i4RTdN4zhsitGIILIsEZ20IZzo Ob4VzHG0nALPFC3lduOinToKtJGSzIdP1LaQzGwHI1L51DbnVM5eO7crPMcrUkqbiGj/ fUuQ== X-Gm-Message-State: ALoCoQmOoP+Fy3EYiPf9kgMpvEkRn9DnFAqyfw9B2oZTJ6QqJss2w+yUumEB63WifEF5pN+9AXWs MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr9791560laj.88.1430515629771; Fri, 01 May 2015 14:27:09 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 1 May 2015 14:27:09 -0700 (PDT) In-Reply-To: <15861641.1430510817938.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> References: <15861641.1430510817938.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Fri, 1 May 2015 14:27:09 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 21:27:19 -0000 On Fri, May 1, 2015 at 1:06 PM, Randy Presuhn wrote: > Hi - > >>From: Andy Bierman >>Sent: May 1, 2015 10:48 AM >>To: Randy Presuhn >>Cc: "netmod@ietf.org" >>Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? >> >>On Fri, May 1, 2015 at 10:25 AM, Randy Presuhn >> wrote: >>> Hi - >>> >>>>From: Andy Bierman >>>>Sent: May 1, 2015 9:43 AM >>>>To: Xiang Li >>>>Cc: "netmod@ietf.org" >>>>Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? >>> ... >>>>I noticed that the example given in Y45-04 for why we need >>>>multiple imports of each module is somewhat flawed: >>>> >>>>import ietf-inet-types { >>>> revision-date 2013-07-17; >>>> prefix inet; >>>>} >>>>import ietf-inet-types { >>>> revision-date 2010-09-24; >>>> prefix inet6021; >>>>} >>>>leaf foo { >>>> type inet:ip-address-no-zone; >>>>} >>>>leaf bar { >>>> type inet6021:ip-address; >>>>} >>>> >>>> >>>>This example shows that author wants to use the new ip-address-no-zone >>>>typedef that was added to RFC 6991, but is going to keep using the >>>>old version of ip-address. >>>> >>>> 1) ip-address did not change at all from RFC 6021, so there is no >>>> point in importing 2 revisions >>>> >>>> 2) even if the ip-address did change, is it really up the the author >>>> of the importing module to decide the standard ip-address type? >>>> Since the augmenting module is being updated anyway, it is OK >>>> to update the typedef. If it is the first version, then even worse >>>> to pick the out-of-date typedef. >>>> >>>>If a typedef gets corrected (e.g., the pattern-stmt is wrong in the old >>>>revision), then why do we want to let other modules keep using >>>>the broken version? Why make YANG complicated so the user can >>>>do the wrong thing? >>>> >>>>What if IPv7 gets added someday? Is it up to each WG, each module >>>>to decide "We have no interest in supporting the new IP version. >>>>We will stick with the current typedef forever". Is this OK, or >>>>should the set of IETF modules use consistent data types? >>> >>> The design of the modeling language is entirely the wrong tool >>> to use to enforce such a policy. >>> >>> As much as it is desirable for standards to be clean and consistent, >>> fielded products are not, especially when there are add-ons from >>> multiple vendors. If this modeling language and protocol >>> are to be able to adequately represent whatever might be found in >>> deployed systems, they must be capable of representing some pretty >>> messy stuff. That's life. >>> >>> I have a feeling that there are differing understandings here of >>> what a Yang augmentation really *means*. Are all of the versioning >>> assumptions folks are making truly consequences of the semantics >>> of augmentation, or are they consequences of specific implementation >>> strategies? >>> >> >>I don't understand the confusion. >>Clearly, if new functionality has been added to rev N, >>then in order to use that functionality, rev N needs to >>be supported. >> >>The deployment is a separate matter. >>A vendor can add deviation-stmts as needed >>to specify the messy product details. >> >>Can the augmenting data assume any functionality in the augmented >>module at all? IMO it is not even possible to write a module that >>integrates with an existing module, unless a specific minimum version >>is selected. >> >>Obviously I cannot import definitions that have not been added yet. >>What is less obvious (I guess) is that the imported definitions >>can interact with various statements to produce version-specific >>dependencies. The simplistic logic of Y45-04 "it exists so it >>must be OK to use any version of it" is broken. > ... > > Though I agree the conclusion that any sort of non-determinism in > version selection is broken, other parts of the reasoning to get to > that conclusion give me heartburn. > > RFC 6020 describes augment in structural terms rather than semantic > ones. Consequently, arguments about augment based on semantics > rather than structure seem to me to be based on assumptions external > to the specification. > But augment is often used with the "when-stmt". The when and must statements allow ad-hoc interactions between objects. IMO we cannot look at some YANG statements and ignore others when considering how modular integration is designed into the data model. > >From the perspective of *structure*, there's nothing wrong with > admitting possibility that an instance of a datatype resulting > from an augmentation might be of a different version from some > other instance of that dataype in the augmented node. > It's possible to figure out deterministically and unambiguously > what version to use for each instance, so it seems to me that > these objections must be based on an assumed tighter coupling > between the underlying implementation of the augmented node and the > augmentation than would be required by 6020. The must/when statements go beyond structure. These can impact any object and they are tied to the semantics of the model, not the structure. > > Randy Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri May 1 15:14:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C431A03D5 for ; Fri, 1 May 2015 15:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goaXBK4ERlYA for ; Fri, 1 May 2015 15:14:43 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC011A039C for ; Fri, 1 May 2015 15:14:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VM26DHHGfZ5BJyFwJ59CCZ8AqWfJQKhTX18SK1ScYBMqFxGTS0C217SgJIMOJfxk; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YoJCh-0004Th-Oj for netmod@ietf.org; Fri, 01 May 2015 18:14:39 -0400 Received: from 76.254.51.223 by webmail.earthlink.net with HTTP; Fri, 1 May 2015 18:14:39 -0400 Message-ID: <23276249.1430518479676.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Fri, 1 May 2015 15:14:39 -0700 (GMT-07:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba0db1002d9e53644c9db99d2d6960e9b68350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Archived-At: Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 22:14:46 -0000 Hi - >From: Andy Bierman >Sent: May 1, 2015 2:27 PM >To: Randy Presuhn >Cc: "netmod@ietf.org" >Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? > >On Fri, May 1, 2015 at 1:06 PM, Randy Presuhn > wrote: >> Hi - >> >>>From: Andy Bierman >>>Sent: May 1, 2015 10:48 AM >>>To: Randy Presuhn >>>Cc: "netmod@ietf.org" >>>Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? >>> >>>On Fri, May 1, 2015 at 10:25 AM, Randy Presuhn >>> wrote: >>>> Hi - >>>> >>>>>From: Andy Bierman >>>>>Sent: May 1, 2015 9:43 AM >>>>>To: Xiang Li >>>>>Cc: "netmod@ietf.org" >>>>>Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? >>>> ... >>>>>I noticed that the example given in Y45-04 for why we need >>>>>multiple imports of each module is somewhat flawed: >>>>> >>>>>import ietf-inet-types { >>>>> revision-date 2013-07-17; >>>>> prefix inet; >>>>>} >>>>>import ietf-inet-types { >>>>> revision-date 2010-09-24; >>>>> prefix inet6021; >>>>>} >>>>>leaf foo { >>>>> type inet:ip-address-no-zone; >>>>>} >>>>>leaf bar { >>>>> type inet6021:ip-address; >>>>>} >>>>> >>>>> >>>>>This example shows that author wants to use the new ip-address-no-zone >>>>>typedef that was added to RFC 6991, but is going to keep using the >>>>>old version of ip-address. >>>>> >>>>> 1) ip-address did not change at all from RFC 6021, so there is no >>>>> point in importing 2 revisions >>>>> >>>>> 2) even if the ip-address did change, is it really up the the author >>>>> of the importing module to decide the standard ip-address type? >>>>> Since the augmenting module is being updated anyway, it is OK >>>>> to update the typedef. If it is the first version, then even worse >>>>> to pick the out-of-date typedef. >>>>> >>>>>If a typedef gets corrected (e.g., the pattern-stmt is wrong in the old >>>>>revision), then why do we want to let other modules keep using >>>>>the broken version? Why make YANG complicated so the user can >>>>>do the wrong thing? >>>>> >>>>>What if IPv7 gets added someday? Is it up to each WG, each module >>>>>to decide "We have no interest in supporting the new IP version. >>>>>We will stick with the current typedef forever". Is this OK, or >>>>>should the set of IETF modules use consistent data types? >>>> >>>> The design of the modeling language is entirely the wrong tool >>>> to use to enforce such a policy. >>>> >>>> As much as it is desirable for standards to be clean and consistent, >>>> fielded products are not, especially when there are add-ons from >>>> multiple vendors. If this modeling language and protocol >>>> are to be able to adequately represent whatever might be found in >>>> deployed systems, they must be capable of representing some pretty >>>> messy stuff. That's life. >>>> >>>> I have a feeling that there are differing understandings here of >>>> what a Yang augmentation really *means*. Are all of the versioning >>>> assumptions folks are making truly consequences of the semantics >>>> of augmentation, or are they consequences of specific implementation >>>> strategies? >>>> >>> >>>I don't understand the confusion. >>>Clearly, if new functionality has been added to rev N, >>>then in order to use that functionality, rev N needs to >>>be supported. >>> >>>The deployment is a separate matter. >>>A vendor can add deviation-stmts as needed >>>to specify the messy product details. >>> >>>Can the augmenting data assume any functionality in the augmented >>>module at all? IMO it is not even possible to write a module that >>>integrates with an existing module, unless a specific minimum version >>>is selected. >>> >>>Obviously I cannot import definitions that have not been added yet. >>>What is less obvious (I guess) is that the imported definitions >>>can interact with various statements to produce version-specific >>>dependencies. The simplistic logic of Y45-04 "it exists so it >>>must be OK to use any version of it" is broken. >> ... >> >> Though I agree the conclusion that any sort of non-determinism in >> version selection is broken, other parts of the reasoning to get to >> that conclusion give me heartburn. >> >> RFC 6020 describes augment in structural terms rather than semantic >> ones. Consequently, arguments about augment based on semantics >> rather than structure seem to me to be based on assumptions external >> to the specification. >> > >But augment is often used with the "when-stmt". >The when and must statements allow ad-hoc interactions >between objects. IMO we cannot look at some YANG statements >and ignore others when considering how modular integration >is designed into the data model. Are you arguing that the when or must statements cannot be evaluated in a meaningful way? That would be a serious problem. Are you arguing that module designers can paint themselves into a corner with when/must statements? That's not solvable. Any language sufficiently powerful to do interesting things will allow one to set up contradictions or nonsense. >> >From the perspective of *structure*, there's nothing wrong with >> admitting possibility that an instance of a datatype resulting >> from an augmentation might be of a different version from some >> other instance of that dataype in the augmented node. >> It's possible to figure out deterministically and unambiguously >> what version to use for each instance, so it seems to me that >> these objections must be based on an assumed tighter coupling >> between the underlying implementation of the augmented node and the >> augmentation than would be required by 6020. > >The must/when statements go beyond structure. >These can impact any object and they are tied to >the semantics of the model, not the structure. Sure, and the dependency graphs resulting could potentially be quite baroque. But that reflects reality. As long as there is no ambiguity/nondeterminism in how these expressions are evaluated, the problem seems to be limited to situations where what a system implements diverges from what might be strictly inferred from what it advertises, and those difficulties appear to be in the advertisement mechanisms, not the modeling. If one were to constrain the language sufficiently to prevent folks from saying anything silly, doing so would also preclude useful things. But I think we are in violent agreement that disregarding a request for a specific revision is the wrong thing to do. Randy From nobody Sat May 2 04:42:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49CA1A7011 for ; Sat, 2 May 2015 04:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWK5c0zcUc5g for ; Sat, 2 May 2015 04:42:06 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C0EBC1A7007 for ; Sat, 2 May 2015 04:42:06 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id D959F1AE046D; Sat, 2 May 2015 13:42:04 +0200 (CEST) Date: Sat, 02 May 2015 13:45:05 +0200 (CEST) Message-Id: <20150502.134505.2297540296678533084.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <23276249.1430518479676.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> References: <23276249.1430518479676.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 11:42:08 -0000 Randy Presuhn wrote: > Hi - > > >From: Andy Bierman > >Sent: May 1, 2015 2:27 PM > >To: Randy Presuhn > >Cc: "netmod@ietf.org" > >Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? > > > >On Fri, May 1, 2015 at 1:06 PM, Randy Presuhn > > wrote: > >> Hi - > >> > >>>From: Andy Bierman > >> >From the perspective of *structure*, there's nothing wrong with > >> admitting possibility that an instance of a datatype resulting > >> from an augmentation might be of a different version from some > >> other instance of that dataype in the augmented node. > >> It's possible to figure out deterministically and unambiguously > >> what version to use for each instance, so it seems to me that > >> these objections must be based on an assumed tighter coupling > >> between the underlying implementation of the augmented node and the > >> augmentation than would be required by 6020. > > > >The must/when statements go beyond structure. > >These can impact any object and they are tied to > >the semantics of the model, not the structure. > > Sure, and the dependency graphs resulting could potentially > be quite baroque. But that reflects reality. > > As long as there is no ambiguity/nondeterminism in how these > expressions are evaluated, the problem seems to be limited to > situations where what a system implements diverges from what > might be strictly inferred from what it advertises I don't think this is correct. If the server diverges from what it advertises, the problem is in the server. The disagreement seems to be around what conformance requirements the import statement implies. RFC 6020 is silent on this matter. It just says that import-by revision locks down typedefs etc, but it does not say anything about augment. The other confusion comes from this situation; suppose we have: module A { ... container a { ... } } module B { ... import A { prefix a;} container b1 { ... } augment /a:a { container b2 { ... } } } and suppose a server advertises that it implements B (but not A). What does this mean? 1) This is an error - since it advertises B it MUST implement /a:a/b:b2, and the only way to do this is to also advertise A. 2) This is fine - since it doesn't advertise A, the client knows that /a:a/b:b2 is not implemented. However /b:b1 is implemented. Again, RFC 6020 is silent on this. I think we all have been thinking along the lines of 1 above, but maybe we should decouple the language and module advertisement even more from conformance, and go with 2 instead. /martin From nobody Sat May 2 07:31:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8669A1A8893 for ; Sat, 2 May 2015 07:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAcstLy5OY9f for ; Sat, 2 May 2015 07:31:22 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (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 9A3F81A8891 for ; Sat, 2 May 2015 07:31:21 -0700 (PDT) Received: by layy10 with SMTP id y10so79673711lay.0 for ; Sat, 02 May 2015 07:31:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0j444e62RC5JzuQCUocZSvuQG5vs+W5yJWz0Wpkmfkc=; b=jVdtUGc+U8eld7equ+MeWbWEaTWnJ+z1+F5YvzHcFjA2xD+F0049l9olePjcOzOfRS 4wdyqIC+AugzO+8N7KUcpsPhEZiAPAxCGxkXwnqTT1LczBuLWKA5FqzK80EMgdCzTj4Y Xo/x4cemGDOW+YOiOxL16/5COF91J6l0J+fHu4HK1nt7Ocwi0FLymrAjkQRFAss8sXKn +Ey/kmNHPFaU3vH0IopCkAbagah/psELx8uAOSyjAwNXBR8L5Iwdsh0X9u0lrWPGmjXe r3fP+zosXGeK/qrlxeUH8ccVgJYdNfJObhR82Ka+mfdIDSWlpfpiJd9ybq4QNf920hgT ZMhA== X-Gm-Message-State: ALoCoQl+wRUJskRVmEiQDdYV1EQqPPc6bFFUiV1ZYOVlMQznAHIAz3h1SmmlOrlz3kna2kEUIWUr MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr12329583lab.82.1430577079912; Sat, 02 May 2015 07:31:19 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sat, 2 May 2015 07:31:19 -0700 (PDT) In-Reply-To: <20150502.134505.2297540296678533084.mbj@tail-f.com> References: <23276249.1430518479676.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <20150502.134505.2297540296678533084.mbj@tail-f.com> Date: Sat, 2 May 2015 07:31:19 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 14:31:24 -0000 On Sat, May 2, 2015 at 4:45 AM, Martin Bjorklund wrote: > Randy Presuhn wrote: >> Hi - >> >> >From: Andy Bierman >> >Sent: May 1, 2015 2:27 PM >> >To: Randy Presuhn >> >Cc: "netmod@ietf.org" >> >Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? >> > >> >On Fri, May 1, 2015 at 1:06 PM, Randy Presuhn >> > wrote: >> >> Hi - >> >> >> >>>From: Andy Bierman >> >> >From the perspective of *structure*, there's nothing wrong with >> >> admitting possibility that an instance of a datatype resulting >> >> from an augmentation might be of a different version from some >> >> other instance of that dataype in the augmented node. >> >> It's possible to figure out deterministically and unambiguously >> >> what version to use for each instance, so it seems to me that >> >> these objections must be based on an assumed tighter coupling >> >> between the underlying implementation of the augmented node and the >> >> augmentation than would be required by 6020. >> > >> >The must/when statements go beyond structure. >> >These can impact any object and they are tied to >> >the semantics of the model, not the structure. >> >> Sure, and the dependency graphs resulting could potentially >> be quite baroque. But that reflects reality. >> >> As long as there is no ambiguity/nondeterminism in how these >> expressions are evaluated, the problem seems to be limited to >> situations where what a system implements diverges from what >> might be strictly inferred from what it advertises > > I don't think this is correct. If the server diverges from what it > advertises, the problem is in the server. > > The disagreement seems to be around what conformance requirements the > import statement implies. > > RFC 6020 is silent on this matter. It just says that import-by > revision locks down typedefs etc, but it does not say anything about > augment. > When the optional "revision-date" substatement is present, any typedef, grouping, extension, feature, and identity referenced by definitions in the local module are taken from the specified revision of the imported module. It is an error if the specified revision of the imported module does not exist. If no "revision-date" substatement is present, it is undefined from which revision of the module they are taken. Multiple revisions of the same module MUST NOT be imported. It is odd that nothing is mentioned about augment. I do notice a MUST NOT that Y45 is trying to change. IMO this MUST NOT needs to remain in place. Andy > The other confusion comes from this situation; suppose we have: > > module A { > ... > container a { ... } > } > > module B { > ... > import A { prefix a;} > container b1 { ... } > augment /a:a { > container b2 { ... } > } > } > > and suppose a server advertises that it implements B (but not A). > What does this mean? > > 1) This is an error - since it advertises B it MUST implement > /a:a/b:b2, and the only way to do this is to also advertise A. > > 2) This is fine - since it doesn't advertise A, the client knows > that /a:a/b:b2 is not implemented. However /b:b1 is > implemented. > > Again, RFC 6020 is silent on this. > > I think we all have been thinking along the lines of 1 above, but maybe > we should decouple the language and module advertisement even more > from conformance, and go with 2 instead. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sat May 2 10:19:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37ECC1A86E3 for ; Sat, 2 May 2015 10:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLNaW0Qu62eT for ; Sat, 2 May 2015 10:19:52 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (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 814EA1A0169 for ; Sat, 2 May 2015 10:19:52 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so81806478lbc.1 for ; Sat, 02 May 2015 10:19:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KyED0ZrF3D1hM4prghSejN0SH28rpxo4oPJnC5EV4rM=; b=KDuX186XL5mO8/yuSU++SF6LH7yOjvsCx3CsF3WKk+7eJtaGPyJT1hvzprcRZ79UZk qkyk+5HwgJe77jtgT8E6D8EbQqB6J9dH9zHwksWXGaYZlbjnj66PY4GnOt8qD4jeN3f8 GqvoMoWKPi0xf2rlzIr/MIhy8B2I1tluF5e4XktlFGpb8yMdR5baDw/xOVPR9B0jSs9H Qa9erphmcdAW9lr9hVC2XtJGgEmIkY22/C0N74Dm1WiQYa52Bqi1dfY1UOn0zcKNwZxG pLzDTwOFVnfETMUZ2uWYBfJsMr8lBEYgh/QY6rMreHgUv4xZ8CXq/LvC+u6ihZ66o6vm lJZQ== X-Gm-Message-State: ALoCoQmXPqiiROnBoNQ7yvs2GHX5yskbq/nvznHOjssqP6zGGotC/58TDNklIsyHIiBlFm3frFQ3 MIME-Version: 1.0 X-Received: by 10.112.204.72 with SMTP id kw8mr12862012lbc.88.1430587191003; Sat, 02 May 2015 10:19:51 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sat, 2 May 2015 10:19:50 -0700 (PDT) In-Reply-To: <20150502.134505.2297540296678533084.mbj@tail-f.com> References: <23276249.1430518479676.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <20150502.134505.2297540296678533084.mbj@tail-f.com> Date: Sat, 2 May 2015 10:19:50 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 17:19:54 -0000 On Sat, May 2, 2015 at 4:45 AM, Martin Bjorklund wrote: > Randy Presuhn wrote: >> Hi - >> >> >From: Andy Bierman >> >Sent: May 1, 2015 2:27 PM >> >To: Randy Presuhn >> >Cc: "netmod@ietf.org" >> >Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? >> > >> >On Fri, May 1, 2015 at 1:06 PM, Randy Presuhn >> > wrote: >> >> Hi - >> >> >> >>>From: Andy Bierman >> >> >From the perspective of *structure*, there's nothing wrong with >> >> admitting possibility that an instance of a datatype resulting >> >> from an augmentation might be of a different version from some >> >> other instance of that dataype in the augmented node. >> >> It's possible to figure out deterministically and unambiguously >> >> what version to use for each instance, so it seems to me that >> >> these objections must be based on an assumed tighter coupling >> >> between the underlying implementation of the augmented node and the >> >> augmentation than would be required by 6020. >> > >> >The must/when statements go beyond structure. >> >These can impact any object and they are tied to >> >the semantics of the model, not the structure. >> >> Sure, and the dependency graphs resulting could potentially >> be quite baroque. But that reflects reality. >> >> As long as there is no ambiguity/nondeterminism in how these >> expressions are evaluated, the problem seems to be limited to >> situations where what a system implements diverges from what >> might be strictly inferred from what it advertises > > I don't think this is correct. If the server diverges from what it > advertises, the problem is in the server. > > The disagreement seems to be around what conformance requirements the > import statement implies. > > RFC 6020 is silent on this matter. It just says that import-by > revision locks down typedefs etc, but it does not say anything about > augment. > > The other confusion comes from this situation; suppose we have: > > module A { > ... > container a { ... } > } > > module B { > ... > import A { prefix a;} > container b1 { ... } > augment /a:a { > container b2 { ... } > } > } > > and suppose a server advertises that it implements B (but not A). > What does this mean? > > 1) This is an error - since it advertises B it MUST implement > /a:a/b:b2, and the only way to do this is to also advertise A. > > 2) This is fine - since it doesn't advertise A, the client knows > that /a:a/b:b2 is not implemented. However /b:b1 is > implemented. > > Again, RFC 6020 is silent on this. > > I think we all have been thinking along the lines of 1 above, but maybe > we should decouple the language and module advertisement even more > from conformance, and go with 2 instead. > I think I posted leafref and must/when-stmt examples before showing it is not just augment that can reference data nodes from module A. Not to mention the description-stmt. IMO it is not possible to specify which statements can just be silently ignored. The only intuitive interpretation of import-by-revision is that all the statements that appear in the specified revision are the ones that will be used. It is probably quite astonishing to users that the actual revision of protocol-accessible nodes may not be the same as the requested revision. MUST be the specified revision: - typedef - grouping - extension - feature - identity unknown revision: - data-def - augment - rpc - notification - deviation > > /martin Andy From nobody Sun May 3 11:09:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E876C1A87B9 for ; Sun, 3 May 2015 11:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXIC4IR_t6mX for ; Sun, 3 May 2015 11:09:22 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 ED3761A87AE for ; Sun, 3 May 2015 11:09:21 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so92008502lbb.3 for ; Sun, 03 May 2015 11:09:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4m4IyZbM5rA+23Yz+K9jyW5k9/yzbgEHj7FeOceNjDQ=; b=I//nxQ/JCnNqBfKMlzrr8UklZClxOfW6/ZPRAJI2Ijg73lsttOTS4ePUzrWVqcRCbc W86MULHRuNAkl2zYJHzYd/6uS1PbNcitHTDaunDdfixgxI3NTbT+RL0b6Sm6SzYSw/Jb FfKEgcaPyXdOPrM/7w5sQL04vSD9KdqxOooxTTnsEef7UcwakOwmq1zqQkOSIhmIk40Z 1APFY7d+0WBoNN2kTVAHAwxbRaGCUppx/w0wsemp7+oiTz82UB6lVD+pPPLW/KjXR4S+ oAAw7b/197cpj1D9fJBEidndOZdjaLwKZYpGtQ8mLk7jeZfh4dNfjKjfmlLCYqX1P9/0 TILw== X-Gm-Message-State: ALoCoQl+XZqwpTdBlp7ad2Qe+V38AYUD6YgusXCfGrfbcOKCONuoVV9ySNBUEgDs6fupN+EP+kc2 MIME-Version: 1.0 X-Received: by 10.112.204.72 with SMTP id kw8mr16556696lbc.88.1430676560505; Sun, 03 May 2015 11:09:20 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 3 May 2015 11:09:20 -0700 (PDT) In-Reply-To: <23276249.1430518479676.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> References: <23276249.1430518479676.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Sun, 3 May 2015 11:09:20 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 18:09:24 -0000 On Fri, May 1, 2015 at 3:14 PM, Randy Presuhn wrote: > Hi - ....... >>The must/when statements go beyond structure. >>These can impact any object and they are tied to >>the semantics of the model, not the structure. > > Sure, and the dependency graphs resulting could potentially > be quite baroque. But that reflects reality. > I don't think I made it clear that my objection is to the server advertising conformance to both "aug1" and "base@2014-01-01". It is OK if the server implements back-revisions of "base", but in order to claim conformance to "aug1", a certain minimum revision needs to be supported. I am willing to accept that the "minimum required revision" is something the vendor can determine. If the requirements for the "group 2 (any revision)" statements are met by a different revision, then the server can advertise conformance for "aug1". So I support Y45-03 (plus any bugfixes that are needed). This solution does not attempt to undo the MUST NOT import more than 1 revision of a module rule. It does not attempt to change the YANG syntax. This seems most appropriate for a "1.1" minor release. > As long as there is no ambiguity/nondeterminism in how these > expressions are evaluated, the problem seems to be limited to > situations where what a system implements diverges from what > might be strictly inferred from what it advertises, and those > difficulties appear to be in the advertisement mechanisms, > not the modeling. If one were to constrain the language sufficiently > to prevent folks from saying anything silly, doing so would also > preclude useful things. > > But I think we are in violent agreement that disregarding a request > for a specific revision is the wrong thing to do. > You have to read the fine print I guess ;-) > Randy > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon May 4 01:09:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA701A92BA; Mon, 4 May 2015 01:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBALG6UcT64a; Mon, 4 May 2015 01:09:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 307A21A9147; Mon, 4 May 2015 01:09:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150504080926.30229.81928.idtracker@ietfa.amsl.com> Date: Mon, 04 May 2015 01:09:26 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 08:09:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc6020bis-05.txt Pages : 193 Date : 2015-05-04 Abstract: YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. This document obsoletes RFC 6020. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 4 01:25:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735551AC3BE for ; Mon, 4 May 2015 01:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7kaFqnpCi65 for ; Mon, 4 May 2015 01:25:10 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7F81AC3BA for ; Mon, 4 May 2015 01:25:10 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 78BCB1AE046E for ; Mon, 4 May 2015 10:25:09 +0200 (CEST) Date: Mon, 04 May 2015 10:25:09 +0200 (CEST) Message-Id: <20150504.102509.954312726625270993.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Y34 anyxml/anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 08:25:13 -0000 Hi, draft-ietf-netmod-rfc6020bis-05 includes solution Y34-05, except that Y34-05 says: - Document that implementations MAY have restrictions for anyxml and that anyxml is not necessarily interoperable; data model writers should use anydata whenever possible. I don't think this text belongs in the specification of the language. Was the intention to add this to 6087bis? /martin From nobody Mon May 4 01:31:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8B51A1B17 for ; Mon, 4 May 2015 01:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjdHn1fVNkzd for ; Mon, 4 May 2015 01:31:19 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766D31A1AFF for ; Mon, 4 May 2015 01:31:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 558CDAFD; Mon, 4 May 2015 10:31:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mB0ErqPUrAbf; Mon, 4 May 2015 10:31:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 4 May 2015 10:31:16 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68DAC2003C; Mon, 4 May 2015 10:31:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id baOCc2DIxGmm; Mon, 4 May 2015 10:31:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1FB0920031; Mon, 4 May 2015 10:31:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 10DA233030E2; Mon, 4 May 2015 10:31:15 +0200 (CEST) Date: Mon, 4 May 2015 10:31:15 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150504083114.GA63125@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20150504.102509.954312726625270993.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150504.102509.954312726625270993.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 anyxml/anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 08:31:22 -0000 On Mon, May 04, 2015 at 10:25:09AM +0200, Martin Bjorklund wrote: > Hi, > > draft-ietf-netmod-rfc6020bis-05 includes solution Y34-05, except that > Y34-05 says: > > - Document that implementations MAY have restrictions for anyxml and > that anyxml is not necessarily interoperable; data model writers > should use anydata whenever possible. > > I don't think this text belongs in the specification of the language. > Was the intention to add this to 6087bis? Yes, sounds good to me to move this into 6087bis. /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 May 4 05:48:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714E31A0062 for ; Mon, 4 May 2015 05:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR-HvRy5kvdP for ; Mon, 4 May 2015 05:48:30 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9983D1A005F for ; Mon, 4 May 2015 05:48:28 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 5459E1CC02A7; Mon, 4 May 2015 14:48:26 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Xiang Li In-Reply-To: References: <20150430102958.GB55253@elstar.local> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <5542457C.3040909@seguesoft.com> <55425A71.3060501@seguesoft.com> <46CE075C-72CE-4E89-867F-3C751990967D@nic.cz> <5543A919.7000309@seguesoft.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 04 May 2015 14:48:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 12:48:33 -0000 Andy Bierman writes: > On Fri, May 1, 2015 at 9:26 AM, Xiang Li wrote: >> >> >> On 5/1/2015 5:25 AM, Ladislav Lhotka wrote: >>>> >>>> On 30 Apr 2015, at 19:22, Andy Bierman wrote: >>>> >>>> On Thu, Apr 30, 2015 at 10:13 AM, Ladislav Lhotka wrot= e: >>>>>> >>>>>> On 30 Apr 2015, at 18:50, Andy Bierman wrote: >>>>>> >>>>>> On Thu, Apr 30, 2015 at 9:38 AM, Xiang Li >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>>>>>>>> >>>>>>>>> On 30 Apr 2015, at 17:08, Xiang Li wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>>>>>>>> >>>>>>>>>>> On 30 Apr 2015, at 15:52, Xiang Li wrot= e: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wro= te: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I like to close Y45. It seems most people are fine with >>>>>>>>>>>>>>>>>> Y45-04. >>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>> may not be fully convinced or he wants a slight change of >>>>>>>>>>>>>>>>>> Y54-04 >>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>> turns import-by-revision semantically into >>>>>>>>>>>>>>>>>> import-by-min-revision. >>>>>>>>>>>>>>>>>> Xiang Li seems to support a motion to make >>>>>>>>>>>>>>>>>> import-by-revision >>>>>>>>>>>>>>>>>> mean >>>>>>>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> settle on >>>>>>>>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean >>>>>>>>>>>>>>>>>> indeed >>>>>>>>>>>>>>>>>> import-by-min-revision. (We would have to write this >>>>>>>>>>>>>>>>>> variation >>>>>>>>>>>>>>>>>> down >>>>>>>>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Two questions: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1. Is import-by-revision supposed to mean >>>>>>>>>>>>>>>>> import-by-min-revision >>>>>>>>>>>>>>>>> only >>>>>>>>>>>>>>>>> for augments? For groupings and typedefs it should IMO me= an >>>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>>> exact >>>>>>>>>>>>>>>>> revision. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I guess this would be more than just augments. Essentially = any >>>>>>>>>>>>>>> reference to an 'object' defined in an external module, >>>>>>>>>>>>>>> irrespective >>>>>>>>>>>>>>> whether the reference is via augments or a must/when statem= ent >>>>>>>>>>>>>>> or >>>>>>>>>>>>>>> anything else. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For must/when a revision makes even less sense because XPath >>>>>>>>>>>>>> expressions refer to an instance document rather than a modu= le. >>>>>>>>>>>>>> >>>>>>>>>>>>> But isn't the same is true for an augment that refers to a >>>>>>>>>>>>> target >>>>>>>>>>>>> that >>>>>>>>>>>>> is a list of a container? The target instance must not only be >>>>>>>>>>>>> defined, it must also exist for the augment to have an effect. >>>>>>>>>>>> >>>>>>>>>>>> No, the target node is by definition a schema node, an augment >>>>>>>>>>>> manipulates the schema - no instance is involved. >>>>>>>>>>>> >>>>>>>>>>>>> Anyway, the main idea behind Y45-04 is to use imports to hand= le >>>>>>>>>>>>> schema >>>>>>>>>>>>> tree dependencies that need to be unambiguous at module compi= le >>>>>>>>>>>>> time >>>>>>>>>>>>> and to leave instance tree dependencies to future work (e.g. a >>>>>>>>>>>>> package >>>>>>>>>>>>> definition system like Andy once proposed). >>>>>>>>>>>> >>>>>>>>>>>> For augments the package is in fact given by the hello message= or >>>>>>>>>>>> other form of data model specification, because an augment mak= es >>>>>>>>>>>> sense only >>>>>>>>>>>> if its target node is part of the schema. In fact, not only >>>>>>>>>>>> revision of the >>>>>>>>>>>> imported module is important here: >>>>>>>>>>> >>>>>>>>>>> "not only revision of the imported module is important..."? >>>>>>>>>>> >>>>>>>>>>> I thought you have been arguing for the contrary? Did you mean >>>>>>>>>>> "not >>>>>>>>>>> only revision of the advertised module is important=E2=80=A6"? >>>>>>>>>> >>>>>>>>>> Let=E2=80=99s go back to Andy=E2=80=99s example >>>>>>>>>> >>>>>>>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>>>>>>>> >>>>>>>>>> Andy wrote: =E2=80=9CThe 'aug1' developer clearly intends for th= e server to >>>>>>>>>> support base@2015-01-01.=E2=80=9D >>>>>>>>>> >>>>>>>>>> But let=E2=80=99s say the new enum in module =E2=80=9Cbase=E2=80= =9D is defined like so: >>>>>>>>>> >>>>>>>>>> enum fastest { >>>>>>>>>> if-feature foo; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Then I could argue that =E2=80=98aug1=E2=80=99 developer clearly= intends for the >>>>>>>>>> server >>>>>>>>>> to support not only base@2015-01-01 but also feature foo. Howeve= r, >>>>>>>>>> the >>>>>>>>>> latter requirement is not expressed in import-by-revision. >>>>>>>>> >>>>>>>>> Current YANG "enum" does not allow "if-feature" as its >>>>>>>>> substatement. >>>>>>>> >>>>>>>> >>>>>>>> Th one in YANG 1.1 proposal does. >>>>>>>> >>>>>>>>> But in general if things depend on some 'features' implemented in= an >>>>>>>>> augmented >>>>>>>>> base module then they are IMO by definition optional. In other >>>>>>>>> words, >>>>>>>>> 'aug1' developer can't >>>>>>>>> demand a server to support feature 'foo', if it is not advertised= . I >>>>>>>>> don't see that's relevant here. >>>>>>>> >>>>>>>> It is relevant - for the sake of this example, base@2015-01-01 >>>>>>>> without >>>>>>>> feature foo is essentially the same as base@2014-01-01. In both ca= ses >>>>>>>> the >>>>>>>> augment from the aug1 module cannot be applied. >>>>>>> >>>>>>> >>>>>>> I think the two scenarios are different. >>>>>>> >>>>>> quite different. >>>>>> >>>>>> The original point is that the designer of "aug1" is using >>>>>> definitions from the new "base" module. There is no way >>>>>> that the server can implement this "aug1" module using the >>>>>> old "base" module. >>>>>> >>>>>> The server does not support the new "fastest" enum. It is a lie to >>>>>> advertise that the leaf using this typedef is supported. >>>>> >>>>> The server advertises the old revision of =E2=80=9Cbase, thus making = clear that >>>>> is does *not* support the new =E2=80=9Cfastest=E2=80=9D enum. Therefo= re, it doesn=E2=80=99t lie. >>>>> Note that the fact that the augment in =E2=80=98aug1=E2=80=99 doesn= =E2=80=99t happen isn=E2=80=99t an error >>>>> from the YANG point of view - it just may or may not be what the serv= er >>>>> implementer intended. >>>>> >>>> If it advertises the old version of "base" then it cannot advertise >>>> "aug1". >>>> The client sees that advertisement and believes that the new revision >>>> of the typedef is supported. It has no reason to suspect that setting >>> >>> If Y45-04 is accepted, the client can never believe the new revision is >>> supported because it is clearly stated that the revision of the import = is >>> ignored for augments. >> >> >> That is what I still have doubt whether it is a good thing to do. >> >>> That is: >>> >>> - if a module is imported only for referring to its nodes (augments, >>> leafrefs, must/when), then the >>> import should be without revision because revision-date would be >>> ignored anyway. >> >> >> Why "revision-date" in this case must be ignored completely? >> >> If we do this, the author of "aug1" can not decide the version where he/= she >> wants to start. >> I think it makes sense for the author of "aug1" to be able to do that and >> set up some basic >> requirements for the implementer of "aug1", and that's why I said I pref= er >> for "augment" >> to use "min-revision-rule", unless it's the intention of the working gro= up >> to prevent the author >> of "agu1" from doing that for other legitimate reasons that I missed. >> >> >>> - if groupings or typedefs from the imported module are used, then the >>> exact revision of each is always >>> known either from revision-date, if present, or from server=E2=80=99s >>> advertisement. >> >> >> We already agreed on this. We are not ignoring "revision-date" in this c= ase >> either. >> >> -Xiang >> >>> I don=E2=80=99t think it it that complicated. >> > > I think it is clearly broken. > Using a fixed revision date for typedefs and groupings > but a variable revision-date for everything else can be easily > broken by mixing types/objects in must/when or > augment statements. I don't see how it can be broken - if multiple prefixes corresponding to the same module appear in must/when of in the target node specification, then it doesn't matter because the revision is ignored for all of them. And typedefs/groupings apprearing inside an augment are resolved in the context of the module defining the augment, so there is no ambiguity either. > > I noticed that the example given in Y45-04 for why we need > multiple imports of each module is somewhat flawed: > > import ietf-inet-types { > revision-date 2013-07-17; > prefix inet; > } > import ietf-inet-types { > revision-date 2010-09-24; > prefix inet6021; > } > leaf foo { > type inet:ip-address-no-zone; > } > leaf bar { > type inet6021:ip-address; > } > > > This example shows that author wants to use the new ip-address-no-zone > typedef that was added to RFC 6991, but is going to keep using the > old version of ip-address. > > 1) ip-address did not change at all from RFC 6021, so there is no > point in importing 2 revisions Right, there is no such need in this case. > > 2) even if the ip-address did change, is it really up the the author > of the importing module to decide the standard ip-address type? > Since the augmenting module is being updated anyway, it is OK I don't think the augmenting module has to be updated - but maybe I don't get what you mean. > to update the typedef. If it is the first version, then even worse > to pick the out-of-date typedef. > > If a typedef gets corrected (e.g., the pattern-stmt is wrong in the old > revision), then why do we want to let other modules keep using > the broken version? Why make YANG complicated so the user can > do the wrong thing? If the module author thinks it is safe to allow for automatic updates, he can use import without revision. On the other hand, typedefs and groupings can be updated in a way that require an update in the server implementation (new enums, extended range of an integer leaf, new nodes in a grouping), and then a fixed revision may be appropriate. Lada > > What if IPv7 gets added someday? Is it up to each WG, each module > to decide "We have no interest in supporting the new IP version. > We will stick with the current typedef forever". Is this OK, or > should the set of IETF modules use consistent data types? > >> >> No... Indeed it's not... >> >> -Xiang > > Andy --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon May 4 06:10:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28271A007F for ; Mon, 4 May 2015 06:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssluhFA8Mw8d for ; Mon, 4 May 2015 06:10:41 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 193F31A0069 for ; Mon, 4 May 2015 06:10:41 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 7F4B81CC02A7; Mon, 4 May 2015 15:10:40 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Martin Bjorklund In-Reply-To: <20150504083114.GA63125@elstar.local> References: <20150504.102509.954312726625270993.mbj@tail-f.com> <20150504083114.GA63125@elstar.local> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 04 May 2015 15:10:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 anyxml/anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 13:10:42 -0000 Juergen Schoenwaelder writes: > On Mon, May 04, 2015 at 10:25:09AM +0200, Martin Bjorklund wrote: >> Hi, >> >> draft-ietf-netmod-rfc6020bis-05 includes solution Y34-05, except that >> Y34-05 says: >> >> - Document that implementations MAY have restrictions for anyxml and >> that anyxml is not necessarily interoperable; data model writers >> should use anydata whenever possible. >> >> I don't think this text belongs in the specification of the language. >> Was the intention to add this to 6087bis? > > Yes, sounds good to me to move this into 6087bis. +1 Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed May 6 23:48:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79F61AD1EC; Wed, 6 May 2015 23:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baaMq2B41Giw; Wed, 6 May 2015 23:48:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DF12C1AD0D1; Wed, 6 May 2015 23:48:56 -0700 (PDT) Received: from ams3-vpn-dhcp4455.cisco.com (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id EE8B31AE046E; Thu, 7 May 2015 08:48:55 +0200 (CEST) From: Stefan Wallin Content-Type: multipart/alternative; boundary="Apple-Mail=_5B05F310-44D4-4B19-9A56-7E0FE690778D" Message-Id: Date: Thu, 7 May 2015 08:48:55 +0200 To: netmod@ietf.org, opsawg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [netmod] YANG Alarm Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 06:48:58 -0000 --Apple-Mail=_5B05F310-44D4-4B19-9A56-7E0FE690778D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi! We have posted a YANG alarm module: = http://tools.ietf.org/html/draft-vallin-alarm-yang-module-00 = Please review and send any comments and most important of all, is this = needed? Being able to read alarm status and get alarm notifications is a basic requirement for any manageable device. Device alarm interfaces needs to = be integrated to alarm management systems at service providers. A standardised interface for that integration would help a lot. = Currently, service providers need to read and understand various proprieatary alarm interfaces including enterprise specific MIBs. Many devices does not = even have a clear notion of alarms, just events in general. The telecom industry have been pushing standardised alarm interfaces for = every new generation of mangement interface protocol. This is usually the the = first data-model that is defined in telco standards. IETF did this a bit too = late for SNMP with the Alarm MIB (RFC 3877). All vendors already had implemented = alarm instrumentation and good or bad MIBs, so vendors argued about adding = support for this MIB afterwards and the MIB had to support fairly complex mapping capabilities to existing proprietary alarm MIBs. We have a chance to resolve this issue with a Alarm YANG Module. Going = forward vendors will write their own alarm modules if we do not provide an IETF = module. All feed-back welcome! Module summary: This YANG module defines an alarm interface for network devices. It includes functions for alarm list management and notifications to inform management systems. There are also RPCs to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. br Stefan and Martin --Apple-Mail=_5B05F310-44D4-4B19-9A56-7E0FE690778D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi!

We have posted a YANG alarm module: http://tools.ietf.org/html/draft-vallin-alarm-yang-module-00

Please review and send any comments and = most important of all, is this needed?

Being = able to read alarm status and get alarm notifications is a basic
requirement for any manageable device. Device alarm = interfaces needs to be
integrated to alarm management = systems at service providers.
A standardised interface for = that integration would help a lot. Currently,
service = providers need to read and understand various proprieatary alarm
interfaces including enterprise specific MIBs. Many devices = does not even have
a clear notion of alarms, just events = in general.

The telecom industry have been = pushing standardised alarm interfaces for every
new = generation of mangement interface protocol. This is usually the the = first
data-model that is defined in telco standards. IETF = did this a bit too late for
SNMP with the Alarm MIB (RFC = 3877). All vendors already had implemented alarm
instrumentation and good or bad MIBs, so vendors argued about = adding support for
this MIB afterwards and the MIB had to = support fairly complex mapping
capabilities to existing = proprietary alarm MIBs.

We have a chance to = resolve this issue with a Alarm YANG Module. Going forward
vendors will write their own alarm modules if we do not = provide an IETF module.

All feed-back = welcome!

Module summary:
  This YANG module defines an alarm interface for = network devices.  It
  includes functions = for alarm list management and notifications to
  inform management systems.  There are also = RPCs to manage the
  operator state of an alarm = and administrative alarm procedures.  The
  module carefully maps to relevant alarm = standards.


br Stefan and = Martin

= --Apple-Mail=_5B05F310-44D4-4B19-9A56-7E0FE690778D-- From nobody Thu May 7 01:33:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDF11A891A for ; Thu, 7 May 2015 01:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgCfygnUW8rR for ; Thu, 7 May 2015 01:33:49 -0700 (PDT) Received: from teledg001ba020.telecomitalia.it (teledg001ba020.telecomitalia.it [156.54.233.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528E91A890D for ; Thu, 7 May 2015 01:33:47 -0700 (PDT) Content-Type: multipart/mixed; boundary="_68f3b88f-d9cb-4895-b77a-dc2a6fbdf311_" Received: from TELCAH003BA020.telecomitalia.local (10.188.101.218) by teledg001ba020.telecomitalia.it (10.188.101.210) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 7 May 2015 10:33:43 +0200 Received: from TELMBA001BA020.telecomitalia.local ([169.254.1.224]) by telcah003ba020.telecomitalia.local ([10.188.101.218]) with mapi id 14.03.0181.006; Thu, 7 May 2015 10:33:43 +0200 From: De Noia Giuseppe To: "netmod@ietf.org" Thread-Topic: [netmod] YANG Alarm Module Thread-Index: AQHQiJHvFaQ95wqghUylYeJNOPsI951wLl6g Date: Thu, 7 May 2015 08:33:42 +0000 Message-ID: <167E7B4797E08C4DBC40AED09620195943C95C57@TELMBA001BA020.telecomitalia.local> References: In-Reply-To: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.188.101.188] x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Archived-At: Subject: [netmod] R: YANG Alarm Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 08:33:52 -0000 --_68f3b88f-d9cb-4895-b77a-dc2a6fbdf311_ Content-Type: multipart/alternative; boundary="_000_167E7B4797E08C4DBC40AED09620195943C95C57TELMBA001BA020t_" --_000_167E7B4797E08C4DBC40AED09620195943C95C57TELMBA001BA020t_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, very interesting module. However I have a question. I suppose this module will be used in netconf Ev= ent Notification framework (rfc 5277). In this case, does a network manager= need to have as many SSH open sessions as the managed devices are? They co= uld be thousands.. Regards, Pino De Noia ------------------------------------------------------------------ Telecom Italia Giuseppe De Noia T.TG.NM.OSI, Via Reiss Romoli, 274 10148 Torino 011 2288887 331 6001197 Da: netmod [mailto:netmod-bounces@ietf.org] Per conto di Stefan Wallin Inviato: gioved=EC 7 maggio 2015 08:49 A: netmod@ietf.org; opsawg@ietf.org Oggetto: [netmod] YANG Alarm Module Hi! We have posted a YANG alarm module: http://tools.ietf.org/html/draft-vallin= -alarm-yang-module-00 Please review and send any comments and most important of all, is this need= ed? Being able to read alarm status and get alarm notifications is a basic requirement for any manageable device. Device alarm interfaces needs to be integrated to alarm management systems at service providers. A standardised interface for that integration would help a lot. Currently, service providers need to read and understand various proprieatary alarm interfaces including enterprise specific MIBs. Many devices does not even h= ave a clear notion of alarms, just events in general. The telecom industry have been pushing standardised alarm interfaces for ev= ery new generation of mangement interface protocol. This is usually the the fir= st data-model that is defined in telco standards. IETF did this a bit too late= for SNMP with the Alarm MIB (RFC 3877). All vendors already had implemented ala= rm instrumentation and good or bad MIBs, so vendors argued about adding suppor= t for this MIB afterwards and the MIB had to support fairly complex mapping capabilities to existing proprietary alarm MIBs. We have a chance to resolve this issue with a Alarm YANG Module. Going forw= ard vendors will write their own alarm modules if we do not provide an IETF mod= ule. All feed-back welcome! Module summary: This YANG module defines an alarm interface for network devices. It includes functions for alarm list management and notifications to inform management systems. There are also RPCs to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. br Stefan and Martin Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non = =E8 necessario. --_000_167E7B4797E08C4DBC40AED09620195943C95C57TELMBA001BA020t_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

very interesting module.

However I ha= ve a question. I suppose this module will be used in netconf Event Notifica= tion framework (rfc 5277). In this case, does a network manager need to have as many SSH open sessions as the managed devices are? They co= uld be thousands..

Regards,

Pino De Noia=

--------------= ----------------------------------------------------
Telecom Italia
Giuseppe De Noia

T.TG.NM.OSI,

Via Reiss Romoli, 274 = ; 10148 Torino
011 2288887
331 6001197

 <= /o:p>

 <= /o:p>

Da: netmod= [mailto:netmod-bounces@ietf.org] Per conto di Stefan Wallin
Inviato: gioved=EC 7 maggio 2015 08:49
A: netmod@ietf.org; opsawg@ietf.org
Oggetto: [netmod] YANG Alarm Module

 

Hi!

 

We have posted a YANG alarm module: http://tools.= ietf.org/html/draft-vallin-alarm-yang-module-00

Please review and send any comments and most important of all, is this need= ed?

Being able to read alarm status and get alarm notifications is a basic
requirement for any manageable device. Device alarm interfaces needs to be<= br> integrated to alarm management systems at service providers.
A standardised interface for that integration would help a lot. Currently,<= br> service providers need to read and understand various proprieatary alarm interfaces including enterprise specific MIBs. Many devices does not even h= ave
a clear notion of alarms, just events in general.

The telecom industry have been pushing standardised alarm interfaces for ev= ery
new generation of mangement interface protocol. This is usually the the fir= st
data-model that is defined in telco standards. IETF did this a bit too late= for
SNMP with the Alarm MIB (RFC 3877). All vendors already had implemented ala= rm
instrumentation and good or bad MIBs, so vendors argued about adding suppor= t for
this MIB afterwards and the MIB had to support fairly complex mapping
capabilities to existing proprietary alarm MIBs.

We have a chance to resolve this issue with a Alarm YANG Module. Going forw= ard
vendors will write their own alarm modules if we do not provide an IETF mod= ule.

All feed-back welcome!

Module summary:
  This YANG module defines an alarm interface for network devices= .  It
  includes functions for alarm list management and notifications = to
  inform management systems.  There are also RPCs to manage = the
  operator state of an alarm and administrative alarm procedures.=  The
  module carefully maps to relevant alarm standards.


br Stefan and Martin

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_167E7B4797E08C4DBC40AED09620195943C95C57TELMBA001BA020t_-- --_68f3b88f-d9cb-4895-b77a-dc2a6fbdf311_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_68f3b88f-d9cb-4895-b77a-dc2a6fbdf311_-- From nobody Thu May 7 01:36:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FCE1A8920 for ; Thu, 7 May 2015 01:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuLmaAM12qNE for ; Thu, 7 May 2015 01:36:12 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6A79D1A890D for ; Thu, 7 May 2015 01:36:12 -0700 (PDT) Received: from ams3-vpn-dhcp4455.cisco.com (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id F36921AE046E; Thu, 7 May 2015 10:36:10 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_13768E77-35CE-4815-9D17-814024E78AB8" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Stefan Wallin In-Reply-To: <167E7B4797E08C4DBC40AED09620195943C95C57@TELMBA001BA020.telecomitalia.local> Date: Thu, 7 May 2015 10:36:10 +0200 Message-Id: References: <167E7B4797E08C4DBC40AED09620195943C95C57@TELMBA001BA020.telecomitalia.local> To: De Noia Giuseppe X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG Alarm Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 08:36:15 -0000 --Apple-Mail=_13768E77-35CE-4815-9D17-814024E78AB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi! Yes, that is certainly a concern and where SNMP UDP notifications has = its benefits :) I have in mind a mapping to SNMP notifications for this same module, = could maybe make sense. br Stefan > On 07 May 2015, at 10:33, De Noia Giuseppe = wrote: >=20 > Hi, > very interesting module. > However I have a question. I suppose this module will be used in = netconf Event Notification framework (rfc 5277). In this case, does a = network manager need to have as many SSH open sessions as the managed = devices are? They could be thousands.. > Regards, > Pino De Noia > ------------------------------------------------------------------ > Telecom Italia > Giuseppe De Noia > T.TG.NM.OSI, > Via Reiss Romoli, 274 10148 Torino > 011 2288887 > 331 6001197 > =20 > =20 > Da: netmod [mailto:netmod-bounces@ietf.org = ] Per conto di Stefan Wallin > Inviato: gioved=EC 7 maggio 2015 08:49 > A: netmod@ietf.org ; opsawg@ietf.org = > Oggetto: [netmod] YANG Alarm Module > =20 > Hi! > =20 > We have posted a YANG alarm module: = http://tools.ietf.org/html/draft-vallin-alarm-yang-module-00 = >=20 > Please review and send any comments and most important of all, is this = needed? >=20 > Being able to read alarm status and get alarm notifications is a basic > requirement for any manageable device. Device alarm interfaces needs = to be > integrated to alarm management systems at service providers. > A standardised interface for that integration would help a lot. = Currently, > service providers need to read and understand various proprieatary = alarm > interfaces including enterprise specific MIBs. Many devices does not = even have > a clear notion of alarms, just events in general. >=20 > The telecom industry have been pushing standardised alarm interfaces = for every > new generation of mangement interface protocol. This is usually the = the first > data-model that is defined in telco standards. IETF did this a bit too = late for > SNMP with the Alarm MIB (RFC 3877). All vendors already had = implemented alarm > instrumentation and good or bad MIBs, so vendors argued about adding = support for > this MIB afterwards and the MIB had to support fairly complex mapping > capabilities to existing proprietary alarm MIBs. >=20 > We have a chance to resolve this issue with a Alarm YANG Module. Going = forward > vendors will write their own alarm modules if we do not provide an = IETF module. >=20 > All feed-back welcome! >=20 > Module summary: > This YANG module defines an alarm interface for network devices. It > includes functions for alarm list management and notifications to > inform management systems. There are also RPCs to manage the > operator state of an alarm and administrative alarm procedures. The > module carefully maps to relevant alarm standards. >=20 >=20 > br Stefan and Martin > =20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. > This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. >=20 > Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario. >=20 > --Apple-Mail=_13768E77-35CE-4815-9D17-814024E78AB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi!
Yes, that is certainly a concern and where = SNMP UDP notifications has its benefits :)
I have = in mind a mapping to SNMP notifications for this same module, could = maybe make sense.
br Stefan


On 07 May 2015, at 10:33, De = Noia Giuseppe <giuseppe.denoia@telecomitalia.it> wrote:

Hi,
very interesting module.
However I have a question. I suppose this module will = be used in netconf Event Notification framework (rfc 5277). In this = case, does a network manager need to have as many SSH open sessions as = the managed devices are? They could be thousands..
Regards,
Pino De Noia
---------------------------------------------------------------= ---
Telecom = Italia
Giuseppe De Noia
T.TG.NM.OSI,
Via= Reiss Romoli, 274  10148 Torino
011 2288887
331 6001197
 
 
Da: netmod [mailto:netmod-bounces@ietf.org] Per conto = di Stefan = Wallin
Inviato: gioved=EC 7 maggio 2015 = 08:49
A: netmod@ietf.org; opsawg@ietf.org
Oggetto: [netmod] YANG Alarm = Module
 
Hi!
 
We have posted a YANG alarm module: http://tools.ietf.org/html/draft-vallin-alarm-yang-module-00

Please review and send any comments and = most important of all, is this needed?

Being = able to read alarm status and get alarm notifications is a basic
requirement for any manageable device. Device alarm = interfaces needs to be
integrated to alarm management = systems at service providers.
A standardised interface for = that integration would help a lot. Currently,
service = providers need to read and understand various proprieatary alarm
interfaces including enterprise specific MIBs. Many devices = does not even have
a clear notion of alarms, just events = in general.

The telecom industry have been = pushing standardised alarm interfaces for every
new = generation of mangement interface protocol. This is usually the the = first
data-model that is defined in telco standards. IETF = did this a bit too late for
SNMP with the Alarm MIB (RFC = 3877). All vendors already had implemented alarm
instrumentation and good or bad MIBs, so vendors argued about = adding support for
this MIB afterwards and the MIB had to = support fairly complex mapping
capabilities to existing = proprietary alarm MIBs.

We have a chance to = resolve this issue with a Alarm YANG Module. Going forward
vendors will write their own alarm modules if we do not = provide an IETF module.

All feed-back = welcome!

Module summary:
  This YANG module defines an alarm interface for = network devices.  It
  includes functions = for alarm list management and notifications to
  inform management systems.  There are also = RPCs to manage the
  operator state of an alarm = and administrative alarm procedures.  The
  module carefully maps to relevant alarm = standards.


br Stefan and = Martin
 
Questo = messaggio e i suoi allegati sono indirizzati esclusivamente alle persone = indicate. La diffusione, copia o qualsiasi altra azione derivante dalla = conoscenza di queste informazioni sono rigorosamente vietate. Qualora = abbiate ricevuto questo documento per errore siete cortesemente pregati = di darne immediata comunicazione al mittente e di provvedere alla sua = distruzione, Grazie.

This e-mail = and any attachments is confidential and may contain privileged information intended = for the addressee(s) only. Dissemination, copying, printing or use by = anybody else is unauthorised. If you are not the intended recipient, = please delete this message and any attachments and advise the sender by = return e-mail, Thanks.

<logo = Ambiente_foglia2.jpg>Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario.

<logo = Ambiente_foglia2.jpg>

= --Apple-Mail=_13768E77-35CE-4815-9D17-814024E78AB8-- From nobody Thu May 7 01:43:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC0E1A8A16 for ; Thu, 7 May 2015 01:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCY3gtWAEaqj for ; Thu, 7 May 2015 01:43:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53021A8AE5 for ; Thu, 7 May 2015 01:43:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B0DF91013; Thu, 7 May 2015 10:43:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id aS2V1fEc3anJ; Thu, 7 May 2015 10:43:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 7 May 2015 10:43:18 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0CAC20033; Thu, 7 May 2015 10:43:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OvV2LCLjcw68; Thu, 7 May 2015 10:43:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7ADD120013; Thu, 7 May 2015 10:43:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ADF713307754; Thu, 7 May 2015 10:43:14 +0200 (CEST) Date: Thu, 7 May 2015 10:43:14 +0200 From: Juergen Schoenwaelder To: De Noia Giuseppe Message-ID: <20150507084312.GA6008@elstar.local> Mail-Followup-To: De Noia Giuseppe , "netmod@ietf.org" References: <167E7B4797E08C4DBC40AED09620195943C95C57@TELMBA001BA020.telecomitalia.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <167E7B4797E08C4DBC40AED09620195943C95C57@TELMBA001BA020.telecomitalia.local> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] R: YANG Alarm Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 08:43:22 -0000 On Thu, May 07, 2015 at 08:33:42AM +0000, De Noia Giuseppe wrote: > However I have a question. I suppose this module will be used in > netconf Event Notification framework (rfc 5277). In this case, does > a network manager need to have as many SSH open sessions as the > managed devices are? They could be thousands.. There is work on call home mechanisms in the NETCONF WG and perhaps a call home mechanism can also be used to establish a secure notification delivery channel on demand (e.g., device calls home, NETCONF client establishes a notification subscription e.g. using a suitable replay and the NETCONF server then sends any of the pending cached events). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu May 7 07:46:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC23A1A90DF for ; Thu, 7 May 2015 07:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UJP-YXJosz9 for ; Thu, 7 May 2015 07:45:57 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F36D1A90DC for ; Thu, 7 May 2015 07:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7414; q=dns/txt; s=iport; t=1431009957; x=1432219557; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZVdwl77CgmkyRPWqgkhjarrWfRnjeR6GUIXFkARA5ug=; b=j5wLu8bIZ9AnsJFMSfuF+h0HJOFIwMIof/5T7fhJCjiBOQD2VU4XiGqn dUMJCju4MC3U8zB99AkvTPZarMzOpthwQn3CEyLZEIFZGmJ5CUzMfBuzH f8XeCaURnoTZiDLnm5LkWxfjyTc4y6yDCaCJmGjCQ4TFilnzZXDzs7YsW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CxBADveUtV/4kNJK1cgkVHVF4GxVcJh1sCgTM4FAEBAQEBAQGBCoQgAQEBBC1MEAIBCBEEAQELHQcyFAkIAgQBDQUIiCTGIAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOYRUMQYBgxeBFgEEkiihESNhgxVvgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,384,1427760000"; d="scan'208,217";a="148027984" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP; 07 May 2015 14:45:56 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t47Ejuf6016399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 14:45:56 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.66]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 7 May 2015 09:45:56 -0500 From: "Alexander Clemm (alex)" To: Stefan Wallin , De Noia Giuseppe Thread-Topic: [netmod] YANG Alarm Module Thread-Index: AQHQiKDuHHzYNBR3xE2TGGnGklU/M51wlVvA Date: Thu, 7 May 2015 14:45:55 +0000 Message-ID: References: <167E7B4797E08C4DBC40AED09620195943C95C57@TELMBA001BA020.telecomitalia.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.161.89] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571DB381AAxmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG Alarm Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 14:45:59 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571DB381AAxmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One comment, below From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Stefan Wallin Sent: Thursday, May 07, 2015 1:36 AM To: De Noia Giuseppe Cc: netmod@ietf.org Subject: Re: [netmod] YANG Alarm Module Hi! Yes, that is certainly a concern and where SNMP UDP notifications has its b= enefits :) AC> Or syslog? ;-) I believe tie-in with syslog would be needed, in fact. --_000_DBC595ED2346914F9F81D17DD5C32B571DB381AAxmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One comment, below

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of Stefan Wallin
Sent: Thursday, May 07, 2015 1:36 AM
To: De Noia Giuseppe
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG Alarm Module

 

Hi!

Yes, that is certainly a concern and where SNMP UDP = notifications has its benefits :)

 <= /p>

AC>   Or syslog? ;-)

I believe tie-in with syslog would be needed, in fact. 

 

 

--_000_DBC595ED2346914F9F81D17DD5C32B571DB381AAxmbrcdx05ciscoc_-- From nobody Thu May 7 08:53:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451851ACD0F; Thu, 7 May 2015 08:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzcTHKAPxUlb; Thu, 7 May 2015 08:53:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868781ACCF0; Thu, 7 May 2015 08:53:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSG35636; Thu, 07 May 2015 15:53:07 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 May 2015 16:53:06 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Thu, 7 May 2015 08:53:01 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" , Kathleen Moriarty Thread-Topic: Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2Q== Date: Thu, 7 May 2015 15:53:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.99] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: [netmod] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:53:15 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e meetings. Among the two I2NSF interfaces, i.e. the client facing Service= Interface and the NSF facing Capability Interface, the work to be done at = the Capability Interface becomes very clear and concrete. But the Service I= nterface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one= IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises. In addition, the European Telecommunications = Standards Institute (ETSI) Network Function Virtualization (NFV) initiative= creates new management challenges for security policies to be enforced by = distributed, virtual, network security functions (vNSF). Without standard i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF. There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the client security policies, to security functions. = I2NSF will NOT standardize security functions or devices. Instead, I2NSF is= only to standardize the policy provisioning to the security functions (not= devices), in the form of "Subject - Object - Function - Action" paradigm. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers' logical= networks, addresses and context. I2NSF Service Layer can also be security = expectation or loose security requirement, especially for customers who don= 't have the security expertise. The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability= to flow based security function, and - The proper secure communication channels to carry the security p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing protocols and data models defined by I2RS, Netconf, and NETMOD. For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter= . (They are different from other security functions such as Authentication,= Authorization, or Encryption). Exemplar services associated with Flow Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors' specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols used by the WG. - Gap analysis of existing protocols and modeling languages - A single, unified, Information Model for expressing policies to = the Flow Based Security Functions described above. - Corresponding Data Models (e.g. YANG models) derived from the ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG. The framework, that describes the functional components and the I2NSF = work items, is to make I2NSF work more organized.] Suggested Milestones - Use Case Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 months to W= G document - Info model: Charter time + 7 months to WG Document - IANA registry consideration + 10 months to WG Document - All Early Drafts to IESG: 10 months [decision point - +10 months] - Data Models: Charter + 9 Months to WG Document - Applicability Statements: 10 months to WG Document - Data Models and Applicability Statements to IESG - 16 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to I2NSF contributors for the good progresses= made since  IETF92 side meetings. Among the two I2NSF interfaces, &nb= sp;i.e. the client facing Service Interface and the NSF facing Capability I= nterface, the work to be done at the Capability Interface becomes very clear and concrete. But the Service Interface is st= ill a little vague.

 

The feedback from last IETF side meetings was "= the scope is too big for one IETF WG". Therefore, we are leaning towar= ds narrowing the I2NSF scope to the Capability Interface. The thinking logi= c is: Once the Capability Interface is completed, we will see more clearly the work for Service interface. Even if Capabilit= y layer alone is standardized, it is a giant leap forward in building block= s for Service Provider to automate their Security Controller that can utili= ze NSF by multiple vendors

 

Here is the narrower scoped I2NSF charter. Your comm= ents and suggestions are greatly appreciated. CC’ed to DOTS, I2RS, an= d Netmod groups for wider review.

 

 <= /p>

 

Enterprises, residential, and mobile customers are i= ncreasingly consuming network functions, especially network security relate= d functions that are not running on their premises.  In addition, the = European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new manage= ment challenges for security policies to be enforced by distributed, virtua= l, network security functions (vNSF). Without standard interface to express= , monitor, and manage security policies to security functions deployed at different premises, it becomes virtually= impossible for security service providers to automate the service offering= utilizing security functions by multiple vendors.

 

The ultimate goal of I2NSF is to enable enterprises = to utilize security functions not hosted on their own premises but instead = hosted in service provider domain, to establish how to communicate desired = security policies to NSF and how to get performance data or report out of NSF or vNSF.

 

There are two layers of interfaces:

-       = ;   Security Policies facing security functions (I2NSF = Capability Layer)

-       = ;   Security Policies facing clients (I2NSF Service Lay= er)

 

The I2NSF Capability Lay= er specifies the functional security policies, which are translated from th= e client security policies, to security functions. I2NSF will NOT standardi= ze security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to the security funct= ions (not devices), in the form of “Subject – Object – Fu= nction – Action” paradigm. 

 =

The I2NSF Service Layer is for clients to express an= d monitor security policies for their specific flows, which is usually base= d on customers’ logical networks, addresses and context. I2NSF Servic= e Layer can also be security expectation or loose security requirement, especially for customers who don’t ha= ve the security expertise.

 

The concrete work at the L2NSF Capability Layer incl= udes

-  &= nbsp;       The informational & data models for each= category to be represented to virtual or physical network security functio= ns,

-  &= nbsp;       The capability registry (IANA) of policy pro= visioning capability to flow based security function, and

-  &= nbsp;       The proper secure communication channels to = carry the security policies between Controller and NSFs.

The capability registry is to make it feasible to ca= tegorize network security functions provided by different vendors based on = security policy provisioning capability without any need to standardize sec= urity functions themselves.  Standard provisioning capability interface is an essential building block for Secur= ity Service Provider to automate their Security Controllers that can utiliz= e NSF by multiple vendors. This layer will leverage the existing protocols = and data models defined by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service Layer, it is out of the scope = for I2NSF (at least for now) to standardize the interface facing clients. H= owever, I2NSF can have informational drafts showing sample APIs or/and REST= ful interfaces to clients and demonstrating the feasibility of them being translated to the Capability Layer policies.=

 =

Since different security vendors support different f= eatures & functions on their devices, I2NSF will focus on flow based se= curity functions that provide treatment to packets/flows, such as IPS/IDS, = Web filter, and flow filter. (They are different from other security functions such as Authentication, Authorizat= ion, or Encryption). Exemplar services associated with Flow Based Security = functions include deep packet inspection, packet/flow/stream filtering or p= attern matching and remediation, etc.

 

Similar to I2RS focusing on the interface to RIB/FIB= even though most routers provide far more functions than RIB/FIB, the I2NS= F focused functions can be a portion of features supported by vendors’= ; specific devices.

 

It is a non-goal to create new protocols or data mod= eling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-       = ;    Use Case document.

-       = ;   Framework Document.

-       = ;   Requirement for extensions (if there are any) to ex= isting protocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages

-       = ;   A single, unified, Information Model for expressing= policies to the Flow Based Security Functions described above.<= /p>

-       = ;   Corresponding Data Models (e.g. YANG models) derive= d from the above Information Model.

-       = ;   IANA registry consideration for flow based security= function policy provisioning capability.

-       = ;    (Optionally) Applicability Statements on how = to use I2RS, Netconf, and NETMOD to carry the content of the specified info= rmation/data models.

 

[The W= G may decide that the Use cases, Framework, and Requirement are Information= al documents or simply reference documents during the lifetime of the WG. The framework, that describes the functional components = and the I2NSF work items, is to make I2NSF work more organized.]

 

Suggested Milestones

  - Use Case Document:  Charter time += 1 month to WG Document

  - Framework: Charter time + 4 months to W= G Document

  - Requirements for extensions to protocols:&n= bsp; Charter time + 6 months to WG document

  - Info model: Charter time + 7 months to = WG Document

  - IANA registry consideration + 10 months= to WG Document

  - All Early Drafts to IESG: 10 months

 

[decision point – +10 months]  <= /o:p>

  - Data Models: Charter + 9 Months to= WG Document

  - Applicability Statements: 10 months to WG D= ocument

  - Data Models and Applicability Statements to= IESG  - 16 months

 

The WG will work c= losely with I2RS, Netconf and Netmod WGs. The WG will communicate with exte= rnal SDOs like ETSI NFV and will encourage open source code development rel= ated to the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 <= /p>

 

Cheers,

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_-- From nobody Thu May 7 13:10:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9579A1ACEC3 for ; Thu, 7 May 2015 13:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NavbrqXVQg7R for ; Thu, 7 May 2015 13:10:45 -0700 (PDT) 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 EE61F1ACEA8 for ; Thu, 7 May 2015 13:10:44 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 7241B41AC148B; Thu, 7 May 2015 20:10:38 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t47KAcoe000680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 16:10:40 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.179]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 7 May 2015 16:10:38 -0400 From: "Sterne, Jason (Jason)" To: Stefan Wallin , De Noia Giuseppe Thread-Topic: [netmod] YANG Alarm Module Thread-Index: AQHQiKDmGjpS5MZA2E+J+Y5JNTbJ0Z1w8l4w Date: Thu, 7 May 2015 20:10:38 +0000 Message-ID: References: <167E7B4797E08C4DBC40AED09620195943C95C57@TELMBA001BA020.telecomitalia.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5C9FF279US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG Alarm Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:10:47 -0000 --_000_A125E53CE190A749957C19483DC79F9F5C9FF279US70TWXCHMBA11z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Or alternate streaming-type transport options for NETCONF notifications ? From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Stefan Wallin Sent: Thursday, May 07, 2015 4:36 AM To: De Noia Giuseppe Cc: netmod@ietf.org Subject: Re: [netmod] YANG Alarm Module Hi! Yes, that is certainly a concern and where SNMP UDP notifications has its b= enefits :) I have in mind a mapping to SNMP notifications for this same module, could = maybe make sense. br Stefan On 07 May 2015, at 10:33, De Noia Giuseppe > wrote: Hi, very interesting module. However I have a question. I suppose this module will be used in netconf Ev= ent Notification framework (rfc 5277). In this case, does a network manager= need to have as many SSH open sessions as the managed devices are? They co= uld be thousands.. Regards, Pino De Noia ------------------------------------------------------------------ Telecom Italia Giuseppe De Noia T.TG.NM.OSI, Via Reiss Romoli, 274 10148 Torino 011 2288887 331 6001197 Da: netmod [mailto:netmod-bounces@ietf.org] Per conto di Stefan Wallin Inviato: gioved=EC 7 maggio 2015 08:49 A: netmod@ietf.org; opsawg@ietf.org Oggetto: [netmod] YANG Alarm Module Hi! We have posted a YANG alarm module: http://tools.ietf.org/html/draft-vallin= -alarm-yang-module-00 Please review and send any comments and most important of all, is this need= ed? Being able to read alarm status and get alarm notifications is a basic requirement for any manageable device. Device alarm interfaces needs to be integrated to alarm management systems at service providers. A standardised interface for that integration would help a lot. Currently, service providers need to read and understand various proprieatary alarm interfaces including enterprise specific MIBs. Many devices does not even h= ave a clear notion of alarms, just events in general. The telecom industry have been pushing standardised alarm interfaces for ev= ery new generation of mangement interface protocol. This is usually the the fir= st data-model that is defined in telco standards. IETF did this a bit too late= for SNMP with the Alarm MIB (RFC 3877). All vendors already had implemented ala= rm instrumentation and good or bad MIBs, so vendors argued about adding suppor= t for this MIB afterwards and the MIB had to support fairly complex mapping capabilities to existing proprietary alarm MIBs. We have a chance to resolve this issue with a Alarm YANG Module. Going forw= ard vendors will write their own alarm modules if we do not provide an IETF mod= ule. All feed-back welcome! Module summary: This YANG module defines an alarm interface for network devices. It includes functions for alarm list management and notifications to inform management systems. There are also RPCs to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. br Stefan and Martin Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se= non =E8 necessario. --_000_A125E53CE190A749957C19483DC79F9F5C9FF279US70TWXCHMBA11z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Or alternate streaming-ty= pe transport options for NETCONF notifications ?

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of Stefan Wallin
Sent: Thursday, May 07, 2015 4:36 AM
To: De Noia Giuseppe
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG Alarm Module

 

Hi!

Yes, that is certainly a concern and where SNMP UDP = notifications has its benefits :)

I have in mind a mapping to SNMP notifications for t= his same module, could maybe make sense.

br Stefan

 

 

 

Hi,

very interesting module.

However I have a question. I suppose th= is module will be used in netconf Event Notification framework (rfc 5277). = In this case, does a network manager need to have as many SSH open sessions as the managed devices are? They could be thousands..

Regards,

Pino De Noia

--------------= ----------------------------------------------------
Telecom Italia
Giuseppe De Noia

T.TG.NM.OSI,

Via Reiss Romoli, 274 = ; 10148 Torino
011 2288887
331 6001197

 

 

Da: netmod [m= ailto:netmod-bounces@ietf.org] Per conto di = ;Stefan Wallin
Inviato: gioved=EC= 7 maggio 2015 08:49
A: netmod@ietf.org= ; opsawg@ietf.org
Oggetto: [netmod] = YANG Alarm Module

 

Hi!

 

We have posted a YANG alarm module: http://tools.ietf.org/html/draft-vallin-alarm-yang-module= -00

Please review and send any comments and most important of all, is this need= ed?

Being able to read alarm status and get alarm notifications is a basic
requirement for any manageable device. Device alarm interfaces needs to be<= br> integrated to alarm management systems at service providers.
A standardised interface for that integration would help a lot. Currently,<= br> service providers need to read and understand various proprieatary alarm interfaces including enterprise specific MIBs. Many devices does not even h= ave
a clear notion of alarms, just events in general.

The telecom industry have been pushing standardised alarm interfaces for ev= ery
new generation of mangement interface protocol. This is usually the the fir= st
data-model that is defined in telco standards. IETF did this a bit too late= for
SNMP with the Alarm MIB (RFC 3877). All vendors already had implemented ala= rm
instrumentation and good or bad MIBs, so vendors argued about adding suppor= t for
this MIB afterwards and the MIB had to support fairly complex mapping
capabilities to existing proprietary alarm MIBs.

We have a chance to resolve this issue with a Alarm YANG Module. Going forw= ard
vendors will write their own alarm modules if we do not provide an IETF mod= ule.

All feed-back welcome!

Module summary:
  This YANG module defines an alarm interface for network devices= .  It
  includes functions for alarm list management and notifications = to
  inform management systems.  There are also RPCs to manage = the
  operator state of an alarm and administrative alarm procedures.=  The
  module carefully maps to relevant alarm standards.


br Stefan and Martin

 

Questo messaggio e i suoi allegati sono indirizzati esclusi= vamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.<= /span>

This e-mail and an= y attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.<= /p>

<logo= Ambiente_foglia2.jpg>Rispetta l'ambiente. Non stampare questa mail se n= on =E8 necessario.

<logo Ambiente_foglia2.jpg>

 

--_000_A125E53CE190A749957C19483DC79F9F5C9FF279US70TWXCHMBA11z_-- From nobody Thu May 7 13:14:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BFD1ACEEC for ; Thu, 7 May 2015 13:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP4st8dkqdUI for ; Thu, 7 May 2015 13:14:53 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9B01ACEDD for ; Thu, 7 May 2015 13:14:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 64C858E3; Thu, 7 May 2015 22:14:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GNNepJjjLWVo; Thu, 7 May 2015 22:14:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 7 May 2015 22:14:51 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC0162002B; Thu, 7 May 2015 22:14:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mFr2JQHsNGy2; Thu, 7 May 2015 22:14:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE72F20013; Thu, 7 May 2015 22:14:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B624B3309917; Thu, 7 May 2015 22:14:50 +0200 (CEST) Date: Thu, 7 May 2015 22:14:50 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Jason)" Message-ID: <20150507201450.GB13768@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" , Stefan Wallin , De Noia Giuseppe , "netmod@ietf.org" References: <167E7B4797E08C4DBC40AED09620195943C95C57@TELMBA001BA020.telecomitalia.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG Alarm Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:14:55 -0000 On Thu, May 07, 2015 at 08:10:38PM +0000, Sterne, Jason (Jason) wrote: > Or alternate streaming-type transport options for NETCONF notifications ? The topic how to transport YANG defined notifications seems to belongs to the NETCONF WG mailing list and not really to the NETMOD mailing list (although I understand why it started here). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu May 7 13:44:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F9E1AD26E; Thu, 7 May 2015 13:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7qYmMtD5DNG; Thu, 7 May 2015 13:44:09 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 497151AD289; Thu, 7 May 2015 13:43:53 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so49728782pac.1; Thu, 07 May 2015 13:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=akjOkYjdHma9lcD19dKRgStVTf+Ok0VG5FwZhZlhWvY=; b=sP1Yd/t79twEiyIXfKvgJOpux44SPaEnlOY66a/I23TgcuTRSV01BBQqZvxi6S3JCF VgqtDRncYEIQuM3LkKd8JgU2CZVngB08Xew3m8cF/SEKBQEc+iFEtEuZGO3GddENBPFX CwQt+cfV3y8Pe2qrylZsQQZkUnkmbB1Sv7WbC2qXS9VV0+kQY2Kb3vuH5tE6J6wfIVJr tuMGpFc7pmu2Mdccbd1xe+sWVBxnyQF6ERMA+EurYL6LvEpjsSt8Tm6pwXD2kbr+i1Co /J5fsmpnjF0ORIOLe7CAHrF9r5Xiv8j1VTKTzew54idky1D1vLCRHdO5uPhzAXsbctsh M7RA== X-Received: by 10.68.106.193 with SMTP id gw1mr263224pbb.111.1431031432992; Thu, 07 May 2015 13:43:52 -0700 (PDT) Received: from ?IPv6:2001:420:302:1330:7197:4184:582e:ba8f? ([2001:420:302:1330:7197:4184:582e:ba8f]) by mx.google.com with ESMTPSA id cp10sm3028451pdb.44.2015.05.07.13.43.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 May 2015 13:43:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 7 May 2015 13:43:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <32144132-ACB1-4CB5-A6EC-8CE6515E6318@gmail.com> References: <167E7B4797E08C4DBC40AED09620195943C95C57@TELMBA001BA020.telecomitalia.local> <20150507201450.GB13768@elstar.local> To: "netmod@ietf.org" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netconf Subject: Re: [netmod] YANG Alarm Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:44:10 -0000 [Cross-posting it to NETCONF] Stefan, did try to post to netconf, but it got blocked because he was = not subscribed to the mailing list. I agree with Juegen that the topic of what transport mechanism is used = belongs to the NETCONF WG, and is certainly an area of interest to the = WG. [Chair hat off] In trying to address the issue, we need to address the issue of what = happens if there are either no sessions connected to the server or = thousands of them. For the latter, we might have to look at a pub/sub = model to contain where alarms get delivered. Throw in other = notifications and now you are looking at prioritizing event = notifications, as I am sure alarms would like to be treated at a = different priority. p.s. Pardon my multiple attempts to post this message >=20 >>=20 >>> On May 7, 2015, at 1:14 PM, Juergen Schoenwaelder = wrote: >>>=20 >>> On Thu, May 07, 2015 at 08:10:38PM +0000, Sterne, Jason (Jason) = wrote: >>>=20 >>>> Or alternate streaming-type transport options for NETCONF = notifications ? >>>=20 >>> The topic how to transport YANG defined notifications seems to = belongs >>> to the NETCONF WG mailing list and not really to the NETMOD mailing >>> list (although I understand why it started here). >>>=20 >>> /js >>>=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Sat May 9 10:32:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B66D1A6EE9; Sat, 9 May 2015 08:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En-8asQGPoUB; Sat, 9 May 2015 08:54:54 -0700 (PDT) Received: from mxe02.gs.com (mxe02.gs.com [199.99.47.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E661A3BA0; Sat, 9 May 2015 08:54:53 -0700 (PDT) Received: from pps.filterd (gsppabdp02sd.idz.gs.com [127.0.0.1]) by gsppabdp02sd.idz.gs.com (8.14.5/8.14.5) with SMTP id t49Fssfm025057; Sat, 9 May 2015 11:54:54 -0400 Received: from gsppabdp04nd.inz.gs.com ([10.204.43.243]) by gsppabdp02sd.idz.gs.com with ESMTP id 1u9dk2sdnt-1; Sat, 09 May 2015 11:54:54 -0400 Received: from pps.filterd (gsppabdp04nd.inz.gs.com [127.0.0.1]) by gsppabdp04nd.inz.gs.com (8.14.5/8.14.5) with SMTP id t49FsVgN016925; Sat, 9 May 2015 11:54:46 -0400 Received: from gshcbdp13ex.firmwide.corp.gs.com (gshcbdp13ex.firmwide.corp.gs.com [10.135.172.22]) by gsppabdp04nd.inz.gs.com with ESMTP id 1u961u1ubs-1; Sat, 09 May 2015 11:54:46 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp13ex.firmwide.corp.gs.com ([10.135.172.22]) with mapi; Sat, 9 May 2015 11:54:45 -0400 From: "Zarny, Myo" To: "'Linda Dunbar'" , "'i2nsf@ietf.org'" , "'Kathleen Moriarty'" Date: Sat, 9 May 2015 11:54:43 -0400 Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QBji2Zg Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230721826C6FGSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-09_02:2015-05-09,2015-05-09,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-09_02:2015-05-09,2015-05-09,1970-01-01 signatures=0 Archived-At: X-Mailman-Approved-At: Sat, 09 May 2015 10:32:13 -0700 Cc: "'i2rs@ietf.org'" , "'dots@ietf.org'" , "'netmod@ietf.org'" Subject: Re: [netmod] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 15:55:00 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230721826C6FGSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, Thanks very much for putting this together. I agree that the scope needs to= be tightened if it is to be meaningful. I'm fine with the suggested delive= rables, milestones, etc. BUT we should tweak the first two paragraphs relat= ed to the goal of the WG. I2NSF shouldn't take a position on where the secu= rity functions are hosted or if the caller and the security service functio= n belong to the same or different domains. Also, not sure if we should brin= g in another organization's name (ETSI) into an IETF charter. I've taken a stab at rewording the first few paragraphs... Network security functions (NSFs) are increasingly provided and consumed in= increasingly diverse environments. Users of NSFs could consume network sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. Likewise, service prov= iders may offer their customers network security services that consist of m= ultiple security products from different vendors. Yet because no widely acc= epted industry standard security interfaces exist today, management of NSFs= (device and policy provisioning, monitoring, etc.) tends to be bespoke, es= sentially as offered by product vendors. As a result, automation of such se= rvices, if it exists at all, is also bespoke. The primary goal of I2NSF is to define a set of interfaces and data models = for policy provisioning and management aspects of NSFs. Other aspects of NS= Fs such as device or network provisioning are out of scope. The scope of I2NSF can be further divided into two layers: * I2NSF Capabilities Layer * I2NSF Services Layer ... I've made a few comments inline below as well. I'm not familiar with how detailed a charter needs to be, so I'll leave it = others to comment on whether the level of detail here is sufficient, too mu= ch or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e meetings. Among the two I2NSF interfaces, i.e. the client facing Service= Interface and the NSF facing Capability Interface, the work to be done at = the Capability Interface becomes very clear and concrete. But the Service I= nterface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one= IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises. In addition, the European Telecommunications = Standards Institute (ETSI) Network Function Virtualization (NFV) initiative= creates new management challenges for security policies to be enforced by = distributed, virtual, network security functions (vNSF). Without standard i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF. There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the client security policies, to security functions. = I2NSF will NOT standardize security functions or devices. Instead, I2NSF is= only to standardize the policy provisioning to the security functions (not= devices), in the form of "Subject - Object - Function - Action" paradigm. MZ: Not sure if we need to explicitly specify a potential solution("Subjec= t-Object-Function-Action") in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers' logical= networks, addresses and context. I2NSF Service Layer can also be security = expectation or loose security requirement, especially for customers who don= 't have the security expertise. MZ: I suggest "I2NSF Services Layer provides a set of interfaces for clien= ts to express and monitor security policies. The policies may be intent-bas= ed." The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability= to flow based security function, and - The proper secure communication channels to carry the security p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing protocols and data models defined by I2RS, Netconf, and NETMOD. For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter= . (They are different from other security functions such as Authentication,= Authorization, or Encryption). Exemplar services associated with Flow Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors' specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols used by the WG. - Gap analysis of existing protocols and modeling languages - A single, unified, Information Model for expressing policies to = the Flow Based Security Functions described above. - Corresponding Data Models (e.g. YANG models) derived from the ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG. The framework, that describes the functional components and the I2NSF = work items, is to make I2NSF work more organized.] Suggested Milestones - Use Case Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 months to W= G document - Info model: Charter time + 7 months to WG Document - IANA registry consideration + 10 months to WG Document - All Early Drafts to IESG: 10 months [decision point - +10 months] - Data Models: Charter + 9 Months to WG Document - Applicability Statements: 10 months to WG Document - Data Models and Applicability Statements to IESG - 16 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_A3233753A4B65F43BCA1B64DA99A9C230721826C6FGSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Thanks very much for putting this together. I agre= e that the scope needs to be tightened if it is to be meaningful. I’m= fine with the suggested deliverables, milestones, etc. BUT we should tweak= the first two paragraphs related to the goal of the WG. I2NSF shouldn̵= 7;t take a position on where the security functions are hosted or if the ca= ller and the security service function belong to the same or different doma= ins. Also, not sure if we should bring in another organization’s name= (ETSI) into an IETF charter.

 

I’ve taken a stab at rewording the fir= st few paragraphs…

 

Network security functions (NSFs) are increasingly provided= and consumed in increasingly diverse environments. Users of NSFs could con= sume network security services hosted by one or more providers, which may b= e their own enterprise, service providers, or a combination of both. Likewi= se, service providers may offer their customers network security services t= hat consist of multiple security products from different vendors. Yet becau= se no widely accepted industry standard security interfaces exist today, ma= nagement of NSFs (device and policy provisioning, monitoring, etc.) tends t= o be bespoke, essentially as offered by product vendors. As a result, autom= ation of such services, if it exists at all, is also bespoke.  

 <= /span>

The primary goal of I2NS= F is to define a set of interfaces and data models for policy provisioning = and management aspects of NSFs. Other aspects of NSFs such as device or net= work provisioning are out of scope.

 

The scope of I2NSF can be further divided into two layers:=

· &= nbsp;       I2NSF Cap= abilities Layer

·         I2NSF Services Layer

…

 =

I’ve ma= de a few comments inline below as well.

 

I’m not familiar with how = detailed a charter needs to be, so I’ll leave it others to comment on= whether the level of detail here is sufficient, too much or too light.

&= nbsp;

My= o

<= o:p> 

 

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of= Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: i2nsf@i= etf.org; Kathleen Moriarty
Cc: i2rs@ietf.org; dots@ietf.org; netm= od@ietf.org
Subject: [I2nsf] Further Narrowing the I2NSF scope: t= he new charter for IETF 93

 

Thanks to I2NSF contributors for the good progre= sses made since  IETF92 side meetings. Among the two I2NSF interfaces,=  i.e. the client facing Service Interface and the NSF facing Capabili= ty Interface, the work to be done at the Capability Interface becomes very = clear and concrete. But the Service Interface is still a little vague.

 

The feedback from last= IETF side meetings was "the scope is too big for one IETF WG". T= herefore, we are leaning towards narrowing the I2NSF scope to the Capabilit= y Interface. The thinking logic is: Once the Capability Interface is comple= ted, we will see more clearly the work for Service interface. Even if Capab= ility layer alone is standardized, it is a giant leap forward in building b= locks for Service Provider to automate their Security Controller that can u= tilize NSF by multiple vendors

 

Here is the narrower scoped I2NSF charter. Your comments and su= ggestions are greatly appreciated. CC’ed to DOTS, I2RS, and Netmod gr= oups for wider review.

 

 

 

Enterprises, residential, and mobile customers are increasi= ngly consuming network functions, especially network security related funct= ions that are not running on their premises.  In addition, the Europea= n Telecommunications Standards Institute (ETSI) Network Function Virtualiza= tion (NFV) initiative creates new management challenges for security polici= es to be enforced by distributed, virtual, network security functions (vNSF= ). Without standard interface to express, monitor, and manage security poli= cies to security functions deployed at different premises, it becomes virtu= ally impossible for security service providers to automate the service offe= ring utilizing security functions by multiple vendors.

 

The ultimate goal of I2NSF is to enabl= e enterprises to utilize security functions not hosted on their own premise= s but instead hosted in service provider domain, to establish how to commun= icate desired security policies to NSF and how to get performance data or r= eport out of NSF or vNSF.

 

There are two layers of interfaces:

-       &n= bsp;  Security Policies facing security functi= ons (I2NSF Capability Layer)

-          Security Policies facing clients (I2NSF Service Layer)=

 <= /o:p>

The I2NSF Capability Layer specifies the functional security poli= cies, which are translated from the client security policies, to security f= unctions. I2NSF will NOT standardize security functions or devices. Instead= , I2NSF is only to standardize the policy provisioning to the security func= tions (not devices), in the form of “Subject – Object – F= unction – Action” paradigm. 

MZ:&= nbsp; Not sure if we need to explicitly specify a potential solution(“= ;Subject-Object-Function-Action”) in the charter.

 

The I2NSF Service Layer is for clients to express and monitor security = policies for their specific flows, which is usually based on customers̵= 7; logical networks, addresses and context. I2NSF Service Layer can also be= security expectation or loose security requirement, especially for custome= rs who don’t have the security expertise.

MZ:  = I suggest “I2NSF Services Layer provides a set of interfaces for clie= nts to express and monitor security policies. The policies may be intent-ba= sed.”

 

= The concrete work at the L2NSF Capability Layer includes

-&n= bsp;         <= ![endif]>The informational & data models for each category to be repres= ented to virtual or physical network security functions,

-       = ;   The capability registry (IANA)= of policy provisioning capability to flow based security function, and

-    &n= bsp;     The proper secu= re communication channels to carry the security policies between Controller= and NSFs.

The capability registry is to make it fea= sible to categorize network security functions provided by different vendor= s based on security policy provisioning capability without any need to stan= dardize security functions themselves.  Standard provisioning capabili= ty interface is an essential building block for Security Service Provider t= o automate their Security Controllers that can utilize NSF by multiple vend= ors. This layer will leverage the existing protocols and data models define= d by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service Layer, it is out of the scope for I2NSF = (at least for now) to standardize the interface facing clients. However, I2= NSF can have informational drafts showing sample APIs or/and RESTful interf= aces to clients and demonstrating the feasibility of them being translated = to the Capability Layer policies.

 <= /p>

Since different security= vendors support different features & functions on their devices, I2NSF= will focus on flow based security functions that provide treatment to pack= ets/flows, such as IPS/IDS, Web filter, and flow filter. (They are differen= t from other security functions such as Authentication, Authorization, or E= ncryption). Exemplar services associated with Flow Based Security functions= include deep packet inspection, packet/flow/stream filtering or pattern ma= tching and remediation, etc.

 

Similar to I2RS focusing on the interface to RIB/FIB even though= most routers provide far more functions than RIB/FIB, the I2NSF focused fu= nctions can be a portion of features supported by vendors’ specific d= evices.

=  

It is a non= -goal to create new protocols or data modeling languages for I2NSF interfac= es.

I2NSF WG= Deliverables include:

 

-          <= ![endif]> Use Case document.

<= ![if !supportLists]>-        &nbs= p; Framework Document.

-      &nbs= p;   Requirement for extensions (if there= are any) to existing protocols used by the WG.

-      &n= bsp;    Gap analysis of existing pro= tocols and modeling languages

-          A single, unified, Information Model for expressing p= olicies to the Flow Based Security Functions described above.

-    &= nbsp;     Corresponding Data Mo= dels (e.g. YANG models) derived from the above Information Model.

-   &nb= sp;      IANA registry con= sideration for flow based security function policy provisioning capability.=

-  = ;         (= Optionally) Applicability Statements on how to use I2RS, Netconf, and NETMO= D to carry the content of the specified information/data models.=

 

[Th= e WG may decide that the Use cases, Framework, and Requirement are Informat= ional documents or simply reference documents during the lifetime of the WG= . The framework, that describes the functional components and the I2= NSF work items, is to make I2NSF work more organized.]

 

Sugg= ested Milestones

  - Use Case Document:  Charter time + 1 month to WG Document=

  - Fra= mework: Charter time + 4 months to WG Document

  - Requirements for extensions to p= rotocols:  Charter time + 6 months to WG document

  - Info model: Charter time= + 7 months to WG Document

  - IANA registry consideration + 10 months to WG Docume= nt

  - A= ll Early Drafts to IESG: 10 months

 

[decision point – +10 months] 

  - Data Models: Ch= arter + 9 Months to WG Document

  - Applicability Statements: 10 months to WG Docum= ent

  - = Data Models and Applicability Statements to IESG  - 16 months

 

=

The WG will = work closely with I2RS, Netconf and Netmod WGs. The WG will communicate wit= h external SDOs like ETSI NFV and will encourage open source code developme= nt related to the WG scope in organizations like ONF, OpenStack, ODL, and O= penNFV.

=  

=  

Cheers,

Linda Dunbar

= --_000_A3233753A4B65F43BCA1B64DA99A9C230721826C6FGSCMAMP19EXfi_-- From nobody Mon May 11 01:50:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C831A7D85; Mon, 11 May 2015 01:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmskAbyXcISE; Mon, 11 May 2015 01:50:18 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13641A700E; Mon, 11 May 2015 01:50:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgHAFFsUFWHCzIm/2dsb2JhbABcgkUhKVReBrJpAQEBAQEBBplbAoElTAEBAQEBAYELhCABAQEBAxIbPg4QAgEIDQQEAQELFgEGBzIUCQgCBAENBQgTB4gKAakYnXABAQEBAQEBAQEBAQEBAQEBAQEBAQEXhhaFI4RUMQYBgxeBFgWLMYcMjAeGS4sTg1UjYYEFghFvgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,405,1427774400"; d="scan'208,217";a="119809747" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 May 2015 04:49:21 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 11 May 2015 04:43:52 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 11 May 2015 10:43:51 +0200 From: "Romascanu, Dan (Dan)" To: "Zarny, Myo" , 'Linda Dunbar' , "'i2nsf@ietf.org'" , 'Kathleen Moriarty' Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQinCJ2OCaxrcKG02LhKTLY5q9wZ12diUw Date: Mon, 11 May 2015 08:43:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "'i2rs@ietf.org'" , "'dots@ietf.org'" , "'netmod@ietf.org'" Subject: Re: [netmod] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 08:50:25 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am fine with the editing proposed by Myo as it makes the scope more clear= . Maybe the only thing I would suggest is to use 'non-standard' rather than= 'bespoke' which may puzzle the non-native English speakers. I had to go to= the dictionary to see what it exactly means (but it may be only me!). Mentioning another SDO in the charter is actually fine as long as it points= to the fact that we are aiming to work in cooperation with other SDOs and = avoid duplicating work. In this case we say at the end that we plan to coop= erate with ETSI, so keeping explicit mentioning out of the introduction is = fine. Thanks and Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo Sent: Saturday, May 09, 2015 6:55 PM To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Hi Linda, Thanks very much for putting this together. I agree that the scope needs to= be tightened if it is to be meaningful. I'm fine with the suggested delive= rables, milestones, etc. BUT we should tweak the first two paragraphs relat= ed to the goal of the WG. I2NSF shouldn't take a position on where the secu= rity functions are hosted or if the caller and the security service functio= n belong to the same or different domains. Also, not sure if we should brin= g in another organization's name (ETSI) into an IETF charter. I've taken a stab at rewording the first few paragraphs... Network security functions (NSFs) are increasingly provided and consumed in= increasingly diverse environments. Users of NSFs could consume network sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. Likewise, service prov= iders may offer their customers network security services that consist of m= ultiple security products from different vendors. Yet because no widely acc= epted industry standard security interfaces exist today, management of NSFs= (device and policy provisioning, monitoring, etc.) tends to be bespoke, es= sentially as offered by product vendors. As a result, automation of such se= rvices, if it exists at all, is also bespoke. The primary goal of I2NSF is to define a set of interfaces and data models = for policy provisioning and management aspects of NSFs. Other aspects of NS= Fs such as device or network provisioning are out of scope. The scope of I2NSF can be further divided into two layers: * I2NSF Capabilities Layer * I2NSF Services Layer ... I've made a few comments inline below as well. I'm not familiar with how detailed a charter needs to be, so I'll leave it = others to comment on whether the level of detail here is sufficient, too mu= ch or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e meetings. Among the two I2NSF interfaces, i.e. the client facing Service= Interface and the NSF facing Capability Interface, the work to be done at = the Capability Interface becomes very clear and concrete. But the Service I= nterface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one= IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises. In addition, the European Telecommunications = Standards Institute (ETSI) Network Function Virtualization (NFV) initiative= creates new management challenges for security policies to be enforced by = distributed, virtual, network security functions (vNSF). Without standard i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF. There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the client security policies, to security functions. = I2NSF will NOT standardize security functions or devices. Instead, I2NSF is= only to standardize the policy provisioning to the security functions (not= devices), in the form of "Subject - Object - Function - Action" paradigm. MZ: Not sure if we need to explicitly specify a potential solution("Subjec= t-Object-Function-Action") in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers' logical= networks, addresses and context. I2NSF Service Layer can also be security = expectation or loose security requirement, especially for customers who don= 't have the security expertise. MZ: I suggest "I2NSF Services Layer provides a set of interfaces for clien= ts to express and monitor security policies. The policies may be intent-bas= ed." The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability= to flow based security function, and - The proper secure communication channels to carry the security p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing protocols and data models defined by I2RS, Netconf, and NETMOD. For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter= . (They are different from other security functions such as Authentication,= Authorization, or Encryption). Exemplar services associated with Flow Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors' specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols used by the WG. - Gap analysis of existing protocols and modeling languages - A single, unified, Information Model for expressing policies to = the Flow Based Security Functions described above. - Corresponding Data Models (e.g. YANG models) derived from the ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG. The framework, that describes the functional components and the I2NSF = work items, is to make I2NSF work more organized.] Suggested Milestones - Use Case Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 months to W= G document - Info model: Charter time + 7 months to WG Document - IANA registry consideration + 10 months to WG Document - All Early Drafts to IESG: 10 months [decision point - +10 months] - Data Models: Charter + 9 Months to WG Document - Applicability Statements: 10 months to WG Document - Data Models and Applicability Statements to IESG - 16 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am fine with the edi= ting proposed by Myo as it makes the scope more clear. Maybe the only thing= I would suggest is to use ‘non-standard’ rather than ‘be= spoke’ which may puzzle the non-native English speakers. I had to go to the dictionary to see what it exactly means (but it may be = only me!).

 

Mentioning another SDO= in the charter is actually fine as long as it points to the fact that we a= re aiming to work in cooperation with other SDOs and avoid duplicating work= . In this case we say at the end that we plan to cooperate with ETSI, so keeping explicit mentioning out of the = introduction is fine.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo
Sent: Saturday, May 09, 2015 6:55 PM
To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty'
Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

Hi Linda,

 

Thanks very much for p= utting this together. I agree that the scope needs to be tightened if it is= to be meaningful. I’m fine with the suggested deliverables, mileston= es, etc. BUT we should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn’t take a pos= ition on where the security functions are hosted or if the caller and the s= ecurity service function belong to the same or different domains. Also, not= sure if we should bring in another organization’s name (ETSI) into an IETF charter.

 

I’ve taken a sta= b at rewording the first few paragraphs…

 

Network security functions (NS= Fs) are increasingly provided and consumed in increasingly diverse environm= ents. Users of NSFs could consume network security services hosted by one or more providers, which may be their own = enterprise, service providers, or a combination of both. Likewise, service = providers may offer their customers network security services that consist = of multiple security products from different vendors. Yet because no widely accepted industry standard securi= ty interfaces exist today, management of NSFs (device and policy provisioni= ng, monitoring, etc.) tends to be bespoke, essentially as offered by produc= t vendors. As a result, automation of such services, if it exists at all, is also bespoke.  <= /span>

 

The primary goal of I2NSF is t= o define a set of interfaces and data models for policy provisioning and ma= nagement aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope.

 

The scope of I2NSF can be furt= her divided into two layers:

·       &= nbsp; I2NSF Capabilities Layer

·       &= nbsp; I2NSF Services Layer<= /o:p>

…

 

I’ve made a few = comments inline below as well.

 

I’m not familiar= with how detailed a charter needs to be, so I’ll leave it others to = comment on whether the level of detail here is sufficient, too much or too = light.

 

Myo<= /p>

 

 

From: I2nsf [mailt= o:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: i2nsf@ietf.org; Kathleen M= oriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter = for IETF 93

 

Thanks to I2NSF contrib= utors for the good progresses made since  IETF92 side meetings. Among = the two I2NSF interfaces,  i.e. the client facing Service Interface an= d the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. Bu= t the Service Interface is still a little vague.

 

The feedback from last = IETF side meetings was "the scope is too big for one IETF WG". Th= erefore, we are leaning towards narrowing the I2NSF scope to the Capability= Interface. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service inte= rface. Even if Capability layer alone is standardized, it is a giant leap f= orward in building blocks for Service Provider to automate their Security C= ontroller that can utilize NSF by multiple vendors

 

Here is the narrower sc= oped I2NSF charter. Your comments and suggestions are greatly appreciated. = CC’ed to DOTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residentia= l, and mobile customers are increasingly consuming network functions, espec= ially network security related functions that are not running on their prem= ises.  In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiativ= e creates new management challenges for security policies to be enforced by= distributed, virtual, network security functions (vNSF). Without standard = interface to express, monitor, and manage security policies to security functions deployed at different premi= ses, it becomes virtually impossible for security service providers to auto= mate the service offering utilizing security functions by multiple vendors.

 

The ultimate goal of I2= NSF is to enable enterprises to utilize security functions not hosted on th= eir own premises but instead hosted in service provider domain, to establis= h how to communicate desired security policies to NSF and how to get performance data or report out of NSF or vN= SF.

 

There are two layers of= interfaces:

-       = ;   Security Policies facing s= ecurity functions (I2NSF Capability Layer)

-       = ;   Security Policies facing c= lients (I2NSF Service Layer)

 

The I2NSF Capability Layer specifies the functional security policies,= which are translated from the client security policies, to security functi= ons. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy pro= visioning to the security functions (not devices), in the form of “Su= bject – Object – Function – Action” paradigm. 

MZ:  Not sure if we need to explicitly specify a potential solu= tion(“Subject-Object-Function-Action”) in the charter.

 

The I2NSF Service Layer= is for clients to express and monitor security policies for their specific= flows, which is usually based on customers’ logical networks, addres= ses and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for cust= omers who don’t have the security expertise.

MZ:  I suggest “I2NSF Services Layer provides a set of in= terfaces for clients to express and monitor security policies. The policies= may be intent-based.”

 

The concrete work at th= e L2NSF Capability Layer includes

-  &= nbsp;       The informational &= amp; data models for each category to be represented to virtual or physical= network security functions,<= /p>

-  &= nbsp;       The capability regi= stry (IANA) of policy provisioning capability to flow based security functi= on, and

-  &= nbsp;       The proper secure c= ommunication channels to carry the security policies between Controller and= NSFs.

The capability registry= is to make it feasible to categorize network security functions provided b= y different vendors based on security policy provisioning capability withou= t any need to standardize security functions themselves.  Standard provisioning capability interface is an essenti= al building block for Security Service Provider to automate their Security = Controllers that can utilize NSF by multiple vendors. This layer will lever= age the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service L= ayer, it is out of the scope for I2NSF (at least for now) to standardize th= e interface facing clients. However, I2NSF can have informational drafts sh= owing sample APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to t= he Capability Layer policies.

 

Since different securit= y vendors support different features & functions on their devices, I2NS= F will focus on flow based security functions that provide treatment to pac= kets/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as= Authentication, Authorization, or Encryption). Exemplar services associate= d with Flow Based Security functions include deep packet inspection, packet= /flow/stream filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusin= g on the interface to RIB/FIB even though most routers provide far more fun= ctions than RIB/FIB, the I2NSF focused functions can be a portion of featur= es supported by vendors’ specific devices.

 

It is a non-goal to cre= ate new protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables i= nclude:

 

-       = ;    Use Case document. <= o:p>

-       = ;   Framework Document.

-       = ;   Requirement for extensions= (if there are any) to existing protocols used by the WG.

-       = ;    Gap analysis of exis= ting protocols and modeling languages

-       = ;   A single, unified, Informa= tion Model for expressing policies to the Flow Based Security Functions des= cribed above.

-       = ;   Corresponding Data Models = (e.g. YANG models) derived from the above Information Model.

-       = ;   IANA registry consideratio= n for flow based security function policy provisioning capability.

-       = ;    (Optionally) Applica= bility Statements on how to use I2RS, Netconf, and NETMOD to carry the cont= ent of the specified information/data models.

 

[The WG may decide that the Use cases, Framework, an= d Requirement are Informational documents or simply reference documents during the lifetime of the WG. The framework, that descri= bes the functional components and the I2NSF work items, is to make I2NSF wo= rk more organized.]

 

Suggested Milestones

  - Use Case Docum= ent:  Charter time + 1 month to WG Document

  - Framework: Cha= rter time + 4 months to WG Document

  - Requirements f= or extensions to protocols:  Charter time + 6 months to WG documen= t

  - Info model: Ch= arter time + 7 months to WG Document

  - IANA registry = consideration + 10 months to WG Document

  - All Early Draf= ts to IESG: 10 months

 

[decision point –= +10 months] 

  - Data Mode= ls: Charter + 9 Months to WG Document

  - Applicability = Statements: 10 months to WG Document

  - Data Models an= d Applicability Statements to IESG  - 16 months

 

The WG will work closel= y with I2RS, Netconf and Netmod WGs. The WG will communicate with external = SDOs like ETSI NFV and will encourage open source code development related = to the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 

 

Cheers,

Linda Dunbar=

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_-- From nobody Mon May 11 12:19:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A221AD0D7 for ; Mon, 11 May 2015 12:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8pC9wFYVrFC for ; Mon, 11 May 2015 12:19:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751AD1AD0D3 for ; Mon, 11 May 2015 12:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=868; q=dns/txt; s=iport; t=1431371946; x=1432581546; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=XoKf06sxP8eOmV8vYtQcuHS+aRU48p5ZU5geFWNEeG4=; b=c0pXPwwAsHn2L6hCMgegpxKnStIRr2QjOR6Hu+d8/NiTlSDUyQTYyFqs hgnPun3cjdeSWC9/bSmU1De8jjOOcm9tXZhs8HT7qLUvzeFLU9elXN9Xa 88eS5dVPjsU6cXkeiwGTsEqBwYP8NBKef7ZuDiHsTehQP/68IZt4bToas c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ALBQBYAFFV/4MNJK1cgw+BOIMYyUAegRxMAQEBAQEBgQuEIwQjEUUSASICJgIEMBUSBA6IMbUbkzYBAQEBAQEEAQEBAQEdgSGPHYJvgUUFj3eCRopjiF+NeCODd4I0gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,409,1427760000"; d="scan'208";a="10974046" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP; 11 May 2015 19:18:49 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4BJImta019854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 May 2015 19:18:48 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.23]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 11 May 2015 14:18:47 -0500 From: "Acee Lindem (acee)" To: "netmod@ietf.org" Thread-Topic: "enabled" functionality in draft-ietf-netmod-routing-cfg-18 Thread-Index: AQHQjB9OmkemmFig3UKnfITbWGsTfQ== Date: Mon, 11 May 2015 19:18:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.202] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "HANKINS, Greg \(Greg\)" , Jeffrey Zhang , Helen Chen Subject: [netmod] "enabled" functionality in draft-ietf-netmod-routing-cfg-18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 19:19:05 -0000 Rm9yIGJvdGggdGhlIHJvdXRpbmctaW5zdGFuY2UgYW5kIHJvdXRpbmctcHJvdG9jb2wsIHRoZXJl IGlzIGV4cGxpY2l0DQpzdXBwb3J0LCB2aWEgdGhlIOKAnGVuYWJsZWTigJ0gbGVhZiwgZm9yIHJl dGFpbmluZyB0aGUgcmVzcGVjdGl2ZSBpbmZvcm1hdGlvbg0KaW4gdGhlIGNvbmZpZ3VyYXRpb24g YnV0IHJlbW92aW5nIGl0IGZyb20gdGhlIG9wZXJhdGlvbmFsIHN0YXRlLiBUaGlzIG5ldw0KZnVu Y3Rpb25hbGl0eSB3b3VsZCBiZSBiZXR0ZXIgcHJvdmlkZWQgd2l0aCBnZW5lcmljIGluZnJhLXN0 cnVjdHVyZSB0bw0KaW5jbHVkZSBvciBvbWl0IGNvbmZpZ3VyYXRpb24gcmF0aGVyIHRoYW4gYSBt YW5kYXRvcnkgbGVhZiBpbiBpbnRyb2R1Y2VkDQppbiB0aGVzZSBtb2RlbHMuIFRob3NlIHdvcmtp bmcgb24gdGhlIElHUCBtb2RlbHMgKE9TUEYgYW5kIElTLUlTKSByZWFjaGVkDQpjb25zZW5zdXMg dGhhdCDigJxlbmFibGVkIiBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBpZXRmLXJvdXRpbmcg bW9kZWwgYW5kDQp0aGUgSUdQcyB3aWxsIG1vZGVsIHRoZSBleGlzdGluZyBwcm90b2NvbCBhZG1p bmlzdHJhdGl2ZSBjb250cm9scy4gQW55DQpvYmplY3Rpb25zPyANCg0KVGhhbmtzLA0KQWNlZSAN Cg0KDQo= From nobody Tue May 12 04:14:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085801A6F1D; Mon, 11 May 2015 04:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ufLWI5dKZQK; Mon, 11 May 2015 04:20:43 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34EAC1A3B9B; Mon, 11 May 2015 04:20:41 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C25033A01A8; Mon, 11 May 2015 13:20:38 +0200 (CEST) Received: from ESTGVMSP108.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 945B43A02E0; Mon, 11 May 2015 13:20:38 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.52) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 May 2015 13:20:38 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) with Microsoft SMTP Server (TLS) id 15.1.160.19; Mon, 11 May 2015 11:19:36 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0160.009; Mon, 11 May 2015 11:19:36 +0000 From: DIEGO LOPEZ GARCIA To: "Romascanu, Dan (Dan)" Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QBji2ZgAFaiOYAABXA3AA== Date: Mon, 11 May 2015 11:19:35 +0000 Message-ID: <5E241E34-B620-4A92-A545-BA6A7C3E6870@telefonica.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: avaya.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [79.150.196.178] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0624; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0624; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0624; x-forefront-prvs: 05739BA1B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(252514010)(24454002)(77156002)(19617315012)(82746002)(33656002)(76176999)(5001960100002)(16236675004)(50986999)(54356999)(62966003)(189998001)(92566002)(110136002)(2900100001)(2950100001)(40100003)(122556002)(36756003)(87936001)(83716003)(2656002)(15975445007)(66066001)(86362001)(102836002)(19580395003)(19580405001)(46102003)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0624; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2015 11:19:35.4160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0624 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: X-Mailman-Approved-At: Tue, 12 May 2015 04:14:18 -0700 Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "i2nsf@ietf.org" , "dots@ietf.org" , "Zarny, Myo" , Kathleen Moriarty Subject: Re: [netmod] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 11:20:50 -0000 --_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Agree with Dan (and therefore Myo) in the suggested changes and in the fact= that mentioning ETSI out of the introduction is fine. And just a minor nit: I'd refrain to mention DPI as an exemplar function (t= he days of DPI as we know it days are close to be over, given the current c= oncerns about privacy and the usage of E2E encryption) and rephrase the sen= tence mentioning it from "Exemplar services associated with Flow Based Security functions include de= ep packet inspection, packet/flow/stream filtering or pattern matching and = remediation, etc." into "Exemplar services associated with Flow Based Security functions include ma= lware detection, packet/flow/stream filtering or pattern matching and remed= iation, etc." Be goode, On 11 May 2015, at 10:43 , Romascanu, Dan (Dan) > wrote: I am fine with the editing proposed by Myo as it makes the scope more clear= . Maybe the only thing I would suggest is to use =91non-standard=92 rather = than =91bespoke=92 which may puzzle the non-native English speakers. I had = to go to the dictionary to see what it exactly means (but it may be only me= !). Mentioning another SDO in the charter is actually fine as long as it points= to the fact that we are aiming to work in cooperation with other SDOs and = avoid duplicating work. In this case we say at the end that we plan to coop= erate with ETSI, so keeping explicit mentioning out of the introduction is = fine. Thanks and Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo Sent: Saturday, May 09, 2015 6:55 PM To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Mori= arty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Hi Linda, Thanks very much for putting this together. I agree that the scope needs to= be tightened if it is to be meaningful. I=92m fine with the suggested deli= verables, milestones, etc. BUT we should tweak the first two paragraphs rel= ated to the goal of the WG. I2NSF shouldn=92t take a position on where the = security functions are hosted or if the caller and the security service fun= ction belong to the same or different domains. Also, not sure if we should = bring in another organization=92s name (ETSI) into an IETF charter. I=92ve taken a stab at rewording the first few paragraphs=85 Network security functions (NSFs) are increasingly provided and consumed in= increasingly diverse environments. Users of NSFs could consume network sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. Likewise, service prov= iders may offer their customers network security services that consist of m= ultiple security products from different vendors. Yet because no widely acc= epted industry standard security interfaces exist today, management of NSFs= (device and policy provisioning, monitoring, etc.) tends to be bespoke, es= sentially as offered by product vendors. As a result, automation of such se= rvices, if it exists at all, is also bespoke. The primary goal of I2NSF is to define a set of interfaces and data models = for policy provisioning and management aspects of NSFs. Other aspects of NS= Fs such as device or network provisioning are out of scope. The scope of I2NSF can be further divided into two layers: =95 I2NSF Capabilities Layer =95 I2NSF Services Layer =85 I=92ve made a few comments inline below as well. I=92m not familiar with how detailed a charter needs to be, so I=92ll leave= it others to comment on whether the level of detail here is sufficient, to= o much or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e meetings. Among the two I2NSF interfaces, i.e. the client facing Service= Interface and the NSF facing Capability Interface, the work to be done at = the Capability Interface becomes very clear and concrete. But the Service I= nterface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one= IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider r= eview. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises. In addition, the European Telecommunications = Standards Institute (ETSI) Network Function Virtualization (NFV) initiative= creates new management challenges for security policies to be enforced by = distributed, virtual, network security functions (vNSF). Without standard i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF. There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the client security policies, to security functions. = I2NSF will NOT standardize security functions or devices. Instead, I2NSF is= only to standardize the policy provisioning to the security functions (not= devices), in the form of =93Subject =96 Object =96 Function =96 Action=94 = paradigm. MZ: Not sure if we need to explicitly specify a potential solution(=93Subj= ect-Object-Function-Action=94) in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers=92 logic= al networks, addresses and context. I2NSF Service Layer can also be securit= y expectation or loose security requirement, especially for customers who d= on=92t have the security expertise. MZ: I suggest =93I2NSF Services Layer provides a set of interfaces for cli= ents to express and monitor security policies. The policies may be intent-b= ased.=94 The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability= to flow based security function, and - The proper secure communication channels to carry the security p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing protocols and data models defined by I2RS, Netconf, and NETMOD. For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter= . (They are different from other security functions such as Authentication,= Authorization, or Encryption). Exemplar services associated with Flow Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors=92 specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols used by the WG. - Gap analysis of existing protocols and modeling languages - A single, unified, Information Model for expressing policies to = the Flow Based Security Functions described above. - Corresponding Data Models (e.g. YANG models) derived from the ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG. The framework, that describes the functional components and the I2NSF = work items, is to make I2NSF work more organized.] Suggested Milestones - Use Case Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 months to W= G document - Info model: Charter time + 7 months to WG Document - IANA registry consideration + 10 months to WG Document - All Early Drafts to IESG: 10 months [decision point =96 +10 months] - Data Models: Charter + 9 Months to WG Document - Applicability Statements: 10 months to WG Document - Data Models and Applicability Statements to IESG - 16 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi,

Agree with Dan (and therefore Myo) in the suggested changes and in the= fact that mentioning ETSI out of the introduction is fine.

And just a minor nit: I'd refrain to mention DPI as an exemplar functi= on (the days of DPI as we know it days are close to be over, given the curr= ent concerns about privacy and the usage of E2E encryption) and rephrase th= e sentence mentioning it from 
"Exemplar services associated with Flow Based Security functions = include deep packet inspection, packet/flow/stream filtering or pattern mat= ching and remediation, etc." 
into 
"Exemplar services associated with Flow Based Security functions = include malware detection, packet/flow/stream filtering or pattern matching= and remediation, etc."

Be goode,

On 11 May 2015, at 10:43 , Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

I am fine with the editing propose= d by Myo as it makes the scope more clear. Maybe the only thing I would sug= gest is to use =91non-standard=92 rather than =91bespoke=92 which may puzzl= e the non-native English speakers. I had to go to the dictionary to see what it exactly means (but it may be only me!)= .
 
Mentioning another SDO in the char= ter is actually fine as long as it points to the fact that we are aiming to= work in cooperation with other SDOs and avoid duplicating work. In this ca= se we say at the end that we plan to cooperate with ETSI, so keeping explicit mentioning out of the introduc= tion is fine.
 
Thanks and Regards,
 
Dan
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo=
Sent: Saturday, Ma= y 09, 2015 6:55 PM
To: 'Linda Dunbar'= ; 'i2nsf@ietf.org'; 'Kathleen Moriart= y'
Cc: 'i2rs@ietf.org'; 'd= ots@ietf.org'; 'netmod@ietf.org'=
Subject: Re: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
 
Hi Linda,
 
Thanks very much for putting this = together. I agree that the scope needs to be tightened if it is to be meani= ngful. I=92m fine with the suggested deliverables, milestones, etc. BUT we = should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn=92t take a position on where = the security functions are hosted or if the caller and the security service= function belong to the same or different domains. Also, not sure if we sho= uld bring in another organization=92s name (ETSI) into an IETF charter.
 
I=92ve taken a stab at rewording t= he first few paragraphs=85
 
Network security functions (NSFs) are increasingly provided and consu= med in increasingly diverse environments. Users of NSFs could consume netwo= rk security services hosted by one or more providers, which may be their own enterprise, service providers, o= r a combination of both. Likewise, service providers may offer their custom= ers network security services that consist of multiple security products fr= om different vendors. Yet because no widely accepted industry standard security interfaces exist today, mana= gement of NSFs (device and policy provisioning, monitoring, etc.) tends to = be bespoke, essentially as offered by product vendors. As a result, automat= ion of such services, if it exists at all, is also bespoke.  
 
The primary goal of I2NSF is to define a set of interfaces and data m= odels for policy provisioning and management aspects of NSFs. Other aspects= of NSFs such as device or network provisioning are out of scope.
 
The scope of I2NSF can be further divided into two layers:=
=B7         <= /span>I2NSF Capabilities Layer
=B7         <= /span>I2NSF Services Layer
=85
 
I=92ve made a few comments inline = below as well.
 
I=92m not familiar with how detail= ed a charter needs to be, so I=92ll leave it others to comment on whether t= he level of detail here is sufficient, too much or too light.
 
Myo
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunb= ar
Sent: 7 May 2015 1= 1:53 AM
To: i2= nsf@ietf.org; Kathleen Moriarty
Cc: i2r= s@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93
 
Thanks to I2NSF contributors for the good progresses made since  IETF9= 2 side meetings. Among the two I2NSF interfaces,  i.e. the client faci= ng Service Interface and the NSF facing Capability Interface, the work to b= e done at the Capability Interface becomes very clear and concrete. But the Service Interface is still a little vague= .
 
The feedback from last IETF side meetings was "the scope is too big fo= r one IETF WG". Therefore, we are leaning towards narrowing the I2NSF = scope to the Capability Interface. The thinking logic is: Once the Capabili= ty Interface is completed, we will see more clearly the work for Service interface. Even if Capability layer alone is = standardized, it is a giant leap forward in building blocks for Service Pro= vider to automate their Security Controller that can utilize NSF by multipl= e vendors
 
Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider r= eview.
 
 
 
Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises.  In addition, the European Telecommunicat= ions Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new management challenges= for security policies to be enforced by distributed, virtual, network secu= rity functions (vNSF). Without standard interface to express, monitor, and = manage security policies to security functions deployed at different premises, it becomes virtually impossible = for security service providers to automate the service offering utilizing s= ecurity functions by multiple vendors.
 
The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF.
 
There are two layers of interfaces:
-          S= ecurity Policies facing security functions (I2NSF Capability Layer)
-          S= ecurity Policies facing clients (I2NSF Service Layer)
 
The I2NSF Capability Layer specifies the functional securi= ty policies, which are translated from the client security policies, to sec= urity functions. I2NSF will NOT standardize security functions or devices. = Instead, I2NSF is only to standardize the policy provisioning to the security functions (not devices), in the fo= rm of =93Subject =96 Object =96 Function =96 Action=94 paradigm. =
MZ:  Not sure if we need to exp= licitly specify a potential solution(=93Subject-Object-Function-Action=94) = in the charter.
 
The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers=92 logic= al networks, addresses and context. I2NSF Service Layer can also be securit= y expectation or loose security requirement, especially for customers who don=92t have the security expertise.
MZ:  I suggest =93I2NSF Service= s Layer provides a set of interfaces for clients to express and monitor sec= urity policies. The policies may be intent-based.=94
 
The concrete work at the L2NSF Capability Layer includes
-         = ; The informational & data models for each category to be represented to vir= tual or physical network security functions,
-         = ; The capability registry (IANA) of policy provisioning capability to flow based= security function, and
-         = ; The proper secure communication channels to carry the security policies betwee= n Controller and NSFs.
The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves.  Standard provisioning capability interface is an essential building block for Security Service Provider to = automate their Security Controllers that can utilize NSF by multiple vendor= s. This layer will leverage the existing protocols and data models defined = by I2RS, Netconf, and NETMOD.
 
For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capability Layer policies.
 
Since different security vendors support different features & functions= on their devices, I2NSF will focus on flow based security functions that p= rovide treatment to packets/flows, such as IPS/IDS, Web filter, and flow fi= lter. (They are different from other security functions such as Authentication, Authorization, or Encryption). = Exemplar services associated with Flow Based Security functions include dee= p packet inspection, packet/flow/stream filtering or pattern matching and r= emediation, etc.
 
Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors=92 specific devices.
 
It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces.
I2NSF WG Deliverables include:
 
-          &= nbsp;Use Case document.
-          F= ramework Document.
-          R= equirement for extensions (if there are any) to existing protocols used by the WG.
-          &= nbsp;Gap analysis of existing protocols and modeling languages
-          A= single, unified, Information Model for expressing policies to the Flow Based Security Funct= ions described above.
-          C= orresponding Data Models (e.g. YANG models) derived from the above Information Model.
-          I= ANA registry consideration for flow based security function policy provisioning capabil= ity.
-          &= nbsp;(Optionally) Applicability Statements on how to use I2RS, Netconf, and NETMOD to carry = the content of the specified information/data models.
 
[The WG may decide that the Use cases, Framework, and Requirement are = Informational documents or simply reference documents during the lifetime o= f the WG. The framework, that describes the functional components and the I2NSF work ite= ms, is to make I2NSF work more organized.]
 
Suggested Milestones
  - Use Case Document:  Charter time + 1 month to WG Document=
  - Framework: Charter time + 4 months to WG Document
  - Requirements for extensions to protocols:  Charter time += 6 months to WG document
  - Info model: Charter time + 7 months to WG Document<= /div>
  - IANA registry consideration + 10 months to WG Document
  - All Early Drafts to IESG: 10 months
 
[decision point =96 +10 months] 
  - Data Models: Charter + 9 Months to WG Document=
  - Applicability Statements: 10 months to WG Document
  - Data Models and Applicability Statements to IESG  - 16 months=
 
The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV.
 
 
Cheers,
Linda Dunbar
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lo= pez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_-- From nobody Tue May 12 04:14:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220931A87A9; Tue, 12 May 2015 04:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvjLhoyo54tB; Tue, 12 May 2015 04:07:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87031A8779; Tue, 12 May 2015 04:07:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSK47304; Tue, 12 May 2015 11:07:21 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 May 2015 12:07:19 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Tue, 12 May 2015 19:07:10 +0800 From: "Xialiang (Frank)" To: Linda Dunbar , "i2nsf@ietf.org" , Kathleen Moriarty Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QDwXbrg Date: Tue, 12 May 2015 11:07:10 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Tue, 12 May 2015 04:14:18 -0700 Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: [netmod] =?gb2312?b?tPC4tDogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2luZyB0?= =?gb2312?b?aGUgSTJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURgk5Mw==?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 11:07:28 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTGluZGEsDQpJIGFncmVlIHRoYXQgd2UgY2FuIHNwZWNpZnkgY2FwYWJpbGl0eSBpbnRlcmZh Y2UgZmlyc3RseSwgYW5kIGxlYXZlIHRoZSBjdXJyZW50bHkgdmFndWUgc2VydmljZSBpbnRlcmZh Y2Ugb3V0IG9mIHNjb3BlIG5vdy4gQnV0IHN0aWxsLCBhcyBhbiBlc3NlbnRpYWwgcGFydCBvZiB0 aGUgd2hvbGUgc29sdXRpb24sIHRoZSBzZXJ2aWNlIGludGVyZmFjZSBpcyBhbHNvIHZlcnkgaW1w b3J0YW50IGZvciB2YXJpb3VzIGNsaWVudHMgdG8gZXhwcmVzcyB0aGVpciBjdXN0b20gc2VjdXJp dHkgcmVxdWlyZW1lbnQgZmxleGlibHkuIFNvLCBJIHN1Z2dlc3Qgd2UgY2FuIHNldCB0aGUgc3Bl Y2lmaWNhdGlvbiBvZiBzZXJ2aWNlIGludGVyZmFjZSBhcyB0aGUgc2Vjb25kIHBoYXNlIG9mIEky TlNGIHdvcmsuDQoNCk90aGVyIGNvbW1lbnRzIGFyZSBpbmxpbmU6DQoNCkIuUi4NCkZyYW5rDQoN CreivP7IyzogSTJuc2YgW21haWx0bzppMm5zZi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExpbmRh IER1bmJhcg0Kt6LLzcqxvOQ6IDIwMTXE6jXUwjfI1SAyMzo1Mw0KytW8/sjLOiBpMm5zZkBpZXRm Lm9yZzsgS2F0aGxlZW4gTW9yaWFydHkNCrOty806IGkycnNAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5v cmc7IG5ldG1vZEBpZXRmLm9yZw0K1vfM4jogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2luZyB0aGUg STJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5Mw0KDQpUaGFua3MgdG8gSTJO U0YgY29udHJpYnV0b3JzIGZvciB0aGUgZ29vZCBwcm9ncmVzc2VzIG1hZGUgc2luY2UgIElFVEY5 MiBzaWRlIG1lZXRpbmdzLiBBbW9uZyB0aGUgdHdvIEkyTlNGIGludGVyZmFjZXMsICBpLmUuIHRo ZSBjbGllbnQgZmFjaW5nIFNlcnZpY2UgSW50ZXJmYWNlIGFuZCB0aGUgTlNGIGZhY2luZyBDYXBh YmlsaXR5IEludGVyZmFjZSwgdGhlIHdvcmsgdG8gYmUgZG9uZSBhdCB0aGUgQ2FwYWJpbGl0eSBJ bnRlcmZhY2UgYmVjb21lcyB2ZXJ5IGNsZWFyIGFuZCBjb25jcmV0ZS4gQnV0IHRoZSBTZXJ2aWNl IEludGVyZmFjZSBpcyBzdGlsbCBhIGxpdHRsZSB2YWd1ZS4NCg0KVGhlIGZlZWRiYWNrIGZyb20g bGFzdCBJRVRGIHNpZGUgbWVldGluZ3Mgd2FzICJ0aGUgc2NvcGUgaXMgdG9vIGJpZyBmb3Igb25l IElFVEYgV0ciLiBUaGVyZWZvcmUsIHdlIGFyZSBsZWFuaW5nIHRvd2FyZHMgbmFycm93aW5nIHRo ZSBJMk5TRiBzY29wZSB0byB0aGUgQ2FwYWJpbGl0eSBJbnRlcmZhY2UuIFRoZSB0aGlua2luZyBs b2dpYyBpczogT25jZSB0aGUgQ2FwYWJpbGl0eSBJbnRlcmZhY2UgaXMgY29tcGxldGVkLCB3ZSB3 aWxsIHNlZSBtb3JlIGNsZWFybHkgdGhlIHdvcmsgZm9yIFNlcnZpY2UgaW50ZXJmYWNlLiBFdmVu IGlmIENhcGFiaWxpdHkgbGF5ZXIgYWxvbmUgaXMgc3RhbmRhcmRpemVkLCBpdCBpcyBhIGdpYW50 IGxlYXAgZm9yd2FyZCBpbiBidWlsZGluZyBibG9ja3MgZm9yIFNlcnZpY2UgUHJvdmlkZXIgdG8g YXV0b21hdGUgdGhlaXIgU2VjdXJpdHkgQ29udHJvbGxlciB0aGF0IGNhbiB1dGlsaXplIE5TRiBi eSBtdWx0aXBsZSB2ZW5kb3JzDQoNCkhlcmUgaXMgdGhlIG5hcnJvd2VyIHNjb3BlZCBJMk5TRiBj aGFydGVyLiBZb3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgZ3JlYXRseSBhcHByZWNp YXRlZC4gQ0Ohr2VkIHRvIERPVFMsIEkyUlMsIGFuZCBOZXRtb2QgZ3JvdXBzIGZvciB3aWRlciBy ZXZpZXcuDQoNCg0KDQpFbnRlcnByaXNlcywgcmVzaWRlbnRpYWwsIGFuZCBtb2JpbGUgY3VzdG9t ZXJzIGFyZSBpbmNyZWFzaW5nbHkgY29uc3VtaW5nIG5ldHdvcmsgZnVuY3Rpb25zLCBlc3BlY2lh bGx5IG5ldHdvcmsgc2VjdXJpdHkgcmVsYXRlZCBmdW5jdGlvbnMgdGhhdCBhcmUgbm90IHJ1bm5p bmcgb24gdGhlaXIgcHJlbWlzZXMuICBJbiBhZGRpdGlvbiwgdGhlIEV1cm9wZWFuIFRlbGVjb21t dW5pY2F0aW9ucyBTdGFuZGFyZHMgSW5zdGl0dXRlIChFVFNJKSBOZXR3b3JrIEZ1bmN0aW9uIFZp cnR1YWxpemF0aW9uIChORlYpIGluaXRpYXRpdmUgY3JlYXRlcyBuZXcgbWFuYWdlbWVudCBjaGFs bGVuZ2VzIGZvciBzZWN1cml0eSBwb2xpY2llcyB0byBiZSBlbmZvcmNlZCBieSBkaXN0cmlidXRl ZCwgdmlydHVhbCwgbmV0d29yayBzZWN1cml0eSBmdW5jdGlvbnMgKHZOU0YpLiBXaXRob3V0IHN0 YW5kYXJkIGludGVyZmFjZSB0byBleHByZXNzLCBtb25pdG9yLCBhbmQgbWFuYWdlIHNlY3VyaXR5 IHBvbGljaWVzIHRvIHNlY3VyaXR5IGZ1bmN0aW9ucyBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcHJl bWlzZXMsIGl0IGJlY29tZXMgdmlydHVhbGx5IGltcG9zc2libGUgZm9yIHNlY3VyaXR5IHNlcnZp Y2UgcHJvdmlkZXJzIHRvIGF1dG9tYXRlIHRoZSBzZXJ2aWNlIG9mZmVyaW5nIHV0aWxpemluZyBz ZWN1cml0eSBmdW5jdGlvbnMgYnkgbXVsdGlwbGUgdmVuZG9ycy4NCg0KVGhlIHVsdGltYXRlIGdv YWwgb2YgSTJOU0YgaXMgdG8gZW5hYmxlIGVudGVycHJpc2VzIHRvIHV0aWxpemUgc2VjdXJpdHkg ZnVuY3Rpb25zIG5vdCBob3N0ZWQgb24gdGhlaXIgb3duIHByZW1pc2VzIGJ1dCBpbnN0ZWFkIGhv c3RlZCBpbiBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbiwgdG8gZXN0YWJsaXNoIGhvdyB0byBjb21t dW5pY2F0ZSBkZXNpcmVkIHNlY3VyaXR5IHBvbGljaWVzIHRvIE5TRiBhbmQgaG93IHRvIGdldCBw ZXJmb3JtYW5jZSBkYXRhIG9yIHJlcG9ydCBvdXQgb2YgTlNGIG9yIHZOU0YuDQpbRnJhbmtdOiB0 aGUgSTJOU0YgY2xpZW50cyBkbyBub3Qgb25seSBpbmNsdWRlIGVudGVycHJpc2UuIFNvLCBjaGFu Z2UgobBlbnRlcnByaXNlobEgdG8gobBJMk5TRiBjbGllbnRzobEuIFdoZXJlIGFyZSB0aGUgcGVy Zm9ybWFuY2UgZGF0YSBvciByZXBvcnQgc2VudCB0bz8gSSB0aGluayB0aGV5IHNob3VsZCBiZSB0 aGUgc2VjdXJpdHkgc2VydmljZSBwcm92aWRlcnMgb3IganVzdCB0aGUgSTJOU0YgY2xpZW50cy4N Cg0KVGhlcmUgYXJlIHR3byBsYXllcnMgb2YgaW50ZXJmYWNlczoNCg0KLSAgICAgICAgICBTZWN1 cml0eSBQb2xpY2llcyBmYWNpbmcgc2VjdXJpdHkgZnVuY3Rpb25zIChJMk5TRiBDYXBhYmlsaXR5 IExheWVyKQ0KDQotICAgICAgICAgIFNlY3VyaXR5IFBvbGljaWVzIGZhY2luZyBjbGllbnRzIChJ Mk5TRiBTZXJ2aWNlIExheWVyKQ0KDQpUaGUgSTJOU0YgQ2FwYWJpbGl0eSBMYXllciBzcGVjaWZp ZXMgdGhlIGZ1bmN0aW9uYWwgc2VjdXJpdHkgcG9saWNpZXMsIHdoaWNoIGFyZSB0cmFuc2xhdGVk IGZyb20gdGhlIGNsaWVudCBzZWN1cml0eSBwb2xpY2llcywgdG8gc2VjdXJpdHkgZnVuY3Rpb25z LiBJMk5TRiB3aWxsIE5PVCBzdGFuZGFyZGl6ZSBzZWN1cml0eSBmdW5jdGlvbnMgb3IgZGV2aWNl cy4gSW5zdGVhZCwgSTJOU0YgaXMgb25seSB0byBzdGFuZGFyZGl6ZSB0aGUgcG9saWN5IHByb3Zp c2lvbmluZyB0byB0aGUgc2VjdXJpdHkgZnVuY3Rpb25zIChub3QgZGV2aWNlcyksIGluIHRoZSBm b3JtIG9mIKGwU3ViamVjdCCoQyBPYmplY3QgqEMgRnVuY3Rpb24gqEMgQWN0aW9uobEgcGFyYWRp Z20uDQoNClRoZSBJMk5TRiBTZXJ2aWNlIExheWVyIGlzIGZvciBjbGllbnRzIHRvIGV4cHJlc3Mg YW5kIG1vbml0b3Igc2VjdXJpdHkgcG9saWNpZXMgZm9yIHRoZWlyIHNwZWNpZmljIGZsb3dzLCB3 aGljaCBpcyB1c3VhbGx5IGJhc2VkIG9uIGN1c3RvbWVyc6GvIGxvZ2ljYWwgbmV0d29ya3MsIGFk ZHJlc3NlcyBhbmQgY29udGV4dC4gSTJOU0YgU2VydmljZSBMYXllciBjYW4gYWxzbyBiZSBzZWN1 cml0eSBleHBlY3RhdGlvbiBvciBsb29zZSBzZWN1cml0eSByZXF1aXJlbWVudCwgZXNwZWNpYWxs eSBmb3IgY3VzdG9tZXJzIHdobyBkb26hr3QgaGF2ZSB0aGUgc2VjdXJpdHkgZXhwZXJ0aXNlLg0K W0ZyYW5rXTogZm9yIHRoZSB0d28gaW50ZXJmYWNlcywgbm90IG1lbnRpb25pbmcgdGhlIGZ1bmN0 aW9ucyByZWxhdGVkIHdpdGggcGVyZm9ybWFuY2UgZGF0YSBvciByZXBvcnQ/DQoNClRoZSBjb25j cmV0ZSB3b3JrIGF0IHRoZSBMMk5TRiBDYXBhYmlsaXR5IExheWVyIGluY2x1ZGVzDQoNCi0gICAg ICAgICAgVGhlIGluZm9ybWF0aW9uYWwgJiBkYXRhIG1vZGVscyBmb3IgZWFjaCBjYXRlZ29yeSB0 byBiZSByZXByZXNlbnRlZCB0byB2aXJ0dWFsIG9yIHBoeXNpY2FsIG5ldHdvcmsgc2VjdXJpdHkg ZnVuY3Rpb25zLA0KDQotICAgICAgICAgIFRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBv ZiBwb2xpY3kgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBm dW5jdGlvbiwgYW5kDQoNCi0gICAgICAgICAgVGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlv biBjaGFubmVscyB0byBjYXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9s bGVyIGFuZCBOU0ZzLg0KVGhlIGNhcGFiaWxpdHkgcmVnaXN0cnkgaXMgdG8gbWFrZSBpdCBmZWFz aWJsZSB0byBjYXRlZ29yaXplIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rpb25zIHByb3ZpZGVkIGJ5 IGRpZmZlcmVudCB2ZW5kb3JzIGJhc2VkIG9uIHNlY3VyaXR5IHBvbGljeSBwcm92aXNpb25pbmcg Y2FwYWJpbGl0eSB3aXRob3V0IGFueSBuZWVkIHRvIHN0YW5kYXJkaXplIHNlY3VyaXR5IGZ1bmN0 aW9ucyB0aGVtc2VsdmVzLiAgU3RhbmRhcmQgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgaW50ZXJm YWNlIGlzIGFuIGVzc2VudGlhbCBidWlsZGluZyBibG9jayBmb3IgU2VjdXJpdHkgU2VydmljZSBQ cm92aWRlciB0byBhdXRvbWF0ZSB0aGVpciBTZWN1cml0eSBDb250cm9sbGVycyB0aGF0IGNhbiB1 dGlsaXplIE5TRiBieSBtdWx0aXBsZSB2ZW5kb3JzLiBUaGlzIGxheWVyIHdpbGwgbGV2ZXJhZ2Ug dGhlIGV4aXN0aW5nIHByb3RvY29scyBhbmQgZGF0YSBtb2RlbHMgZGVmaW5lZCBieSBJMlJTLCBO ZXRjb25mLCBhbmQgTkVUTU9ELg0KDQpGb3IgdGhlIEkyTlNGIFNlcnZpY2UgTGF5ZXIsIGl0IGlz IG91dCBvZiB0aGUgc2NvcGUgZm9yIEkyTlNGIChhdCBsZWFzdCBmb3Igbm93KSB0byBzdGFuZGFy ZGl6ZSB0aGUgaW50ZXJmYWNlIGZhY2luZyBjbGllbnRzLiBIb3dldmVyLCBJMk5TRiBjYW4gaGF2 ZSBpbmZvcm1hdGlvbmFsIGRyYWZ0cyBzaG93aW5nIHNhbXBsZSBBUElzIG9yL2FuZCBSRVNUZnVs IGludGVyZmFjZXMgdG8gY2xpZW50cyBhbmQgZGVtb25zdHJhdGluZyB0aGUgZmVhc2liaWxpdHkg b2YgdGhlbSBiZWluZyB0cmFuc2xhdGVkIHRvIHRoZSBDYXBhYmlsaXR5IExheWVyIHBvbGljaWVz Lg0KDQpTaW5jZSBkaWZmZXJlbnQgc2VjdXJpdHkgdmVuZG9ycyBzdXBwb3J0IGRpZmZlcmVudCBm ZWF0dXJlcyAmIGZ1bmN0aW9ucyBvbiB0aGVpciBkZXZpY2VzLCBJMk5TRiB3aWxsIGZvY3VzIG9u IGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb25zIHRoYXQgcHJvdmlkZSB0cmVhdG1lbnQgdG8g cGFja2V0cy9mbG93cywgc3VjaCBhcyBJUFMvSURTLCBXZWIgZmlsdGVyLCBhbmQgZmxvdyBmaWx0 ZXIuIChUaGV5IGFyZSBkaWZmZXJlbnQgZnJvbSBvdGhlciBzZWN1cml0eSBmdW5jdGlvbnMgc3Vj aCBhcyBBdXRoZW50aWNhdGlvbiwgQXV0aG9yaXphdGlvbiwgb3IgRW5jcnlwdGlvbikuIEV4ZW1w bGFyIHNlcnZpY2VzIGFzc29jaWF0ZWQgd2l0aCBGbG93IEJhc2VkIFNlY3VyaXR5IGZ1bmN0aW9u cyBpbmNsdWRlIGRlZXAgcGFja2V0IGluc3BlY3Rpb24sIHBhY2tldC9mbG93L3N0cmVhbSBmaWx0 ZXJpbmcgb3IgcGF0dGVybiBtYXRjaGluZyBhbmQgcmVtZWRpYXRpb24sIGV0Yy4NCg0KU2ltaWxh ciB0byBJMlJTIGZvY3VzaW5nIG9uIHRoZSBpbnRlcmZhY2UgdG8gUklCL0ZJQiBldmVuIHRob3Vn aCBtb3N0IHJvdXRlcnMgcHJvdmlkZSBmYXIgbW9yZSBmdW5jdGlvbnMgdGhhbiBSSUIvRklCLCB0 aGUgSTJOU0YgZm9jdXNlZCBmdW5jdGlvbnMgY2FuIGJlIGEgcG9ydGlvbiBvZiBmZWF0dXJlcyBz dXBwb3J0ZWQgYnkgdmVuZG9yc6GvIHNwZWNpZmljIGRldmljZXMuDQoNCkl0IGlzIGEgbm9uLWdv YWwgdG8gY3JlYXRlIG5ldyBwcm90b2NvbHMgb3IgZGF0YSBtb2RlbGluZyBsYW5ndWFnZXMgZm9y IEkyTlNGIGludGVyZmFjZXMuDQpJMk5TRiBXRyBEZWxpdmVyYWJsZXMgaW5jbHVkZToNCg0KDQot ICAgICAgICAgICBVc2UgQ2FzZSBkb2N1bWVudC4NCg0KLSAgICAgICAgICBGcmFtZXdvcmsgRG9j dW1lbnQuDQoNCi0gICAgICAgICAgUmVxdWlyZW1lbnQgZm9yIGV4dGVuc2lvbnMgKGlmIHRoZXJl IGFyZSBhbnkpIHRvIGV4aXN0aW5nIHByb3RvY29scyB1c2VkIGJ5IHRoZSBXRy4NCg0KLSAgICAg ICAgICAgR2FwIGFuYWx5c2lzIG9mIGV4aXN0aW5nIHByb3RvY29scyBhbmQgbW9kZWxpbmcgbGFu Z3VhZ2VzDQoNCi0gICAgICAgICAgQSBzaW5nbGUsIHVuaWZpZWQsIEluZm9ybWF0aW9uIE1vZGVs IGZvciBleHByZXNzaW5nIHBvbGljaWVzIHRvIHRoZSBGbG93IEJhc2VkIFNlY3VyaXR5IEZ1bmN0 aW9ucyBkZXNjcmliZWQgYWJvdmUuDQoNCi0gICAgICAgICAgQ29ycmVzcG9uZGluZyBEYXRhIE1v ZGVscyAoZS5nLiBZQU5HIG1vZGVscykgZGVyaXZlZCBmcm9tIHRoZSBhYm92ZSBJbmZvcm1hdGlv biBNb2RlbC4NCg0KLSAgICAgICAgICBJQU5BIHJlZ2lzdHJ5IGNvbnNpZGVyYXRpb24gZm9yIGZs b3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb24gcG9saWN5IHByb3Zpc2lvbmluZyBjYXBhYmlsaXR5 Lg0KDQotICAgICAgICAgICAoT3B0aW9uYWxseSkgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIG9u IGhvdyB0byB1c2UgSTJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRCB0byBjYXJyeSB0aGUgY29udGVu dCBvZiB0aGUgc3BlY2lmaWVkIGluZm9ybWF0aW9uL2RhdGEgbW9kZWxzLg0KDQpbVGhlIFdHIG1h eSBkZWNpZGUgdGhhdCB0aGUgVXNlIGNhc2VzLCBGcmFtZXdvcmssIGFuZCBSZXF1aXJlbWVudCBh cmUgSW5mb3JtYXRpb25hbCBkb2N1bWVudHMgb3Igc2ltcGx5IHJlZmVyZW5jZSBkb2N1bWVudHMg ZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUgV0cuIFRoZSBmcmFtZXdvcmssIHRoYXQgZGVzY3Jp YmVzIHRoZSBmdW5jdGlvbmFsIGNvbXBvbmVudHMgYW5kIHRoZSBJMk5TRiB3b3JrIGl0ZW1zLCBp cyB0byBtYWtlIEkyTlNGIHdvcmsgbW9yZSBvcmdhbml6ZWQuXQ0KDQpTdWdnZXN0ZWQgTWlsZXN0 b25lcw0KICAtIFVzZSBDYXNlIERvY3VtZW50OiAgQ2hhcnRlciB0aW1lICsgMSBtb250aCB0byBX RyBEb2N1bWVudA0KICAtIEZyYW1ld29yazogQ2hhcnRlciB0aW1lICsgNCBtb250aHMgdG8gV0cg RG9jdW1lbnQNCiAgLSBSZXF1aXJlbWVudHMgZm9yIGV4dGVuc2lvbnMgdG8gcHJvdG9jb2xzOiAg Q2hhcnRlciB0aW1lICsgNiBtb250aHMgdG8gV0cgZG9jdW1lbnQNCiAgLSBJbmZvIG1vZGVsOiBD aGFydGVyIHRpbWUgKyA3IG1vbnRocyB0byBXRyBEb2N1bWVudA0KICAtIElBTkEgcmVnaXN0cnkg Y29uc2lkZXJhdGlvbiArIDEwIG1vbnRocyB0byBXRyBEb2N1bWVudA0KICAtIEFsbCBFYXJseSBE cmFmdHMgdG8gSUVTRzogMTAgbW9udGhzDQoNCltkZWNpc2lvbiBwb2ludCCoQyArMTAgbW9udGhz XQ0KICAtIERhdGEgTW9kZWxzOiBDaGFydGVyICsgOSBNb250aHMgdG8gV0cgRG9jdW1lbnQNCiAg LSBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudHM6IDEwIG1vbnRocyB0byBXRyBEb2N1bWVudA0KICAt IERhdGEgTW9kZWxzIGFuZCBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudHMgdG8gSUVTRyAgLSAxNiBt b250aHMNCg0KVGhlIFdHIHdpbGwgd29yayBjbG9zZWx5IHdpdGggSTJSUywgTmV0Y29uZiBhbmQg TmV0bW9kIFdHcy4gVGhlIFdHIHdpbGwgY29tbXVuaWNhdGUgd2l0aCBleHRlcm5hbCBTRE9zIGxp a2UgRVRTSSBORlYgYW5kIHdpbGwgZW5jb3VyYWdlIG9wZW4gc291cmNlIGNvZGUgZGV2ZWxvcG1l bnQgcmVsYXRlZCB0byB0aGUgV0cgc2NvcGUgaW4gb3JnYW5pemF0aW9ucyBsaWtlIE9ORiwgT3Bl blN0YWNrLCBPREwsIGFuZCBPcGVuTkZWLg0KDQoNCkNoZWVycywNCkxpbmRhIER1bmJhcg0K --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Linda,

I agree that we can specify capability interface firstly, and lea= ve the currently vague service interface out of scope now. But still, as an= essential part of the whole solution, the service interface is also very important for various clients to expres= s their custom security requirement flexibly. So, I suggest we can set the = specification of service interface as the second phase of I2NSF work.<= /o:p>

 

Other comments are inline:

 

B.R.

Frank

 

=B7=A2=BC=FE=C8=CB: I2nsf [= mailto:i2nsf-bounces@ietf.org] =B4=FA= =B1=ED Linda Dunbar
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA5=D4=C27=C8=D5 23:53
=CA=D5=BC=FE=C8=CB: i2nsf@ietf.org; Kathleen Moriarty
=B3=AD=CB=CD: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
=D6=F7=CC=E2: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

 

Thanks to I2NSF contributors fo= r the good progresses made since  IETF92 side meetings. Among the two = I2NSF interfaces,  i.e. the client facing Service Interface and the NS= F facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. But the = Service Interface is still a little vague.

 

The feedback from last IETF sid= e meetings was "the scope is too big for one IETF WG". Therefore,= we are leaning towards narrowing the I2NSF scope to the Capability Interfa= ce. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service inte= rface. Even if Capability layer alone is standardized, it is a giant leap f= orward in building blocks for Service Provider to automate their Security C= ontroller that can utilize NSF by multiple vendors

 

Here is the narrower scoped I2N= SF charter. Your comments and suggestions are greatly appreciated. CC=A1=AF= ed to DOTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential, and m= obile customers are increasingly consuming network functions, especially ne= twork security related functions that are not running on their premises.&nb= sp; In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiativ= e creates new management challenges for security policies to be enforced by= distributed, virtual, network security functions (vNSF). Without standard = interface to express, monitor, and manage security policies to security functions deployed at different premi= ses, it becomes virtually impossible for security service providers to auto= mate the service offering utilizing security functions by multiple vendors.

 

The ultimate goal of I2NSF is t= o enable enterprises to utilize security functions not hosted on their own = premises but instead hosted in service provider domain, to establish how to= communicate desired security policies to NSF and how to get performance data or report out of NSF or vNSF.<= /o:p>

[Frank]: the I2NSF clients do not only include enterprise. So, ch= ange =A1=B0enterprise=A1=B1 to =A1=B0I2NSF clients=A1=B1. Where are the per= formance data or report sent to? I think they should be the security service providers or just the I2NSF clients.

 

There are two layers of interfa= ces:

-=    &n= bsp;      Security Policies facin= g security functions (I2NSF Capability Layer)

-=    &n= bsp;      Security Policies facin= g clients (I2NSF Service Layer)

 

The I2NSF= Capability Layer specifies the functional security policies, which are tra= nslated from the client security policies, to security functions. I2NSF wil= l NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to = the security functions (not devices), in the form of =A1=B0Subject =A8C Obj= ect =A8C Function =A8C Action=A1=B1 paradigm. 

&nbs= p;

The I2NSF Service Layer is for = clients to express and monitor security policies for their specific flows, = which is usually based on customers=A1=AF logical networks, addresses and c= ontext. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customers who do= n=A1=AFt have the security expertise.

[Frank]: for the two interfaces, not mentioning the functions rel= ated with performance data or report?

 

The concrete work at the L2NSF = Capability Layer includes

-The informational &= data models for each category to be represented to virtual or physical net= work security functions,

-The capability registry= (IANA) of policy provisioning capability to flow based security function, = and

-The proper secure commu= nication channels to carry the security policies between Controller and NSF= s.

The capability registry is to m= ake it feasible to categorize network security functions provided by differ= ent vendors based on security policy provisioning capability without any ne= ed to standardize security functions themselves.  Standard provisioning capability interface is an essenti= al building block for Security Service Provider to automate their Security = Controllers that can utilize NSF by multiple vendors. This layer will lever= age the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service Layer, it= is out of the scope for I2NSF (at least for now) to standardize the interf= ace facing clients. However, I2NSF can have informational drafts showing sa= mple APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to t= he Capability Layer policies.

&nbs= p;

Since different security vendor= s support different features & functions on their devices, I2NSF will f= ocus on flow based security functions that provide treatment to packets/flo= ws, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Authenti= cation, Authorization, or Encryption). Exemplar services associated with Fl= ow Based Security functions include deep packet inspection, packet/flow/str= eam filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusing on the= interface to RIB/FIB even though most routers provide far more functions t= han RIB/FIB, the I2NSF focused functions can be a portion of features suppo= rted by vendors=A1=AF specific devices.

 

It is a non-goal to create new = protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables include:<= o:p>

 

-=    &n= bsp;       Use Case document= .

-=    &n= bsp;      Framework Document.

-=    &n= bsp;      Requirement for extensi= ons (if there are any) to existing protocols used by the WG.

-=    &n= bsp;       Gap analysis of e= xisting protocols and modeling languages

-=    &n= bsp;      A single, unified, Info= rmation Model for expressing policies to the Flow Based Security Functions = described above.

-=    &n= bsp;      Corresponding Data Mode= ls (e.g. YANG models) derived from the above Information Model.<= /span>

-=    &n= bsp;      IANA registry considera= tion for flow based security function policy provisioning capability.<= /o:p>

-=    &n= bsp;       (Optionally) Appl= icability Statements on how to use I2RS, Netconf, and NETMOD to carry the c= ontent of the specified information/data models.

 

[The WG may decide that the Use cases, Framework, a= nd Requirement are Informational documents or simply reference documents during the lifetime of the WG. The f= ramework, that describes the functional components and the I2NSF work items= , is to make I2NSF work more organized.]=

 

Suggested Milestones=

  - Use Case Document:&nbs= p; Charter time + 1 month to WG Document

  - Framework: Charter tim= e + 4 months to WG Document

  - Requirements for exten= sions to protocols:  Charter time + 6 months to WG document

  - Info model: Charter ti= me + 7 months to WG Document

  - IANA registry consider= ation + 10 months to WG Document

  - All Early Drafts to IE= SG: 10 months

 

[decision point =A8C +10 mo= nths] 

  - Data Models: Char= ter + 9 Months to WG Document

  - Applicability Statemen= ts: 10 months to WG Document

  - Data Models and Applic= ability Statements to IESG  - 16 months

 

The WG will work closely with I= 2RS, Netconf and Netmod WGs. The WG will communicate with external SDOs lik= e ETSI NFV and will encourage open source code development related to the W= G scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 

 

Cheers,

Linda Dunbar<= /p>

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_-- From nobody Tue May 12 22:48:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE4E1A9105; Tue, 12 May 2015 20:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdONEigTiZnf; Tue, 12 May 2015 20:55:29 -0700 (PDT) Received: from out4133-50.mail.aliyun.com (out4133-50.mail.aliyun.com [42.120.133.50]) by ietfa.amsl.com (Postfix) with ESMTP id 88C431A8F45; Tue, 12 May 2015 20:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1431489313; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=cwNWZqs8M1TIDYg6hwGFobH/ejKNObyv2IQQcH5xIuE=; b=mqGIdA/rUQb5VY3Vn9Whn+XICpW6+WLo2YWCazKFbrSyUNf9rTGPL7sbo8/cFl8g9ON9z4z3PtyZghulixUd5wTZ2XJrGGIcjMdWejUPWwGEEK8YHOdwMZPN9bqsq3dlHmMIlCfoa+m1ot916/Xeesp/aEehPfr6iy/DvPjfyfc= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R631e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03024; MF=dacheng.zdc@alibaba-inc.com; PH=DS; RN=6; RT=6; SR=0; Received: from 10.62.55.14(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Wed, 13 May 2015 11:55:09 +0800 User-Agent: Microsoft-MacOutlook/14.4.9.150325 Date: Wed, 13 May 2015 11:55:02 +0800 From: "Dacheng Zhang" To: Linda Dunbar , "i2nsf@ietf.org" , Kathleen Moriarty Message-ID: Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3514362909_21843223" Archived-At: X-Mailman-Approved-At: Tue, 12 May 2015 22:48:54 -0700 Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 03:55:35 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3514362909_21843223 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi=EF=BC=8CLinda: I like the current version of charter, which clarifies a reasonable scope o= f this work. Some tiny comments. The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represented to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability to flow based security function, and - The proper secure communication channels to carry the security policies between Controller and NSFs. >>Dacheng: the third bullet is quite trival compared with the first two bul= lets, since we will try to re-use the work of I2RS,Netconf where the generation o= f security channels have already considered. So, maybe we could remove it. The capability registry is to make it feasible to categorize network security functions provided by different vendors based on security policy provisioning capability without any need to standardize security functions themselves. Standard provisioning capability interface is an essential building block for Security Service Provider to automate their Security Controllers that can utilize NSF by multiple vendors. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD. >>Dacheng: I suggest to change the last sentence to =E2=80=9CIn this layer, we wi= ll leverage the existing protocols and data models defined by I2RS, Netconf, a= nd NETMOD as much as possible.=E2=80=9D Similar to I2RS focusing on the interface to RIB/FIB even though most routers provide far more functions than RIB/FIB, the I2NSF focused function= s can be a portion of features supported by vendors=E2=80=99 specific devices. >>Dacheng: the first part of this sentence is redundant. We don=E2=80=99t have to= imply that =E2=80=9Cwe work in this way because I2RS used to do similar things. So if y= ou want to challenge us, please challenge I2RS first=E2=80=9D. Maybe we could remove it. =E5=8F=91=E4=BB=B6=E4=BA=BA: Linda Dunbar =E6=97=A5=E6=9C=9F: 2015=E5=B9=B45=E6=9C=887=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B =E4=B8=8B=E5=8D=8811:53 =E8=87=B3: "i2nsf@ietf.org" , Kathleen Moriarty =E6=8A=84=E9=80=81: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" =E4=B8=BB=E9=A2=98: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e meetings. Among the two I2NSF interfaces, i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. But the Service Interface is still a little vague. =20 The feedback from last IETF side meetings was "the scope is too big for one IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to th= e Capability Interface. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service interface. Even if Capability layer alone is standardized, it is a giant leap forward in building blocks for Service Provider to automate their Security Controller that can utilize NSF by multiple vendors =20 Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=E2=80=99ed to DOTS, I2RS, and Netmod groups for wider review.=20 =20 =20 =20 Enterprises, residential, and mobile customers are increasingly consuming network functions, especially network security related functions that are not running on their premises. In addition, the European Telecommunication= s Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new management challenges for security policies to be enforced by distributed, virtual, network security functions (vNSF). Without standard interface to express, monitor, and manage security policies to security functions deployed at different premises, it becomes virtually impossible for security service providers to automate the service offering utilizing security functions by multiple vendors. =20 The ultimate goal of I2NSF is to enable enterprises to utilize security functions not hosted on their own premises but instead hosted in service provider domain, to establish how to communicate desired security policies to NSF and how to get performance data or report out of NSF or vNSF. =20 There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability Layer) - Security Policies facing clients (I2NSF Service Layer) =20 The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the client security policies, to security functions. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to the security functions (not devices), in the form of =E2=80=9CSubject =E2=80=93 Object =E2=80=93 Function =E2=80=93 Action=E2=80=9D p= aradigm. =20 The I2NSF Service Layer is for clients to express and monitor security policies for their specific flows, which is usually based on customers=E2=80=99 logical networks, addresses and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customer= s who don=E2=80=99t have the security expertise. =20 The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represented to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability to flow based security function, and - The proper secure communication channels to carry the security policies between Controller and NSFs. The capability registry is to make it feasible to categorize network security functions provided by different vendors based on security policy provisioning capability without any need to standardize security functions themselves. Standard provisioning capability interface is an essential building block for Security Service Provider to automate their Security Controllers that can utilize NSF by multiple vendors. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD. =20 For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for now) to standardize the interface facing clients. However, I2NSF can have informational drafts showing sample APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to the Capability Layer policies. =20 Since different security vendors support different features & functions on their devices, I2NSF will focus on flow based security functions that provide treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Authentication, Authorization, or Encryption). Exemplar services associated with Flow Based Security functions include deep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc. =20 Similar to I2RS focusing on the interface to RIB/FIB even though most routers provide far more functions than RIB/FIB, the I2NSF focused function= s can be a portion of features supported by vendors=E2=80=99 specific devices. =20 It is a non-goal to create new protocols or data modeling languages for I2NSF interfaces.=20 I2NSF WG Deliverables include: =20 - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protocols used by the WG. - Gap analysis of existing protocols and modeling languages - A single, unified, Information Model for expressing policies to the Flow Based Security Functions described above. - Corresponding Data Models (e.g. YANG models) derived from the above Information Model. - IANA registry consideration for flow based security function policy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netconf, and NETMOD to carry the content of the specified information/data models. =20 [The WG may decide that the Use cases, Framework, and Requirement are Informational documents or simply reference documents during the lifetime o= f the WG. The framework, that describes the functional components and the I2NSF work items, is to make I2NSF work more organized.] =20 Suggested Milestones - Use Case Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 months to W= G document - Info model: Charter time + 7 months to WG Document - IANA registry consideration + 10 months to WG Document - All Early Drafts to IESG: 10 months =20 [decision point =E2=80=93 +10 months] - Data Models: Charter + 9 Months to WG Document - Applicability Statements: 10 months to WG Document - Data Models and Applicability Statements to IESG - 16 months =20 The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will communicate with external SDOs like ETSI NFV and will encourage open source code development related to the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV. =20 =20 Cheers,=20 Linda Dunbar _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf --B_3514362909_21843223 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi=EF=BC=8CLinda:

I like the current version of charter, which clarifies a reasonable s= cope of this work. Some tiny comments. 


The = concrete work at the L2NSF Capability Layer includes

-          <= /span>The informational & data models for each category to be represente= d to virtual or physical network security functions,

-          <= /span>The capability registry (IANA) of policy provisioning capability to fl= ow based security function, and

- =          The proper secu= re communication channels to carry the security policies between Controller = and NSFs.


>>Dacheng: the third bullet is quite tri= val compared with the first two bullets, since we will try to re-use the wor= k of I2RS,Netconf where the generation of security channels have already con= sidered.  So, maybe we could remove it. 


The capability registry is to make it fe= asible to categorize network security functions provided by different vendor= s based on security policy provisioning capability without any need to stand= ardize security functions themselves.  Standard provisioning capability= interface is an essential building block for Security Service Provider to a= utomate their Security Controllers that can utilize NSF by multiple vendors.= This layer will leverage the existing protocols and data models defined by = I2RS, Netconf, and NETMOD.


>>Dacheng: I suggest to change the last sentence to “= ;In this layer, we will leverage the existing protocols and data models defi= ned by I2RS, Netconf, and NETMOD as much as possible.”


Similar to I2RS focusing on the interface to RIB/FIB even though mos= t routers provide far more functions than RIB/FIB, the I2NSF focused functio= ns can be a portion of features supported by vendors’ specific devices= .


=

>>Dache= ng: the first part of this sentence is redundant. We don’t have to imp= ly that “we work in this way becau= se I2RS used to do similar things. So if you want to challenge us, please ch= allenge I2RS first”. Maybe we could remove it. 

<= div>
=E5=8F=91=E4=BB=B6=E4=BA=BA: Linda Dunbar &l= t;linda.dunbar@huawei.com>=E6=97=A5=E6=9C=9F: 2015=E5=B9=B45=E6=9C=887=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B =E4= =B8=8B=E5=8D=8811:53
=E8=87=B3: "i2nsf@ietf.org" <i2nsf= @ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
=E6=8A=84=E9=80=81: "i2rs@ietf.org<= /a>" <i2rs@ietf.org>, "dots@ietf.org" <dot= s@ietf.org>, "netmod@ietf.org" &= lt;netmod@ietf.org>
=E4=B8=BB=E9=A2=98: [I2nsf] Further Narrowing the I2NSF scope:= the new charter for IETF 93

Thanks to I2NSF contribut= ors for the good progresses made since  IETF92 side meetings. Among the= two I2NSF interfaces,  i.e. the client facing Service Interface and th= e NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. But the Service Interface is st= ill a little vague.

 

The feedback from last IETF side meetings was "the scope is too big for o= ne IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to = the Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. Even if Capabilit= y layer alone is standardized, it is a giant leap forward in building blocks= for Service Provider to automate their Security Controller that can utilize= NSF by multiple vendors

 

Here is the narrower scoped I2NSF charter. Your co= mments and suggestions are greatly appreciated. CC’ed to DOTS, I2RS, a= nd Netmod groups for wider review.

 

<= o:p> 

 

Enterprises, residential, and mobile customers are increasingly= consuming network functions, especially network security related functions = that are not running on their premises.  In addition, the European Tele= communications Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new manage= ment challenges for security policies to be enforced by distributed, virtual= , network security functions (vNSF). Without standard interface to express, = monitor, and manage security policies to security functions deployed at different premises, it becomes virtually= impossible for security service providers to automate the service offering = utilizing security functions by multiple vendors.

 

The ultimate goal of I2NSF is to enable enterprises to utilize security f= unctions not hosted on their own premises but instead hosted in service prov= ider domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF.

 

There are two layers o= f interfaces:

<= span style=3D"mso-list:Ignore">-        &nbs= p; Security Policies facing security functions (I2= NSF Capability Layer)

-       &n= bsp;  Security Policies facing clients (I2NSF Service= Layer)

 

The I2NSF Capability Layer specifies the = functional security policies, which are translated from the client security = policies, to security functions. I2NSF will NOT standardize security functio= ns or devices. Instead, I2NSF is only to standardize the policy provisioning to the security funct= ions (not devices), in the form of “Subject – Object – Fun= ction – Action” paradigm. 

&= nbsp;

The I2NSF Service Layer is for cl= ients to express and monitor security policies for their specific flows, whi= ch is usually based on customers’ logical networks, addresses and cont= ext. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customers who don’t ha= ve the security expertise.

 

The concrete work at the L2NSF Capability Layer = includes

-     &= nbsp;    The informational & data models for = each category to be represented to virtual or physical network security func= tions,

= -=           The capability registry (IANA) of policy= provisioning capability to flow based security function, and

= - = ;         The proper secure communication channels= to carry the security policies between Controller and NSFs.

The ca= pability registry is to make it feasible to categorize network security func= tions provided by different vendors based on security policy provisioning ca= pability without any need to standardize security functions themselves. &nbs= p;Standard provisioning capability interface is an essential building block for Secur= ity Service Provider to automate their Security Controllers that can utilize= NSF by multiple vendors. This layer will leverage the existing protocols an= d data models defined by I2RS, Netconf, and NETMOD.

 <= /p>

For the I2NSF Service Layer, it is out of the scope = for I2NSF (at least for now) to standardize the interface facing clients. Ho= wever, I2NSF can have informational drafts showing sample APIs or/and RESTfu= l interfaces to clients and demonstrating the feasibility of them being translated to the Capability Layer policies.=

 

Since different security vendors support= different features & functions on their devices, I2NSF will focus on fl= ow based security functions that provide treatment to packets/flows, such as= IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Authentication, Authorizat= ion, or Encryption). Exemplar services associated with Flow Based Security f= unctions include deep packet inspection, packet/flow/stream filtering or pat= tern matching and remediation, etc.

 

Similar to I2RS focusing on the interface to RIB/FIB even though mo= st routers provide far more functions than RIB/FIB, the I2NSF focused functi= ons can be a portion of features supported by vendors’ specific device= s.

 

It is a non-goal to create new protocols or data modeling languages for = I2NSF interfaces.

I2NSF WG Deliverables include:

 

-     &n= bsp;     Use Case document.

-  = ;        Framework Document.

-   = ;       Requirement for extensions (if there are any) t= o existing protocols used by the WG.

-           Gap analysis of existing protocols and mo= deling languages

A single, unified, Information Model for expres= sing policies to the Flow Based Security Functions described above.

-= -    &n= bsp;     IANA registry consideration for flow based secu= rity function policy provisioning capability.

-   &n= bsp;       (Optionally) Applicability Statements on = how to use I2RS, Netconf, and NETMOD to carry the content of the specified i= nformation/data models.

 =

[The WG may decide that the= Use cases, Framework, and Requirement are Informational documents or simply= reference documents during the lifetime of the WG. The framework, that describes the functional components = and the I2NSF work items, is to make I2NSF work more organized.]

 

Suggested Milestones

  - Use Case Document:  Charter time + 1 month to WG Document

  - Framework: Charter time + 4 month= s to WG Document

  - Requirements fo= r extensions to protocols:  Charter time + 6 months to WG document=

  - Info model: Charter time + 7 months = to WG Document

  - IANA registry con= sideration + 10 months to WG Document

&nb= sp; - All Early Drafts to IESG: 10 months

 

[decision point – +10 month= s] 

  - Data Models: Char= ter + 9 Months to WG Document

  - Ap= plicability Statements: 10 months to WG Document

  - Data Models and Applicability Statements to IESG  - 16= months

 

The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will= communicate with external SDOs like ETSI NFV and will encourage open source= code development related to the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 

 

Cheers,

Linda Dunbar

_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/= mailman/listinfo/i2nsf --B_3514362909_21843223-- From nobody Tue May 12 23:51:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653EF1AC3EA for ; Tue, 12 May 2015 23:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trcsWo5a_Dgs for ; Tue, 12 May 2015 23:51:05 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50BD1A0231 for ; Tue, 12 May 2015 23:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=452; q=dns/txt; s=iport; t=1431499864; x=1432709464; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=vn7ZeEw/84Nm0RhOzTYDdNdpNIW01TTES+52oIzMSnM=; b=GTH4HQ6GGEgJTUMMUC+FPlwoDs97T4sMIlSP4umWP9dGO+NHTxwZT/RA kShAn+fMFBimUuN6A/OsSxyDWFgvojrjkqtrNp4u1xyl57zs816Tih0jp djnDGHDDu7K10KKfs3/dn9hEH8BodajiTAWdDy3hff1RUY63bqIKHZvXl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnBAA781JV/xbLJq1ch1/JcIF0EAEBAQEBAQGBCoQjJw8BBUABNQIFFgsCCwMCAQIBSw0BBwEBiCi1bJI3AQEBAQEBBAEBAQEBARyBIY8dgm+BRQEEnUGBJYNjgluPEyNhgxg8gncBAQE X-IronPort-AV: E=Sophos;i="5.13,419,1427760000"; d="scan'208";a="471321042" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 13 May 2015 06:51:03 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t4D6p3mm014747; Wed, 13 May 2015 06:51:03 GMT Message-ID: <5552F457.2040002@cisco.com> Date: Wed, 13 May 2015 08:51:03 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [netmod] Next NETMOD chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 06:51:06 -0000 Dear all, As you probably know from a previous message to the list, Jürgen announced his plans to step down as co-chair. Please welcome Kent Watsen, who has accepted to serve as NETMOD co-chair. As agreed with Jürgen, the NETMOD WG will run with three chairs until the YANG 1.1 work is completed. That important YANG 1.1 milestone is the point in time Jürgen decided to pass the baton. Thanks to Kent and Jürgen. Regards, Benoit From nobody Wed May 13 02:00:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6FC1A6EE6 for ; Wed, 13 May 2015 02:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.238 X-Spam-Level: * X-Spam-Status: No, score=1.238 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpvBHmUgYN9F for ; Wed, 13 May 2015 02:00:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C451A1E0E for ; Wed, 13 May 2015 02:00:15 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 25CDD13FACA for ; Wed, 13 May 2015 11:00:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1431507613; bh=ahkiywysry+PNWi8aq5Q8hgcF4jAMJ/DXPs9q4ayaGI=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=SMTzElYhSH0SiNHdMgssyZ48+Ej2+oQ+5jqfzwWiQRbQIMyLhi0HFAraXF6UQtHeT dGb3W4/krMJoazQqnGrjZmPh5APZomkcR4ORf9LMvig048O8//FlPaCzIF+BufMFSW YEhTU6mS9UafxvyvO0EPD/bpR3KSjsnNLxr1tdHQ= From: Ladislav Lhotka Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 13 May 2015 11:00:14 +0200 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] references to state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 09:00:17 -0000 Hi, I don=E2=80=99t want to reopen Y42 but maybe there are some related bits = we could still consider. One thing that I find really annoying is the restriction that = configuration cannot refer to state data in leafrefs and must/when = expressions. I understand it prevents the data modeller from doing some = stupid things like defining a config leafref pointing to a statistics = counter, but it also IMO makes tome clearly useful things impossible. For example, ietf-system has platform information under system-state, = and it would make a very good sense to have some config data conditional = via =E2=80=9Cwhen", based on the platform. Similarly, in order to be able to refer in configuration to a = system-controlled interface, one needs to put the system-controlled = interface into configuration as well, even though nothing is really = configured for it. Is that restriction really necessary? What about removing it in YANG = 1.1? Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed May 13 06:01:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A5B1A9151 for ; Wed, 13 May 2015 06:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jbx8kdqSwGtP for ; Wed, 13 May 2015 06:01:21 -0700 (PDT) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id ADAF41A914F for ; Wed, 13 May 2015 06:01:21 -0700 (PDT) Received: from [192.168.1.108] (unknown [50.255.148.181]) by lucidvision.com (Postfix) with ESMTP id 8013F3492042; Wed, 13 May 2015 09:01:20 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Thomas D. Nadeau" In-Reply-To: <5552F457.2040002@cisco.com> Date: Wed, 13 May 2015 09:01:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5552F457.2040002@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.2098) Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Next NETMOD chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 13:01:27 -0000 Welcome Kent! > On May 13, 2015:2:51 AM, at 2:51 AM, Benoit Claise = wrote: >=20 > Dear all, >=20 > As you probably know from a previous message to the list, J=C3=BCrgen = announced his plans to step down as co-chair. > Please welcome Kent Watsen, who has accepted to serve as NETMOD = co-chair. > As agreed with J=C3=BCrgen, the NETMOD WG will run with three chairs = until the YANG 1.1 work is completed. > That important YANG 1.1 milestone is the point in time J=C3=BCrgen = decided to pass the baton. >=20 > Thanks to Kent and J=C3=BCrgen. >=20 > Regards, Benoit >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed May 13 08:32:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEB61B2F7F for ; Wed, 13 May 2015 08:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iCwHygxS9aE for ; Wed, 13 May 2015 08:32:52 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDE31B2F91 for ; Wed, 13 May 2015 08:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2035; q=dns/txt; s=iport; t=1431531123; x=1432740723; h=message-id:date:from:mime-version:to:subject; bh=Trs8gl2ErMJubj0WhAwwSMPaCN1a9/1/o+JHwZNgKmA=; b=R2BW7/b5l3mAxcUrrkam7z3oMZrpUA1860gS1XGOCCMRDEkGwQo3Bl4Q MzIxvCV3J4j/EVsYIqC0nLtr/oGf2RZ4Wkkfnl+32xXis87h2ARo7RkPb u9CV/Oydv7688kkxXPC8XMXDCo9iQeGMh5bb+JFFcZQ4x94yvdBBZ2n9U Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DwBAAebVNV/xbLJq1cg2Nfgx3BcoFYhgADgXUTAQEBAQEBAYEKhBczBEcKHwEdFgsCCwMCAQIBSw0IAQGIKA2mLo9XkjcBAQgBAQEBHpMugUUFln2GSYFjhgCPEyNhgxg8gncBAQE X-IronPort-AV: E=Sophos;i="5.13,421,1427760000"; d="scan'208,217";a="476473646" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 13 May 2015 15:32:01 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4DFW1iP019240 for ; Wed, 13 May 2015 15:32:01 GMT Message-ID: <55536E71.4010007@cisco.com> Date: Wed, 13 May 2015 17:32:01 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/alternative; boundary="------------040909020506030708020900" Archived-At: Subject: [netmod] Consistent Modeling of Operational State Data in YANG -> interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 15:32:54 -0000 This is a multi-part message in MIME format. --------------040909020506030708020900 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, I see this draft (Consistent Modeling of Operational State Data in YANG, http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/) is being discussed in different mailing lists. At this point in time, we should decide once for all on how to model the operational state, and provide guidance in draft-ietf-netmod-rfc6087bis-02 . What's in stake is the consistency of future YANG models. I would like to propose a NETMOD interim meeting only dedicated to that topic. Let me work with the WG chairs on how to make it happen. Regards, Benoit --------------040909020506030708020900 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

I see this draft (Consistent Modeling of Operational State Data in YANG, http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/) is being discussed in different mailing lists.

At this point in time, we should decide once for all on how to model the operational state, and provide guidance in draft-ietf-netmod-rfc6087bis-02. What's in stake is the consistency of future YANG models.

I would like to propose a NETMOD interim meeting only dedicated to that topic.
Let me work with the WG chairs on how to make it happen.

Regards, Benoit

--------------040909020506030708020900-- From nobody Wed May 13 09:26:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53EC1A8A84; Wed, 13 May 2015 09:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKUS6xKe1b2K; Wed, 13 May 2015 09:26:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073211A88FF; Wed, 13 May 2015 09:26:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSM49135; Wed, 13 May 2015 16:26:31 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 17:26:31 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Wed, 13 May 2015 09:26:21 -0700 From: Linda Dunbar To: Dacheng Zhang , "i2nsf@ietf.org" , "sacm@ietf.org" Thread-Topic: secure communication channel to exchange security policy and monitor execution status for I2NSF (was RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQjTCk1xjNa7wv+UGGDcLStnhTlZ16Fx/w Date: Wed, 13 May 2015 16:26:21 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C1443C@dfweml701-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: [netmod] secure communication channel to exchange security policy and monitor execution status for I2NSF (was RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:26:39 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGEgQ2hlbmcsDQoNCg0KWW91IHN0YXRlZCB0aGF0IHRoZSBidWxsZXQgZm9yIOKAnFRoZSBwcm9w ZXIgc2VjdXJlIGNvbW11bmljYXRpb24gY2hhbm5lbHMgdG8gY2FycnkgdGhlIHNlY3VyaXR5IHBv bGljaWVzIGJldHdlZW4gQ29udHJvbGxlciBhbmQgTlNGc+KAnSAgaXMgdHJpdmlhbC4gQnV0DQpT QUNNIGlzIGNvbnNpZGVyaW5nIHVzaW5nIFhNUFAgdG8gZXhjaGFuZ2UgZGF0YSBhbW9uZyBlbmQg ZGV2aWNlcyAoaW5zdGVhZCBvZiBORVRDT05GKTogc2VlICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1zYWxvd2V5LXNhY20teG1wcC1ncmlkLw0KDQoNClNvIHRoZXJlIG1p Z2h0IGJlIG1vcmUgdGhhbiBzaW1wbGUgTkVUQ09ORiwgbWF5IGJlIFRMUyAreHh4IGhhdmUgdG8g YmUgY29uc2lkZXJlZC4NCg0KTGluZGENCg0KRnJvbTogRGFjaGVuZyBaaGFuZyBbbWFpbHRvOmRh Y2hlbmcuemRjQGFsaWJhYmEtaW5jLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1heSAxMiwgMjAxNSAx MDo1NSBQTQ0KVG86IExpbmRhIER1bmJhcjsgaTJuc2ZAaWV0Zi5vcmc7IEthdGhsZWVuIE1vcmlh cnR5DQpDYzogaTJyc0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2luZyB0aGUgSTJOU0Ygc2NvcGU6IHRo ZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5Mw0KDQpIae+8jExpbmRhOg0KDQpJIGxpa2UgdGhlIGN1 cnJlbnQgdmVyc2lvbiBvZiBjaGFydGVyLCB3aGljaCBjbGFyaWZpZXMgYSByZWFzb25hYmxlIHNj b3BlIG9mIHRoaXMgd29yay4gU29tZSB0aW55IGNvbW1lbnRzLg0KDQoNClRoZSBjb25jcmV0ZSB3 b3JrIGF0IHRoZSBMMk5TRiBDYXBhYmlsaXR5IExheWVyIGluY2x1ZGVzDQoNCi0gICAgICAgICAg VGhlIGluZm9ybWF0aW9uYWwgJiBkYXRhIG1vZGVscyBmb3IgZWFjaCBjYXRlZ29yeSB0byBiZSBy ZXByZXNlbnRlZCB0byB2aXJ0dWFsIG9yIHBoeXNpY2FsIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rp b25zLA0KDQotICAgICAgICAgIFRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBvZiBwb2xp Y3kgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBmdW5jdGlv biwgYW5kDQoNCi0gICAgICAgICAgVGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFu bmVscyB0byBjYXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9sbGVyIGFu ZCBOU0ZzLg0KDQoNCg0KPj5EYWNoZW5nOiB0aGUgdGhpcmQgYnVsbGV0IGlzIHF1aXRlIHRyaXZh bCBjb21wYXJlZCB3aXRoIHRoZSBmaXJzdCB0d28gYnVsbGV0cywgc2luY2Ugd2Ugd2lsbCB0cnkg dG8gcmUtdXNlIHRoZSB3b3JrIG9mIEkyUlMsTmV0Y29uZiB3aGVyZSB0aGUgZ2VuZXJhdGlvbiBv ZiBzZWN1cml0eSBjaGFubmVscyBoYXZlIGFscmVhZHkgY29uc2lkZXJlZC4gIFNvLCBtYXliZSB3 ZSBjb3VsZCByZW1vdmUgaXQuDQoNClRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IGlzIHRvIG1ha2Ug aXQgZmVhc2libGUgdG8gY2F0ZWdvcml6ZSBuZXR3b3JrIHNlY3VyaXR5IGZ1bmN0aW9ucyBwcm92 aWRlZCBieSBkaWZmZXJlbnQgdmVuZG9ycyBiYXNlZCBvbiBzZWN1cml0eSBwb2xpY3kgcHJvdmlz aW9uaW5nIGNhcGFiaWxpdHkgd2l0aG91dCBhbnkgbmVlZCB0byBzdGFuZGFyZGl6ZSBzZWN1cml0 eSBmdW5jdGlvbnMgdGhlbXNlbHZlcy4gIFN0YW5kYXJkIHByb3Zpc2lvbmluZyBjYXBhYmlsaXR5 IGludGVyZmFjZSBpcyBhbiBlc3NlbnRpYWwgYnVpbGRpbmcgYmxvY2sgZm9yIFNlY3VyaXR5IFNl cnZpY2UgUHJvdmlkZXIgdG8gYXV0b21hdGUgdGhlaXIgU2VjdXJpdHkgQ29udHJvbGxlcnMgdGhh dCBjYW4gdXRpbGl6ZSBOU0YgYnkgbXVsdGlwbGUgdmVuZG9ycy4gVGhpcyBsYXllciB3aWxsIGxl dmVyYWdlIHRoZSBleGlzdGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGRlZmluZWQgYnkg STJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRC4NCg0KPj5EYWNoZW5nOiBJIHN1Z2dlc3QgdG8gY2hh bmdlIHRoZSBsYXN0IHNlbnRlbmNlIHRvIOKAnEluIHRoaXMgbGF5ZXIsIHdlIHdpbGwgbGV2ZXJh Z2UgdGhlIGV4aXN0aW5nIHByb3RvY29scyBhbmQgZGF0YSBtb2RlbHMgZGVmaW5lZCBieSBJMlJT LCBOZXRjb25mLCBhbmQgTkVUTU9EIGFzIG11Y2ggYXMgcG9zc2libGUu4oCdDQoNClNpbWlsYXIg dG8gSTJSUyBmb2N1c2luZyBvbiB0aGUgaW50ZXJmYWNlIHRvIFJJQi9GSUIgZXZlbiB0aG91Z2gg bW9zdCByb3V0ZXJzIHByb3ZpZGUgZmFyIG1vcmUgZnVuY3Rpb25zIHRoYW4gUklCL0ZJQiwgdGhl IEkyTlNGIGZvY3VzZWQgZnVuY3Rpb25zIGNhbiBiZSBhIHBvcnRpb24gb2YgZmVhdHVyZXMgc3Vw cG9ydGVkIGJ5IHZlbmRvcnPigJkgc3BlY2lmaWMgZGV2aWNlcy4NCg0KPj5EYWNoZW5nOiB0aGUg Zmlyc3QgcGFydCBvZiB0aGlzIHNlbnRlbmNlIGlzIHJlZHVuZGFudC4gV2UgZG9u4oCZdCBoYXZl IHRvIGltcGx5IHRoYXQg4oCcd2Ugd29yayBpbiB0aGlzIHdheSBiZWNhdXNlIEkyUlMgdXNlZCB0 byBkbyBzaW1pbGFyIHRoaW5ncy4gU28gaWYgeW91IHdhbnQgdG8gY2hhbGxlbmdlIHVzLCBwbGVh c2UgY2hhbGxlbmdlIEkyUlMgZmlyc3TigJ0uIE1heWJlIHdlIGNvdWxkIHJlbW92ZSBpdC4NCg0K 5Y+R5Lu25Lq6OiBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPG1haWx0bzps aW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+DQrml6XmnJ86IDIwMTXlubQ15pyIN+aXpSDmmJ/mnJ/l m5sg5LiL5Y2IMTE6NTMNCuiHszogImkybnNmQGlldGYub3JnPG1haWx0bzppMm5zZkBpZXRmLm9y Zz4iIDxpMm5zZkBpZXRmLm9yZzxtYWlsdG86aTJuc2ZAaWV0Zi5vcmc+PiwgS2F0aGxlZW4gTW9y aWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPG1haWx0bzprYXRobGVlbi5t b3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+DQrmioTpgIE6ICJpMnJzQGlldGYub3JnPG1haWx0bzpp MnJzQGlldGYub3JnPiIgPGkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+PiwgImRv dHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+IiA8ZG90c0BpZXRmLm9yZzxtYWlsdG86 ZG90c0BpZXRmLm9yZz4+LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0K5Li76aKYOiBbSTJu c2ZdIEZ1cnRoZXIgTmFycm93aW5nIHRoZSBJMk5TRiBzY29wZTogdGhlIG5ldyBjaGFydGVyIGZv ciBJRVRGIDkzDQoNClRoYW5rcyB0byBJMk5TRiBjb250cmlidXRvcnMgZm9yIHRoZSBnb29kIHBy b2dyZXNzZXMgbWFkZSBzaW5jZSAgSUVURjkyIHNpZGUgbWVldGluZ3MuIEFtb25nIHRoZSB0d28g STJOU0YgaW50ZXJmYWNlcywgIGkuZS4gdGhlIGNsaWVudCBmYWNpbmcgU2VydmljZSBJbnRlcmZh Y2UgYW5kIHRoZSBOU0YgZmFjaW5nIENhcGFiaWxpdHkgSW50ZXJmYWNlLCB0aGUgd29yayB0byBi ZSBkb25lIGF0IHRoZSBDYXBhYmlsaXR5IEludGVyZmFjZSBiZWNvbWVzIHZlcnkgY2xlYXIgYW5k IGNvbmNyZXRlLiBCdXQgdGhlIFNlcnZpY2UgSW50ZXJmYWNlIGlzIHN0aWxsIGEgbGl0dGxlIHZh Z3VlLg0KDQpUaGUgZmVlZGJhY2sgZnJvbSBsYXN0IElFVEYgc2lkZSBtZWV0aW5ncyB3YXMgInRo ZSBzY29wZSBpcyB0b28gYmlnIGZvciBvbmUgSUVURiBXRyIuIFRoZXJlZm9yZSwgd2UgYXJlIGxl YW5pbmcgdG93YXJkcyBuYXJyb3dpbmcgdGhlIEkyTlNGIHNjb3BlIHRvIHRoZSBDYXBhYmlsaXR5 IEludGVyZmFjZS4gVGhlIHRoaW5raW5nIGxvZ2ljIGlzOiBPbmNlIHRoZSBDYXBhYmlsaXR5IElu dGVyZmFjZSBpcyBjb21wbGV0ZWQsIHdlIHdpbGwgc2VlIG1vcmUgY2xlYXJseSB0aGUgd29yayBm b3IgU2VydmljZSBpbnRlcmZhY2UuIEV2ZW4gaWYgQ2FwYWJpbGl0eSBsYXllciBhbG9uZSBpcyBz dGFuZGFyZGl6ZWQsIGl0IGlzIGEgZ2lhbnQgbGVhcCBmb3J3YXJkIGluIGJ1aWxkaW5nIGJsb2Nr cyBmb3IgU2VydmljZSBQcm92aWRlciB0byBhdXRvbWF0ZSB0aGVpciBTZWN1cml0eSBDb250cm9s bGVyIHRoYXQgY2FuIHV0aWxpemUgTlNGIGJ5IG11bHRpcGxlIHZlbmRvcnMNCg0KSGVyZSBpcyB0 aGUgbmFycm93ZXIgc2NvcGVkIEkyTlNGIGNoYXJ0ZXIuIFlvdXIgY29tbWVudHMgYW5kIHN1Z2dl c3Rpb25zIGFyZSBncmVhdGx5IGFwcHJlY2lhdGVkLiBDQ+KAmWVkIHRvIERPVFMsIEkyUlMsIGFu ZCBOZXRtb2QgZ3JvdXBzIGZvciB3aWRlciByZXZpZXcuDQoNCg0KDQpFbnRlcnByaXNlcywgcmVz aWRlbnRpYWwsIGFuZCBtb2JpbGUgY3VzdG9tZXJzIGFyZSBpbmNyZWFzaW5nbHkgY29uc3VtaW5n IG5ldHdvcmsgZnVuY3Rpb25zLCBlc3BlY2lhbGx5IG5ldHdvcmsgc2VjdXJpdHkgcmVsYXRlZCBm dW5jdGlvbnMgdGhhdCBhcmUgbm90IHJ1bm5pbmcgb24gdGhlaXIgcHJlbWlzZXMuICBJbiBhZGRp dGlvbiwgdGhlIEV1cm9wZWFuIFRlbGVjb21tdW5pY2F0aW9ucyBTdGFuZGFyZHMgSW5zdGl0dXRl IChFVFNJKSBOZXR3b3JrIEZ1bmN0aW9uIFZpcnR1YWxpemF0aW9uIChORlYpIGluaXRpYXRpdmUg Y3JlYXRlcyBuZXcgbWFuYWdlbWVudCBjaGFsbGVuZ2VzIGZvciBzZWN1cml0eSBwb2xpY2llcyB0 byBiZSBlbmZvcmNlZCBieSBkaXN0cmlidXRlZCwgdmlydHVhbCwgbmV0d29yayBzZWN1cml0eSBm dW5jdGlvbnMgKHZOU0YpLiBXaXRob3V0IHN0YW5kYXJkIGludGVyZmFjZSB0byBleHByZXNzLCBt b25pdG9yLCBhbmQgbWFuYWdlIHNlY3VyaXR5IHBvbGljaWVzIHRvIHNlY3VyaXR5IGZ1bmN0aW9u cyBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcHJlbWlzZXMsIGl0IGJlY29tZXMgdmlydHVhbGx5IGlt cG9zc2libGUgZm9yIHNlY3VyaXR5IHNlcnZpY2UgcHJvdmlkZXJzIHRvIGF1dG9tYXRlIHRoZSBz ZXJ2aWNlIG9mZmVyaW5nIHV0aWxpemluZyBzZWN1cml0eSBmdW5jdGlvbnMgYnkgbXVsdGlwbGUg dmVuZG9ycy4NCg0KVGhlIHVsdGltYXRlIGdvYWwgb2YgSTJOU0YgaXMgdG8gZW5hYmxlIGVudGVy cHJpc2VzIHRvIHV0aWxpemUgc2VjdXJpdHkgZnVuY3Rpb25zIG5vdCBob3N0ZWQgb24gdGhlaXIg b3duIHByZW1pc2VzIGJ1dCBpbnN0ZWFkIGhvc3RlZCBpbiBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFp biwgdG8gZXN0YWJsaXNoIGhvdyB0byBjb21tdW5pY2F0ZSBkZXNpcmVkIHNlY3VyaXR5IHBvbGlj aWVzIHRvIE5TRiBhbmQgaG93IHRvIGdldCBwZXJmb3JtYW5jZSBkYXRhIG9yIHJlcG9ydCBvdXQg b2YgTlNGIG9yIHZOU0YuDQoNClRoZXJlIGFyZSB0d28gbGF5ZXJzIG9mIGludGVyZmFjZXM6DQoN Ci0gICAgICAgICAgU2VjdXJpdHkgUG9saWNpZXMgZmFjaW5nIHNlY3VyaXR5IGZ1bmN0aW9ucyAo STJOU0YgQ2FwYWJpbGl0eSBMYXllcikNCg0KLSAgICAgICAgICBTZWN1cml0eSBQb2xpY2llcyBm YWNpbmcgY2xpZW50cyAoSTJOU0YgU2VydmljZSBMYXllcikNCg0KVGhlIEkyTlNGIENhcGFiaWxp dHkgTGF5ZXIgc3BlY2lmaWVzIHRoZSBmdW5jdGlvbmFsIHNlY3VyaXR5IHBvbGljaWVzLCB3aGlj aCBhcmUgdHJhbnNsYXRlZCBmcm9tIHRoZSBjbGllbnQgc2VjdXJpdHkgcG9saWNpZXMsIHRvIHNl Y3VyaXR5IGZ1bmN0aW9ucy4gSTJOU0Ygd2lsbCBOT1Qgc3RhbmRhcmRpemUgc2VjdXJpdHkgZnVu Y3Rpb25zIG9yIGRldmljZXMuIEluc3RlYWQsIEkyTlNGIGlzIG9ubHkgdG8gc3RhbmRhcmRpemUg dGhlIHBvbGljeSBwcm92aXNpb25pbmcgdG8gdGhlIHNlY3VyaXR5IGZ1bmN0aW9ucyAobm90IGRl dmljZXMpLCBpbiB0aGUgZm9ybSBvZiDigJxTdWJqZWN0IOKAkyBPYmplY3Qg4oCTIEZ1bmN0aW9u IOKAkyBBY3Rpb27igJ0gcGFyYWRpZ20uDQoNClRoZSBJMk5TRiBTZXJ2aWNlIExheWVyIGlzIGZv ciBjbGllbnRzIHRvIGV4cHJlc3MgYW5kIG1vbml0b3Igc2VjdXJpdHkgcG9saWNpZXMgZm9yIHRo ZWlyIHNwZWNpZmljIGZsb3dzLCB3aGljaCBpcyB1c3VhbGx5IGJhc2VkIG9uIGN1c3RvbWVyc+KA mSBsb2dpY2FsIG5ldHdvcmtzLCBhZGRyZXNzZXMgYW5kIGNvbnRleHQuIEkyTlNGIFNlcnZpY2Ug TGF5ZXIgY2FuIGFsc28gYmUgc2VjdXJpdHkgZXhwZWN0YXRpb24gb3IgbG9vc2Ugc2VjdXJpdHkg cmVxdWlyZW1lbnQsIGVzcGVjaWFsbHkgZm9yIGN1c3RvbWVycyB3aG8gZG9u4oCZdCBoYXZlIHRo ZSBzZWN1cml0eSBleHBlcnRpc2UuDQoNClRoZSBjb25jcmV0ZSB3b3JrIGF0IHRoZSBMMk5TRiBD YXBhYmlsaXR5IExheWVyIGluY2x1ZGVzDQoNCi0gICAgICAgICAgVGhlIGluZm9ybWF0aW9uYWwg JiBkYXRhIG1vZGVscyBmb3IgZWFjaCBjYXRlZ29yeSB0byBiZSByZXByZXNlbnRlZCB0byB2aXJ0 dWFsIG9yIHBoeXNpY2FsIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rpb25zLA0KDQotICAgICAgICAg IFRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBvZiBwb2xpY3kgcHJvdmlzaW9uaW5nIGNh cGFiaWxpdHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBmdW5jdGlvbiwgYW5kDQoNCi0gICAgICAg ICAgVGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFubmVscyB0byBjYXJyeSB0aGUg c2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9sbGVyIGFuZCBOU0ZzLg0KVGhlIGNhcGFi aWxpdHkgcmVnaXN0cnkgaXMgdG8gbWFrZSBpdCBmZWFzaWJsZSB0byBjYXRlZ29yaXplIG5ldHdv cmsgc2VjdXJpdHkgZnVuY3Rpb25zIHByb3ZpZGVkIGJ5IGRpZmZlcmVudCB2ZW5kb3JzIGJhc2Vk IG9uIHNlY3VyaXR5IHBvbGljeSBwcm92aXNpb25pbmcgY2FwYWJpbGl0eSB3aXRob3V0IGFueSBu ZWVkIHRvIHN0YW5kYXJkaXplIHNlY3VyaXR5IGZ1bmN0aW9ucyB0aGVtc2VsdmVzLiAgU3RhbmRh cmQgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgaW50ZXJmYWNlIGlzIGFuIGVzc2VudGlhbCBidWls ZGluZyBibG9jayBmb3IgU2VjdXJpdHkgU2VydmljZSBQcm92aWRlciB0byBhdXRvbWF0ZSB0aGVp ciBTZWN1cml0eSBDb250cm9sbGVycyB0aGF0IGNhbiB1dGlsaXplIE5TRiBieSBtdWx0aXBsZSB2 ZW5kb3JzLiBUaGlzIGxheWVyIHdpbGwgbGV2ZXJhZ2UgdGhlIGV4aXN0aW5nIHByb3RvY29scyBh bmQgZGF0YSBtb2RlbHMgZGVmaW5lZCBieSBJMlJTLCBOZXRjb25mLCBhbmQgTkVUTU9ELg0KDQpG b3IgdGhlIEkyTlNGIFNlcnZpY2UgTGF5ZXIsIGl0IGlzIG91dCBvZiB0aGUgc2NvcGUgZm9yIEky TlNGIChhdCBsZWFzdCBmb3Igbm93KSB0byBzdGFuZGFyZGl6ZSB0aGUgaW50ZXJmYWNlIGZhY2lu ZyBjbGllbnRzLiBIb3dldmVyLCBJMk5TRiBjYW4gaGF2ZSBpbmZvcm1hdGlvbmFsIGRyYWZ0cyBz aG93aW5nIHNhbXBsZSBBUElzIG9yL2FuZCBSRVNUZnVsIGludGVyZmFjZXMgdG8gY2xpZW50cyBh bmQgZGVtb25zdHJhdGluZyB0aGUgZmVhc2liaWxpdHkgb2YgdGhlbSBiZWluZyB0cmFuc2xhdGVk IHRvIHRoZSBDYXBhYmlsaXR5IExheWVyIHBvbGljaWVzLg0KDQpTaW5jZSBkaWZmZXJlbnQgc2Vj dXJpdHkgdmVuZG9ycyBzdXBwb3J0IGRpZmZlcmVudCBmZWF0dXJlcyAmIGZ1bmN0aW9ucyBvbiB0 aGVpciBkZXZpY2VzLCBJMk5TRiB3aWxsIGZvY3VzIG9uIGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVu Y3Rpb25zIHRoYXQgcHJvdmlkZSB0cmVhdG1lbnQgdG8gcGFja2V0cy9mbG93cywgc3VjaCBhcyBJ UFMvSURTLCBXZWIgZmlsdGVyLCBhbmQgZmxvdyBmaWx0ZXIuIChUaGV5IGFyZSBkaWZmZXJlbnQg ZnJvbSBvdGhlciBzZWN1cml0eSBmdW5jdGlvbnMgc3VjaCBhcyBBdXRoZW50aWNhdGlvbiwgQXV0 aG9yaXphdGlvbiwgb3IgRW5jcnlwdGlvbikuIEV4ZW1wbGFyIHNlcnZpY2VzIGFzc29jaWF0ZWQg d2l0aCBGbG93IEJhc2VkIFNlY3VyaXR5IGZ1bmN0aW9ucyBpbmNsdWRlIGRlZXAgcGFja2V0IGlu c3BlY3Rpb24sIHBhY2tldC9mbG93L3N0cmVhbSBmaWx0ZXJpbmcgb3IgcGF0dGVybiBtYXRjaGlu ZyBhbmQgcmVtZWRpYXRpb24sIGV0Yy4NCg0KU2ltaWxhciB0byBJMlJTIGZvY3VzaW5nIG9uIHRo ZSBpbnRlcmZhY2UgdG8gUklCL0ZJQiBldmVuIHRob3VnaCBtb3N0IHJvdXRlcnMgcHJvdmlkZSBm YXIgbW9yZSBmdW5jdGlvbnMgdGhhbiBSSUIvRklCLCB0aGUgSTJOU0YgZm9jdXNlZCBmdW5jdGlv bnMgY2FuIGJlIGEgcG9ydGlvbiBvZiBmZWF0dXJlcyBzdXBwb3J0ZWQgYnkgdmVuZG9yc+KAmSBz cGVjaWZpYyBkZXZpY2VzLg0KDQpJdCBpcyBhIG5vbi1nb2FsIHRvIGNyZWF0ZSBuZXcgcHJvdG9j b2xzIG9yIGRhdGEgbW9kZWxpbmcgbGFuZ3VhZ2VzIGZvciBJMk5TRiBpbnRlcmZhY2VzLg0KSTJO U0YgV0cgRGVsaXZlcmFibGVzIGluY2x1ZGU6DQoNCg0KLSAgICAgICAgICAgVXNlIENhc2UgZG9j dW1lbnQuDQoNCi0gICAgICAgICAgRnJhbWV3b3JrIERvY3VtZW50Lg0KDQotICAgICAgICAgIFJl cXVpcmVtZW50IGZvciBleHRlbnNpb25zIChpZiB0aGVyZSBhcmUgYW55KSB0byBleGlzdGluZyBw cm90b2NvbHMgdXNlZCBieSB0aGUgV0cuDQoNCi0gICAgICAgICAgIEdhcCBhbmFseXNpcyBvZiBl eGlzdGluZyBwcm90b2NvbHMgYW5kIG1vZGVsaW5nIGxhbmd1YWdlcw0KDQotICAgICAgICAgIEEg c2luZ2xlLCB1bmlmaWVkLCBJbmZvcm1hdGlvbiBNb2RlbCBmb3IgZXhwcmVzc2luZyBwb2xpY2ll cyB0byB0aGUgRmxvdyBCYXNlZCBTZWN1cml0eSBGdW5jdGlvbnMgZGVzY3JpYmVkIGFib3ZlLg0K DQotICAgICAgICAgIENvcnJlc3BvbmRpbmcgRGF0YSBNb2RlbHMgKGUuZy4gWUFORyBtb2RlbHMp IGRlcml2ZWQgZnJvbSB0aGUgYWJvdmUgSW5mb3JtYXRpb24gTW9kZWwuDQoNCi0gICAgICAgICAg SUFOQSByZWdpc3RyeSBjb25zaWRlcmF0aW9uIGZvciBmbG93IGJhc2VkIHNlY3VyaXR5IGZ1bmN0 aW9uIHBvbGljeSBwcm92aXNpb25pbmcgY2FwYWJpbGl0eS4NCg0KLSAgICAgICAgICAgKE9wdGlv bmFsbHkpIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50cyBvbiBob3cgdG8gdXNlIEkyUlMsIE5ldGNv bmYsIGFuZCBORVRNT0QgdG8gY2FycnkgdGhlIGNvbnRlbnQgb2YgdGhlIHNwZWNpZmllZCBpbmZv cm1hdGlvbi9kYXRhIG1vZGVscy4NCg0KW1RoZSBXRyBtYXkgZGVjaWRlIHRoYXQgdGhlIFVzZSBj YXNlcywgRnJhbWV3b3JrLCBhbmQgUmVxdWlyZW1lbnQgYXJlIEluZm9ybWF0aW9uYWwgZG9jdW1l bnRzIG9yIHNpbXBseSByZWZlcmVuY2UgZG9jdW1lbnRzIGR1cmluZyB0aGUgbGlmZXRpbWUgb2Yg dGhlIFdHLiBUaGUgZnJhbWV3b3JrLCB0aGF0IGRlc2NyaWJlcyB0aGUgZnVuY3Rpb25hbCBjb21w b25lbnRzIGFuZCB0aGUgSTJOU0Ygd29yayBpdGVtcywgaXMgdG8gbWFrZSBJMk5TRiB3b3JrIG1v cmUgb3JnYW5pemVkLl0NCg0KU3VnZ2VzdGVkIE1pbGVzdG9uZXMNCiAgLSBVc2UgQ2FzZSBEb2N1 bWVudDogIENoYXJ0ZXIgdGltZSArIDEgbW9udGggdG8gV0cgRG9jdW1lbnQNCiAgLSBGcmFtZXdv cms6IENoYXJ0ZXIgdGltZSArIDQgbW9udGhzIHRvIFdHIERvY3VtZW50DQogIC0gUmVxdWlyZW1l bnRzIGZvciBleHRlbnNpb25zIHRvIHByb3RvY29sczogIENoYXJ0ZXIgdGltZSArIDYgbW9udGhz IHRvIFdHIGRvY3VtZW50DQogIC0gSW5mbyBtb2RlbDogQ2hhcnRlciB0aW1lICsgNyBtb250aHMg dG8gV0cgRG9jdW1lbnQNCiAgLSBJQU5BIHJlZ2lzdHJ5IGNvbnNpZGVyYXRpb24gKyAxMCBtb250 aHMgdG8gV0cgRG9jdW1lbnQNCiAgLSBBbGwgRWFybHkgRHJhZnRzIHRvIElFU0c6IDEwIG1vbnRo cw0KDQpbZGVjaXNpb24gcG9pbnQg4oCTICsxMCBtb250aHNdDQogIC0gRGF0YSBNb2RlbHM6IENo YXJ0ZXIgKyA5IE1vbnRocyB0byBXRyBEb2N1bWVudA0KICAtIEFwcGxpY2FiaWxpdHkgU3RhdGVt ZW50czogMTAgbW9udGhzIHRvIFdHIERvY3VtZW50DQogIC0gRGF0YSBNb2RlbHMgYW5kIEFwcGxp Y2FiaWxpdHkgU3RhdGVtZW50cyB0byBJRVNHICAtIDE2IG1vbnRocw0KDQpUaGUgV0cgd2lsbCB3 b3JrIGNsb3NlbHkgd2l0aCBJMlJTLCBOZXRjb25mIGFuZCBOZXRtb2QgV0dzLiBUaGUgV0cgd2ls bCBjb21tdW5pY2F0ZSB3aXRoIGV4dGVybmFsIFNET3MgbGlrZSBFVFNJIE5GViBhbmQgd2lsbCBl bmNvdXJhZ2Ugb3BlbiBzb3VyY2UgY29kZSBkZXZlbG9wbWVudCByZWxhdGVkIHRvIHRoZSBXRyBz Y29wZSBpbiBvcmdhbml6YXRpb25zIGxpa2UgT05GLCBPcGVuU3RhY2ssIE9ETCwgYW5kIE9wZW5O RlYuDQoNCg0KQ2hlZXJzLA0KTGluZGEgRHVuYmFyDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBJMm5zZiBtYWlsaW5nIGxpc3QgSTJuc2ZAaWV0Zi5vcmc8 bWFpbHRvOkkybnNmQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2kybnNmDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk65a6L5L2TO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3Vu IjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFy YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsN CgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTg2MzA2NTcy Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTYxNTk5 ODIyIDE5ODI2NjA0MzYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMi41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 MTU1MDYwNjg1NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MTMxMTkxOTA3MiAyMTMzMDcwMzI2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MjIuNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5EYSBDaGVuZywgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3Rl eHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPllvdSBzdGF0ZWQg dGhhdCB0aGUgYnVsbGV0IGZvciDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtjb2xvcjpibGFjayI+VGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFubmVscyB0 byBjYXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2Vlbg0KIENvbnRyb2xsZXIgYW5kIE5T RnPigJ0gPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDtpcyB0cml2aWFs LiBCdXQgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNBQ00gaXMgY29uc2lkZXJpbmcgdXNpbmcgWE1QUCB0byBl eGNoYW5nZSBkYXRhIGFtb25nIGVuZCBkZXZpY2VzIChpbnN0ZWFkIG9mIE5FVENPTkYpOiBzZWUN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zYWxvd2V5LXNh Y20teG1wcC1ncmlkLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2Fs b3dleS1zYWNtLXhtcHAtZ3JpZC88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TbyB0aGVyZSBtaWdodCBi ZSBtb3JlIHRoYW4gc2ltcGxlIE5FVENPTkYsIG1heSBiZSBUTFMgJiM0Mzt4eHggaGF2ZSB0byBi ZSBjb25zaWRlcmVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5MaW5k YSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBEYWNoZW5nIFpoYW5nIFttYWlsdG86ZGFjaGVuZy56ZGNAYWxpYmFiYS1pbmMuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAxMiwgMjAxNSAxMDo1NSBQTTxicj4N CjxiPlRvOjwvYj4gTGluZGEgRHVuYmFyOyBpMm5zZkBpZXRmLm9yZzsgS2F0aGxlZW4gTW9yaWFy dHk8YnI+DQo8Yj5DYzo8L2I+IGkycnNAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmc7IG5ldG1vZEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2lu ZyB0aGUgSTJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5MzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+SGk8L3NwYW4+ PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6U2lt U3VuO2NvbG9yOmJsYWNrIj7vvIw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkxpbmRhOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj5JIGxpa2Ug dGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBjaGFydGVyLCB3aGljaCBjbGFyaWZpZXMgYSByZWFzb25h YmxlIHNjb3BlIG9mIHRoaXMgd29yay4gU29tZSB0aW55IGNvbW1lbnRzLiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBjb25j cmV0ZSB3b3JrIGF0IHRoZSBMMk5TRiBDYXBhYmlsaXR5IExheWVyIGluY2x1ZGVzPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIy LjVwdDt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29s b3I6YmxhY2siPi0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtUaGUgaW5mb3JtYXRpb25hbCAmYW1wOyBkYXRhIG1vZGVscyBmb3IgZWFj aCBjYXRlZ29yeSB0byBiZSByZXByZXNlbnRlZCB0byB2aXJ0dWFsIG9yIHBoeXNpY2FsIG5ldHdv cmsgc2VjdXJpdHkgZnVuY3Rpb25zLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0u MjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+LSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBj YXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBvZiBwb2xpY3kgcHJvdmlzaW9uaW5nIGNhcGFiaWxp dHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBmdW5jdGlvbiwgYW5kPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41 cHQ7dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OmJsYWNrIj4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7VGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFubmVscyB0byBj YXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9sbGVyIGFuZCBOU0ZzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41cHQ7dGV4dC1p bmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4m Z3Q7Jmd0O0RhY2hlbmc6IHRoZSB0aGlyZCBidWxsZXQgaXMgcXVpdGUgdHJpdmFsIGNvbXBhcmVk IHdpdGggdGhlIGZpcnN0IHR3byBidWxsZXRzLCBzaW5jZSB3ZSB3aWxsIHRyeSB0byByZS11c2Ug dGhlIHdvcmsgb2YgSTJSUyxOZXRjb25mIHdoZXJlIHRoZQ0KIGdlbmVyYXRpb24gb2Ygc2VjdXJp dHkgY2hhbm5lbHMgaGF2ZSBhbHJlYWR5IGNvbnNpZGVyZWQuICZuYnNwO1NvLCBtYXliZSB3ZSBj b3VsZCByZW1vdmUgaXQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IGlzIHRvIG1ha2UgaXQg ZmVhc2libGUgdG8gY2F0ZWdvcml6ZSBuZXR3b3JrIHNlY3VyaXR5IGZ1bmN0aW9ucyBwcm92aWRl ZCBieSBkaWZmZXJlbnQgdmVuZG9ycyBiYXNlZCBvbiBzZWN1cml0eSBwb2xpY3kgcHJvdmlzaW9u aW5nDQogY2FwYWJpbGl0eSB3aXRob3V0IGFueSBuZWVkIHRvIHN0YW5kYXJkaXplIHNlY3VyaXR5 IGZ1bmN0aW9ucyB0aGVtc2VsdmVzLiAmbmJzcDtTdGFuZGFyZCBwcm92aXNpb25pbmcgY2FwYWJp bGl0eSBpbnRlcmZhY2UgaXMgYW4gZXNzZW50aWFsIGJ1aWxkaW5nIGJsb2NrIGZvciBTZWN1cml0 eSBTZXJ2aWNlIFByb3ZpZGVyIHRvIGF1dG9tYXRlIHRoZWlyIFNlY3VyaXR5IENvbnRyb2xsZXJz IHRoYXQgY2FuIHV0aWxpemUgTlNGIGJ5IG11bHRpcGxlIHZlbmRvcnMuDQogVGhpcyBsYXllciB3 aWxsIGxldmVyYWdlIHRoZSBleGlzdGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGRlZmlu ZWQgYnkgSTJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZndDsmZ3Q7RGFjaGVuZzogSSBzdWdnZXN0IHRvIGNoYW5nZSB0aGUgbGFz dCBzZW50ZW5jZSB0byDigJxJbiB0aGlzIGxheWVyLCB3ZSB3aWxsIGxldmVyYWdlIHRoZSBleGlz dGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGRlZmluZWQgYnkgSTJSUywgTmV0Y29uZiwg YW5kDQogTkVUTU9EIGFzIG11Y2ggYXMgcG9zc2libGUu4oCdPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5TaW1pbGFyIHRvIEkyUlMgZm9jdXNpbmcgb24gdGhlIGludGVyZmFj ZSB0byBSSUIvRklCIGV2ZW4gdGhvdWdoIG1vc3Qgcm91dGVycyBwcm92aWRlIGZhciBtb3JlIGZ1 bmN0aW9ucyB0aGFuIFJJQi9GSUIsIHRoZSBJMk5TRiBmb2N1c2VkIGZ1bmN0aW9ucyBjYW4NCiBi ZSBhIHBvcnRpb24gb2YgZmVhdHVyZXMgc3VwcG9ydGVkIGJ5IHZlbmRvcnPigJkgc3BlY2lmaWMg ZGV2aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7RGFj aGVuZzogdGhlIGZpcnN0IHBhcnQgb2YgdGhpcyBzZW50ZW5jZSBpcyByZWR1bmRhbnQuIFdlIGRv buKAmXQgaGF2ZSB0byBpbXBseSB0aGF0Jm5ic3A74oCcd2Ugd29yayBpbiB0aGlzIHdheSBiZWNh dXNlIEkyUlMgdXNlZCB0byBkbyBzaW1pbGFyIHRoaW5ncy4gU28gaWYNCiB5b3Ugd2FudCB0byBj aGFsbGVuZ2UgdXMsIHBsZWFzZSBjaGFsbGVuZ2UgSTJSUyBmaXJzdOKAnS4gTWF5YmUgd2UgY291 bGQgcmVtb3ZlIGl0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1m YW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNr Ij7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bh bj48L2I+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5MaW5kYSBEdW5iYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsaW5kYS5k dW5iYXJAaHVhd2VpLmNvbSI+bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjwv c3Bhbj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xv cjpibGFjayI+5pel5pyfPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjo8 L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+MjAxNTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+NTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OlNpbVN1bjtjb2xvcjpibGFjayI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Nzwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xv cjpibGFjayI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iY29sb3I6YmxhY2si Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2Nv bG9yOmJsYWNrIj7mmJ/mnJ/lm5s8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJjb2xv cjpibGFjayI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpT aW1TdW47Y29sb3I6YmxhY2siPuS4i+WNiDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjExOjUzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjxiPjxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7o h7M8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bhbj48L2I+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mcXVvdDs8YSBocmVmPSJtYWlsdG86aTJuc2ZAaWV0Zi5vcmciPmkybnNmQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmkybnNmQGlldGYub3JnIj5pMm5zZkBp ZXRmLm9yZzwvYT4mZ3Q7LCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmth dGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tIj5rYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdt YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0i Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7mioTpgIE8L3NwYW4+PC9iPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDs8YSBocmVm PSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPiZndDssICZxdW90Ozxh IGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPiZx dW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W0kybnNmXSBGdXJ0aGVyIE5h cnJvd2luZyB0aGUgSTJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5MzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFua3MgdG8gSTJO U0YgY29udHJpYnV0b3JzIGZvciB0aGUgZ29vZCBwcm9ncmVzc2VzIG1hZGUgc2luY2UgJm5ic3A7 SUVURjkyIHNpZGUgbWVldGluZ3MuIEFtb25nIHRoZSB0d28gSTJOU0YgaW50ZXJmYWNlcywgJm5i c3A7aS5lLiB0aGUgY2xpZW50IGZhY2luZyBTZXJ2aWNlIEludGVyZmFjZSBhbmQgdGhlIE5TRiBm YWNpbmcgQ2FwYWJpbGl0eSBJbnRlcmZhY2UsIHRoZSB3b3JrDQogdG8gYmUgZG9uZSBhdCB0aGUg Q2FwYWJpbGl0eSBJbnRlcmZhY2UgYmVjb21lcyB2ZXJ5IGNsZWFyIGFuZCBjb25jcmV0ZS4gQnV0 IHRoZSBTZXJ2aWNlIEludGVyZmFjZSBpcyBzdGlsbCBhIGxpdHRsZSB2YWd1ZS4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgZmVlZGJhY2sgZnJvbSBsYXN0IElFVEYgc2lk ZSBtZWV0aW5ncyB3YXMgJnF1b3Q7dGhlIHNjb3BlIGlzIHRvbyBiaWcgZm9yIG9uZSBJRVRGIFdH JnF1b3Q7LiBUaGVyZWZvcmUsIHdlIGFyZSBsZWFuaW5nIHRvd2FyZHMgbmFycm93aW5nIHRoZSBJ Mk5TRiBzY29wZSB0byB0aGUgQ2FwYWJpbGl0eSBJbnRlcmZhY2UuIFRoZSB0aGlua2luZyBsb2dp YyBpczogT25jZSB0aGUgQ2FwYWJpbGl0eQ0KIEludGVyZmFjZSBpcyBjb21wbGV0ZWQsIHdlIHdp bGwgc2VlIG1vcmUgY2xlYXJseSB0aGUgd29yayBmb3IgU2VydmljZSBpbnRlcmZhY2UuIEV2ZW4g aWYgQ2FwYWJpbGl0eSBsYXllciBhbG9uZSBpcyBzdGFuZGFyZGl6ZWQsIGl0IGlzIGEgZ2lhbnQg bGVhcCBmb3J3YXJkIGluIGJ1aWxkaW5nIGJsb2NrcyBmb3IgU2VydmljZSBQcm92aWRlciB0byBh dXRvbWF0ZSB0aGVpciBTZWN1cml0eSBDb250cm9sbGVyIHRoYXQgY2FuIHV0aWxpemUgTlNGIGJ5 DQogbXVsdGlwbGUgdmVuZG9yczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IZXJl IGlzIHRoZSBuYXJyb3dlciBzY29wZWQgSTJOU0YgY2hhcnRlci4gWW91ciBjb21tZW50cyBhbmQg c3VnZ2VzdGlvbnMgYXJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuIEND4oCZZWQgdG8gRE9UUywgSTJS UywgYW5kIE5ldG1vZCBncm91cHMgZm9yIHdpZGVyIHJldmlldy4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAxLjBwdCAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5FbnRlcnByaXNlcywgcmVz aWRlbnRpYWwsIGFuZCBtb2JpbGUgY3VzdG9tZXJzIGFyZSBpbmNyZWFzaW5nbHkgY29uc3VtaW5n IG5ldHdvcmsgZnVuY3Rpb25zLCBlc3BlY2lhbGx5IG5ldHdvcmsgc2VjdXJpdHkgcmVsYXRlZCBm dW5jdGlvbnMgdGhhdCBhcmUgbm90IHJ1bm5pbmcgb24gdGhlaXIgcHJlbWlzZXMuJm5ic3A7IElu IGFkZGl0aW9uLCB0aGUgRXVyb3BlYW4gVGVsZWNvbW11bmljYXRpb25zDQogU3RhbmRhcmRzIElu c3RpdHV0ZSAoRVRTSSkgTmV0d29yayBGdW5jdGlvbiBWaXJ0dWFsaXphdGlvbiAoTkZWKSBpbml0 aWF0aXZlIGNyZWF0ZXMgbmV3IG1hbmFnZW1lbnQgY2hhbGxlbmdlcyBmb3Igc2VjdXJpdHkgcG9s aWNpZXMgdG8gYmUgZW5mb3JjZWQgYnkgZGlzdHJpYnV0ZWQsIHZpcnR1YWwsIG5ldHdvcmsgc2Vj dXJpdHkgZnVuY3Rpb25zICh2TlNGKS4gV2l0aG91dCBzdGFuZGFyZCBpbnRlcmZhY2UgdG8gZXhw cmVzcywgbW9uaXRvciwgYW5kDQogbWFuYWdlIHNlY3VyaXR5IHBvbGljaWVzIHRvIHNlY3VyaXR5 IGZ1bmN0aW9ucyBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcHJlbWlzZXMsIGl0IGJlY29tZXMgdmly dHVhbGx5IGltcG9zc2libGUgZm9yIHNlY3VyaXR5IHNlcnZpY2UgcHJvdmlkZXJzIHRvIGF1dG9t YXRlIHRoZSBzZXJ2aWNlIG9mZmVyaW5nIHV0aWxpemluZyBzZWN1cml0eSBmdW5jdGlvbnMgYnkg bXVsdGlwbGUgdmVuZG9ycy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUg dWx0aW1hdGUgZ29hbCBvZiBJMk5TRiBpcyB0byBlbmFibGUgZW50ZXJwcmlzZXMgdG8gdXRpbGl6 ZSBzZWN1cml0eSBmdW5jdGlvbnMgbm90IGhvc3RlZCBvbiB0aGVpciBvd24gcHJlbWlzZXMgYnV0 IGluc3RlYWQgaG9zdGVkIGluIHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCB0byBlc3RhYmxpc2gg aG93IHRvIGNvbW11bmljYXRlIGRlc2lyZWQgc2VjdXJpdHkNCiBwb2xpY2llcyB0byBOU0YgYW5k IGhvdyB0byBnZXQgcGVyZm9ybWFuY2UgZGF0YSBvciByZXBvcnQgb3V0IG9mIE5TRiBvciB2TlNG LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGVyZSBhcmUgdHdvIGxheWVycyBv ZiBpbnRlcmZhY2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U2VjdXJpdHkgUG9saWNpZXMg ZmFjaW5nIHNlY3VyaXR5IGZ1bmN0aW9ucyAoSTJOU0YgQ2FwYWJpbGl0eSBMYXllcik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjIyLjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlNlY3VyaXR5IFBvbGljaWVzIGZhY2luZyBjbGllbnRzIChJMk5T RiBTZXJ2aWNlIExheWVyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgSTJO U0YgQ2FwYWJpbGl0eSBMYXllciBzcGVjaWZpZXMgdGhlIGZ1bmN0aW9uYWwgc2VjdXJpdHkgcG9s aWNpZXMsIHdoaWNoIGFyZSB0cmFuc2xhdGVkIGZyb20gdGhlIGNsaWVudCBzZWN1cml0eSBwb2xp Y2llcywgdG8gc2VjdXJpdHkgZnVuY3Rpb25zLiBJMk5TRiB3aWxsIE5PVCBzdGFuZGFyZGl6ZSBz ZWN1cml0eSBmdW5jdGlvbnMgb3IgZGV2aWNlcy4gSW5zdGVhZCwNCiBJMk5TRiBpcyBvbmx5IHRv IHN0YW5kYXJkaXplIHRoZSBwb2xpY3kgcHJvdmlzaW9uaW5nIHRvIHRoZSBzZWN1cml0eSBmdW5j dGlvbnMgKG5vdCBkZXZpY2VzKSwgaW4gdGhlIGZvcm0gb2Yg4oCcU3ViamVjdCDigJMgT2JqZWN0 IOKAkyBGdW5jdGlvbiDigJMgQWN0aW9u4oCdIHBhcmFkaWdtLiZuYnNwOw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBJMk5TRiBTZXJ2aWNlIExheWVyIGlzIGZvciBjbGll bnRzIHRvIGV4cHJlc3MgYW5kIG1vbml0b3Igc2VjdXJpdHkgcG9saWNpZXMgZm9yIHRoZWlyIHNw ZWNpZmljIGZsb3dzLCB3aGljaCBpcyB1c3VhbGx5IGJhc2VkIG9uIGN1c3RvbWVyc+KAmSBsb2dp Y2FsIG5ldHdvcmtzLCBhZGRyZXNzZXMgYW5kIGNvbnRleHQuIEkyTlNGIFNlcnZpY2UgTGF5ZXIg Y2FuIGFsc28NCiBiZSBzZWN1cml0eSBleHBlY3RhdGlvbiBvciBsb29zZSBzZWN1cml0eSByZXF1 aXJlbWVudCwgZXNwZWNpYWxseSBmb3IgY3VzdG9tZXJzIHdobyBkb27igJl0IGhhdmUgdGhlIHNl Y3VyaXR5IGV4cGVydGlzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGNv bmNyZXRlIHdvcmsgYXQgdGhlIEwyTlNGIENhcGFiaWxpdHkgTGF5ZXIgaW5jbHVkZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjIyLjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlRoZSBpbmZvcm1hdGlvbmFsICZhbXA7IGRhdGEgbW9kZWxzIGZv ciBlYWNoIGNhdGVnb3J5IHRvIGJlIHJlcHJlc2VudGVkIHRvIHZpcnR1YWwgb3IgcGh5c2ljYWwg bmV0d29yayBzZWN1cml0eSBmdW5jdGlvbnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41cHQ7dGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUg Y2FwYWJpbGl0eSByZWdpc3RyeSAoSUFOQSkgb2YgcG9saWN5IHByb3Zpc2lvbmluZyBjYXBhYmls aXR5IHRvIGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb24sIGFuZA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoy Mi41cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5UaGUgcHJvcGVyIHNlY3VyZSBjb21tdW5pY2F0aW9uIGNoYW5uZWxzIHRvIGNh cnJ5IHRoZSBzZWN1cml0eSBwb2xpY2llcyBiZXR3ZWVuIENvbnRyb2xsZXIgYW5kIE5TRnMuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IGlzIHRvIG1ha2UgaXQgZmVhc2li bGUgdG8gY2F0ZWdvcml6ZSBuZXR3b3JrIHNlY3VyaXR5IGZ1bmN0aW9ucyBwcm92aWRlZCBieSBk aWZmZXJlbnQgdmVuZG9ycyBiYXNlZCBvbiBzZWN1cml0eSBwb2xpY3kgcHJvdmlzaW9uaW5nIGNh cGFiaWxpdHkgd2l0aG91dCBhbnkgbmVlZCB0byBzdGFuZGFyZGl6ZSBzZWN1cml0eSBmdW5jdGlv bnMNCiB0aGVtc2VsdmVzLiAmbmJzcDtTdGFuZGFyZCBwcm92aXNpb25pbmcgY2FwYWJpbGl0eSBp bnRlcmZhY2UgaXMgYW4gZXNzZW50aWFsIGJ1aWxkaW5nIGJsb2NrIGZvciBTZWN1cml0eSBTZXJ2 aWNlIFByb3ZpZGVyIHRvIGF1dG9tYXRlIHRoZWlyIFNlY3VyaXR5IENvbnRyb2xsZXJzIHRoYXQg Y2FuIHV0aWxpemUgTlNGIGJ5IG11bHRpcGxlIHZlbmRvcnMuIFRoaXMgbGF5ZXIgd2lsbCBsZXZl cmFnZSB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIGFuZCBkYXRhIG1vZGVscw0KIGRlZmluZWQgYnkg STJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Rm9yIHRoZSBJMk5TRiBTZXJ2aWNlIExheWVyLCBpdCBpcyBvdXQgb2YgdGhlIHNjb3BlIGZv ciBJMk5TRiAoYXQgbGVhc3QgZm9yIG5vdykgdG8gc3RhbmRhcmRpemUgdGhlIGludGVyZmFjZSBm YWNpbmcgY2xpZW50cy4gSG93ZXZlciwgSTJOU0YgY2FuIGhhdmUgaW5mb3JtYXRpb25hbCBkcmFm dHMgc2hvd2luZyBzYW1wbGUgQVBJcyBvci9hbmQgUkVTVGZ1bCBpbnRlcmZhY2VzDQogdG8gY2xp ZW50cyBhbmQgZGVtb25zdHJhdGluZyB0aGUgZmVhc2liaWxpdHkgb2YgdGhlbSBiZWluZyB0cmFu c2xhdGVkIHRvIHRoZSBDYXBhYmlsaXR5IExheWVyIHBvbGljaWVzLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlNpbmNlIGRpZmZlcmVudCBzZWN1cml0eSB2ZW5kb3JzIHN1cHBv cnQgZGlmZmVyZW50IGZlYXR1cmVzICZhbXA7IGZ1bmN0aW9ucyBvbiB0aGVpciBkZXZpY2VzLCBJ Mk5TRiB3aWxsIGZvY3VzIG9uIGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb25zIHRoYXQgcHJv dmlkZSB0cmVhdG1lbnQgdG8gcGFja2V0cy9mbG93cywgc3VjaCBhcyBJUFMvSURTLCBXZWIgZmls dGVyLA0KIGFuZCBmbG93IGZpbHRlci4gKFRoZXkgYXJlIGRpZmZlcmVudCBmcm9tIG90aGVyIHNl Y3VyaXR5IGZ1bmN0aW9ucyBzdWNoIGFzIEF1dGhlbnRpY2F0aW9uLCBBdXRob3JpemF0aW9uLCBv ciBFbmNyeXB0aW9uKS4gRXhlbXBsYXIgc2VydmljZXMgYXNzb2NpYXRlZCB3aXRoIEZsb3cgQmFz ZWQgU2VjdXJpdHkgZnVuY3Rpb25zIGluY2x1ZGUgZGVlcCBwYWNrZXQgaW5zcGVjdGlvbiwgcGFj a2V0L2Zsb3cvc3RyZWFtIGZpbHRlcmluZyBvciBwYXR0ZXJuDQogbWF0Y2hpbmcgYW5kIHJlbWVk aWF0aW9uLCBldGMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TaW1pbGFyIHRv IEkyUlMgZm9jdXNpbmcgb24gdGhlIGludGVyZmFjZSB0byBSSUIvRklCIGV2ZW4gdGhvdWdoIG1v c3Qgcm91dGVycyBwcm92aWRlIGZhciBtb3JlIGZ1bmN0aW9ucyB0aGFuIFJJQi9GSUIsIHRoZSBJ Mk5TRiBmb2N1c2VkIGZ1bmN0aW9ucyBjYW4gYmUgYSBwb3J0aW9uIG9mIGZlYXR1cmVzIHN1cHBv cnRlZCBieSB2ZW5kb3Jz4oCZIHNwZWNpZmljIGRldmljZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkl0IGlzIGEgbm9uLWdvYWwgdG8gY3JlYXRlIG5ldyBwcm90b2NvbHMgb3Ig ZGF0YSBtb2RlbGluZyBsYW5ndWFnZXMgZm9yIEkyTlNGIGludGVyZmFjZXMuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkkyTlNGIFdHIERlbGl2ZXJhYmxlcyBpbmNsdWRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDoyMi41cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDtVc2UgQ2FzZSBkb2N1bWVudC4gPG86cD4NCjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjIyLjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkZyYW1ld29yayBEb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIyLjVw dDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPlJlcXVpcmVtZW50IGZvciBleHRlbnNpb25zIChpZiB0aGVyZSBhcmUgYW55KSB0byBl eGlzdGluZyBwcm90b2NvbHMgdXNlZCBieSB0aGUgV0cuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIyLjVwdDt0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwO0dhcCBhbmFseXNpcyBvZiBleGlzdGluZyBwcm90b2NvbHMgYW5kIG1vZGVsaW5n IGxhbmd1YWdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QSBzaW5nbGUsIHVuaWZpZWQsIElu Zm9ybWF0aW9uIE1vZGVsIGZvciBleHByZXNzaW5nIHBvbGljaWVzIHRvIHRoZSBGbG93IEJhc2Vk IFNlY3VyaXR5IEZ1bmN0aW9ucyBkZXNjcmliZWQgYWJvdmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41cHQ7 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5Db3JyZXNwb25kaW5nIERhdGEgTW9kZWxzIChlLmcuIFlBTkcgbW9kZWxzKSBkZXJpdmVk IGZyb20gdGhlIGFib3ZlIEluZm9ybWF0aW9uIE1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3Rl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+SUFOQSByZWdpc3RyeSBjb25zaWRlcmF0aW9uIGZvciBmbG93IGJhc2VkIHNlY3VyaXR5IGZ1 bmN0aW9uIHBvbGljeSBwcm92aXNpb25pbmcgY2FwYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIyLjVw dDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyhPcHRpb25hbGx5KSBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudHMgb24gaG93 IHRvIHVzZSBJMlJTLCBOZXRjb25mLCBhbmQgTkVUTU9EIHRvIGNhcnJ5IHRoZSBjb250ZW50IG9m IHRoZSBzcGVjaWZpZWQgaW5mb3JtYXRpb24vZGF0YSBtb2RlbHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5bPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIFdH IG1heSBkZWNpZGUgdGhhdCB0aGUgVXNlIGNhc2VzLCBGcmFtZXdvcmssIGFuZCBSZXF1aXJlbWVu dCBhcmUgSW5mb3JtYXRpb25hbCBkb2N1bWVudHMgb3Igc2ltcGx5IHJlZmVyZW5jZSBkb2N1bWVu dHMgZHVyaW5nIHRoZSBsaWZldGltZQ0KIG9mIHRoZSBXRy4gVGhlIGZyYW1ld29yaywgdGhhdCBk ZXNjcmliZXMgdGhlIGZ1bmN0aW9uYWwgY29tcG9uZW50cyBhbmQgdGhlIEkyTlNGIHdvcmsgaXRl bXMsIGlzIHRvIG1ha2UgSTJOU0Ygd29yayBtb3JlIG9yZ2FuaXplZC5dPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlN1Z2dlc3RlZCBNaWxlc3RvbmVzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsgLSBVc2UgQ2FzZSBEb2N1bWVudDombmJzcDsgQ2hhcnRlciB0aW1lICYjNDM7IDEgbW9udGgg dG8gV0cgRG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtIEZyYW1ld29yazogQ2hhcnRlciB0 aW1lICYjNDM7IDQgbW9udGhzIHRvIFdHIERvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgLSBS ZXF1aXJlbWVudHMgZm9yIGV4dGVuc2lvbnMgdG8gcHJvdG9jb2xzOiZuYnNwOyBDaGFydGVyIHRp bWUgJiM0MzsgNiBtb250aHMgdG8gV0cgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtIElu Zm8gbW9kZWw6IENoYXJ0ZXIgdGltZSAmIzQzOyA3IG1vbnRocyB0byBXRyBEb2N1bWVudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7IC0gSUFOQSByZWdpc3RyeSBjb25zaWRlcmF0aW9uICYjNDM7IDEwIG1v bnRocyB0byBXRyBEb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IC0gQWxsIEVhcmx5IERyYWZ0 cyB0byBJRVNHOiAxMCBtb250aHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W2Rl Y2lzaW9uIHBvaW50IOKAkyAmIzQzOzEwIG1vbnRoc10mbmJzcDsgPG86cD4NCjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOy0gRGF0YSBNb2RlbHM6IENoYXJ0ZXIgJiM0MzsgOSBNb250aHMgdG8gV0cgRG9j dW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50czogMTAg bW9udGhzIHRvIFdHIERvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgLSBEYXRhIE1vZGVscyBh bmQgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIHRvIElFU0cmbmJzcDsgLSAxNiBtb250aHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMS4wcHQgMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+VGhlIFdHIHdpbGwgd29yayBjbG9zZWx5IHdpdGggSTJSUywgTmV0Y29uZiBhbmQgTmV0 bW9kIFdHcy4gVGhlIFdHIHdpbGwgY29tbXVuaWNhdGUgd2l0aCBleHRlcm5hbCBTRE9zIGxpa2Ug RVRTSSBORlYgYW5kIHdpbGwgZW5jb3VyYWdlIG9wZW4gc291cmNlIGNvZGUgZGV2ZWxvcG1lbnQg cmVsYXRlZCB0byB0aGUgV0cgc2NvcGUgaW4gb3JnYW5pemF0aW9ucyBsaWtlDQogT05GLCBPcGVu U3RhY2ssIE9ETCwgYW5kIE9wZW5ORlYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5DaGVlcnMsIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TGluZGEg RHVuYmFyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2T O2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXyBJMm5zZiBtYWlsaW5nIGxpc3QNCjxhIGhyZWY9Im1haWx0bzpJMm5zZkBpZXRmLm9yZyI+ STJuc2ZAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaTJuc2YiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p Mm5zZjwvYT4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_-- From nobody Wed May 13 09:31:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4071B2DFB; Wed, 13 May 2015 09:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQzgfpmJKayQ; Wed, 13 May 2015 09:31:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C211B2CEB; Wed, 13 May 2015 09:31:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSM49385; Wed, 13 May 2015 16:31:14 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 17:31:14 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 13 May 2015 09:31:06 -0700 From: Linda Dunbar To: "Romascanu, Dan (Dan)" , "Zarny, Myo" , "'i2nsf@ietf.org'" , "'Kathleen Moriarty'" Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQinCAWnYgWx+c3k2SduRLi+ubTp127a2AgAMwn9A= Date: Wed, 13 May 2015 16:31:06 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C14453@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'i2rs@ietf.org'" , "'dots@ietf.org'" , "'netmod@ietf.org'" Subject: Re: [netmod] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:31:25 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Dan, Myo, Diego, Xiao Jun, Frank and Zing's suggestions. p.s. I had to check dictionary for "bespoke" too. Synonyms are "custom-made", "made to order", and "made to meas= ure", which is a very accurat= e description. I will update the charter per your suggestions, Linda From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Monday, May 11, 2015 3:44 AM To: Zarny, Myo; Linda Dunbar; 'i2nsf@ietf.org'; 'Kathleen Moriarty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 I am fine with the editing proposed by Myo as it makes the scope more clear= . Maybe the only thing I would suggest is to use 'non-standard' rather than= 'bespoke' which may puzzle the non-native English speakers. I had to go to= the dictionary to see what it exactly means (but it may be only me!). Mentioning another SDO in the charter is actually fine as long as it points= to the fact that we are aiming to work in cooperation with other SDOs and = avoid duplicating work. In this case we say at the end that we plan to coop= erate with ETSI, so keeping explicit mentioning out of the introduction is = fine. Thanks and Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo Sent: Saturday, May 09, 2015 6:55 PM To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Hi Linda, Thanks very much for putting this together. I agree that the scope needs to= be tightened if it is to be meaningful. I'm fine with the suggested delive= rables, milestones, etc. BUT we should tweak the first two paragraphs relat= ed to the goal of the WG. I2NSF shouldn't take a position on where the secu= rity functions are hosted or if the caller and the security service functio= n belong to the same or different domains. Also, not sure if we should brin= g in another organization's name (ETSI) into an IETF charter. I've taken a stab at rewording the first few paragraphs... Network security functions (NSFs) are increasingly provided and consumed in= increasingly diverse environments. Users of NSFs could consume network sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. Likewise, service prov= iders may offer their customers network security services that consist of m= ultiple security products from different vendors. Yet because no widely acc= epted industry standard security interfaces exist today, management of NSFs= (device and policy provisioning, monitoring, etc.) tends to be bespoke, es= sentially as offered by product vendors. As a result, automation of such se= rvices, if it exists at all, is also bespoke. The primary goal of I2NSF is to define a set of interfaces and data models = for policy provisioning and management aspects of NSFs. Other aspects of NS= Fs such as device or network provisioning are out of scope. The scope of I2NSF can be further divided into two layers: * I2NSF Capabilities Layer * I2NSF Services Layer ... I've made a few comments inline below as well. I'm not familiar with how detailed a charter needs to be, so I'll leave it = others to comment on whether the level of detail here is sufficient, too mu= ch or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e meetings. Among the two I2NSF interfaces, i.e. the client facing Service= Interface and the NSF facing Capability Interface, the work to be done at = the Capability Interface becomes very clear and concrete. But the Service I= nterface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one= IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises. In addition, the European Telecommunications = Standards Institute (ETSI) Network Function Virtualization (NFV) initiative= creates new management challenges for security policies to be enforced by = distributed, virtual, network security functions (vNSF). Without standard i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF. There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the client security policies, to security functions. = I2NSF will NOT standardize security functions or devices. Instead, I2NSF is= only to standardize the policy provisioning to the security functions (not= devices), in the form of "Subject - Object - Function - Action" paradigm. MZ: Not sure if we need to explicitly specify a potential solution("Subjec= t-Object-Function-Action") in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers' logical= networks, addresses and context. I2NSF Service Layer can also be security = expectation or loose security requirement, especially for customers who don= 't have the security expertise. MZ: I suggest "I2NSF Services Layer provides a set of interfaces for clien= ts to express and monitor security policies. The policies may be intent-bas= ed." The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability= to flow based security function, and - The proper secure communication channels to carry the security p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing protocols and data models defined by I2RS, Netconf, and NETMOD. For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter= . (They are different from other security functions such as Authentication,= Authorization, or Encryption). Exemplar services associated with Flow Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors' specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols used by the WG. - Gap analysis of existing protocols and modeling languages - A single, unified, Information Model for expressing policies to = the Flow Based Security Functions described above. - Corresponding Data Models (e.g. YANG models) derived from the ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG. The framework, that describes the functional components and the I2NSF = work items, is to make I2NSF work more organized.] Suggested Milestones - Use Case Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 months to W= G document - Info model: Charter time + 7 months to WG Document - IANA registry consideration + 10 months to WG Document - All Early Drafts to IESG: 10 months [decision point - +10 months] - Data Models: Charter + 9 Months to WG Document - Applicability Statements: 10 months to WG Document - Data Models and Applicability Statements to IESG - 16 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Dan, Myo, Diego= , Xiao Jun, Frank and Zing’s suggestions.

 

p.s. I had to check di= ctionary for “bespoke” too. Synonyms are "custom-made", "made to or= der", and "made to measure", which is a very accurate description.

 

I will update the char= ter per your suggestions,

 

Linda

 

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, May 11, 2015 3:44 AM
To: Zarny, Myo; Linda Dunbar; 'i2nsf@ietf.org'; 'Kathleen Moriarty'<= br> Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

I am fine with the edi= ting proposed by Myo as it makes the scope more clear. Maybe the only thing= I would suggest is to use ‘non-standard’ rather than ‘be= spoke’ which may puzzle the non-native English speakers. I had to go to the dictionary to see what it exactly means (but it may be = only me!).

 

Mentioning another SDO= in the charter is actually fine as long as it points to the fact that we a= re aiming to work in cooperation with other SDOs and avoid duplicating work= . In this case we say at the end that we plan to cooperate with ETSI, so keeping explicit mentioning out of the = introduction is fine.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo
Sent: Saturday, May 09, 2015 6:55 PM
To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty'
Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

Hi Linda,

 

Thanks very much for p= utting this together. I agree that the scope needs to be tightened if it is= to be meaningful. I’m fine with the suggested deliverables, mileston= es, etc. BUT we should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn’t take a pos= ition on where the security functions are hosted or if the caller and the s= ecurity service function belong to the same or different domains. Also, not= sure if we should bring in another organization’s name (ETSI) into an IETF charter.

 

I’ve taken a sta= b at rewording the first few paragraphs…

 

Network security functions (NSFs= ) are increasingly provided and consumed in increasingly diverse environmen= ts. Users of NSFs could consume network security services hosted by one or more providers, which may be their own = enterprise, service providers, or a combination of both. Likewise, service = providers may offer their customers network security services that consist = of multiple security products from different vendors. Yet because no widely accepted industry standard securi= ty interfaces exist today, management of NSFs (device and policy provisioni= ng, monitoring, etc.) tends to be bespoke, essentially as offered by produc= t vendors. As a result, automation of such services, if it exists at all, is also bespoke.  <= /span>

 

The primary goal of I2NSF is to = define a set of interfaces and data models for policy provisioning and mana= gement aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope.

 

The scope of I2NSF can be furthe= r divided into two layers:

·       I2NSF Capabilities Layer

·       I2NSF Services Layer

…

 

I’ve made a few = comments inline below as well.

 

I’m not familiar= with how detailed a charter needs to be, so I’ll leave it others to = comment on whether the level of detail here is sufficient, too much or too = light.

 

Myo<= /p>

 

 

From: I2nsf [mailto:= i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: i2nsf@ietf.org; Kathleen M= oriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter = for IETF 93

 

Thanks to I2NSF contribut= ors for the good progresses made since  IETF92 side meetings. Among th= e two I2NSF interfaces,  i.e. the client facing Service Interface and = the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. Bu= t the Service Interface is still a little vague.

 

The feedback from last IE= TF side meetings was "the scope is too big for one IETF WG". Ther= efore, we are leaning towards narrowing the I2NSF scope to the Capability I= nterface. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service inte= rface. Even if Capability layer alone is standardized, it is a giant leap f= orward in building blocks for Service Provider to automate their Security C= ontroller that can utilize NSF by multiple vendors

 

Here is the narrower scop= ed I2NSF charter. Your comments and suggestions are greatly appreciated. CC= ’ed to DOTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential,= and mobile customers are increasingly consuming network functions, especia= lly network security related functions that are not running on their premis= es.  In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiativ= e creates new management challenges for security policies to be enforced by= distributed, virtual, network security functions (vNSF). Without standard = interface to express, monitor, and manage security policies to security functions deployed at different premi= ses, it becomes virtually impossible for security service providers to auto= mate the service offering utilizing security functions by multiple vendors.

 

The ultimate goal of I2NS= F is to enable enterprises to utilize security functions not hosted on thei= r own premises but instead hosted in service provider domain, to establish = how to communicate desired security policies to NSF and how to get performance data or report out of NSF or vN= SF.

 

There are two layers of i= nterfaces:

-       = ;   Security Policies facing security functions (I2NSF = Capability Layer)

-       = ;   Security Policies facing clients (I2NSF Service Lay= er)

 

The I2NSF Capability Layer specifies the functional security policies, w= hich are translated from the client security policies, to security function= s. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy pro= visioning to the security functions (not devices), in the form of “Su= bject – Object – Function – Action” paradigm. 

MZ:  Not sure if we need to explicitly specify a potential soluti= on(“Subject-Object-Function-Action”) in the charter.=

 

The I2NSF Service Layer i= s for clients to express and monitor security policies for their specific f= lows, which is usually based on customers’ logical networks, addresse= s and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for cust= omers who don’t have the security expertise.

MZ:  I suggest “I2NSF Services Layer provides a set of inte= rfaces for clients to express and monitor security policies. The policies m= ay be intent-based.”

 

The concrete work at the = L2NSF Capability Layer includes

-  &= nbsp;       The informational & data models for each= category to be represented to virtual or physical network security functio= ns,

-  &= nbsp;       The capability registry (IANA) of policy pro= visioning capability to flow based security function, and

-  &= nbsp;       The proper secure communication channels to = carry the security policies between Controller and NSFs.

The capability registry i= s to make it feasible to categorize network security functions provided by = different vendors based on security policy provisioning capability without = any need to standardize security functions themselves.  Standard provisioning capability interface is an essenti= al building block for Security Service Provider to automate their Security = Controllers that can utilize NSF by multiple vendors. This layer will lever= age the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service Lay= er, it is out of the scope for I2NSF (at least for now) to standardize the = interface facing clients. However, I2NSF can have informational drafts show= ing sample APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to t= he Capability Layer policies.

 

Since different security = vendors support different features & functions on their devices, I2NSF = will focus on flow based security functions that provide treatment to packe= ts/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Aut= hentication, Authorization, or Encryption). Exemplar services associated wi= th Flow Based Security functions include deep packet inspection, packet/flo= w/stream filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusing = on the interface to RIB/FIB even though most routers provide far more funct= ions than RIB/FIB, the I2NSF focused functions can be a portion of features= supported by vendors’ specific devices.

 

It is a non-goal to creat= e new protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables inc= lude:

 

-       = ;    Use Case document.

-       = ;   Framework Document.

-       = ;   Requirement for extensions (if there are any) to ex= isting protocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages

-       = ;   A single, unified, Information Model for expressing= policies to the Flow Based Security Functions described above.<= /p>

-       = ;   Corresponding Data Models (e.g. YANG models) derive= d from the above Information Model.

-       = ;   IANA registry consideration for flow based security= function policy provisioning capability.

-       = ;    (Optionally) Applicability Statements on how = to use I2RS, Netconf, and NETMOD to carry the content of the specified info= rmation/data models.

 

[The WG may decide that the Use cases, Framework, and = Requirement are Informational documents or simply reference documents during the lifetime of the WG. The framework, that descri= bes the functional components and the I2NSF work items, is to make I2NSF wo= rk more organized.]

 

Suggested Milestones=

  - Use Case Documen= t:  Charter time + 1 month to WG Document

  - Framework: Chart= er time + 4 months to WG Document

  - Requirements for= extensions to protocols:  Charter time + 6 months to WG document<= o:p>

  - Info model: Char= ter time + 7 months to WG Document

  - IANA registry co= nsideration + 10 months to WG Document

  - All Early Drafts= to IESG: 10 months

 

[decision point – &= #43;10 months] 

  - Data Models= : Charter + 9 Months to WG Document

  - Applicability St= atements: 10 months to WG Document

  - Data Models and = Applicability Statements to IESG  - 16 months

 

The WG will work closely = with I2RS, Netconf and Netmod WGs. The WG will communicate with external SD= Os like ETSI NFV and will encourage open source code development related to= the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 

 

Cheers,

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_-- From nobody Wed May 13 09:49:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616D11B2E0B for ; Wed, 13 May 2015 09:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZI2sjVf02h1 for ; Wed, 13 May 2015 09:49:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7B41A8F49 for ; Wed, 13 May 2015 09:49:39 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.160.19; Wed, 13 May 2015 16:49:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.160]) with mapi id 15.01.0160.009; Wed, 13 May 2015 16:49:38 +0000 From: Kent Watsen To: "Thomas D. Nadeau" , Benoit Claise Thread-Topic: [netmod] Next NETMOD chair Thread-Index: AQHQjUkwmzY3lr1OYkmNwntHboIbaJ153z0A///8tAA= Date: Wed, 13 May 2015 16:49:37 +0000 Message-ID: References: <5552F457.2040002@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: lucidvision.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51414003)(24454002)(479174004)(51704005)(377454003)(83506001)(76176999)(54356999)(99286002)(189998001)(36756003)(2656002)(87936001)(46102003)(2900100001)(92566002)(86362001)(62966003)(2950100001)(77156002)(122556002)(5001960100002)(50986999)(19580405001)(40100003)(19580395003)(5001770100001)(106116001)(102836002)(15975445007)(4001350100001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <41F553BFD63D40469C885F5EA79C22F7@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2015 16:49:37.3236 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Next NETMOD chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:49:41 -0000 Thank you Tom, and thank you Benoit. I look forward to working with everyone. Cheers! Kent On 5/13/15, 9:01 AM, "Thomas D. Nadeau" wrote: >Welcome Kent! > >> On May 13, 2015:2:51 AM, at 2:51 AM, Benoit Claise >>wrote: >>=20 >> Dear all, >>=20 >> As you probably know from a previous message to the list, J=FCrgen >>announced his plans to step down as co-chair. >> Please welcome Kent Watsen, who has accepted to serve as NETMOD >>co-chair. >> As agreed with J=FCrgen, the NETMOD WG will run with three chairs until >>the YANG 1.1 work is completed. >> That important YANG 1.1 milestone is the point in time J=FCrgen decided >>to pass the baton. >>=20 >> Thanks to Kent and J=FCrgen. >>=20 >> Regards, Benoit >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Wed May 13 14:33:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AEF1B30CD; Wed, 13 May 2015 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM0rbJs24JMW; Wed, 13 May 2015 10:18:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402FA1B30CA; Wed, 13 May 2015 10:18:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVZ87055; Wed, 13 May 2015 17:18:26 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 18:18:25 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.83]) by SJCEML702-CHM.china.huawei.com ([169.254.4.88]) with mapi id 14.03.0158.001; Wed, 13 May 2015 10:18:17 -0700 From: John Strassner To: Linda Dunbar , "i2nsf@ietf.org" , Kathleen Moriarty Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QEwhD0w Importance: high X-Priority: 1 Date: Wed, 13 May 2015 17:18:16 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.161] Content-Type: multipart/mixed; boundary="_006_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Wed, 13 May 2015 14:33:48 -0700 Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 17:18:35 -0000 --_006_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: multipart/related; boundary="_005_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_"; type="multipart/alternative" --_005_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: multipart/alternative; boundary="_000_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_" --_000_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress the work that you started in better focusing the working group, and I= hope that they help in this process. Best regards, John Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD [logo.gif] Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e meetings. Among the two I2NSF interfaces, i.e. the client facing Service= Interface and the NSF facing Capability Interface, the work to be done at = the Capability Interface becomes very clear and concrete. But the Service I= nterface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one= IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises. In addition, the European Telecommunications = Standards Institute (ETSI) Network Function Virtualization (NFV) initiative= creates new management challenges for security policies to be enforced by = distributed, virtual, network security functions (vNSF). Without standard i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF. There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the client security policies, to security functions. = I2NSF will NOT standardize security functions or devices. Instead, I2NSF is= only to standardize the policy provisioning to the security functions (not= devices), in the form of "Subject - Object - Function - Action" paradigm. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers' logical= networks, addresses and context. I2NSF Service Layer can also be security = expectation or loose security requirement, especially for customers who don= 't have the security expertise. The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability= to flow based security function, and - The proper secure communication channels to carry the security p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing protocols and data models defined by I2RS, Netconf, and NETMOD. For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter= . (They are different from other security functions such as Authentication,= Authorization, or Encryption). Exemplar services associated with Flow Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors' specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols used by the WG. - Gap analysis of existing protocols and modeling languages - A single, unified, Information Model for expressing policies to = the Flow Based Security Functions described above. - Corresponding Data Models (e.g. YANG models) derived from the ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG. The framework, that describes the functional components and the I2NSF = work items, is to make I2NSF work more organized.] Suggested Milestones - Use Case Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 months to W= G document - Info model: Charter time + 7 months to WG Document - IANA registry consideration + 10 months to WG Document - All Early Drafts to IESG: 10 months [decision point - +10 months] - Data Models: Charter + 9 Months to WG Document - Applicability Statements: 10 months to WG Document - Data Models and Applicability Statements to IESG - 16 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Linda,=

 

First, thank you for p= ulling together these changes. The charter development has progressed nicel= y.

 

Second, attached is a = word document with my edits and suggestions for consideration by the workin= g group. Despite the large number of edits and comments, I am very supporti= ve of I2NSF being made a working group, and would like to volunteer to work on its deliverables. My edits and comm= ents are to address the work that you started in better focusing the workin= g group, and I hope that they help in this process.

 

Best regards,

John

 

Dr. John Strassner, Ph.D.<= /p>

CTO, Software Laboratory, CRD

3D"logo=

 

Futurewei Technolog= ies

US R&D Center

2330 Central Expresswa= y
Building A, office A2-2143

Santa Clara, Californi= a   95050

  Office:  +1.408.330.4923

  Email:   john.sc.strassner@huawei.com

 

 

 

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, May 07, 2015 8:53 AM
To: i2nsf@ietf.org; Kathleen Moriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter = for IETF 93

 

Thanks to I2NSF contributors for the good progresses= made since  IETF92 side meetings. Among the two I2NSF interfaces, &nb= sp;i.e. the client facing Service Interface and the NSF facing Capability I= nterface, the work to be done at the Capability Interface becomes very clear and concrete. But the Service Interface is st= ill a little vague.

 

The feedback from last IETF side meetings was "= the scope is too big for one IETF WG". Therefore, we are leaning towar= ds narrowing the I2NSF scope to the Capability Interface. The thinking logi= c is: Once the Capability Interface is completed, we will see more clearly the work for Service interface. Even if Capabilit= y layer alone is standardized, it is a giant leap forward in building block= s for Service Provider to automate their Security Controller that can utili= ze NSF by multiple vendors

 

Here is the narrower scoped I2NSF charter. Your comm= ents and suggestions are greatly appreciated. CC’ed to DOTS, I2RS, an= d Netmod groups for wider review.

 

 

 

Enterprises, residential, and mobile customers are i= ncreasingly consuming network functions, especially network security relate= d functions that are not running on their premises.  In addition, the = European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new manage= ment challenges for security policies to be enforced by distributed, virtua= l, network security functions (vNSF). Without standard interface to express= , monitor, and manage security policies to security functions deployed at different premises, it becomes virtually= impossible for security service providers to automate the service offering= utilizing security functions by multiple vendors.

 

The ultimate goal of I2NSF is to enable enterprises = to utilize security functions not hosted on their own premises but instead = hosted in service provider domain, to establish how to communicate desired = security policies to NSF and how to get performance data or report out of NSF or vNSF.

 

There are two layers of interfaces:

-       = ;   Security Policies facing security functions (I2NSF = Capability Layer)

-       = ;   Security Policies facing clients (I2NSF Service Lay= er)

 

The I2NSF Capability Lay= er specifies the functional security policies, which are translated from th= e client security policies, to security functions. I2NSF will NOT standardi= ze security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to the security funct= ions (not devices), in the form of “Subject – Object – Fu= nction – Action” paradigm. 

 =

The I2NSF Service Layer is for clients to express an= d monitor security policies for their specific flows, which is usually base= d on customers’ logical networks, addresses and context. I2NSF Servic= e Layer can also be security expectation or loose security requirement, especially for customers who don’t ha= ve the security expertise.

 

The concrete work at the L2NSF Capability Layer incl= udes

-  &= nbsp;       The informational & data models for each= category to be represented to virtual or physical network security functio= ns,

-  &= nbsp;       The capability registry (IANA) of policy pro= visioning capability to flow based security function, and

-  &= nbsp;       The proper secure communication channels to = carry the security policies between Controller and NSFs.

The capability registry is to make it feasible to ca= tegorize network security functions provided by different vendors based on = security policy provisioning capability without any need to standardize sec= urity functions themselves.  Standard provisioning capability interface is an essential building block for Secur= ity Service Provider to automate their Security Controllers that can utiliz= e NSF by multiple vendors. This layer will leverage the existing protocols = and data models defined by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service Layer, it is out of the scope = for I2NSF (at least for now) to standardize the interface facing clients. H= owever, I2NSF can have informational drafts showing sample APIs or/and REST= ful interfaces to clients and demonstrating the feasibility of them being translated to the Capability Layer policies.=

 =

Since different security vendors support different f= eatures & functions on their devices, I2NSF will focus on flow based se= curity functions that provide treatment to packets/flows, such as IPS/IDS, = Web filter, and flow filter. (They are different from other security functions such as Authentication, Authorizat= ion, or Encryption). Exemplar services associated with Flow Based Security = functions include deep packet inspection, packet/flow/stream filtering or p= attern matching and remediation, etc.

 

Similar to I2RS focusing on the interface to RIB/FIB= even though most routers provide far more functions than RIB/FIB, the I2NS= F focused functions can be a portion of features supported by vendors’= ; specific devices.

 

It is a non-goal to create new protocols or data mod= eling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-       = ;    Use Case document.

-       = ;   Framework Document.

-       = ;   Requirement for extensions (if there are any) to ex= isting protocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages

-       = ;   A single, unified, Information Model for expressing= policies to the Flow Based Security Functions described above.<= /p>

-       = ;   Corresponding Data Models (e.g. YANG models) derive= d from the above Information Model.

-       = ;   IANA registry consideration for flow based security= function policy provisioning capability.

-       = ;    (Optionally) Applicability Statements on how = to use I2RS, Netconf, and NETMOD to carry the content of the specified info= rmation/data models.

 

[The W= G may decide that the Use cases, Framework, and Requirement are Information= al documents or simply reference documents during the lifetime of the WG. The framework, that describes the functional components = and the I2NSF work items, is to make I2NSF work more organized.]

 

Suggested Milestones

  - Use Case Document:  Charter time += 1 month to WG Document

  - Framework: Charter time + 4 months to W= G Document

  - Requirements for extensions to protocols:&n= bsp; Charter time + 6 months to WG document

  - Info model: Charter time + 7 months to = WG Document

  - IANA registry consideration + 10 months= to WG Document

  - All Early Drafts to IESG: 10 months

 

[decision point – +10 months]  <= /o:p>

  - Data Models: Charter + 9 Months to= WG Document

  - Applicability Statements: 10 months to WG D= ocument

  - Data Models and Applicability Statements to= IESG  - 16 months

 

The WG will work closely with I2RS, Netconf and Netm= od WGs. The WG will communicate with external SDOs like ETSI NFV and will e= ncourage open source code development related to the WG scope in organizati= ons like ONF, OpenStack, ODL, and OpenNFV.

 

 

Cheers,

Linda Dunbar

--_000_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_-- --_005_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2669; creation-date="Wed, 13 May 2015 17:18:15 GMT"; modification-date="Wed, 13 May 2015 17:18:15 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhMgAyAPf/AO3b2elrUvbKwuNBIPa0g/GUa8WJguZWOfGjk8zMzKguI7Ozs/Hx8e+Pe6ZE OeZcQvvi3f39/eXl5et5YnNzc8lGNvj4+NU5I+6JdfS3qudZPfvl4OSimoyMjOlpTOx3VPSkdvnH lODg4JSUlKOjo/W4rBsbG+jo6NSDe9HR0fOfc9bW1p4uIvPj4f729ODAvP77+rkxJMuVj/749u6N e/nUzVNTU/jOxfGZhNRKOHh4eNnZ2e+Tgfa5ieM/IP3w7sQ0JOhhRuRAKcLCwjs7OzIyMuM8IOVR MelmTPb29uVNMUBAQPKuoQoKCvv7+xQUFCoqKktLS+WNgfr6+vrVxNZ4bvKpmZiYmPW9spcrH++L ZcGAeSMjI+ZRNPjRyPCXhfbBt7u7u/rd1vzq5803JK6urvWuf/nZ0uRGLeM9JfOlefa7mmNjY/fG vei7t9k7Iut3Xvrf2eRKKoaGhuREK/308vT09OVPL+2Gcv3y72xsbPOrnGhoaPrg25ycnP3v7PbF u7RGO6qqqlxcXO23sOZPNPGejfSoefv49t89Ifny8fjKtO2CXupxWO29uLdrY/XBuYGBgfzp4eyB av76+fOzpv75+Pbs6+tzYO3t7fjBjvCYifOwot3d3adLQe2Cbfzs6Prs6/bZ1eA+IeQ9JcbGxu/B u/Onm+S+uuhkR+M/H+VKL+yupeM8IvW7r+x7V/CPaP37+/Gdiex9Z9A5Jfra1O2FbtarpvnTzPfI v+x/WudcP+RHJ9w7IeVLMONDIudfRedXP+RCK//9/PnX0Pzt6v/+/fzu6/KXbvnQv+ZUN/nw7+x2 W967t+6cj+zGwvbQy/Pn5u+HYvfCr/Otl+M+I/OvnuvRzueAcPWwi/vt7PCMZ/zr6OhgQ/a/tvTW 0uNFI7BgV68vI+NEK+NELNxVQOydkelkRPnXyfa8o/vo5P3u5vWpfuZPOfa1kvSwn7pya757c+LG wuXIxf/8/OfNyuzLyPS0qOM7I+pxXvK9tepwT+NAIONCIAAAAP///yH5BAEAAP8ALAAAAAAyADIA QAj/AP8JHEiwoMBh6rydckHQmKRFkiwZM0ixosBin/o1mCHwz4R+/fgZaSVs1YFUoIxN24ZMBYiX KpDBSjawTwA6WIZZvOGDH78BIIPu2iDgSNCQPmjMECZE2DhyaNDMMnaKVCsjRvgdDfCH4KMs4mKQ ufBm1CwBM7B4ABr0C71GIMHAgAvOVZ4DR8FhiFPMSrejIJU0IBjhEoDD367Ze2bKEaFKTBDwqKHT YB1Om5hUKoEFUK4buGr1gQAhDiWLqFOrXm3ChB2BQ/wN+qfD35IRFJ5w2RHF35AkSSwsaTIk0xN/ UCT8u+LPnx6BYaA0icKHjR4GV55YWP0vToB+Poyk/0HTZZcXgTDWqCGgKYQmAocWTeQuEMKdn0cR wNjwHaTIVkKswgQMcKTiwT4IJvjOP9xM4IswaRjhwwANMDRQFVWg9c8xs/ikFWBg4IJXUIZQ0kVQ v0xSBxyABaUMJ/VZ0UglAlFiQBYsKBADEGP1MkpPvtCwwQ8ZBIEBDH0wtEEdtXSBAS6UYAFXiwN4 qIwAFrWwRRZcchkOKsvQJ1Af5uRwAS20kJEDIZZQ1JoEdliwgD98SMDFEicINIc/I/yThAk2dOCP HxEwNwdtTRBhQikMLFGEBHz4Q8I/FlQawQja0UdPJQdUkwYdSvDQpkDHqKAGO2aYscY6YhpkDEcD Df9jC0jhjVfILg3Q848kyIBgRg+a9ACfClQQBAMMqp2hRFBB1CCQLL/QKh6oB9xADw6vMCKNFtxK w0gDYvwDwx7KoJFGK5/kUdEePrEVFBx14KJBUPyER8omlGjQxQEa9NvvYG0EQ8e5WYF0BCgUzcBu u4DJQQwgdwDGwwxyhIeVEZjU0YCEHx51AAQFOSAOj+U4A3KRPgFmxRh/gbQHDC2Dg8MMQbT4yycg tzFJUEcE8E80DmShI48X+OgDMEwUUwMe0fZDwz+y9FMLPRjI0Yc6RvWzyx6gnIEBLy2GpMomBcXy QjwODN1jIj/21EgNuhY0DAwI3DHA3Xh7yA8vASD/EG5Fl8DTJZcshAUEEDmwcgxqxhCDR08+RD7K KIn08sYF+py2Wh2XhNmqQZaEoo3mFXEBRRIClfKEHhIUYYNy/3TwhB8CnVDEEx38s8ITRAi0Ahcm RCKQICZQsBwXTSTfxAkkmLAd8npQQIENztmJp0CC0k4EnZFw4c8CFtjwRBlP8HGCCVEIOmlvg0Si gw6R2OFHpvQNQwwGwbSzCi4EUZIOMuxwBxVI9zmLGOMeXagVGgqBhB8chAq+IkAPeqAqdRWwIgiI lgLLYw2duEANh2BPCEIAn2xI4oK1QIA6BnKMj4BnWoXQADNmYAx0FEAFh0iVGQ6hggLQZCBguEcd /1JDjz2A5A6VmAglZtWPAfgAQOTZhRiGQQ1GaKEAyMhiAWCxjWL9wwV4WIUQ2nEGi7igAR3rxwTU hYWsDQArQligK2Bgi3184BW6yOMrPiALdQkACWK8ygCcRRFAMCwoGrjBP3gADpA4cVr6QcIuunGO c6QiFeeAQw0sIQtfDAwrWklFVwzCCQ+5y2X/sEXTqhQeURUCDb5QQiFm+YA25CEfQoiQhFyEMIOA IhimlJgxZgEYCrmADkbARxrSQAo0uEIdwcBKTwCDgFEJpAWhEEgdOpQywMDBBZNoGki+QAm71csH qwADMXiBH8AcwRWViQMi/hGIGFRACtD4hyV4IP+HbjLLBYwMin5G1I8D1AAMYetHKsDwjz+UgC5B +EfadkSLNwTgHjPoAwZ+ccou/KASjexHBmDgAZCk4hicaNEuOGEMMfAgYiD5xRFS8Y9b4GhkPRpF qCCgDkOcCCRygMAZImatnc3iH4Y4SiPAkAcwTAkwqngAyGrKJbUVrW1waEMdAMGMfvxCDHVoBATo YQhD/OML/TjCF+IACgTMi0o+AcYGCKIIGbCgcDta2yjqFYQ9GAMCGbBQTeYYB1vIAa4eCkAuLIII AMwDFW5whCNMAYnKggELlaAMRergihKAoQ1tyEUuQAsIQAgAFytETT0c4InWeiIQgaiAbHPwhjf/ 0GAMFYGBAIDBDzkoQQldUAa/dvEAYDwAGw7M0lcGlyNxoOAb3PkBFoCRiOpa7nK0YEVlUqMIeRjg EVtoRjQuOANRcABDHBDFdi/IXu7sYAcREEgSEiABJ+ygE06oXQIyMZBOpGA7DEgB7KYgghUwQCAW WAF+/8GAHaTgwU7IxAoE8gTnpc4fbJCACYgAuz316R+RSJ4JGJCEIjRhwnPyRxTyS4HvLaAJXBjB AsoAvuw8zx+tMcFxWHenPP3Dw/8YgT/C8A8TQCECIvAHESxAhCIIwh8dSEETKGCB3uTYyCeY33ZM wIVKWSA2bLAdFBIQ3xaHgXxPeEITTKDkf5QBSjlPEEQE2LDmIuzgH4OQVAScMIX8Ymo7RSDCa/6R gNX9QwR8MEHyijCEFbjOx/9ong4ioIcn2CB1UDDBpASygCWoec0nEEQRthMQADs= --_005_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_-- --_006_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="i2nsf charter-jcs-20150512.docx" Content-Description: i2nsf charter-jcs-20150512.docx Content-Disposition: attachment; filename="i2nsf charter-jcs-20150512.docx"; size=26676; creation-date="Wed, 13 May 2015 04:54:14 GMT"; modification-date="Wed, 13 May 2015 06:46:58 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBjgxjKjgEAAKUGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 ldtOg0AQhu9NfAeytwa29cIYA/TCw6WaWB9guwwtkT1kZ+nh7R2gJUYttcXekBB2vvn/fydDPFmr MliCw8LohI2jEQtAS5MVep6w9+lTeMsC9EJnojQaErYBZJP08iKebixgQNUaE7bw3t5xjnIBSmBk LGj6khunhKdXN+dWyA8xB349Gt1wabQH7UNfM1gav5AAV2QQvArnn4WiPnxlXEYHlaKDGBGNBfdt Wd05YcLaspDCk26+1Nm3nqHJ80JCZmRVA6KaZp2RgEjOVBntyFc1mafxA+SiKn3wuCZlbRgOSjyu 6dZkRJWNMFwUFns69LvaKtsbTmeuH3NCOB1ZiULv9O/VoSs1A0ex/v8tdeiDItBvSjjDnLTcvvYU 1qszFjlN5OAEoB6/DLKQhtWC8wV087M3fwTvKf1zmN+S/2RfVuiNGpxAiznGv6elA7x5jge3bzB9 fpu9lNMmmopZCYP7/VhMHfqgiBXM3s529V/gfUK64ZfGnRDGbmHW1b9cOW9+MuknAAAA//8DAFBL AwQUAAYACAAAACEAmVV+BQQBAADhAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySz0rDQBDG74Lv sMy9mbSKiDTpRYTeROIDDLvTJJj9w+5U27d3LYgGatKDx5355pvffOx6c7CDeueYeu8qWBYlKHba m961Fbw2T4t7UEnIGRq84wqOnGBTX1+tX3ggyUOp60NS2cWlCjqR8ICYdMeWUuEDu9zZ+WhJ8jO2 GEi/Ucu4Kss7jL89oB55qq2pIG7NDajmGPLmeW+/2/WaH73eW3ZyZgXyQdgZNosQM1uUPl+jGoot SwXG6+dcTkghFBkb8DzR6nKiv69Fy0KGhFD7yNM8X4opoOXlQPMRjRU/6Xz4aDBHdMp2iub2P2n0 Pom3M/GcNN9IOPqY9ScAAAD//wMAUEsDBBQABgAIAAAAIQBBQiNEGAEAADkEAAAcAAgBd29yZC9f cmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKyTTU7DMBCF90jcwZo9cVKgIFSnG4TULYQDOMnkR8R2ZE+B3B4TKU0qqrDxxtI8y+99nrF3+2/V sU+0rjVaQBLFwFAXpmx1LeA9e7l5BOZI6lJ2RqOAAR3s0+ur3St2kvwh17S9Y95FOwENUf/EuSsa VNJFpkftdypjlSRf2pr3sviQNfJNHG+5XXpAeubJDqUAeyhvgWVD75P/9zZV1Rb4bIqjQk0XIrhD In8z5z2lrZEETErkOYFfRngIiUC+NTjnjyUf12SNYROSwdHQ+TnOTRjrtfgkZLw+qhytn8NMcJLW ILYhISqjKZN5t5jFSVqDuA8JURj1+1QXo5iUNYS7kAhfmL/9+RULcQLhZx8+/QEAAP//AwBQSwME FAAGAAgAAAAhAAPXirT4IwAAlr8AABEAAAB3b3JkL2RvY3VtZW50LnhtbORd3W7bSJa+X2DfgfDF IgEcW5L/vR020nE8yKA3E7S9M5hZ7AUtlSxOKFJNUlY7V/0Oe7XADjDPMo/STzLfqR9WFYtF02Wp 0cD2RTvWD+v8n++cOlX+5tuflln0wMoqLfK3e+OD0V7E8mkxS/P7t3v/eXv95nwvquoknyVZkbO3 e4+s2vs2/td/+WZzOSum6yXL6wiPyKvLB7y7qOvV5eFhNV2wZVIdFCuW4815US6TGr+W94fLpPyy Xr2ZFstVUqd3aZbWj4eT0eh0Tz6meLu3LvNL+Yg3y3RaFlUxr+krl8V8nk6Z/KG+UQ5ZV3zzSpLM VzwsWQYairxapKtKPW0Z+jSwuFAPeehj4mGZqc9tVkNWm5XJBvpYZoLsTVHOVmUxZVWFV6/Em80T x6O+taUA6RHNN4aQYK+pKFkmad48hqyjpf9GeQdQ3qFY+5AepRmBLGLY0l0xe6Sfq2hzCVuc/fB2 bzR6fzQZnZ3tqZeu2DxZZ7X7zmfjJXpISf/jZnlZrZIp6FqVrGLlA9uLP+Q1K1dlWrFqP8Kr6QwW nCbZfgQbj5YFLJJF03VVF0s4RZSULErzackSknX2GE1hLusl/h3lrAYrX6L5Op9yK9qPvjnEujH9 n5MwYxloT2cgj5hI1vWigLFelQfR74tFHt3UZVJVOSvp3VlSg9DJaHzyZnTyZjy5nYwvT44vR6O/ cAGVUgpXLCNuz84mV9dX/B2scst+8rDLqhWbgj1QTmTJzyoSxSskrTSvJKnjrZHKdWgQWseQZLam 0NISlGLO+QbFBFeHtpzBBKh/Su9KWxWbrkvEHPsZXDJSAJNAAZy8VFc8HLFZv6L6bLuxxDZzWrtH W2PO0VX86tPNdfX6IKIf8JN1NovuWIRINVtPwdbdY4QMEhUlvAxehdcf4HzkY3A84VY9n9qHG8Jz l2yWJmVKzosHMXxzDceu5KLLBGvg+cmjZWDaQrRHHgcK4nS4luN6kdQUQXo9r0+hUV7Ufl2ebI0F R5fdfgdteuQqmIjLdZ5TaCzyqF5wtjujIXJ9UDR8juzTMlzqyBZLShAWs2aM5DkpIJy7DAyUfFTM SaLKTUr1O7maRaU2de3zQHDPF/fkcjxyTJ1TezKeXH93xlNPHcu02fgdt1jh9eTd3Osf0rJeJ1n6 Fb+m+Rw5ry7X03otHKOxEE16n0sc/OPvthFuLoEtCIb+kOT37KZOyloG8ou9Q8oK2ufHoWn4zJHE 1fPS8Mc8SmazlGDCPlfkh3UJcJzk0S3LGDGwztOpAKOABQS3y1kVfcyrOq3XNYtefbi9+fg6+iQx x7XEHNEflWz5d6NXn67/+BpCxkp44QEGA+RSswpgZYOwmCf3jCP26QKQgEFeVQRwHjVJcVVk6RTR NaoLit0sx7syds9SqC29AzGz/UiqdL8BQc0TdA569QDrRDro9UNTdx8QzQVckpor8WsDBj+8P7m4 vuBmV37mFlLe1I8Aa5vLhwSY6L20AjZnJSoYRsqHScnPqnXUu+ZC9CkNH+I/pYBp61pWPSXZLBLP HDjS8jQzHoxDQZNrWE5AiH0O3uclpD/2E6FeJMplAXsoSuGqLR4M5wjFPS4Pz3QOYZf9dqKj2TgU wrh0urIGDKnLImsJybJDE9B2p0k7Pg0La43/NB7YosFQVCh0cQXwTEXBqIgqkEIFR28REYpNXBpd JXFYdV+gacFhBgLVInlIEcaQJHsSoiHBUADiUueVYNxoVEfEGVtlxSOyIGDhLJ3zQFUDCPcK1SA7 FHacD09fsUY+XjWLwIPUn9aQPSIr8oVMCCgz0+WqQGPiDpHZSi1Uf6N3Y+B+mBMwVIG+CeuAi4bH BwEYVM8u364xCZxoGjMW1tnA4+GKGbQ0WOnWswbtFyHgayDtSNOoMKxAMSzaROsajbev1jfNfDYJ BUpDJG6nUU2wNvRJaDp1l/f7p9TaE1bu0b9fcqFZ1CXdsdVuWnQgsYjScu3DCR1BynqKZRShiXcA a/G8LJbWypp+wy5CM9+FNwBen343ut6TZQLPane8dxBmFku0J9MVIt8DOhMFtSXaPK1oqRc3OXld 8+KnPBXlblFwWvSbtdQkKMNPoAifLq5PJqNrSxfdBk8y5jmDaPPqSYfgSVC276SUu6RBZx2jk4wd DbvdhHLCLFzMz3dzZEtZW36f594XSUaA5+MEkCdKecXWUpYhgiDkABGMHWW5IpixeYq+XmKtrpkw qAjK42hEeKiwGhE56p2a5QJ4cBD9GKHVsGSiR8+7gih/qTtFGPEgul1AaBUqPbQpRV96EA9B+Xxy OXG7wzK+H4/fqWZKTu0RvleGPgHKNop81Bx9WrRHQQl7mII9NluxmuwP2xaJIFU0cmmrbiN2TWTV LFoMT1rHUVDSBwvkqfYeCZesZR18F2T+CO3Tpg/VxbTrQ7/9uGaleF2WyfxV2ZKmWjBTJvM0B0G5 H+QfDeDgIPoP3b6RhU7bfKnJIftINmucnQX6Y8SL7CPO0/t1KbpG/XWTduCjIAQABj19T1NFHitr bRoYLSxSYI1WlUctGjUcBaEGsipHLVei62dEdJl/uqlneUJlEFEoP+fWzAadoRnVu0loyFetD6mp 7U/qEYk6gOkGoC5WaethUVRo98l2fooCe5OjfhMlYoRWIOIVPpDM1AfTHE+yy7xohgIvpa4nOlIY JLjL0mqBz2/oBW2wLJphL7bEYg0kbToh+CDlODJi+b17xJ4VenIUK9HqE0EIIR6uXaD9S907YdO0 G0RtyF4VyHr2oG1JLlaTilfZffCG9Eo2LMWPaZGBLNm2HF8fX5xdiU519VW9igqIY7zq63val+UN TvEabIm3NPFTPZXjuC0+2rt3/l/XZZJ/+e9LG6/4G/BHp4ILLuCmEbsF5mmXncKYAD/TLIVZV7A0 vvtQ5NSF4DvN1MFW9m5p16ZZN54bipWKaa/dcKPtdZ7FSqTNBoZvWULdMekguimcQQXVHW/voByd 7U6B3eRhYwK7EtEvP/+f1twvP/+NggVes/SNl1v1lVerio3da5WvpLTqFev57sQa/2mB/Q8+t0Ie 0hMlCQJBrt9GHwEJ0vwLAYNHBSmw+UNfb4JxO6xXFFn/ijEZ/jFLL8McTYlg9yrhKymV7CQUDcgc IaNM267y41ttGpsiypJHmr5Aomw2uGwwZTZ/jgLrnrEH256eT87G7/co9nkmlxC6H1KaSuS7xoaZ JSuMjiTThWVn0C+wSBNK6/iy/babzUN0QivIvLuyth+/x/bo56RM7stktRDuna+XIiun2QMNgvEs Pmre+0i7nfw1nuzBgfwC/mWm9jq+UTNLn9X2LHYjCco37qlh2yvhi++TVSKGK6PvSc+v/z+IQwEB KYMbCUV3LQAeU+r4H3/fuYy7EMKI/0dWRTGODK5lP8O+5PVDBA2Js9o2FYmqmo8L4EPKBtGXauxS Yfj9aLNIpwuRlgAiKwzewq+p68s925Kc2WY8DmxsjL1FkRF5hkqmt8gTRtdf5OkS+jiwy9HBD+9y BHBTx0j8NAHJG3eyI9BSgNXADFmjG93ZhQPsVMZsQz6BPZSJW6wHy6ebdtVwJVhkSUuz4QUXro9S BWN7ifVMM/UeB3ZdMD/c2RgLUWdsd7g1y7p9cRzYZukg80q0WQIIVW0O2RdSv5JsRWDEK5TCDYML 7LqM3T2lLRscwTLskNMuOgVJzAxMMS8GYI4d9oyPcbGZZTRaK88zxG57d4pEQ2aBOypjTxM8QNEe 0Mi75Sh/MBQs5qh9G/tDQ79nHSjGEr1lUYGbLbuXjuxwq4Fr6m7bbGgLMpQduGvT4ddbdhCKxObs j6URzcrznEFHZYVnsFckMPUmzbLo0x9um8lATLRqqNN8nCrjGaNZF385dRxaTu3cg+R8Tnd1sRUJ d4cbCFn0kveltK21TEh4EgoJXdm9ONF084KNRaJ+QPY5CYWDLi/BzhWTXbek/Svjv+e5aLfQedu3 xQY0gBqbDmCdBOLKjqC8I6ORKcVrNNuQkTjIWc4ocPlFFYg3f0VRSQi+JVnFvEptyUMnwJNAYNsh j3AfHbLReRIKZd1g8mIbFwXDlhTU7fBtCzY09pvFpxzGGzDsEFhBzpy7fRANYQzWQsGlZws+BHrH BuiyvEYTDMWrwBsIH8cuwS83Sn7mkHrKvOtREPG7NVGCqE2ZrxHiK9pclxjR7sxaQCcUJO5CdHT+ kpsoL0exaYDtuA752Vtw5mmsU9n5VtDi5dq8Wd/9lU1rUPI/0R/0P6/V2Sh6/R0/mt1BqFA99QLM XTq9E9wm1xO6t3AGSawEeniG155zGooNd6F+2oNdYXtjlt7zOd2duo1zxg/C2fr2zbAOAK2seup8 7wdhrTmSZm8gSYM+O+MTfepzgTMihhkEIteJ2Hnz7wt4Whu632/tn9CIqRXszUh1GgoZ3dFwKUUj LylTQ+CJ1A4PwDITx9t6XVvnzdNQEOdS2I4EHjnOcdUIdaEwyWnJDRYFssiWDB0HIreOHotXfh4Q RR2zXhnyqFTHErRYrJhdr9NAzNXBgiNg3BtxbzataCTTIkTLVFDr4bXJxGpbytaMxU4gzpp4plEN e/bYC4eGNDiL/W0MNM1o5EVusE0jnGrGzJuaWvbwbthTIOjqoP6Z9kROCtCDWcGG9nlWbHAKVWwA DjE1RJp1hQPjGOO6S4QLWRxbegrESB2cOmbnsSKuH3FW+w23Snm1yJuG45L9uMYsI520tluA2k61 rs4C21kdHDxTV/qam19+/t8oK+5xAj1TJ7qhMZxYpwPEoo0JgrsPffZ6HB88xplazOb3zmqZQPFM zj4aInpZCqRY20KdMknLKMwZEz1eO+fRhkuSVfwsfBM8kHiAOuXkdAm5FZUB8g3d72Pgtbl9h2ev 5lqhzaLAuGIOuWPINsE5fatQoBXKGjdQ8MEir+S7gasSn+KYm7XBr8Q9WwCuYiXYNEwA//9VENrL x2VNqVlmd7TDobxmclbGxwhXRxljV7hHAQUhxQtVm6Ju1OWiuhhog5sJeib6vm1FSZNTXdicKT4V QhXXSTXHULZoH3ylLdvHtofiuoM8gWD0ZXB7Bs4m8xNE2H4lH22J2IhRgQCz42DQlbpbpNGJCgHf 0/LqF/q38Dy8QpFMo92zUDzpdgLb4aOOP1oyABESzopEEPPzaM6okJzHdtKhGzRa9dPn0rBPZbLP Lap2NqoHDcgRv+b+tLNQICwuF+D2bZ0QcIdHIHM5IAjNQya0wSHuyXvunUSdB9OufPbn95WhdhmK S4fY5bvcMkyd8x0T7ubD9m3Hro2jea11DCWEolGXP68S4oRv1mHRADzWolxHjPNQFOo2mwaKWxxv 5FUPH0TDJRIWdVoBBpWBLbGJ8C0TCDpUxhTv2QrnSCSEw3giiplKXsaUfuU9Y6QA4wwa2qANLFQ1 ZScT5LG0+lbObO96/rgJagFh6DwUqrsa8nvAvyXL1b+TnL1OYJhMYGtqkMm8g/rpqFmnznl29o7V 2sZuJu/zUCThaVUZ2N/Tevjzu0+/s+nRziezunHM12LWIjwUdQwgHLfNzHDTyoM5NJzc4Q4goGi4 Ke4DaI5M71sEtjkZEvvtPQGzSDiXJ9pgeDLvnoc2ilymvQbfTTNFJ4ZzEBgLrNl9UT5xw2t3NaAY 2n21KFaCOrhFGQIMxQQvFiAabJimbI6Di5bb0LASmuldqp1M1K1u0T8TR4rp4h8kInGvW6s5Sgd6 AjxAXuBkf9X07otQhOAZlDXDUow+0WEv0TGMfbV4rMwWlc69TalsPcOiPhQ5DKC+W1/Uv4V5yaZg /6gu7tH0Ux6YUY88lnZ8NjkH2iM04kkH1NS0yFExFD+fQjEyhslFECP5Ztlvr17T8eciECBI+YbW axeBWb5DrbbMSbHgjoqDbsPkvQ19PKxk93Sz52P06uO7T+9eU/jgUPZRTIKqaYmp/gYMm3r6sjnf AGDlhPqeSUkG7w4i6sN88MqwXqEo+3/zZqRx5kUg+AkyI55CM9yj+wPumcJx39lnXOz6Ha56/cLN sUfxmIBBb1lETmpxNReGYJuSzl7nLONXCU2TEiZBWabRrypwENXqDWOtbU2uW4mJLgJbIEfeIsAI Wr22/V7c35mBRWlu3UWyobdA/NZBK0/kBqXijgKjXJTnrl5ZwRUxtSyK+YeSIFj9uMIfAcAZ0iVH nbIjrcIodcKs5xf86sjmjIPnUej9PvGg7kBBlyfwK1baI0oWWDQJ8jzH4lclk/7ySG1LG7wZOguE jEN01s2C0/ptcxHTpVIWnxb6CESL4QTDSQkXCuPrzub9Cmht13Wmfql6ZZ5PxWz74/yPdhjGI7sa Kb8EOmNz/J0PQE4ez7Y+qvPDYEDCI21PPDXSYpNIvWYwHgVi6I6k7wSbbsNV9YJFkzZe7VPjUSBC PvIgZEO1HvmRUyHnlMkUd7QAg6RTcYWYMV5qlyPddO8QH5NXD5BcKIIcILmYZ2OzjsBsBK/45B2T b3K2xp+Rwd9wKqbJ3TprX0aoZYbEKfPzeBQKPl2Kr8RmgaHt3gSN2Q7Ax2XyBY2bOprTn9WhK7Lw GslZflUBRn8fZjw6sVOal4xYdkfoyIPzN2AUZOWRu7W4IEei6UZwocjGLca8FHc7cpd8NIndzZ1G SmCt4SAU77iqNxsXMge4TG1vO1lyA6Z5UFYgxF0S3HLUx6e95d+g0LfkyqtZm9GiFsD1lj0d9qnl 35cmItq2pyvJrEhiwoPxKBTQeJRieKMn9oo9DrWlQeDFJg+sITe0rT8Qxhy7h/P9WkvyRzgqb8Z1 ifyfAgAAAP//3FzbcttGEv2VKT1s2WVZoiiSsrkxqmRdHG0ljkrUVmp3Kw8QOBRRBgEGACXTT/mH fdo3f4s/JV+yp+dCzgADCppQdip+kC1eMD19Od19psf3wzFPgu/uh3FaMPwcv9k5OOjs4J/hopxm +Zud03yP/SObpmxU5mFRpDynd8dhyd/sdDsH/Zed/suD7nW3O+x1hp3Ov3foaTk+khfx+OrNTqfT O+q+etURr5dBOeWzgid3vGBl9t3+/bAM6GcufkII8W36UbKPs2RYzMMIC81zXvD8ju8EzPqOLffB 08ntFuaG2+JgI9YWgqIM03GYj+NPfIPc3aeTOxhb664FhNlX9j7c2vqnPKlYHOtc849Nxix4tMjj cskmizQq4wxOSPKqL2nPuB9G2WzG0/IqTG/5qAzzciV7b2ffdLhGAQzHc6wg16QHmSudpeOmdaqO nV/Cg+HGo3KZcHzpLoQiTpTUfMJznkacRMVK6rN6Jf2uvRR9TjyRfjSob499+QxtCA+zHdGOi76n fQ9axHOcljyfIEgLNslyNsvSuMzyOL1lkItFWVrmWZLQ74h8dsOn4V2Mz2UT9n50XrAwtwMD21YR BB9YaWSwtQ00+8c8z+7iAi5IskbhPLyJE/LM1QZZDHHTjc4jLNZgLMaLAi4chwm7WcTJmJa5SbLo Az1xBYK24Y62tu+qv5ZBYa271vvGPZCJRzpmR0DkOOLskjQ35rn1QHsjrzw30m3hgV4bKTOGBJfN kMY2Rc7rp5PbnVEoSBYFp/gYxxOBG6WMlEmezdhskZTxHAhzx9NxlhfsZmmL386OWCU2DNlsuK5v KdDGcLMwDW854XpFgByB76we3DqzNXA/RCRnk7OcnlIu56geijlPEpE27GRRDwoK0DLmTS5lYFLX t9ioa6YZk04UfHJYupyGJXApZYsSwPSJk1eQ+asuQbqEnJR0df6UrzycTSpm0AmqlnS7XalHt6KR NZWaN6Su6ynQNAmXHFaKk4Ql/I7n8AaRJfjHuCgJH7FAmUVZQsA7Zqg5QyQYbK5gYz6JUz4mBVx0 r0a7j/cBIVzwnpfIUZPKzlttLNgVUr0/u/7xp9PKA0zVGVWEVlyTg2+xipBLwfJGFRHsWWLizTlp YW6G28lht3Mk8o6IwFM+CYE5VNTZ71waL4kK7A8/5SH/PEfuIXi86JLn6+TzA/nQLotLSs/ZoiTk pE8VUTbnoiSRn3+G6El4WJTitTS7f47+gxn1ufjWOtmjpBGFQBIDE4o99n12Ty66q5anQEQpw1Ee ICcijaBwQGYf5+GkLFgxze7p20U4I7C2tG4lxq5v6d1zJ8b+oHty9mpnQ+AZQVQJGriD3bwcX17Y QGiL3tuB33h0iS1ED3YtlVUla5cGTLD2rYDrsiqwNhStwTbL90lq/Sv9G7EnX1n7dgAkszZnK9W3 0q0LKpKbIWYZ7Gd2ieanVhParFase7QpK5jpV7hncHU2up4skooyWkFvgwOsold2kav819jVaZEt PDZ0tk08FtqRPqFAuaFRACxFEnVk1uPoqQpwLyIjErRNAGOx6k4k2s3QWBHe4FNpkaCmHRO40WdP 1o2MQEo2z5I4QoWzZ6MSBNtOLiDbzlUzLP9C/gZyq5a4I/6Qo5Aq6AO0sv5bfPmPZqN1rLndZBSj FTeq6xUHoWvqYjGfZ6AY1gU4NF4uQEHZOrMj17fFGTyM5DXMgM7qXXLXt1mpS9AMcn9DRvs72ewB mHOr3qB5spT8E13ImFMTWejEKqrBSRYtkM1TNkmy+wpAYOPwEEFUHnp2J/0jt87Pjo9OB29l9gxe Wus6NX7o2QM41lcaNyRQCm5QpLcJbsIC6LDy+TXvJvoLoC+18gASeDx1ZlWPh1Qr7XvSlv1XNe0/ cvfAto37N13Es8ByCCkSqmGgMsiqfYOVR8yPbrDiKkutXQyo2Mj5gQ//wMtinyIDQVMsoikLC3Zx Odq/OEUf9DO/YZM4ASkn2xP6nHqhAvkihlfG9KrmDofdRmP2ev3jw1MRTMqVg2cOq9m52SooDvuq j1QZQXlJ/cFu7V5PuSRH9PK0ukw4eIVUbJYyRpdWXVfSBOvtbLEqkEtJuWx7eBWCj7OHW21gZM3M R6xTBqTOXZihve8YZ0VEnUSiD9pl9DtI4E/qV6T/szTKl3Pqkp5LN2w0yibnP/vI0VCFJIugHsEL FEUWxaLiuY/L6Sa48iJTD4eH/Sa4qjticO7wcFhX+Zu7tjUqYxO4vOoJp7hV/y0DG7eqwBPUky42 sEIKrzLDKdipOi1ah5byCrdntgb9nldd4BSxrrsbMrEDtA0V9bzqAuf6jSoK3m50NRlFASV7S14U 2052tBVpV40uw117XsUAtlwvPusqt1mItbuaKvfK8871m1U+aqNyfTqyrqzQbyQLFFVjzudM5m/Q RiClxYnnrnpJZPR9NHo8nKmEjZauYjxT454Zu5XGRe1gre3WuhevAq3XC/BGrTdggeQy4AGPJ7qh 8BL1UcpA20VT6puJXbZ22xQmBlarCMtxgDFGAkJmqzzB9E7PbP4YPYGOBpdNMngppVYcbsQJrPIQ XaAMenbSf30uUkZ7PlnQABaHYOrSN4+/Fnncj3lQm1EZX9WjV63I8c2b8c3yMoAcm7GrWque7r2W 9bShzL5vpnxEAAejeBZT0Ya2jc5qQMCju6ewkxyAccKOT1xdvN0/v3jLQLYTQ5Atbqc48wFtn4Pc p3Mw+KVoUSd44ixDsboGWrSwqX7ArqC/JPcvFkTXu/4k0fcY3glBh+UUunRqsCJ5FP8jT5cUKfT7 b/9jhNjxJI40ZbG3MdgamgttBKtVNCrJLTYXcimEqmx6Wgbs1n2871sNNfp4C/TxjU0jwfZ9S5pG oNnM+16II6yQpVn68jbDYRKiISIehrOU3xtnoWin1qc4FEcJTmgXODyVIzjS59dceAXZncprRmn7 nac89Quk4D+/Y0DbmI6DbxJsSVVPQyu7OjdhH1C284DtHV0q0ntuTYD9gIPsyxAH23k4n0r0TRcz mdri5I6aKjEp1lm9d0EjZ+K1A3oNG1VfoC2rnLiBHvry+Z+YHjlB3c/GgFmi8NrY30d1RmL7apsO zvNwxu+z/AM71dt7Gsf4Frtzl7pX/NdFTGUm2Fiav8JgB09pUK1gz2Jx2I0kSKxNmC7FobZjfAIj RWJWAjQN+/ndX8ojvnx+F86x9zBZFjQCMIGCnOMjYnLEgkvLc6zTnL5nO9k0Aq1QdEPgCtPKCmMJ IXdZzsXQM1g1+u3XBc/l6+sJS0nwmiOWK1pfn/JZOwSCIL2RDGaW82wje/U5JtG4mzutz5uI9bcG 3n+eGD1mVNAmfJctUpSIfIzjrPVgCPuRhpZU8JJVRfWrbUR53rKTRQT3PVvsXn14VzUxhoUgVfNw NmEFyaU+JHKRrCTxStWLPBtch5R1L1IeL7p05e0VfVnFtLG/hhN2W93rsMC+NMvZ9+wyHRs6lSyn IZbW6Ga22AxSzzbRIU1dvY8mg03BPMngVoK1OIEdePavjvUbzeTOyq1DY+DZ/jhErNuuBRk98Gxj HOs3qqgVGe3WoziOroQz4kPH4cA3ET8C/oLVRPu5voXSFvcGvtmzLl7duHRBwtKME6kG3yxBgAcp ojy+QWkZ3mR34iKHhjaS20oWii4VnIl5evIQK9GujfvzVAInWY4EP89SccHDMp9Vdw2eMGO6I+1f x+/fNWU+aR33905p7FpUMLX5JzNQv0LCdMv3jO/d7jGxOzkc/nwzNitPxIUVkAwgBemEm2od4cP1 su3RHmujJIDMi/h+spYa8kgawTSeb30hm4DH0dCDOg195JvG602IrX3CBexTnBFdHL8/Rld1i+Yw X9LNNNxPBckk6F/qq8WkTMN4lBybXEryuX5JTPiIXqcGfQ1MsNZDU/G6RSZYLrWC5L8a5n75/Own MVsSJgkokOP5HDOu+v4ejkBKQZ6IgUIM5lO/RVes/hT3RgTJG+ZwSIIg6m6I5tF3GOSBA0DKuGWw v+Z+i0djU7tsuj1SVGCtduRz7I5mN8MiiuM3O9fxDPTue1DbV7iHl+7gnekxgtL5TlTUXxZiPjBd TKMa/6lkYVOoFl+/FpwZDouXKHgiMR1JV7HIXsS1RqhgMYi3IiYlK2OSdsTNGWwAmH1NzcIlMcsU Y6ZpCWQSt/2iNXGLW064HE1j3VgqiSe8hMa0b4DFq2zLwPMj356jfo2gjqfKnA9qTuGhO2m7UjQy k8qW9UXVwwIyxkRzwHTGB0voMpTuyK2PA6FmAC8KMQSUvD9G78ozBkEgx4AFGA6cIQBhFn6w3hQn i1l+G6a4ajfejO+P9KdfLLsBlLcDx9sLWjNfWQfIR+ren9hwgrtUVzxFCuXjSxw+vcVR1QchRBmM Frc4jaJrCD/GOMMpYQS7k7FPqY3Zy9USum6ia2YGdaKxxDplOfG6Zy+XeoKkKNRTBl8+s5cCIcRp jD6uGOLlkyn+BwNMVIp4fsEO6NY8ZhfhhnT4pc41nsZLqCAy5VvB1rAqVU9KJaLjq4tlwKc81DQO PaAmzACU4l6oQ5sDW24NtV9HnQTzWB9oVdPnkS2Xr5ltaNRR8scnUY58iRY5HovAp0iizoIQrdZh HPkSJY3TtwYo6OQgIm5TmY9Y6zSbQT9G7ETsA6/I/Qh+QSvbuPmqX2qt/2Zs1cPutJQCj2NcjD4L cxQHp/JeKVz/4mz0brjehuXWzaiqH67lfUJUFUttGVW3l9sU9lVLwtqwGw7sZ/VhP6r/qPuraN35 7XYTtfMMgxrs99/+y16sXPMX+LG1AkXU1jxwhf5fPr9kBrezBqwX7DX4HmSkb4P9Te2b4fXfJFUa uhJHUU1yknAUpZYJYcHq3LXbxQjD2nyznXsd6GxoPXJr/rTtuHT3ClTzowIRNwNF5R4lWcH/DwAA //+sVE1v2zAM/SuEz0HrZFk3BI1PSYMCW1LUxXpWJdoWKouCxDRNf/1oJe2yw4Ch7cXghx75RD7Z 7WFnuYPryW09gsvz3Yyr4Rury90sRKJmGSNIdB9wXqSAztWsIhfnw4F8iqs1sibf/Bd66c0pFp57 N0tBaakeIiaMT1hUoLz5AJmezCdyuV+lM7jrEO5XMivnQFPfb73VivEwPHxmjF45qBebBM4+Iizv 6mtYX/3KN8ko9Jq2UbUIFNBDEkej1DIIBp/QUejRM0R0UtcAE/ChZ9ICAOuBYqu8fVFsyR/bbNZX 797aRmjILvXj581qBJvFj9FHtjeQkrG9h1J19hdKRByyiEW9MVlzOy/Kcjoel+VF8RpaYKO2jk8y WdYJNd8Mqv8Hrpb8CSZ3aesXAezmxXgymZZDh07sr9/FzjVD+1Plh0RB4tPDkWjbTiq9ug/ETP0f 32Fzku1QGYzz4tskl2+IRHVvbrvl7B7baXJJOBxf1gDJLAzpVbRGMs56vLGsheWXi5yVgR0unn8A D2T22RDIdlBm9RsAAP//AwBQSwMEFAAGAAgAAAAhANmE+NlTCgAAVCYAABEAAAB3b3JkL2NvbW1l bnRzLnhtbOxY227bRhB9L9B/WPDJBnSh5IscNZKh2DWQomkDx0WAvq2WS3FrcpfdXUrWm/+hTwXa n/OX9MySlOzUCCwDaYMgL7pwuTPDmTNzzvLl6U2Rs6W0Thk9iQa9OGJSC5MovZhEv1xddE8i5jzX Cc+NlpNoLV10Ov32m5ersTBFIbV3DCa0Gy+xmnlfjvt9JzJZcNczpdRYTI0tuMdfu+gX3F5XZRd7 S+7VXOXKr/vDOD6OGjNmElVWjxsT3UIJa5xJPW0ZmzRVQjZf7Q77FL/1znMjKoo5eOxbmSMGo12m StdaK55rDY+YtUaWH3uIZZG3963Kp3hLLF+hHkVeh70yNimtEdI5XD2vFzcWB/HHfDcJJBObHU8J 4aHPNpKCK70xQ+j4oP6b4vVQvH7tu0+mtg+CXEy3WGKrsUom0YsIP3jlM4Pantse+8Fkmr3zljun paXVhHv4G8aDo2581B0Mr4YH48PjcRz/SqtKK6947ibRb8IFByWuAuTJ5SSK4+/Pjl5cBCfh0rlM eZX7eysUUvnWhq93fp1L7F7yfBKd1Zi/kjc+6k9f9je3hXttvcU+tuVSptKitWSzr7mXa218QCFu qC3Wpsi3n/5kPEOdAVk8DvOG+UwykXHrpe2Rex+CwBYKJXwi1QTxf2f1AD22e1qHY2T2aWk9Ggwv Xo3IyYdpbVY+m7TOFlbKXdMXnmxXVH6R6TtXjlMGe+wqU44VfM1UUeZrxpnIFcDXddKCVFjJLU/U oviOrSRzmanyhAHvbC5ZrgrlZVJjWrmdwQxe+grmMCO21biUpbEg5CbTyDJNjnZsOCkqC7pFvTRf SBoSzK2dl8WuyT+GSvikyT8+GY4GZ49Nkmbls5kkF8o632GvWWL03e2fSHam9DU+ub+HeVdKoVL0 h14zIm0QStsaPXZhLJM3HA0kO7RnBZ5gxqqF0jxHUyXKiSpwPVPaU3fNuUPnlCZXQkmHTZkSGSII vaU0W0iwJPhCGE3aq+2xez7fSawlHWbAJ9s2dWxP9ha9Dvv+bLbPOMIoDD5KK0F+BBfYrpzEYyTM Sie5FVmYARamFJZdE4GvwL9LieDNfKlM5RAiEkLklai0IUK6fS79SkrN7m7/uqi0IDV2d/t3cIBL s82Fu9s/yHnKBZINM0hlWcI/PRpgToYdL+SuQB4NngnkwydS4mh0OJg9SonNymcD5C2CK53gPECa H3lFjWiGkHDpsR/NQgnCZIcJXvKg3gHALVL43EGkCao012ADogEIdra3/Wnl75UCeMKqZyZ9YGq/ w+ZVDRTSiWgVQokpS+PAFi2Qdy7zwdcyB1Xpp4GwkdJVtsbQomZGnxUGehlTiEqOueCtyakLlQY5 8IRqVFPGrnk/eabiPBh8ce31HvnGgMZ415JUDxrrdEcBOoiPngfjg9EXl87ttHJSssys6lGVybx0 YCR+3XACyVLZsisBmQs6N7co76EHBCZVIlOlwWssW8+tCoi/fDU7Cw0xox97DnI1r/nm7ZvZGdiR 6FOlNe3V1J8r9AuuBptBDNRtg3tO2c+W6o+lTIprNgfxsgcuiMVBhDWLBtrdo3bMEe1+PU5JUzyG GRz82iMXHWE/FeX46XvicD43GNCc5YYnECI514KmdIqZvgI1/K8BXkEGUBHYwoBgjH5sXv1X2aLX WWNXcoHXFBBQ4UAUTd+QnoJmIcFSGsi5DnswBXB0vl/Lw9Hw5CSOSCT4aSBjAjRRLhmQNwQ4MHMA NjAqC9XdZ6QcMWH4jdGmgAJLQcON8k8bjYUeeZ0SqiBSOYzZCtITJjUAuj088Dl6B8FuumPTBK1t qMtGQvp1SSlvmSIcLjbeOmwtPaQhWizETG2Hp2l1cv1gJAYFJ0aqewC22jNi5cN7wieUs0lYm8O3 eH8Uxx9cvPe6515+n/G6x29q/A8AAAD//9xY3XLiNhR+lTNcJyzhJz90ocOG0NKLNBPo7EzvhC2D GltyJRnHvcprdKa97YPlSfod26Shy04I04ukMx6wJUtI5/s5R8hBI7XSSbuWjeF8JSlfmVhSapT2 ZCL6+CHv+yF/2uHHzcdNea8+VO3Vkx8GIhULFSuvpNs1zNN9EvddKoKtHyW3Mlkc0kKSNxTKSGlJ QpO891I7tcBqEhPKmPxKeJJaoMXhQWLESqyVsbxOfo4yHXhlNHoNTxdKF1i1kCEpTeKLrRC241R4 e2MHjVare9Y+P281yk3u3p+TZUQWmYpDpZe0iE1w95qdHtH1j/P/Zi1e3BttkmJnnIfNrWZgl5ZI BSZJpAaaeb++RQhUOGicnHQbuBWZXxkEY2yb9INZaZp5K5zT0nJvKDxwa7dOeset3vFJe95u97sn /VbrZ+5VGriL2A0avwSujGKK1jK+z6K7aRrLSGSxf9bDi0qruKczXwD0vL8W8aBxWS16Djo0KsLV r1V8rIbYXUNuZSSt1IGsx9nqXaG18YJ5ghdqCj9R20MDyhEupxIVC8tUyhzDPanZJWL6VCLPSM4K 52VCY+nUUr867O32gWHv/O/CPp3Q7KebEUfeZ1aXmkXoBX3+7ojFrUl5CkqjyDxM5je4BSS/lGCn CuBXsQoKiqxIZG7sHVsCz/d6SM4OhKS3JyS90/bl1Tn/SCmOZ0qoe96KEna79TSiXIL5oL0IyaUy UJECWp5lI3BpGi0cfCPwNBZe0LxIZY0gBuaMoH58+N0TvLt0fMBlCxILk/kS0lBFtW7h4T6XgJ4n vZniK+RbZCZpI2SR5heWzrFzRYLgRkbDXj5DuOzVjuMdrATMbdLqjjaGULriS97Y6R3CiE6/sy8j ut3eqDPexYi6560wYvj48Md8JYvHhz9ZpyJZqGVmMnfEwLNwIUiHBMOe26Rr48lllisK5O3CZCTw 4G3BZgppO4GJ/nptpupeHIjGxZ76fA9obMyD8+fVZe9iclFm3K8UWAyElb9mykKnEcolQSwFiKhJ t9NPpawm/A14AgPsUp+JOC5oo0TWJXSH63o2+QbDeVQ5Dw9jJmB+ZzIbsCkDbDRt4YrUbo2JrqzF yj0MYdCAc8TxzGMZLEaY4df2NHSZDPea7UqHL8y129KqshPhSLjyLNkK90J9wB1e3MG+8pVCRVIF oNowV8wKNN9a2R6V1umB/O3um/JrPmzCWRW3/2p8lnSe0ectlF+7EZp6SkQB4w8lKIzKXqQgVGoV SlIGqSo+cQ+EpqPrEdX4MdmtXCokK8uuswUWOFcSb3ex/+JhZnhEC2SsKYWGUFCC+ErfVfQvc6HG UjcHkX/SJEpGdskn/cFOoTpWnoixSM0bykXhuH4JcQaDUyKxvpplZwcVlp1+d9+c9W4INfzepDLK 2M5KWOo0FSnrPK0lajDoHMFm5hyPkclQYzCceC5JtgbhQhNkfHD6llD9OIOX4rg+czqcMoEZLBAQ eoOCdbmEFzq1lltk28MZzg6sM7qne2a294MZ9I7gS2G5pkA+gWQQaA4x/hwQXPyHjJZrlvKrykkn Ja1M/oRyaoAC/ip4STtApj4Mu+HfAAAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQGwAAFQAA AHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbY UKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX 7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduL lErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQav iZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5v ftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9as NVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizeg iNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7i eCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE 5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQ xkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLP EXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3 GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvS eoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/B ULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWO u0+vBrdp6Ig0CxA9MxHal1CqnQoc0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oyYftE+V2E O1l0u1wE9O2vuVt4kuwRCPP5jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMeU8YGasrI DWmaZAn7RNCHQb3OnA5JcWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc7MxwJW2N hyZd2WNhUx8YbD2QWO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb3YhmSp3D rVAZfDivGgwW1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6clMeKuQmA 2KnwkT7knWK1EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56yMdp2xvD mRYe4xS8LnXPh1kIF0O+EjbsT01mk+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0zFQWAizRnKz8 y00w60UpYCP9NaRYWYNg+NekADu6riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN2ETsY3C/DlXQJ6AS riZMRdAvcI+mrW2m3OKcJV359srg7DhmaYSzcqtTNM9kCzd5XMhg3krigW6Vshvlzq+KSfkLUqUc xv8zVfR+AjcFK4H2gA/XuAIjna9tjwsVcahCaUT9voDGwdQOiBa4i4VpCCq4TDb/BTnU/23OWRom reHAp/ZpiASF/UhFgpA9KEsm+k4hVs/2LkuSZYRMRJXElakVe0QOCRvqGriq93YPRRDqpppkZcDg Tsaf+55l0CjUTU4535waUuy9Ngf+6c7HJjMo5dZh09Dk9i9ErNhV7XqzPN97y4roiVmb1cizApiV toJWlvavKcI5t1pbseY0Xm7mwoEX5zWGwaIhSuG+B+k/sP9R4TP7ZUJvqEO+D7UVwYcGTQzCBqL6 km08kC6QdnAEjZMdtMGkSVnTZq2Ttlq+WV9wp1vwPWFsLdlZ/H1OYxfNmcvOycWLNHZmYcfWdmyh qcGzJ1MUhsb5QcY4xnzSKn914qN74OgtuN+fMCVNMME3JYGh9RyYPIDktxzN0o2/AAAA//8DAFBL AwQUAAYACAAAACEAVPDOsgMNAACoOAAAEQAAAHdvcmQvc2V0dGluZ3MueG1snFvZbiPHFX0PkH8Q 9JwZ1b4IloNas8BODMv+gJbU0hBDsgmSM/Lk63NaFC0PctowgnkYqm9X9a27L3W/+esvm/XF53F/ WE3bm0v5XlxejNv76WG1fbq5/Pmn/i5cXhyOw/ZhWE/b8ebyy3i4/Ou3f/7TN8/Xh/F4xGuHC2yx PVxPN5ef9tvrw/2HcTMc3m1W9/vpMD0e391Pm+vp8XF1P77+d/m6Yn9z+eF43F1fXb0uej/txi12 e5z2m+F4eD/tn65OK+t0/2kzbo9XSgh3tR/XwxEIHz6sdofzbpv/dzd86sN5k8+/d4jPm/X5vWcp fu/N1+M+T/uHX1f8EfTmBbv9dD8eDqDsZn067mZYbc/bHNZ/ZJ8TPb9b3e2H/ZffbPIt2Pafadpc PF/vxv09CAqeK3F5NQMepn9Nx7o67NbDlx+GpzFPn8D2/Wo8vICB1/R4exyOI1YfduN6/SIj9+tx AHbP10/7YbMZwNPTk5c1x/1w//HH8fNqFq/TNg/j4/BpffxpuLs9Tjus+zzgSP6MxP2HAWuO4/52 N9zjA2XaHvfT+vzeC45l2uz2INEJbYjXbji+fA5S/HCYjzL/+HGajudlQhSthPenFTP0DSKEkFVS iBTFL0CMWIAoIbulu2mpvOYQVapZgLTQOMToznHTxluOgVFWZrqbU7UFDtEicay9l43vFnXvfE20 qkb6neS0dRSSXXCcc0VUuwAx2XBI1bp0+p1qoqkc4lLmuzWdu6JrumiZ8lQKV1tia6TSWdDvSGVz 5RCts+Pf0bZ0eh5pQDcqIdI4HwvFDZKj+G5W1kIlUVqFE/HdVBdUDqQzIfHzeNUap4E30lPplZDR QvVHBuG5VMkghebnCaZqTreoeuU8jbo6vlsSNVJJlMkZxemWhQ6cC9mIxKmTbVmgTnbVUemVRSTL MSimcUshi03ciskqsCGVgypC5vyBZkcuIdUlwbldwW5OnSaDXoIkbkdlQ6zBMWgqak63Zjy3sLLB 8nE56E5zXwKPpTl/lBSB64KSMmfKOaWkLdQqQ0udpdRRCjylMqq0EFxClFEi8+8Y5QO1LsoYz7kA SOvULygsUZQ/yiqh+Hesc4FKonKyZ77GKdOo1iunIpc3QDqXeOW0NlR6lTNFUV1QzgnuS5QHuznn gi6R2gM1QxbWmF6pXKvgKpdrFZXhvkRFSC//ToGt4LgVEwqnTrExUv1R1RrJJQTWLVOrrKoLie6m hZKKrgHEZqoLGh6dUweQ1vlu0iRPJVFLh3/MWiKETYGeVCsdE+UcgkGlqVRpawyXN2198FQXYI5s pjqnvXKCYxDgazkkKWs5RZPy3C/ooqTj5ylGcs+kq+5RU4pW4+wCxGMZXdNsWaBBc1FwbjcHmae7 deEiX9Ot4dGTESoZupsRzgiKtZESmTPDwEgLw0MhainaMPAlXOeMUplbPqO0llTrjXLNUzkwGhkY tb1G6wV7bYzI3tDzGAO/ySE28fjAWNcqp5tzPVJJNF5YHsNCGU2lNhGQwD2TCUJoztMgY+LnCabF TE8aTSqcC8h+DLVIBnqqOH+SSYZD5piPU6fCVnEMqukLuCFfiVwOmmieWiTTdeb5qRXSdrrGStV5 pmelr1zrEWxEQXlqNWoBVE+ttr1TGljtBbfK8HKdS4i1YiEetU4VbhOts8VRu2Odl4pKlfU62gUI QqQFiEXIwyTReucstTs2CK2oBtugvaFSBUhPnAvBxsbXROd5Tcgmlw2XkCJap1qC4Lpb/h1kRoHv 1nThHtAJt5DTOnCH89QhwOcajL2yoRR1SiBlYfwBpPHswynZeBXHaWES1VOnZeb1nRnCPaBDpCyo FUPGJHge7KxQPEd3UG6ezwGiF+hmZQlUeiG6zlG/MEO45XPWdUl1zvnZp1MuoEqROA2CrJ3aXheQ F1C744JXlkqviybzqpSLrvHo1iUpub12WSJroucpKvGIyxUXeVbg4Et4pueq0TzudRUmnp+0+uao rXLNFJ7Tuo7iCqW1F9pwj+EhVJlqFiJymyhu4E7kOQbCa28pRb3yKdLzeG00z5m8UQs5kze+cf3x 1iEBYTz1Tlhu37yTUVE/551FmER38wIGgUOULFTnvFeV1zo9aoM82oDpX4IEaAPndoDscC4g8g+c 21F7Ltc+ic5tok/GJepLfIL9r5Q6yQde9fBZ9MZxy9prail81n2BBhVpPV/TEPxzznWdPOdct3qB p8h/eIzku8OJKA06pJRaS6SgNVDPhGADlXK2GwrB2VCsg5KRx2IBWU7ka9BI4RFKgKHgOhe0VQtY G9F5lBaQSnCpCg6+nloKNFgar/uHKBO3vSHOLQFKN9RnF05adFmAVFW5noZqC48TQxNBUC0JkERu 40MzmVvL0JwvVHpDV91Q7xyFqbz/E6WQvH4NSOC5cwTOnHMwISA3o3U0VvEKYDQu8ywnWlF5nSJa ExXlabToQFEtgdNe8M7RiaSo3YlzyEX1NEJ4G/+OtypS2xtR0eSeKUIZuN0BZCHjj9EIXh+NEahx rJNRhWMNS84rWRG5M48gAWlKU24nW3k/GCk1AgS6JovAawEx+8Q7ArFYyXuhEZLDM4lYZeVVw1hN 5X1NQBqvlMTqnOG0bmKhfhAbInwuIQ0BPpfEZuWCNnYruQ9OAo6B0joJXT21FFAEwSU+aRE7PWnS xvBeQbLSauplkkN0SU+avEJfkUlI8jrx/gIgleclCHY6t28pysjrbwlRlaf2OkF/eDSYgDO3/qkI w6v7qUgXOEWLjFJRGhRleZ0PKoL4lq/Rjcd8qZjMs4JUbeW2KjVRuQanZlugfjsL9PLpedAodpLK QUaNy1I/l6VOnG4ZmTP3mhl8k3w33Hbh1jJrpxuN/bORgVdkACmexr0I0QLvxmYrRaJakuE0NdWF 7CTaH4zbuGaxcN8lw/IunBTXKXimlwM6KVRGM3IMQX1Jxo0BXi3KyUbeZ8q4B8Nj2Fx0XeBcMZ37 rFy8WvhOlYFXi3JVIXNuV58Tl52Grh7nQp/DJ8qfjltUCxCbuIUtAt0KygVAOu87F2EXpBdBSHb0 pGVuBPLvIKfmEl+QlfC+MwwSirSMBij/1UjtQTGoDdKYoqCPzuuWCAI0j9YRkAebKAbWGh4nFidz oTpXnOmOWtjitZIca496FZWd4lHB4GuCKAtygNNwy1ei64FTtKBXQPW0AMJz2tLg0TluyFx5dbJ0 VDco3SoiCo5BFabwWLmi28dv6VSJ20DUWla0XHnVvSpfuAbjml2rlKfVeMSDTHaqFQt3cQDpvG5Z rQ48CwWkcMtXoT28J1Fxn4Jzu3qdeZ0cEPSX6XkCtITagxqc5fpT0UviWVuNEmUh+p2ocK+SQ9AR pnanJqW4RaoJBXnOn4y7IxwD3D7j0XqFE17AYHa1XN6y07zHUqvDdV160orrYvykiP0XuNBw8Yqf tC/VLWt3jVfZmnAL93ub1Oi+M6wbboHwTkqT3vKIqylUi/huWi1YvoYmP69fN1y75ZUFFDozj4ib hx2lnGseUQC1ic0jGKMxbPPosFO/3dCt4DcGGgovPGtruInJ6/4tIsegEtISXC2Vg5Z81AtrfOVy 3RBcco8OiFvg9hw6cOoU3O+lfq7BcfPaeisWDKLyhltU3Lq0giCW6jauP3ie8bdmXeLc7sYtSEi3 IALDrYOl3I52ie/Q83QUi3idr+M6kqTnAaTymnfXqnAf3FE+4PfFOtr/vAuHgwqem6Hov3DTojtZ +d1JXBLtvDfV4cy4VHVc0Oedu45+I+dPx2a8k48wBJE85VyQntfs+lzs5JxLtvGea0eqx28hdtwO 1ByDJhd8cEdVt1Fb1WHGGo3FOnIMHo925Bg8d8bAw0LdsiO6PsWWV6fBFEyobK7noaMf9udfHVMu F5vTKEwZNnf71XDx/TyWhLGWzfXd/mNebc/wuxHjUeNvIbef7s7Ad+9OgMNmWK87JmnOAEwknSAP GPCp4+PLxuvvh/3T284vTmVzvadPMbfzz193myeHxv3f9tOn3WnX5/2w+8f2AY/PH5S4h3WCrbbH 71ab8/PDp7vb86otppN+A8K40b8/7+dFV28Eer4+YqBsnCn03bB9Os/tjNt3P9/Orz5f36/3t/PQ 2fj9sNthZAiv3D3Jm8v16unDUc6jSUf8hUmmjy9/3D2pV5h6geGvGfbyx3A/nwxvv/6YXzj9xFuv P96e6fMz/fbMnJ+Zt2f2/My+PXPnZ25+9uELxrEwT/URw13nn/Pzx2m9np7Hh7+fH95c/s+jExEO H4bdCL7Os1UQsOn65cHrsNXh4vP1+AtmvcaH1RHzfLvVw2b45eZSiVNg9Po25r6mT8ev3p13ml/e ffX04mE4Dpgce2HVV4vBOgyHfY0LJsvG+xUE8vbL5u5tlOv9CfH16nC8HXeY+jpOexz5ZRzsLy87 v40YfvtfAAAA//8DAFBLAwQUAAYACAAAACEAA1BAKn4BAABuBwAAFAAAAHdvcmQvd2ViU2V0dGlu Z3MueG1s7FVLT8JAEL6b+B+avUtfpEBDISEEL/iIovel3dJNdnea3aUVfr1DQQX1YBNNPHDqvPvN fO3McPwihVMxbTiohPgdjzhMpZBxtUrI02J21SeOsVRlVIBiCdkwQ8ajy4thHdds+cisxUjjYBVl Yp2Qwtoydl2TFkxS04GSKfTloCW1qOqVC3nOUzaFdC2Zsm7geZGrmaAWEZiCl4YcqtU/qVaDzkoN KTMGgUixrycpV2SEGDNemcPTqWOeYYthEIZR5Pca/xKyzZRX6KuoQCdxd9GS6jnL7ZvVe7c+8FXx jXkB5dfYCVgL8pMd8UwyvXuH/chROFmCgWabEJw/CiVNcdaNnIIAnCtdW9jDEEfI2mUuTxC1y9XH nbdJdRsSmqb34ikdQdgd9EIvGpzpaPMR/BUdfhRFnh/0g/DMx3/gI8B11Q1Dzzuvq1ZL8jf/j/3a as4IlJZLvmUz0BMNtWG6uRd4vjZ36vlm3mhUCKjvb69RwdSjKzl6BQAA//8DAFBLAwQUAAYACAAA ACEAekoIgM8IAADWRAAADwAAAHdvcmQvc3R5bGVzLnhtbLxb33ObOBB+v5n7Hxjee0mcNr526nZa p7l2pk1/OJl7lrEcc8HIB7hJ+tffagUCA4LdQO4pBaT9tLufvlVS7eu399vI+ymTNFTxzD/549j3 ZByoVRjfzPzrq4tnf/pemol4JSIVy5n/IFP/7Zvff3t99yrNHiKZemAgTl8lM3+TZbtXR0dpsJFb kf6hdjKGb2uVbEUGj8nNkVqvw0Ceq2C/lXF2NDk+PjtKZCQyAE834S71c2t3FGt3KlntEhXINIXV biNjbyvC2H8Dy1up4FyuxT7KUv2YfEvyx/wJf1yoOEu9u1ciDcLwChYOLm7DWCUf38Vp6MMXKdLs XRqK1o8bPar1S5BmFWvvw1XoH2nE9BfY/CmimT+ZFG/megUH7yIR3xTvZPzselFdycy3r5Zgd+aL 5NninTZ2hG4WPyvu7g6chydcyk4EEDjAEetMQgIhHxonCnWiJ9Oz4uHHPoIXYp+pHAQNAFjVLDzW Ig55hSwvDEvgq1x/VsGtXC0y+DDzEQteXn/6loQqCbOHmf/ypcaElwu5DT+Gq5XUpMzfXcebcCX/ 3sj4OpWr8v33C6RYbjFQ+ziD5Z9NkQVRuvpwH8idphiYjoXO8KWeEGmzaQUHF7QPy9WYFzVUfPlv AXlictiKspFCbyMP198JhF7vBwNNtEdVB9Aua62nw008H27ixXATSN5hsZgOXwWI59CMGG5UWElP aqYCQ75qHE5fdlBWz2iwqHdGgzS9Mxoc6Z3RoETvjAYDemc0Et47o5Hf3hmNdHbOCAQKV51FpxgN 0sa+CrNI6vmdAnQyUOryUuN9E4m4ScRu4+nCWl92l1gu9suMtlSU08eL5SJLVHzTGxGoznrrPlqT P2x3G5GGcKLpCf1kYOivxDKS3l9JuOqFemHI1/AJDyatJexbJAK5UdFKJt6VvDcZZcy/VN7CnDJ6 FzcwrZ/Dm03mLTZYcnvBzhxBd0fC2P8cphiDzs105nClzzgph2cOXrqNf5GrcL8tQkM4jZwZPWek uQaBS+wO0XOdoubu6vVCJ4DigikXfBfQPmH9prjw7escU9ZvStEj7RPWbwrXI+0jP7rzy1aac5Hc eqTtNWXv3bmKVLLeR8Ue6JWHKXsHWwiaC+xNbO2TRGLK3sEH8um9CwL4zY3CU3YuSh1loLDTYVBw s9F9YSelJnsnDI/YCaphTRhYw7SWAcQW3R/yZ6j/8MQtBqjS9qzZu51PHRGAEkQ6Q3/fq6z/DD1x aB4V5VMMfy5JpUdDO3XsPCpazidT7xg5Hlb4GEDDKiADaFgpZAA5+OE+89iaSAcZXhwZWGxZtlUM aUdW5ilbmS0QrwSMVDcJ5y/H7nVzoVk3CSjsBDXrJgGFnZ1aLbN1k4A1Wt0kYDmqhjtHVU3lOMWu m1UgexIgeDSOeBOAxhFvAtA44k0AGi7e/SDjiTcBi60NVlOr4k0AwiGcX/UtUFW8CUBsbTBql//N qKh7aKX7l9sRxJuAwk5QU7wJKOzsuMSbgIVDOEyoYVmpI2CNI94EoHHEmwA0jngTgMYRbwLQOOJN ABou3v0g44k3AYutDVZTq+JNAGLLgwWqijcBCIdwtKFVvHHXP7l4E1DYCWqKNwGFnZ2aoNpDKgGL naAalhVvAhYO4ZAhx0Jyc5waR7wJHo0j3gSgccSbADSOeBOAhot3P8h44k3AYmuD1dSqeBOA2PJg gariTQBia0OreONmfHLxJqCwE9QUbwIKOzs1QbU6R8BiJ6iGZcWbgIV8GSzeBCAc8lggjkfjiDfB o3HEmwA0jngTgIaLdz/IeOJNwGJrg9XUqngTgNjyYIGq4k0AYmtDq3jjHnly8SagsBPUFG8CCjs7 NUG14k3AYieohmWljoA1jngTgJCYg8WbAIRDHgGEu4iTpnHEm+DROOJNABou3v0g44k3AYutDVZT q+JNAGLLgwWqijcBiK0N+p4t3BclX089cZCAes+guNVABpw4kkQFzB38IdcygU4m2X87ZCBg4SED 0UEPqovvlbr1aBe7Tx0EIUOFyyhUeKX7AW/pVBoRTqcdnQRXX+feR9MA05iHlDq8eQPdQ9V2IWxP 0o1DsM7sYQctO7viZrm2Bg1Cuq8rbwHCPrRP0BCUt/XoybrPBwZiU1X+Gv/fNkfFf0PP26oYc3w8 P50cT3OPXA1S+B8/eXvUc/vQ3h6Vt2LBj4Mes5k/F1G4TELtR9FbNvMX4Xaxx3tQ2FJ2MCpI7Xfz f8+mOayc/GvzbH6Zt2ZBmxv2f2FQmmEMNhDHALq9OsKYX+a396vwKn89qI4b/7jAst2kCG9+8788 H5pxB/dP4RWwwLHuTN9y71gz3oLvzL+HQwxjmwuExjNcUt8K7Y0xHJ0tI9NKB//4FGsyQeMi8sKQ dnUvjFn4PpdR9EVg412mdu6hkVxn5uvJMVb6mqmlyjK1dc9P8CI8rqTNAIS4uhjz2M2ZeL9dygQ6 2Trif6l0hcSOu8OtZ+70mnRb7YDV486kRt3NiwNZsEKg12Lp21gU1vLyM65tKaCl8KvuEGxIRpMs cJ8QJ7HEJER+6OzO/Ck0fYAFcKvopHTQ/mC7Wvfmaqv7Z8uCU9+cIo4VNFnqlsfE1sE2P1u3Og5s ek1NFijegbBOp5Pzi3MTMVQn2OS2CfbkzHxIf5VNsOYdBKdHy9pznwcHu1U64pLpbpa2kFSrBUj9 bUGJit05iKiZ+z9FydBFx62MkqVQT5QOKBTsUxCPha6s9eJZ968eu/w7tgF5ZQRqG8dNKEcsmXHs pdbo1bbkqjsL+vCCjdSPqsmdPIbj7D8yaCprZYun+ZA2NleyaiIdA+9bKG0+tuQoxy8T/qSUXxof 5in87BcAJrWrrrjYnY9xE7wS0DIm7riNTW9egNqZ9V5EkVJxq0Lm30yzXxuhXPJYMVrG5Um5Ut/p V2KjtkKfUfIjdPlCn6DzJ/Sp3NND6g+VfvXQ1LlXjbmbeDRlrWCNTT13vEvVa/waMywHPF0tTonp m/8AAAD//wMAUEsDBBQABgAIAAAAIQAQLL6n9gAAAGwBAAATAAgBZG9jUHJvcHMvY3VzdG9tLnht bCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyQy26DMBBF95X6D5b3jo0DJSBD 1ECy7iLt3jKGIOGHbIcWVf33GqWPfZYzd3TmzLD9h5rALJ0fja5gsiEQSC1MN+qhgq/nE9pB4APX HZ+MlhVcpIf7+vGBvThjpQuj9CAitK/gJQRbYuzFRSruNzHWMemNUzzE0g3Y9P0oZGvEVUkdMCXk CYurD0Yh+4eDN145h3uRnRGrnX87Lzbq1uwHvoBehbGr4GebNW2bkQzRY9GghCQHVGyLHJEdIfRA m1PxfPyCwK7DFALNVTzd9xMfIm0O5WTffXB1km6TtKB5mjP832X4d1/N8Cpye1P9DQAA//8DAFBL AwQUAAYACAAAACEAoog5JmABAACmAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJJda8IwGIXvB/sPJfdtWr82QlthEy/GhIGOjd2F5FXD mg+SzOq/X9pqVebF7pKe8z6c96T5dC+raAfWCa0KlCUpikAxzYXaFOh9NY8fUeQ8VZxWWkGBDuDQ tLy/y5khTFt4s9qA9QJcFEjKEWYKtPXeEIwd24KkLgkOFcS1tpL6cLUbbCj7phvAgzSdYAmecuop boCx6YnoiOSsR5ofW7UAzjBUIEF5h7Mkw2evByvdzYFWuXBK4Q8m7HSMe8nmrBN7996J3ljXdVIP 2xghf4Y/F6/LdtVYqKYrBqjMOSNe+ArKHJ+P4cQsUK9tObNJ9KK3Klp6S51TYFvjSW76rajzi/AU awH86XBz4q+rGbSwE82Dlg85vryGUG0HXQjgUdiKdB2clI/h82w1R+UgzcZxOo6z4SodkfGApOlX E/Bqvtmy+yCPMf9JnJDR5Jp4AoS6QuLrP6v8BQAA//8DAFBLAwQUAAYACAAAACEAAsiKd0cDAABS DgAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbKxXS27bMBDdF+gdDAJd2pJlyXaMKEGaxECLNi2K9AC0 RMdE+RFI2o7P0GXv0Rv0Nu09OqQ+UeLUsBpuoohv5s284Ygcn57fc9bbEKWpFCkaDkLUIyKTORV3 Kfp6O+9PUU8bLHLMpCAp2hGNzs9evzrdzsSaL4gCwx5wCD3bALwyppgFgc5WhGM9kAURAC6l4tjA q7oLOFbf1kU/k7zAhi4oo2YXRGE4RhWNTNFaiVlF0ec0U1LLpbEuM7lc0oxUj9pDHRO39LyS2ZoT YVzEQBEGOUihV7TQNRv/XzaQuKpJNodEbDir7bbFMdFyhbdQZ87KtLdS5YWSGdEaVq9KsGEchodi VwW0FI3HMSk8jllnwjEVDY1tjyf732zeADYvKGMHlupBCNTiDJoJL7RRODM3a9579PYuT1HoTISm OWAbzFIURfMoicNLFFhnvmaGfiAbwm53BaltVruFovlHizGLlbaGF6y2mI+T6+j6bVQibGMBCg8b Ef41BctSNBlHl/N5Epc5rPmcm9p/sWaMmMb7ltw3UL9ZfZ/V5owsK+Pis7J5U2EF2eUUxYmLucLi zn17o3FoKYLtrDJWpY+aS2E0uGGdUZqiS8wo6LT5EqzNhaY4RX9+fv/964ddW11A2R5ZZTpFt5QT 3bsh294XyTFsIRhSAVnkZImhYFVkFxIygJLYdNsFGj4UKIzDkzAMR65AcFaopgjDsghwULSKlpOM clztBlC2q/YmGhxTNwPdYhOCJ2TuGgJi2IwKCeqGcVzXrrZsV9rBVvE/Sv284GhPcOJD8MiH4GjY NMtzgh3cWfBoT/DQh+DYi+Dp9NAORxbuLDjeE+ylpRMfguE0OCTYwZ0FJ3uCvbT02IfgeBQdEuzg zoJhxqhP9erQ8tLSEx+CE8ioOnaf+4Yd3FnwZE+wl5aeehE8OXhoJRbuLBim1Sc77KWlT3wIHscH Dy0HHyEYrqfWsGSvQbj7wA/+2lmp7OiWxTs7Y7g70vWXu8Y/wcQPs5Edlep5xw1ScB3vQa1PpIU5 Qne/l9dlDVVzQv3aBIge7o4W1pWl1b0vYClHOTepvICl1VgvYBl7qcvEC8u0IwvsPDSdm1HhWf4W PPsLAAD//wMAUEsDBBQABgAIAAAAIQD3hgv5XQIAAEAIAAASAAAAd29yZC9mb250VGFibGUueG1s tJVNjtowFID3lXqHyPtOnPDTDJowmqHDchYdRl2b4BBLsR3ZhnTO0GXv0Rv0Nu09+hw7YRqgQNUm Eojn5PH8+fPzze1nXgZbqjSTIkXRFUYBFZlcMbFO0fNi/i5BgTZErEgpBU3RC9Xodvr2zU09yaUw OoD3hZ6oFBXGVJMw1FlBOdFXsqICxnKpODHwU61Dmecsox9ktuFUmDDGeBwqWhID/60LVmnks9Xn ZKulWlVKZlRrKJaXLh8nTKCpry6oJ4JwqHpGSrZUrBmoiJCaRjC2JWWKcIzneASf9h7igf1Eoc2Q FURparoHsQvnhLPypY3qmmntBipmsqKNb4liZFlSN6TZGgY2eolT9IDhiudz5CJRioYQuJt1kRiK clfknxl0EVgeKKzJ0zwSXTd5IAJ5/FtNnaFbnz0SP799+fH9awOClOYR6LQVLxinOnikdfBRciIu YEA2Rh5AsKI52ZRmn0BXZ0egF9kRaOYL3I4TgFc9kzMJ9OdpEe07EeMxuDACI6wbg4ucUDt+FzgR 33UGwExmMK/3ybA1YEfk+rQTLs/5Tjwx/rRxu6bnhLel2Q77jCJghIFN1N4HnUnGLvz7vjnizPFt 4xUZ+OkDojhJ5jbqIx2iaHwCkd1vDdjzES1IAYt6pH/cAwfbOawtw//fPyJoHw99V8Z4dN8HEZ9y BRbuUlc+Qa+1h4M+yGLkV+nV10EncPwvnWgNACeATXP1UXSWHGwkyau3zndiRjicKceksI3DKWEb yWWHyt81kP1DBQ87Tbrd8WcSDYjTh4o/XfT0FwAAAP//AwBQSwMEFAAGAAgAAAAhAMMMd/z3AQAA +gMAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAnFPLbtswELwX6D8IOjeW5MZJYNAMCgeFD2ljwEpy3lIriShFEiTtxv36LqVYkdOeqtM+BrPD 3RG7felUckDnpdGrtJjlaYJamErqZpU+ll8vbtLEB9AVKKNxlR7Rp7f84we2dcaiCxJ9QhTar9I2 BLvMMi9a7MDPqK2pUxvXQaDUNZmpaynwzoh9hzpk8zy/yvAloK6wurAjYTowLg/hf0krI6I+/1Qe LQnmrMTOKgjIv0c5imVjgZUmgCplh7woLqkxpmwLDXpesGwI2LNxFeXFgmBDzNYtOBCB9sevFjdU nxTYF2uVFBBotfybFM54U4fkoV9CEglYNoUwWswOxd7JcOQ5y6Ypu5eatMTJQ0TiHDQObEuKFlHi mLKdAIVrej+vQXlk2VuBbRDibbcgSTI7hOUBRTAu8fI3XXeeJj/AY9zaKj2Ak6ADbS/ChqSPlfXB 8VIGRdzUG/I+nMKmsbyMeyQsBefAWBw0UONcXT/BP9T0tvAPscVUbK9hkDqRMwnHGe9Y16azoI98 s4dfKJMSRauNMk009trMPt2HakZnfUXFO/z0j7Y0d9FNr/s9L05M8SxDu7Mg6HTX1/PPU3tMWmxH LsKK7n0ifCuwDd3CqTiVrKUbrE6YvxvRcE/Dr8yL+Synr3fYqUYuGf8x/gcAAP//AwBQSwECLQAU AAYACAAAACEAY4MYyo4BAAClBgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQCZVX4FBAEAAOECAAALAAAAAAAAAAAAAAAAAMcDAABfcmVscy8ucmVs c1BLAQItABQABgAIAAAAIQBBQiNEGAEAADkEAAAcAAAAAAAAAAAAAAAAAPwGAAB3b3JkL19yZWxz L2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAAPXirT4IwAAlr8AABEAAAAAAAAAAAAA AAAAVgkAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhANmE+NlTCgAAVCYAABEAAAAA AAAAAAAAAAAAfS0AAHdvcmQvY29tbWVudHMueG1sUEsBAi0AFAAGAAgAAAAhAJa1reKWBgAAUBsA ABUAAAAAAAAAAAAAAAAA/zcAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBU 8M6yAw0AAKg4AAARAAAAAAAAAAAAAAAAAMg+AAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAI AAAAIQADUEAqfgEAAG4HAAAUAAAAAAAAAAAAAAAAAPpLAAB3b3JkL3dlYlNldHRpbmdzLnhtbFBL AQItABQABgAIAAAAIQB6SgiAzwgAANZEAAAPAAAAAAAAAAAAAAAAAKpNAAB3b3JkL3N0eWxlcy54 bWxQSwECLQAUAAYACAAAACEAECy+p/YAAABsAQAAEwAAAAAAAAAAAAAAAACmVgAAZG9jUHJvcHMv Y3VzdG9tLnhtbFBLAQItABQABgAIAAAAIQCiiDkmYAEAAKYCAAARAAAAAAAAAAAAAAAAANVYAABk b2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQACyIp3RwMAAFIOAAASAAAAAAAAAAAAAAAA AGxbAAB3b3JkL251bWJlcmluZy54bWxQSwECLQAUAAYACAAAACEA94YL+V0CAABACAAAEgAAAAAA AAAAAAAAAADjXgAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAMMMd/z3AQAA+gMA ABAAAAAAAAAAAAAAAAAAcGEAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAA4ADgCBAwAAnWQAAAAA --_006_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_-- From nobody Wed May 13 14:37:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCF11AD0C9; Wed, 13 May 2015 14:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pSg3MP4uKk3; Wed, 13 May 2015 14:37:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FBA1AD0CA; Wed, 13 May 2015 14:37:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D565519; Wed, 13 May 2015 23:37:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WZY8lSeXizdW; Wed, 13 May 2015 23:37:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 13 May 2015 23:37:37 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49B0F2002B; Wed, 13 May 2015 23:37:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IhtJzKnap8i8; Wed, 13 May 2015 23:37:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B2C920013; Wed, 13 May 2015 23:37:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 88009333336F; Wed, 13 May 2015 23:37:33 +0200 (CEST) Date: Wed, 13 May 2015 23:37:33 +0200 From: Juergen Schoenwaelder To: John Strassner Message-ID: <20150513213733.GA629@elstar.local> Mail-Followup-To: John Strassner , Linda Dunbar , "i2nsf@ietf.org" , Kathleen Moriarty , "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "i2nsf@ietf.org" , "dots@ietf.org" , Kathleen Moriarty Subject: Re: [netmod] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 21:37:44 -0000 Can we please stop this cross-posting thread? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu May 14 09:26:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62E31A8820 for ; Thu, 14 May 2015 09:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLsWk5tz9WlQ for ; Thu, 14 May 2015 09:16:19 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB1B1A8784 for ; Thu, 14 May 2015 09:16:18 -0700 (PDT) Received: by laat2 with SMTP id t2so74902645laa.1 for ; Thu, 14 May 2015 09:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=XqDMxwDCQDllYvqFeT78hdeupRwj8zwuyx2bv5AuczM=; b=XPbhuljaQQrQ02hUVSLxpwhogk2zcTUZHskOHFbqL1Wec92Bkpqf8whxULE2bF+hbD KRxF2avmYwSivmxvRXFnFp22uO0A0e8t7vs9+dyePG5zGcPxay02UM5yeCLkEkIQK44a CMQhfZfbf6d/bWP9ORXCnUdoWAVSco+btnrbko8qUoQKVN1yXSeDT4AlF3lzDKwe/mhw iJO+d/SMy525kX6VAJ8wfzQMOLPO3JmWkq+qIHWMiVIzVoK/5EqPw82UyaC1AF3nJrpI FpMI1hadOEdqYjJlazaP9zkiU3EfMSsf5zWYCEIli4yKLirxqoTVFXHRH16GVDQx6d8k ahCQ== MIME-Version: 1.0 X-Received: by 10.112.161.40 with SMTP id xp8mr1953114lbb.71.1431620177188; Thu, 14 May 2015 09:16:17 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Thu, 14 May 2015 09:16:17 -0700 (PDT) Date: Thu, 14 May 2015 11:16:17 -0500 Message-ID: From: Behcet Sarikaya To: netmod@ietf.org, lhotka@nic.cz Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Thu, 14 May 2015 09:26:03 -0700 Subject: [netmod] draft-ietf-netmod-routing-cfg-18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:16:19 -0000 Hi all, I am new to this list, I just sent my subscription request, if it doesn't go thru, I hope that chairs can subscribe me. I have been reading this draft and have a few comments: The draft defines one RPC operation called fib-route to query a routing instance for the active route in the FIB. As such it seems to be a read operation. What about write or modify type of operations? Are they not needed? In Appendix D an example get reply is given, which is useful. What about fib-route? Regards, Behcet From nobody Thu May 14 09:29:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5B91A8863 for ; Thu, 14 May 2015 09:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVY41azlgJg3 for ; Thu, 14 May 2015 09:29:34 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A8F1A885A for ; Thu, 14 May 2015 09:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1170; q=dns/txt; s=iport; t=1431620974; x=1432830574; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xeIBNE/WlUcL3jZp2Vi0pxZSxD6rcu7YF2+gVxu5nqY=; b=GzvbQ2nN/rZzAGBno4AGuuhz0PfV4cr/toVpdfbMJnkK6QKpyDwT0KKv FsD4oZPkzBwLFUaCraZCnlsa6A16tULqnsVU5ySUbcmaEt6qdDCu3jaYF BBdXupcU1PNjO6FzWzE3CxYd1FZrmd8Am35nEvUVKiRYP61pITH0NC8eC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BXBABwzFRV/5hdJa1cgw9UXgaDGMFQCYFOCoUsSgIcgSU4FAEBAQEBAQGBCoQjAQEEAQEBIBE6GwIBCBoCCAEdAgICHwYLFRACBAESiBcDEg2wKZ8xDYRxAQEBAQEBAQEBAQEBAQEBAQEBARUEgSGKGYJNggU6gmiBRQWSYIkdgVWBJ4Zgh3yGdiOBZoIRb4FFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,429,1427760000"; d="scan'208";a="150129890" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 May 2015 16:29:32 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4EGTWYl025093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 May 2015 16:29:32 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.23]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 14 May 2015 11:29:32 -0500 From: "Acee Lindem (acee)" To: "sarikaya@ieee.org" , "netmod@ietf.org" , "lhotka@nic.cz" Thread-Topic: [netmod] draft-ietf-netmod-routing-cfg-18 Thread-Index: AQHQjmKwY8EqpUCqrkyKNG2LnDDb6p17ulSA Date: Thu, 14 May 2015 16:29:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.202] Content-Type: text/plain; charset="utf-8" Content-ID: <3134509636717C4C8B252522F28FFCCF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:29:36 -0000 DQoNCk9uIDUvMTQvMTUsIDEyOjE2IFBNLCAiQmVoY2V0IFNhcmlrYXlhIiA8c2FyaWtheWEyMDEy QGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5IaSBhbGwsDQo+DQo+SSBhbSBuZXcgdG8gdGhpcyBsaXN0 LCBJIGp1c3Qgc2VudCBteSBzdWJzY3JpcHRpb24gcmVxdWVzdCwgaWYgaXQNCj5kb2Vzbid0IGdv IHRocnUsIEkgaG9wZSB0aGF0IGNoYWlycyBjYW4gc3Vic2NyaWJlIG1lLg0KPg0KPiBJIGhhdmUg YmVlbiByZWFkaW5nIHRoaXMgZHJhZnQgYW5kIGhhdmUgYSBmZXcgY29tbWVudHM6DQo+DQo+VGhl IGRyYWZ0IGRlZmluZXMgb25lIFJQQyBvcGVyYXRpb24gY2FsbGVkIGZpYi1yb3V0ZSB0byBxdWVy eSBhDQo+cm91dGluZyBpbnN0YW5jZSBmb3IgdGhlIGFjdGl2ZSByb3V0ZSBpbiB0aGUgRklCLiBB cyBzdWNoIGl0IHNlZW1zIHRvDQo+YmUgYSByZWFkIG9wZXJhdGlvbi4NCj5XaGF0IGFib3V0IHdy aXRlIG9yIG1vZGlmeSB0eXBlIG9mIG9wZXJhdGlvbnM/IEFyZSB0aGV5IG5vdCBuZWVkZWQ/DQoN CkN1cnJlbnRseSwgdGhpcyB1c2UtY2FzZSBpcyB1bmRlciB0aGUgcHVydmlldyBvZiB0aGUgSTJS UyBXRy4NCg0KQWNlZSANCg0KDQoNCg0KPg0KPkluIEFwcGVuZGl4IEQgYW4gZXhhbXBsZSBnZXQg cmVwbHkgaXMgZ2l2ZW4sIHdoaWNoIGlzIHVzZWZ1bC4NCj5XaGF0IGFib3V0IGZpYi1yb3V0ZT8N Cj4NCj5SZWdhcmRzLA0KPg0KPkJlaGNldA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== From nobody Thu May 14 09:34:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182C51A88D3 for ; Thu, 14 May 2015 09:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_BugJXs0LK9 for ; Thu, 14 May 2015 09:34:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8D80F1A8903 for ; Thu, 14 May 2015 09:34:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 64A211E308; Thu, 14 May 2015 16:34:40 +0000 (UTC) Date: Thu, 14 May 2015 12:34:40 -0400 From: Jeffrey Haas To: netmod@ietf.org Message-ID: <20150514163440.GA3679@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [netmod] Groupings - augmentation and deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:34:38 -0000 [I'm weeks behind on reading this list due to day-job needs. If this is answered in a previous thread, I'm happy to get a pointer to that.] As best I'm able to tell, it is not possible to add augmentations or deviations to groupings directly. They don't implement any data nodes. If this is the case, the implication is that when you need to do a common augmentation or deviation to a grouping, you're responsible for adding the augmentation/deviation in every instantiation of it. Is this correct? If so, this seems a bit clumsy. -- Jeff From nobody Thu May 14 09:36:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512201A88C8; Thu, 14 May 2015 09:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVUM9L1R3FXM; Thu, 14 May 2015 09:36:16 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::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 A2E1D1A8876; Thu, 14 May 2015 09:36:11 -0700 (PDT) Received: by lagv1 with SMTP id v1so75833736lag.3; Thu, 14 May 2015 09:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=go7N5T/M88qorbFwZNQUzANTZUjFSJ+XeB7m6zQE8sE=; b=ALKwcLcCXggaa/MqzZHrmJOqqo219GTHQpwa+kcWgTi4Rv996ZmeU5m3FlISnecouQ VcY9cySqJcyuBWtQWSBPtC0n3Uo1C9nMqbu0Ag3WM9xIOxfYztruilf9qZ/hxMNWJ1kp 3pADBhLplJgf2pqiKwlUT914kw2iXqTj9kw7/rSLh2kp+vU4rn44xrlheMXOcQGgjfbL KMbFAEnbtFsWd0lyDJvM8dLGDnKc5+YNX3daGubP22zAHogRmuqrme1mPp4J5WAnilUM miTde5TLHfz5/nsyk1X4WWmNQTvdZFQThUn8wbc+jM1tcqnaOZRMaQ0HqrsB5KmmHgpl sFdQ== MIME-Version: 1.0 X-Received: by 10.152.88.46 with SMTP id bd14mr3786827lab.71.1431621370114; Thu, 14 May 2015 09:36:10 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Thu, 14 May 2015 09:36:10 -0700 (PDT) Date: Thu, 14 May 2015 11:36:10 -0500 Message-ID: From: Behcet Sarikaya To: "Acee Lindem (acee)" , "i2rs@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:36:17 -0000 Thanks, let me take it to I2RS list then. On Thu, May 14, 2015 at 11:29 AM, Acee Lindem (acee) wrote: > > > On 5/14/15, 12:16 PM, "Behcet Sarikaya" wrote: > >>Hi all, >> >>I am new to this list, I just sent my subscription request, if it >>doesn't go thru, I hope that chairs can subscribe me. >> >> I have been reading this draft and have a few comments: >> >>The draft defines one RPC operation called fib-route to query a >>routing instance for the active route in the FIB. As such it seems to >>be a read operation. >>What about write or modify type of operations? Are they not needed? > > Currently, this use-case is under the purview of the I2RS WG. > > Acee > From nobody Thu May 14 13:26:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9571ACD15 for ; Thu, 14 May 2015 13:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_woHLZM6HQv for ; Thu, 14 May 2015 13:26:57 -0700 (PDT) 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 07B121AC3F5 for ; Thu, 14 May 2015 13:26:56 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 0958A4FD45447; Thu, 14 May 2015 20:26:49 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t4EKQqEj028063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 May 2015 16:26:53 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.179]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 14 May 2015 16:26:52 -0400 From: "Sterne, Jason (Jason)" To: Jeffrey Haas , "netmod@ietf.org" Thread-Topic: [netmod] Groupings - augmentation and deviations Thread-Index: AQHQjmPiOWLQ+83bHUqeLMW88jPFDp1766ng Date: Thu, 14 May 2015 20:26:51 +0000 Message-ID: References: <20150514163440.GA3679@pfrc.org> In-Reply-To: <20150514163440.GA3679@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Groupings - augmentation and deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:26:58 -0000 You have that correct. Jason -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Thursday, May 14, 2015 12:35 PM To: netmod@ietf.org Subject: [netmod] Groupings - augmentation and deviations [I'm weeks behind on reading this list due to day-job needs. If this is an= swered in a previous thread, I'm happy to get a pointer to that.] As best I'm able to tell, it is not possible to add augmentations or deviat= ions to groupings directly. They don't implement any data nodes. If this is the case, the implication is that when you need to do a common a= ugmentation or deviation to a grouping, you're responsible for adding the a= ugmentation/deviation in every instantiation of it. Is this correct? If so, this seems a bit clumsy. -- Jeff _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Fri May 15 04:07:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09051A0222 for ; Fri, 15 May 2015 04:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44VBh4psrM7U for ; Fri, 15 May 2015 04:07:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DF51A0204 for ; Fri, 15 May 2015 04:07:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 16D1415B9 for ; Fri, 15 May 2015 13:07:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7HaNIAG6MncM for ; Fri, 15 May 2015 13:07:19 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 15 May 2015 13:07:19 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E58520031 for ; Fri, 15 May 2015 13:07:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iPACHeu5hp7y; Fri, 15 May 2015 13:07:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACAF22002C; Fri, 15 May 2015 13:07:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 32C123334056; Fri, 15 May 2015 13:07:17 +0200 (CEST) Date: Fri, 15 May 2015 13:07:17 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150515110717.GA4272@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] Y45 - time to summarize and decide X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 11:07:23 -0000 Hi, over last few days, I contacted the WG members that were active in the recent discussion round concerning Y45 in order to find out what their state of thinking is. Here is the result: | Contributor | Preference | Acceptable | Objections | |------------------+------------+---------------+------------------------| | Martin Bjorklund | Y45-04 | Y45-05,Y45-03 | Y45-02, DEAD | | Lada Lhotka | Y45-04 | Y45-03,Y45-05 | all others | | Xiang Li | Y45-05 | Y45-04,Y45-03 | Y45-02, DEAD | | Andy Bierman | Y45-03 | | Y45-04, Y45-05 | | Randy Presuhn | Y45-04 | Y45-02 | Y45-01, Y45-03, Y45-05 | |------------------+------------+---------------+------------------------| I am happy to add more opinions should there be more contributors with a clear opinion on Y45. But please speak up quickly (ideally by the beginning of next week, that is May 18th.) So far, it seems there is consensus that there is agreement to address Y45 (that is to not simply declare it dead). And so far, Y45-04 clearly is the strongest candidate. Note that Y45 is the last technical issue waiting to be resolved and it is time to decide and then to move on. /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 May 18 10:20:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEAB1A007A for ; Mon, 18 May 2015 10:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJWmgbZUQVSK for ; Mon, 18 May 2015 10:20:53 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C811A0102 for ; Mon, 18 May 2015 10:20:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A5A44134E for ; Mon, 18 May 2015 19:20:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GRdHSBuWigeH for ; Mon, 18 May 2015 19:20:36 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 18 May 2015 19:20:38 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D669A2002B for ; Mon, 18 May 2015 19:20:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id voXVXlK576Bw; Mon, 18 May 2015 19:20:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0881E20013; Mon, 18 May 2015 19:20:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 68A733352D8E; Mon, 18 May 2015 19:20:36 +0200 (CEST) Date: Mon, 18 May 2015 19:20:36 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150518172036.GB48290@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] diffserv model questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 17:20:54 -0000 Hi, what is the purpose of the feature policy-template-support in draft-asechoud-netmod-diffserv-model-01.txt? Can I use the model without this feature? I also note that no implementable object is left in ietf-diffserv-policy if I do not support the feature policy-template-support. Is this useful? Is it a bug or a feature to support inline classifier definitions? Is it correct that actions are always 'inline' so to say? Is this a bug or a feature? /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 May 19 02:59:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8277A1A700C for ; Tue, 19 May 2015 02:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPNQ18Lc1fbF for ; Tue, 19 May 2015 02:59:36 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010AF1A7007 for ; Tue, 19 May 2015 02:59:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CAA6F13AC for ; Tue, 19 May 2015 11:59:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TrTA1S7FTDyr for ; Tue, 19 May 2015 11:59:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 19 May 2015 11:59:34 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F37CF2002B for ; Tue, 19 May 2015 11:59:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id e3Nu7lIX0JXU; Tue, 19 May 2015 11:59:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B77420013; Tue, 19 May 2015 11:59:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2DA0A3353350; Tue, 19 May 2015 11:59:32 +0200 (CEST) Date: Tue, 19 May 2015 11:59:31 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150519095931.GA49981@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 09:59:37 -0000 Hi, after long discussions in physical meetings, virtual meetings, and on the mailing list, I believe we have reached rough consensus to adopt Y45-04 in order to resolve import ambiguities (aka typedef drift and grouping drift) and we will leave it to YANG extensions (to be worked on in the future) to provide means to define explicit conformance requirements (instead of trying to derive conformance requirements from import relationships alone). A recent poll of core contributors on this issue can be found here: http://www.ietf.org/mail-archive/web/netmod/current/msg12560.html Please speak up by Monday 2015-05-25 if you disagree with this proposal and your position is not yet included in the email message pointed to above. For more details, see the issues list available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /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 May 19 05:55:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0E41A88D2 for ; Tue, 19 May 2015 05:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLk_HGlnpE34 for ; Tue, 19 May 2015 05:55:28 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (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 47A111A88C9 for ; Tue, 19 May 2015 05:55:28 -0700 (PDT) Received: by laat2 with SMTP id t2so22367375laa.1 for ; Tue, 19 May 2015 05:55:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=pGLKSv5PzXKBWU3RnDYQkZJGcgcuSn+pdq1m8B9dhjc=; b=E/AQKXC8AjSZ3aaZLoxnLuCB6DMkkppSNX8FUeEG1iPAR+oka2uSfRW91/xY4bfSKg 3t9O6XKCP4JlparSH359tw6tZG8EpSFTl3YIYLTGqg1U04TgfDFciX7F+ZO1vF9VQ1lo ynU0Vxtj7unrlyQAUlPbnMdl7Ueh3ZUhVDfP9Vj/KTE6SlRdGeP8Rv+Q6Y4JolpHojji TLn2zVBbWreQkFDC8MmXyOAFLHy+YjxbSg6gjKfEkGvkk810up1FFSNie91A5FIBDhNC DD8nYx/QehAaZvNCw+IXn+BaXAczdQ6ITrW0JnIZXOalpQuqIYMpuwZCQvc+Rd3UuuYo nqdQ== X-Gm-Message-State: ALoCoQmDzdc6TevkiFOqEP0OmCExkPa6Wz6Q7ez7MLVykpSIlCQrKZGQThG+1Fu5p4xEKC23k5Pp MIME-Version: 1.0 X-Received: by 10.152.115.173 with SMTP id jp13mr3786295lab.119.1432040126617; Tue, 19 May 2015 05:55:26 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 19 May 2015 05:55:26 -0700 (PDT) In-Reply-To: <20150519095931.GA49981@elstar.local> References: <20150519095931.GA49981@elstar.local> Date: Tue, 19 May 2015 05:55:26 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 12:55:30 -0000 Hi, RFC 6020, sec. 7.1.5 has this sentence: Multiple revisions of the same module MUST NOT be imported. I expect the new RFC will contain a complete explanation why this MUST NOT is wrong and needs to be changed. I would expect that multiple implementation examples of this approach can be cited, as proof that the new solution already works (before it is standardized). Andy On Tue, May 19, 2015 at 2:59 AM, Juergen Schoenwaelder wrote: > Hi, > > after long discussions in physical meetings, virtual meetings, and on > the mailing list, I believe we have reached rough consensus to adopt > Y45-04 in order to resolve import ambiguities (aka typedef drift and > grouping drift) and we will leave it to YANG extensions (to be worked > on in the future) to provide means to define explicit conformance > requirements (instead of trying to derive conformance requirements > from import relationships alone). A recent poll of core contributors > on this issue can be found here: > > http://www.ietf.org/mail-archive/web/netmod/current/msg12560.html > > Please speak up by Monday 2015-05-25 if you disagree with this > proposal and your position is not yet included in the email message > pointed to above. > > For more details, see the issues list available here: > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue May 19 06:17:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D56D1A8F48 for ; Tue, 19 May 2015 06:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4xhSV20mFOM for ; Tue, 19 May 2015 06:17:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8097D1A8A98 for ; Tue, 19 May 2015 06:16:06 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id E53F1141BB7; Tue, 19 May 2015 15:16:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1432041364; bh=hhy4ec9HNvkHFPHflb9A8FeHB1CjVVRNTaLf72rVwFc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nT7Nmy2CRol2FyeZ1Gijh9+wbfeFUxoBCJrF0fxx+7qqpEPWwyz3qZnqrmz7+xQc3 ViiLMeleTjCOr5y4e9LPGJxcCwuaGhJWi8nNwK9/GAd5oZTPbHhsd7cEq4He2sNHI2 vXeArZaEfDrdGASsoi7WXwfI7zAn0mHKiq6nGYic= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 19 May 2015 15:16:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0FCE0AC6-8F2B-4216-A373-662F6ECCACD2@nic.cz> References: <20150519095931.GA49981@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 13:17:38 -0000 > On 19 May 2015, at 14:55, Andy Bierman wrote: >=20 > Hi, >=20 > RFC 6020, sec. 7.1.5 has this sentence: >=20 > Multiple revisions of the same module MUST NOT be imported. >=20 > I expect the new RFC will contain a complete explanation why > this MUST NOT is wrong and needs to be changed. It=E2=80=99s not wrong but without this restriction a data modeller can = use some typedefs/groupings from a new revision and isn=E2=80=99t forced = to upgrade everything to the new revision at the same time. It was you = who advocated this option in Dallas: AB: I agree with Martin that the ripple effect is a problem. When you want to use a new version of a module, you have to update everything else that you use from the same module. > I would expect that multiple implementation examples of this > approach can be cited, as proof that the new solution already works > (before it is standardized). It will be implemented in pyang, including the mapping to DSDL schemas. Lada >=20 >=20 > Andy >=20 >=20 >=20 > On Tue, May 19, 2015 at 2:59 AM, Juergen Schoenwaelder > wrote: >> Hi, >>=20 >> after long discussions in physical meetings, virtual meetings, and on >> the mailing list, I believe we have reached rough consensus to adopt >> Y45-04 in order to resolve import ambiguities (aka typedef drift and >> grouping drift) and we will leave it to YANG extensions (to be worked >> on in the future) to provide means to define explicit conformance >> requirements (instead of trying to derive conformance requirements >> from import relationships alone). A recent poll of core contributors >> on this issue can be found here: >>=20 >> http://www.ietf.org/mail-archive/web/netmod/current/msg12560.html >>=20 >> Please speak up by Monday 2015-05-25 if you disagree with this >> proposal and your position is not yet included in the email message >> pointed to above. >>=20 >> For more details, see the issues list available here: >>=20 >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >>=20 >> /js >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue May 19 08:00:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514461B301A for ; Tue, 19 May 2015 08:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxXeBpr6q6Zj for ; Tue, 19 May 2015 08:00:11 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (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 B59CF1B3007 for ; Tue, 19 May 2015 08:00:10 -0700 (PDT) Received: by lagr1 with SMTP id r1so28352607lag.0 for ; Tue, 19 May 2015 08:00:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oxlvo17HYAb8y3ekA9uywWkna6E3675D46g/L3HibXU=; b=aoRWYXv1veLAu40H8uMK5IVukv2ZoDT/egDnMPim6n9wmgZwpex9Nl1eFsnUAuq8bw GRCwPjLCRqIvgsbEfPFLA1ymBBhR/MIg6EPEnXJ0gRrEeEb/ASYheNmov/+SyP8SsYfj Ca5z5lgPtdmXw0SPByGHqK8x6v1w3b/Hc+QxzaHdmHqFSvzcb2TqridUOa11mJkLg7QB TRkAy4F4kUwjj9f8SrZEpjPNnlA0g6kK/Owd7Y6liIo06U83jjIufl6sgvpOqzV+zGqy pEO7XamjP6q2NJJ1GFFr8fr9UYpU1ubK7o9wDGJrotCgD8kFluOICVewDmzCRWIwIMzP pHDw== X-Gm-Message-State: ALoCoQnSzSEkOUMzENYCNos3ZqP9n+4KfqIWDLBxldDcbWjQ3IGZqykBpveCs/LRQ0bF+5sdbOpK MIME-Version: 1.0 X-Received: by 10.112.130.129 with SMTP id oe1mr13038630lbb.37.1432047607331; Tue, 19 May 2015 08:00:07 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 19 May 2015 08:00:07 -0700 (PDT) In-Reply-To: <0FCE0AC6-8F2B-4216-A373-662F6ECCACD2@nic.cz> References: <20150519095931.GA49981@elstar.local> <0FCE0AC6-8F2B-4216-A373-662F6ECCACD2@nic.cz> Date: Tue, 19 May 2015 08:00:07 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 15:00:15 -0000 On Tue, May 19, 2015 at 6:16 AM, Ladislav Lhotka wrote: > >> On 19 May 2015, at 14:55, Andy Bierman wrote: >> >> Hi, >> >> RFC 6020, sec. 7.1.5 has this sentence: >> >> Multiple revisions of the same module MUST NOT be imported. >> >> I expect the new RFC will contain a complete explanation why >> this MUST NOT is wrong and needs to be changed. > > It=E2=80=99s not wrong but without this restriction a data modeller can u= se some typedefs/groupings from a new revision and isn=E2=80=99t forced to = upgrade everything to the new revision at the same time. It was you who adv= ocated this option in Dallas: > > AB: I agree with Martin that the ripple effect is a problem. When > you want to use a new version of a module, you have to update > everything else that you use from the same module. > The updating of import revision dates is not "fixed" by adding multiple import-by-revision statements to a module. The MUST NOT is correct but it is being removed anyway? I would expect the sentence to be replaced by a thorough explanation of why it was incorrectly placed in RFC 6020. >> I would expect that multiple implementation examples of this >> approach can be cited, as proof that the new solution already works >> (before it is standardized). > > It will be implemented in pyang, including the mapping to DSDL schemas. > So no existing designs that would validate this approach before it is standardized? Didn't think so. > Lada > Andy >> >> >> Andy >> >> >> >> On Tue, May 19, 2015 at 2:59 AM, Juergen Schoenwaelder >> wrote: >>> Hi, >>> >>> after long discussions in physical meetings, virtual meetings, and on >>> the mailing list, I believe we have reached rough consensus to adopt >>> Y45-04 in order to resolve import ambiguities (aka typedef drift and >>> grouping drift) and we will leave it to YANG extensions (to be worked >>> on in the future) to provide means to define explicit conformance >>> requirements (instead of trying to derive conformance requirements >>> from import relationships alone). A recent poll of core contributors >>> on this issue can be found here: >>> >>> http://www.ietf.org/mail-archive/web/netmod/current/msg12560.html >>> >>> Please speak up by Monday 2015-05-25 if you disagree with this >>> proposal and your position is not yet included in the email message >>> pointed to above. >>> >>> For more details, see the issues list available here: >>> >>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Tue May 19 08:30:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0331A8BC0 for ; Tue, 19 May 2015 08:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD2aEvVUUeMP for ; Tue, 19 May 2015 08:29:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B3C1A8A4F for ; Tue, 19 May 2015 08:29:56 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id AFFE7141B9B; Tue, 19 May 2015 17:29:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1432049394; bh=elDfDFvUQMCn72FRRc1iV4cnUjBsybdZ5elFmge0/TM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DQOiBn9cL78OqG+WHQoGd4x1MHKapsLcmgFmI/JwKIzQrSserDg+p+6JVMUvC/jcD SZ7CVfJFG7c9HFY9okzOJJDhnQYWrq7Y2nQIaerhvOgn2lQumcFmHdjmet8QT7KoM7 AkxhpOT/ewdDH+f27FaWZ9p0ufPb3nnykYXqJCxw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 19 May 2015 17:29:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150519095931.GA49981@elstar.local> <0FCE0AC6-8F2B-4216-A373-662F6ECCACD2@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 15:29:59 -0000 > On 19 May 2015, at 17:00, Andy Bierman wrote: >=20 > On Tue, May 19, 2015 at 6:16 AM, Ladislav Lhotka = wrote: >>=20 >>> On 19 May 2015, at 14:55, Andy Bierman wrote: >>>=20 >>> Hi, >>>=20 >>> RFC 6020, sec. 7.1.5 has this sentence: >>>=20 >>> Multiple revisions of the same module MUST NOT be imported. >>>=20 >>> I expect the new RFC will contain a complete explanation why >>> this MUST NOT is wrong and needs to be changed. >>=20 >> It=E2=80=99s not wrong but without this restriction a data modeller = can use some typedefs/groupings from a new revision and isn=E2=80=99t = forced to upgrade everything to the new revision at the same time. It = was you who advocated this option in Dallas: >>=20 >> AB: I agree with Martin that the ripple effect is a problem. When >> you want to use a new version of a module, you have to update >> everything else that you use from the same module. >>=20 >=20 >=20 > The updating of import revision dates is not "fixed" by adding = multiple > import-by-revision statements to a module. It is - you can import a new revision with a different prefix and update = only selected groupings or typedefs. >=20 > The MUST NOT is correct but it is being removed anyway? > I would expect the sentence to be replaced by a thorough > explanation of why it was incorrectly placed in RFC 6020. It=E2=80=99s not about correct-incorrect but rather about better-worse. Lada >=20 >=20 >>> I would expect that multiple implementation examples of this >>> approach can be cited, as proof that the new solution already works >>> (before it is standardized). >>=20 >> It will be implemented in pyang, including the mapping to DSDL = schemas. >>=20 >=20 > So no existing designs that would validate this approach > before it is standardized? Didn't think so. >=20 >=20 >> Lada >>=20 >=20 > Andy >=20 >>>=20 >>>=20 >>> Andy >>>=20 >>>=20 >>>=20 >>> On Tue, May 19, 2015 at 2:59 AM, Juergen Schoenwaelder >>> wrote: >>>> Hi, >>>>=20 >>>> after long discussions in physical meetings, virtual meetings, and = on >>>> the mailing list, I believe we have reached rough consensus to = adopt >>>> Y45-04 in order to resolve import ambiguities (aka typedef drift = and >>>> grouping drift) and we will leave it to YANG extensions (to be = worked >>>> on in the future) to provide means to define explicit conformance >>>> requirements (instead of trying to derive conformance requirements >>>> from import relationships alone). A recent poll of core = contributors >>>> on this issue can be found here: >>>>=20 >>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12560.html >>>>=20 >>>> Please speak up by Monday 2015-05-25 if you disagree with this >>>> proposal and your position is not yet included in the email message >>>> pointed to above. >>>>=20 >>>> For more details, see the issues list available here: >>>>=20 >>>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >>>>=20 >>>> /js >>>>=20 >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue May 19 08:55:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D2B1A8ACE for ; Tue, 19 May 2015 08:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW8SgTq2rYgV for ; Tue, 19 May 2015 08:55:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1D81A911E for ; Tue, 19 May 2015 08:55:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 96E0513F6; Tue, 19 May 2015 17:55:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id JloDHoZUtVMQ; Tue, 19 May 2015 17:55:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 19 May 2015 17:55:37 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A12762002B; Tue, 19 May 2015 17:55:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Cl1au9kdR3Ml; Tue, 19 May 2015 17:55:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8803C20013; Tue, 19 May 2015 17:55:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C295033535A6; Tue, 19 May 2015 17:55:35 +0200 (CEST) Date: Tue, 19 May 2015 17:55:35 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150519155535.GB50390@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20150519095931.GA49981@elstar.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 15:55:45 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 19, 2015 at 05:55:26AM -0700, Andy Bierman wrote: > Hi, > > RFC 6020, sec. 7.1.5 has this sentence: > > Multiple revisions of the same module MUST NOT be imported. > > I expect the new RFC will contain a complete explanation why > this MUST NOT is wrong and needs to be changed. > I would expect that multiple implementation examples of this > approach can be cited, as proof that the new solution already works > (before it is standardized). > The attached yang module compiles using pyang 1.3 and if you replace yang1:uuid with yang0:uuid, you get an error (as one would expect). Depending on how your code is organized, the Y45-04 behaviour may fall out naturally and it takes extra effort to implement the MUST quoted above. It may be possible to find a second implementation that actually does not implement this MUST. (Our libsmi code has a problem with import-by-revision so it is not a candidate unless we implement this.) The reason to change the MUST quoted above can certainly be explained. /js PS: Yes, pyang is broken wrt. YANG 1.0 since it does not implement the MUST quoted above. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="aa.yang" module aa { namespace "http://aa.example.com/"; prefix aa; import ietf-yang-types { prefix yang0; revision-date 2010-09-24; } import ietf-yang-types { prefix yang1; revision-date 2013-07-15; } leaf a { type yang0:counter32; } leaf b { type yang1:uuid; } } --liOOAslEiF7prFVr-- From nobody Tue May 19 09:22:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7529A1A92F6 for ; Tue, 19 May 2015 09:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbH1fRricL_3 for ; Tue, 19 May 2015 09:22:31 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (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 6BE241A92F5 for ; Tue, 19 May 2015 09:22:31 -0700 (PDT) Received: by lagv1 with SMTP id v1so32824972lag.3 for ; Tue, 19 May 2015 09:22:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=z7WOmEJRdGiyWk8sFJ5LUEPRMAx26GPr/+8Ji8fdiS0=; b=KXu+EeH6EgBew/YqI9vyEjNPzWFf9VCyDUmdOQJpeyjrBLfSHMJ/5pIWEkjHAb2+Ec nYVIzd7gVeRkNdI+oBBbJpCya1ROHsfEcDCpWKhB2+DwgQwhxZjG0BtwhFpgSfLsVdYC 27Ol1vYFI5TJuAdivaQ5sUuf584hyDugCNteWLCHmT5Lu20gcuLnCrL6IXI6uvQOd19z kDZh4pIRRCXFGdOgnqW0RwJD3bqFxzfdVseHaMOFE8YJLeDze6LIw3jTYGTyZow2JFpE XxdzOyxPPU7DtJRz17+1+pYCQhQ80ybNxoe6LSBBmKxHou80GFZALBXXBwyMGxC/hlCh ZBIQ== X-Gm-Message-State: ALoCoQm6FzFcmHijo8E4Y0L6vdAN9LxaJS1S6V9HnUmNWm7dmkphyy73mETyTpkZkdz93eqq95vE MIME-Version: 1.0 X-Received: by 10.112.125.33 with SMTP id mn1mr22283326lbb.82.1432052549809; Tue, 19 May 2015 09:22:29 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 19 May 2015 09:22:29 -0700 (PDT) In-Reply-To: <20150519155535.GB50390@elstar.local> References: <20150519095931.GA49981@elstar.local> <20150519155535.GB50390@elstar.local> Date: Tue, 19 May 2015 09:22:29 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 16:22:35 -0000 On Tue, May 19, 2015 at 8:55 AM, Juergen Schoenwaelder wrote: > On Tue, May 19, 2015 at 05:55:26AM -0700, Andy Bierman wrote: >> Hi, >> >> RFC 6020, sec. 7.1.5 has this sentence: >> >> Multiple revisions of the same module MUST NOT be imported. >> >> I expect the new RFC will contain a complete explanation why >> this MUST NOT is wrong and needs to be changed. >> I would expect that multiple implementation examples of this >> approach can be cited, as proof that the new solution already works >> (before it is standardized). >> > > The attached yang module compiles using pyang 1.3 and if you replace > yang1:uuid with yang0:uuid, you get an error (as one would expect). > A tool that parses the syntax is not really the same as a server implementation. I do not question the ability to distinguish 2 different strings as 2 different prefixes. > Depending on how your code is organized, the Y45-04 behaviour may fall > out naturally and it takes extra effort to implement the MUST quoted > above. It may be possible to find a second implementation that > actually does not implement this MUST. (Our libsmi code has a problem > with import-by-revision so it is not a candidate unless we implement > this.) > > The reason to change the MUST quoted above can certainly be explained. > So what is the explanation? Removing a MUST NOT (especially from a 1.1 maintenance release) is a big deal. I would expect it to be easy to demonstrate that the original MUST NOT is a bug. > /js > > PS: Yes, pyang is broken wrt. YANG 1.0 since it does not implement > the MUST quoted above. > Andy > -- > 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 May 19 12:57:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A041B2A42 for ; Tue, 19 May 2015 12:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPGLoyBfxpBH for ; Tue, 19 May 2015 12:57:28 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F591A9168 for ; Tue, 19 May 2015 12:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1388; q=dns/txt; s=iport; t=1432065448; x=1433275048; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Jdhbbx/vRmSryJl/VGI6aZjyURB8eIGXs1JUXeQlycI=; b=Cp36GZ+SfsX9YtuBhLYDyODJ2NAeULO2XgZezzf1eq4Cht7YKXF41v40 /s+m+538vFdj+c+OF4GLdnkXQNmwRxGulvtyu4hFOucFeTFO38QvfcPfn oxMMK3/QZWgtOnplVRFrFEqmUUttthENnny4ZTP5qaWtp+QIf8JBT4XOw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ArBQCVlFtV/5FdJa1ZA4MQVF4GxCFmCYFQCoUsSgKBQjgUAQEBAQEBAYEKhCMBAQQBAQE3NBkEAQgOAiYrDAslAgQBEogsDdNTAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSLNoR1FxGEHAWQMII8in6BJ4NpkgAjgWaCEm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,459,1427760000"; d="scan'208";a="151577127" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 May 2015 19:57:27 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4JJvQT7028297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 May 2015 19:57:26 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.91]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 19 May 2015 14:57:26 -0500 From: "Aseem Choudhary (asechoud)" To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] diffserv model questions Thread-Index: AQHQkm4HVke1RaYia02/d/ycYewc1Q== Date: Tue, 19 May 2015 19:57:26 +0000 Message-ID: In-Reply-To: <20150518172036.GB48290@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.209.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] diffserv model questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:57:29 -0000 Hi Juergen, Please find the replies inline. -thanks, Aseem On 5/18/15, 10:20 AM, "Juergen Schoenwaelder" wrote: >Hi, > >what is the purpose of the feature policy-template-support in >draft-asechoud-netmod-diffserv-model-01.txt? Can I use the model >without this feature? > >I also note that no implementable object is left in >ietf-diffserv-policy if I do not support the feature >policy-template-support. Is this useful? [AC] ietf-diffserv-policy module defines policy as a template. The other option is to configure & apply it directly under target as defined in ietf-diffserv-target module. > >Is it a bug or a feature to support inline classifier definitions? Is >it correct that actions are always 'inline' so to say? Is this a bug >or a feature? [AC] Classifier can be defined inline or can be defined as a separate template and referred in the policy definition. All the actions are defined inline. This is the most common use-case. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Tue May 19 13:39:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681091B3246 for ; Tue, 19 May 2015 13:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXYXlvnkXY13 for ; Tue, 19 May 2015 13:39:39 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092941B3248 for ; Tue, 19 May 2015 13:39:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CF34413BA; Tue, 19 May 2015 22:39:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id LnvaE2u3rKts; Tue, 19 May 2015 22:39:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 19 May 2015 22:39:32 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CABD62002C; Tue, 19 May 2015 22:39:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z9McDxknwe43; Tue, 19 May 2015 22:39:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B34742002B; Tue, 19 May 2015 22:39:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AA2A33353851; Tue, 19 May 2015 22:39:29 +0200 (CEST) Date: Tue, 19 May 2015 22:39:29 +0200 From: Juergen Schoenwaelder To: "Aseem Choudhary (asechoud)" Message-ID: <20150519203929.GA51040@elstar.local> Mail-Followup-To: "Aseem Choudhary (asechoud)" , "netmod@ietf.org" References: <20150518172036.GB48290@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] diffserv model questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:39:42 -0000 On Tue, May 19, 2015 at 07:57:26PM +0000, Aseem Choudhary (asechoud) wrote: > Hi Juergen, > > Please find the replies inline. > > -thanks, > Aseem > > On 5/18/15, 10:20 AM, "Juergen Schoenwaelder" > wrote: > > >Hi, > > > >what is the purpose of the feature policy-template-support in > >draft-asechoud-netmod-diffserv-model-01.txt? Can I use the model > >without this feature? > > > >I also note that no implementable object is left in > >ietf-diffserv-policy if I do not support the feature > >policy-template-support. Is this useful? > > [AC] ietf-diffserv-policy module defines policy as a template. The other > option is to configure & apply it directly under target as defined in > ietf-diffserv-target module. OK, but why is there a feature since this 'policy' is an extension defined in a separate YANG model? > >Is it a bug or a feature to support inline classifier definitions? Is > >it correct that actions are always 'inline' so to say? Is this a bug > >or a feature? > > [AC] Classifier can be defined inline or can be defined as a separate > template and referred in the policy definition. Yes, but is this a bug or a feature? From an implementation perspective, this sounds like extra cost. So what is the benefit of having both options? > All the actions are defined inline. This is the most common use-case. Hm. Why are classifiers and actions treated differently? Perhaps some discussion of the design decisions somewhere in the document would be useful. /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 May 19 14:21:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7324C1B3325 for ; Tue, 19 May 2015 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILv4YNDYvIzw for ; Tue, 19 May 2015 14:21:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D763D1B3353 for ; Tue, 19 May 2015 14:20:54 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) with Microsoft SMTP Server (TLS) id 15.1.166.22; Tue, 19 May 2015 21:20:52 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.35]) with mapi id 15.01.0166.017; Tue, 19 May 2015 21:20:52 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] VRFY :45: better conformance mechanism Thread-Index: AQHQkhqJ88+ryphC8EOYQFVJdUlc3p2DjBoA Date: Tue, 19 May 2015 21:20:52 +0000 Message-ID: References: <20150519095931.GA49981@elstar.local> In-Reply-To: <20150519095931.GA49981@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB456; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB456; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(51704005)(377424004)(199003)(479174004)(24454002)(377454003)(64706001)(2501003)(105586002)(106356001)(66066001)(86362001)(561944003)(76176999)(50986999)(106116001)(40100003)(54356999)(99286002)(68736005)(2950100001)(122556002)(189998001)(36756003)(87936001)(2656002)(107886002)(19580405001)(19580395003)(81156007)(4001540100001)(4001350100001)(77156002)(2900100001)(15975445007)(102836002)(62966003)(83506001)(5001920100001)(101416001)(92566002)(46102003)(5001830100001)(97736004)(5001770100001)(5001960100002)(5001860100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB456; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <9A4F87C6F7BB70479269486DEDF5FD24@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2015 21:20:52.5985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB456 Archived-At: Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:21:31 -0000 It's unclear to me why Y45-04 is needed at all. Doesn't a newer revision of a module contain all the same typedefs from before, and thus a module could import just the more recent revision to get everything it needs? Why would a module ever have to import an older revision? RFC 6020 says "New typedefs, groupings, rpcs, notifications, extensions, features, and identities may be added." I take this to imply that they cannot be removed or even renamed. Is this not the case? Thanks, Kent On 5/19/15, 5:59 AM, "Juergen Schoenwaelder" wrote: >Hi, > >after long discussions in physical meetings, virtual meetings, and on >the mailing list, I believe we have reached rough consensus to adopt >Y45-04 in order to resolve import ambiguities (aka typedef drift and >grouping drift) and we will leave it to YANG extensions (to be worked >on in the future) to provide means to define explicit conformance >requirements (instead of trying to derive conformance requirements >from import relationships alone). A recent poll of core contributors >on this issue can be found here: > >http://www.ietf.org/mail-archive/web/netmod/current/msg12560.html > >Please speak up by Monday 2015-05-25 if you disagree with this >proposal and your position is not yet included in the email message >pointed to above. > >For more details, see the issues list available here: > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Tue May 19 15:49:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5459A1B3336 for ; Tue, 19 May 2015 15:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbU8Hz_HJqg0 for ; Tue, 19 May 2015 15:49:19 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF8B1B3335 for ; Tue, 19 May 2015 15:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2775; q=dns/txt; s=iport; t=1432075760; x=1433285360; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kfAQo/687Ke4TQfk1ZfY7SLzaHfwOWD66IQyIAge/tI=; b=PT3qY2ONGAJxSQV7XqCI1i14UlXaNaPBNIhvllePRR8XWaa/8vhE349t Xrk7o+NdxoDCA1NJn13N1T75DMAmktMgr3FGITEIoErIUcSN3BREnrBGS sWW3NeWGVhumKlMolhPfMXPiwjY94H3egIjr/vpv3l/rh5OO1ByTboPb5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BWBAAIvVtV/4QNJK1ZA4MQVF4GxCNmCYFWhXoCgUY4FAEBAQEBAQGBCoQiAQEBAwE6Pw4EAQgOAggeKxclAgQOBYgkCNFcAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSLNoR1EAcRhBwFkmyKfoEng2mOJ4NZI4FmghJvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,460,1427760000"; d="scan'208";a="270889" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP; 19 May 2015 22:49:19 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4JMnIqS030338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 May 2015 22:49:18 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.91]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 19 May 2015 17:49:18 -0500 From: "Aseem Choudhary (asechoud)" To: Juergen Schoenwaelder Thread-Topic: [netmod] diffserv model questions Thread-Index: AQHQknPswwpHhJ2TMkCiCuf1tAquUp2DxaOA Date: Tue, 19 May 2015 22:49:18 +0000 Message-ID: In-Reply-To: <20150519203929.GA51040@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.209.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] diffserv model questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:49:21 -0000 On 5/19/15, 1:39 PM, "Juergen Schoenwaelder" wrote: >On Tue, May 19, 2015 at 07:57:26PM +0000, Aseem Choudhary (asechoud) >wrote: >> Hi Juergen, >>=20 >> Please find the replies inline. >>=20 >> -thanks, >> Aseem >>=20 >> On 5/18/15, 10:20 AM, "Juergen Schoenwaelder" >> wrote: >>=20 >> >Hi, >> > >> >what is the purpose of the feature policy-template-support in >> >draft-asechoud-netmod-diffserv-model-01.txt? Can I use the model >> >without this feature? >> > >> >I also note that no implementable object is left in >> >ietf-diffserv-policy if I do not support the feature >> >policy-template-support. Is this useful? >>=20 >> [AC] ietf-diffserv-policy module defines policy as a template. The other >> option is to configure & apply it directly under target as defined in >> ietf-diffserv-target module. > >OK, but why is there a feature since this 'policy' is an extension >defined in a separate YANG model? [AC] OK, I see the point you are making, but there are some changes regarding it in next version which will alleviate your concern. > >> >Is it a bug or a feature to support inline classifier definitions? Is >> >it correct that actions are always 'inline' so to say? Is this a bug >> >or a feature? >>=20 >> [AC] Classifier can be defined inline or can be defined as a separate >> template and referred in the policy definition. > >Yes, but is this a bug or a feature? From an implementation >perspective, this sounds like extra cost. So what is the benefit of >having both options? [AC] There are pros and cons of defining either way: When defined as a separate template, it becomes reusable objects. Any change in the object updates the referencing objects too. While when defined inline, it is local change only. Any modification has to be done on every instance. There are use-cases where users may use template and others where they define inline. There are vendors which support either/or/both. Also, Inline is defined as a feature. > >> All the actions are defined inline. This is the most common use-case. > >Hm. Why are classifiers and actions treated differently? Perhaps some >discussion of the design decisions somewhere in the document would be >useful. [AC] Actions are typically not reusable objects. Like metering rate or RED thresholds are specific values vs classification of voice, video or data. I will take this point of adding to the document. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 From nobody Tue May 19 23:24:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8CA1A0218 for ; Tue, 19 May 2015 23:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCqaG26obEkf for ; Tue, 19 May 2015 23:24:18 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4101A020A for ; Tue, 19 May 2015 23:24:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 947D91326; Wed, 20 May 2015 08:24:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id b32C9SA2k2qR; Wed, 20 May 2015 08:24:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 20 May 2015 08:24:15 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE4562002B; Wed, 20 May 2015 08:24:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UDVyESVJncKg; Wed, 20 May 2015 08:24:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B79920013; Wed, 20 May 2015 08:24:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1F1D13353C87; Wed, 20 May 2015 08:24:12 +0200 (CEST) Date: Wed, 20 May 2015 08:24:11 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150520062409.GD51901@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20150519095931.GA49981@elstar.local> <20150519155535.GB50390@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 06:24:20 -0000 On Tue, May 19, 2015 at 09:22:29AM -0700, Andy Bierman wrote: > On Tue, May 19, 2015 at 8:55 AM, Juergen Schoenwaelder > wrote: > > On Tue, May 19, 2015 at 05:55:26AM -0700, Andy Bierman wrote: > >> Hi, > >> > >> RFC 6020, sec. 7.1.5 has this sentence: > >> > >> Multiple revisions of the same module MUST NOT be imported. > >> > >> I expect the new RFC will contain a complete explanation why > >> this MUST NOT is wrong and needs to be changed. > >> I would expect that multiple implementation examples of this > >> approach can be cited, as proof that the new solution already works > >> (before it is standardized). > >> > > > > The attached yang module compiles using pyang 1.3 and if you replace > > yang1:uuid with yang0:uuid, you get an error (as one would expect). > > A tool that parses the syntax is not really the same > as a server implementation. I do not question the ability > to distinguish 2 different strings as 2 different prefixes. How does the resolution of symbols (typedef and grouping names) at module compile time impact the server implementation? > > Depending on how your code is organized, the Y45-04 behaviour may fall > > out naturally and it takes extra effort to implement the MUST quoted > > above. It may be possible to find a second implementation that > > actually does not implement this MUST. (Our libsmi code has a problem > > with import-by-revision so it is not a candidate unless we implement > > this.) > > > > The reason to change the MUST quoted above can certainly be explained. > > > > So what is the explanation? > Removing a MUST NOT (especially from a 1.1 maintenance release) > is a big deal. I would expect it to be easy to demonstrate that > the original MUST NOT is a bug. > The original MUST NOT makes it expensive to upgrade since it is an all or nothing upgrade mechanism and the only way to ease the pain is that the module author anticipates incremental updates and maintains N different versions of definitions to ease the pain. The NETMOD principle has always been that module readers are first priority, module writers are second priority, and tool implementers are third priority. Yes, Y45-04 is a change for tool implementors (except perhaps tools that failed to implement the MUST NOT) but it is done for a reason. /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 May 19 23:26:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78C01A01F2 for ; Tue, 19 May 2015 23:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCwy0dXaMler for ; Tue, 19 May 2015 23:26:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5926A1A017E for ; Tue, 19 May 2015 23:26:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2C0898E3; Wed, 20 May 2015 08:26:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XkP1-HnInl8Z; Wed, 20 May 2015 08:26:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 20 May 2015 08:26:54 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 153442002B; Wed, 20 May 2015 08:26:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nIG2gGAdOWtF; Wed, 20 May 2015 08:26:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F017220013; Wed, 20 May 2015 08:26:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DEBA03353CB5; Wed, 20 May 2015 08:26:51 +0200 (CEST) Date: Wed, 20 May 2015 08:26:51 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150520062649.GE51901@elstar.local> Mail-Followup-To: Kent Watsen , "netmod@ietf.org" References: <20150519095931.GA49981@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 06:26:57 -0000 On Tue, May 19, 2015 at 09:20:52PM +0000, Kent Watsen wrote: > > > It's unclear to me why Y45-04 is needed at all. Doesn't a newer revision > of a module contain all the same typedefs from before, and thus a module > could import just the more recent revision to get everything it needs? > Why would a module ever have to import an older revision? > > RFC 6020 says "New typedefs, groupings, rpcs, notifications, extensions, > features, and identities may be added." I take this to imply that they > cannot be removed or even renamed. Is this not the case? > The definitions can be changed and Y45 is about making sure that we always know precisely which definition is used - this was called typedef drift and grouping drift. Please check the extensive discussions we had about this plus the I-Ds people wrote about this. I do not think we should restart this discussion once more. /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 May 20 10:40:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A271A89C5 for ; Wed, 20 May 2015 10:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpGMLNfPcoqU for ; Wed, 20 May 2015 10:40:07 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (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 726AB1A89A8 for ; Wed, 20 May 2015 10:40:07 -0700 (PDT) Received: by lagv1 with SMTP id v1so85204068lag.3 for ; Wed, 20 May 2015 10:40:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ItxBACDv3FESRVXjz6I0VDL2Mny0wNnqNsIRAb7LFZ8=; b=LG0fnRcGPj61C2CZZpVpEHBQs47Q7j49t6b0VHId600JkDoe0WMmH7hm9yGZBy2luT IZv/m1HTOZUQlm415fWVttlTSwaVH+6V0TqEmoFpbULUrb9amq7SHjTCcVDZ6j/whi8i fSnf9z4yd9qDItWcXwNBVz+1Z4ehsE5nCvY5r1uF72GARQw1lZfmBecOQuEWhBmRypWT W5jZLDZKjnqhYyODWnUqUL4+8Y4r/PEmHSoRs64sAZsEakq3ZHf9s3yv1dybil9OWiUu iEOXsuwKrI5h7AaChyccnw24ifbQC/PN3swI2+jpCieajgcybaA8rdnyh3rWRj9ktkL5 vo1g== X-Gm-Message-State: ALoCoQmEmtx1PTtTvVyajroIw8oDKcyaeEFPD+3CeMiyZn+Eh+2nsTed/6Deti8b2ud44ABUjR8I MIME-Version: 1.0 X-Received: by 10.152.87.164 with SMTP id az4mr27026265lab.123.1432143605975; Wed, 20 May 2015 10:40:05 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 20 May 2015 10:40:05 -0700 (PDT) In-Reply-To: <20150520062409.GD51901@elstar.local> References: <20150519095931.GA49981@elstar.local> <20150519155535.GB50390@elstar.local> <20150520062409.GD51901@elstar.local> Date: Wed, 20 May 2015 10:40:05 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 17:40:09 -0000 On Tue, May 19, 2015 at 11:24 PM, Juergen Schoenwaelder wrote: > On Tue, May 19, 2015 at 09:22:29AM -0700, Andy Bierman wrote: >> On Tue, May 19, 2015 at 8:55 AM, Juergen Schoenwaelder >> wrote: >> > On Tue, May 19, 2015 at 05:55:26AM -0700, Andy Bierman wrote: >> >> Hi, >> >> >> >> RFC 6020, sec. 7.1.5 has this sentence: >> >> >> >> Multiple revisions of the same module MUST NOT be imported. >> >> >> >> I expect the new RFC will contain a complete explanation why >> >> this MUST NOT is wrong and needs to be changed. >> >> I would expect that multiple implementation examples of this >> >> approach can be cited, as proof that the new solution already works >> >> (before it is standardized). >> >> >> > >> > The attached yang module compiles using pyang 1.3 and if you replace >> > yang1:uuid with yang0:uuid, you get an error (as one would expect). >> >> A tool that parses the syntax is not really the same >> as a server implementation. I do not question the ability >> to distinguish 2 different strings as 2 different prefixes. > > How does the resolution of symbols (typedef and grouping names) at > module compile time impact the server implementation? > Implementors who followed the MUST NOT rule may have optimizations wrt/ symbol resolution. These will be invalid once the MUST NOT is removed. It is fairly trivial to parse YANG compared to implementing NETCONF/YANG it in a server. >> > Depending on how your code is organized, the Y45-04 behaviour may fall >> > out naturally and it takes extra effort to implement the MUST quoted >> > above. It may be possible to find a second implementation that >> > actually does not implement this MUST. (Our libsmi code has a problem >> > with import-by-revision so it is not a candidate unless we implement >> > this.) >> > >> > The reason to change the MUST quoted above can certainly be explained. >> > >> >> So what is the explanation? >> Removing a MUST NOT (especially from a 1.1 maintenance release) >> is a big deal. I would expect it to be easy to demonstrate that >> the original MUST NOT is a bug. >> > > The original MUST NOT makes it expensive to upgrade since it is an all > or nothing upgrade mechanism and the only way to ease the pain is that > the module author anticipates incremental updates and maintains N > different versions of definitions to ease the pain. The NETMOD > principle has always been that module readers are first priority, > module writers are second priority, and tool implementers are third > priority. Yes, Y45-04 is a change for tool implementors (except > perhaps tools that failed to implement the MUST NOT) but it is done > for a reason. > The original MUST NOT depends on the update rules in sec. 10. IMO following lots of dependencies makes YANG modules harder to read, so I don't agree Y45-04 is good for readers. > /js Andy > > -- > 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 May 20 10:51:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482B41A89F2 for ; Wed, 20 May 2015 10:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7mf0yB6FZCt for ; Wed, 20 May 2015 10:51:30 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (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 4DED61A88C2 for ; Wed, 20 May 2015 10:51:30 -0700 (PDT) Received: by laat2 with SMTP id t2so84809298laa.1 for ; Wed, 20 May 2015 10:51:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=58S5oKNSP3T28SnfJ7SRqbJWhuiIj9bbjen5I2Jr8UE=; b=jOt1ErlLT4/7KCm5BProOgb94yjQC79Pqa1wZcvt5ZyDO3Kq+DzWkc/k9nuVO5Z0iN vQ37iVgPN5ckN66k4BxtETKpMzoO4aVxZvqNp0Xp8W1snWB5hM7+iw6TgoUrvN2xwdTw aXq9p1tRjyn3QkhGJXjIKTwJ6dq+pJP4JyB5m8uN2SifCB03N/IoWBMtRO9oSxvDAyU2 GQf4Wo4GwNyohG/16grJXVFYg+szHkvAc1+PMNyWtFntIfotvnZXnOQmYTpa6k2kd0zk Q1pn4frWeuKUyfW8Q8EztpppIGq95E1mBYcZKlfO6udzTzH0MdOAk5iUPdr8EnvF43cL bUAw== X-Gm-Message-State: ALoCoQkfnzSORjK79ZiNXv7ROD8szO/AhiPRXSqsysbJfxSYkDbX8eKYsg1DRxzxuhBWPTWIwcnX MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr17224471lab.82.1432144288724; Wed, 20 May 2015 10:51:28 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 20 May 2015 10:51:28 -0700 (PDT) In-Reply-To: <20150520062649.GE51901@elstar.local> References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> Date: Wed, 20 May 2015 10:51:28 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Kent Watsen , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 17:51:32 -0000 On Tue, May 19, 2015 at 11:26 PM, Juergen Schoenwaelder wrote: > On Tue, May 19, 2015 at 09:20:52PM +0000, Kent Watsen wrote: >> >> >> It's unclear to me why Y45-04 is needed at all. Doesn't a newer revision >> of a module contain all the same typedefs from before, and thus a module >> could import just the more recent revision to get everything it needs? >> Why would a module ever have to import an older revision? >> >> RFC 6020 says "New typedefs, groupings, rpcs, notifications, extensions, >> features, and identities may be added." I take this to imply that they >> cannot be removed or even renamed. Is this not the case? >> > > The definitions can be changed and Y45 is about making sure that we > always know precisely which definition is used - this was called > typedef drift and grouping drift. Please check the extensive > discussions we had about this plus the I-Ds people wrote about this. > I do not think we should restart this discussion once more. > You seem to be suggesting that Kent is an uninformed observer and Y45-04 is actually really easy to understand. Neither is true. The solution is not intuitive at all. The implications of cherry-picking YANG statements from various revisions of a YANG module are not well understood. The concept of writing a YANG module so it works with all possible combinations of all possible back-revisions of imported modules is not well understood. The question "why can't the module being updated use the latest revision of an import" is quite legitimate. So is the question "Why can't I determine what a server implementation is required to support for a given YANG module?" The issue title "Better YANG conformance" is misleading because YANG conformance specificity is actually much worse with this solution. It's great for vendors who want to interpret for themselves what conformance means. Andy > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed May 20 17:39:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1F61ACDCE for ; Wed, 20 May 2015 17:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkhRAW9gAQUb for ; Wed, 20 May 2015 17:39:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE011ACD3C for ; Wed, 20 May 2015 17:39:52 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 00:39:34 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.01.0166.017; Thu, 21 May 2015 00:39:34 +0000 From: Kent Watsen To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] VRFY :45: better conformance mechanism Thread-Index: AQHQkhqJ88+ryphC8EOYQFVJdUlc3p2DjBoAgADbmoCAAL9IAIAALvSA Date: Thu, 21 May 2015 00:39:33 +0000 Message-ID: References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(189002)(199003)(164054003)(86362001)(2656002)(102836002)(2501003)(92566002)(106356001)(36756003)(93886004)(68736005)(2900100001)(87936001)(2950100001)(106116001)(189998001)(64706001)(62966003)(101416001)(46102003)(122556002)(77156002)(105586002)(66066001)(50986999)(40100003)(54356999)(4001350100001)(4001540100001)(99286002)(83506001)(5001770100001)(76176999)(107886002)(5001960100002)(5001860100001)(5001830100001)(81156007)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <0FBD6881AA440C4692FC40EB6BA8CA69@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2015 00:39:33.5851 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 00:39:55 -0000 >You seem to be suggesting that Kent is an uninformed observer and Y45-04 >is actually really easy to understand. Neither is true. I appreciate Andy's vote of confidence, but the reality is that I fell into a black hole right at the end of the Dallas meeting and just now caught up on the Y45 discussion. That said, my comment was based solely on what I read in the YANG 1.1 issue list, which wasn't easy to understand, so at least that part is true ;) After catching up on the Y45 discussion to date, I was concerned if Andy's objection to the removal of the MUST NOT clause might be substantiated by the Charter, which currently says: "The changes to RFC 6020 are restricted in the following ways: - All compliant YANG 1.0 modules must be accepted as compliant YANG 1.1 modules. - All known ambiguities of YANG 1.0 and all reported defects and errata will be addressed. - YANG 1.1 is not adding fundamentally new data modeling concepts to the language. - The changes of the specification will be kept to the minimum necessary to achieve the previously stated goals." The 1st point was the one I was worried about the most. Had it said instead "6020bis must be backwards compatible", then Y45-04 would not be allowed. However, as worded, Y45-04 is OK. The 3rd and 4th points are up to interpretation, but I don't think Y45-04 steps over the line. I don't have a strong preference or objection to any of the proposed solutions (Juergen, you can mark this statement in your table). That said, I wish we could better decouple "imports for typedefs/groupings" from "imports for augments/leaf-refs". For instance: import-declaration mod-a { prefix a; revision 2001-01-01; } import-declaration mod-a { prefix a2; revision 2002-01-01; } import-runtime mod-a { prefix a2; min-revision 2002-01-01; } The idea is to give explicit control to the module designer to cherry-pick declarations from any module revision *and* specify the min-revision needed (if any) in order to resolve protocol accessible nodes. Of course, this would break point #1 in the charter above, but it seems better than leaving it solely to the discretion of the server... Thanks, Kent From nobody Wed May 20 23:27:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D191A19E5 for ; Wed, 20 May 2015 23:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI7DCIxCDATd for ; Wed, 20 May 2015 23:27:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE3B1A19E3 for ; Wed, 20 May 2015 23:27:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4A71E15FD; Thu, 21 May 2015 08:27:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dcZLCOB2dtGZ; Thu, 21 May 2015 08:27:28 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 21 May 2015 08:27:37 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7147D2002B; Thu, 21 May 2015 08:27:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0EaX99_L1MMf; Thu, 21 May 2015 08:27:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF94320013; Thu, 21 May 2015 08:27:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AE69E33545A8; Thu, 21 May 2015 08:27:35 +0200 (CEST) Date: Thu, 21 May 2015 08:27:35 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150521062735.GA54298@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , "netmod@ietf.org" References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 06:27:42 -0000 On Wed, May 20, 2015 at 10:51:28AM -0700, Andy Bierman wrote: > The solution is not intuitive at all. The implications of cherry-picking > YANG statements from various revisions of a YANG module are > not well understood. If there are issues that have not been brought up before that we do not understand, please put them on the table. But things need to be concrete, not abstract. > The concept of writing a YANG module so it works with all possible > combinations of all possible back-revisions of imported modules is > not well understood. This is an example of an abstract claim that is difficult to work with. > The question "why can't the module being updated use the latest revision > of an import" is quite legitimate. So is the question "Why can't I determine > what a server implementation is required to support for a given YANG module?" > > The issue title "Better YANG conformance" is misleading because YANG > conformance specificity is actually much worse with this solution. > It's great for vendors who want to interpret for themselves > what conformance means. This is what I wrote: I believe we have reached rough consensus to adopt Y45-04 in order to resolve import ambiguities (aka typedef drift and grouping drift) and we will leave it to YANG extensions (to be worked on in the future) to provide means to define explicit conformance requirements (instead of trying to derive conformance requirements from import relationships alone). I think we concluded from ~1 year of discussions that deriving conformance requirements from import statements does not work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu May 21 02:27:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAEA1A905D for ; Thu, 21 May 2015 02:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4W1w-F8m07C for ; Thu, 21 May 2015 02:27:52 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 822C61A9027 for ; Thu, 21 May 2015 02:27:52 -0700 (PDT) Received: by lbcmx3 with SMTP id mx3so13597178lbc.1 for ; Thu, 21 May 2015 02:27:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=gwwbFPskUmzHkbA/irAQU+mNDgiv+8J6yr+JXhwGKvI=; b=DxTnyZX/Qi7GjcBsiaWc9O8/QqS2jVeMJdvjgFjk69d0LcYKlXbALGdocqRjreNb8N j5lbbw+aYPONMUKmFiTC+q1VtH9QFWEYw69PC8HoQRyhl/2otmS/hdRbetUhe5kmd2nv kdqnGCDToXo4oLjr/BVhibIGbfMf9TxqjVLiExNlcYfs8TIv94fNELIKBTnrt6w4yJJ4 iCM9hpylUCWWq5TNjXAgoe1s1ExIIvBFVO0/ajWCdj+FfhBM5fHLPx7FeBOPS7XxPGSu DBrUh/SqXEXVHWGCP/OYAh6p4/yk25KvvJNg5SEjXrFNV6HjoXFV24uDCDjlGAJke23f sh3A== X-Gm-Message-State: ALoCoQkszw+4k4yFtO8aDua4owpTixvX1tqoSdm7ZOJiT4rOyvmn436urnTHCaX4JXoj4gCxJPze MIME-Version: 1.0 X-Received: by 10.112.56.42 with SMTP id x10mr1395885lbp.123.1432200470784; Thu, 21 May 2015 02:27:50 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 21 May 2015 02:27:50 -0700 (PDT) In-Reply-To: <20150521062735.GA54298@elstar.local> References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> <20150521062735.GA54298@elstar.local> Date: Thu, 21 May 2015 02:27:50 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Kent Watsen , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 09:27:54 -0000 On Wed, May 20, 2015 at 11:27 PM, Juergen Schoenwaelder wrote: > On Wed, May 20, 2015 at 10:51:28AM -0700, Andy Bierman wrote: > >> The solution is not intuitive at all. The implications of cherry-picking >> YANG statements from various revisions of a YANG module are >> not well understood. > > If there are issues that have not been brought up before that we do > not understand, please put them on the table. But things need to be > concrete, not abstract. > >> The concept of writing a YANG module so it works with all possible >> combinations of all possible back-revisions of imported modules is >> not well understood. > > This is an example of an abstract claim that is difficult to work > with. According to Y45-04, if I use import-by-revision it only applies to some statements. The vendor can use any revision for the rest of the statements. This may be abstract to you, but it sounds like a tech-support nightmare to me. > >> The question "why can't the module being updated use the latest revision >> of an import" is quite legitimate. So is the question "Why can't I determine >> what a server implementation is required to support for a given YANG module?" >> >> The issue title "Better YANG conformance" is misleading because YANG >> conformance specificity is actually much worse with this solution. >> It's great for vendors who want to interpret for themselves >> what conformance means. > > This is what I wrote: > > I believe we have reached rough consensus to adopt Y45-04 in order > to resolve import ambiguities (aka typedef drift and grouping drift) > and we will leave it to YANG extensions (to be worked on in the > future) to provide means to define explicit conformance requirements > (instead of trying to derive conformance requirements from import > relationships alone). > > I think we concluded from ~1 year of discussions that deriving > conformance requirements from import statements does not work. > Then we agree that this issue does nothing for conformance (except make it worse). > /js > Andy > -- > 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 May 21 05:40:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB2E1AD350 for ; Thu, 21 May 2015 05:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZu8Ogk8hB2N for ; Thu, 21 May 2015 05:40:47 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A9B151AD333 for ; Thu, 21 May 2015 05:40:47 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 5F1621CC01AA; Thu, 21 May 2015 14:40:51 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen , Andy Bierman , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 21 May 2015 14:40:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 12:40:49 -0000 Kent Watsen writes: >>You seem to be suggesting that Kent is an uninformed observer and Y45-04 >>is actually really easy to understand. Neither is true. > > I appreciate Andy's vote of confidence, but the reality is that I fell > into a black hole right at the end of the Dallas meeting and just now > caught up on the Y45 discussion. That said, my comment was based solely > on what I read in the YANG 1.1 issue list, which wasn't easy to > understand, so at least that part is true ;) > > > > > After catching up on the Y45 discussion to date, I was concerned if Andy's > objection to the removal of the MUST NOT clause might be substantiated by > the Charter, which currently says: > > "The changes to RFC 6020 are restricted in the following ways: > - All compliant YANG 1.0 modules must be accepted as compliant > YANG 1.1 modules. > - All known ambiguities of YANG 1.0 and all reported defects > and errata will be addressed. > - YANG 1.1 is not adding fundamentally new data modeling > concepts to the language. > - The changes of the specification will be kept to the minimum > necessary to achieve the previously stated goals." > > > The 1st point was the one I was worried about the most. Had it said > instead "6020bis must be backwards compatible", then Y45-04 would not be > allowed. However, as worded, Y45-04 is OK. The 3rd and 4th points are up > to interpretation, but I don't think Y45-04 steps over the line. Of course it doesn't, but it is not only this issue where Andy insists (above the charter) on stricter backward compatitibility - except for new features that he has already implemented. I think we would get nowhere with YANG 1.1 if everybody fiercely opposed changes that need some work on his part. Lada > > > > > I don't have a strong preference or objection to any of the proposed > solutions (Juergen, you can mark this statement in your table). That > said, I wish we could better decouple "imports for typedefs/groupings" > from "imports for augments/leaf-refs". For instance: > > import-declaration mod-a { > prefix a; > revision 2001-01-01; > } > import-declaration mod-a { > prefix a2; > revision 2002-01-01; > } > import-runtime mod-a { > prefix a2; > min-revision 2002-01-01; > } > > > > > The idea is to give explicit control to the module designer to cherry-pick > declarations from any module revision *and* specify the min-revision > needed (if any) in order to resolve protocol accessible nodes. Of course, > this would break point #1 in the charter above, but it seems better than > leaving it solely to the discretion of the server... > > > Thanks, > Kent > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu May 21 07:21:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE461A1A66 for ; Thu, 21 May 2015 07:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3yKRnDE0BjM for ; Thu, 21 May 2015 07:21:27 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (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 91E5F1A03A2 for ; Thu, 21 May 2015 07:21:26 -0700 (PDT) Received: by laat2 with SMTP id t2so103732669laa.1 for ; Thu, 21 May 2015 07:21:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BVwO8KvnDbD+06eBqIg6Ilc0XvQCG0PTSDTOcjzxW64=; b=h4IiG4lXBRC3SHxR8LkaIvSltCSGBtDMCfvsfEQyIuPyotPB12i50rP8MHaBTP/jSh QffStsVTINV6sV69g7Z6b/r81toE/PteziXVLI2n5kapKFKOibkFFizjn6MoywcLB0k1 z+b5PCCa3j1nvOzjVBlBxCrgqkg2QzECt/bjnGGTxQ0hi+dWfjzeWgJjLTn/5l58X9e/ 1BH410UOGGrQb0aq+wHUaVZpIWAJHsoPcPERx0OYeJbNXkVFo5YKgpqByNN1VQnpWARQ 2x4Z0yCDTvZAzmcMLe4lr6oXZ3zGHcOiUXMkxB/0SxxRuQSh4O2Iu5OI1RmPn6rXxUqf ZgYw== X-Gm-Message-State: ALoCoQkOzDsTCINe9/pXB5SShYzmDnQMRxVPMbajd8nEGUfQBsi0RzNW14sr0/G4iAbbc+2eQ5fI MIME-Version: 1.0 X-Received: by 10.152.115.173 with SMTP id jp13mr2385184lab.119.1432218085042; Thu, 21 May 2015 07:21:25 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 21 May 2015 07:21:24 -0700 (PDT) In-Reply-To: References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> Date: Thu, 21 May 2015 07:21:24 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:21:28 -0000 On Thu, May 21, 2015 at 5:40 AM, Ladislav Lhotka wrote: > Kent Watsen writes: > >>>You seem to be suggesting that Kent is an uninformed observer and Y45-04 >>>is actually really easy to understand. Neither is true. >> >> I appreciate Andy's vote of confidence, but the reality is that I fell >> into a black hole right at the end of the Dallas meeting and just now >> caught up on the Y45 discussion. That said, my comment was based solely >> on what I read in the YANG 1.1 issue list, which wasn't easy to >> understand, so at least that part is true ;) >> >> >> >> >> After catching up on the Y45 discussion to date, I was concerned if Andy's >> objection to the removal of the MUST NOT clause might be substantiated by >> the Charter, which currently says: >> >> "The changes to RFC 6020 are restricted in the following ways: >> - All compliant YANG 1.0 modules must be accepted as compliant >> YANG 1.1 modules. >> - All known ambiguities of YANG 1.0 and all reported defects >> and errata will be addressed. >> - YANG 1.1 is not adding fundamentally new data modeling >> concepts to the language. >> - The changes of the specification will be kept to the minimum >> necessary to achieve the previously stated goals." >> >> >> The 1st point was the one I was worried about the most. Had it said >> instead "6020bis must be backwards compatible", then Y45-04 would not be >> allowed. However, as worded, Y45-04 is OK. The 3rd and 4th points are up >> to interpretation, but I don't think Y45-04 steps over the line. > > Of course it doesn't, but it is not only this issue where Andy insists > (above the charter) on stricter backward compatitibility - except for new > features that he has already implemented. > > I think we would get nowhere with YANG 1.1 if everybody fiercely opposed > changes that need some work on his part. > I haven't implemented any of YANG 1.1, but that is irrelevant. I don't ilke standardizing solutions that have never been tried and have not been proven to be useful. Changing a MUST NOT to a MAY in any standard is a big deal. It needs to be done with care and clarity. > Lada > Andy >> >> >> >> >> I don't have a strong preference or objection to any of the proposed >> solutions (Juergen, you can mark this statement in your table). That >> said, I wish we could better decouple "imports for typedefs/groupings" >> from "imports for augments/leaf-refs". For instance: >> >> import-declaration mod-a { >> prefix a; >> revision 2001-01-01; >> } >> import-declaration mod-a { >> prefix a2; >> revision 2002-01-01; >> } >> import-runtime mod-a { >> prefix a2; >> min-revision 2002-01-01; >> } >> >> >> >> >> The idea is to give explicit control to the module designer to cherry-pick >> declarations from any module revision *and* specify the min-revision >> needed (if any) in order to resolve protocol accessible nodes. Of course, >> this would break point #1 in the charter above, but it seems better than >> leaving it solely to the discretion of the server... >> >> >> Thanks, >> Kent >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Thu May 21 07:37:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C8A1A1BB5 for ; Thu, 21 May 2015 07:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfIGIDTG5j1j for ; Thu, 21 May 2015 07:37:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2661A1BBC for ; Thu, 21 May 2015 07:37:03 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id C6BF0141454; Thu, 21 May 2015 16:37:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1432219021; bh=tXS1jQn8dhzPj8cyahhCDRxQi7fDDSrCmhruKlfZ+YU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=t1lVvHJyB18rvNB8UTM7cITE0JEuqgiqOEZhaIC234o2v+UbQsedH2ZnJDgeV6ILs HwiZVGqjiTsw3sUuJ2VBTWdEVF/7P+v9l/CjzyE3JL9kbfGwIkxHnxCAPZIgHAOcUL fWCRmR6AJauFs9PUrJek9TLN9uFfvZIvuw0gdxZE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 21 May 2015 16:37:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:37:07 -0000 > On 21 May 2015, at 16:21, Andy Bierman wrote: >=20 > On Thu, May 21, 2015 at 5:40 AM, Ladislav Lhotka = wrote: >> Kent Watsen writes: >>=20 >>>> You seem to be suggesting that Kent is an uninformed observer and = Y45-04 >>>> is actually really easy to understand. Neither is true. >>>=20 >>> I appreciate Andy's vote of confidence, but the reality is that I = fell >>> into a black hole right at the end of the Dallas meeting and just = now >>> caught up on the Y45 discussion. That said, my comment was based = solely >>> on what I read in the YANG 1.1 issue list, which wasn't easy to >>> understand, so at least that part is true ;) >>>=20 >>>=20 >>> >>>=20 >>> After catching up on the Y45 discussion to date, I was concerned if = Andy's >>> objection to the removal of the MUST NOT clause might be = substantiated by >>> the Charter, which currently says: >>>=20 >>> "The changes to RFC 6020 are restricted in the following ways: >>> - All compliant YANG 1.0 modules must be accepted as compliant >>> YANG 1.1 modules. >>> - All known ambiguities of YANG 1.0 and all reported defects >>> and errata will be addressed. >>> - YANG 1.1 is not adding fundamentally new data modeling >>> concepts to the language. >>> - The changes of the specification will be kept to the minimum >>> necessary to achieve the previously stated goals." >>>=20 >>>=20 >>> The 1st point was the one I was worried about the most. Had it said >>> instead "6020bis must be backwards compatible", then Y45-04 would = not be >>> allowed. However, as worded, Y45-04 is OK. The 3rd and 4th points = are up >>> to interpretation, but I don't think Y45-04 steps over the line. >>=20 >> Of course it doesn't, but it is not only this issue where Andy = insists >> (above the charter) on stricter backward compatitibility - except for = new >> features that he has already implemented. >>=20 >> I think we would get nowhere with YANG 1.1 if everybody fiercely = opposed >> changes that need some work on his part. >>=20 >=20 >=20 > I haven't implemented any of YANG 1.1, but that is irrelevant. You once mentioned Yuma already supported XPath extension functions. Is = it not true? > I don't ilke standardizing solutions that have never been > tried and have not been proven to be useful. >=20 > Changing a MUST NOT to a MAY in any standard is a big deal. > It needs to be done with care and clarity. RFC 6020 also states that must and when expessions are XPath 1.0, and we = are moving away from it. This is IMO a much bigger change than Y45-04. Lada >=20 >> Lada >>=20 >=20 > Andy >=20 >>>=20 >>>=20 >>> >>>=20 >>> I don't have a strong preference or objection to any of the proposed >>> solutions (Juergen, you can mark this statement in your table). = That >>> said, I wish we could better decouple "imports for = typedefs/groupings" >>> from "imports for augments/leaf-refs". For instance: >>>=20 >>> import-declaration mod-a { >>> prefix a; >>> revision 2001-01-01; >>> } >>> import-declaration mod-a { >>> prefix a2; >>> revision 2002-01-01; >>> } >>> import-runtime mod-a { >>> prefix a2; >>> min-revision 2002-01-01; >>> } >>>=20 >>>=20 >>>=20 >>>=20 >>> The idea is to give explicit control to the module designer to = cherry-pick >>> declarations from any module revision *and* specify the min-revision >>> needed (if any) in order to resolve protocol accessible nodes. Of = course, >>> this would break point #1 in the charter above, but it seems better = than >>> leaving it solely to the discretion of the server... >>>=20 >>>=20 >>> Thanks, >>> Kent >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu May 21 07:42:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F27F1A6F33 for ; Thu, 21 May 2015 07:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ueJb8l3iTRP for ; Thu, 21 May 2015 07:42:46 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4410E1A6EFC for ; Thu, 21 May 2015 07:42:46 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C09661AE035C; Thu, 21 May 2015 16:42:44 +0200 (CEST) Date: Thu, 21 May 2015 16:42:44 +0200 (CEST) Message-Id: <20150521.164244.1330523722762887433.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> References: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:42:48 -0000 Ladislav Lhotka wrote: > RFC 6020 also states that must and when expessions are XPath 1.0, and > we are moving away from it. No we are not moving away from XPath 1.0. XPath 1.0 allows you to specify a function library - in fact, it *requires* you to do this - and we use the core function + some more. /martin From nobody Thu May 21 07:47:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1A61A6FBB for ; Thu, 21 May 2015 07:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFgfsy4ggJSg for ; Thu, 21 May 2015 07:47:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C895F1A6F33 for ; Thu, 21 May 2015 07:47:38 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 65AB8141499; Thu, 21 May 2015 16:47:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1432219657; bh=txLSPL0dBVEHefAjy8FLTE1Hz43P4vZK9UNGKL0rVAc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DyM2iYzHbxzxsiip0YK1K+j3oLzAWCszRfTZcZ9vLjL3QbN8o0u3YO7YU4Ej0YnZz zdQumWsvIYvLPY3Lk3VPMqam2MUHFtQBqmXU6gEUvxwCwmFA+k86Rgcz6Kezu48v5t khoyyMXbKQC9gdL+ZcWYnCJNqNoWGoYhQH9xqei8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: <20150521.164244.1330523722762887433.mbj@tail-f.com> Date: Thu, 21 May 2015 16:47:38 +0200 Content-Transfer-Encoding: 7bit Message-Id: <35BCD9CC-4D3C-4BA2-B172-9BB2364F3717@nic.cz> References: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> <20150521.164244.1330523722762887433.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:47:45 -0000 > On 21 May 2015, at 16:42, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: >> RFC 6020 also states that must and when expessions are XPath 1.0, and >> we are moving away from it. > > No we are not moving away from XPath 1.0. XPath 1.0 allows you to specify > a function library - in fact, it *requires* you to do this - and we > use the core function + some more. Well, but RFC 6020 states: o The function library is the core function library defined in [XPATH], and a function "current()" that returns a node set with the initial context node. Introducing new functions certainly affects implementors. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu May 21 07:50:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E33C1A1B44 for ; Thu, 21 May 2015 07:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v2LWm13HOdn for ; Thu, 21 May 2015 07:50:05 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 980061A1BAC for ; Thu, 21 May 2015 07:50:05 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id DA3161AE035C; Thu, 21 May 2015 16:50:04 +0200 (CEST) Date: Thu, 21 May 2015 16:50:04 +0200 (CEST) Message-Id: <20150521.165004.1789028089280303536.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <35BCD9CC-4D3C-4BA2-B172-9BB2364F3717@nic.cz> References: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> <20150521.164244.1330523722762887433.mbj@tail-f.com> <35BCD9CC-4D3C-4BA2-B172-9BB2364F3717@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:50:06 -0000 Ladislav Lhotka wrote: > > > On 21 May 2015, at 16:42, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> RFC 6020 also states that must and when expessions are XPath 1.0, and > >> we are moving away from it. > > > > No we are not moving away from XPath 1.0. XPath 1.0 allows you to specify > > a function library - in fact, it *requires* you to do this - and we > > use the core function + some more. > > Well, but RFC 6020 states: > > o The function library is the core function library defined in > [XPATH], and a function "current()" that returns a node set with > the initial context node. > > Introducing new functions certainly affects implementors. Absolutely. But we're not moving away from XPath 1.0. /martin From nobody Thu May 21 07:51:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF261A1BAC for ; Thu, 21 May 2015 07:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsbWyKPdgoBN for ; Thu, 21 May 2015 07:51:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520EA1A1B7F for ; Thu, 21 May 2015 07:51:27 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id EF7AB14143A for ; Thu, 21 May 2015 16:51:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1432219886; bh=93BsPBNJe7khWdR/GVdwgxS5F7swAztyHerJQNpraRc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=WcVSOOnZ154yAYZU57BdQYDegY9c2cCIMUWYlY6pnwEyDZiEpihBF1EhQS+6elNr9 oUkNEkcgCTxz20mHakEfPjwzc7zfAGmknaMrlm0ndyVYCJENh9eGJgIE0yQtT3Tm24 J8ZRgnEkjDSphQsWz7M2X/g44a508ddF81aYtD6U= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: <20150521.165004.1789028089280303536.mbj@tail-f.com> Date: Thu, 21 May 2015 16:51:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1AE44CD8-5B43-4B8F-A5BC-1923E3623CEB@nic.cz> References: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> <20150521.164244.1330523722762887433.mbj@tail-f.com> <35BCD9CC-4D3C-4BA2-B172-9BB2364F3717@nic.cz> <20150521.165004.1789028089280303536.mbj@tail-f.com> To: NETMOD Working Group X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:51:28 -0000 > On 21 May 2015, at 16:50, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 21 May 2015, at 16:42, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>> RFC 6020 also states that must and when expessions are XPath 1.0, = and >>>> we are moving away from it. >>>=20 >>> No we are not moving away from XPath 1.0. XPath 1.0 allows you to = specify >>> a function library - in fact, it *requires* you to do this - and we >>> use the core function + some more. >>=20 >> Well, but RFC 6020 states: >>=20 >> o The function library is the core function library defined in >> [XPATH], and a function "current()" that returns a node set with >> the initial context node. >>=20 >> Introducing new functions certainly affects implementors. >=20 > Absolutely. But we're not moving away from XPath 1.0. Yes, sorry, this was my wrong formulation. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu May 21 10:14:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9676C1A0056 for ; Thu, 21 May 2015 10:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFDX5R_Y-y9m for ; Thu, 21 May 2015 10:14:55 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 4681A1A0063 for ; Thu, 21 May 2015 10:14:55 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so23055019lbb.0 for ; Thu, 21 May 2015 10:14:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BYDrtUeVZr/xzC7JDsPwCYkc7OT1Og7ZG1WqcYTAlUc=; b=Qv8JqIuHl/HUIIHWQY9qqkU8exggvnnYvl8WLNa4VtbrcIIMJajOk4HekKg5b58Z9C 17kuEZFfymiWsVrBx6u1DxJPOg3KdKCAKI3wvzQuysLIt3JyoBWfSttHm19o0LFKcnwL 9MlnJWdp0rhc1S9Br+t6rDizq24oSrcwe9PM4qFBTdaqgP+bYrqWM6IYibbOarmhlxY8 CEHvTljGWZKeuYigzY1U4h2uE8LArISrJthw5cl8SmTKwPAZm9L4GmYyAfRAiHUE0yPO Nd0PtjX1ZAvhaMYgtJJ3C4hOpsQJwUpevomCGHWpfbxfQ/yWVooyROmSoq49BF3rgKkn LUjw== X-Gm-Message-State: ALoCoQk5nhRjPP1sEEUQAehskNF926OiwIRmOMCal5xoY+0kutHO8I4yQugMOdoAcB1jaQ9wC+HU MIME-Version: 1.0 X-Received: by 10.112.77.234 with SMTP id v10mr3024759lbw.119.1432228493810; Thu, 21 May 2015 10:14:53 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 21 May 2015 10:14:53 -0700 (PDT) In-Reply-To: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> Date: Thu, 21 May 2015 10:14:53 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:14:57 -0000 On Thu, May 21, 2015 at 7:37 AM, Ladislav Lhotka wrote: > >> On 21 May 2015, at 16:21, Andy Bierman wrote: >> >> On Thu, May 21, 2015 at 5:40 AM, Ladislav Lhotka wrote: >>> Kent Watsen writes: >>> >>>>> You seem to be suggesting that Kent is an uninformed observer and Y45-04 >>>>> is actually really easy to understand. Neither is true. >>>> >>>> I appreciate Andy's vote of confidence, but the reality is that I fell >>>> into a black hole right at the end of the Dallas meeting and just now >>>> caught up on the Y45 discussion. That said, my comment was based solely >>>> on what I read in the YANG 1.1 issue list, which wasn't easy to >>>> understand, so at least that part is true ;) >>>> >>>> >>>> >>>> >>>> After catching up on the Y45 discussion to date, I was concerned if Andy's >>>> objection to the removal of the MUST NOT clause might be substantiated by >>>> the Charter, which currently says: >>>> >>>> "The changes to RFC 6020 are restricted in the following ways: >>>> - All compliant YANG 1.0 modules must be accepted as compliant >>>> YANG 1.1 modules. >>>> - All known ambiguities of YANG 1.0 and all reported defects >>>> and errata will be addressed. >>>> - YANG 1.1 is not adding fundamentally new data modeling >>>> concepts to the language. >>>> - The changes of the specification will be kept to the minimum >>>> necessary to achieve the previously stated goals." >>>> >>>> >>>> The 1st point was the one I was worried about the most. Had it said >>>> instead "6020bis must be backwards compatible", then Y45-04 would not be >>>> allowed. However, as worded, Y45-04 is OK. The 3rd and 4th points are up >>>> to interpretation, but I don't think Y45-04 steps over the line. >>> >>> Of course it doesn't, but it is not only this issue where Andy insists >>> (above the charter) on stricter backward compatitibility - except for new >>> features that he has already implemented. >>> >>> I think we would get nowhere with YANG 1.1 if everybody fiercely opposed >>> changes that need some work on his part. >>> >> >> >> I haven't implemented any of YANG 1.1, but that is irrelevant. > > You once mentioned Yuma already supported XPath extension functions. Is it not true? > Within the C code there is an extensible XPath function library. It would be unreasonable to design a XPath implementation with a hard-wired function library. The standard is designed to support the opposite. >> I don't ilke standardizing solutions that have never been >> tried and have not been proven to be useful. >> >> Changing a MUST NOT to a MAY in any standard is a big deal. >> It needs to be done with care and clarity. > > RFC 6020 also states that must and when expessions are XPath 1.0, and we are moving away from it. This is IMO a much bigger change than Y45-04. > Show me the "MUST NOT" that is getting reversed and I will agree with you. I am not objecting to Y45-04. I am objecting to removing a "MUST NOT" from the standard. Discussion of relative implementation complexity of other YANG 1.1 changes is irrelevant. > Lada > Andy >> >>> Lada >>> >> >> Andy >> >>>> >>>> >>>> >>>> >>>> I don't have a strong preference or objection to any of the proposed >>>> solutions (Juergen, you can mark this statement in your table). That >>>> said, I wish we could better decouple "imports for typedefs/groupings" >>>> from "imports for augments/leaf-refs". For instance: >>>> >>>> import-declaration mod-a { >>>> prefix a; >>>> revision 2001-01-01; >>>> } >>>> import-declaration mod-a { >>>> prefix a2; >>>> revision 2002-01-01; >>>> } >>>> import-runtime mod-a { >>>> prefix a2; >>>> min-revision 2002-01-01; >>>> } >>>> >>>> >>>> >>>> >>>> The idea is to give explicit control to the module designer to cherry-pick >>>> declarations from any module revision *and* specify the min-revision >>>> needed (if any) in order to resolve protocol accessible nodes. Of course, >>>> this would break point #1 in the charter above, but it seems better than >>>> leaving it solely to the discretion of the server... >>>> >>>> >>>> Thanks, >>>> Kent >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Thu May 21 10:38:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAABE1A008B for ; Thu, 21 May 2015 10:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csHqcvSKUgiI for ; Thu, 21 May 2015 10:38:47 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D13581A0068 for ; Thu, 21 May 2015 10:38:46 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2E20D1AE035C; Thu, 21 May 2015 19:38:45 +0200 (CEST) Message-ID: <555E1825.9020007@tail-f.com> Date: Thu, 21 May 2015 19:38:45 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Andy Bierman References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:38:48 -0000 On 2015-05-21 19:14, Andy Bierman wrote: > On Thu, May 21, 2015 at 7:37 AM, Ladislav Lhotka wrote: >> >> RFC 6020 also states that must and when expessions are XPath 1.0, and we are moving away from it. This is IMO a much bigger change than Y45-04. >> > > Show me the "MUST NOT" that is getting reversed and I will agree with you. > I am not objecting to Y45-04. I am objecting to removing a "MUST NOT" > from the standard. Discussion of relative implementation complexity > of other YANG 1.1 changes is irrelevant. I don't have one for that, but these are: A member type can be of any built-in or derived type, except it MUST NOT be one of the built-in types "empty" or "leafref". I believe they're described as CLR in the issues doc... --Per Hedeland From nobody Thu May 21 10:47:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2132D1A0199 for ; Thu, 21 May 2015 10:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6WafBi6yOYH for ; Thu, 21 May 2015 10:46:58 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (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 A8EDC1A0264 for ; Thu, 21 May 2015 10:46:57 -0700 (PDT) Received: by laat2 with SMTP id t2so108096947laa.1 for ; Thu, 21 May 2015 10:46:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UTpjluMB81ZJuYOB8pU8qdlVlgCJcI1fSgs75qJPpTs=; b=Kx6srPVesQx9smiy1OsJdPmASJ6xyMiNzZC8MVIYdaaQdKqcfyE63vpeCCbWT6hS15 B0EryZUqDp3W92mAqP+XoeKiJlojl+7vo5dJCMVcMaI/+2ch3M/Ory/eMyDKdiyhlt/V 26FWVwLS1blTN2aqsMOLdVG1CAwiA9eRCCW2o7Oml14Jg0Xo0QXVYABOJM6EZcQrWooX s7f/5yJogdKKMhAYmwonbQMEBE70jeB5lLyTfgoJeeux+7G6w/OAW5Zq3ack59rE43OZ U+U/SM4g/Ybk286qIDmY+UNIA6vpOjv+xyn7BNSRcBLyor3fPheGAtP+vskRsmuczTMJ VNJw== X-Gm-Message-State: ALoCoQk+w4NS1RGAthmqpjOr5pOC3XT4AL8N78QtJ3hhLfixwVtft9k8wH1Xv36iMphi/F/3VA3Q MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr3211509laj.88.1432230416225; Thu, 21 May 2015 10:46:56 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 21 May 2015 10:46:56 -0700 (PDT) In-Reply-To: <555E1825.9020007@tail-f.com> References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> <555E1825.9020007@tail-f.com> Date: Thu, 21 May 2015 10:46:56 -0700 Message-ID: From: Andy Bierman To: Per Hedeland Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:46:59 -0000 On Thu, May 21, 2015 at 10:38 AM, Per Hedeland wrote: > On 2015-05-21 19:14, Andy Bierman wrote: >> On Thu, May 21, 2015 at 7:37 AM, Ladislav Lhotka wrote: >>> >>> RFC 6020 also states that must and when expessions are XPath 1.0, and we are moving away from it. This is IMO a much bigger change than Y45-04. >>> >> >> Show me the "MUST NOT" that is getting reversed and I will agree with you. >> I am not objecting to Y45-04. I am objecting to removing a "MUST NOT" >> from the standard. Discussion of relative implementation complexity >> of other YANG 1.1 changes is irrelevant. > > I don't have one for that, but these are: > > A member type can be of any built-in or derived type, except it MUST > NOT be one of the built-in types "empty" or "leafref". > > I believe they're described as CLR in the issues doc... > I don't know about leafref, but type "empty" and a zero-length string are identical on the wire, and that is allowed. This is a trivial change to YANG syntax. I don't think Y45 has such a trivial impact on YANG syntax or usage. > --Per Hedeland Andy From nobody Thu May 21 11:06:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671661A1A13 for ; Thu, 21 May 2015 11:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZtYQsgM0GBN for ; Thu, 21 May 2015 11:06:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CEDE41A19E4 for ; Thu, 21 May 2015 11:06:51 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1CAA21AE035C; Thu, 21 May 2015 20:06:51 +0200 (CEST) Message-ID: <555E1EBB.4060405@tail-f.com> Date: Thu, 21 May 2015 20:06:51 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Andy Bierman References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> <555E1825.9020007@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:06:53 -0000 On 2015-05-21 19:46, Andy Bierman wrote: > On Thu, May 21, 2015 at 10:38 AM, Per Hedeland wrote: >> On 2015-05-21 19:14, Andy Bierman wrote: >>> On Thu, May 21, 2015 at 7:37 AM, Ladislav Lhotka wrote: >>>> >>>> RFC 6020 also states that must and when expessions are XPath 1.0, and we are moving away from it. This is IMO a much bigger change than Y45-04. >>>> >>> >>> Show me the "MUST NOT" that is getting reversed and I will agree with you. >>> I am not objecting to Y45-04. I am objecting to removing a "MUST NOT" >>> from the standard. Discussion of relative implementation complexity >>> of other YANG 1.1 changes is irrelevant. >> >> I don't have one for that, but these are: >> >> A member type can be of any built-in or derived type, except it MUST >> NOT be one of the built-in types "empty" or "leafref". >> >> I believe they're described as CLR in the issues doc... >> > > I don't know about leafref, but type "empty" and a zero-length string > are identical on the wire, and that is allowed. This is a trivial > change to YANG syntax. I don't think Y45 has such a trivial impact > on YANG syntax or usage. Probably not (though the needed server implementation change is not likely to be as trivial as the syntax change), but you said that you weren't objecting to Y45, but to removing a "MUST NOT"... --Per From nobody Thu May 21 11:25:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C401A1A1C for ; Thu, 21 May 2015 11:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkri6PMjqIhB for ; Thu, 21 May 2015 11:25:11 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 E90BF1A034F for ; Thu, 21 May 2015 11:25:10 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so24379822lbb.0 for ; Thu, 21 May 2015 11:25:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3Ae2J/pn3UqdcLY1v6sDyihOAhfow1dGh4kpiAmRfpA=; b=FZAQkh6+W0LnQIDws4jBwuzynzdSOaJksVmN00l4epP/B3L6VCX+9UkjkFo9/f+nic c0YSLURyjxxDZwFEK5AoL6cQ11Qa53iearLXp6Pt462x+qhTq3UQxvNRWNNS8lQTgX7Q 4MRXnrU/4eBlbTu8B00KzPRivFWAd6HfFjAckhg0c/STNcK09P3IZ4guGgf+mLpXYtWJ lcKos+4dYK0+Svgv5o+PyTEmDsobqhA2ueroG70IbMWxu+3l9v5i4SdTWI6KtuIgHKz1 0hbaLmYJh0g4/7fTwLPC42rnnVcaHVzGcTmS+p/uYaFRhBruDxL4KmjeycuAaIik4N0l KKuw== X-Gm-Message-State: ALoCoQndVznZkoANxEBribGcY+0CB92MLvv2pKvh7pDZDNNJ8qb5s+1zqK4XG+9fdJyDMZFd+XM2 MIME-Version: 1.0 X-Received: by 10.152.115.173 with SMTP id jp13mr3231706lab.119.1432232709474; Thu, 21 May 2015 11:25:09 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 21 May 2015 11:25:09 -0700 (PDT) In-Reply-To: <555E1EBB.4060405@tail-f.com> References: <20150519095931.GA49981@elstar.local> <20150520062649.GE51901@elstar.local> <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> <555E1825.9020007@tail-f.com> <555E1EBB.4060405@tail-f.com> Date: Thu, 21 May 2015 11:25:09 -0700 Message-ID: From: Andy Bierman To: Per Hedeland Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:25:12 -0000 On Thu, May 21, 2015 at 11:06 AM, Per Hedeland wrote: > On 2015-05-21 19:46, Andy Bierman wrote: >> On Thu, May 21, 2015 at 10:38 AM, Per Hedeland wrote: >>> On 2015-05-21 19:14, Andy Bierman wrote: >>>> On Thu, May 21, 2015 at 7:37 AM, Ladislav Lhotka wrote: >>>>> >>>>> RFC 6020 also states that must and when expessions are XPath 1.0, and we are moving away from it. This is IMO a much bigger change than Y45-04. >>>>> >>>> >>>> Show me the "MUST NOT" that is getting reversed and I will agree with you. >>>> I am not objecting to Y45-04. I am objecting to removing a "MUST NOT" >>>> from the standard. Discussion of relative implementation complexity >>>> of other YANG 1.1 changes is irrelevant. >>> >>> I don't have one for that, but these are: >>> >>> A member type can be of any built-in or derived type, except it MUST >>> NOT be one of the built-in types "empty" or "leafref". >>> >>> I believe they're described as CLR in the issues doc... >>> >> >> I don't know about leafref, but type "empty" and a zero-length string >> are identical on the wire, and that is allowed. This is a trivial >> change to YANG syntax. I don't think Y45 has such a trivial impact >> on YANG syntax or usage. > > Probably not (though the needed server implementation change is not > likely to be as trivial as the syntax change), but you said that you > weren't objecting to Y45, but to removing a "MUST NOT"... I object to removing this specific MUST NOT, not any in general. I don't agree this MUST NOT was an omission or trivial CLR like the example you cited. I think the WG made the correct decision the first time. > > --Per Andy From nobody Thu May 21 13:35:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365731A8AAB for ; Thu, 21 May 2015 13:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lZfvAbLaL8h for ; Thu, 21 May 2015 13:35:55 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2374A1A8AAA for ; Thu, 21 May 2015 13:35:55 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 2003C1AE035C; Thu, 21 May 2015 22:35:53 +0200 (CEST) Date: Thu, 21 May 2015 22:36:45 +0200 (CEST) Message-Id: <20150521.223645.824542350167593812.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 20:35:56 -0000 Andy, I don't think the implementation burden on the server is that heavy. A YANG 1.0 compliant server today supports: leaf a in module A of type foo from foo@2001-01-01 leaf b in module B of type foo from foo@2002-02-02 I.e., it supports different leafs in the combined data model referring to different versions of the same type. A YANG 1.1 server would also support leaf a in module A of type foo from foo@2001-01-01 leaf b in module A of type foo from foo@2002-02-02 Of course, how much a specific implementation is affected will vary, but I don't think the concepts are *that* different. /martin From nobody Thu May 21 14:17:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58961A908A for ; Thu, 21 May 2015 14:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6uRcXqkzyU3 for ; Thu, 21 May 2015 14:17:53 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (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 1C5401A907E for ; Thu, 21 May 2015 14:17:53 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so27400100lbb.2 for ; Thu, 21 May 2015 14:17:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EPm9byUh0bOkFto2FqOqItTmHJM6iNXGJLrudGQOL4k=; b=R0Tv0VPtfpdGGRwIbGEV18e/YnIa9tDIKxqc9r8Idrl4gRyuyU9LKTkYyucBPNb977 /YQKXGl5NBYKwOcxUdLRZRLutxLkXq68gp6r6Pe5waltbaEOBQal+mgfS/7TIxOfQgSv mDbuQhnr8/JMYcputJwmYB1IS/Y1zmhN8HE6OOVzC891xcARQ9P6xfcYhfkf7PPujV9B TCalXXjUCrMPbsoV21E8isF0fhTIFDjkjgOap6FtYywVWk+6qHFZrjpLRqUv/rp0QdBY qcviO+P2amYibgxG2REyw01SD5lKVh7Cx0+qRADqdvegpLtcExVjG5Xz7mkiIY5Z+hza dACw== X-Gm-Message-State: ALoCoQlc7zxmhXtTydivfXl5NQPSsmRn5FK1Mqt4eeDJP9Z/PuDKD9GKBrDnYIlvWc8nbJcCnSyi MIME-Version: 1.0 X-Received: by 10.112.139.130 with SMTP id qy2mr3815887lbb.33.1432243071508; Thu, 21 May 2015 14:17:51 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 21 May 2015 14:17:51 -0700 (PDT) In-Reply-To: <20150521.223645.824542350167593812.mbj@tail-f.com> References: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> <20150521.223645.824542350167593812.mbj@tail-f.com> Date: Thu, 21 May 2015 14:17:51 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 21:17:54 -0000 On Thu, May 21, 2015 at 1:36 PM, Martin Bjorklund wrote: > Andy, > > I don't think the implementation burden on the server is that heavy. > A YANG 1.0 compliant server today supports: > > leaf a in module A of type foo from foo@2001-01-01 > leaf b in module B of type foo from foo@2002-02-02 > > I.e., it supports different leafs in the combined data model referring > to different versions of the same type. > > A YANG 1.1 server would also support > > leaf a in module A of type foo from foo@2001-01-01 > leaf b in module A of type foo from foo@2002-02-02 > > Of course, how much a specific implementation is affected will vary, > but I don't think the concepts are *that* different. > I am not that concerned about the implementation details. Our server fully supports multiple revisions at once. I am more concerned with the increased complexity due to multiple imports of the same module. I think Y45-03 is sufficient and Y45-04 covers 1 or 2 corner-cases that don't justify the increased complexity. In the hands of experts it won't be a problem, but most YANG modules are not read or written by experts. We don't have any experience using multiple revisions at once. Even the example touted as the reason we need Y45-04 was pointless (because ip-address the same in both revisions). I am not convinced it is really needed. I am much more comfortable adding a new feature like "actions", because there is significant deployment of this solution approach. > > /martin Andy From nobody Thu May 21 16:15:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9AF1A897F for ; Thu, 21 May 2015 16:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNaXHaasNMkG for ; Thu, 21 May 2015 16:15:19 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 BF9111A8925 for ; Thu, 21 May 2015 16:15:18 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so1274210lbb.3 for ; Thu, 21 May 2015 16:15:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wQfmRQRcx36RQBZ3FPQeyeMlYMQpq2coPrWF8d1AChE=; b=fqN8D98JU9lpCLAB9j7V9QKH1u6YX31gjb5K2j/r1TgGfNoIqkylnkmBsDJR2AQXKW 0jAtYnuxlYKqZV+pcuvplYpL8DEpYNr9z+JkuKsNhTvTlH89z1kUZlbiW/DQoLeeOgMY fk6SPc3apHMm9Vg4RXWAl0KVjJ24sTjsAWX10PLeO3WxLS4US2NhzeTHGXhIlvFAasOR 0ByKNHKyYnr9G8G7vgFqfASiwtohp81qJd077A9hbOffFmZOLrNDFiTDQ/yHoKlK7y9b xv55FosSecJYY5c6EUy9hwChFudQ4/yru6HFwt06stWPIioAuY/A93tDLT9XkOmWSiRE K1fQ== X-Gm-Message-State: ALoCoQlQvh6oF91dWCqbSxajExzZXXLaKwEi1Tj+NC2ZL9ClEmiwthAfXjCfMbaDNjbhzGmxl3hZ MIME-Version: 1.0 X-Received: by 10.112.77.234 with SMTP id v10mr3997532lbw.119.1432250117349; Thu, 21 May 2015 16:15:17 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 21 May 2015 16:15:17 -0700 (PDT) In-Reply-To: <20150521.223645.824542350167593812.mbj@tail-f.com> References: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> <20150521.223645.824542350167593812.mbj@tail-f.com> Date: Thu, 21 May 2015 16:15:17 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 23:15:20 -0000 Martin, I will remove my objection to Y45-04 if you write a section in the draft about why multiple imports of the same module is needed, plus examples that show appropriate use of this new feature. I also think examples are needed that highlight how data nodes and augments ignore the revision date (multiple module augments example), while still using groupings and typedefs that do not ignore the revision dates. IETF modules should not need to cherry-pick from multiple revisions. That means the WG is deciding to stay "down-rev" on something, and that should not be approved without good reason. Andy On Thu, May 21, 2015 at 1:36 PM, Martin Bjorklund wrote: > Andy, > > I don't think the implementation burden on the server is that heavy. > A YANG 1.0 compliant server today supports: > > leaf a in module A of type foo from foo@2001-01-01 > leaf b in module B of type foo from foo@2002-02-02 > > I.e., it supports different leafs in the combined data model referring > to different versions of the same type. > > A YANG 1.1 server would also support > > leaf a in module A of type foo from foo@2001-01-01 > leaf b in module A of type foo from foo@2002-02-02 > > Of course, how much a specific implementation is affected will vary, > but I don't think the concepts are *that* different. > > > /martin From nobody Fri May 22 01:20:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0F81ACED2 for ; Fri, 22 May 2015 01:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz6u5ue5JBkS for ; Fri, 22 May 2015 01:20:36 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B81D31ACECC for ; Fri, 22 May 2015 01:20:36 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8FB421CC0168; Fri, 22 May 2015 10:20:39 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20150521.223645.824542350167593812.mbj@tail-f.com> References: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> <20150521.223645.824542350167593812.mbj@tail-f.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 22 May 2015 10:20:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 08:20:40 -0000 Martin Bjorklund writes: > Andy, > > I don't think the implementation burden on the server is that heavy. > A YANG 1.0 compliant server today supports: > > leaf a in module A of type foo from foo@2001-01-01 > leaf b in module B of type foo from foo@2002-02-02 In fact, the same can be done in two submodules of the same module, or main module and submodule, which leads exactly to the situation below - and that's allowed even in YANG 1.0. Lada > > I.e., it supports different leafs in the combined data model referring > to different versions of the same type. > > A YANG 1.1 server would also support > > leaf a in module A of type foo from foo@2001-01-01 > leaf b in module A of type foo from foo@2002-02-02 > > Of course, how much a specific implementation is affected will vary, > but I don't think the concepts are *that* different. > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri May 22 01:29:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F711ACE99 for ; Fri, 22 May 2015 01:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5keWj2jJkhni for ; Fri, 22 May 2015 01:29:48 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7081ACEF9 for ; Fri, 22 May 2015 01:29:48 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id A9B561CC0168; Fri, 22 May 2015 10:29:53 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Martin Bjorklund In-Reply-To: References: <0DCFAE4A-7EA9-4425-9C57-28ECE4201B97@nic.cz> <20150521.223645.824542350167593812.mbj@tail-f.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 22 May 2015 10:29:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 08:29:50 -0000 Andy Bierman writes: > Martin, > > I will remove my objection to Y45-04 if you write a section > in the draft about why multiple imports of the same module > is needed, plus examples that show appropriate use > of this new feature. The use case is clear: With the IETF process in place, one cannot expect fine granularity of module revisions. That is, a new revision may typically include several changes, and authors of modules that import such a module may want to use just a subset of the changes and stick to the old revision for the rest. There is some evidence it was you who came up with this use case when you advocated that every change in a grouping/typedef be accompanied with a name change of the grouping/typedef, and both the old and new version be kept. Lada > > I also think examples are needed that highlight how data nodes and > augments ignore the revision date (multiple module augments > example), while still using groupings and typedefs that do not > ignore the revision dates. > > IETF modules should not need to cherry-pick from multiple > revisions. That means the WG is deciding to stay "down-rev" > on something, and that should not be approved without good reason. > > > Andy > > > On Thu, May 21, 2015 at 1:36 PM, Martin Bjorklund wrote: >> Andy, >> >> I don't think the implementation burden on the server is that heavy. >> A YANG 1.0 compliant server today supports: >> >> leaf a in module A of type foo from foo@2001-01-01 >> leaf b in module B of type foo from foo@2002-02-02 >> >> I.e., it supports different leafs in the combined data model referring >> to different versions of the same type. >> >> A YANG 1.1 server would also support >> >> leaf a in module A of type foo from foo@2001-01-01 >> leaf b in module A of type foo from foo@2002-02-02 >> >> Of course, how much a specific implementation is affected will vary, >> but I don't think the concepts are *that* different. >> >> >> /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri May 22 01:36:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45611ACF03 for ; Fri, 22 May 2015 01:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7_SwMT9E-yr for ; Fri, 22 May 2015 01:36:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 75F601ACE9A for ; Fri, 22 May 2015 01:36:33 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 8EDFA1AE0375; Fri, 22 May 2015 10:36:31 +0200 (CEST) Date: Fri, 22 May 2015 10:37:29 +0200 (CEST) Message-Id: <20150522.103729.1288400908403164613.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20150521.223645.824542350167593812.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 08:36:35 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Andy, > > > > I don't think the implementation burden on the server is that heavy. > > A YANG 1.0 compliant server today supports: > > > > leaf a in module A of type foo from foo@2001-01-01 > > leaf b in module B of type foo from foo@2002-02-02 > > In fact, the same can be done in two submodules of the same module, or > main module and submodule, which leads exactly to the situation below - > and that's allowed even in YANG 1.0. Yes, you're right! Which makes the current MUST NOT more of a CLR. /martin From nobody Fri May 22 07:11:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15C71B2BF3 for ; Fri, 22 May 2015 07:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-upClt1P7Vh for ; Fri, 22 May 2015 07:11:29 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (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 064501AD36F for ; Fri, 22 May 2015 07:11:29 -0700 (PDT) Received: by labbd9 with SMTP id bd9so13504158lab.2 for ; Fri, 22 May 2015 07:11:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yBCRmMHxez2FOaaPrqjARSqhSWX+OD303I81dIywtoA=; b=I8BLUBCqXZ+b/NK2BvEXUZy6DRntCmJ6UK5cM3eYTbomPs9YFwBNuR1hvqVizcF0j2 TRVWvQQ1jVNuTDzLlMIq4OrrBwOY6sqOvX9DGf6pe+CGsnf1n1t5dDmsVcCFu4z3JD6A 1hxz2zhnoFHHPYzVnkSxVad5B7ZXFit1SszvJaLkpnKuOmBH9iGxSVzfN1EbjufrG83M ddKAjnpHfZihRaNInaI4uZ68d2tZNjsjCNptdNWtJL3mUVm3UBBdq/ZVyYTCqxRXrdfQ YTA/pDn0Es23vUvrm6IHW90PTJnFfdyg0x1dz1dRBc6/3bp2ePUIpf9+19TORm392v/x pKgA== X-Gm-Message-State: ALoCoQmtiMkG3uYsDM7J/4+RLDjmPLqy+gMYXMdMt6u+NWtnBhXa4N7e66SSKCEWgQO/fm3Nz0Pb MIME-Version: 1.0 X-Received: by 10.112.130.129 with SMTP id oe1mr6428156lbb.37.1432303887405; Fri, 22 May 2015 07:11:27 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 22 May 2015 07:11:27 -0700 (PDT) In-Reply-To: <20150522.103729.1288400908403164613.mbj@tail-f.com> References: <20150521.223645.824542350167593812.mbj@tail-f.com> <20150522.103729.1288400908403164613.mbj@tail-f.com> Date: Fri, 22 May 2015 07:11:27 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:11:30 -0000 On Fri, May 22, 2015 at 1:37 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >> >> > Andy, >> > >> > I don't think the implementation burden on the server is that heavy. >> > A YANG 1.0 compliant server today supports: >> > >> > leaf a in module A of type foo from foo@2001-01-01 >> > leaf b in module B of type foo from foo@2002-02-02 >> >> In fact, the same can be done in two submodules of the same module, or >> main module and submodule, which leads exactly to the situation below - >> and that's allowed even in YANG 1.0. > > Yes, you're right! Which makes the current MUST NOT more of a CLR. > Completely wrong because each submodule is its own context and you cannot combine multiple revisions of any module in any 1 submodule. All XPath and other statements in the submodule will only be using 1 revision of any of the submodules or modules it can access. > > /martin Andy From nobody Fri May 22 07:21:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0D91A1A17 for ; Fri, 22 May 2015 07:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhimzxAz0w2j for ; Fri, 22 May 2015 07:21:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FC21A0364 for ; Fri, 22 May 2015 07:21:40 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id CDC5B141458; Fri, 22 May 2015 16:21:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1432304497; bh=aMZO4Urdy2cRm0KwXxswVqsCfoqoijqXfHh4KM55h7E=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fWCaFHvKxD59re5nzkjjnVVo3HoNbh5ogcqQp6/oEdq3Xq4elyA0b+0cjdX7XCKue KmQLZNfrAVuxoE7grQKrH8AgVtmbRop3yAQJBySuidaKYv3ujgHcVeVq7CzCbd3SDs MBJ8rHeMxZx0+M/Ep9xqfwbQ8182v8+MFRt0V+JY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 22 May 2015 16:21:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150521.223645.824542350167593812.mbj@tail-f.com> <20150522.103729.1288400908403164613.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :45: better conformance mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:21:43 -0000 > On 22 May 2015, at 16:11, Andy Bierman wrote: >=20 > On Fri, May 22, 2015 at 1:37 AM, Martin Bjorklund = wrote: >> Ladislav Lhotka wrote: >>> Martin Bjorklund writes: >>>=20 >>>> Andy, >>>>=20 >>>> I don't think the implementation burden on the server is that = heavy. >>>> A YANG 1.0 compliant server today supports: >>>>=20 >>>> leaf a in module A of type foo from foo@2001-01-01 >>>> leaf b in module B of type foo from foo@2002-02-02 >>>=20 >>> In fact, the same can be done in two submodules of the same module, = or >>> main module and submodule, which leads exactly to the situation = below - >>> and that's allowed even in YANG 1.0. >>=20 >> Yes, you're right! Which makes the current MUST NOT more of a CLR. >>=20 >=20 > Completely wrong because each submodule is its own context and you > cannot combine > multiple revisions of any module in any 1 submodule. All XPath and = other > statements in the submodule will only be using 1 revision of any of = the > submodules or modules it can access. This looks like your wishful thinking - the CLR in section 7.1.5 is = totally unqualified, and my interpretation is that it=E2=80=99s meant = for the text of a single module or submodule because an import in one = submodule doesn=E2=80=99t apply to other submodules nor the main module. = Moreover, I can easily combine *groupings and typedefs* from multiple = revisions. For everything else, including XPath, the revisions are = irrelevant. Lada >=20 >=20 >>=20 >> /martin >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri May 22 08:40:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277251A0276 for ; Fri, 22 May 2015 08:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-n_5VvF9Bsl for ; Fri, 22 May 2015 08:40:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CECAE1A0367 for ; Fri, 22 May 2015 08:40:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150522154049.25843.22418.idtracker@ietfa.amsl.com> Date: Fri, 22 May 2015 08:40:49 -0700 From: IETF Secretariat Archived-At: Subject: [netmod] Milestones changed for netmod WG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 15:40:51 -0000 Changed milestone "Submit first working group draft of the stateless packet filter data model", resolved as "Done", added draft-ietf-netmod-acl-model to milestone. URL: https://datatracker.ietf.org/wg/netmod/charter/ From nobody Fri May 22 14:40:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC1F1A88D5 for ; Fri, 22 May 2015 14:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTBY2Y6IAbs8 for ; Fri, 22 May 2015 14:40:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226901A88CB for ; Fri, 22 May 2015 14:40:17 -0700 (PDT) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB507.namprd05.prod.outlook.com (10.141.71.143) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 22 May 2015 21:39:57 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.166.22; Fri, 22 May 2015 21:39:56 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.01.0166.017; Fri, 22 May 2015 21:39:56 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: scheduling interim meetings Thread-Index: AQHQlNfX3TIAxP7ggUqTUfGv0PjAmQ== Date: Fri, 22 May 2015 21:39:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB507; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(105586002)(106356001)(99286002)(54356999)(50986999)(110136002)(62966003)(87936001)(19580395003)(229853001)(97736004)(2656002)(68736005)(106116001)(122556002)(107886002)(81156007)(2351001)(64706001)(92566002)(46102003)(66066001)(2900100001)(5001860100001)(5001920100001)(5001830100001)(101416001)(2501003)(4001350100001)(189998001)(77156002)(15975445007)(83506001)(19580405001)(102836002)(86362001)(40100003)(450100001)(5001960100002)(4001540100001)(36756003)(133083001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <36BA2BEDA3A9D94DB96948A3724BF35F@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2015 21:39:55.2322 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 X-OriginatorOrg: juniper.net Archived-At: Subject: [netmod] scheduling interim meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 21:40:20 -0000 Following up on=20 https://www.ietf.org/mail-archive/web/netmod/current/msg12549.html, and also to help other drafts progress, we'd like to schedule 3-4 one-hour virtual interim meetings before the meeting in Prague. The first meeting is already set in terms of time and agenda (see below), but the other slots remain open for signups. To accommodate IETF's 2-week announcement requirement, please send your request for time before next Thursday (5/28). Tentative schedule: Fri 6/12 11:30-12:30 EST: modeling operational state (draft-openconfig-netmod-opstate) Thu 6/18 10:00-11:00 EST: TBD Thu 6/25 10:00-11:00 EST: TBD Thu 7/02 10:00-11:00 EST: TBD Please send your request for time to netmod-chairs@tools.ietf.org. Thanks, NETMOD co-chairs From nobody Mon May 25 06:20:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046C11A8A52; Mon, 25 May 2015 06:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FR5fB8tQ-k3S; Mon, 25 May 2015 06:20:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FDB1A8A45; Mon, 25 May 2015 06:20:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150525132045.19664.94221.idtracker@ietfa.amsl.com> Date: Mon, 25 May 2015 06:20:45 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-19.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 13:20:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for Routing Management Authors : Ladislav Lhotka Acee Lindem Filename : draft-ietf-netmod-routing-cfg-19.txt Pages : 70 Date : 2015-05-25 Abstract: This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for routing protocols, route filters and other functions. The core routing data model provides common building blocks for such extensions - routing instances, routes, routing information bases (RIB), and routing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 26 14:14:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B251B3183; Tue, 26 May 2015 14:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsmzlnFkjpKK; Tue, 26 May 2015 14:14:02 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CFBF21B317A; Tue, 26 May 2015 14:14:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:13:59 -0400 Message-ID: <00a101d097f8$e2847700$a78d6500$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A2_01D097D7.5B78F180" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX+KHfDvCKoPtTS9efx7CdbCb8fA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org Subject: [netmod] I2RS interim 5/27 10:00am - 11:30am EDT (Webex) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:14:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A2_01D097D7.5B78F180 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A3_01D097D7.5B78F180" ------=_NextPart_001_00A3_01D097D7.5B78F180 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The I2RS interim is schedule for Wednesdsay 5/27 10:00am =E2=80=93 = 11:30am. The interim schedule opens 30 minutes early to allow speakers = to check their mike and make sure there slides are ready.=20 =20 There are two topics on the agenda:=20 =20 1) I2RS Protocol requirements with discussion on the following = drafts =20 a. = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ = (WG adoption 5/26 to 6/9/2015)=20 b. = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requiremen= ts (WG adoption 5/26 to 6/9/2015) c. = http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ( = WG LC 5/26 to 6/9/2015)=20 d. http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ = WG LC 5/26 to 6/9/2015)=20 =20 These set of requirements are intent as a group of requirements to pass = to the netmod/netconf WG on 6/10.=20 The 6/10 I2RS interim will review the discussions on the email list, and = finalize the set of documents passed to netconf/netmod for review.=20 =20 2) Announcement of I2RS Design team for FB-RIB documents=20 a. Review of draft = = draft-kini-i2rs-fb-fib-info-model-00=20 b. Review of Yang models proposed=20 i. = Generic FB-RIB-info-model=20 ii. = Rules specific to individual RIB-forwarding=20 =20 This meeting is to provide verbal discussions as a prelude to the I2RS = mail list discussions on the protocol, and to inform the WG regarding = the FB-RIB models in order to aid the WG on the protocol discussion.=20 =20 We apologize for the reminder of the meeting time, and the web-ex = meeting.=20 =20 Sue Hares and Jeff Haas=20 =20 From: I2RS Working Group [mailto:messenger@webex.com]=20 Sent: Tuesday, May 26, 2015 4:34 PM To: i2rs-chairs@tools.ietf.org Subject: WebEx meeting scheduled: I2RS interim 5/27 =20 Hi, I2RS Working Group,=20 You are the host for this WebEx meeting.=20 =20 Host key: 487042 (Use this to reclaim host privileges.)=20 =20 =20 =20 I2RS interim 5/27=20 Wednesday, May 27, 2015=20 9:30 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs=20 =20 =20 =20 = Join WebEx meeting=20 =20 Meeting number:=20 646 391 150=20 Meeting password: jeff.is.wise =20 =20 =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 391 150 Toll-free calling = restrictions =20 =20 =20 = Add this meeting to your calendar. =20 =20 =20 Can't join the meeting? Contact = support.=20 =20 =20 =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. You should inform all meeting attendees = prior to recording if you intend to record the meeting. =20 ------=_NextPart_001_00A3_01D097D7.5B78F180 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The I2RS interim is schedule for Wednesdsay 5/27 10:00am =E2=80=93 = 11:30am. The interim schedule opens 30 minutes early to allow speakers = to check their mike and make sure there slides are ready. =

 

There are two topics on the agenda:

 

1)      = I2RS Protocol requirements =C2=A0with discussion on the following = drafts =C2=A0

a.       = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/=C2=A0 (WG adoption 5/26 to 6/9/2015)

b.      = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netcon= f-requirements (WG adoption 5/26 to = 6/9/2015)

c.       = http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/ ( WG LC 5/26 to 6/9/2015)

d.      = ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/=C2=A0 WG = LC 5/26 to 6/9/2015)

 =

These set = of requirements are intent as a group of requirements to pass to the = netmod/netconf WG on 6/10.

The 6/10 = I2RS interim will review the discussions on the email list, and finalize = the set of documents passed to netconf/netmod for review. =

 =

2)      = Announcemen= t of I2RS Design team for FB-RIB documents

a.       = Review of = draft draft-kin= i-i2rs-fb-fib-info-model-00 

b.      = Review of Yang models proposed =

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   i.      = Generic FB-RIB-info-model =

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp; ii.      = Rules specific to individual RIB-forwarding = =

 =

This = meeting is to provide verbal discussions as a prelude to the I2RS mail = list discussions on the protocol, and to inform the WG regarding the = FB-RIB models in order to aid the WG on the protocol discussion. =

 =

We = apologize for the reminder of the meeting time, and the web-ex meeting. =

 

Sue Hares and Jeff Haas

 

From:= = I2RS Working Group [mailto:messenger@webex.com]
Sent: = Tuesday, May 26, 2015 4:34 PM
To: = i2rs-chairs@tools.ietf.org
Subject: WebEx meeting scheduled: = I2RS interim 5/27

 

Hi, I2RS Working Group,

You are the host for this WebEx meeting. =

 

Host key: 487042 (Use this to reclaim host privileges.) =

 

 

 

I2RS interim = 5/27 =

Wednesday, May 27, 2015

9:30 am  |  Eastern Daylight Time (New York, = GMT-04:00)  |  2 hrs =

 

 

 

Join = WebEx meeting =

 

Meeting number:

646 391 150

Meeting password:

jeff.is.wise

 

 

 

Join by = phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

Access code: 646 391 150

Toll-free = calling = restrictions

 

 

 

Add this = meeting to your = calendar.

 

 

 

Can't join the meeting? Contact support. =

 

 

 

= IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. You should inform all meeting attendees = prior to recording if you intend to record the = meeting.

 

------=_NextPart_001_00A3_01D097D7.5B78F180-- ------=_NextPart_000_00A2_01D097D7.5B78F180 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="WebEx_Meeting.ics" BEGIN:VCALENDAR=0A= PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN=0A= VERSION:2.0=0A= METHOD:REQUEST=0A= BEGIN:VTIMEZONE=0A= TZID:Eastern Time=0A= BEGIN:STANDARD=0A= DTSTART:20131101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0A= TZOFFSETTO:-0500=0A= TZNAME:Standard Time=0A= END:STANDARD=0A= BEGIN:DAYLIGHT=0A= DTSTART:20130301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0A= TZOFFSETTO:-0400=0A= TZNAME:Daylight Savings Time=0A= END:DAYLIGHT=0A= END:VTIMEZONE=0A= BEGIN:VEVENT=0A= ATTENDEE;CN=3D"I2RS Working = Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DFALSE:MAILTO:i2rs-chairs@tools.ietf.= org=0A= ORGANIZER;CN=3D"webex":MAILTO:messenger@webex.com=0A= DTSTART;TZID=3D"Eastern Time":20150527T093000=0A= DTEND;TZID=3D"Eastern Time":20150527T113000=0A= LOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0A= SEQUENCE:1432672422=0A= UID:ff572edf-29d8-499c-ae8b-114047c18e30=0A= DTSTAMP:20150527T133000Z=0A= DESCRIPTION:\nHost key: 487042\n\n\nJOIN WEBEX = MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm70918adad686cacc341500= c2d75e34c4\nMeeting number: 646 391 150\nMeeting password: = jeff.is.wise\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll free number = (US/Canada) \n1-650-479-3208 Call-in toll number (US/Canada)\nAccess = code: 646 391 150\n\nToll-free dialing restrictions: = \nhttp://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join = the meeting? Contact support = here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Please note = that this WebEx service allows audio and other information sent during = the session to be recorded, which may be discoverable in a legal matter. = You should inform all meeting attendees prior to recording if you intend = to record the meeting.\n=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:  
Host key: = 487042 
 
 
Join WebEx = meeting =
Meeting number: 646 391 = 150
Meeting = password:jeff.is.wise
 
 
Join by = phone 
1-877-668-4493 Call-in toll free = number (US/Canada) 
1-650-479-3208 Call-in toll number = (US/Canada) 
Access code: 646 391 150 
Toll-free calling = restrictions  


 
Can't join the = meeting? Contact support. =  
 
IMPORTANT NOTICE: Please note that this WebEx service = allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. You should inform = all meeting attendees prior to recording if you intend to record the = meeting.=0A= SUMMARY:I2RS interim 5/27=0A= PRIORITY:5=0A= CLASS:PUBLIC=0A= BEGIN:VALARM=0A= TRIGGER:-PT5M=0A= ACTION:DISPLAY=0A= DESCRIPTION:Reminder=0A= END:VALARM=0A= END:VEVENT=0A= END:VCALENDAR=0A= ------=_NextPart_000_00A2_01D097D7.5B78F180-- From nobody Tue May 26 14:28:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAE31B31F0; Tue, 26 May 2015 14:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ehjY_3dTaSy; Tue, 26 May 2015 14:28:20 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C3EF51B31F9; Tue, 26 May 2015 14:28:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:28:17 -0400 Message-ID: <00d801d097fa$e1c756a0$a55603e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01D097D9.5AB8C3E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX+oY2bTi4IH4qRaukXOC6nfsAwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: [netmod] This is 2 week adoption call for draft-haas-i2rs-ephemeral-state-req (5/26 to 6/9) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:28:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D9_01D097D9.5AB8C3E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. This document is a companion to three other documents for I2RS requirements which have WG calls: 1) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ [This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 2) draft-ietf-i2rs-pub-sub-requirements-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-haas-i2rs-ephemeral-state-req (5/26 to 6/9). Jeff is the author so he will be kicking of the adoption call and responding to the IPR question (do you know of any IPR on the requirements draft). Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but it is required. ------=_NextPart_000_00D9_01D097D9.5AB8C3E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: =

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the netmod and = netconf Working

   Groups = for functionality to support the ephemeral state = requirements

   to = implement the I2RS architecture.

 

 

This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

1)      draft-haas-i2rs-netmod-netconf= -requirements-01 

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netco= nf-requirements/

 

[This draft is an early set of requirements = from which the ephemeral state and “identity, secondary-identity = and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS Status: WG Adoption (5/26 to 6/9) =

 

2)      draft-ietf-= i2rs-pub-sub-requirements-02  =

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

I2RS Status: WG LC (5/26 to 6/9) =

 

 <= /p>

3)      draft-iet= f-i2rs-traceability-02 

ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

(5/26 to 6/9) =

 

This thread is to discuss the = draft-haas-i2rs-ephemeral-state-req (5/26 to 6/9).  Jeff is the = author so he will be kicking of the adoption call and responding to the = IPR question (do you know of any IPR on the requirements draft).  =

 

Sue Hares

 

PS – = Yes – I know an IPR call on a requirements draft may seem silly, = but it is required.

 

=

 

------=_NextPart_000_00D9_01D097D9.5AB8C3E0-- From nobody Tue May 26 14:36:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E15B1B3202; Tue, 26 May 2015 14:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ue39Sygk4BP; Tue, 26 May 2015 14:36:28 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CC8271B3201; Tue, 26 May 2015 14:36:27 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:36:26 -0400 Message-ID: <00f101d097fc$05a0a030$10e1e090$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01D097DA.7E914A20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX+y7VjhtpZaQbTuuEu5xIa4QtPA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org Subject: [netmod] draft-haas-i2rs-netmod-netconf-requirements-01 (2 week WG adoption - (5/26 to 6/9/2015) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:36:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F2_01D097DA.7E914A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week adoption call for draft-haas-i2rs-netmod-netconf-requirements-01 (5/26 to 6/9/2015). This document is a companion to three other documents for I2RS requirements which have WG calls: This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) The three other documents are: 1) Draft-haas-i2rs-ephemeral-state-reqs-00 https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. 2) draft-ietf-i2rs-pub-sub-requirements-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-haas-i2rs-netmod-netconf-requirements-01 ( (5/26 to 6/9). Jeff is the author so he will be kicking of the response to the adoption call and state if he knows of any IPR. Please note that the adoption of this draft is to show WG direction, and we expect a more detailed draft may be created for mutual authentication requirements (section 2.2) and transaction requirements. Jeff and I welcome more detailed proposals for mutual authentication requirements (section 2.2) and transaction requirements. If you are interested in working on a quick turn on a proposal, please contact me. I am working on this draft and would like co-authors. Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but it is required. ------=_NextPart_000_00F2_01D097DA.7E914A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week adoption call for = draft-haas-i2rs-netmod-netconf-requirements-01 (5/26 to 6/9/2015). This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

This draft = is an early set of requirements from which the ephemeral state and = “identity, secondary-identity and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS = Status: WG Adoption (5/26 to 6/9)

 

The three = other documents are:

 

1)      = Draft-haas-i2rs-ephemeral-state-reqs-00

 

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the netmod and = netconf Working

   Groups = for functionality to support the ephemeral state = requirements

   to = implement the I2RS architecture.

 

2)      draft-ietf-= i2rs-pub-sub-requirements-02  =

    http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

    I2RS Status: WG LC (5/26 = to 6/9)

 

 <= /p>

3)      = draft-iet= f-i2rs-traceability-02 

     ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

      (5/26 to 6/9) =

 

This thread is to discuss the = draft-haas-i2rs-netmod-netconf-requirements-01 ( (5/26 to 6/9). =  Jeff is the author so he will be kicking of the response to the = adoption call and state if he knows of any IPR.

 

Please note = that the adoption of this draft is to show WG direction, and we expect a = more detailed draft may be created for mutual authentication = requirements (section 2.2) and transaction requirements.  Jeff and = I welcome more detailed proposals for mutual authentication requirements = (section 2.2) and transaction requirements.  If you are interested = in working on a quick turn on a proposal, please contact me.  I am = working on this draft and would like co-authors.

 

Sue Hares =

 

PS – Yes – I know an IPR call on a = requirements draft may seem silly, but it is required.

 

------=_NextPart_000_00F2_01D097DA.7E914A20-- From nobody Tue May 26 14:54:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA11B3222; Tue, 26 May 2015 14:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S790X8F1Q_OI; Tue, 26 May 2015 14:54:45 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BBA2E1B3224; Tue, 26 May 2015 14:54:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:54:31 -0400 Message-ID: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0128_01D097DD.0576C220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX/brn0dvPMo3GSuqLIt07oHEavg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: cpignata@cisco.com, netmod@ietf.org, jclarke@cisco.com, "'Gonzalo Salgueiro \(gsalguei\)'" , 'Alia Atlas' , netconf@ietf.org Subject: [netmod] 2 week WG LC for draft-ietf-i2rs-traceabilty X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:54:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0128_01D097DD.0576C220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 from (5/26 to 6/9) (http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/) I2RS Status: WG LC (5/26 to 6/9) Carlos, joe, and Gonzalo - please indicate whether you know of any IPR on this draft. This document is a companion to three other documents for I2RS requirements which have WG calls: 1) This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status: WG adoption call (5/26 to 6/9) 2) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ [This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 3) draf-ietf-i2rs-pub-sub-requirements-02. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) This thread is to discuss WG consensus on draft-ietf-i2rs-traceability-02 . Please discuss the merits of the traceability framework described in this draft as being part of the requirements forwarded to netmod/netconf. Also discuss if this framework provides the necessary things for I2RS deployment. This draft will also be forwarded as part of the requirements to the IESG. Sue Hares ------=_NextPart_000_0128_01D097DD.0576C220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC for draft-iet= f-i2rs-traceability-02 from (5/26 to 6/9)  

(ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/) =

 

I2RS Status: WG LC (5/26 to 6/9) =

 

Carlos, joe, = and Gonzalo – please indicate whether you know of any IPR on this = draft.

 

 

This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

1)      = This begins a 2 week adoption call for = draft-haas-i2rs-ephemeral-state-req:

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the = netmod and netconf Working

   Groups for functionality to = support the ephemeral state requirements

   to implement the I2RS = architecture.

 

Status: WG adoption call (5/26 to 6/9) =

 

2)      draft-haas-i2rs-netmod-netconf= -requirements-01 

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netco= nf-requirements/

 

[This draft is an early set of requirements = from which the ephemeral state and “identity, secondary-identity = and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS Status: WG Adoption (5/26 to 6/9) =

 

3)      = draf-ietf-i2rs-pub-sub-requirements-02. =

 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

I2RS Status: WG LC (5/26 to 6/9) =

 

 

This thread = is to discuss WG consensus on  draft-iet= f-i2rs-traceability-02 .  Please discuss the merits of = the traceability framework described in this draft as being part of the = requirements forwarded to netmod/netconf.   Also discuss if = this framework provides the necessary things for I2RS deployment. =

 

This draft will also be forwarded as part of the = requirements to the IESG.

 

Sue Hares =

 

 

 

------=_NextPart_000_0128_01D097DD.0576C220-- From nobody Tue May 26 17:20:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53AD1ACE38; Tue, 26 May 2015 17:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMpHJ68Vxj5l; Tue, 26 May 2015 17:20:36 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 824A81ACE39; Tue, 26 May 2015 17:20:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 20:20:34 -0400 Message-ID: <017a01d09812$f31d4780$d957d680$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017B_01D097F1.6C0EB4C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX/SqdWbWgG8/OQamGAg9/X0In5w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: [netmod] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (5/26 to 6/9) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 00:20:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_017B_01D097F1.6C0EB4C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC on draft-ietf-i2rs-pub-sub-requirements-02. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) Eric, Alexander, Gonzalez - please state whether you know of any IPR related to the draft. This document is a companion to three other documents for I2RS requirements which have WG calls: 1) This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status: WG adoption call (5/26 to 6/9) 2) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ [This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-i2rs-pub-sub-requirements-02 and forwarding to the netmod/netconf and IESG as requirement for I2RS. Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but it is required. ------=_NextPart_000_017B_01D097F1.6C0EB4C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC on draft-ietf-i2rs-pub-sub-requirements-02. =

 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

I2RS Status: WG LC (5/26 to 6/9) =

 

Eric, = Alexander, Gonzalez – please state whether you know of any IPR = related to the draft.  

 

This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

1)      = This begins a 2 week adoption call for = draft-haas-i2rs-ephemeral-state-req:

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the = netmod and netconf Working

   Groups for functionality to = support the ephemeral state requirements

   to implement the I2RS = architecture.

 

Status: WG adoption call (5/26 to 6/9) =

 

2)      draft-haas-i2rs-netmod-netconf= -requirements-01 

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netco= nf-requirements/

 

[This draft is an early set of requirements = from which the ephemeral state and “identity, secondary-identity = and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS Status: WG Adoption (5/26 to 6/9) =

 

3)      = draft-iet= f-i2rs-traceability-02 

ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

(5/26 to 6/9) =

 

This thread is to discuss the = draft-i2rs-pub-sub-requirements-02 and forwarding to the netmod/netconf = and IESG as requirement for I2RS.  

 

Sue Hares =

 

PS – Yes – I know an IPR call on a = requirements draft may seem silly, but it is required.

 

 

 

 

------=_NextPart_000_017B_01D097F1.6C0EB4C0-- From nobody Tue May 26 22:42:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB591A00B2; Tue, 26 May 2015 22:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIZaNOOR15EN; Tue, 26 May 2015 22:41:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FD01A009B; Tue, 26 May 2015 22:41:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3CEC910C8; Wed, 27 May 2015 07:41:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QZvfogcwvDOp; Wed, 27 May 2015 07:41:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 May 2015 07:41:53 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92D0C2002B; Wed, 27 May 2015 07:41:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id U4tkOcVBdnzZ; Wed, 27 May 2015 07:41:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96FC320013; Wed, 27 May 2015 07:41:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 368163384F67; Wed, 27 May 2015 07:41:48 +0200 (CEST) Date: Wed, 27 May 2015 07:41:48 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150527054148.GA6258@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org References: <00a101d097f8$e2847700$a78d6500$@ndzh.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: <00a101d097f8$e2847700$a78d6500$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: i2rs@ietf.org, 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] I2RS interim 5/27 10:00am - 11:30am EDT (Webex) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 05:41:58 -0000 On Tue, May 26, 2015 at 05:13:59PM -0400, Susan Hares wrote: > The I2RS interim is schedule for Wednesdsay 5/27 10:00am – 11:30am. The interim schedule opens 30 minutes early to allow speakers to check their mike and make sure there slides are ready. > > > > There are two topics on the agenda: > > > > 1) I2RS Protocol requirements with discussion on the following drafts > > a. https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ (WG adoption 5/26 to 6/9/2015) > > b. http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements (WG adoption 5/26 to 6/9/2015) > I can't make it to this meeting. My suggestion is to merge the above two I-Ds into one I-D. There is already overlap. It also seems that a. goes quite a bit into solution space, so calling it a requirements document may be a bit of a stretch. (But that said, we need to start talking about solutions since we already have a document full of requirements.) /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 May 26 22:53:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB471B3229; Tue, 26 May 2015 15:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IW3oqEChGku; Tue, 26 May 2015 15:05:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C02B1B320B; Tue, 26 May 2015 15:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13437; q=dns/txt; s=iport; t=1432677915; x=1433887515; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uGILI0wyIZ2UuPF06D5dvIJ03Fl1FmA1CcxYi3Je92U=; b=Y2LoXbSChyARssvmjbf3wafv0OIqR2HrK9Yoa7grX1cmK9fdIbeRhSwn m8quW8dG20BqZq0ytCALyt6CRPZaEuMlK54ZOeISkrKpdJuWEYzHV6r+W EUq+RC3OfX2UPwTGxVOkhkh3337DNViybGE/vXDFvGK7uO7OZMlvLE4ti k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFBgDM7GRV/4UNJK1TCYJFS1RetHyNUTyCDoV1AoFLTAEBAQEBAYELhCMBAQQdEEwQAgEIDgQTGgcyFAMOAQEEDgWILA3MaAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOoQpWAQHgxeBFgWTCIQ1hlqBKT6DM5IVI4N4b4JHAQEB X-IronPort-AV: E=Sophos;i="5.13,501,1427760000"; d="scan'208,217";a="419690459" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-9.cisco.com with ESMTP; 26 May 2015 22:05:14 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4QM5DoM015685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 May 2015 22:05:13 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.169]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 26 May 2015 17:05:12 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Susan Hares Thread-Topic: 2 week WG LC for draft-ietf-i2rs-traceabilty Thread-Index: AdCX/brn0dvPMo3GSuqLIt07oHEavgAAk6Os Date: Tue, 26 May 2015 22:05:12 +0000 Message-ID: <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> References: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> In-Reply-To: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9CD84E4E0899402CA1024B6DAFE3CBAFciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 26 May 2015 22:53:43 -0700 Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "Carlos Pignataro \(cpignata\)" , "Joe Clarke \(jclarke\)" , Alia Atlas , "netconf@ietf.org" Subject: Re: [netmod] 2 week WG LC for draft-ietf-i2rs-traceabilty X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 22:05:17 -0000 --_000_9CD84E4E0899402CA1024B6DAFE3CBAFciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have no IPR to declare related to this draft, nor do I know of any. Regards, Gonzalo On May 26, 2015, at 5:54 PM, Susan Hares > wrote: This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 from (5/26 to 6/9) (http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/) I2RS Status: WG LC (5/26 to 6/9) Carlos, joe, and Gonzalo =96 please indicate whether you know of any IPR on= this draft. This document is a companion to three other documents for I2RS requirements= which have WG calls: 1) This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-st= ate-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status: WG adoption call (5/26 to 6/9) 2) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements= / [This draft is an early set of requirements from which the ephemeral state = and =93identity, secondary-identity and priority=94 were pulled into draft-= haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled= into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been = separated before draft-haas-i2rs-nemod-netconf-requirements was published. = This draft remains the only source for mutual authentication requirements (= section 2.2), transaction requirements, and the history of the discussion. = This draft is being requested to be adopted as a general roadmap for the = I2RS WG. In the future, the I2RS WG will accept more detailed specification= on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 3) draf-ietf-i2rs-pub-sub-requirements-02. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) This thread is to discuss WG consensus on draft-ietf-i2rs-traceability-02<= http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/> . Please di= scuss the merits of the traceability framework described in this draft as b= eing part of the requirements forwarded to netmod/netconf. Also discuss i= f this framework provides the necessary things for I2RS deployment. This draft will also be forwarded as part of the requirements to the IESG. Sue Hares --_000_9CD84E4E0899402CA1024B6DAFE3CBAFciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I have no IPR to declare related to this draft, nor do I know of any.<= br>
Regards,

Gonzalo



On May 26, 2015, at 5:54 PM, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week WG LC for draft= -ietf-i2rs-traceability-02 from (5/26 to 6/9)  

(http://datatracker.ietf.org/doc/draft-ietf-i2rs-trac= eability/)

 

I2RS Status: WG LC (5/26 to 6/9)

 

Carlos, joe, and Gonzalo =96 please indicate whether= you know of any IPR on this draft.

 

 

This document is a companion to three other document= s for I2RS requirements which have WG calls:

 

1)    &nbs= p; This begins a 2 week adoption call for draft-ha= as-i2rs-ephemeral-state-req:

https://datatracker.ietf.org/doc/draf= t-haas-i2rs-ephemeral-state-reqs/

 

  This document covers requests to the n= etmod and netconf Working

   Groups for functionality to supp= ort the ephemeral state requirements

   to implement the I2RS architectu= re.

 

Status: WG adoption call (5/26 to 6/9) <= /o:p>

 

2)      draft-haas-i2rs-netmod-netconf-requirements-01 

http://datatracker.ietf.org/doc= /draft-haas-i2rs-netmod-netconf-requirements/

 

[This draft is an early set of requirements f= rom which the ephemeral state and =93identity, secondary-identity and prior= ity=94 were pulled into draft-haas-i2rs-ephemeral-state-reqs.  The &nb= sp;notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments.   The traceability had been= separated before draft-haas-i2rs-nemod-netconf-requirements was published.= This draft remains the only source for mutual authentication requirements = (section 2.2), transaction requirements, and the history of the discussion.   This draft is being requested t= o be adopted as a general roadmap for the I2RS WG. In the future, the I2RS = WG will accept more detailed specification on the mutual authentication or = the transaction protocol.

 

I2RS Status: WG Adoption (5/26 to 6/9) <= /o:p>

 

3)    &nbs= p; draf-ietf-i2rs-pub-sub-requirements-02.

 

http://datatracker.ietf.org/= doc/draft-ietf-i2rs-pub-sub-requirements/

 

I2RS Status: WG LC (5/26 to 6/9)

 

 

This thread is to discuss WG consensus on  draft-ietf= -i2rs-traceability-02 .  Please discuss the merits of the traceability framework described in this draft a= s being part of the requirements forwarded to netmod/netconf.   A= lso discuss if this framework provides the necessary things for I2RS deploy= ment.

 

This draft will also be forwarded as part of the req= uirements to the IESG.

 

Sue Hares

 

 

 

--_000_9CD84E4E0899402CA1024B6DAFE3CBAFciscocom_-- From nobody Tue May 26 22:53:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE32A1B3230; Tue, 26 May 2015 15:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzFgHX_vgVtM; Tue, 26 May 2015 15:07:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12DA1B322C; Tue, 26 May 2015 15:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2919; q=dns/txt; s=iport; t=1432678066; x=1433887666; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NYVVt1CS83B6ht/AG80FwiJz6aRcLyjhwLXB862daBg=; b=A3l1dcM88iFSJq+m5KmG4CR4F6AQ2p3UBVGwQnRLllVlZiy+nzhpZ33k ke5wR5oYPlE08fLpJwOdDVF8EsmnGT8SqKlX1Z5XHJ502UWqLilvI/Sps b+dQfWrbNgWdw6oaESli3jgQDok0nmDmNZddEPjd59gyQretCCt94yKUv k=; X-IronPort-AV: E=Sophos;i="5.13,501,1427760000"; d="scan'208";a="422765105" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 26 May 2015 22:07:45 +0000 Received: from [10.117.46.173] (rtp-jclarke-89112.cisco.com [10.117.46.173]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4QM7hla013958; Tue, 26 May 2015 22:07:43 GMT Message-ID: <5564EEAF.3040901@cisco.com> Date: Tue, 26 May 2015 18:07:43 -0400 From: Joe Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" , Susan Hares References: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> In-Reply-To: <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 26 May 2015 22:53:43 -0700 Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "Carlos Pignataro \(cpignata\)" , Alia Atlas , "netconf@ietf.org" Subject: Re: [netmod] 2 week WG LC for draft-ietf-i2rs-traceabilty X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 22:07:46 -0000 On 5/26/15 6:05 PM, Gonzalo Salgueiro (gsalguei) wrote: > I have no IPR to declare related to this draft, nor do I know of any. No, no IPR. Joe > > Regards, > > Gonzalo > > > > On May 26, 2015, at 5:54 PM, Susan Hares > wrote: > >> This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 >> from >> (5/26 to 6/9) >> >> (http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/) >> >> I2RS Status: WG LC (5/26 to 6/9) >> >> Carlos, joe, and Gonzalo please indicate whether you know of any IPR >> on this draft. >> >> This document is a companion to three other documents for I2RS >> requirements which have WG calls: >> >> 1)This begins a 2 week adoption call for >> draft-haas-i2rs-ephemeral-state-req: >> >> https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ >> >> This document covers requests to the netmod and netconf Working >> >> Groups for functionality to support the ephemeral state requirements >> >> to implement the I2RS architecture. >> >> Status: WG adoption call (5/26 to 6/9) >> >> 2)draft-haas-i2rs-netmod-netconf-requirements-01 >> >> >> http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ >> >> [This draft is an early set of requirements from which the ephemeral >> state and identity, secondary-identity and priority were pulled into >> draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription >> were pulled into the draft-ietf-i2rs-pub-sub-requirments. The >> traceability had been separated before >> draft-haas-i2rs-nemod-netconf-requirements was published. This draft >> remains the only source for mutual authentication requirements >> (section 2.2), transaction requirements, and the history of the >> discussion. This draft is being requested to be adopted as a general >> roadmap for the I2RS WG. In the future, the I2RS WG will accept more >> detailed specification on the mutual authentication or the transaction >> protocol. >> >> I2RS Status: WG Adoption (5/26 to 6/9) >> >> 3)draf-ietf-i2rs-pub-sub-requirements-02. >> >> http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ >> >> I2RS Status: WG LC (5/26 to 6/9) >> >> This thread is to discuss WG consensus on >> draft-ietf-i2rs-traceability-02 >> . >> Please discuss the merits of the traceability framework described in >> this draft as being part of the requirements forwarded to >> netmod/netconf. Also discuss if this framework provides the >> necessary things for I2RS deployment. >> >> This draft will also be forwarded as part of the requirements to the >> IESG. >> >> Sue Hares >> From nobody Wed May 27 06:55:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE4A1ACF55; Wed, 27 May 2015 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEDaoyKcrO7n; Wed, 27 May 2015 06:55:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 54FA31A1A86; Wed, 27 May 2015 06:55:14 -0700 (PDT) Received: from [192.168.1.70] (99-59-193-146.lightspeed.livnmi.sbcglobal.net [99.59.193.146]) by slice.pfrc.org (Postfix) with ESMTPSA id 13B101E30A; Wed, 27 May 2015 09:55:52 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jeffrey Haas In-Reply-To: <20150527054148.GA6258@elstar.local> Date: Wed, 27 May 2015 09:55:12 -0400 Message-Id: <75138D77-1D2C-4E2C-9976-4CC119E079C7@pfrc.org> References: <00a101d097f8$e2847700$a78d6500$@ndzh.com> <20150527054148.GA6258@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netmod@ietf.org, i2rs@ietf.org, Alia Atlas , netconf@ietf.org, Sue Hares Subject: Re: [netmod] [i2rs] I2RS interim 5/27 10:00am - 11:30am EDT (Webex) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 13:55:17 -0000 --Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 27, 2015, at 1:41 AM, Juergen Schoenwaelder = wrote: >=20 > On Tue, May 26, 2015 at 05:13:59PM -0400, Susan Hares wrote: >> The I2RS interim is schedule for Wednesdsay 5/27 10:00am =E2=80=93 = 11:30am. The interim schedule opens 30 minutes early to allow speakers = to check their mike and make sure there slides are ready.=20 >>=20 >>=20 >>=20 >> There are two topics on the agenda:=20 >>=20 >>=20 >>=20 >> 1) I2RS Protocol requirements with discussion on the following = drafts =20 >>=20 >> a. = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ = (WG adoption 5/26 to 6/9/2015)=20 >>=20 >> b. = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirement= s (WG adoption 5/26 to 6/9/2015) >>=20 >=20 > I can't make it to this meeting. My suggestion is to merge the above > two I-Ds into one I-D. There is already overlap. I believe I=E2=80=99d prefer to not adopt the netmod-netconf draft. Its = goal, as explained during the last netconf WG session that I presented = it in, is to simply use it as the placeholder =E2=80=9CTODO=E2=80=9D = list for the actual drafts covering the work. However, there was strong = pressure to have adopted WG items to cover the contents. The state = draft is another piece of that. I believe this leaves authentication requirements as the only meaningful = content. A last draft covering that may perhaps be spun out or not as = the WG desires. After that, the netmod-netconf requirements draft can = die. > It also seems that > a. goes quite a bit into solution space, so calling it a requirements > document may be a bit of a stretch. (But that said, we need to start > talking about solutions since we already have a document full of > requirements.) The actual requirements have been stalled since before the NYC interim: = We need ephemeral state. The implications of any given solution space = are too important to draft requirements in the absence of some = understanding of the likely solution. I=E2=80=99m happy to rename the draft something that doesn=E2=80=99t = contain the word =E2=80=9Crequirements=E2=80=9D if you have a better = suggestion. =E2=80=94 Jeff --Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 27, 2015, at 1:41 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Tue, May 26, 2015 at 05:13:59PM -0400, Susan = Hares wrote:
The I2RS interim is schedule for Wednesdsay 5/27 = 10:00am =E2=80=93 11:30am. The interim schedule opens 30 minutes early = to allow speakers to check their mike and make sure there slides are = ready. 



There are two = topics on the agenda: 



1) =      I2RS Protocol requirements  with = discussion on the following drafts  

a. =       https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-stat= e-reqs/  (WG adoption 5/26 to 6/9/2015) 

b.      http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-= requirements (WG adoption 5/26 to 6/9/2015)


I can't make it to this = meeting. My suggestion is to merge the above
two I-Ds into one I-D. There is already = overlap.

I believe = I=E2=80=99d prefer to not adopt the netmod-netconf draft.  Its = goal, as explained during the last netconf WG session that I presented = it in, is to simply use it as the placeholder =E2=80=9CTODO=E2=80=9D = list for the actual drafts covering the work.  However, there was = strong pressure to have adopted WG items to cover the contents. =  The state draft is another piece of that.

I believe this leaves authentication requirements = as the only meaningful content.  A last draft covering that may = perhaps be spun out or not as the WG desires.  After that, the = netmod-netconf requirements draft can die.

It also seems that
a. goes quite a bit into solution space, so = calling it a requirements
document may be a bit of a = stretch. (But that said, we need to start
talking about solutions since we already have a = document full of
requirements.)

The actual = requirements have been stalled since before the NYC interim: We need = ephemeral state.  The implications of any given solution space are = too important to draft requirements in the absence of some understanding = of the likely solution.

I=E2=80=99m = happy to rename the draft something that doesn=E2=80=99t contain the = word =E2=80=9Crequirements=E2=80=9D if you have a better = suggestion.

=E2=80=94 = Jeff

= --Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8-- From nobody Wed May 27 07:09:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7B81B2ACE; Wed, 27 May 2015 07:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxNcYP8aLZ5h; Wed, 27 May 2015 07:09:45 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FE01B2ABE; Wed, 27 May 2015 07:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14845; q=dns/txt; s=iport; t=1432735787; x=1433945387; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pzx2FcQxFTH7FyWj9H8vi4XEV2jn9Zk0G98cU/BJqmk=; b=eebS61YYZdQv4f8TBrousSAfMx/Lz4Ok3CWigOT0GyONQ4KMX3Gva54C ppG953rIu2ps3A5WiK7ujDTPycZEfbysOLTb/7a4Zw4BqJQhsDaFs88UW jVIe/ZSBO6BXLm/4dJGO9DjiPllO1T577jtUtpsE85YksZt/7aUklcMoG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1BADcz2VV/5FdJa1TCYJFS1ReBrMljg0qCYFbhXUCgTw4FAEBAQEBAQGBCoQiAQEBBB0QTBACAQgOAwEDAQELAxoHMhQDBggBAQQBDQUIiCUN0GYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqEKSstBAYBgxeBFgWTCIQ1hluBKD6DM5IVI4I7gT1vgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,506,1427760000"; d="scan'208,217";a="153774712" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 27 May 2015 14:09:46 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4RE9iwu000358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 14:09:44 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 27 May 2015 09:09:44 -0500 From: "Eric Voit (evoit)" To: Susan Hares , "i2rs@ietf.org" Thread-Topic: [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (5/26 to 6/9) Thread-Index: AdCX/SqdWbWgG8/OQamGAg9/X0In5wAiVB1Q Date: Wed, 27 May 2015 14:09:43 +0000 Message-ID: References: <017a01d09812$f31d4780$d957d680$@ndzh.com> In-Reply-To: <017a01d09812$f31d4780$d957d680$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.118.56.229] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (5/26 to 6/9) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 14:09:53 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We know of no IPR related to draft-ietf-i2rs-pub-sub-requirements. Eric From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, May 26, 2015 8:21 PM To: i2rs@ietf.org Cc: netconf@ietf.org; netmod@ietf.org Subject: [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (= 5/26 to 6/9) This begins a 2 week WG LC on draft-ietf-i2rs-pub-sub-requirements-02. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) Eric, Alexander, Gonzalez - please state whether you know of any IPR relate= d to the draft. This document is a companion to three other documents for I2RS requirements= which have WG calls: 1) This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-st= ate-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status: WG adoption call (5/26 to 6/9) 2) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements= / [This draft is an early set of requirements from which the ephemeral state = and "identity, secondary-identity and priority" were pulled into draft-haas= -i2rs-ephemeral-state-reqs. The notification-subscription were pulled int= o the draft-ietf-i2rs-pub-sub-requirments. The traceability had been sepa= rated before draft-haas-i2rs-nemod-netconf-requirements was published. This= draft remains the only source for mutual authentication requirements (sect= ion 2.2), transaction requirements, and the history of the discussion. Th= is draft is being requested to be adopted as a general roadmap for the I2RS= WG. In the future, the I2RS WG will accept more detailed specification on = the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-i2rs-pub-sub-requirements-02 and forwar= ding to the netmod/netconf and IESG as requirement for I2RS. Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but i= t is required. --_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We know of no IPR rela= ted to draft-ietf-i2rs-pub-sub-requirements.

 

Eric=

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, May 26, 2015 8:21 PM
To: i2rs@ietf.org
Cc: netconf@ietf.org; netmod@ietf.org
Subject: [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requremen= ts-02 (5/26 to 6/9)

 

This begins a 2 week WG L= C on draft-ietf-i2rs-pub-sub-requirements-02.

 

http://d= atatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/

 

I2RS Status: WG LC (5/26 to 6= /9)

 

Eric, Alexander, Gonzalez= – please state whether you know of any IPR related to the draft. &nb= sp;

 

This document is a compan= ion to three other documents for I2RS requirements which have WG calls:

 

1)      This begins a 2 week adoption call for draft-haas-i= 2rs-ephemeral-state-req:

https://d= atatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/

 =

  This docum= ent covers requests to the netmod and netconf Working

   Grou= ps for functionality to support the ephemeral state requirements=

   to i= mplement the I2RS architecture.

 =

Status: WG adopti= on call (5/26 to 6/9)

 =

2)&n= bsp;     draft-haas-i2rs-netmod-netconf-requirements-01 

htt= p://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/

 =

[This draft is an= early set of requirements from which the ephemeral state and “identi= ty, secondary-identity and priority” were pulled into draft-haas-i2rs= -ephemeral-state-reqs.  The  notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments.   The = traceability had been separated before draft-haas-i2rs-nemod-netconf-requir= ements was published. This draft remains the only source for mutual authent= ication requirements (section 2.2), transaction requirements, and the history of the discussion.   This draft is= being requested to be adopted as a general roadmap for the I2RS WG. In the= future, the I2RS WG will accept more detailed specification on the mutual = authentication or the transaction protocol.

 =

I2RS Status: WG A= doption (5/26 to 6/9)

 

&n= bsp;

3)      draft-ietf-i2rs-traceability-02&nb= sp;

http://d= atatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

(5/26 to= 6/9)

 

This thread is to discuss= the draft-i2rs-pub-sub-requirements-02 and forwarding to the netmod/netcon= f and IESG as requirement for I2RS.  

 

Sue Hares

 

PS – Yes – I = know an IPR call on a requirements draft may seem silly, but it is required= .

 

 

 

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_-- From nobody Wed May 27 08:39:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D520F1A8A79 for ; Wed, 27 May 2015 08:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.205 X-Spam-Level: X-Spam-Status: No, score=-96.205 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_46=0.256, HTML_FONT_FACE_BAD=0.981, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG_uXPR_vXAz for ; Wed, 27 May 2015 08:38:58 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E1A401A892E for ; Wed, 27 May 2015 08:38:56 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 6F4F948F0A03E for ; Wed, 27 May 2015 23:38:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t4RFchrw086241 for ; Wed, 27 May 2015 23:38:43 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) To: netmod@ietf.org MIME-Version: 1.0 X-KeepSent: EE7A0E98:89296BCD-48257E52:0055094B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Wed, 27 May 2015 23:38:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-05-27 23:38:24, Serialize complete at 2015-05-27 23:38:24 Content-Type: multipart/related; boundary="=_related 0055F1E548257E52_=" X-MAIL: mse01.zte.com.cn t4RFchrw086241 Archived-At: Cc: xiao.yuqing@zte.com.cn Subject: [netmod] A question about updating model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 15:39:06 -0000 This is a multipart message in MIME format. --=_related 0055F1E548257E52_= Content-Type: multipart/alternative; boundary="=_alternative 0055F1E648257E52_=" --=_alternative 0055F1E648257E52_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KICAgSWYgSSB3YW50IHRvIGFkZCBhIG5ldyBjaGlsZCBkYXRhIG5vZGUgdG8gYSBj b250YWluZXIgbm9kZSBvciBsaXN0IA0Kbm9kZSwgaW4gb3JkZXIgdG8ga2VlcCBiYWNrd2FyZCBj b21wYXRpYWJsZSwNCnNob3VsZCB0aGlzIGNoaWxkIG5vZGUgYmUgYWRkZWQgdG8gdGhlIGVuZCBv ZiBzb24gbm9kZXMgb2YgcGFyZW50IG5vZGU/DQogICBGb3IgZXhhbXBsZSwgDQogICBjb250YWlu ZXIgYSB7DQogICAgICAgbGVhZiBiOw0KICAgICAgIGxlYWYgYzsNCiAgICAgICBsZWFmIGQ7DQog ICB9DQogICBJZiBJIHdhbnQgdG8gYWRkIGxlYWYgZSBhcyBhJ3MgY2hpbGQgbm9kZSwgbGVhZiBl IG11c3QgYmUgdGhlIGxhc3QgDQpjaGlsZCBvZiBjb250YWluZXIgYT8NCk90aGVyd2lzZSwgaXQg aXMgbm90IGEgYmFja3dhcmQgY29tcGF0aWFibGUgdXBkYXRlPw0KIA0KDQoNCg0KDQpGcmFuayBG ZW5nICAgt+uz5Q0KQk4gUHJvZHVjdCBUZWFtDQpCTrL6xrfNxbbTDQoNCkFkZDogWlRFIENvcnBv cmF0aW9uLCA1MCBTb2Z0d2FyZSBBdmVudWUsIFl1SHVhVGFpIERpc3RyaWN0LCBOYW5qaW5nLCBQ LlIuIA0KQ2hpbmEsMjEwMDEyDQrEz76pytDT6ruozKjH+MjtvP6087XANTC6xdbQ0MvNqNG2DQpN cDorODYtMTg5MTM4NTI2MTINCkUtbWFpbDogZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24NCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkg aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4 Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVu ZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9u IG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFp bCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 0055F1E648257E52_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtJZiBJIHdhbnQgdG8gYWRkIGEg bmV3DQpjaGlsZCBkYXRhIG5vZGUgdG8gYSBjb250YWluZXIgbm9kZSBvciBsaXN0IG5vZGUsIGlu IG9yZGVyIHRvIGtlZXAgYmFja3dhcmQNCmNvbXBhdGlhYmxlLDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+c2hvdWxkIHRoaXMgY2hpbGQgbm9kZSBiZSBhZGRlZCB0 byB0aGUNCmVuZCBvZiBzb24gbm9kZXMgb2YgcGFyZW50IG5vZGU/PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7Rm9yIGV4YW1wbGUsIDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2NvbnRh aW5lciBhIHs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xlYWYgYjs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xlYWYgYzs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2xlYWYgZDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDt9PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7SWYgSSB3YW50IHRvIGFkZCBsZWFmIGUNCmFzIGEncyBjaGlsZCBub2Rl LCBsZWFmIGUgbXVzdCBiZSB0aGUgbGFzdCBjaGlsZCBvZiBjb250YWluZXIgYT88L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk90aGVyd2lzZSwgaXQgaXMgbm90IGEg YmFja3dhcmQgY29tcGF0aWFibGUNCnVwZGF0ZT88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDs8YnI+DQo8L2ZvbnQ+DQo8dGFibGU+DQo8dHI+ DQo8dGQ+PGltZyBzcmM9Y2lkOl8yXzA5OTcyNjhDMDk5NzIyOEMwMDU1RjFFMDQ4MjU3RTUyPg0K PHRkPjxmb250IHNpemU9MT48YnI+DQo8L2ZvbnQ+DQo8dGFibGU+DQo8dHI+DQo8dGQ+PGZvbnQg c2l6ZT00IGZhY2U9Is6iyO3RxbraIj48Yj5GcmFuayBGZW5nICZuYnNwOyC367PlPC9iPjwvZm9u dD4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPTIgY29sb3I9IzVmNWY1ZiBmYWNlPSJBcmlhbCI+PGI+ Qk4gUHJvZHVjdCBUZWFtPC9iPjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzVmNWY1ZiBmYWNl PSLOosjt0cW62iI+PGI+PGJyPg0KQk6y+sa3zcW20zwvYj48L2ZvbnQ+DQo8dHI+DQo8dGQ+PGlt ZyBzcmM9Y2lkOl8yXzA5OTczREZDMDk5NzNBMjgwMDU1RjFFMDQ4MjU3RTUyPg0KPHRyPg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+QWRkOiBaVEUgQ29ycG9yYXRpb24sIDUwIFNvZnR3 YXJlIEF2ZW51ZSwNCll1SHVhVGFpIERpc3RyaWN0LCBOYW5qaW5nLCBQLlIuIENoaW5hLDIxMDAx Mjxicj4NCsTPvqnK0NPqu6jMqMf4yO28/rTztcA1MLrF1tDQy82o0bY8YnI+DQpNcDorODYtMTg5 MTM4NTI2MTI8YnI+DQpFLW1haWw6IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPC9mb250PjwvdGFi bGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgp IGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBl eGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRl bmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlv biBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1h aWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4N Cg0KPC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 0055F1E648257E52_=-- --=_related 0055F1E548257E52_= Content-Type: image/jpeg Content-ID: <_2_0997268C0997228C0055F1E048257E52> Content-Transfer-Encoding: base64 /9j/4R9rRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBXaW5kb3dzADIwMTQ6MDg6MTIgMTY6Mzc6 MDAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAoKADAAQAAAABAAAAxgAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAAB41AAAAAAAAAEgAAAABAAAASAAAAAH/2P/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSA AAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAoACBAwEiAAIRAQMRAf/dAAQACf/EAT8AAAEF AQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAAB BAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHx Y3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm 9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS 0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9VSSSSUpJJDvvqoZvsMA kNaAJJcfosY0e5zklEgCzokQbMljZDGuuePzKxJn93c7bWz+29QbXff7sj9Gz82hp1j/AIaxv0v+ Lr/R/wDGoll2PjtAcQwD6LR/BrU4DWvmPgtMtL+Udy4lnXuou6uzpLqqen2WMFjLLybg+fo1sZUc dnqaP/w62KactoHrZAsPfZWGD7nOtd/01k9YZ0/qtIqvqMs1qvBAew+LIn/MVWjrXVOnsFOaRk0N 0ZmNBLgP+7DJ3f2//PqnOIyiOGIif0on/pRl/wBy0/vAxzl7sjOBNxyDaP8AVyQjw/8Ahj0oa8fn z8QFJ0x7RJ8DosZnXHlocPTsYeHCdfxVirrmM4xaDX5j3D8Pd/0VGcGQfo35M8eZxH9Kr7/xdAPH DgWnz/vUlCuyq5m+twsYe4MhRc19fur9ze9Z/wDRbio66bM16XuPBKkoVW13Viys7mu+XGha4H6L m/nNU0Eg3qFJJJJKUkkkkp//0PVUkkklIcvKow8a3KyHbKqWl73eQ8P5TvzVCih7njJyB+nIhjOR W0/mM/l/6Wz8/wD4tZ/1optyuh5zK/zGBzR4ljm22H+y1iQ65VlYmPbUQG2s9XIM6MaP52r+vv8A Z/6sUscZMQY7kmMvAU155oxyGM9BGInH+seKUZf4nobOZ1JrBtqPJjfzx9LZ/V/eWPkZQbvdu3bf pk8jzcqXWeosJF2Md9Fg2NPG17R7qnN/M/fWPl5toyfUa8tcQ14j+U1rz/1Sv4OV0B2vu5fN/EPU QPVRG3y1L9KLp3dXY36Jn4Kq/qz3fR9p8+Cs59ld+tYFd3evhrv+K/dd/wAF/wBtqq66DB0I0IVy OGA6a+Lnzz55H5tP6rpDNex5IGyeQ3T8PoqYzMh2tTvUjlvDh/ZWR9oPB1HgU/rDlroI4kwfk5OM I9h+xi4Mn6MiPB2sbrmZiWG2l+14+kOxj82xn5y7HofX8fqtewxVlsE2Uzz/AC6v3mf9QvPqbLbx +sVF1fe8+zaPE2Ha16NtsxiLsR7hY3VjmO9wkbXPa5nu7qvzHL48gquGf6Mh/wB0z8p8Ry8vk4ZE zh+lAmx/gy/Rk9/gWGzM6h6UGmu4NBB0L9jPtDP7D/8Awb1VoAgiQsv6s5+HmdJq+y1to9H9HbQ2 YY8au+l7nepu9Xf/AOjFfLzXktYfoXA7fJ7dSP7bP/PayckSJyiRRjpr/VelwyBxxkDYn6rG3rP8 oJkkklGyqSSSSU//0fVVF7i1hI1PYefZSVLqozn0MowLRRkXWNaL3N3hjRNlr/TPte7YzYz+ujEW QNvNbI1EmifAbp77KsXFsss1rqYXOnuANf8AOXnpe+ltuPUQym8tsNY/Nn3MZP8Ar/g1q9f6OMDE ruys/JzLbLNrvUf7IAc87a/d+c1v5yw8dwcJBmDB+K0uUxCMDMHi4jvWnpee+Mczk4ow4PbMB+9x S/Wb3w/1UuPU5u5ljt1FwDbWRB0+hYw/6Wp30P8Atv8APWb1FxpvFbyJaxg3djA27m/ctdqDm5oo 201ub67wS0PAc0R9Fj/3PW/MVqMzxXvblYM+SRGLhE9yL9PDXq+b91w2+rdpVW6z+qCR/nfRU3xx l3VVOHB3h9n9V1WP6rnf21Kz6yXlprtqqc0aFj2GAR2LN6G3rdbjtb0/FM+Fe3TxKk4pdm4MWfrj AH9WceL/ABp8P/QWf9lpgu9XI3fRc3bVWf6rz61jkvt4pP6Kuqp/8lvqOHxuyN/v/qMT/tfCbIb0 /H930y3c0E/yfapU29GubuHT2ADRwFjxB/kwhZPQp4SBeTFOQ/vYiD5w9yMP+ajbmvufNznPA7vc SZ8E1dvu31OIdyI0cEYO6V6gacB1bWk7XDIdB/qtd9LcoPt6DU7aabtw7C0mPmjddCF136RinVbD 2tv8HI7P1e63nYucwUNYbMktrcH+1th19Ntn7j93trtW0z66Pu6nj/aaWU4TbJ3AkvbuY+nfY72s dXus3v8AYuQGZgQPRxnkmNu58kn81W82i2kN9Zjmes0PrkEbmu7s/eVfJhxzlZjRI4V8OYz4RGMB OGMS4uGXCY/ZHi4YvqdF1eRTXfUd1drQ9jh3a4bmlEVHowzG9Pqqza21X0gVuDNGENA2OYPzfZ+Z ++ryx5CiR2L0kDxRBOljyUkkkguf/9L1VRP0h8CpKl1VtlmL6Nbix2Q9tLrGmHNY9wba5h/f9Lds RiLIHdEjUSd66PKfXLqdeZ9n9BrnY1b7Wtv4ZY9uxtno/nPrp+h6383v/m1yz8u2pwcHlpbw1ujR 8Qu0+veLVT03CsY306saz0mMYIAa5nsa391rfRauBtydn80xrT+8fc7/AKS2eT4TgjWw4h/znnuf xH71PiHGZCP935W3X1PqljgGEBk62GsbQB4/vI+VjYnWA9tL24/UGa2VkyHNH5z2/S/t/Tr/AMIs N2TeXm02OLmDQk9z7WqFQcx7bi5zbAd7HAw8n9/f+apzEdNCwfdqInAjFOI9PBHc/u5P34Oi7Bbq 3KZuyI22WEFrtPbv5/d/wn+EVMGnbtbWS3uXOjd5u2BbFGfR1KtuN1A+jkD+ayWe0E9v5LHf8G/9 FYq2Z027Gs97RqdHN+i7+Uz9x379SIl0Io/msx5SJGGS4z3Eb9P97H/V/wCg0QY+jWxv9ncf+nuR G22M0d7/AB7AHwbtRBXt/rfkTigmO06Dz/qt+k5OZDIHpbVeG2EmwBr+zx+R4/7+l9jufc2tlZtt t1ZW3Wf3nOP5jP6y0DhNph2U80A6hgAde4fyavo0f17kK7JJpdj0s9DGP06wSXv87r/pP/qfzSbv t9qY5v8AN+rxP83Hy/f/AMH/AMba5uZghzKbBflukPvbrXUOCzF/0l37+R+Z/gV6t9UYt+rHTHPA cW0t2k6xt9rTqvIrKSGkt1aB8IXs/wBXsU4nQun4zhDq8eoOH8ra0v8A+kqPxHSEB1Mv2On8NA4p n5iQOIlvDl3+vZSUW8k+akst1FJJJJKf/9P1VReJbxJGoB8RqpJJKcz6x9PPU+iZWNWN1rmb6Y7v YfVrA/rubsXjltkifHsvdG6Es+bfgvLvrz0F3SeqHNoZ+p5zi9h7MuMvto/k+p7shn/XKq/5taHw /MAZYifm9Uf+6aHP4eLhygWY+mXk846v0SGOh1n0nDkNJ+ju/e2qTGkmTqTySoV1k6kjzcSIn4q9 RiFw3SC0cu+i0f1rHrSsOXM8I1PmWDK50iZ7crY6Zdc79Tui6og6OklscN3D83+uq1Yx6xDW+ue8 Haz/ANK2f9BF332N2H21/wCjYNrf81v0v7SRHEK/Fo5zxgjh8pS04T+9H9L/AKDbf0vHEvDnNiSR AJgaw0uVIZBAP2VookavHutI87XfR/62reK3JaZrkgctJO2Pn9FPkYldgNtAAs7tEFpP/Uf5qA9J qR4vH/vmCJmP5wmcf0Zfof4blOq5Pc6k8koL2Qrr6njSxorJ4jv/AGkGysCfyqRsxnrqv0Xpp6j1 fFwQJrteDd/xTP0l3/Qbs/tr2AmBJ7LlvqN0J2HjO6nkNjIy2gVNPLaZ3a/yr3fpP6npLp3GXBkS Bq4/9SsbnswyZeEfLj0/wv0no+QwnHhuQ9WT1fT9Fk0ENE89/inSSVNuKSSSSU//1PVUkkklMXhx b7fpjVs8T/K/krHu6HldTw343V851zLY9aimuplYIO8Cv1a7sj9G7+bs9XetpRc3WW6O/L5FOjMx 20Pelk4CW9+QJj/0XyXqvSbug9QtpuDLqgWtrvYCZD9zqmXbi6vHu2Vu/Rf4T/B+xVXXMtcJYdrf ojdEf2W+1eqNw6HX5uPmVNsq6g5tu14Dmu2110PqM/6P7P6v9v8AkLneqf4vWAm3o9oZOv2a8kj/ AK1f7nt/q2+p/wAatPBzsCQMp4ZUPX+jJyOY+HSJOTEOLU+i/VH92v8ABeTr9L91w+YP/fVboYHE BsgnxAP5E9/ROr4ZIyMS5gHL2jez/tyn1GqOOQ14Jc5sHXWD+KvCQlG4S4vI8TkZccoGpiUf7w/7 56LA6c8gE4/r+G61v/nt4bWr2RiWOqIsw7dsfmuqdx+7tsVbplpIAqzbQ790Cuz/AKJrWk9vVC3a yxto/wCFx3NP+djv/wDRazcs5CepH143Zw4ccsVAyIIqqw8P/R4njLbGPBDhI8D/ABWn0X6v3OvZ l5uHffiiH00ez3nsbvXtq/Qt/wBG/wDnv+K+nqZ3Qr8nEtLMM25djdLLHNqY0z9OljXWWvd/4ZRf qtX1DP6VTk5ebY7HdLaaWAMO1hNX6TIb+nfu2/muYnZOZPtngkB+jL6/ucLX5T4ccecDJxS044aV D0/v+5/6j43Sdn9Ste6rHw212DSb7W+2eHvrxftH+b6le9aDGuawBx3Oj3OAiT47U1VVdTAypoYw cACAprOkQdgA7sIkaykZHx6f4vCpJJJNXqSSSSU//9X1VJJcXnf4zMPEzsnEODbYca2ykvD2gONb jU5wB/lNT8eKeQkQHFS2eSMBcjVvaJLhf/HVw/8Ayuu/z2Le+rf1u6b9YPUroa+jKpAdZj2xO06e pU5pc2yvd7P9a0+fLZoR4pQIA6rY5scjUZAl2rK2WN2vG4fx8R+65Aurzmsd9lsY50extwJE9psr LXf9B6w/rJ9d8boGezBsxX5D31C4uY5rQA5z62t93/Fq79WvrJi/WHEsyKK3UPps9Oyl5BI0D2P9 v5j2lD2skYDIY+g9VccJSML9fhoW1VblViMxlpcfpOqAdWD/AMH6X6zt/wCMrRRiYVzQ91Tbp1Bt Bef/AAbc5qwvrJ9d8boHUGYNmLZkPfU24uY5rQA5z62t93/FLW6D1dvWul09SZU6hlxeG1uIJ9j3 0zLf3vTSlDIIDJw8MZbEFETAyML4yNxIXJvNa1g2sAaBwAICksSz6zA2Ppxen5WRcA41thjA9rHe k6332esyn1Pz30omN9YqsjeG4mQwtrte0vFYa51JDbqfVZa9lVrXnb+m9NVvexk1xNw8pmAvhoec f+i6WTjsyaXUWE+nYNrw07SWn6TNzfd7v5KnXXXVW2utoZWwBrGNEAAaNa1o+i1qxj9aK68WvKvw shjL278dg9N731hvq23bG2/oq6a9vqet6f01Z6X1ujPxLMiyt+GccA5Db4aGgsbd6gt+g6nY7+cR GaBIiJa78KJcpliDMw0HpMgYy/6P9b/nukksav6xOddS+zDsp6bkv9OjPsc0NcTPpPdR/PVU3ub+ hts+nvp/0qi360Y7633MxrnUsZQ8Ebd5OQ+yikem57Wf4L/S/wCFYh72Pv8AgenX+6n7pn/c7bGO 8jwcJ/r8X6DtpLEH1kcWmv8AZ97csWCkUPdW0F5achzPW9TYzZjD1nep/pK1p4ORfk44tvoOM8kj 0y9tmgOjt9Jcz3IxyRkaBv6FbkwZMYuYA/wom/GMeL1R/rthJJJPYn//1vU7LGVVuteYYwFzj4AC SvBa92Vks9V4Yci0epY4gAeo/wB9jnO9rWt37l7P9askYv1b6lcf+49jB8Xj0m/9J68h6L0q3q3U qOmUvFT79wFjgXBoY11jiWtj9xaPw8CMMkyaHf8Au6tLnLM8cAL8PN6X63dN+pGJ0wP6NbWc82N2 MovdfLZ/S+q11tza2bPdv/0ij/ixwb7utXZ7QRjY1Lq32djZYWbaf8xjrH/ufo/9Is/6yfUzM+r2 LTlXZFeRVdZ6PsaWFri11jdHOfua5tb10v8Aiy61lZDMjpF8PqxWNsxnAAFrSSyyp5b9P3bX17vf /OfyE/Ia5WRhM5Qd5zOvCtgL5iPHEYyBoIvNfX3I9f615mstoFVLT/VY2x3/AIJbYp/UPrP7L69X XY6MbPjHtHYPJ/VrP7Nh9L/r6yeq2nP61mW1GftWXZ6Z8n2FlX/RLVc+t/RR0Xrl2NUCzGtAvxCD wx35rXf8Bc17P+21PwxOOOCX6UP+jwsPFL3JZhtGf5pfr3k+t9ac50yyn06m+WytheP+3XWL0z6u 1MwPqxgNscKm1YjH2vfo1pLPVue+fota5z143kWX9RzX22w6/Ntl+0QC610Ohv8AaXt2dlY/TsGX PpqAAqp+0P8ATrLo9jH2bX7fa39xU+f/AFeHFAn5Rr/gDhbfIg5Ms5AE8RAA/vPKtdl1Mc3odjci utzLcvIxMZ1e4Vu3bfXfdY7Of7v6Ox38z+j9T8xLJowrcDqnUKeo03W5gopyH1sOOaw+yut3rt9X dUy2sfpvWr3/AMtXcj633Y3pAfs7Jda8MZXj5hc7mPpOx2U1t/42xit9V+stGNS1+JVVnC5riIsA 3OY/0IY303+v722fQ/0SwiMQEryfKNvX6OL0gwjxPRXzIlD9VrOQ9XFivLwSjOUcs+D/AFfo/m/+ qPMWVYT3vrw2vtqZbc7HxqH2fpm2vrosxGvod6np5GBhfaPU/mdl/wDwi3a7Psv1KycjHufYbmPI JfY70t59D0a3X7r2Mw2/o/8Arfqqf/O6uux1bqsetzai5gNxjcHNZ6TrG0HY11X6RqLlfWZ9Gbdi Cmhwoa4Wg3ta4PFTcnc5tjWVsxd9teP69tlf6RDH7YEiMt2ODSMvRKfyqyHmJ8EThNQl7tSyxPHD H84/5/zOTZj9GqyPU6XdisOLutZcOoOsssDK3FjPs9jvSZuu2eo+yz9HUql7cNvSyzeNtjiaXQ21 r2YmMzDZ6Pr+p/PZz7a8ezH/AEtnq/olu9L+tLOo5NNFePUPVfsdF1RcGisusf6O/wBZ/wCsN2M/ R+/H/To+R1vMwsmmnqGJjsY8Gy003PtdXVXq7IfV9lr/AEbbNjGf8IiYYzEyE+GJ00jwx1T7nMQm ISxmUxHi4ZZozySjHiP6XF6uKLzZw+n1UZbHht7enUZXqSxjQLh6eFi+t6W31LXvZfbjWZO/I/wq 7jp2FVgYNGHU0NZQwMhogEge9/8AWe/3vQMbq3TcyvItx5fTQN1trq3MYSAXQHWtZ6j2NZ7tv0E/ Q87I6h0rHzchja7b2l5aydoBJ2Ru/eZtU2CEIy9MuLijYI/dj4/4rU5vLmyQ9cZQGOYEozP6eSPH H0en/Wf47fSSSVhov//X6z/GRkGn6sWVCZybqqtAToHeu7j+RSvMMHNzen5LcvCc+nIYHBtgZJAc Nr/ptc36K94XK0fWHqDLPtd+92JYzKvZU+tjA+qoudjV4VrX+pZkPZ6P9Ib6T6/Vs9itYObGLGYe 3xWSTr38OFr5uXOSYnx8NbUHzzJyPrH157HXDK6g6uRW1tbnBs/S2sqZsbu2+5y736p9ByPqz0TO 6hnANzbaza+sEO9Oulr31VbmfSs3OsfZs/74tav6xP8AXNV+I6sVP9LJsa7eyt/p/af53Yyl1VVW z7Ra6yv0bf8AtxVb/rVY1tbjQ6jbkV12NHv3NspsyGVh1gobW/f6DLrnfqtXq+r9pexLLzhnHgEB CF6xH5Kx8sISMjIynXzF81+q+M/J6/0yosJnIre8EGIYfXf/ANQvQf8AGP0Y53Rhn1N3X9OJsMcm l2mQP7EMv/60rd/XupMy7GNprLaLLC5geBNVGOy3J33Pb7dmZl0s9Rrf8H6f/CKwPrFbZkfZ6MJz 3WOFdG+xrC54qZlX72w/0qcdlnpWW/pP1j9H6f56WTnJTywyCPDwdLu/3lQ5YRhKBN8fg+W/VfFf k/WPptQaf6Qywy0xFX6w/n+TUvVvrAMnKoHTMWvc7Ka717Xe2tlI/nQ+2HbX5E+hX7fz7Lf8Eh1/ WfGsxm5XpOZS40jc4jT1a/tlv0d39Fxf0r9n85/gkJ3XuoX2VUUYno5D7KCGOe1wNVrcjILbHtn0 LW04jvW+n9P9D6yi5vMeYrTgFcOhtl5SH3c2PWQeIXp6v0f8V5+ro+d1HDzcqhvq47mBjfeZtbS3 1W1srdhY78ljrP0Vf9E/66rnXMcXZeNdj4loq2Y9GPX6b2sY07rXOo9G+lrXtps9D0/Tr/c3rq+n 5gzsGjMDDX69bbNjiCW7hO2R9JWFQ+6DhMeI6/Mf8b/vnSPxGfGJcFCN8I4uhEY+r/wt5RmPn05X StlT8LGbvofkBrrHn7Q5mW+r0rX5V2Kz1Kfs/r3Xex9n+DZ6azLcI512Za/Hsd6pdZsbTY2wevcx 7abrKqr3u9TAx2We+n06N/p2LvkkZcrxacZr/wBB4UQ+ISib4PV+8Dr85yS4j6perieS6VWf2x9t yKbrH4OI8saQXWMk+yjb9lwPfbV6noUfpf8ArabG6liOpuzLMx+L1fNLTZcMay30a2mWYVTbKfT2 MZ/OO/Pv9S5dckiMEgKE+5Ng7y/S9M4epaecjIkmB2jEcMh8sPXwevHkjwSn6+F51+WbPq31Cy7P +1MIfU3IfjvqLd7WV+m6hjA+332fSrrW3g4rcPCx8Ruox6mVAj+Q0M/gjpKWEKNk36eHr/3UpMGT LxDhA4QZGdentwx0hDGpJJJPYn//0PVVn0dA6NQ0tpxK2tLQzbEgNa5trWNB+iz1GMfsatBJJTSt 6P0u66y+3GY+y5pbYXCQ7c30nuLPoeo+r9E63+c9L9Gmb0XpTWPZ9mY4Wh7bS+Xl4sa2i31X2Fz7 PUpqrq9/+DV5JJTTd0vpjfXsdQyLmPbeTrLHhjb26/m2tpr9X/SbFh4+b0zNxcenPwCTa5lt1tbd tTLcqp+Y73+r6/8AMO25W32fpP0n6JdLdSy+mymwTXa0seASDDhtd7m+5U3dE6Y6o1GmGOcXwHOH uNH7O9sO9v6n+i/9SJKchmV0e61tlPTrqc7IZW7EAZUHxbRbXXfWx9j8Wh9OLXbTZ9o/M9On3/oq 1HpV/RcdjHspdZde+u1n6JtYaLKHDdVUHfoqsbEpuru92/1PUq/wlTFs39E6de4vcxzXlzXCxlj2 ObtZ9nit9bmuY11J9N+xNZ0HpNgcDjtAfijBIaS0DHBJbQwNPsb7vzUlOdT9ZMVmPQzCxSMep/ov aHVltdLKHZW+p1NtlVnpVsra6ttns/7a9Q4+stNWN6uTVaQyt+69jAK33UsN2Tj0Nda6zd7La2b/ ANH6tdlPrKw/6v8ATLGuFjbLC8vdY51thc82VNw7fUdv92/HYxmz/MTu6B0t9j7HVuPqFx2F79jS 97b7/Sr3bKvXtZuu9P8AnElJ8HObmesPSsofj2elYyzbMlleQ0/o3WN91V9aoXdfa36wUdLqfSWE mrIBd+l9V1b8mkVVz/NV11fp37P+1NH7ly1KManHNpqEG+w22EkmXkBs+7+Sxqr/ALI6eccYxqmt txyNXO3G0uNzrXWbt7nOe7/0X/NpKaeN9ZsbKqbZj491jrXiuitpr3PO11zw5vq/qzqWV/p2ZfoP q/R/n2KLvrb0xtr6i2wOra42NO0Oa9lX2qyl9Rs9Vrm1t2eps+z+v+h9berH/NzpW2Cyw2TJuNtn qkbfR9M5G/1vS9H9Hs3/APgil+wemRa1tbmVXNLXUtse2obtLPToa70q3WNb79jP/PliSkLevWW5 OPj04lrX2ZHo3i3aCxno/bPV9tjvzX1ez/1H6muqg6ZhjLGYGuF4e6zdud9J7GY75bu27fSpq9n8 hW0lKSSSSU//2f/tJ8ZQaG90b3Nob3AgMy4wADhCSU0EJQAAAAAAEAAAAAAAAAAAAAAAAAAAAAA4 QklNBDoAAAAAAJMAAAAQAAAAAQAAAAAAC3ByaW50T3V0cHV0AAAABQAAAABDbHJTZW51bQAAAABD bHJTAAAAAFJHQkMAAAAASW50ZWVudW0AAAAASW50ZQAAAABJbWcgAAAAAE1wQmxib29sAQAAAA9w cmludFNpeHRlZW5CaXRib29sAAAAAAtwcmludGVyTmFtZVRFWFQAAAABAAAAOEJJTQQ7AAAAAAGy AAAAEAAAAAEAAAAAABJwcmludE91dHB1dE9wdGlvbnMAAAASAAAAAENwdG5ib29sAAAAAABDbGJy Ym9vbAAAAAAAUmdzTWJvb2wAAAAAAENybkNib29sAAAAAABDbnRDYm9vbAAAAAAATGJsc2Jvb2wA AAAAAE5ndHZib29sAAAAAABFbWxEYm9vbAAAAAAASW50cmJvb2wAAAAAAEJja2dPYmpjAAAAAQAA AAAAAFJHQkMAAAADAAAAAFJkICBkb3ViQG/gAAAAAAAAAAAAR3JuIGRvdWJAb+AAAAAAAAAAAABC bCAgZG91YkBv4AAAAAAAAAAAAEJyZFRVbnRGI1JsdAAAAAAAAAAAAAAAAEJsZCBVbnRGI1JsdAAA AAAAAAAAAAAAAFJzbHRVbnRGI1B4bEBSAAAAAAAAAAAACnZlY3RvckRhdGFib29sAQAAAABQZ1Bz ZW51bQAAAABQZ1BzAAAAAFBnUEMAAAAATGVmdFVudEYjUmx0AAAAAAAAAAAAAAAAVG9wIFVudEYj Umx0AAAAAAAAAAAAAAAAU2NsIFVudEYjUHJjQFkAAAAAAAA4QklNA+0AAAAAABAASAAAAAEAAgBI AAAAAQACOEJJTQQmAAAAAAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAAB4OEJJTQQZAAAA AAAEAAAAHjhCSU0D8wAAAAAACQAAAAAAAAAAAQA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1 AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAA AAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4AAAAAABwAAD///////////////////////////// A+gAAAAA/////////////////////////////wPoAAAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAADhCSU0EAAAAAAAAAgAIOEJJTQQCAAAAAAAS AAAAAAAAAAAAAAAAAAAAAAAAOEJJTQQwAAAAAAAJAQEBAQEBAQEBADhCSU0ELQAAAAAAAgAAOEJJ TQQIAAAAAAAQAAAAAQAAAkAAAAJAAAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAzkAAAAG AAAAAAAAAAAAAADGAAAAoAAAAAIAQgBOAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAA AACgAAAAxgAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVs bAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAxgAAAABSZ2h0bG9uZwAAAKAAAAAGc2xpY2VzVmxM cwAAAAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJ RGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQA AAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAA UmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAMYA AAAAUmdodGxvbmcAAACgAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNn ZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAA CGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAA AAdkZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQA AAALYmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0 c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAA AAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAA AAAEAAAACzhCSU0EDAAAAAAeUQAAAAEAAACBAAAAoAAAAYQAAPKAAAAeNQAYAAH/2P/tAAxBZG9i ZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEM DAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQR DAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAoACBAwEiAAIR AQMRAf/dAAQACf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAA AAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIj JBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU 5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITES BEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi 8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMR AD8A9VSSSSUpJJDvvqoZvsMAkNaAJJcfosY0e5zklEgCzokQbMljZDGuuePzKxJn93c7bWz+29Qb Xff7sj9Gz82hp1j/AIaxv0v+Lr/R/wDGoll2PjtAcQwD6LR/BrU4DWvmPgtMtL+Udy4lnXuou6uz pLqqen2WMFjLLybg+fo1sZUcdnqaP/w62KactoHrZAsPfZWGD7nOtd/01k9YZ0/qtIqvqMs1qvBA ew+LIn/MVWjrXVOnsFOaRk0N0ZmNBLgP+7DJ3f2//PqnOIyiOGIif0on/pRl/wBy0/vAxzl7sjOB NxyDaP8AVyQjw/8Ahj0oa8fnz8QFJ0x7RJ8DosZnXHlocPTsYeHCdfxVirrmM4xaDX5j3D8Pd/0V GcGQfo35M8eZxH9Kr7/xdAPHDgWnz/vUlCuyq5m+twsYe4MhRc19fur9ze9Z/wDRbio66bM16XuP BKkoVW13Viys7mu+XGha4H6Lm/nNU0Eg3qFJJJJKUkkkkp//0PVUkkklIcvKow8a3KyHbKqWl73e Q8P5TvzVCih7njJyB+nIhjORW0/mM/l/6Wz8/wD4tZ/1optyuh5zK/zGBzR4ljm22H+y1iQ65VlY mPbUQG2s9XIM6MaP52r+vv8AZ/6sUscZMQY7kmMvAU155oxyGM9BGInH+seKUZf4nobOZ1JrBtqP Jjfzx9LZ/V/eWPkZQbvdu3bfpk8jzcqXWeosJF2Md9Fg2NPG17R7qnN/M/fWPl5toyfUa8tcQ14j +U1rz/1Sv4OV0B2vu5fN/EPUQPVRG3y1L9KLp3dXY36Jn4Kq/qz3fR9p8+Cs59ld+tYFd3evhrv+ K/dd/wAF/wBtqq66DB0I0IVyOGA6a+Lnzz55H5tP6rpDNex5IGyeQ3T8PoqYzMh2tTvUjlvDh/ZW R9oPB1HgU/rDlroI4kwfk5OMI9h+xi4Mn6MiPB2sbrmZiWG2l+14+kOxj82xn5y7HofX8fqtewxV lsE2Uzz/AC6v3mf9QvPqbLbx+sVF1fe8+zaPE2Ha16NtsxiLsR7hY3VjmO9wkbXPa5nu7qvzHL48 gquGf6Mh/wB0z8p8Ry8vk4ZEzh+lAmx/gy/Rk9/gWGzM6h6UGmu4NBB0L9jPtDP7D/8Awb1VoAgi Qsv6s5+HmdJq+y1to9H9HbQ2YY8au+l7nepu9Xf/AOjFfLzXktYfoXA7fJ7dSP7bP/PayckSJyiR Rjpr/VelwyBxxkDYn6rG3rP8oJkkklGyqSSSSU//0fVVF7i1hI1PYefZSVLqozn0MowLRRkXWNaL 3N3hjRNlr/TPte7YzYz+ujEWQNvNbI1EmifAbp77KsXFsss1rqYXOnuANf8AOXnpe+ltuPUQym8t sNY/Nn3MZP8Ar/g1q9f6OMDEruys/JzLbLNrvUf7IAc87a/d+c1v5yw8dwcJBmDB+K0uUxCMDMHi 4jvWnpee+Mczk4ow4PbMB+9xS/Wb3w/1UuPU5u5ljt1FwDbWRB0+hYw/6Wp30P8Atv8APWb1Fxpv FbyJaxg3djA27m/ctdqDm5oo201ub67wS0PAc0R9Fj/3PW/MVqMzxXvblYM+SRGLhE9yL9PDXq+b 91w2+rdpVW6z+qCR/nfRU3xxl3VVOHB3h9n9V1WP6rnf21Kz6yXlprtqqc0aFj2GAR2LN6G3rdbj tb0/FM+Fe3TxKk4pdm4MWfrjAH9WceL/ABp8P/QWf9lpgu9XI3fRc3bVWf6rz61jkvt4pP6Kuqp/ 8lvqOHxuyN/v/qMT/tfCbIb0/H930y3c0E/yfapU29GubuHT2ADRwFjxB/kwhZPQp4SBeTFOQ/vY iD5w9yMP+ajbmvufNznPA7vcSZ8E1dvu31OIdyI0cEYO6V6gacB1bWk7XDIdB/qtd9LcoPt6DU7a abtw7C0mPmjddCF136RinVbD2tv8HI7P1e63nYucwUNYbMktrcH+1th19Ntn7j93trtW0z66Pu6n j/aaWU4TbJ3AkvbuY+nfY72sdXus3v8AYuQGZgQPRxnkmNu58kn81W82i2kN9Zjmes0PrkEbmu7s /eVfJhxzlZjRI4V8OYz4RGMBOGMS4uGXCY/ZHi4YvqdF1eRTXfUd1drQ9jh3a4bmlEVHowzG9Pqq za21X0gVuDNGENA2OYPzfZ+Z++ryx5CiR2L0kDxRBOljyUkkkguf/9L1VRP0h8CpKl1VtlmL6Nbi x2Q9tLrGmHNY9wba5h/f9LdsRiLIHdEjUSd66PKfXLqdeZ9n9BrnY1b7Wtv4ZY9uxtno/nPrp+h6 383v/m1yz8u2pwcHlpbw1ujR8Qu0+veLVT03CsY306saz0mMYIAa5nsa391rfRauBtydn80xrT+8 fc7/AKS2eT4TgjWw4h/znnufxH71PiHGZCP935W3X1PqljgGEBk62GsbQB4/vI+VjYnWA9tL24/U Ga2VkyHNH5z2/S/t/Tr/AMIsN2TeXm02OLmDQk9z7WqFQcx7bi5zbAd7HAw8n9/f+apzEdNCwfdq InAjFOI9PBHc/u5P34Oi7Bbq3KZuyI22WEFrtPbv5/d/wn+EVMGnbtbWS3uXOjd5u2BbFGfR1Ktu N1A+jkD+ayWe0E9v5LHf8G/9FYq2Z027Gs97RqdHN+i7+Uz9x379SIl0Io/msx5SJGGS4z3Eb9P9 7H/V/wCg0QY+jWxv9ncf+nuRG22M0d7/AB7AHwbtRBXt/rfkTigmO06Dz/qt+k5OZDIHpbVeG2Em wBr+zx+R4/7+l9jufc2tlZttt1ZW3Wf3nOP5jP6y0DhNph2U80A6hgAde4fyavo0f17kK7JJpdj0 s9DGP06wSXv87r/pP/qfzSbvt9qY5v8AN+rxP83Hy/f/AMH/AMba5uZghzKbBflukPvbrXUOCzF/ 0l37+R+Z/gV6t9UYt+rHTHPAcW0t2k6xt9rTqvIrKSGkt1aB8IXs/wBXsU4nQun4zhDq8eoOH8ra 0v8A+kqPxHSEB1Mv2On8NA4pn5iQOIlvDl3+vZSUW8k+akst1FJJJJKf/9P1VReJbxJGoB8RqpJJ Kcz6x9PPU+iZWNWN1rmb6Y7vYfVrA/rubsXjltkifHsvdG6Es+bfgvLvrz0F3SeqHNoZ+p5zi9h7 MuMvto/k+p7shn/XKq/5taHw/MAZYifm9Uf+6aHP4eLhygWY+mXk846v0SGOh1n0nDkNJ+ju/e2q TGkmTqTySoV1k6kjzcSIn4q9RiFw3SC0cu+i0f1rHrSsOXM8I1PmWDK50iZ7crY6Zdc79Tui6og6 OklscN3D83+uq1Yx6xDW+ue8Haz/ANK2f9BF332N2H21/wCjYNrf81v0v7SRHEK/Fo5zxgjh8pS0 4T+9H9L/AKDbf0vHEvDnNiSRAJgaw0uVIZBAP2VookavHutI87XfR/62reK3JaZrkgctJO2Pn9FP kYldgNtAAs7tEFpP/Uf5qA9JqR4vH/vmCJmP5wmcf0Zfof4blOq5Pc6k8koL2Qrr6njSxorJ4jv/ AGkGysCfyqRsxnrqv0Xpp6j1fFwQJrteDd/xTP0l3/Qbs/tr2AmBJ7LlvqN0J2HjO6nkNjIy2gVN PLaZ3a/yr3fpP6npLp3GXBkSBq4/9SsbnswyZeEfLj0/wv0no+QwnHhuQ9WT1fT9Fk0ENE89/inS SVNuKSSSSU//1PVUkkklMXhxb7fpjVs8T/K/krHu6HldTw343V851zLY9aimuplYIO8Cv1a7sj9G 7+bs9XetpRc3WW6O/L5FOjMx20Pelk4CW9+QJj/0XyXqvSbug9QtpuDLqgWtrvYCZD9zqmXbi6vH u2Vu/Rf4T/B+xVXXMtcJYdrfojdEf2W+1eqNw6HX5uPmVNsq6g5tu14Dmu2110PqM/6P7P6v9v8A kLneqf4vWAm3o9oZOv2a8kj/AK1f7nt/q2+p/wAatPBzsCQMp4ZUPX+jJyOY+HSJOTEOLU+i/VH9 2v8ABeTr9L91w+YP/fVboYHEBsgnxAP5E9/ROr4ZIyMS5gHL2jez/tyn1GqOOQ14Jc5sHXWD+KvC QlG4S4vI8TkZccoGpiUf7w/756LA6c8gE4/r+G61v/nt4bWr2RiWOqIsw7dsfmuqdx+7tsVbplpI AqzbQ790Cuz/AKJrWk9vVC3ayxto/wCFx3NP+djv/wDRazcs5CepH143Zw4ccsVAyIIqqw8P/R4n jLbGPBDhI8D/ABWn0X6v3OvZl5uHffiiH00ez3nsbvXtq/Qt/wBG/wDnv+K+nqZ3Qr8nEtLMM25d jdLLHNqY0z9OljXWWvd/4ZRfqtX1DP6VTk5ebY7HdLaaWAMO1hNX6TIb+nfu2/muYnZOZPtngkB+ jL6/ucLX5T4ccecDJxS044aVD0/v+5/6j43Sdn9Ste6rHw212DSb7W+2eHvrxftH+b6le9aDGuaw Bx3Oj3OAiT47U1VVdTAypoYwcACAprOkQdgA7sIkaykZHx6f4vCpJJJNXqSSSSU//9X1VJJcXnf4 zMPEzsnEODbYca2ykvD2gONbjU5wB/lNT8eKeQkQHFS2eSMBcjVvaJLhf/HVw/8Ayuu/z2Le+rf1 u6b9YPUroa+jKpAdZj2xO06epU5pc2yvd7P9a0+fLZoR4pQIA6rY5scjUZAl2rK2WN2vG4fx8R+6 5Aurzmsd9lsY50extwJE9psrLXf9B6w/rJ9d8boGezBsxX5D31C4uY5rQA5z62t93/Fq79WvrJi/ WHEsyKK3UPps9Oyl5BI0D2P9v5j2lD2skYDIY+g9VccJSML9fhoW1VblViMxlpcfpOqAdWD/AMH6 X6zt/wCMrRRiYVzQ91Tbp1BtBef/AAbc5qwvrJ9d8boHUGYNmLZkPfU24uY5rQA5z62t93/FLW6D 1dvWul09SZU6hlxeG1uIJ9j30zLf3vTSlDIIDJw8MZbEFETAyML4yNxIXJvNa1g2sAaBwAICksSz 6zA2Ppxen5WRcA41thjA9rHek6332esyn1Pz30omN9YqsjeG4mQwtrte0vFYa51JDbqfVZa9lVrX nb+m9NVvexk1xNw8pmAvhoecf+i6WTjsyaXUWE+nYNrw07SWn6TNzfd7v5KnXXXVW2utoZWwBrGN EAAaNa1o+i1qxj9aK68WvKvwshjL278dg9N731hvq23bG2/oq6a9vqet6f01Z6X1ujPxLMiyt+Gc cA5Db4aGgsbd6gt+g6nY7+cRGaBIiJa78KJcpliDMw0HpMgYy/6P9b/nukksav6xOddS+zDsp6bk v9OjPsc0NcTPpPdR/PVU3ub+hts+nvp/0qi360Y7633MxrnUsZQ8Ebd5OQ+yikem57Wf4L/S/wCF Yh72Pv8AgenX+6n7pn/c7bGO8jwcJ/r8X6DtpLEH1kcWmv8AZ97csWCkUPdW0F5achzPW9TYzZjD 1nep/pK1p4ORfk44tvoOM8kj0y9tmgOjt9Jcz3IxyRkaBv6FbkwZMYuYA/wom/GMeL1R/rthJJJP Yn//1vU7LGVVuteYYwFzj4ACSvBa92Vks9V4Yci0epY4gAeo/wB9jnO9rWt37l7P9askYv1b6lcf +49jB8Xj0m/9J68h6L0q3q3UqOmUvFT79wFjgXBoY11jiWtj9xaPw8CMMkyaHf8Au6tLnLM8cAL8 PN6X63dN+pGJ0wP6NbWc82N2MovdfLZ/S+q11tza2bPdv/0ij/ixwb7utXZ7QRjY1Lq32djZYWba f8xjrH/ufo/9Is/6yfUzM+r2LTlXZFeRVdZ6PsaWFri11jdHOfua5tb10v8Aiy61lZDMjpF8PqxW NsxnAAFrSSyyp5b9P3bX17vf/OfyE/Ia5WRhM5Qd5zOvCtgL5iPHEYyBoIvNfX3I9f615mstoFVL T/VY2x3/AIJbYp/UPrP7L69XXY6MbPjHtHYPJ/VrP7Nh9L/r6yeq2nP61mW1GftWXZ6Z8n2FlX/R LVc+t/RR0Xrl2NUCzGtAvxCDwx35rXf8Bc17P+21PwxOOOCX6UP+jwsPFL3JZhtGf5pfr3k+t9ac 50yyn06m+WytheP+3XWL0z6u1MwPqxgNscKm1YjH2vfo1pLPVue+fota5z143kWX9RzX22w6/Ntl +0QC610Ohv8AaXt2dlY/TsGXPpqAAqp+0P8ATrLo9jH2bX7fa39xU+f/AFeHFAn5Rr/gDhbfIg5M s5AE8RAA/vPKtdl1Mc3odjciutzLcvIxMZ1e4Vu3bfXfdY7Of7v6Ox38z+j9T8xLJowrcDqnUKeo 03W5gopyH1sOOaw+yut3rt9XdUy2sfpvWr3/AMtXcj633Y3pAfs7Jda8MZXj5hc7mPpOx2U1t/42 xit9V+stGNS1+JVVnC5riIsA3OY/0IY303+v722fQ/0SwiMQEryfKNvX6OL0gwjxPRXzIlD9VrOQ 9XFivLwSjOUcs+D/AFfo/m/+qPMWVYT3vrw2vtqZbc7HxqH2fpm2vrosxGvod6np5GBhfaPU/mdl /wDwi3a7Psv1KycjHufYbmPIJfY70t59D0a3X7r2Mw2/o/8Arfqqf/O6uux1bqsetzai5gNxjcHN Z6TrG0HY11X6RqLlfWZ9GbdiCmhwoa4Wg3ta4PFTcnc5tjWVsxd9teP69tlf6RDH7YEiMt2ODSMv RKfyqyHmJ8EThNQl7tSyxPHDH84/5/zOTZj9GqyPU6XdisOLutZcOoOsssDK3FjPs9jvSZuu2eo+ yz9HUql7cNvSyzeNtjiaXQ21r2YmMzDZ6Pr+p/PZz7a8ezH/AEtnq/olu9L+tLOo5NNFePUPVfsd F1RcGisusf6O/wBZ/wCsN2M/R+/H/To+R1vMwsmmnqGJjsY8Gy003PtdXVXq7IfV9lr/AEbbNjGf 8IiYYzEyE+GJ00jwx1T7nMQmISxmUxHi4ZZozySjHiP6XF6uKLzZw+n1UZbHht7enUZXqSxjQLh6 eFi+t6W31LXvZfbjWZO/I/wq7jp2FVgYNGHU0NZQwMhogEge9/8AWe/3vQMbq3TcyvItx5fTQN1t rq3MYSAXQHWtZ6j2NZ7tv0E/Q87I6h0rHzchja7b2l5aydoBJ2Ru/eZtU2CEIy9MuLijYI/dj4/4 rU5vLmyQ9cZQGOYEozP6eSPHH0en/Wf47fSSSVhov//X6z/GRkGn6sWVCZybqqtAToHeu7j+RSvM MHNzen5LcvCc+nIYHBtgZJAcNr/ptc36K94XK0fWHqDLPtd+92JYzKvZU+tjA+qoudjV4VrX+pZk PZ6P9Ib6T6/Vs9itYObGLGYe3xWSTr38OFr5uXOSYnx8NbUHzzJyPrH157HXDK6g6uRW1tbnBs/S 2sqZsbu2+5y736p9ByPqz0TO6hnANzbaza+sEO9Oulr31VbmfSs3OsfZs/74tav6xP8AXNV+I6sV P9LJsa7eyt/p/af53Yyl1VVWz7Ra6yv0bf8AtxVb/rVY1tbjQ6jbkV12NHv3NspsyGVh1gobW/f6 DLrnfqtXq+r9pexLLzhnHgEBCF6xH5Kx8sISMjIynXzF81+q+M/J6/0yosJnIre8EGIYfXf/ANQv Qf8AGP0Y53Rhn1N3X9OJsMcml2mQP7EMv/60rd/XupMy7GNprLaLLC5geBNVGOy3J33Pb7dmZl0s 9Rrf8H6f/CKwPrFbZkfZ6MJz3WOFdG+xrC54qZlX72w/0qcdlnpWW/pP1j9H6f56WTnJTywyCPDw dLu/3lQ5YRhKBN8fg+W/VfFfk/WPptQaf6Qywy0xFX6w/n+TUvVvrAMnKoHTMWvc7Ka717Xe2tlI /nQ+2HbX5E+hX7fz7Lf8Eh1/WfGsxm5XpOZS40jc4jT1a/tlv0d39Fxf0r9n85/gkJ3XuoX2VUUY no5D7KCGOe1wNVrcjILbHtn0LW04jvW+n9P9D6yi5vMeYrTgFcOhtl5SH3c2PWQeIXp6v0f8V5+r o+d1HDzcqhvq47mBjfeZtbS31W1srdhY78ljrP0Vf9E/66rnXMcXZeNdj4loq2Y9GPX6b2sY07rX Oo9G+lrXtps9D0/Tr/c3rq+n5gzsGjMDDX69bbNjiCW7hO2R9JWFQ+6DhMeI6/Mf8b/vnSPxGfGJ cFCN8I4uhEY+r/wt5RmPn05XStlT8LGbvofkBrrHn7Q5mW+r0rX5V2Kz1Kfs/r3Xex9n+DZ6azLc I512Za/Hsd6pdZsbTY2wevcx7abrKqr3u9TAx2We+n06N/p2LvkkZcrxacZr/wBB4UQ+ISib4PV+ 8Dr85yS4j6perieS6VWf2x9tyKbrH4OI8saQXWMk+yjb9lwPfbV6noUfpf8ArabG6liOpuzLMx+L 1fNLTZcMay30a2mWYVTbKfT2MZ/OO/Pv9S5dckiMEgKE+5Ng7y/S9M4epaecjIkmB2jEcMh8sPXw evHkjwSn6+F51+WbPq31Cy7P+1MIfU3IfjvqLd7WV+m6hjA+332fSrrW3g4rcPCx8Ruox6mVAj+Q 0M/gjpKWEKNk36eHr/3UpMGTLxDhA4QZGdentwx0hDGpJJJPYn//0PVVn0dA6NQ0tpxK2tLQzbEg Na5trWNB+iz1GMfsatBJJTSt6P0u66y+3GY+y5pbYXCQ7c30nuLPoeo+r9E63+c9L9Gmb0XpTWPZ 9mY4Wh7bS+Xl4sa2i31X2Fz7PUpqrq9/+DV5JJTTd0vpjfXsdQyLmPbeTrLHhjb26/m2tpr9X/Sb Fh4+b0zNxcenPwCTa5lt1tbdtTLcqp+Y73+r6/8AMO25W32fpP0n6JdLdSy+mymwTXa0seASDDht d7m+5U3dE6Y6o1GmGOcXwHOHuNH7O9sO9v6n+i/9SJKchmV0e61tlPTrqc7IZW7EAZUHxbRbXXfW x9j8Wh9OLXbTZ9o/M9On3/oq1HpV/RcdjHspdZde+u1n6JtYaLKHDdVUHfoqsbEpuru92/1PUq/w lTFs39E6de4vcxzXlzXCxlj2ObtZ9nit9bmuY11J9N+xNZ0HpNgcDjtAfijBIaS0DHBJbQwNPsb7 vzUlOdT9ZMVmPQzCxSMep/ovaHVltdLKHZW+p1NtlVnpVsra6ttns/7a9Q4+stNWN6uTVaQyt+69 jAK33UsN2Tj0Nda6zd7La2b/ANH6tdlPrKw/6v8ATLGuFjbLC8vdY51thc82VNw7fUdv92/HYxmz /MTu6B0t9j7HVuPqFx2F79jS97b7/Sr3bKvXtZuu9P8AnElJ8HObmesPSsofj2elYyzbMlleQ0/o 3WN91V9aoXdfa36wUdLqfSWEmrIBd+l9V1b8mkVVz/NV11fp37P+1NH7ly1KManHNpqEG+w22Ekm XkBs+7+Sxqr/ALI6eccYxqmttxyNXO3G0uNzrXWbt7nOe7/0X/NpKaeN9ZsbKqbZj491jrXiuitp r3PO11zw5vq/qzqWV/p2ZfoPq/R/n2KLvrb0xtr6i2wOra42NO0Oa9lX2qyl9Rs9Vrm1t2eps+z+ v+h9berH/NzpW2Cyw2TJuNtnqkbfR9M5G/1vS9H9Hs3/APgil+wemRa1tbmVXNLXUtse2obtLPTo a70q3WNb79jP/PliSkLevWW5OPj04lrX2ZHo3i3aCxno/bPV9tjvzX1ez/1H6muqg6ZhjLGYGuF4 e6zdud9J7GY75bu27fSpq9n8hW0lKSSSSU//2QA4QklNBCEAAAAAAFUAAAABAQAAAA8AQQBkAG8A YgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBw ACAAQwBTADUAAAABADhCSU0PoAAAAAAA+G1hbmlJUkZSAAAA7DhCSU1BbkRzAAAAzAAAABAAAAAB AAAAAAAAbnVsbAAAAAMAAAAAQUZTdGxvbmcAAAAAAAAAAEZySW5WbExzAAAAAU9iamMAAAABAAAA AAAAbnVsbAAAAAEAAAAARnJJRGxvbmdHI0uGAAAAAEZTdHNWbExzAAAAAU9iamMAAAABAAAAAAAA bnVsbAAAAAQAAAAARnNJRGxvbmcAAAAAAAAAAEFGcm1sb25nAAAAAAAAAABGc0ZyVmxMcwAAAAFs b25nRyNLhgAAAABMQ250bG9uZwAAAAAAADhCSU1Sb2xsAAAACAAAAAAAAAAAOEJJTQ+hAAAAAAAc bWZyaQAAAAIAAAAQAAAAAQAAAAAAAAABAAAAADhCSU0EBgAAAAAABwAIAAAAAQEA/+EWMmh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBD ZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIg eDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3 OjMyOjAwICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4 bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0i aHR0cDovL25zLmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJs Lm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94 YXAvMS4wL21tLyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlw ZS9SZXNvdXJjZUV2ZW50IyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENT NSBXaW5kb3dzIiB4bXA6Q3JlYXRlRGF0ZT0iMjAxNC0wOC0xMlQxNjoyODozMyswODowMCIgeG1w Ok1ldGFkYXRhRGF0ZT0iMjAxNC0wOC0xMlQxNjozNyswODowMCIgeG1wOk1vZGlmeURhdGU9IjIw MTQtMDgtMTJUMTY6MzcrMDg6MDAiIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHBob3Rvc2hvcDpJ Q0NQcm9maWxlPSJzUkdCIElFQzYxOTY2LTIuMSIgZGM6Zm9ybWF0PSJpbWFnZS9qcGVnIiB4bXBN TTpJbnN0YW5jZUlEPSJ4bXAuaWlkOjEwN0MwRkQ0RkIyMUU0MTE5ODY1QjgyMDYxRUIyNkNDIiB4 bXBNTTpEb2N1bWVudElEPSJ4bXAuZGlkOjNDRDI3QzlERUUyMUU0MTE5ODY1QjgyMDYxRUIyNkND IiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6M0NEMjdDOURFRTIxRTQxMTk4NjVC ODIwNjFFQjI2Q0MiPiA8cGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8cmRmOkJhZz4gPHJk ZjpsaT5hZG9iZTpkb2NpZDpwaG90b3Nob3A6MGMxMzZiYWMtODYyMS0xMWRkLWJjMGYtZTgwNGFm YjAzOTg4PC9yZGY6bGk+IDxyZGY6bGk+YWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmRjOGY5ZTk4LTE2 Y2QtMTFkYi05Mjg1LWJjYWM2NGZhNDExNzwvcmRmOmxpPiA8cmRmOmxpPmFkb2JlOmRvY2lkOnBo b3Rvc2hvcDpkZmUwYWM3ZS0xNDIyLTExZTEtODE2ZS05ZWM3Nzc3ZmE2MzQ8L3JkZjpsaT4gPHJk ZjpsaT51dWlkOjJBRUY5MjNFMUJDRUUxMTFCRTVCRUJERTMyQTJDOUJGPC9yZGY6bGk+IDxyZGY6 bGk+dXVpZDo1QzhCNjgyRDdDQjlFMzExQUI2MjhFNDU2RTA5QTM3MTwvcmRmOmxpPiA8cmRmOmxp PnV1aWQ6OTM1NjI3MUVCRDRDRTExMUExQUVGM0FFNjQ4NURCNDY8L3JkZjpsaT4gPHJkZjpsaT51 dWlkOkM2NkM4QjBDNDFBNERFMTFCQTdGRUU1NDMzRDA0RjZEPC9yZGY6bGk+IDxyZGY6bGk+eG1w LmRpZDozRDkzQzE0RjJGRDhFMTExQUJDRkM5OEYwNTJCNkNDODwvcmRmOmxpPiA8cmRmOmxpPnht cC5kaWQ6NDU3NDIxRDMzODdBRTExMThBM0NDQTBDMUQzMTgwNEM8L3JkZjpsaT4gPHJkZjpsaT54 bXAuZGlkOjgyNTI3NzhDQTYzRkUyMTFBMUE1RDM2ODFGNUYwRDFDPC9yZGY6bGk+IDxyZGY6bGk+ eG1wLmRpZDpBNEU5NjVBNEMyMjYxMUUwOUUyMEFGQ0E1NTUxNDNCRjwvcmRmOmxpPiA8cmRmOmxp PnhtcC5kaWQ6QTdFNDhDOUVDMUQzRTIxMTgxRTA5RTEwODQ2NTM2QzU8L3JkZjpsaT4gPHJkZjps aT54bXAuZGlkOkMzN0M1Qzk2QkM4N0UyMTE5NjkzODdFMUU4ODY0NkQ5PC9yZGY6bGk+IDwvcmRm OkJhZz4gPC9waG90b3Nob3A6RG9jdW1lbnRBbmNlc3RvcnM+IDx4bXBNTTpIaXN0b3J5PiA8cmRm OlNlcT4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImNyZWF0ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9Inht cC5paWQ6M0NEMjdDOURFRTIxRTQxMTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49IjIwMTQt MDgtMTJUMTY6Mjg6MzMrMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hv cCBDUzUgV2luZG93cyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3Rh bmNlSUQ9InhtcC5paWQ6M0REMjdDOURFRTIxRTQxMTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0Ondo ZW49IjIwMTQtMDgtMTJUMTY6Mjg6NDQrMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2Jl IFBob3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0 OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6M0VEMjdDOURFRTIxRTQx MTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49IjIwMTQtMDgtMTJUMTY6Mjg6NDQrMDg6MDAi IHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6 Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNl SUQ9InhtcC5paWQ6M0ZEMjdDOURFRTIxRTQxMTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49 IjIwMTQtMDgtMTJUMTY6MzY6NTYrMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBo b3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFj dGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6NDBEMjdDOURFRTIxRTQxMTk4 NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49IjIwMTQtMDgtMTJUMTY6MzcrMDg6MDAiIHN0RXZ0 OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6Y2hhbmdl ZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0iY29udmVydGVkIiBzdEV2dDpwYXJhbWV0ZXJz PSJmcm9tIGFwcGxpY2F0aW9uL3ZuZC5hZG9iZS5waG90b3Nob3AgdG8gaW1hZ2UvanBlZyIvPiA8 cmRmOmxpIHN0RXZ0OmFjdGlvbj0iZGVyaXZlZCIgc3RFdnQ6cGFyYW1ldGVycz0iY29udmVydGVk IGZyb20gYXBwbGljYXRpb24vdm5kLmFkb2JlLnBob3Rvc2hvcCB0byBpbWFnZS9qcGVnIi8+IDxy ZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDoxMDdD MEZENEZCMjFFNDExOTg2NUI4MjA2MUVCMjZDQyIgc3RFdnQ6d2hlbj0iMjAxNC0wOC0xMlQxNjoz NyswODowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBXaW5kb3dz IiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDwvcmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8eG1wTU06 RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDo0MEQyN0M5REVFMjFFNDExOTg2 NUI4MjA2MUVCMjZDQyIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDozQ0QyN0M5REVFMjFFNDEx OTg2NUI4MjA2MUVCMjZDQyIgc3RSZWY6b3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjNDRDI3 QzlERUUyMUU0MTE5ODY1QjgyMDYxRUIyNkNDIi8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpS REY+IDwveDp4bXBtZXRhPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDw/eHBhY2tldCBlbmQ9InciPz7/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlu bwIQAABtbnRyUkdCIFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAA AAAAAAAA9tYAAQAAAADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABFjcHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAA ABRyWFlaAAACGAAAABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAAC xAAAAIh2dWVkAAADTAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNo AAAEMAAAAAxyVFJDAAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHly aWdodCAoYykgMTk5OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJ RUM2MTk2Ni0yLjEAAAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVog AAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpY WVogAAAAAAAAJKAAAA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAA AAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNv bG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNv bG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJl bmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5j ZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHZpZXcAAAAAABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAA Vx/nbWVhcwAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAA AAAAAAQAAAAABQAKAA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcA fACBAIYAiwCQAJUAmgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwEN ARMBGQEfASUBKwEyATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB 2QHhAekB8gH6AgMCDAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLg AusC9QMAAwsDFgMhAy0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0E OwRIBFUEYwRxBH4EjASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXV BeUF9gYGBhYGJwY3BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H 0gflB/gICwgfCDIIRghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woR CicKPQpUCmoKgQqYCq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcM wAzZDPMNDQ0mDUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+z D88P7BAJECYQQxBhEH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMT IxNDE2MTgxOkE8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbW FvoXHRdBF2UXiReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwb FBs7G2MbihuyG9ocAhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+U H78f6iAVIEEgbCCYIMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwk qyTaJQklOCVoJZclxyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoC KjUqaCqbKs8rAis2K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv /jA1MGwwpDDbMRIxSjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3 NnI2rjbpNyQ3YDecN9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9 Ij1hPaE94D4gPmA+oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RH RIpEzkUSRVVFmkXeRiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JM KkxyTLpNAk1KTZNN3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRC VI9U21UoVXVVwlYPVlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZd J114XcleGl5sXr1fD19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9 ZpJm6Gc9Z5Nn6Wg/aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9Fw K3CGcOBxOnGVcfByS3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pG eqV7BHtje8J8IXyBfOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOF R4Wrhg6GcobXhzuHn4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBu kNaRP5GokhGSepLjk02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByc iZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjE qTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2 AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NY w9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzR vtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A2 4L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070Dv zPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t ////7gAOQWRvYmUAZEAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAgICAgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCADGAKADAREAAhEBAxEB /90ABAAU/8QBogAAAAYCAwEAAAAAAAAAAAAABwgGBQQJAwoCAQALAQAABgMBAQEAAAAAAAAAAAAG BQQDBwIIAQkACgsQAAIBAwQBAwMCAwMDAgYJdQECAwQRBRIGIQcTIgAIMRRBMiMVCVFCFmEkMxdS cYEYYpElQ6Gx8CY0cgoZwdE1J+FTNoLxkqJEVHNFRjdHYyhVVlcassLS4vJkg3SThGWjs8PT4yk4 ZvN1Kjk6SElKWFlaZ2hpanZ3eHl6hYaHiImKlJWWl5iZmqSlpqeoqaq0tba3uLm6xMXGx8jJytTV 1tfY2drk5ebn6Onq9PX29/j5+hEAAgEDAgQEAwUEBAQGBgVtAQIDEQQhEgUxBgAiE0FRBzJhFHEI QoEjkRVSoWIWMwmxJMHRQ3LwF+GCNCWSUxhjRPGisiY1GVQ2RWQnCnODk0Z0wtLi8lVldVY3hIWj s8PT4/MpGpSktMTU5PSVpbXF1eX1KEdXZjh2hpamtsbW5vZnd4eXp7fH1+f3SFhoeIiYqLjI2Oj4 OUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6/9oADAMBAAIRAxEAPwDf49+691737r3Xvfuvde9+ 691737r3XvfuvdYp6iClhkqKqaKmp4UMk088iQwxIv6nklkZURB+SSB7siM7BEUlzwAyT+XVJJI4 UaWWRViUVJJAAHqScDooHenzY6x6O2vujdjbU7V7Ow+zcY+V3LlusNi12a2phaVZFgByG/stNgti CQTuqvDBkaipjB1NEB7HnLft3vPMd7ZWIvbKzuLh9Ma3EwSRzx7YVDzcOBMaqfJuod5697+VuR9q 3Td/3Tu26WdlHrmksrVpIIxWnddSGK1rWgKpM7itSvQd9FfJv5HfKfZW3u1uouounNm9WbjesbGZ nsft/Nbg3fVQ4/IVONrYanZ2w9iTY7B5OnqqV1enqcy0iEcjkezbmXk7lPkrcbrZN+33cLje4QNS QWqJECyhgRLNMGdSCKMsVD0HeQ/dD3H91tk2/mzk3lLZbTlO5ZtEt3uEs07BHZGBt7W1KROGU1V7 io8xno5GDpO0vEr7lz2wmqCvNPgdq7gjgRiDx91kd3zSzBT+fFHf+g9gC5k2TVSztbrR6vKlf2LE KftPUx2MPN2iu57jt3iekVvNQf7Z7kk/7yvSkji3Imoy1uEnuQVCY2updItyCxytXqufzYe0ZazN NMUg/wBsp/59HRmibstddxbt9kbr/wBZG6eV16F1hTJpGoJfSXtyFLc6Sfpf2nNK44dLxq0jVTVT y9fl0z/x6kikMWQiq8SwYKsmQh8dHIT9NGRiabH3Y/RTKrn/AFPtR9LIw1RMsg/onP8AvJo38qfP pD+8oI2KXSPCa8XFFP2OCU/IsD8unoEEAggggEEG4IPIII+oPtN0YAgio4dd+/de697917r3v3Xu ve/de697917r3v3Xuv/Q3+Pfuvde9+691737r3Xvfuvde9+690GNTv6ozmRrMB1zRU246/HVclDm tx1ck0Wy9uVcPFTRVOTp1aTO5ymayvj6Eu8LnTUy03BJym1pbRR3W7yGGJ1qkYoZpAeBCn4EPk70 qMor9BWbmGW/uZtv5ZgW5uI3KSzMSLaFh8SlxmWVeBiiqVOJXi83WDY1HWPHV7uq5N45BDrVcnDH FgqSS3P8N23G0mNgCkDTJP8Ac1ItzMfbDblJGDHYRi3iP8Jq5/00nxH7BpX+j0qj5fgmZZ95mN9c j/fgAiU/0IBVF+RbW/8ATPU3eu3Nn7p2duLaG+aDE1+ytyYTIbd3Disu0UGKrsJlKOShraCoLvCs UUtLKygqysnBUggEU2y53G03G0vtreRdyhkWSNkBLB1OoEUrUgj0NfPpRv22bJu2x7ns3MEEMmxX Vu8M0chCxtFIpRkJqKAqSKggjiCCAetfDFYPt/8Aladl53OdFZw/IL4kbnypye6tgJWyVG49nqfH E1fJJBBLTUWboKRViXMUqyUeRgiVK+GF1hkTLeWPZ/ezZLaDmixO0c9wR6YpytI5fOlCQxRjkxNR 4yaxMwLA8vpz7gfc45r3HeeQLo80+x11N4l1aKxae0GAXOlSEkRaKLmMNDKi6biOMiMrbZ1j88/j 925t2HcOy8pnq5BHGcpiJsXTU2cwNS45pMxjZMkJYGVrhZUMlNLa8cjjn3Bm6+z3OWzXTW19FApr 2sHJRx6qwTP2GjDzA6zT5E+8/wC1HuPs6bxytuU8ygDxYiirPAx/DNGZKrnAcao34o7DoVKT5KdV VLhJ8pksdf8AtVuJqig/4M1GKwAeyaX255ojBKW0cn+lkWv/ABrT0PYfdjkyVgsl5LF83jan/GdX Ql7f7A2TuohdvbpwuUmb6UtPXQit/wBjRStHVj/Yp7Dl/sO9bXU3+2TRJ/EVOn/ehVf59CzbOZ+X t5IXbN5t5nP4Vca/94NG/l0r2UMCrAMrAqysAQwIsQQeCCPZRwyOPR4QCCCKg9M0+MnhVpMLUrj5 v1CmljaoxcpHOmSkDxvT6/prgaMgm5DWsVKzqxAuU1r6jDD8/P7GB/LpDJZyRgtYTCKT+EjVGftW oK/ahX1IPDqNjtwCatGHytJJiM0UkkippGM1FkoorGWow2REccVfHGpBeMrHUxDmSJVKsbTWumP6 iCQSW1ePAqT5Ov4fkcqfJiagNWu5eJP9DewGC/oSFJqjgcWiegDgcSpCyLxZACCVH7SdGnXvfuvd dG9jYAmxsCbAn8AkBiBf/A+/de679+691737r3X/0d/j37r3Xvfuvde9+6910zBQWYhVUFmZiAFA FySTwAB79xwOPWiQASTQDoCXqs13PUvTYityO3OoqWpkhrM9j6iXH57tFoGKS0e3K6Ax1mC2D5VK y5KF0rMsARSPFS2qakTBLfl5A08aS78wqEYBktq8DIpw8/pGQUi/0QM/YgBMt7zvI0dpNLbcnKxD SoSkt9Q0KwsKNFaVqGmUiS4/0EpDSSUXaen2/tDBRU1LDjNu7dwlGsUEEEdPjsZjaOEWSOKKMRwQ RLfgAC5P5J9kf+Objd58Sa9lb5szMf2knoYom3bNYLHGsVttsCUAACRoo4ADAA/y/PorPYfybjon nx2yqZQELIc/k4Tpe3GvHY6QLdRbh5/r/wAc7c+5R2D21aYR3G8ycf8AQkP/AB9x/gX/AHrqG+af dxLYyW2wRAAY8aQcfmiH/C/+8efRNN19qZHM1D1eczVXk57tpatqWkSL/CGEkQU6f4Iqgf09zBtf K9vaRiKys0jT+iKV+08T+ZPUB73zxcXkrTbhuDzSDzZq0+wcF+wAdBTlO0aBVbTWRpMisNBkA1rY ggc25H1/3nj2KLXlmeorCSh86dATcOfbIBqXaiYDhXj/AKv+L6JLvzGbBXcLbz2LlZesN9wu8rZT bbLR46vdzqlXJ4eMpSslS3+cMYCSfWSOT3Ju17Zu0lqLK9g+r28j4XyR6UbjjyrkeRHWH/PuycnH eX5t5I3x+WueEJPjWxCwSkmpE1uCFo5+IoAr8ZI5OpuC+T2aptOL3lHRz18Q0LncFIJMfXqvAlmo lPko5X+raBov/YQe6XPIccR8VY3jgJ/EOHy1cP25+Z6KNo+9TumySpsvuXZxR3QOlb61Ou1m+bot WiY+dBTz8OMdKIfJfDpKp/iMccsbBlYS+OSM/UMpBV0PHBHt9fbm6li1JCXiYeQqD/kPUhx/eJ5d k0SxbrEQaFWDj9oIPRkesf5iu6tlzU1PUZyn3dgkKLJhtw1bVEyRCylaDMkvkKN1X9IczRA/7rPu POZfu9bZvCSSR2LWl8eEkS0Ff6UfwN86aW/pdTHyX98272OSKGTd4r/bRQGKd9Rp/Qly6n0qXUfw 9W19D/Kfqb5AUvh2nmoqHdVPB58jszKzQRZunjRQZaqhCt4cxjkJ5mpy2gW8ixkge8U+efa/mrkK XXutmX2tmolwgJjJ8lbzjf8AotSv4Swz1nv7W++nIHuzBo5e3RE3tF1SWkjKJlA4slDSWMfxpWn4 1QkDoddxbfx+58RV4bJfcpBUqDFV0FTLQ5PHVcZ10mTxWQgK1GPydBOBJBNGQ0bqD9LggO0upbOd LiGhYeTAFWHmrKcMrDBBwR1Ku5bdb7rZzWVzqEbDDIxV0YZV43GUdD3KwyCOgu6l31msv/efZu8Z YqvdvXm6KnZWbzFPDFTR5edMXi9w7fy1XRQ/tY+o3NtHO0NcBH/k/nlmhTS0OknW+7bbwfR7ht6l bG7hEyISTpGpo3UE5YRyo6Z7qBWNQ1egnyfv99dndNk3pw+77bdm2klACiQ+HHNFIyjCNPbyxSin YWZ0FClCNnsOdDrr3v3Xuve/de697917r//S3+Pfuvde9+691737r3RHe6e7abL/ACe6F+ItFEz4 zsnG7/3z2fXCQxJV7U2Ht+oqcfsWlkjdZXO49xT08mUtZTjaWSlbUKmQJI/LvLrwcm8z89yGk1m8 ENsPSSaQBpjX/fceoR+fiMHxoFYK5354ivPdDkH2fhWtpuaXVxfNWmqC2hd0tVI4+NKFM/l4KNEa iVwpzMlkcZtzFvV1RSkoKKOOGKGCMAn9MNLRUdNGBrlkbSkUaD62AsPYCtra4v7lYYQWmckkk/mW YngBxJPU0Xd3abXZtPOQlvGAAAPyVVUcScBQOq2++u8spWStR5F2xBLNNSbe8qFsJQqzLTVOVMbN HPn8io8g5K00BATlizZF8i8kWsSCa3Hi4o0tP7RvMJXhEnD1dsnAoMTfc33JunYwXT+AclYa/wBk n4WkpgzScfSNKacsSSNdg984XFU2MbMSxmhyOONS1XSlY62GaGsrMfPPGCwhnMctIbxkAMDa4Nj7 m3l/kW9upLoWaHx45NOlsqQVVgD5iobj5enWLnOvvHsuz29k+63Cizlh1F1IDqQ7xswBNGoUytBU GlQeiV9pd55XEQwV+MmXM4DKaxitw492bGVLLy9JOf8AO0GTg/3ZTShZFtcXHPuZeWOSLS6aSC7X wL+KmuJ/jX+kPJkPk61B+Rx1ij7ie8u8WUcF3sy/W7Lcg+DdRn9FqcUb8Ucq/jicBhxyM9FGz3dm 58k7t/EWp1JJAhYhh9foxJNx/X3Kdpyps9ooH04Y/PrHPcufudN5dmfcWiQ+SYI/M9IWr7HqsgPH l6uoqhyFqVlYVEV/9jplF/wf959mC7bBanVZRoh/hp2n/N0WGW+3IBN4nlm9H1HUP8hHSfqM3PH/ AJXRVbVUSnUJoJHE8J/5uxgiSMj+v09vieGQGC5hCk4KsAVP2VwempOVS8bPEBNbnjip/wBspz/k 6cqTsehq1Wl3LR/fwAaUyNIy0+Vpgfo2oFYqoA/htJP5J9k0mySWjtcbDd/TyE1MbVaFvyNSv2j+ XQXuOTLm3ZrjZbjwZeJjerRN8qcV+0Vp8un0Y2fIU75HZuWi3FRxjVNSRyCmzVGDzpqKGQqWI/qL X/APvycwi3kW232zNtOeD/FE3zDCtPzrTzPRYL9bGZLTmCyeyujwfLQv81ccPzrTzI6asN2bu3ZG 6sDnsLns7tnce2aqbJYquoKqrx+XxuSURwQS0jK0U8c2mRh/RlJBupI9mV5tey75t9zZ31lBdbbc JpdWVXR1PEHiCP8AAcjPUh8u7lzDsNxbb7ytv1xbblBNHJBPBKytGyktrR1OOGc5FQag062YvhP/ ADTdidmbCy2I+R+4sDsHsTYm3KrP1u46qSKhwe/NvYxP8pyGOp4kCx7xpgAtTi6ZGNXI3ko0ZS8U POT3p+7funKu7QbnyHZzXnLd5OIxEKtJayue1HY8YG/BKx7B2ymtHftH92777fLXN3K9/tnvHvNt tvNu1Whma6ekUO4QRjukjQfDdg4e2jBMx77dMtFEcb4nY7dm7aHt7vbfe38htOX5D7+pd2bU2VmI mpM1t3q/bO0sBsfr47gpAxbH7l3BicC2XqoQxamNckZIeM2hHnuSw2+XYeWNru0nG02pilmQ1SS5 kleafwz+KONn8JTTu0E8D1kr7Kxb3zBZc5+43Me1y2R5n3IXNtaSjTLBt8FvDa2XjLXsnmjhNzIo NU8VVrVTQ2dHO6zS4+oLGenRZIZXIJrKRjpScHi8sTeiUfhrNwHX2A5FBUSr8JOfkfT7DxH7PI9T TBIwd7WUnxFFQT+JfI/aODfOhwGHTj7a6V9e9+691737r3X/09/j37r3XvfuvdMmfyFTQY8jHqkm Vr5o8diY5QzRGvqgwSedV9TUtDCj1EwFiYYWtzb2ptYkll/VNIFGpvXSPIfNjRR8yOkG5XMtvbUt gDeSMEjB4a24E/0UALt/RU0z1Sj/ADFWy3xg+S/wn+W2MgyGR2hsit3B1rvyWMPLVT0WfqKvJ5mS ocDxy5Xc+Cz2cqEvYPVUo4Fx7yO9oo4OduT/AHH5DmZE3C5RLiAcACgCpTz0xvHCp/ot1gD96vcb 32Y9zPYX3ot4pZdgsJ5bK8IqWKyl3lr5NLcQz3brXBkjr6dGF7Y+VuGzGdl3rgszFV9V7Boo6/Hz UcqCDfGTzdFJBjBTSSKRoyvnP27lS0FJDLNYM1h7lL2wuoNvi2q6tCOZNxajVGbeNGDMTT+Cg1Ct GdkStBXofc9++u1XN5JzPt25q/JG1xCRGQjTePMhEWknFJdXYSKpEryUBNOqtflZ8g8V2HR1PZ/W AnlxuP8A4ftzfWMnRIcptvLyiT+D5eujp5p4qnCZqImlhq0IUVFN45ArOgOUPtdyBc8vSx8t8zlV nk1zWzjKTRiniRqSARJGe9kOdD6lqA1MAPf/AN7IOc7SfnL25DS2kBS2v42oJLWYg+DM4UsHgmFY 0lU08SLQ+lmQGtrfe+a/ObG2dka2reWWnzm9cRJ6zpCIdvZmBLA/QPmZbX9z/tVhbbbvO729vEAj Q27j7f1Yz/KNesPN8n3PmTlblm+3K4aW4S6vYjXgB/i8yinpWZ6dA9iu0cjtpquCP7fJYXJKseZ2 /kg02KykK/pM0Vw0FZEOYqiIrNE3INrgmm4bbb3/AIUjVS8j+CVcOh+R81Pmp7SOI6d5anv9mE1v Giy7ZPiWCQaopAPMr+Fx+F1oyngeIKf3DNjMjTT5zZdRPU0MamXJbfq3EmcwF/1E6QBlcWpPpqIx qUcSKDc+621xdIwt79R43k6/C/z/AKLeq/sx0bXWxbaGW4sWKW7n4H+JD/Dq4MP4Tgnzz0EFRun6 2l45/tX/AOK+1+tfXpVDsX/C89Ny7vmgkEkFQ8Ui/R0cqf8AWP8AUH+h49tSeHKpR0BX59GcGzPE weOob5dSxvOirDbIKaeU/WtpAFuf9VPT30Pz9Stj7SFLiDNs+pP4G/yN5fnjox/dNvc4uYNMn8aj /CvA/lnpV7Xg3pla6Gp2PTZbMzxHVHX7cjqZXp+RxPLDYQc/qDnT/Xj2zPuW2tG8O6aI0plZaU/L 1+VM+nQX5p27l7ZbF25jv7JNvfFJnQavsRzqJ/0oJHlno0+FyqTUa4rt2s2ZBuVJFGPgnrMVU5JK TxAv/GmpDNQYusMlgoMkfkBsRqHICvY/Bl+p5Y+qWybDU1hS1fwcGYU44NPWnWPO47PdieXcfbqw 3V9iCapWWOZYq1wYtYV5Ep56WpTBpwacs2V29WYvcPWNTj3m27kqbK/dYSejyGRxmVx1XFksZPAr SVUbR09SgkEOk3I/Sykj2psprPcBPZ82iR45kKKsoZY2VlKPqFF7iMazwHmDQ9CXlLmK8sN02y+3 q5uLXebZ45LR5UKKrRvrDUZQC4cAhnBHkeGdv/4CfLzFfMLorHbxn+1oex9qTxbU7V2/ABCKDdFP TrJFl6SkJ8sGF3RSAVdMCLRP5qe7NTsx5m+9PtlP7Yc43G1wlpOX7kGazlOdUJPwM3AvCexvUaXo A4HX0pfdv96rX3u9ubHfpjGnM9rpgv4loFE4WomQf75uF/USlQreJEGYxEkyPatZLt7bi78pQxqN g1Ue4apFJUVW21Ipt3Uc3NmjO35ZqiMG6rVU0Lkege482ONbq7O2P8F0vhj5ScYiP+bgCn+izDz6 lXm+Z9u2xeYYQfF25xMw/ih+G4U/LwSziuBIiN+HoSo5I5o0lidZI5FDo6EMrKwuCCOCCPZOQVJU ihHQoR1kVXRgUIqD1z966t1737r3X//U3+Pfuvde9+690nIwa/ck8rKTT4CkSlguPS2TyiJU1jjn 9dLjlgVT/Spce1Z/Ss1UHvlap/0q4H7W1f7yOixQbjdZHI/StkCj/mpJRmP2qmgA/wBNh0Rr+Zll djn4x57ZO76OnyFdv/KYzE7UjdddZjM5jaiPLxbjx6i0pqcR9sEAUjyNUCJrpIymZPu/7Nuu5c/2 19t8rR29lC8kzDgUYaBG3lRiamvAIWFCARi999HdOV4vZPd+XeYoUkuN2mjhtQcvHMhEgnQDJaPS FoCNXiCM1VyDrOz7q35jtmS9M1tfAuO2xncsVSlmSVo8mdFFPFLXQySLV09Aadkp1v8AsrJIo/VY Z+bJHtFjuzb7dWrm6khTSSD8GWFFNKa9QavnRa8B1wU3n3I5l2PYbz2r5gvym17fdzEeFR28XCFD IrUdE0nw80QNIoIDUCa2Tid67SzZzFHNgs1jclR1OG3TtXIy1sWP3TtrIhUymErZhTusZlRRJBNp 1U1THHMhDIPYl3zmDZ98tBaPBcQzxuJIZlCloZV+CRRq8uDLWjoWU4PQK5K94Nr5K3n6mTbp5trm jaG6hbSY7i3koJInXUDkUZGHckipIvco6CHvnb6ddbep8ZRVklZt+u33lsttasqWjFc2Kr9uYXy0 GSjQkJlcRPSCCoKjxysgljJRxYy5Z3l95vHuriMJerZokoFdOtZJO5a/gcHUvmK6TkHqfYjydvXL iyck72l9sv7weRK9s8SyRRfpXERo8ciaNJNNEmnXGzKRQl2S3IRq/c/259jNpMfLpVZbLXT2dJ/G 5zP12ShXa1PmMjlke1PHgaOtyFdrPGlYaCKeQhr2IIIYcEEe0k88US6p3VV9WIA/n0dXW3bbY2ck m9XEEFiR3NM6RpT5s5Ufz6Eyv673ZlKT7/d9Jgupso+grVb53Bhdq0ObZ2ADfwCprG3DSVr3uTFR tG5/APtAd7sJKrbu8s3pEhcH/bUCj7S1OgPa84cv2Nx9Ly9cXXMFiK9tjbzXTw0zTx1QW7oPINMG HqR0ichjesNp1j0G69/7l3TlobNJhet9n1ENK4P6dO6d5vi4ZIH/ABLBj50I5BPtia83MGn0aQD1 mcV/3lK/8eHQq26fn7maBZ+WuTLSzsmwJr+6DuPttbISsCP4XuIz606k0vZ2y8FEKzA9XbXw9NG7 JDney81XdgZ6qmjsSmPwEQw+3RUL9WLUMkUN/UTwCmCXFypafc53j9IVEan5BzVj9ur7fTpVN7Zc 17i/0/MPuBctKRVoLCOOwiVT5ySDx7vT6DxVZ/IDJDTmfkhvLMkQ1G6sq+NQGODAYcU21tswRlSm kYnCwUkNQQp+roLn8Ace6rtNs2rTaRxE/iJMsn+9tw+dOjnZPaPkjlmVbyy2CO43UZNxODPKSfPx JzLIPlQin29Z5d24ur2/STV001BPW1BkpmDLKqGRdLGeIBXceJAwYjgOCPqD7MIbS5sIxPE6yOT8 PA0xwPkaf4ejS4ji3TcprBonSGJRVhkVHAf6WppQeanhnrrEbnzW2aiLJ4jIy0308dfjprwSof8A dc6DVG8bflJFKn/H26ZrLcka2uYgT5o4yPmPP8xnoPb/AMl297bvDuFnHcWh9RUfaDxU/MEH59WS /B352dl9E9r0eV2JisPX7h322E2ZmcFXRmPb2/kqsvTw4XHZDTUUr4bMxZKr0UdfHIRTtO6svikk jeHPdf2r2Tm3lyS33G7kWytNc6MDWS3IQl2TB1oVFXjI7tIIOpVINPZDmn3Q9g+cRuPtWy39nfmO Cbbbk1S4BkGhUeq6JFYkRyalZCzA61Z0a2T5L/znd0S0We602v8AH3+765Ham5dldl0PYmbrKbcu D3RkaHJYDN4nCQ4mCOGnj2/UuR5q2ITTyKUempytzjNyj93O0je23q85rE2meOa3a3QGN4lKyI7l ia+IPJDRRQh3r1lr7gf3g1/uSX/Ke1e2L2TPaTWt/HfSMLiG5ZXhmiiEYXSIGxqlQO5BDQxEZu7+ MXenXffPVWz93dfZ+DLUuS2ft3PVlAzxpmMJLk3yuIrKHOUKSStQZCDc22cpA63KF6djGzJpY408 5ctbtyxve4WG62pR0uJEDZ0vp0sGQ0FVMckbDz7hUA1HXRf2q595b9wOUtm3jl3cVmhls4ZWWo8S IuZI3SVQTpcTwTqRUiqEqStCTF+wn1JfXvfuvdf/1d/j37r3XvfuvdUwbk+U/wDMO7j3hvna/wAQ vjdtzDdf7e35vTbkXenaNTHT4zd64Dc+Uwcea2lRZfJ4GjqMWaahjRZYYMwJTETdP0DIWy5K9qNg sNtvefebppN0ltoZPo7cEtFrjVykpRXYNUk0JipXz49YQb57q/eU5w3bfNp9lvbS1i2KDcLmL96X xAScRTSRrLAsskSFNKqKqlzXSfhPaKq/mDvb5kUvYo2/8ke0dvbj3Z1gcRJjqHZdNiaXB4fJ7roK LcDUdAaDbWAp6nJ0WMipZ6mSVZPDqhVXJYe8q/aLlzk5+XP3nyLYtabVuYkDmYu0siQM0WpqvIQj OXVApGrvJUAdc1/vL7/94W453Ox+5/Oltdb7sTwmFbVY1himuo0uNKeHbwq0scQieVnDaKxhWJI6 K5gIgQrG5Z2MrszFmd5GLu7sSS7u5JYkkk8+xtcTSzyvLPIWk4En5YA+QAwB5dc6t7nmlmmeaQtM SakmpJ86n16FfGxcL/gB/rc+0HUeXr5brLunbez9xYGop98Y7GZDAUQOUqTlS0dPQikR3at+6jki mpBDDq1OrrdSQbjj2/bXd5Zza7GR0nPaNPnXypwPSvk685jh5o2mz5X3R7Td7yeO2V14frOqDWul tSgkMRpYilQKjolGT3n8T9i7myGLz3S2UpMziqkwVEVfBR52jW1pIaqmpa/dE1HPTVULLJDIIyJI 2BH19iUy8x3UCOu71iYVx2n7CQoII888esyLv2Z+81eQtaw+59g0VSKpK8DHy+NLRXp/tusm4PkH 8ZNxUjY2XI9zbSxLR+NsTsOWTZuJCadJV6Pa2VpUmuPrrD39oUj3O3bWRbySV4yDxG/awPRVtH3c vvEbRcC+t7Hlbcr4GomvWW8lr8nu4iR/tadATUYz+X7WySzzbl7loqyUs0lXW02Rys+om5aR6rDZ RZTf8sG9qn3XfyAC8IT0HaP5UP8APqV7XbPvp7XGkMXKHKtxEvAK8Kj8lFxEB+Q6Urbd+GkVDSY3 Md19jVFA8QqcZi907XqppsXA91QxrR7LpaujpqiM3SKU2ZbOoAsfayPfd3t1RJtttZPMamJYfmX1 Cvz6IJbj73E9xcXVj7U7Wk4bTI9ndRokpHEEfWtG7KcFkFQaqxJqOkbVfHD4w7khkzmL+VObWhWR aWNJtjNURY1C5Wmofs6eioKikgjuFXVGoa+okkkl79+73KPF/dSMgNO2QY9BSpp+zoyi9z/vCbFI m17j93GM3RXUSt4QZDSrPrZ5FdjxNGNOGAKCDVfE7pHCTUtTV/Lba0EEjOaanz+1Wx0dVKkeuOOV m3BCzRIxUyKApK+m6k39ufv3coSpuNkYD/TjP8v29Xi97fdzco54IPu2bq0qgamguGkKgmhIH0xA JFQpqQDmhpTrPS/FHa2ZoZpcP8rOq82Jcn9ya1aMxoZRTmKenYRbglCuA6EKOFUAW+ntxeZLt0Jb ZJzVuINRw/0vSW497uattuoo9x+7zzJbFYNOg6iaaqq2bYVHxZ8ya149O1F8W5NvOrv8iuqzTyMA 8LMVjqE41Dw1GYVGYr9COf8AH2xccwJIoE2zzBxwNaEH5GnV4PffeZyfp/ZLmWnmPDZh+dID0r26 42Ng4Iwe4Nsyy07Ry002Lqscr01RA6y089II8tI0csEyhkNiQw9pId4m1F/3c7seOokggihBFMgj j1s+5nPG6Oo2/wBoN0goQV1rMpUg1Br9OtCDniOl9vPK1m65qjduQyD5ur3VLU7iqM86sP49U5Or qKitzCMQBIK6v8rFluuvUB9PZBaW8NlGthbxiOGACMIPwBQAqfLStB9lOo6v5d+bmLdL3mW0mh3q 7ne4lWUEMWuGMpbPxBi9a+f216uY/kQ9i9e7Z7F7g62ysWYoux+yaPC121cjI1Q+2s1g9j0eYyGX 27CqAU9NubHHMSV416jPRGTTo8LeTGT7zm0brd7ZsW7wGNtotGcSKKeIjzFFVz5mNtITHB6Vrqx1 F/u8+aOXbHdubOW7pZk5l3JI2hck+DLHbLK8kQHATIHMma6o9dNOnv2fPeGXXVrr3v3Xuv/W3+Pf uvdYKp2jpal0bQyQTOr8HSyxsQ1mIX0kX5492QAugIxUdNzErFKwNCFP+Dpj2ft6i2ntPbW2MaCK Hb+CxWHpS1tbw4+ihpVkkIuGll8epz+WJPtTf3Ul9fXl5N/ayys5+1iT+weXSHZtug2jaNs2u2H6 Fvbxxr9iKFqfmaVPzPWlx8+99ZPefyz+QTVGSWgxGF7R3XgY5aiR44UTAVi7eMhjT92pqZIcPGgU AnRGq8Ae+tHs/DYbF7YciW0NuZtzl2yCUogBb9VfFyeCLWQmp8yT59fO995rmO83v3790mPiS+Fv d1DHGnE+A/gVPkKrCo1NwVVHl0Wza3cu1cVJHisi2YehoqdIm3JNSxGnYxluaqmifz08QSwVvW7A crfknO6cu3rvJdqIVmlcnwVJJFf4TSjZqSMAeR6xn3T2p5n3pJ9x22G38d2LGHWV0g+kj0QsTWoq o/hJ8hWh+R/StFA0sm+6GQxrdqenosrJVtb8JTtQoWP+xt/j7IW2Hd1IDWTD5kin7QT0A4vYr3T3 W48C25WYGtNTzW6J9uoy8PsB6bfkHW7z3105HluoKmh3PtTKUrVu4kwjPU5vMYSALL4cRpbxzU9P PEwrqUAVZ06bWEinW3eBa3pF6pSdcLXgCfM/5Dw/l0J/YG25O5J92ZNu91baaw5otpPDtDPpW2hu GqtZieDupH00xYwd2okEo4pty266jt+nG3KsJD2Jtunel2rJVSLDLuHb1GCTtTI1EpVTlcNGrSUc jkaotUZNlB9yPZ26CMxwsKnPyYnjT7eukO6Rz8qbkm93kbPyzMQtwACzW0nBJwBUtE+FkAGGKsAa 06DzP9S9i4Z6L73HPXCukEMX8CnfJCKoYahBUrDGrwsQDZyPEbH1e1T2U66ax1r6Z6W7V7i8pbmt z9LuHg+CKnxh4VV/iWpoR8gdX9HpR0PW+68CqyQYmonzQs38RyFRTUmGwrfX/IhX1EMeUyUZ/wB3 spp4W/zYkYBw8LCSMV+nBk9SFoPsrxPz4Dyr0UXPPmzbmWR930bZ/vuPW003+n8MExRn+AESOPjK CqmMdlZRJJJ8vvTCUc8sjSTtJuGpytZJKxLO8i48VTSSsfqS1yfbLbbCxJmMOo8a0J/kD0rXncaE i2zZr+SJRRQIvCQAcAPEKAD0x0vOv6egwefFRS7yymRqPtKiGTx0tbj8VGJSkaPU1VZUqXJkISJS lmkcW59v2tht8UupUUtTyWg/M/4Pn0GebN85g3LaDDNtohg8RSKyiSU6akhUVTTGWIOFB8uhF3nk JZqGCiqKjH1ddNOsuKos5Uyx0s9VGrca4yGVjG5C6iI2YgH2oubCxdAslrEWrgMME/l0EuWNy3WC 6luYLy7jtVSkrwULqpp/FXzAJoCwAJHQRQdi71xiZfC1NFSY2sho62fHwU1ItDHRywwGR1+2RXWp DRI8iSavUygXIPBeLeBBJEbJFahoACKfl59SPJt1lett25Q73cTWzSIsjM/iFwWoDqNNNCQpWmAe AI6B2LJ7qrJ5Jp8zWvBEPJW11TKziKP8lpba3lf6KgN2P+8E88FlDRvpleZjRRxJP5+XqeAHUq28 xlTwo3EcAGdICgD7BT8vPoxvU9FJu/HZbdWcmm2l1ztSRU3DvTIoPtppBbw4bCJZTl915GwVKaEP oZgz24DE9xDNbSxQxsr3EnBB5etfRB6mnUZe4POljsMtnsGz2h3Dnq+FLWyQ1Yr53Fyw/sLaP4nk amqmlPMjaH/lu/C3oP5/fBCPdUMWd6s3xtfuHsHZuI3jiqls9Vtg8TT7fqsVjNxYLI1SY2upjj8s k7R070ssdXLI6zWkkD4ne7XufzP7Y+5jWSeFebPNYQSGFxoGpjIGZJFBYNqUirBgVABXAInX2w+5 3yV7ve0cG48zbxdQe5q7jOZ9yiJdWYpCfA+mdgn0sSlVhRDE6kFtYDupur+InwQ60+H2wqXb+Oyt Rv3dkm/4d9V2+83jafF1aZ2fC1OzKeLBY6kqKsYagg25l6qlEZqKh5fvJy7kOqpjlz77m7xz/usl 3NALWx+lMKwoxYaA4lJdiBrYyIrV0qBoWgwScxvZX7vfK/sjy1b7VaXjbhu37wW5a6lQRt4pja2A iQM/hoIZJE0l3LeK9WoQqnz9xh1kP1737r3X/9ff49+691Er0WShrUYEq9JUowXhirQuCFtzcg8e 3IiRLGRx1D/D0zcgNb3CkYKN/gPRN+6+xOyt+75x/wAYvj3lV2vuuq25i91dz9yGliyEfSHXWalq aTDUuAopw1HkO29/mgqlw1PNePH0lPNXzIVEAcfcu7VtG17dLzjzVB41iszR2lrXT9ZOgBYuRlbW HUvisMuzLEprqpDHPHMPM3MO9Qe13t3efSbs9qk+47jpD/uyzlLLGIlPa1/daHFujYiRGnYU0HrT A+VmCh2B8g+9dly5HOZHH7J7Y35tynrtwZKTK7jzC47cuRpqWqy2VnVZMhmclBEJ6upZQZJHZ7XY D31Y9vbyO85C5Pv7S2hjuLzbbeVhGulFLRKWovkik6USuAAowOuIXPfKEXLvuf7h7QZp5YLPebyI STOZJ5QlxIqtLIRV5HA1SORkktTIHRSMnQbq3CpNJjzS45NRjeqdMbjYF/46GSpZGlP5L2dj/X2M UtilWAJc8WPE/wCx8hgdIk3rZ7IpFcXY1DhFGC7fZRa5+bGvQay4fZVBl8dHurfuJqHbI0iS4jC0 9RkYJSahB9vX5MaKelpZD6ZGtcKT7owjBAeUeWBn+fQoh3Dma8sLttg5TnVRC5EszLGRRT3JFlmY cVFcmnQyr8wD0bvKmotp42DdtC8UUO5sFS5daDB0sUNQFjjokpqeppoNx00CtolQKI1IjlDA2Um3 zabHcY/DZQLlRhx+H5H+IfLy8iOo9m+703uty7Lc8x3z2F4CTbTtDrnYlfx6mVjbMxFUNdRq8ZU5 Y3EWxeofkph4u3ejn27idyeWd92YqXCYyhzM2UqqZ2+wz7Rr91g82sx1LPGzUlchJDEEv7C22bvf ct3SWe5RarMnBpXHqp8x6jiOoJ/rpz97O3re2nvCL242ZUVbK6WaWSOOJGFGiBOm6taYMbAT2xoA MeGSU9rQ5mgp9wbRphVUW68VJTyZbHJJU0WUpKCGbXUy09liapFkXUI2P7T6uQReTFvLe+tC+3zq 9QD2nNPP/iusjeSoLM3Gz8wXfhS8vXKt4E3bJBKzCi92QOJpqAIcaSAwIBYI8VPVEPUSTVDHnVPL JMxv+dUrOTf2i01yxJPU0PfxQDTCioo8lAX/AAAdPdJtuSeSOGCHVJIQEUAAfS7MzGyqirckngAE n24sRJAC9FlxvSRI8kslEHH/AFeZPkPM46dqvExJAuOpBqpUdZamcKR9/VqColN+ftoAxWFT+CXP qbi7LQaF+HzPqf8AN6dILfcHaU3lxiciir/vtfT/AEzcXP2KMDLJUYRn5fU9l03csxAH0UFieP6D 22UJ4r0Zw7mFwhAzXGOlLisfJLJjKXccM1TTGeKDEmKJ59w65WEa0tBEiyVFVSThtLI6kWJ034Ht O14GPhRqHK8WJoqf6ZvT5f4Oq3FvFbwXe4xXItkKFpFJARwMliCQqMKVElQMZ6FXMdDbO60p4Nz9 5V1didvAR1W1+nNvyq3YG65mjDody1igQ7TxMhsHqZytU8Z0xqjfUOGV55pY9oPjPWjXDD9NP6Kf xU8guPM16j2P3n5l59duW/aexhe5QlbjdJgfoLUVoWhU917cAcEWsStliy8Cx9t9mbi7JqMdSSUe P2rsvbKPT7M6+23G1JtnbFIQRqhhGlsjl50/4EV04aeZif0qdPtda2EdmHYEvcP8bt8TH/IPQDHU v+33JOzcmRXlwl1Nf8zXpDXl/cnXc3L+jN/ocKn+zhSiIKfERXrdl/4TSUtXD/L13PU1QIXIfJbs uelJB9cFPtTrjHu4v+PuqORf9dT753fevkV/c60UcU2mAH7TJOf8BHXUX7tcXh+3twwFFfcZWH/O KAf4QetgPI2MMA0a71+OsvIsVrqd9fH/ABzC6v8AYe8aovibNO1v+OnqeLr+zjGmv6if8fU1/Lj1 P9tdKeve/de6/9Df49+6910QGBB+hBB/1iLe/cM9aIqCDw6L78etpHCY3s3dWRXy7p7E7m7Jze4q 6VLVM0G2Nw1PWu0KIuw8go8VsjZOOhhjvoX1Mou7Eijmm++pm2eyixZWm3wJGBwBkQXEp+1pppCT x4A8B0APb7aPoLbmTdLgV3Xcd4u5ZnIyRDKbOBfXTHbW0SqOAyR8Rrp1fzdMXN1F85+7qGlxdMh3 bX4XsjHZGqjaUTQ7y29jKmumpo2sv7ecpKuIsDYvG3H199Pvu6b9HuvtBypIoBubaN7ZjxIMMrhB 8v0yh+wjrj996nkOay9/OdlubiQbZeSx3caL2hvHhjaQk+f6wkH5HPVLO9t5ZfKmT+I5OqqluSIX lZadf+CU0eiAf8k+5hmmdviboHcs8ubfYBPo7GNG9QO4/axq38+gXpq6+UevYB4cJA+WdTyj1MDp Hi6Y/j/KMrLCCPygb+ntIh1OXPwqK/5v506lKe08Lbls1NJ7thED5hWBMrf7WIOa/wAVPXrDg8Cs kS5TLyywUUsjsrIFNfl59ZMyUCOCukyE+WpceKIn+29kO0jqNch7P5n7P8p4de3TdjG5sduRXulA rX+ziWmDIR8vhjHc39Fe4Dh132Dvbr3ceO3JsTKS7ZqMcDFBQUeqbF1dHIytPRZqimJjzcVXpHma fU5IBQxlU01urO33GA291CDB5DzB9QeIPz8/sx1FvOHKXLPN+zXmy81WK30M2WkfEquK6XhcZgKV OgR0UDDBwW1Wm7a3j1P8ucRQYrdNJFsXuLE03+4qtpHQVbSxIS0u3a6coc5iXNzLjak/cRKToJF5 CCJrLduVJxe2TmSwrx9Pk48v9MMH5cOsH9y2f3A+7te3txs0h3n2vuXrNDJXQATQeMq1+mnAwl1E PDcgax/ofRWO0egNzbEyzCvx8QWod3iyFAjfwTLKG5rKCV1AopzcGalk0vGxuLggkd7RvFlvkeu3 IS7HxIf8K+o6njk33O2Lmra/qtov3kt0A1RyU+ptyeEc6CutfKOdKxuBSoaqgNkwwpY3pYkvK48d XMByQDc00R/EQI9Z/wB2Ef6kcnXh6Rp8/M/5OhM25eO6Tu36Yyg/5+Pz9B+EfPhNh2hPIiyzIlJA xAWaounkYmwWCK3lndjwAoNz7SySxKSkdXlHkvl9p4D8+lUd1Iy+JJIEh9WwKf4T0LmF6Gro8fFu PdVZj+uNrsA67m3rEy5SuS2rTtjZ8Z/imRqHH6GdUU/W/sOXO5rNK1rArXNz/vqE9o/5qS/CB6gd AbcvePZrK7k2Xk+wm33mUY8O3oYoz6zTmsMSjzJLsPQdQ8h2PtfrlKim6P29PDnpY3grO3d6wU2S 3rUB1KSnbOMdJMZtOnkH6WVHqNP1sefdl2S6vAp3mUCAcIIqiMf6duLn+XSCLlTmLnmaO99198Eu 36gy7VaMyWYpkfUy1Et0w8wSI68KjHRWczVZavqKvK5OrqsxX1sjfxmbLTzV02V1sWjnrJ6h3mkn QkoJL6lGkDjj2epGsMaxxRgRKKaQKCnlgdTjtsO32sNvYWNvHbWkQ/REShFioKFUVQFCnB00oc16 D+t2lFkkmnxkyxKLD7SqDeSGU3Ji86gq0Vv0uRyPr7baAOCyHHoehdbcwSWTRx3sZLfxpShHrp4g +o/Z19Az+SZ1N/oi/ltfHzHTQyxV+9aXdnZ1f54TBJN/frd2ZyuIqPGwDCObbf2LJfnQR75SfeI3 dN393OajE+qG2aO3H2wxIrj8pdfXW37v9hcWPtPytJdIFnuke4oM9ssjNFnzrD4ZJ/Z1aZVupqcd TksGlqJJrKLgpTU8jMWP4USun+xI9wxGDolbyAp+0j/JXqXJ2BltYq5Lk/kqn/KR04e2ulXXvfuv df/R3+Pfuvde9+6901UCLTVWSo1iihRqj+IQ+Ow8q14L1MjoOfK1ekrMfzqB+p9vykukMhYk00n/ AGvD/jNP2dI7cCKa6hCADVrFPPX8R+3WGJ+0dawv/CjroSq/hXSnyiw1E0lPjzWdNb8qIogft4ay Ws3RsGtqGTkQ/eHL0zSPwJJoEvdgPebP3Pub0R+ZuRrmWhel5ACeJAEU4Hzp4TADyDHy6wU++jyG 10/KnP8AawVMYNlcEDIFWltyaeQJnBJ8ygrkdafO4q95HZEDSO7hERAWeSR2CoiKOWdmNgByT7zd lYnHr1iPsVmigSPQRqKkngAMkn5Dieptftr+51DQUme8FZmMs38ZqcNBJIY4/CGp8bT5apTQftaQ yTO0UR1TzPbUqR6i+8QtkVJMyNkj/BX5fIcT9nSW13z+sd1eXW1a49ugHgrMwFTXukaJTXueiAMw pGgrQs+kc6RKjITipq380rKiA6USOONBaOGCKMLHBTxL6UjQBVH0HuqhnJLH/V6D5dM3Lw2kXgwL pjBJ8ySTxLE1LMeJYkk+Z6EnEYy+n08m3tUi17iOgXuF7TVnoVMBh6pqmnNAs4q4pEmgkpTJHUQS xENHPFNEVkgeJhcOpBU839qNCaSZaaKZrSlPnXHQH3G7EySxSIHjcFSpGoMDgqVIIYEYIIIPVnvR 29cx2JiMvsPsiLGbi/h+LgqFrauWM5WvpmmFLpyFLEtpKmk1KVrFaOfkawWOr3GfMm3W+zzW267M 8sYZyDQEIGpXtJ8j/Caj09OsLvdXlCH243Ha+ceT7mTb7qe4ZPBjykR06jQ1IVH4GBwyHIFFGnp5 yPxi2bVyLNiMrkMVUtKuqWWjx2R0wmQFljUxUmmcR+lZH1kHkg+00XOl+tRdW6ypTgGZamnnxx6g U6T2f3jOZbeNxe8vWErhO1k8SIhgPiIJkUgnJAC0/CR0AlVvDAbNyFZjevNsUtLnqCoqaCfeO73p 9xbnFTSzPTzvi6VlbDYe0sZ0+JHNh7HtvsVxuUMMu63+q1dQwhhrHHQioDH43xxqR1IP7l37m2CD ceeOYJp9umRXFpa6oLbSwDKJWr40uCKhio8ugX3GM1uKvmyu4MlX5rJTX8lbkamWqnsedEbSMRDE PwiBUH4HsQwWNvZxLBawLFCPJQAP5cftOepC2Y7bs9rHYbRZRW1mvBI1CL9ppxP9Jqn1PQeZDC2D WT+vFve2SnEdC+z3KtKt0g6/FqHYMtlIKuPyUI/of8eR/Qj2naOh/o9Cy0viQKHPEfb08dQdQ7l7 m7k6z6V2TSmfP9o702/tCll0l/AuYro6ety85S4hodv4wz1kzfRYYHYmw9hzmjfrPlLl/eeY74/4 nZ2zzN/S0qSqD5u1EUebMB1JXJGwXnPXMWycu2hP1t3cpElBUJqYAuw81UVZz5KCfLr6WuydoYXr /Zm0th7bpxR7e2VtnBbTwVKLf5Nh9u4ulxGNg9IAvFR0aA8c298Wtz3C53bctw3W9fVeXM7yufV5 GLsfzJPXc3atttdn2zbtosU02VrBHDGPRI0CKPyUDp2jLTZOoYraKjp46eNyBdp6kioqQD9dKRJB /sSf6e05osKivcxr+QwP516dWsl3K1OyNQoPzbub+QTpx9s9Kuve/de6/9Lf49+691737r3TTkV+ 3lpcokbO1IWgqNJIP8Pq3iFS5UA6xTSRJN/UKjW5Ni/EdSvCThsj/TCtP21I+0jpHdDw3iu1WpTD f6RiNR/2pAb7AacegW+Uvx72l8qvj92j0HvS0WH7G2vV4mmyiwrPPt7cEDR5Ha+56ONiNVXtzcNH TViLcCQw6CdLH2IuSuar/knmnZeaNuzcWkwYrWgdD2yRn5SRlkPpWvEdEXOvKu3878r7zyxuQH09 3CVDUrokBDRyAescgVwPOlDgnr5mHcfV27/jp21vvrHtHEHHdidU7nq8FuDHSB2oabK0c2vDzY2W RVGVj3DTeKvo51BgGOkE41sVC9f+Xd92zmTZtt5j2mcS7fcwrLGfSv4SPJ1YFXX8DKwORjkrzDy3 vGybjufKG4wtb3KSvDIPxMq4eQHFINJGhsGYslKRtVgjgqK3LVsuRyVTLW1tU/knqZ3Lu7n6AE30 RovCqLKq2A49moLOxd2Jc9F88VrYW0dlZQrHaxiiqooAP8pPEniTk9DBtra+Wr4Y6mkxtTNTM2la kIEp7g6TeeQpEAG+pva/txZoEYo8qhhk1x0CN0uGUH1PkMk/kKn+XRlOv+ra7OP5EQVlNTc1tVDO lJhKEKCWWu3FUiPHqyn9SQtK49tXG6W9uVEkwjrwFC0jf6SMZ+wtQdRBzdzjsnLi6dwuC1+/wQJ3 SsT6RrVz+wD+l0PdDjutNtJ4KzJ1e7apbasFs5mxWA8g+iZLc9QhyGSRTwftwB7bRN43BtVrai2h /wB+XHfIfmsQ7V+Wo9RHf8ye4G+Bl22wh2fbz/os413BHqkCnSp/5qselZFv3cJpxj9r02O2JiQw YUW1KZaSqmsbq1dmZRJlK2TjkmRQfyLezS25XsC3jbi8l5cU+KY1Uf6VBRFH5H7egXJyps/jG832 ebddwp8d02tR66IRSJB6dpp69CttDtHfFFVwNmal9wY4qsU0M8FLDWKL/wDAinq4IYWaoQfiTUrj g2PIK925K2Ke3kFkn093xDAsV+xlJPafUUI+fDoBcwci8sXVvIm2W4tL2tVKlmQ/0WRmPaf6NCPm MdSN99Nbf3pG269kzDF5GoDVFVjPD4qSqqbl3JhZkkoKwv8ArRToc8ra/JFtHMd3slwNp36piXCv xKjyyPiT58R59L+WPcneOX2i5b52t2ZFAWO4aurRwAc0pIlMLLTUvB9QFVK7klpMdXT4nKU9bRZW ml+3kggqJ5onnOkLHE5mVlZyw9LhdJ4J9ydHcW80aujVVhUEGoNfQ9TDbLdzwJeWskb2bDUCyqCF 9SKEEeYKkhhlcdJ3IYStcsSZKOPn9uSSOqqWH+1HQYof9gzn35ozQ+Q/b0a2m52qgAASP6gFV/w1 P5gdB1lcS0IezBz+WkU6z/wZgxv/ALb2ldKGnQxsNwWTTUUHyOP2U62Kf5CPwsq3zu4PmlvvEeGg oKXL7D6Pjq4SHrK2qL0G/N80gdVYU1HTq+Fo5Vusjy1448ak4Jfe59yYkhtPbLapwZiyT3pU/CB3 QQH5k0mcHgBCfxHrp39yf2unb6z3V3e3Ig0vBYhh8THtnnHyUVgVgaEtMCAUHW0NXVkOPpZquoJE cQXhRd5JJHWKCCJfq81RM6oijlnYAfX3ghFG0rrGgyf+LJPyAyfl10PuJ47aF55D2r+0kmgA9SxI AHmSB1xoKZqWmVJG1zyPLUVMn+rqKiRpZbf7QjNpQfhFA/Hvcr63JHwjA+wYH+z8+q20RhiCsayE lmP9JjU/kOA+QA6m+2+lHXvfuvdf/9Pf49+691737r3XRAYFWAZWBDKQCCCLEEHggj37hkcetEAg gjHQPdldw9cfH3Z1duztvdNNtDZuLqcbjqDN5CKvyEuTrMxUmkxO3cVjcVS1+Zze4Zan9mCjpYJ6 qoQKyqxEmk+2nYt15nvo7LZLMz37hmZAQoUKKs7MxVESmSzEKpqCRioT37mnYeRtqm3DmfcRa7TE VVJGDOXLmiRIiK0kkoOAiKzsoDAHuprX/wA3z417Z+f1NtjvH4y9I/JhO+tqUsGEyOTyfxk7J25t DtTYflQxirr904XBy0+7Nqx6nxldJTsaiiaSjc2+2MOWHsfzPde3L3HLXOXM+0jlWVzIFXcIJJLe alDRYnYGOTAdNQCuA/8AHqxL95brbef4U5i5L5A5nn5mjRY9f7ou4oriEHAMk0aEGPUWVghLLVKE hNOsPsnaLzbi/gVdn8dQT071tPVJ99T5LcMeQoHaKegGEnp6Wlx1RTyROJVkilkhMbKfV9M05buz htRc2m3a1IBDMO0g8G1AkEGopSta8eufXOfNu9bbZXU8u2XwuUcK0bxPbxIK0Ot6mRiDQUBQEngO jJ023IdqUcdY7Tb0qzMIaCDO5CixVDTyMrSCSs8tVCKtABZIIdINuRbn2XRXA3O4IlfwEAqdCs5p wooAOn5sfy6h6fn7dt8QbbbuNrgCEyywo88z5oRGQh8MZFXYMR5NXqe0vYmf8MORh+5x8JBpcTj0 xTYajUfpSkx9FLJAgUcAkM3+J9iaz/q/ad8c2icjLsXDn7WYD/N0HYLnlTYhM1g0a3T5eWZWaZz5 l5ZU1H7AQvy6WmJwuXiC/cbfkX6cnFzp/vMIQez2C82tiNG7p/zlX/KeiDcOY9vkroubVv8AbKP8 BHQm4ajgEtPDU44RyzOEihjjyBqJWJA0xU8Zmmkb/gqm3tbPcxxxFor8MAPVD/MdBC4uzfyiG0tY 5HYgYYgCvqdVB0ffp/oTP7ljp56LacVCkgQnJ7kqZJGAP5pMBjllqXt+BPU0p/qPcHc38/Q2LSRt uBNPwoAP2uxA/YrdZR+1fsK+7Rw3tztWuZ6Eu7FgK/woFqfzZfz6NxD8Q2p6VqzI5TP1lY0Dohij pMXiqTWB66fD0NOiStGRwamWpcD6ML39xFP7nC5cQiOERg1ySzH/AG5OK/0Qo+XU7c1fdK5Z5s2K Tbd8s5tdCY5UVUeB6YeOi+X4lcsrjDDzBFu4+r22llpsPurFUU/3SzSY7KikieDJwKQjyEspkWeP UBKpPkQkckFSZS5U5rWaGNo5SbSvctcoT5j5eeMHjg1HXOrmTkvnT2A5nPLHMjtNskpLWtzHXS8a mmpQSSNNQJrdqmNjVKqQXJbuTaVbjpKiox8E+SxxZnGN+7pf4hSoByKOaQk1UYtcRSHWPorH6e5b s+bNtcRW5vhq4VZHH/Gjj/eqfb07ZczcvbpOTKr21yxwwWkTH+koB0E/xKKeq9GG+Dfwe3F82u1Y sRRwZDC9S7SraOp7X3swaOTF0RYTJtPEa4Y4m3luCJCkMZDijgLVMgKrGksee9Pu5tntXy49y0yS 8y3Kstpb0yzcDLIK1EMRNWONbUjU1JK5h/dv9ht+95Oa4rQ20kHJ9myve3daqErUQwsBoeeahC8R GuqRx2hW3Xtq7X2Z1XsjBbR2xjsTs/Yux8DRYXDY6BoqHE4PBYilSnpojLM6pHFDBEC8sjFna7ux YknkruO4bnv+63m57hPJc7rdzM7sas7yOak0HqTgAUAwBQAdd1ds23Z+V9lstq26CK02SygWONQQ qRxxgACpPAAZZjUmpYkknrjgM9tzsGix+5Nt5ah3DthKieXFZfGTJWYfMVdLLLSGvxtdFqpcnj6S RHEM8LSQSy+tGOhW90ura72uSW0u4GivCAGVhR0BodLDirHFVNCBgjJHTdhf7dzDFb7ltt2lxtas THIh1RyMpK60YdroprpZSVZsqTpB6WPtB0dde9+691737r3X/9Tf49+691737r3XvfuvdMWf23hN zQUMGbxePyRxOWx+4MNJXUVNWviNwYib7jFZvHfdRSilyeOnu0UqWdQWF7MQVNtd3Fm0jW8zJrRk ahI1IwoyNTirDiDj9nSK+26z3KOFLy3SQxSrLGWUMY5UNUkSoNHU8CM8RwJ6l0NbJKzUtbGlNkIg xeJX1RVMKsFFbRknW9M+oXB9UTHS34ZqSRhQHjNYj5+YPofn/hGR6C8E7OTDOoW5Hl5MP4l8yp8/ NTg+ROtb87v5YtV8zPkh8pN9/GHF7I6k7K6twvWmE3HU1dLVUFF332jufAP2DuUVWRpp/wCHbLy1 JsvM4SnbJpRyNk66dvvHUBqhcuvbD3kj9vOVuTNu5xlub7Z72S4dACCbK3jfwI6KRqlUypKwj1jw 0A8MHCHB33a9kD7z+4fOs+wwW9p+4Y7VSjAiPcL+eL6l2kIOhfBt5IACUIklclyMsNZHsXrHuDqT fOR627o2lvLZm89vzaarbG7qerSppkdisdXQSO81DlMVVBb09dSSTUtTHZo5GHvO7lbd9g5g2yHd +Wry3ubCUYlhoQaeTUoysPxIwDKcMB1z+5y5SvuR91vtr3jYv3duYNXRkEZIJNCCBR0NKqykqwyp PThhofAVLoENvyVHP+JH0t7GCg0APDqItzk8XUA1ehdwmSSLQHy0tOvHop6ieEn8WaRD5Pz/AGdP tR4FrJXxoYyPmoP+EdR7uVk8hbRt4dvVlDfyOP216M/1RnNtPmKGHObgooqBeHGUr3jgIuP1vVuA RyfqfYO5psbNbKZrHb4jP5aEXV+VBXos5T5Uiv8Amu1G9bMv7v4trRQh4ceA6ui6J2p8ad0LQxT7 j2K1VIIwf4d2OcLVlja5Axu5sfKHJP4F7+8Oudr/AJx25pngsboRCvG31r/xqNh10z9s/Zz2N3KG 2E9hZRXBAzDf3Fs9f+bF3EQfs6PjH8bOrq2iZsDmeyaeHxMUnwHc3YU9KLJ+pVO5chSlf9ha3uFG 533+KYfV29mXrwks7cH/AKtqeskF+7v7dfTn907vzNAlMG35g3cr+Qa8kX+VOqmfmB8bd1Uu5I9w bO3JkNw4unxq0dTjt6blqa7NY+WCaaR5qLK5IGKooJxJqMbsjxyBjdgw05D+3vNMN7ZC1u7NI7gt UGJAqGoGCq8GHyqCKcOueP3nPuzb5ccxW/MPLfMl1uG3R24jaLcbySa4iKsxJjmmw0Taq6GZWRtR 7gw0kv6p6jx24u/es+qe/NyZLpTam/JoqtN3ZXGGmp6/EzrXDGS4fIZX7bGRUG48jj3oKfKv5qOn nbUyuFI9jDmnmG42nlvfN15ds49y3GzFDDHIG0v2lg4Srao1YO8QpIQNI0kg9QH7Vey237t7ncoc ne6O4z8vcv7i2r6mSLSJIjrEZieXTGI55EMMdz3wq51EMFI62Mdq/H/4w9ObewGwOu/kF3qMXXxV OY2v1x1N3NlavLZ6OukkmqcxQ4bq+ipc1W0tZUIRLk5nWlSwElQiINOGG78689817heb3v8Ayztr 3i6Ulubu0UKmkAKhe5YopUcI1Go+SEnPa3l72n9puQtp2vlrlb3P5lO3srSW9lt+6yM8ocktIkVg iSMrNXVMxCDAaRVAoKOG+G/W266ynyu/NlZqsxMUiTR4ntXsnfHc+8MsEd2H8bqt57t3Ttfa0Eq2 8lLiUqKiQf8AKbGpeFg5ce4G72UbwbZuMSzkU1W1vDaRL/pBDFFJIR5NLpUf77OGA9272T5Y3OWK 637Y7h7QEEJf311udzJQ/wCitc3FxBADjUlvrc/7/UakJ3qKio8bR0mOx1JTUGPoKaCioaGigipa Oio6WJIKakpKaBI4KampoI1SONFCIgAAAHuOJJJJpHllctKxJZiSSSTUkk5JJySck9TvBBDbQw21 tCsdvGoVVUBVVVFFVVFAFAAAAAAAoOpPunTvXvfuvde9+691/9Xf49+691737r3Xvfuvde9+691D q6GnrRH5VKywOZaWpjIWopZipTywSWOlipIYEFXUlWBUke3I5GjJ0ntPEeRHz/1VHl0zNBHOF1ij qaqw4qfUH/D5EYIIx0BKYSfqzsXdnYlSoqNsdmQbeG/62jglK4Pc+1Md/AMLvWoplaVocZl9sR0u OyhGpKM42lnFoXqWhEhuF3ra7LakNLyzL+CCR3xyNreIHzZZNTx+beI6/EE1Aj6V+V9+3Tfphq23 cVi+pdQaRzQp4UdwwzRHhCRTHIj8KJ8IZCkjvL43dC/KLaUW2+5evttdg4V4GmwuTqIzFmsP95Fd chtfdWLlps1hpJUZX10lSiSgDWHXj29ynzxzdyFuLX3K+9T2V1WjqDVHofhliYFHpwo6kjyoenuc /b7kf3K2pNv5u2G23CyK1jdh3pqHxQzIRIlRmqOAwpWo6oh7t/kALTVldm/jX3DF9vIZZabY/cNL PIab+2kFFvrbNJI0q3JRFq8PIwFi8xN295ecn/fIYJDa89cuMWFKz2ZGfm0EpFPUlJh8l8usFvcP 7hSXDT3ftvzUiA1K218poPOi3EKn7AHtz5Vc8eq+90/ywvnL1vPItf0dl9y0kRbTktg5fb27qSeN P92R0mJyQzUakC4EtFE1vqB7yQ5f+8Z7ObyqaOcYbaU/huUlhI+1nTw/2SEfPrCnnT7oP3gtikmP 9Qp7yAcHtJIbgEeoSN/FH+2jU/LpC7X2B2fsTc1FSbk613njslHULDJi63auVeuLXAZBRLRS1Dtc fQKb+xlunNPJu9bZO9lzXtzwFahluIqft1AdY7Qche5PKXNVhLecjbulwslDH9LOX+Y0hCSflTPl 1cx0h1ruLdGOoRlfjnmczBMkYMu4+o3gpXBA5as3HgqSmAI/Jf3hzzrzJsNncT/Sc+26ODwhu9R/ ZE7H+XXUX2p2Lmjc9vtBfe19+6FRmfb3Qfm08ar+09G8k+GmGyMCSUvQe3Nq1rqp/iG1s/DsavjL Dk+bZ248XLG6/wDBWsfwfcPv7pG3dgebLi6jH4ZYzMp/5zxtjrJAe0lxcRq0XIUFrMR8UUyW7D/n BMhH7D0pti/DXc20suMtRzYGqkKL9q3cO++wu+6DCSK5YVOI2XVrsLFwVqG2h6nKZDx2Gkg3JKN4 9113K2a1rLFF5izhgsWcejzjx3IPmEjjr5jpdtHsnu1ldpeeDt7SjKtuM93uqxn1S1Is4gw4gyTT UPA9VlfzZviR2juDdXR27J+5cz3D2R2lvnB9LbF6nptkYnblFiqGfH5fNZ/NbahxGTq5abCY+alh lr3qY52p45hJPVmNEVZQ9juftms7HmSwTl+Pb9os7Z7ua5MzSM7BlREkLqKuwJCaSAxWix1Jri19 7v2M5q3ve+RN9ueeZ965l3G+j261sBaxwJEmiSSSSERSMViVghkLqzIH1STlVUC+vo/4/dQ/HTZt HsjqHYuB2ZiYYKda+XGUurK5ysgj0tkc/m6kzZfOVzszHy1U0jKG0rpWyjGDmTmnfubNwk3Hftyl uJyTpDHtQE/CiCiovyUD1NTnroXyJ7d8ne22yQbFydsFvZWiqocoKySsBTXNK1ZJWP8AE7EjgKDH Qzew/wBDbr3v3Xuve/de697917r3v3Xuv//W3+Pfuvde9+691737r3Xvfuvde9+6914i/B5B4IP5 9+690HuQ2HJBC/8AcbcVfsKpMrzinxtFjsntyeaRxJJ91trKQS0sMcz3MhoJKCZ2JJkuT7NI9zDs P3larcpSlWLLIB8pFIJI8tYcD06IJtiMSH9yX72L1J0oqPCScmsLgqAfPwjExOS3QFZ/F/K6Pd1R Llsxt7c/WcVNRpjsd0umM687Bq6vyytkm3KvaU+8cRVUhiWIU/8ACc5hZlYyeRmGj2JLWbko2KCC CWHdyTqa71TwAU7fD+nETA1rq8SGUcKAZ6Bd/be5w3R2ubuC45dCrpXb9FrdM1Tr8X6wzoVpp0+D cW7A6tROOlvBuvrLK/w7D752vurC1wcUlPR9rbYzdZSSzj+z/eSqXO7KyE7k8GLISn+nFvZc1nvE Piz7bewyR8SbaRAQP+aY0TKPtQdGq7hyxdeBab5tdzFLXSFvoZHUn/mq3i27H/Syt8uhsxeFwuGg EOExOLxVMwBEWLoKShgI+oIjpIooyP8AYew9NcXFw2q4nd39WJJ/mT0M7SysbKMJY2kUMR8o0VB+ xQB06e2elfXvfuvde9+690joNhbVj3c2/Z8VBkd5jGy4Wk3Jkx97k8ThKiZKiqw2CkmDR4LGVs8S PUxUiwireNGnMjRoVXtud6bH92LOU2/WHMa4VnAoHenxsASFLV0gkLQE9E0ewbUu7HfpLUSb14Zj WZ+544yatHETiJGIBdYwushS+oqCFj7QdHPXvfuvde9+691737r3Xvfuvde9+691/9ff49+690Tr 5H/zAPh98Rdz4HZnyM7uwPWG59zYH+8+CxGUwm8MtUV+B/iFXiv4kj7a25mqeGE5CgmiAkdHLRmw tz7HHK3ttzvzraXF/wAr8vyXdpFJ4bsrxKA+kNp73Uk6SDgEZ6CHMXPvKPKVzBZ8xb1HbXMsetVZ ZGJWpWvYjDiCM+nRdv8Ah7L+Vx/3lztD/wBA7tT/AOwP2KP9YP3e/wCmKn/5y2//AFu6D3+vR7Y/ 9NZD/wA45/8ArV1mp/51f8ruqqIKaP5dbKWSomigjao2t2ZSU6vM6xo09XV7HgpaWEM3qkldI0W5 ZgAT7q3sL7uorOeSrigFcSQE49AJSSfkASfLra+83tizKo5thqTTKTAfmTGAPtOB1YxsHsHYnam0 cLv7rPeW2N/7H3HTNV4Hd2zs5jdx7dy9PHNLTTSY/L4moqqGp+3qoHilCuWimjZHAdWAi/cts3HZ 72423drGa23CI0eOVGR1NKjUrAEVBBGMggjB6kSw3Cx3S0hv9tvIriykFVkjYOjDhhlJBoQQc4II OR0Xb5J/PD4k/EHL7YwHyP7pwPV+Z3lja7Mbax+UxG68vUZTGY2qioq2sQbZ2/m1poYqqZUBmMZd r6dWlrCflX265052gu7nlbYZLyCBwsjK0ahWYEgfqOlTQVxWnnxHQe5j565T5RmtoOYt5jtZplLI GWRiyg0J7EamTTNK+XTV8dP5hnwy+Wm8Mr1/8eO+ds9lbzwu3p915HbuPxe68NkYtu0mQx+Lq8rD Hufb+EStpqWvytNHL4GkaMzoWADA+3uaPbLnvkuxh3Lmflya0sJJRGrs0bLrIZgp8N3oSFYitK0N OmuXvcDk7mu8lsOX99iubxIy5QK6nQCFLd6LUAsAaVpUV6NlufcuC2XtrcO8d0ZKDDbZ2ng8tuXc WYqvIaXFYLBUFRlMvkqkQpLKYKHH0skr6VZtKGwJ49gy0tLi/u7Wxs4jJdzSLGijizuQqqK4qWIA 6FVzcwWdtcXl1IEtokZ3Y8FVQWYn5AAnqs3/AIey/lcf95c7Q/8AQO7U/wDsD9yx/rB+73/TFT/8 5bf/AK3dRt/r0e2P/TWQ/wDOOf8A61dWiUNdS5Oho8lQzCooshS09dR1Cq6rPS1cKT08yrIqOolh kDAMARfke4ikjeKR4pFpIpII9CDQj9vUmxusqJIhqjAEH1ByOiz7n+bPxF2dkM1idx/I7qDH5Xb0 lXBmcYm98LXZGiq6FWNZQNQ46pq6qbJUzo0b00aPOJlMWjyAr7jPcveL2r2me8tdw9wNqjurcsJE +ojZ1ZfiXShYlxwKAFtXbTVjqZdn+737479a7fe7V7U77LZXQVopDaSojq/wvrdVURsCGEjEIVIf VpNemranzz+Gu9IsLJgfkl1QZNwmnTF0OZ3RSbYy0k1W4ip6arw25/4PlsXWSyEKIaqGGXUQNNyP aXbPe72k3hbNrH3C2vVPTQskywuS2AGjm8N0YnGl1Vq4p0t3r7tfv3y++4LuXtPvem11GR4rdriM BRVmWW38WORQM643daVNaA9OO/Pm38UOsN3ZrYe/+89kbV3ht2eCmzeAylVWx1+NnqaOnr4IqlIq KWMNLR1ccgsx9Lj2o3v3j9sOW91vNk33nSytt2t2AkidmDISoYA0UjKsDx4HpLy193r3q5w2Pb+Z OWfbncb3YrpS0U0aoUkCsyEqS4OGVl4cQenXsX5hfFzqbcuO2d2H3z1ntndOQz1PttsDVbnoKrJ4 XKVMElRE27qXHSVkmyMUIoyXyGY+xoIyVV5lZ1BU7/7se2vK+42+079zvt1tuck4i8IzKzxuQSPH CFjbpQZln8OIYBcEiqLlX2J94+dtput+5W9tt3vNmitmn8Zbd1jljUhT9M0gQXclTiG18aZgCVjI UkGAxGXxOfxePzmBymOzeFy9HT5HFZjEVtNksXk8fVxLPSV2PyFHLNSVtHVQuHjljdkdSCCQfY7t bq1vraC9srmOazlQOkiMHR1YVVlZSVZSMggkEZB6jG+sb3bLy627crOW33CCRkkilRo5I3U0ZHRg GRlIIZWAIIoRXopO3f5gfw73b2rR9Kbb7wwGZ7GyWdk2zjcTRYXeEmIyWdjd4hjcdvI7dXZVdNPN GY4TFkXSeUhIy7MoMWWHvr7TbpzNDyft/OcE3MEk5hRFjnKPJw0LceF9OxJFF0ykMaBSSQOpv3X7 sXvvsnJdx7g7t7d3NvypFbC4kkeW1EscJAPiPa+P9WgAOp9UAKLVnCqCQKuV+SvReF3nh+va7sfB tvLObvyuwqPBY+PJZiop93YLALunM4bNTYihrqPbc2M27ItXPJkZKWGOF1JcalBE117h8l2e72mx TcwQ/vaa7e2WNQ8hE8cXjSRyFFZYikRDsZSihSKnI6Bdl7Se424bBf8ANFvypcDYbaxjvGmcxxK1 tNMbeKWISujTiScGJFgWR2YEBcGiKf5xfDhNwQ7aPyf6LORnxUuZSpTszakm31pIqpaRoZt2R5Nt rU+VMrArQSVi1zxXkWExguCc+83tKL5NuPuRsv1BiMlfq4DFpB00M4fwQ9eEZkEhHcEK56EC/d29 +W2x93Hs9zH9KswiKmwuRNqK6qi2Mf1DR0wZliMIbsLhyF6Yt7fzAPh115u+t2Huvvba1HuzHS0l PWYnHUG5dxtFU10MNRS0q1m28Hl8fNVSxVCftJK0ilgpAbj2i3j309pth3WbZNz51tk3SMqGRFml oWAKjVFG6kkEYDEitCK9GXL33ZPffmnY7fmTZfbe8k2SVWZZXe3gqqEqzaZ5onCgqe4qAQKgkZ6O J7lnqCOv/9Df49+6918+f/hRr2Ed6fzLNzbbMgcdR9PdT9ehQFBiGSxeQ7W8bEEliT2cWubGzAfQ A++ln3Xds+g9qbS6p/ubfXE3+8stv/1g6wE+8PuH1nuRc21f9xLOCL9qmf8A6zdE++DH8rb5N/zC cB2DuXoeo63ocT1tmMHgs9Udg7ly+3fucjnqKvyFNDiP4btnPpWfa01AWqNTRGPyx8HVwN/cL3e5 T9s7nbLTmJbpprpHdBDGr0VCAS2qRKVJxxrQ+nQQ5I9sOZef4Nwudia2WK2dVYyuyVLAkaaI1aAZ 4UqPXoAPl58Q+5fhF3LX9Gd50GDpN40mDw+5qSr2zmFzu381t/OrUDH5bE5A09FUtTtU0VRA6T08 EyTQOCltLMJeSedti5/2KPmHl6SRrFpGjIkXQ6OlNSstSK0KnDEEEZ6IebeUt45K3iTZN7jQXgRX BRtSMjVoymgNKgjIBqDjrZH/AOEsvZe/Zs98q+oJsjX1nWVBhNh9h0OLm88uOwG9a/I5Xb1dVY9r /b0VTunC0kS1Kn1VAxUJW3ie+LH3v9p21bbk7e1iVd2aSaEsKBniCq4DeZEbE6f4fEb1HWRn3X9y vzPzTtBkY7aqRShTWiyEshI8gXUCvroHoeiYf8KW+wxuz+YHt7Z0FQGperOgNh7eqKVREfDmtxZ7 eO+Kud2W8okqMPuPHLpYgBYlKqNRZh391LbPovbW5vmXvvNymcH1REiiA9MMj/t44wDfvIbh9Xz9 b2at22thEhHoztJIT+aun7P21S/A35TZn4ZfLHpr5C4z7qfGbM3RBT72xNI5Emf673BHJgt9YZYy fFLVVG3K+eSj8gZIq+KCWxMY9zH7i8oQc98mb7yzLpEs8JMTH8Eyd8LfIBwA1MlCy+fUWci80Tcn c1bPzBFUxQygSKPxxP2yr9pQkrXgwU+XX0Dv5p/cWH2x/K6+VnZu3MvSZLAbz6Dqdu7fzdBJTz0W UxPeRxHXWIyFDPMVjkp8lSb8jeGRf3LSBo/XpHvmt7P7HPd+7vJ203UDJcwbkHdDUFWtNU7Ageam EgjhjOK9Z8+6G8Q23tjzTudvMGgmsCiMKEMtzphUgnyIlFDxzjNOvnLfHfr0dt/IDozqkxecdm9x dZdemHWkfmG9N64TbZi8kiSxx+QZK2plYC9yD9PfUPmfc/3Ly1zDvNafSWM81fTwonf/AJ96548v bf8Avbf9j2qlfqbyGKn/ADUkVP8AL19WDsnPHavXe/dzrOaZ9u7M3Pm46gUWWybQyYrCVtdHImNw KSZ3IurwArT0StVzH0QgyMo98UN/vl2zYt53J5Ci29pLISEeQjRGzVCR/qORTCR97HtTuI666cq7 cN35n5c2po9a3N/bxFdccdRJKiEa5qQoCDl5T4a/FJ2g9a1nXu6PjT8b9rV/Z/aOJp+38/tPC1eG 646Kxfxu351V1HNks9lqiauq92djdr7W3lunf25JaeunmpqzcNRU/ZIhjhilaOmeHn3sm6e03t9b ScxcxxzbobWIx21guzT2loWlclmlnvUlkupqMxR7udtAFFVisZTq9zXae6/uru1vyjyfePsW3Xtw st9u8m+Wm47kEhjUIttZbdPaW9lACiLJFZRx+KTqd0DTLI9d0Yrqnuzvzr/BfH/ZCRddfIBts7a7 Y2H2X8ct77e692Nm8bX7Yj2lP11vLZu29mb92XPubII611RQVdPjjKrT10zUkzwRruY7bkHnPnba rHlPbbhNj33wYbm2uNmmS0gkVohCYLiIWt1amVh+o8L+EW1PO3hMVCHkDeOcvb/225j3D3K35m5q 5Z+on269sN8tZr27ikS4Nyt9a3U11Z3YgQgwpNE84UiO3QTxrIz9L3Z8g2+ZW6flMNo9P4zrbLfK 7bvwkyuxd0UuT3Dvui6r6+hq94dm7vo5mwuIoMFnqDHU8mUniaWXw5Oojp5ZGgppDMevzduR90dy 9zfDhj2uXmKPl57Wa1SSZYLVTcXUiv4yeHpAaWRyCySsqMjKjBitOSfbAewuzezZ3jfZea4OTp+a o7y3eOC0fcb0rbWFs6+JK80LuVt0YKuq3RpUUSSror52vkOz81i8Fv8A3f0D8Vt0bi2Hkt2b83dt jem6d1L2b8k8n8uxWU/Xa0EB6ayNZvKTZRrTVYmCirJ0oqwiol8cisFhXbW2e8tbTfd02Hb7m/sZ JrmaG4gX6zdn33ULXSKs1wbfVrgWORhFJ+o2lgQMm94l5RsLvc+Wtj9x+crLa9yhtbO1ntYLf6DY o+WtDXuo/vNEtRd6BHcvLEhlirEmtSCdgD5Xbf3F0j/Lw2P051hSZjZXYO4W6c6X2Zt/bnZmRwy0 m8975jG0eW29XdhptXK57J7bUzZBal6fHU9XkadNCmk8hkizM9x9uh5O9k9m5P2iW9sLm4ey2+3W 3mpKJrh1UxtKe5ozWQS6SrulQrLWo5p+zW87Zz996HmDn7nCW33Hlq2/ee6XU09hHLqtbWJ2jmSy +ojhjnxCYw8zxwOdRE2gK5LPkPsj5d7L6d6E6P3vF8F8dsLAd4dKbR2Ft747br7q2p3htjdMe6YM bQ5zrrM7yTceJG7se9ZUy1VTkaCpMjzSzyjzkP7jbn/YeY9n5R5L5N3fceXY9ng3iwgtItrS5h3C K4EwRJLaSe7lQTKWYySSRSHud2UvQ9T77Y80eyO989+5PuJy+fcSbmW65f3W4vJt7g2q52m4tzbl 3hvorUQSfTOFjWOOCaPSESNP0wV6BfovObrq+zqrtuGi/vAMFsv5/fLrEVtBQVnZ+ayFX2Tuui+N XXVRV7Xq6bbUe9VWm2VJPNRyV9EskXnZZgsk8igHlG8spN+l5rs5r26mgtOY98jP0yXLP9XMu0Qs 0fjL45X6clYyyCRNbF4wz0HnuJFssfKEPJDyfSi4vuTeW5Ud1sIkSwgffb1UuFM5tCWugqyrDKVb wwYyUjUlt60n7Uzm69udXZjZ25KHZmwe29ibuTe8/wAO8VW76y1XkKiv3ruDbneElX2BCdudYY/B 5RKhMa2RytFWbfhWWWmp4IAksd7DLNeXm1cuS7duq2dlusE7TPy7B4zMxa4aK/c3xZLMRPrMLM8b WyhjGESjStzXc8mWGz7tzhY7vbSb9ueyXdqbQczyJZxKipawz7SFsj424PLGUM4gt5YrxmRJZJJC yHy+EtX8u8Buj4lbd293Fsfa+zfljm+9Pkl27sSi6xweay2z9s4LdEVbTQUO8sqy5bdlX2nSmGgW rlgxI2+raoo8h4NDzj7SSc52O4+3e37Lzt4G1czy3+7T25262LxxRzBnDztM8hN0KRxuB+iMgNpo ccfvAN7H7ttHvPum6cg7jeb/AMmW207Ftl4+4TRR3M8tuUZntYx4duu3tqmMavc/WkUdrbxNS7GP vOfrlr1//9Hf49+6918vj+aB2Ee0P5hvzG3aJBNAO/N/7VoZ1ChKjF9e5eXr/E1EekkGOoxm2InU mzFWBIBJA64+0e2fuj2y5GsqUb92wyEejTL4zD8mkI65le5u4fvP3A5vu61X6+VAfVYm8JT+aoD0 Yb+Xx/OG7o/l09V7w6r6t6n6k3pQ717AqewMtn9+LvR8ytVNtzb23KfEU67f3ThsauMoYcCZoyYD OZaqXW7KI1QMe5fsfsPuhvFjvG77ze28lvbCFUh8LTQO7ljrjZtRL0OaUUUANSRDyB7vbz7ebXeb Xte1WkyTXBlZpfE1V0IgUaHUaRpqMVqxqaUoT/5bfLft/wCe/wAgqrunu/MbYxu4s9Dg9o4mlxlJ WYfY2wNo0FXP/DcNjYHlzeYhwOLqcpU1lRLNLW1cktRNIWdmCgb8l8l7J7cctJsPL8Er2sZeRixD SzSEDUzHsUuwVVAAVQAoxSvQR5s5s3fnvf23ne5oluJAsahQViijBNFA7mCqWZiSWYksc8Ot73+S x8GeuPhr8VKfObU7H2Z3PvLv+bFb63z2r13k/wCMbDzFJiYK/H7V2rsvJARNkNvbOFdXqaiaKGqm yNZWGSOFRHTw87ffn3C3TnrnFre82uewsdtDQxW8y6ZlLEGSSVc6XlonaCVCKlC2WbOX2a5I27k/ lZZ7XcYby8vysss8TaomCghEjPmkdWyQGLs9QMKulr/OE7D/ANJ38zH5hbiE61C4rtWbrxWURBY/ 9EuAwfVrwBYfQGp5dnMjf2i4Jf1lveePshtn7p9qOR7XTQvZib/spd7iufXxa/Zwx1hr7u7h+8/c nm641VC3Xhf84FWCn5eH/nz1XpmNr7h2/QbXyebw9fi8fvXAzbo2nV1kDQwbg29T7j3BtCbMYx2/ 4E0Ee59qZKhMg4+4opV/s+5Ngu7a5ku4bedXlt5BHIAalHKJIFb0PhyI9P4WB8+o/mtri3S2lmhZ Y5o9aEjDoHePUvqNaOtfVSPLq9HdX8wcdn/yJIfi7uLNPVdmdX/Ibqrp56WokSWtyfSkuP3x2p15 lS9VMZZKPbWR66kwBWmT/JKehoFewqLnHqz9tP3T94hubrW307Td7ZcXNRwW61RW8y4HGRZxN3Hu LyEfD1N91z/+8/Y0csXE1dytdwgt6Hi1tSSeJs+SGExY+ELHX4uixfyTuuz2V/M8+KmLkgaWi23u zcfYldIGVVpR13sXdG8MZPIWjlJV8/iKOIALcvKougu6iz383P8AdXtJzjMGpJLCkI+fjzRxMP8A eGY/YPPgQ17L7f8AvL3M5WiK1SOV5T8vCieRT/vSqPz8uPX0aOzo+zpdjZ6Ppup2PR9kulAu2qrs imztZsuBjlKH+KyZmm21UUualIwn3P2whcD7vxGS8esHkfzIvMjbJfLyhJZJzEQvgm7ErW4711mQ QkSH9PXo0n+006qrUddP+U25TTmDbm54i3B+VgX8dbFoluj+m/hiJpw0Q/V8PXqB/T16aNpPRHa/ 4L7u74qpsp81+6avuKnp8VmqDanWewMIOuurtkZLN4utxD7tpaJKrIZLdG88RTZCY43IZG7UTSH0 SAKFhWf2T3XniV7n3k5xbd41ikWCztY/pLK2eRGjM6rqZ5riMM3gyy5jJ+FsUyAt/vB7L7dwpZ+w 3IibHK00T3F9eS/W390kUiyC3ZyqJb2sjIvjww4lA+Jamq96M6e+XXTG49r7Iynd/W/a/wAedvU0 uKpZN4bHy2K7pxW28fip6fbOEocrt3I022cvU4+ohpYJq6vWSSWmEj+PyaEU95K5S91+T9w2zZbn nTbt05At1KA3Fs6bgkKoRDGrxOIZChCK0soJZNR06tIAd9wed/Zbnra933+05A3TZvcy5YSMLa7j k2uSd5A08rxzI08aupkdYoSFV9K69OpiRnL/AMun5a7kqMlt3I9odD4fZVH2L3vv3bucxtFv7J73 zGT+QkU22915velFU4/GYRs3tzZtfUHDiinQRZAp5ppYlBEKXf3ffdTcZLjb7jmXY4dmTcNzuYpE W6e5kfdAYZ5LhSiR+JFbs/geGw0y01uyjrIKy+897M7VFa7nbcpcxT78+17RZzRO1mlrHHsxE9vF asryS+FPcon1PiodUOrQiOel5jP5avbGM3N1V3HD3ntQ9wdI/wBz9rdY7equu8TkurcD1JsqCqxO K2VX1FXQ/wB6s7uI4qqef+8EwWsgrJZGhjSUQ1UJ5bfd05ptty5X5uTna1/rbsvgQ2cTWiPZRWNu GjS3YsvjSy6GLfVNSRZGYoqtolQO3X3qeTbraecOR5Pb68/qTv8A9TcX8y3siX8243RWSS6RVf6e GHxFCfRrWN4lUOzJrhc6Py/6H7F7x2/1JP1XunaW2969Pd2bO7mwkO/cdkcps7NZDaFHmoaGhzFP hx/E08VXlElSSEhlCuFKSFJY5h92eR+YOdbDlV+WNztbfedo3m33CMXKO9vI8CyBVkEfeKM4YFc4 IBVirLBPsn7icse3+5c5x837Re3Ww73sFztkps3SO5iS5aIu8Rk/TNVjKkNgkgkMoZGLZtv4rfI+ l7FrOxs51h/Liptz5Sr3Pm8lvbbHV3bUG/jujPUuTqTn6HP5PP1D0WVq89WLJU1i/wCU+KSUo2th eOtu9sPcOLmCbmG95a9vV3KVppHuIbO+F140qufFWV5TpdpWBeQd+kvpNT1Ke6+7/tdNyxByvt/N vui20wpBElrPf7cbP6eFo18F4UhUNGsKlY4z2aggYaR0HO2P5cHbeP6r7R2nW736o25ubsvaOwel KOPY9Fvt9p9edGbf3LW7n3jRbel3XXZnc+d3ZvHIV0jSff1Apw0khMnqUIH9t+7zzXb8sczbVNvW 12+5blaWu3KLZbkwWu2xTNNcLEZ2kmlnuGYk+K2ipYlsigo3b70XJdzzfyjvMGwbzdbTtV7eboxu ntBcXu7TQLBbPMLdIoIbe2RFC+CmuiqAmCWTWQ/lv/Iuq21hcxR7+6UxnamU7B7y3TvaOkh33HsX C4btbp/HdP7Yx2xpBQfxutn61xNHPPjhXwwgzVY8skqQslQWz/d59wJNus7uHfdmj5nlv9ymuAou RbRx3tglhClsdPiMbNFZohKq9z9zMEIkNbb70ftjDut/Yz8ub9LyfDtu029qWNobuWXb9yfcp3ux r8JBfSMiTGFm7Y+xULhozv8AVHxWy3WPfeyd8w5bBVvW3VfxH2l8bNhY8tV/3qky2K3NS5ncO7sv RfwuLD0UuXosXTRGWnq5ZZWMmpEBJkmjlf2wuuW+edm3tLqB+Xdr5Ug2i2Tu8cukyySzyLoEamRU QaldmY6qquS0Ac4+8FnzZ7db9y/JZXEfNW8c6XG+Xj9v04jkgaKG2jbxDKwjeSRgrxqqjTRmNAp2 vczdQJ1//9Lfc3PuCg2ltrcO6sqxTF7ZweW3BknXTqSgw1BUZGsZdRVbrT0zEXIHtRaW0l7d2tnC P1pZFRftYhR/M9MXNxHaW1xdS/2USM5+xQSf5Dr5IW6dxZDd+59x7syzI+V3RnsvuLJtGuiNshms hUZKtaNf7KGpqWsPwPfaWztYrK0tbKEfowxqi/6VFCj+Q65P3VxJd3Nxdy/2ssjO32sST/M9byv8 vf8Aknfy+Oz/AITfGbs3vP49HefaXZPU+2+wtz7mbtfvXbhyi73ik3RgpP4Ltnsjb2BohT7bytHC BTUcUbiPX6yxkbnx7l+/nuXtHP3Nm08vczeBs9revDHH9PaPp8I+G/dJA7mrqx7mJFaYpQZucgey /IG58l8tbnvnL/jbpc2qSu/j3KavE717UmRRRGUYUA0rmtTqPfzE+qekuj/mt8hOp/jpm48905sj ekOI2lVQ5qXcUWOmO38LWbo2umcqJ6qpyq7M3hVZDEeaWWaZ/sbySO+pzmn7Ybxv/MHIXLO880W5 j3y4gLSAqE1DWwjk0AAL4sQSSgAA14AGOsTvcLatl2TnPmDauXpvE2eCYLGdWuh0KXTUSS3hyF46 kk9uSTnra3/4TC7r3TJ8Pe/8fuLIVH9wNn95zT7Znr5SaHEVFdsPb+V3lSUk0shFLRQBaOskiULG ktVJLy0rn3hx97azsxzvy3Laxj95T7eBIBxYCZ1iJHmT3KDxIUDgB1lP92e6ujyhv0dxIfoIb4lC eCkxI0gHoB2sRwqxPEnrS37b3zUdn9q9m9lVhc1fYfYO8981RkSOOQ1G7dx5LPzmSOICKNzLkDdV 9IPA49547Lt67Rs+07UnwWttFEPsjRUHH/S9YbbtfNue6bluT/HcXEkp+2Ryx/w9bPX8xf8Al8rJ /Ji+B/fO1cKw378b+leu8h2JFFAHyFR133nSY7d+5I6lqfmpOxeyd0xTIuhkgpK6vmMllYtiT7X+ 5ZHvt7i8uXk/+67db+ZYM9omtC0aUrw8aCMg5qWSNaZFMl/cPkAH2c5G321h/wAf26yiMuMmG5Ak etOPhTOD8laQ19dUbUwUpqOlirFbnSWUMFYj6EqHNj+Ln+vvMj5+fWLHy8utj/8A4TGddncfzf7Q 7AqYDJQ9b/HrcMdLMrKPBuPee89l4nH61aNy0Uu36PLjgqwYKbkXBxa+9nuf0vt/tG2o1JLrc0qP VIopWb/jZj/n1kV92nb/AKjnbc79l7Lbb3ofR5JI1H/GBJ1tN/zIe9sT091EYd14r5V4bZOSnxFd uLtv4tZTD7a3LsqWPc2FxWDwlRuXKmWogl3dl8lFTinpIJZZ4wyOUR/VyA98eYH2nlsWktnzHHts rI0t5tE9vbTQFZUVIzLO6keMzBdMasWAKkgNnsb91P27u+d+d/G2i+5Ln5ghWRINt5hjluLe7Bt5 ZJZRBEApFtHGz65XVUajKGZcUg9/d2ZrblNn9sdCb5/nXZLszae313rvmLuXN9o4DGdabGRZqkbx 3TtHCdeSbjqcHVQUU4SeqqcNQIEaRqpgjIcS+d35msYLmy5F3r3Vl3+GLxpvr9x8OO2hyfFkhjQy uhAahZ4Ix8RkIBXroZ7Z8i7Vus227t7l8vfd9h5SvLn6W0O1wWE0l/dmi/TW9zNeiBZVLJVI47qY 1CiEFg3R9ZP5gyVvwMx++Nu717kxUeEquvtk0HyF3t/oy643h2vuunwOc3X2fLsXCdt17YPdEO1q jAHDVAo5MnVVlVLJHRidoDPJNE/ufvR9n7aexvN1S7h+khXcpZNugnu5fDklu2hS6maFxC0fgNRp HdmYRB9HiNjUn3aI7f7yF1sO67HsE31KXt0+y2v7wvrXbrdporbbxdzbagmtzcLN9UniLBHFGqNO YxII1JL0z8r/AJIbuqt1UeP+Q/cHZWb3/W7yzu1NjbT76+KtZueq2xJtKoqsVEu333XX762bnsPi aOSuyNFt+jx60LQSPHDFMsknuGOWObPdy8k3aM82bzfXN5LO8MEO57IXMRhPhjSbhp4JEUGSRLVY lQqWRVYM3WQnPvs77Q7LFss0/tlsG02G2R2sNzd3Oz8xLAtwLkLKfGFslpdQyyMsMEt7LOZg6q8j xlE6O78X/kd3bubpjaXyd3kPkPjesenviVvbcmQ3NuTeOztw9Tdr57rTa256ap3LmsMKGp7ZzO8M zlBJNpq50kM+PVWLuqiSXvbzmb3Duth2nnLe4t7i2va+W5mZ5byzmsb2e2hlXxZFBa7eaRzqJkcA NGNTEgase/eD2u9udq583v2k2B+VpubN952tIEggtbqDcttgv7i3YQRS6l22K1ijotY0ICTEgKpJ StiD5x9lUWwex6F/kN8xKDdO9tvfH7ZNfj8/g91Z3sGDufsWm3X2Jlanp3aU+4+vM5tLaeQoNu47 H0dTh2nJx+WhL0korqVkg9OcfcSHZd/tzznzMm5Xtrt0LCSVJbhb6fxrmZrKP6u1a3hIjiiRoWJM UwPguJFKZYS/d/5LuOZuVLhfbLkOXZ9vut6u0eGW3hsm2qya2sol3S5FvexXNyjzzzyR3QX9a2cL On08wYwXRvyW+T2Q+THR/TXePYfye647P7S7vwfblR1zuzqXfO3ttVm1IqnL4qXZWHzm4++MBIvT 9LhaOsnloU29LevgLVUdeaZQwu5O3/3el535U2PnLe99st2vt6jvZLeSLTCYQXQ20btu6N9CIw7G JbRqyisiz+GKxl7i+1Xs1a+03uFz17d8scn7ryns/Ls22Le2+5Wk1wtwVjkF3LDBs0wO5tK0SLMb 1aQuBC9t4xoeL507NzvUAxUPX3yz+Z+Z+RPyM7FqtudE9NYXtXAwbTfcGayf8Ry9XJhsT13DW7e6 s6+xlYXqJmq4IKKnEEUlTEjNMkr+73Ku9bFA8vLHuZzbPzvvF4yWNkt/BHbh5H1OdH06MlpbI1SF caV0KWAJcY8fdz5i2rndrpuavZTkC39ruVtrWfd90l26ZrnwYo9ESiWS+Kz7jeyLRFEbvK/iOsTs BGxiNudlfPfZ+3NvdXUPxNbfea2xSY3Z0vfvYnyJ6zp9v7xbCJHjarszNbZwQrt9xU25UpTWrQ+B shEKhUmLSq5YX7fzD74bTt9hy1D7XfW3lsiQHc7rdbQRT+HRDdyQx6rkCbT4gj0mVdQDksGJi/de Uvu077uu6c5XHvYNt2+8eS6GzWOx37TWvikyLYRXE2izLW5YRGbWIG0FowEZQA++f+8ctX/IX+XN 0FQZ7J4+s7I77qd8bnpMDUZehp8ttzqmnwFfm8fkhQTEJispjM5XKkdTIUcRsLsVPtD71NvG5c4e x3KtjcukVxvf1N14chjDRWgjLoy6wzI6vKNPdwNfmJfuzbNt1p7Y/eo9ybvboZItr5aFpbNMsTtH PuLTJE8esf2kckMJLRgEahwBHVrvvI7rC7r/09wn+Z/2B/ox/l5fMbdiyeGc9BdgbWoZwbNT5PsD Dy7AxdRGdSWmp8juaJ0+o1qOG+hkT2k2z97e5vI1kRVf3lDIR6rCwmYfYVjIPy6A3ubf/uz2/wCc LqtG+glQH0Mq+Ep/IuKdfL399ceuZXQoU/bfdGQxlNs6k7N7QrcPLR0+Co9q0+8911OMlx8cSUlJ hqbBxZJ6V6NIEWKOnWIoEAULYAeyl9l2GOV759ptFnDFzIYow1eJYvprWuS1a+dejNd23mSNbNNy umhIChBI5FOAULWlKYApTow3x3/l1/NH5Q7pwu2uqPj12XU0eXmplm31ubaed2l1rg6OpCS/xPOb 8zuOpNv0tMlI5nSKOWasqo1IpoJ3shDHM/ufyHyjZz3e88zWgdAaRRyJJO5H4UhRi5NcVICqfjZR noQcve3vOXM91DbbVy/clHI/VdGjhUH8TSsAgFM0BLMPhVjjrebp/j1tT+Vx/KD7z692tlY8xn9h fHruXdO5t6pSQ0R3n3Ju7Z+UpRnmpKmRkgxwz1RQY6hicyTR4ujp4380ykyc925mvfd73t5e3O7h KW1zudrHHFUnwrWOVToqOLaA7uRQGRmI0qcZvLy/a+2PtJvm32soe4g2+4d5KAeJcSRsNVDwGoqi g1IRVBqRn51+0tt5DeW69s7QxK68ruvcOF23jEtq15DOZKmxdEunUt9VTVKLXH+v76eXt1FY2d3f TH9GGJnb/SopY/yHXPa0tpLy6trSIfqyyKi/axCj+Z6+sbmupdi7k6iyXRm4MNHmOtsz15U9W5bB V2iRMhs2s2621qrG1DJGiapsO5QsqrZjdQLC3GiDetxtd7i5htpym6x3QuFcfhlD+IGH2NnrqpNt Njc7TJsdxCH257cwMp84ymgg/auOvlsfLL48bo+J/wAkO4fjxu7yS5Xq7emSwNLkZEWP+P7cl8eT 2huiKNeI6fdG1K+iyEacMiVIVgGBA69cmcz2nOXK2x8z2VBDeQK5X+B/hlj+2OQMhPmVqMdcw+a+ XrrlXmLd+X7upltZioP8SfFG/wBjoVcelacetqn/AISv9dmj67+XnbEsBYbj3p1f13j6lmUrGdl4 PdO5cvBCojDKZxv2haQlmDeNLBbEth598Hc9e6ck7Mrf2UFxMR/zVeNFJ+zwXp9p4+WUf3Xtv0bf zbupX+0mhiB/5pq7sPz8Va/YPztS+fGA7B+SmR3Z1piqDE7S6I+NGFm7X7i352fQ7wptgb03VS7X gztDs/Gy7GH98s1i9nbCzdZlcjJibyrXeGmDQ1CxOeQvvpYb97i3G68uWsEVryRy5Cb6/ubxbhbW 4mWESLAhtv8AGJEt7aSSeUwZ8TRHVJArHr993LcuWvau12bmu8uJr33D5rnG37ZaWD2zXlrbtcGJ 7lxd/wCLRSXN3FHbwLcUUxa5aSRF1FYvxr/l17l+Rzb83ztjBdF0vVp3bQ7S2/nMtB8k8HBPQ4rF 0jZ3dvU+Jz+5aHcVbBVSZLVfdAq4GyFP40hhhWaE42+3X3f9x9wjvm97bZbIvLP1awRSON3jBVEX xZ7FJZllYMXr/jmtTKmkIiB06yy90/vObV7Xjl3l/dtw5hfm76J7maKM7HKQ8kjeDbbjJDA8KlQl P8Q8NxC+pndyj9HD31gt99gfCf4kbKy3SncMeZ6Vrqt92Q7e6t643nhcPmegqjO9azUW8sDv3ce2 qWtxuZqMe9edEk9LWrBIKuGXUhWW97sd8372a9qtmuuTd2F5szt44isrS4jjk2wy2ZW4iuZYVZJC hlwWSQK3io1RSEOX9w5e5b9+veffrPn3ZDYb9GotzNf3trLLFvAivg9tNaQTsrxK4hyqSRF18F0o aoz4L4b5OU+16bfuB6IXdG7K/b+5dwbVk3/1J01sLYFVWbr3TTbbMlJ3LSVo7Pp8ZiNn5qpq3xNP i6damGmqKKJQjLIxP7J2fuRHtke+2PJAud0kt5pYDdWO32tqzTziGq7grfWBI7eR3MCQqHVJIVAU hie/eDvvaeTd5eXNx9wzabNHcwQ3As9x3O8vFW3t2no22Mn0BkkuYo4xcPO5R3juHJYFQgOt+vN6 9ZfD35J9R7nm7Tr++chvrb/xai27U4Xcc+x9jbAfPZreuZ3Hs2aKh+1rNjZvZWP3Bma/LNGivBTQ AiOKWOSci5d2DeeW/aX3E5T3J9zk54kvotlERjlNtbWviyXEk1uQtGtpLdbq4lnIAKonwqys4k5o 5m2Hmz3u9rOdNpj2iP27j2+bfzMssAu7u88GK1iguQX1LdxXT2dtDbgkh3koWdGWMNqXp3J7ywdP vY9edp/ICCfvLsXK7X3buTpP5D1FPv3qLbe0dtdX9bZOrzfSNNgNybOyNFWbWnqYcYWpWFNFTeRQ A0XsOx8o3O72Ue8/uDc9+Rt7u3hnm27dSLmxighs7R2k24RTW7q0LOsNUOhY9QABXoUy88Wmx7hJ sI5m2jluReX7KOe3g3TZlNpuU9zPf30axbq00FyjLcJG04Eg1tLpJJD9Gm+D3VGNHzSxGdbqXC4a HYPTe463MU2KpvkNOer9857J4iPC0+74fkI246/Db7ze1aqc0VFjq2ndaJ5nlTyI6CTfZbla3HvF aXp5VhhSw2iVpAg3U/R3MrxiMTjdfFaO5kgZvDjikUiMuWGoEdRD94DnK6PsRe7eOc5533LfIEia RtmH19pDHIZTbHZvASW0iuFTxZZ4nBlEao2llYrPoL5ddBVXdPZ3yZ+Tm6d17S7fyGQynXXWHWeS 6l7ezY6U6kw1bLHT42OswGwMrin3du+raSqys0czspYxr4lllhU35F91+RJeceZfcf3J3O6tebJJ HtLOzexv5P3dYxsQEDRWrp487VedgxIrpGkMyAj9x/Zb3Hh5D5T9qPabaLO95Jijjvb++Tcdti/e m4yqCzlZryOT6a2XTHbqygGmo6yiOXfqLN/HTJ9ydYJ1p/MS+dm8d1zb9wk0exuzB2/uPY29aUVf mrtqZbH5rp3am3cVj8xCrRSVdROsVHCWdAjqkkavlS99vrnm/lpeXPvAc73m6G+jItrz6+W2uF1V aB0ksIIkSQVUuzBY1qRpIDKi50sPc+05H5tbmv7snt5Y7Ou3Sg3dj+7YLu1bTRLiN4tzuJpHiNGW NELSNRW1KWVjN5zCbK7H/mb7JyMW9ap94fHn4/5rKTbDG065qKnffFVkMHNnJN7fxP8Ah0dZU4jf FMkeO+z8zRxvL5SvpWSb2y2bmH7yOzXC7yx3bYNhkc23gNpBuWaMym416AxjuUAi8PUQC2ojAifb 7/fuV/un7/avsKDZOZuZIoxd/UJrItFSURC18PWVWS0kJm8TSCypoBybHPeQnWL3X//U3+PfuvdV g/KL5x5/pvuvefWmC3/8XNg4nrzp3aHY2Wm783FuXHbi3juXdWa3zCuzdjYvbGUiyFbLQ4HatLUT PDQ5CeJ8nDeEq6B/de6FTGfPnqjEYrbdP25h98da70TqjYvaPbeJOxt5bj2t0pT742vWbgxuK3/v jEYCXCYSvyNXjZaDHUlQYslka+SCmipTUyiEe690t6b5p9JVOK3JVhezqbcG19x7W2rWdcZDp3s7 Gdp1uZ35SZbI7DixPXuR2vS7kr6TeGKwNZV0lSIBTxU9JO1S9OYJ1j917oI9w/zD+p6DcHTs9HXt idjbw/06QdirvLbG7ML2PtHP9N1+1NmnYWP2AaNdx1+/sp2ZvKkxMeOho62arljljplkkUlfde6S vYf8wuo25vndm0ML1fu+mptsdv8Axl6qiyGe6/7ByGVy9f2/TPvTsHHUe1cJio8zJu7bHV8sFbi8 VAKmrq6h9Tx+NlT37r3QzP8APj4/ig2NPD/pNrcxvzJ9gYel2dQdTb8rN57ZruptxYja/aH9/dvQ YV6rZFDsHKZhf4lWZAw0cUcE7JK/iYe/de6z0Hz3+N2Qxm582ud3rQ4Tbuwa3tPHZnM9WdjYPGb+ 67x2Xw+3q3d3WNVlts0ab9xMWe3DQUqfw/yyztWwSQpJBNHK3uvdL/sP5V9NdZZvdG19xZbP1e7N rVnX2Ifae2dn7n3VuTcO4+0aTdWR2VtXZ+JwWLrqndG5MljNl5CrmpaQSNQ0cP3FUYYGEnv3Xui4 7g/mLdcHdHUqbEwu9937Q3ZVd+Um+6Wh6n7PrOydvVfRuH2r/GMdQ7Fp8FDm6Keh3Nu6Glr6ivpo 6OD7Spj8glTj3Xuj57I3lt7sXZe0ewdo1xym099bXwG8tsZNqaqomyO3tz4qkzeFrjR10NPW0hq8 bXRSeKaOOWPVpdVYED3XulR7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6//V 3+PfuvdV29kfC7tPePZXyI3ht3vjr3bm2vkbRbXwm48BuH440+/dz7Z29tzYFLsB8dtbeOS7bxmM gqK2lNZWLNUYSeOKrrCTDIiBT7r3XDP/AMvTbWX6n7l6rpew6+Cl7Kz3QddtzJZjbce449s7c+OO z+r9sbA2juzF1uehTsXG1dX11LW5RmmxX3j5WVVSJ0Ez+690H8v8ufcqYSlOO7F6gxebyu/Ruzf+ zsN0Lkdr9IbvwlLtObbO1to5baeze2dudi7mouva7J5DL4189uvKwTZGtlL08cfhSD3XumLB/wAq fE4Ta+x6CDuOGDenU22sp/of3xhuraLAnr3tDLfITNd61XYuO21j96DFTUU1DU4/bMmFQ08LYiil C1CCoWKn917oxO3Ph/uKg7tl7P3H2bhs1tqD5FZ75JUe0aPYmQx+Srd4Z3oVujKWhzG4KrfWUo2x u0McRVYrw49JEOtJGdpPIvuvdBb1j8Udg5bc3yA2W/dGQ3puig6x7j6N7Nkodi5ba+X2pun5Y763 F8iN2blxu5q7MZDG1+SrNsb+wNPHT0T1Bphi4ZKip80pp4fde6h7j/l9dh772O2G3931trMbq2b1 Psvp3pauwHUE+19n7S2xs3sXrnsGvr927ZfsfO1+6c92C/VOHx2Uko8hiaSloBPHS048hPv3XukX 238d+5OtN8YnvWDP7y7b7rzfc+V7SXenV/SOIzO1tjJQ9DUvSmF63q+nc33Li8lk9sZfDZHKCgyy bgimxlZJFLXPJ/lFVP7r3S++Ovwp7E2vsJdzb+7DfE9zbz+Pvcmxdwz1G38duHI7S7P+QPam5u3N 679qc1jc/RUG4Kyjr8piaOWgpUpaeZsMHWrImBT3Xuju7fi2P8dOoetdn5vcNDids7HwXWPUODyV ZC9GuSyOnAdd7QxtHj4XrZ/vs7lZKWCCnjaZg8oGoqC3v3Xul1tfeGB3lT5iq2/PXVEGC3NuHZ+R krsJnMJpz21cnPh85BRrnMdjXylDTZGmkjjrqUTUNToLQTSL6vfuvdKb37r3XvfuvdBRs/vHqnf/ AGJ2Z1Ps/eNFnOwOnjt1exdv01HlYm28+6YchPh0GTq6Cnw2YkcYudKlaCoqjQzx+GqEMrKh917o V/fuvde9+691737r3SW2tvXa29RuFtq5mlzSbV3TmdlZ+SkWfxY7dO3nhizmGeWWKOOeqxVRMIpz EXSOYPGW1o6r7r3Sp9+691//1t/j37r3Xvfuvde9+691737r3Xvfuvde9+691TNtv48717K7spsj 2f132LRddbh+QHzV763tTfd5/ApnsThcbsf499GbWzstBV42sqo93bGpKzJ0WMSdYqjHoeJqaaov 7r3QBYj4v9wbj+PW/jvzr3uev3X138F+uev+mdlV2U3mJh3J2buXtDfddXQRUGQoZs9mulTm9sY9 PukmGKWhdGiR4Wv7r3Qv0vUvd2U7iqcfmNl97ZHvTFfLvZ2a2t31lczuOk6l2b8RevsxtaWOnw+V ps7R7Tr/APSFszb1XRZjbEUT5TKZfLSyZAvAkc3v3XuklW9UfJ3E9a9k0ua2J2Pk9v8Axx3L2h0t 0LQ4Ws3xJuzd2E7l7jy/95/kLHj9k1OP3zuXEdefH3cVFhcRQ4p/v6gnLrSzwyuksPuvdBttD407 2ytVSYvsLozsDKdT5v5u9JZGTbmJ6r3ttHC0XXu1+kNyVGS37S9a5rfu/s/tXA7n7By2MocrXVGX nqVp6ItXJS1aNTj3XunOn6m+QM3XmRwHa3TPyF3hvDdXx/xGW+NOK2fl9z43bXW/yH7j3t2n2D2P ubsfOYzcGOpNg722LujeWDaPI5sRCjxuOlggBcMj+690PVH8cu0MvuuDtPd+G7Gy3bWV+fXTtFT7 iWu3tRYjb/TfSGB2bgNzb8pcBBWUGIx2B7Rx/WmRp6nKT0xjyVLlqSK7BotXuvdWgd9bz3xsLqbe G4Osdl5PsHsn7CLEbB2rjaKWsjrd35+rgwuCrc46GOPH7UwlfXJXZaqlkjSDHU0zBtehW917qomn +Nnyj+NG4a93av7kXsv4nfIbq/cXYHx72Zn9s9mUPYlduuPtHEdi7uzm69+bgpc92Rl9w773JPha iA4qE1WqnjhQmnQe690hOuepu4Nvbdx2H3J0521U/HGt7v2onbFb11sztvrzsjuLY2y+n92Pg6/c Xx4zu+d0btwlDmO0cliqbc9ViWiOfSiWSSPwQCST3XumPtLof5LZrMU+1tv7E73666zqOtopfjz1 lFid0d4Uuyd9bx37vbO5erzG/wDbve3UOM6W3zs6myeLmx9duKTK0uHx3koaWd2o9Fd7r3RiKf41 9nZTcFJ2Fuuj7V3F2jP88+ksTQburqjeOOgwvTPR23th7d3L2PFtmgyy4HF0Xa2P61r4q7LNHPHX x5WmVncaCfde6Nx/Lu6vpesPj39tVddbi633ruXsPsvdHYGL3TjcpjsvWZ3M75z2Qx9Qpyp82QxV BtqroqGjq1VVqIKUOdbl3b3Xuj2+/de6/9ff49+691737r3Xvfuvde9+691737r3Xvfuvde9+691 737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X// 2Q== --=_related 0055F1E548257E52_= Content-Type: image/jpeg Content-ID: <_2_09973DFC09973A280055F1E048257E52> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAAlAS0DAREA AhEBAxEB/8QAHQAAAQUAAwEAAAAAAAAAAAAABQAEBgcIAgMJAf/EAEEQAAEDAwMCBQIEAwQHCQAA AAECAwQFBhEABxIhMQgTFCJBFVEJFjJhI0KBF1JxkSQoM2JygrE4ZXaDkqGjs8H/xAAbAQEAAwEB AQEAAAAAAAAAAAAAAQIDBAUGB//EADoRAAEDAgMFBgMHBAIDAAAAAAEAAhEDIRIxQQQiUWFxBROB kbHwMqHBBhQjQtHh8RUWUmIzQ3KCwv/aAAwDAQACEQMRAD8A034lfGTcOyW57lsU2iU2oR0xGpIe kuLCyV8sjAOOmNfUdndkUtuod89xBBXmbVtT6Lw1oUf2f8c917kbmW/bcy3KXDiVF5Tbj7LjhUgB tShjJ/3dbbZ2LS2fZ3Vg42WdDbTVqYCFEnfxG7wRJkNItijLDa1IGHXPg/PXXc37PUTnUKy/qDry FK7K8dF0XZZ1+VddCpTL9u09iYyhtxZS4pb6WyleT0ABJ1wbT2JSo1aTG1CcRIPktae2udiLhYBQ p38R+9mkFRtyhjCScKccz2/x13/27RJ/5Fh/UH6Bbh2tuqVfG3luXDLaQzJqcJuU600TwSpQyQM/ Gvi9ppijWdTabAr2abzUaHLO90+MC5KD47qHsW1Rae5QahDbkrqSlL9SgqaWs4GeOMp+3zrnWq1J WqzDtyizqpU5SIVOhMrkSJLysIabSOSlE/AAB0RZO3d/ESty0rJ2yu60YJuK2rxrRpjlSeJbTCSh wJdCk9w5jKgD8DPzoisDfbxbUfYTdLa+06hT36oxe8hyOJUZXJcU8m0NL4/zJUpZBx9tEV/JWTn9 tEVVp3Vqo8SQ2/8ATx/o5ohqQfVnzS5yAwPjHUd/30RWfVJTsGmS5LDHqn2WVuNsc+HmKCSQnlg4 yemcayqv7tjnxMCVpTbjeGzElU/cviXiUCx7TuFuiLmqrgWtcREnBjIb6OqKuB5cT07DP3GuggNr tpE2IBJ4TEevHMLJsupOeBcEiOMT+nzUiuPd9VKr1ZptPpbFRTTKS3U1yX6k3EaKnHAlDRWscUgp PLmVY+MayJIbUJHwOa3z/ThrkrNh3dx+YF3gP1NuWalLd9UFLzEWVWqXFqTnlIMJc5ouBxxOUIAz klXxge7uNbObDyxt4JHlnblrw1WYduB7rSJ9n6p1CuuiVKrSKXErECVU4+S9CYlIW81ggHkgHIwS Acj51m3eGJtwru3SA6yhNr7xPXPGoT7dHjxm6jUpMBwPVRtCmg0SOaEqCS6Tj9KRkaimQ9tN5sHs LukadOJyGqVNw1B/i4N6zr+2uilsO/7YqEuNFi3HSJMqVnyGGZzS1vYJB4JCsq6pUOn2P21YAuMD 3r6I7d+K2ninKrroiK4miqrEBNYUMinmUj1B9vL/AGeeX6evbt11Dd6cN4R26AXWlC9zr3/s4sep XEIX1Eww3/o3m+Vz5OJR+rirGOWe3xqhcQ5rQJLjC0Y3GSORPkJUVoe8FcTd1Hod2WU7a/1gOCDK TU2piHFoSFFKuAHHp8/fHTuRq0NJc0mCBPgM78vek85duCoBLTAnrkpzTL1t6tPlmn16mT3g0Xy3 GmNuKDYPErwkn2g9M9s6qbAuOQz5a+l1rBDgzU2jmu6h3TRbnQ8ujVeBVkMkBxUGSh4IJ7BXEnGc Hv8AbUwYnRVkTCidY3jpMW6rao1LdhVwVaW7EefhzkK9GpCQr3JSFZJ+xKe2q0yKj4/LhLp0sJU1 Pw2FxzBaI6kj6KUt3hQXocSW3W6cuJLe9NGfTLbKHnckeWhWcKVkEcR16atBkDU3HTihtJOmfLrw XJ+66JFrLVIfrEBmrOgFuA5KQl9eeow2TyPY/HxqBvSBpn5T6X6Id0Am0/x6oVam51t3tV6rTaNU 2ZkmnL4OhC0+/tlSBnKkgkAqxjPYnRu/T7wZTH79Dpxg6I/cf3bs/duo14TxTfcfcdFhNUyPGpj9 crlVeMen0yOoILygMqKlnohCQRlWDjI+MkUkuf3bBJiegHu3GFaAGGo4wB6nIe/WAhdn7rzqpdf5 Zui2H7SrbzCpURtctEpmS2n9XFxAA5DqSn7Dv8a0GFzXEG7bnpx87freM3EsLZFnZHnw8r+xMpg3 3bVUmxocK4aVLlyUlTDDE1pbjoGclKQrKgOKu390/bQAmY09/UKzt34rJwq66IiuJoqqxATWFDIp 5lI9Qfby/wBnnl+nr27ddQ3enDeEdugF1pXW1elvv1L6c1XaY5UPMW16RExsu80DK08M5ykdSMdP nUAgjEMonw49OakjCYPuckzG5dpLp0+e1ctKkxIDfmynI0xt3yU9gVBJJ6noB3J6Dro4hrcZy/VS AXOwDP3Plqg9O3bp9xN2xJoaYtQg1iQthxbtQZYdjFKeWPKJJcX1GUJ9wBBOrhpxtY7VpdxyAMfQ kWBCzLhgLhoQPMkT9QMypO3dlDeraqM3WaeusIzyp6ZSDIGByOW88u3Xt21Vu8CW3j+PWys7dIDr T/Pomz1/2vGlemduSkNSfPVG8lc5oL80EBTeCrPIEjKe/UffRu/AbecuaO3ZLrQj+iKvdzLPskU2 rXVcluUupPQIi31yZkZK1cEJJCckdvjGurZ620B7aFNxElYvawNLnBYQ8Elpm/fEEqvKjhmBSUPV JTaE4QhbpKW0AfGApXT9tfddu1fu+xCn+Yx5Lx9jbjrOedFLfxCrIt6y1WcaDRYVIMlEtTxhspb8 wjgRnHfudcv2fq1Kwqd44mIVtuY1obAzVs7yWLbts+Dyr1Gk0WDTZ02iwPUyIzCULe97R9xHfqSd eVsVarW7Tax7iYJj5rp2hoGzSBoot4IbJsa49nZcm5aRRZ04VR9AcqKG1OBHFGB7uuO+untuptFP aQ2kTEDzWeyNpmnLlR34oF7X/Ze7G0ln7VXFVLcbq9NMaNT6LLVHaecVI4NjCSB8gDXyRcSTOeq9 cRFsli2s2D4iWfE1TaBUJtbVvEuOlcWQ5PJlhrgopw7noOIV86hFrP8AD3uHdK6PFHfm1u71yVmu x4tuzItQotWmqkNBZcZQroSRnitQz+50RUfVtt6/QtofELsx9NnVBdj3LDrNKWy0pYQFvGOpIwOh cacaVj546Ir/AKM5VfEJ+IHshRa1CfjSbBtSHLrEV1PvjSm2fNUlY+FB1xpJB+Roi9UGkjBP7576 Is9JAHjoJ+fymR/8o0RaK0zsUWYrM2eqtQvq86PVoD7VvQIk6LR3XmFJaV6pfLk2o9FYGckHI6A6 wa0/cnf5gBo54SXA+ceC2e4Damn8pJcf/ZoBHlPOya2xZV0Sdi9wJlXpE4XHUm2ITcMxnPPcajob bQQg+459x6DrgntrbajioNw3LnYj4uHpE9CsqAwVyDk1paOGRy628VM7L25M/cy8qnUqIUSEU+nI pc6dEPFt0RgFKaUofqSpKclPUEa0rgmnX7s7znvg8jMeBnxWdIgHZg8S0NuPEWI49VW+z22lxUy+ 7fZqMKs06bSZbjrz4tyOiOsZUFgz/NSt1KkqIGQrv0BAzq9FzZxCwwkQbaRlqQYjztcqKzXXaTMu BnPWczlz/Wyktn2lXIyNvPOo1Qa9LcdSfkc4rifJbVy4rXke1J+Ceh1xsBFKiOFF4PUgwOp4LWvc 141qNI5jj0Qi3Nqn4G11mTU2rJYudu6GnpL3oViWhkPK9y+nINhISevt7H5zrsaQ2ts8ZRf55/v0 Va++Nqm8zh+WXzyQlW19z/2jToc2NWWpTtcM5ipwrcjymiOYWhwzluoWgdOqM4GMYJONY7FuCkHZ tzmw53/MD4zlEqds3+8w5Oy16CNIy06wr88RFJm1zZ6vwqdDkT5joY4R4rSnHFYfbJwlIJOACf6a zLcVWloMQvwsbrakQCZ4H0K42tshTKBXIddmVu4bjqENpSYn12eZCYxWMKKBxGCR065H7ZAOprGK dQMFyCJ1i9vf1K46YL2MxWyMaTb0VZ23tDOc8Nk+NBoHorvneZ54fY9PLfbEnkWitQCglSEDAJwe n31euQ0UoEtbhJA118wT1ta662720VjOZcAeo05HyXXSrPn3fcNWm2nZtQsKALbfpzrU2P6Ey5K0 q8sJSP1YOP4h+3XHTUVWucysZkOiB0IJMZCRLYyvzdGVIhr6IIu3M8iIzzN7+HRC7Rt1527dsEQd uKrbj9HUtmrVJ6nltDznl45FYGVpyCeasfqwNaGKtV7mGGuY4AG18Jz4ZxObtbhZOaW0e7ddwcDP LF8+eggcU3odJuWNQrItJ6z662/Q7rblS6gYhMUt+cshSFjqpOCSVY4gAdeo1NFwfUo1DaGOBniR 78cpWm02btIF8ZkRwj15I4u2l0q6bkp1Y2wn3VWajXjPgVppPlMpYUtJRylp9zPDiTxH+BxnWWyj dpM+FzSZPzxf7Tw/+rKdouXuNw5oAHyjl1+l1L9mreRam5t+QnbXkwFSJjkmHVRTw3FMc8f4KHsf cg8R09p+RjVqFtlwZEOPiMh5Qek2zSvevjN5DecGL+fHjmiu79IrFNuy0b3pFKfrwoin2ZlOi9X1 MupCSttP8yk/3R1OR8ZIpTd3VVziN1wg8oMj1vwhWeO9pBgN2mRz4j5W+tghlMeq+6u6lAuFVtVW 26FbseThdajiPIkPuo4cUt5J4gdeWcd/nVHtwUq9Vx+JuEDpck+n63ilQ4w2kBrJPTID68uFppmw 7dXcll2hTqPZMxqvqrQnG6kxk+QGUPOcip8HKSOOPLOP0gjJIz2U7VqLvhDQC7mIy5zPh8OUptNz tLTcuJA5G3l+6dq2vuf+0adDmxqy1KdrhnMVOFbkeU0RzC0OGct1C0Dp1RnAxjBJxrDYtwUg7Nuc 2HO/5gfGcolTtm/3mHJ2WvQRpGWnWFZdo2Q7SoW6deVaDNSuJyrTzT0VOHkyGSn2hBUMqbXyWCEn Cu2dYgmnsdNrReLjXMZjOwEgcclqYftUk2hsdQDkdDpOmqhFsWXOuC6qhJNl1CjQalbEmKuPJorU SOJmQrihttPRIUAUF0lZ4j3HAxeo2KNdrTNgW8bHynOwvF9ZVKbpqUC4RDr8Ijzi9ybEyABcItZN Anu0radmNatUor9LqLyKkqRTFMfxPIA89XTqk5A5qxkpx8a6KsvrNLDA7t4HI4QPCTJHHPNc43aL muEnG09RiJ+Qz4IJSrCq3prftlqxqhAvSDWxLl3apgCOtoLUsrEodV5SR7PuPv01FAt7yi9owtYN 4cdCI1n9vhutNoBis07xed08NQeUe96yfVzatyo2bu5OetV+TXn6645TXlQVqkLa81JCmemSkgr6 p6Ed841zU5Zs+z4bOBvx0z9810SHbQ/F8OAdJwn5zC09TgtNPihwKDgaTyCu+cDOddVWO8dGUlcV AEUmA8B6LOfj0vv8q7Ju0lp0ol1+UiGAD1LQ97n/ALDH9de12Hs/f7WHf4rn21+Gnh4oR+H3Yf0H aifcT7fCRX5hW2SOvkN+xH9CeR1t9odo7zagwXDQs9gZFLGcyoB+JifdYv24TP8Ao3r0fs1/2+Cx 7QsGq3N/z/qUSj/3LA7f8TOvH7Pt2oOp+q6a99m8lifbHwyX3vJasit2u1EMBLy4p8+X5R8xKQT0 /qNfZbZ2lseyVO6rNkwLrxqNCrUbiYU48fchjbXxF+Fh64ZKIMahR4blQfzyS0lqWguLz8gcSdfm lZwqVXPbkV9OwFrACgV6+JPbaq/ig2zuTGuqI7ZUWmtMvVYZDSFhlxJSf6qH+eslZDNr7nn7l+Mz xOVvaqe5PqlWtmpPUCbT18XFulyNwU2r4OQdEVcUKzvGLTtwLio1MmXEzd8liPVqtHbmD1LyCPKa ec65PROOv20RDdv9nfFVSt3rrmW8muovlK2FXFJizQZSkvYcT5pzk8sZ/poi93aYXDT4/m584NpC wrvyx1z++iKgU/8AboV/4TP/ANo0RaFffbjMuPPOJaabSVrcWoJSlIGSST2A1BIaJOSkAkwFX9X3 9sek1mk04V2FOVUFqT6mHMYWxGCQDyeWXAEA56dycdtS3ecW5WmdOnVQ7dbi5gc+vQaqSUzcO1a1 LEWnXNR58kpUoMxZ7TiyAMk8UqJwACTobNLjkLnkguQ0ZnJAnt56E3YIvBMeoO0lUkRUBLAS44S7 5QWkKUAUE9Qc9v3BAsGkvpMNi+I5SJvw9xa6gkBtRwuGTPOIy45+qKUzcqhT6dUpkmSqitU2UYcz 6un0oZdyMAqUeJ5ApUME9FJ+TjVAQWNfo7LrqOouDzB4KxBD3M1F/A5HoUFlb+WRFueFRjXoLolM reFRamsKiNFOfYtzzPao/AI6576lu8XDKBPW8W5/RQ7dDTxMdLTfl9UTre69tUi0apccepMVyn00 J9QKQ+1IWkqUAB0UAD1+SOmqvdgAcRYmFZjcbi0G4E+v6JhP3YdpluO16TZtwN0lqP6tcjzIJw1x 5cuIlcu3xjOrVfwSQ+0GPGY9VWn+KAWXkT4RPoiFV3QpFHtu36y+1LUzXHY7MOO02FvqU8AU5SFf A6nBPbpnWjmFtcbPqSelsz05qgeDRdW0HuBzXG4d2rbtNEhyruVOBHjueU5Jdo03yArOBh0M8CCe xBIPxnWIIdAGuS1wm64Xpu1RbFpUifOi1h9plpDx9NSpBSUqxj+KpAbSeoyFLBHbv01LjhdhOcx7 4+EqGDvAHNyIn3+/omDG+VvyLiFGTBuASfRiby+hyj7CrjjgEFzv/Nw4f72emrx8X+pj3w8YPJUx Waf8vfj4Su2498LStet0mlzak2mRPXwWS62j0XtCgZKVrStrII7p/wAcaq2HPLJ430tmJGvDj5qx szHHC2t9Y4cUPq/iAoFMrL0BmBUqq23IiRRNp/p3WHFyUc2Qj+KFLBGeqUnsf21NMGo5rcpJF+WZ 5AZyoeQxhfnAxW4THnKs7UKUtES0RfCMgg9tVc0OBaciiF2xa9Ms2isUmjxvR09gqLbPmKXxKlFS uqiT1JJ760Li6J0t5Ibuc7UmT1RXVUS0RLREtES0RLREtEXnD+ILeirl3dh26y8TFoUIBaR2Dz3u Uf8AEJCf89foX2epd1s7qoElxhfP9oVMTw0K7tlPFxtzHj2dYFFhVVtwoYpsdTjGEFfHBJP2Jyc6 8DbuyNrpiptD4IXdR2qmcFJqgn4mHX8i/wDDM/6I16P2ZM96ByXP2jkxWzv6sHwUys+0fRoHX/ma 15XZ4ntUDm75SuquJ2VUJ4WfFbaGyG2kug12PUXpi6g7L5RWuaOCkoA6/f2693tbsitttbG2IiFx bJtLKNPCVb3iD8IdjePK3rOumpVSq0FbUQrhyIYSXFMOe7gtKgR366+GfTNF5pHSy9trsbZXnHdH gRteg+Ouh7EtXHVXaDUIbcpdSUhv1KVKaWsgDHHujHb51RWW6dqfBpYP4eLV3bxR7jr9ws02hPty IbrLZ5N8kL9vAZzlCR9hknRFUv4byL28RniU3D8RFwvSYdMdbXTIsVKyGXVKI4spB7oaQlP/ADKz oiBbpXzXfAV+IXULznJm1Tb/AHFw9KKcrVwUoBQT91Mr6hP91WB30ReqMWSmTHbdbB4OoStPJODg jIyNEWfQf9ejscG0z1/80aItCynHGYzzjTJkOoQVIaSoJKyB0SCegz266q4kNJaJPBWaAXAOMBZU o0quv7p3lMuOjvTa8gRmyKTUKoymG0pHMMhUJhzkAOOeeAVJJHLJOppANomDMuMm9yLZcBprGaiq SajZsMNha08+PHTgjFr1CdX6zubSJqrjRTW6QyW6XGmzZMlOUnkGfWNpc5L7dUfPTIwdUcMey1NT ibGXO2tuPJWacO0U4tuu9c9LjSNeahtft+tR9iJblw+qiSkBnhErNZVESwhBHlNMwW/YslDas+YG 1khRAOMnSq4NdTeYJBk6yTEiMgAHDIyBIMCAq0RONosIPK2hJzJJGogmIkyVPLM3FYt6yLyuSl0q 36dHhw21w34tD+nCcs5SglPqFOLR5nNAPFIJCsKyFAWrYmMhtyXAAcRxgakGRqBBi9s6DQ5zQdGk zzGk6wYB58LSco+y12PWLVqSL0ap8S4T6uTG+mOuORFOYU6224uSVcVZIVyyT17EnUVaTWgUJlrD bmAZA6Tf1JVqVUvP3gCC4DwMZ9f2iIRK/BItax6Pa1diQbujVidHo7LKXJFPSlJGUlxwuPuKwUDJ BB//AE8/eawYRcy6f/GD7vdGD7vSc8Gwgedj7i2igsatwK9Pj2iLXmuvSahOoq4ki9al6MCM0hSu uDlCgogJ4fA+/Ss9+3vDeW479Y85EqT+BIyjCLf7SmtYambq0uxZVAoVegIYRJp6mKa81IjQ4iOT LnFx9KB5y0gJSoqBAGep7zh72r3jzIe0EzzJsOp+KNNCFJ/CYaTc2OgdQAZPSd2ddQURuS3I0So0 O3LkYvCfPWpTNuimvxY7EYsgKDjQVKUorSP531E4OABgASHOqVC5p/EAmeUnTKDrMuMXMqsBlOD/ AMdhHMiBPMXy3ReBC+bnWkFVi2ZM+emoXnMhobmQ5tGTIL0dvkVKQ23FmJad5KHJQynocdNVGEVn hgtmeRgNBBjKQZHQc1Yz3TS43BIHSSTrcwRB4X4hRirWfT3XYTNZjs0ChyHhHmSVW+UOkLGEpac+ jMBtfLHUr1ZjRUqNYTnYaEnTXLiOCq5xYwvGmfADX9uaOXzajlRuTcVuK7VXYdIpsdqog1tqMJEY M+chtDYhOdU8CMlWTk9cKI1k6pipvrvFnPJ8QbHoJEdNSFqxkPpUmZ4YHQyD55n5ZBRVNRbp12/m CPJLtRiSaE9DpMktKXLS7ECFIShtCOS0JcHEoSAPt112UwRXaDeX1GnoYl3yvpfhZcj4+7SMmsBH VrzA8p52Wydc63S0RLREtES0RLREtES0RLREtES0RLRFQ26fg8snd68ZNzVJydDqUhKW3jEd4pcK BxSoj74AH9NetsvatfZaeBmQXHU2WnUOIoNaHgUsWybrpNwQZ1VVLpkhEllDr2UFSewI+2tto7b2 mvSdSdEFZ09ip0yCMwprvf4crc8QK6X+YJExj6YHEtekc4554zn/ANI1x7Ht1XYCe61XRW2dtcNL lKq7tpR7j25VY9QS4/RnISYKsq/icUgBKs/cYBzrmZtL2VxtI+KVqWBzMJyVDq/Dq284kfUqyBjG PPHb/LXv/wBxbUy4AXnnYKZMrRVl2vFsm1aXb0JS3IlMjojMrdOVFKRgE/vr5urVNeo6q7Mlek1o Y0AKpa14Q7XrniYpu+L9RqAuWBHSw3ESpIjkJQpAyMZ7KOqqVcF1W1AvS2KtQKo151NqkVyHJbz+ ptxJSof5E6Ihu2m21vbSWZS7UtanN0yiU5ryWGEd+/uUo/zKUepJ7nREJ3a2WtLemFSIV1UtuoN0 ue1VIiz0W080oKGD/dOACPkaIrAT8fb7aIqtRtyhXiL/ADt9QcDoopp/ofLHAjkDy5Zzn9tEVq6I gsWz6TBqVaqEeOtibWQgTX233Eqc4pKEkEK9hAPdGD899REM7sZST4nNTMvDzmLIfTdsrfpJqy4z M1MiqpQiZLXU5K5DoQMJHnKcK04Bx7VDpoQHM7s5TPv36lAYcH6gQmKdkLBTLjSfyjSS5HaLKAqM koKTjqpB9q1dP1KBV369dWm5dx92GQ8OmSroBw93Ovj1ShbJ2RBQtCLfYeSot4Epxx/yw2srQlHm KVwSFEninAOSCCNGktiNIPOQIF8zAsJRwDpnUEcoJk2yub9bqcahSgd1WVRL3YhsV2nN1JiJITKa ZeJ4BwAgFSQcKGCfarIOeo1EAOD9RPzUycJboUAb2MsNpxlQtmGttmS9LRHc5LYS46lKVnyiSjGE JwnGE4GANBYRyjwmfZzUG884+WXr46p5C2ltSn0yNTWqUVUqPzKKc9JediqKlFRK2VLKFnkcgqSc dMYwNSbxN4EXv7N88+aaki0mTFvYtlkm8nZm1pcuHKdZqipELl6Rz63OBjZGCGsPewYAGE4GABoJ BxTfjqepzKGCMMW4acrZW04J3P2rtWryKc/VKSisO09pbMdVVdcmYSo5PLzVK5nPYqyR8EaWxF0X IA8Bl/OZ1T8obNgSfP3lkuidsxYs9ttKrSpLBbcS6hyHFTHcCknI97YSrGfjOD86lpLXNe3MGQoc A5pYcjZdlX2js64KlVKhU7ehVCdUkJRIkSUFxeEo4DgSf4Z4/KOJ6A9xnVA0BuEZTPs5/RXxGQeH 85Ilblj0S0pEp+kwvSOyWmGXVeatfJDKPLaHuUcYT06d/nJ1oXEgg6knxOazDQIjQR4TKO6qrJaI loiWiJaIloiWiJaIloiWiJaIloi//9k= --=_related 0055F1E548257E52_=-- From nobody Wed May 27 08:51:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526861B2D97; Wed, 27 May 2015 08:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv8TfbdOzErP; Wed, 27 May 2015 08:51:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADBA1B2E1E; Wed, 27 May 2015 08:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20039; q=dns/txt; s=iport; t=1432741892; x=1433951492; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rLCPMgPZvew6SBdfOCErBo+MdMce9Ag+wC5i0d/9GKI=; b=MBd+qYRwsmtsyg9BpCj2yu1eOsN1uB9vkavnsG42CaaZSMuRDukxPRvI LbUm025hEPTNQWZ3Aplg9HBXXH+4q+gxP4qhb7NicFKDAiBj3eBKjEdan OAGqXvmEFoXu+gBJ3X7POZs9ny6eU+E1qlA/UZEqZT+IPBzgkEyNiuGE7 o=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BhBgCT5mVV/5xdJa1TCYJFS1RRDQazJo1RPIIOhXUCgT1MAQEBAQEBgQuEIgEBAQMBHVwFCwIBCBIGDRoHMhQDDgIEDgUOiBcIDdExAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s6hClYBAeDF4EWBZBMgjyCEoFDYIZaAYEoPoMzkhUjg3hvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,506,1427760000"; d="asc'?scan'208,217";a="423104413" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 27 May 2015 15:51:31 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4RFpVWC022588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 15:51:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 27 May 2015 10:51:31 -0500 From: "Carlos Pignataro (cpignata)" To: "Gonzalo Salgueiro (gsalguei)" Thread-Topic: 2 week WG LC for draft-ietf-i2rs-traceabilty Thread-Index: AQHQmJT/G84nv2mRhUmMuFoWysqLBQ== Date: Wed, 27 May 2015 15:51:30 +0000 Message-ID: References: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> In-Reply-To: <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.54.90] Content-Type: multipart/signed; boundary="Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "Joe Clarke \(jclarke\)" , Alia Atlas , "netconf@ietf.org" , Susan Hares Subject: Re: [netmod] 2 week WG LC for draft-ietf-i2rs-traceabilty X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 15:51:39 -0000 --Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C Content-Type: multipart/alternative; boundary="Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526" --Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I do not know of any IPR relating to draft-ietf-i2rs-traceability-02. Thanks! =97 Carlos. > On May 26, 2015, at 6:05 PM, Gonzalo Salgueiro (gsalguei) = wrote: >=20 > I have no IPR to declare related to this draft, nor do I know of any. >=20 > Regards, >=20 > Gonzalo >=20 >=20 >=20 > On May 26, 2015, at 5:54 PM, Susan Hares > wrote: >=20 >> This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 = from = (5/26 to 6/9) >> (http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ = ) >>=20 >> I2RS Status: WG LC (5/26 to 6/9) >>=20 >> Carlos, joe, and Gonzalo =96 please indicate whether you know of any = IPR on this draft. >>=20 >>=20 >> This document is a companion to three other documents for I2RS = requirements which have WG calls: >>=20 >> 1) This begins a 2 week adoption call for = draft-haas-i2rs-ephemeral-state-req: >> = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ = >>=20 >> This document covers requests to the netmod and netconf Working >> Groups for functionality to support the ephemeral state = requirements >> to implement the I2RS architecture. >>=20 >> Status: WG adoption call (5/26 to 6/9) >>=20 >> 2) draft-haas-i2rs-netmod-netconf-requirements-01 = >> = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirement= s/ = >>=20 >> [This draft is an early set of requirements from which the ephemeral = state and =93identity, secondary-identity and priority=94 were pulled = into draft-haas-i2rs-ephemeral-state-reqs. The = notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments. The traceability had been = separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion. This draft is being requested to be adopted as a = general roadmap for the I2RS WG. In the future, the I2RS WG will accept = more detailed specification on the mutual authentication or the = transaction protocol. >>=20 >> I2RS Status: WG Adoption (5/26 to 6/9) >>=20 >> 3) draf-ietf-i2rs-pub-sub-requirements-02. >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ = >>=20 >> I2RS Status: WG LC (5/26 to 6/9) >>=20 >>=20 >> This thread is to discuss WG consensus on = draft-ietf-i2rs-traceability-02 = . = Please discuss the merits of the traceability framework described in = this draft as being part of the requirements forwarded to = netmod/netconf. Also discuss if this framework provides the necessary = things for I2RS deployment. >>=20 >> This draft will also be forwarded as part of the requirements to the = IESG. >>=20 >> Sue Hares --Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I do not know of any IPR relating = to draft-ietf-i2rs-traceability-02.

Thanks!

=97 Carlos.

On May 26, 2015, at 6:05 PM, Gonzalo Salgueiro (gsalguei) = <gsalguei@cisco.com> wrote:

I have no IPR to = declare related to this draft, nor do I know of any.

Regards,

Gonzalo



On May 26, = 2015, at 5:54 PM, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 from (5/26 to 6/9)  
(http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/)
I2RS Status: WG LC (5/26 to 6/9)
 
This document is a companion to three = other documents for I2RS requirements which have WG calls:
 
1)      This begins a = 2 week adoption call for draft-haas-i2rs-ephemeral-state-req:
https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-stat= e-reqs/
 
  This document covers requests to the netmod and = netconf Working
   Groups for functionality to support the = ephemeral state requirements
   to implement the I2RS = architecture.
 
Status: WG adoption call (5/26 to 6/9) 
 
2)      draft-haas-i2rs-netmod-netconf-requirements-01 
http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-= requirements/
 
[This draft is an early set of requirements from which the = ephemeral state and =93identity, secondary-identity and priority=94 were = pulled into draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.
 
I2RS Status: WG Adoption (5/26 to = 6/9) 
 
3)      draf-ietf-i2rs-= pub-sub-requirements-02. 
 
 
I2RS Status: WG LC (5/26 = to 6/9)
 
 
This thread is to discuss WG consensus = on  draft-ietf-i2rs-traceability-02 .  Please discuss the = merits of the traceability framework described in this draft as being = part of the requirements forwarded to netmod/netconf.   Also = discuss if this framework provides the necessary things for I2RS = deployment.
 
This draft will also be forwarded as part of the requirements = to the IESG.
 
Sue Hares 

= --Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526-- --Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C 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 - http://gpgtools.org iQIcBAEBCAAGBQJVZegBAAoJEIXgpQGOZny9SaEP/0jBga0U+oiZlSm7K0jQ+NUa 1r49iW03CZP3ormv62G3W15I4YWPxqfHgt1XpgY+Fu9iEKldXTWAgFV03JtngY9M RFrkaM0hwlxDHKT+tHvpew81T7dBjQ+QL4ptUWFdFyUDCu8P5zWx0C0hL2yB9oUv +SQkptA4hCXFcM3pQXs2+Jvphgakle9XwOqXNn0CjWZ71J3BW0dkT5PmyNp1okf+ yE6/HchAxqlGvLCCoHEmpHmdn6JU77yGu/EM7I49xlWOnH/Mc3JDTlmIKUyq5Gjy /w+7OOaei7iYPMFL1vpIz00/OcCTkfBogk8s2csy/KwKUj85DnqkY+oZ3DcFH73+ 2itlWghr7+XuSg2BhZoA7IEGM9j/SeWOitqvgAUO41mc4nLRDjAN9w9RNJMN6eZP wJoxjS1klwLIZZncI9gQBvtcXE9yWZLy/QcgiglP9B6EBAWjlQwO+kYj6oo5M1Xs A8vgHksBa1DZ4M8k1rqGnaeErnRlmWA+aGBVCjhazXLWqbCzGywH3IIPGAjn2Fax RqxGSy+LZFMP0w2BrNV3cF2CTsm5pDEHuC/9BgNVZSsJJxYnXI1IAjg4okADoOyC e31hS+VLGssah/Qmbd4zvWaC2VYRvvymh7js2kxxPsINRy1XWxjlmxIi0dZN2irO Q5/u5Q23qKRpYMrO1mf9 =j1Kw -----END PGP SIGNATURE----- --Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C-- From nobody Wed May 27 09:41:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E021A7D82 for ; Wed, 27 May 2015 09:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzdJgeaHVxGw for ; Wed, 27 May 2015 09:41:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA4A1A7D80 for ; Wed, 27 May 2015 09:41:23 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 1122A1AE0714; Wed, 27 May 2015 18:41:21 +0200 (CEST) Date: Wed, 27 May 2015 18:41:39 +0200 (CEST) Message-Id: <20150527.184139.1637425437174998580.mbj@tail-f.com> To: feng.chong33@zte.com.cn 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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: xiao.yuqing@zte.com.cn, netmod@ietf.org Subject: Re: [netmod] A question about updating model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 16:41:24 -0000 SGksDQoNCmZlbmcuY2hvbmczM0B6dGUuY29tLmNuIHdyb3RlOg0KPiBIaSBhbGwsDQo+ICAgIElm IEkgd2FudCB0byBhZGQgYSBuZXcgY2hpbGQgZGF0YSBub2RlIHRvIGEgY29udGFpbmVyIG5vZGUg b3IgbGlzdCANCj4gbm9kZSwgaW4gb3JkZXIgdG8ga2VlcCBiYWNrd2FyZCBjb21wYXRpYWJsZSwN Cj4gc2hvdWxkIHRoaXMgY2hpbGQgbm9kZSBiZSBhZGRlZCB0byB0aGUgZW5kIG9mIHNvbiBub2Rl cyBvZiBwYXJlbnQgbm9kZT8NCg0KTm8gaXQgZG9lc24ndCBoYXZlIHRvIGJlIGFkZGVkIGluIG9y ZGVyLiAgU2VlIHNlY3Rpb24gMTAgb2YgUkZDIDYwMjAuDQoNCg0KL21hcnRpbg0KDQoNCj4gICAg Rm9yIGV4YW1wbGUsIA0KPiAgICBjb250YWluZXIgYSB7DQo+ICAgICAgICBsZWFmIGI7DQo+ICAg ICAgICBsZWFmIGM7DQo+ICAgICAgICBsZWFmIGQ7DQo+ICAgIH0NCj4gICAgSWYgSSB3YW50IHRv IGFkZCBsZWFmIGUgYXMgYSdzIGNoaWxkIG5vZGUsIGxlYWYgZSBtdXN0IGJlIHRoZSBsYXN0IA0K PiBjaGlsZCBvZiBjb250YWluZXIgYT8NCj4gT3RoZXJ3aXNlLCBpdCBpcyBub3QgYSBiYWNrd2Fy ZCBjb21wYXRpYWJsZSB1cGRhdGU/DQo+ICANCj4gDQo+IA0KPiANCj4gDQo+IEZyYW5rIEZlbmcg ICDlhq/lhrINCj4gQk4gUHJvZHVjdCBUZWFtDQo+IEJO5Lqn5ZOB5Zui6ZifDQo+IA0KPiBBZGQ6 IFpURSBDb3Jwb3JhdGlvbiwgNTAgU29mdHdhcmUgQXZlbnVlLCBZdUh1YVRhaSBEaXN0cmljdCwg TmFuamluZywgUC5SLiANCj4gQ2hpbmEsMjEwMDEyDQo+IOWNl+S6rOW4gumbqOiKseWPsOWMuui9 r+S7tuWkp+mBkzUw5Y+35Lit5YW06YCa6K6vDQo+IE1wOis4Ni0xODkxMzg1MjYxMg0KPiBFLW1h aWw6IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWlRFIEluZm9ybWF0aW9u IFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwg KGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBh bmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2Yg dGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwg YW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3Nl bWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxl YXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K From nobody Wed May 27 10:34:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703CD1A88C7 for ; Wed, 27 May 2015 10:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ2YmiM1DRZD for ; Wed, 27 May 2015 10:34:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74BF1A88D0 for ; Wed, 27 May 2015 10:34:38 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB283.namprd05.prod.outlook.com (10.141.70.142) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 27 May 2015 17:34:37 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 27 May 2015 17:34:36 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) with mapi id 15.01.0172.012; Wed, 27 May 2015 17:34:36 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] scheduling interim meetings Thread-Index: AQHQmKNm3TIAxP7ggUqTUfGv0PjAmQ== Date: Wed, 27 May 2015 17:34:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB283; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(51704005)(189002)(164054003)(199003)(479174004)(64706001)(40100003)(62966003)(450100001)(66066001)(36756003)(77156002)(15975445007)(102836002)(2900100001)(101416001)(92566002)(122556002)(5001830100001)(68736005)(4001540100001)(46102003)(86362001)(50986999)(99286002)(105586002)(106116001)(87936001)(2656002)(54356999)(5002640100001)(4001350100001)(83506001)(2351001)(106356001)(5001860100001)(19580405001)(81156007)(19580395003)(189998001)(97736004)(5001960100002)(110136002)(107886002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <726CB669BFB96F49BBD61DD33A775F2A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2015 17:34:35.6068 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [netmod] scheduling interim meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 17:34:40 -0000 There has only been one response so far. Please respond by tomorrow if interested in having time during an interim meeting. Thanks, Kent On 5/22/15, 5:39 PM, "Kent Watsen" wrote: > >Following up on=20 >https://www.ietf.org/mail-archive/web/netmod/current/msg12549.html, and >also to help other drafts progress, we'd like to schedule 3-4 one-hour >virtual interim meetings before the meeting in Prague. > >The first meeting is already set in terms of time and agenda (see below), >but the other slots remain open for signups. To accommodate IETF's >2-week announcement requirement, please send your request for time before >next Thursday (5/28). > >Tentative schedule: > >Fri 6/12 11:30-12:30 EST: modeling operational state >(draft-openconfig-netmod-opstate) >Thu 6/18 10:00-11:00 EST: TBD > >Thu 6/25 10:00-11:00 EST: TBD > >Thu 7/02 10:00-11:00 EST: TBD > > >Please send your request for time to netmod-chairs@tools.ietf.org. > >Thanks, >NETMOD co-chairs > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Sun May 31 19:54:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608A61B2A19 for ; Sun, 31 May 2015 19:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIUWc3NWHm7d for ; Sun, 31 May 2015 19:54:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83811B2A03 for ; Sun, 31 May 2015 19:54:29 -0700 (PDT) Received: from BY1PR0501MB1111.namprd05.prod.outlook.com (25.160.103.145) by BY1PR0501MB1110.namprd05.prod.outlook.com (25.160.103.144) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 02:54:06 +0000 Received: from BY1PR0501MB1111.namprd05.prod.outlook.com ([25.160.103.145]) by BY1PR0501MB1111.namprd05.prod.outlook.com ([25.160.103.145]) with mapi id 15.01.0172.012; Mon, 1 Jun 2015 02:54:06 +0000 From: Norm Strahle To: "netmod@ietf.org" Thread-Topic: need input on diffserv Yang model Thread-Index: AdCcFjiBpihULBRfSJKIcfXzi9C37g== Date: Mon, 1 Jun 2015 02:54:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nstrahle@juniper.net; x-originating-ip: [66.129.241.14] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1110; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BY1PR0501MB1110; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1110; x-forefront-prvs: 05947791E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(33656002)(2351001)(99286002)(68736005)(107886002)(5001960100002)(64706001)(77156002)(62966003)(450100001)(5001830100001)(122556002)(229853001)(110136002)(5001860100001)(189998001)(97736004)(66066001)(5002640100001)(92566002)(74316001)(15975445007)(105586002)(102836002)(46102003)(5890100001)(2501003)(2656002)(101416001)(87936001)(86362001)(575784001)(19580395003)(106356001)(40100003)(50986999)(4001540100001)(81156007)(2900100001)(54356999)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1110; H:BY1PR0501MB1111.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB11115EAA21C76AC317852796CFB60BY1PR0501MB1111_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2015 02:54:05.9118 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1110 Archived-At: Subject: [netmod] need input on diffserv Yang model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 02:54:32 -0000 --_000_BY1PR0501MB11115EAA21C76AC317852796CFB60BY1PR0501MB1111_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey folks, The diffserv group looking at some alternatives for supporting various vendor implementations. The main component in differv model is the policy. Basically it looks something like: policy classifier-1 action-1 action-2 child-policy classifier-n action-x action-y child-policy etc. A classifier will classify on things like address, port, dscp. Example acti= ons are: discard, mark dscp, meter, schedule and queue. A child policy can be attached under a classifier to add further classification and corresponding actions. As shown here, the policy is fairly flexible and extensible. For example, one could have multiple schedulers in a single policy under different classifiers, one could have n-number of child policies, etc. Two issues we are running into are: - in a base model, how do we limit various combinations of classifier/actio= n/ child-policy for vendors that don't support them - how do we limit the model to not support things that don't make sense in general, e.g. a child policy with a scheduler underneath a poli= cy with queue We are discussing some approaches, and are looking to a wider audiance for suggestions. Some approaches we are considering for some of the issues: - if-feature conditions to allow some vendors to not support some function= ality - "must" statements to limit some combinations of classifer/action/child-p= olicy - alternatively using more explicit modules (i.e. less flexible) to restri= ct what capabilities are available - using standard and vendor-specific extensions to define additional capabilities. Likely some combination of some/all of these will be needed. We are looking at two alternatives for defining queues and schedulers. - The first approach is using the generic policy definition above. Queues would be defined in a child policy underneath an action/classifier with a scheduler. - The second approach would be to define explicit queue policy module and a separate scheduler module (in addition to the scheduler action). The queue policy could be referenced by either a scheduler action (supported by some vendors) or a scheduler module attached directly to an interface (supported by other vendors). The advantages of the first approach is that we are defining a very general and consistent approach to a policy module. The difficulty is that some vendors do not support child policies, schedulers as actions, and may be more restrictive as to how one can configure queues as an action. Should a controller request any of the combinations of capabilities that are not supported by a particular router, the router would have to fail the config. The advantage of the second approach is that the rules for applying a sched= ule or queue policy would be much more explicit leading to fewer invalid combinations of configuration that a router vendor could support. Additional levels of functionality could be supported with if-feature or extensions. The disadvantage is that the policy module is not as generic. So, to generalize, I believe the choice is between a more flexible/generic module with routers failing configurations that are not valid, or a more restrictive/limited/explicit base module where invalid configurations are rare. Sorry for the long explanation, but hopefully the explanation is clear. Thanks for your inputs. Norm --_000_BY1PR0501MB11115EAA21C76AC317852796CFB60BY1PR0501MB1111_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hey folks,
 
The diffserv group looking at some alternatives for supporting =
various vendor implementations.
 
The main component in differv model is the policy. Basically it= looks
something like:
 
    policy
        classifier-1
            act= ion-1
            act= ion-2
            chi= ld-policy
        classifier-n
            act= ion-x
            act= ion-y
            chi= ld-policy
        etc.
 
A classifier will classify on things like address, port, dscp. = Example actions
are: discard, mark dscp, meter, schedule and queue. A child pol= icy can
be attached under a classifier to add further classification and
corresponding actions. As shown here, the policy is fairly flexible an= d
extensible. For example, one could have multiple schedulers in a singl= e
policy under different classifiers, one could have n-number of child
policies, etc.
 
Two issues we are running into are:
- in a base model, how do we limit various combinations of classifier/= action/
   child-policy for vendors that don't support them
- how do we limit the model to not support things that don't make
   sense in general, e.g. a child policy with a scheduler un= derneath a policy
   with queue
 
We are discussing some approaches, and are looking to a wider audia= nce for
suggestions.  Some approaches we are considering for some of the = issues:
- if-feature conditions to allow some vendors to not support some fun= ctionality
- "must" statements to limit some combinations of classi= fer/action/child-policy
- alternatively using more explicit modules (i.e. less flexible) to r= estrict
   what capabilities are available
- using standard and vendor-specific extensions to define additional<= /div>
   capabilities.
 
Likely some combination of some/all of these will be needed.
 
We are looking at two alternatives for defining queues and schedulers.=
- The first approach is using the generic policy definition above. Qu= eues
  would be defined in a child policy underneath an action/classif= ier with
  a scheduler.
- The second approach would be to define explicit queue policy module= and
  a separate scheduler module (in addition to the scheduler actio= n). The
  queue policy could be referenced by either a scheduler action (= supported
  by some vendors) or a scheduler module attached directly to an = interface
  (supported by other vendors).
 
The advantages of the first approach is that we are defining a very ge= neral
and consistent approach to a policy module. The difficulty is that som= e
vendors do not support child policies, schedulers as actions, and may = be
more restrictive as to how one can configure queues as an action. Shou= ld
a controller request any of the combinations of capabilities that are = not
supported by a particular router, the router would have to fail the config.
 
The advantage of the second approach is that the rules for applying a = schedule
or queue policy would be much more explicit leading to fewer invalid <= /div>
combinations of configuration that a router vendor could support.
Additional levels of functionality could be supported with if-feature =
or extensions. The disadvantage is that the policy module is not as
generic.
 
So, to generalize, I believe the choice is between a more flexible/gen= eric
module with routers failing configurations that are not valid, or a mo= re
restrictive/limited/explicit base module where invalid configurations = are
rare.
 
Sorry for the long explanation, but hopefully the explanation is clear= .
 
Thanks for your inputs.
Norm
&nbs= p;
&nbs= p;
 --_000_BY1PR0501MB11115EAA21C76AC317852796CFB60BY1PR0501MB1111_--