From nobody Wed Feb 5 02:47:40 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423D0120804 for ; Wed, 5 Feb 2020 02:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQGkLu5_TyoB for ; Wed, 5 Feb 2020 02:47:28 -0800 (PST) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 130CE1207FC for ; Wed, 5 Feb 2020 02:47:28 -0800 (PST) Received: by mail-wm1-x343.google.com with SMTP id c84so2111558wme.4 for ; Wed, 05 Feb 2020 02:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fkKp7Icj8Lbd0np3miI8wE9ebqb5+Arp8Jd8OKM4v1k=; b=bNWP1w5Rv6QgoddqrzcN1a4Wk86IPX2I+vcGQw01cBcdKSeHRsI1a8g/1w5YPcDX8F a5aQmFVoD0ee/LM10lyyk2NUx4BNYx1lKPfhSEuaCSqrJHMwzG+T7LJHLcFPxZfcqVcU +7aVU4IH/M08Vb03dF4vFwFilKyD9p5VAn4s2KgqurMKvblOjmKpXig7+4U4ah/O0H6T Sm2hbUAZfv0fjytA0S1KX4dP0dmdTLxlIUenqTlh6DwS0Dc1/Yt5v30lEuvLWtZzIZTh iT2pvEm9wY86iN1XpjTRmcJpl5O3c8yGzKsQDUkV5GNrhfgk1lgiFgJhKoHU+k4TLhUE LOig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fkKp7Icj8Lbd0np3miI8wE9ebqb5+Arp8Jd8OKM4v1k=; b=QdCl3poQeSe/KNfDtnpRuStegooAf/gaW11BOKdyBGYka3Xewy17eXScMUTmk99A4A Or+kyYfH913DtMC4953SU+gOU2a//2AqT9nyTon/Mh17FhYkYgyrP0JcmXZ7XCnXFBcT c+C/Mc/3gwuuj46zrlXtQWQVvq0WSvullJpONcGtqlcwmbsCfVnZpPqQz7oVfGIiMAAg DVaCkG5mMdXuCPRhqpvoJ237O/gRoukFrdgxr8URXVNgQF1r5fsBI6ICuCOoJSq/Dqfo BmlohX1cPKhTSeXZb14o6YHJlRkCvHeM3KzgJIdLNX0A9ocB0gQjY2tjJkjS/XduXNj3 3Axw== X-Gm-Message-State: APjAAAVZnWhh2spG9OrPRSB81LAGxwLK1Pjn1MieZcCJdQsZyIpozrfZ LQoTH8xDfwx+oB0x7Wq4o7UY8XmfCMhTMdXUdOQBxQ== X-Google-Smtp-Source: APXvYqy+7oTqLw7P9XXno86LD5koMXxmie0C6uCRF4uvhtsOGIpeGEb4XqubsCZmXT/tjJ/1NlNqjGH+jN6k3bt6qxk= X-Received: by 2002:a05:600c:2290:: with SMTP id 16mr5105730wmf.93.1580899646039; Wed, 05 Feb 2020 02:47:26 -0800 (PST) MIME-Version: 1.0 References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> <26398.1579112884@localhost> <0805B57C-3DCB-4601-976C-2D51CE812312@tzi.org> <14603.1579125396@localhost> <18568.1579133839@localhost> <5C3B4919-5513-4342-888D-998A11366D36@tzi.org> In-Reply-To: From: Ivaylo Petrov Date: Wed, 5 Feb 2020 11:46:59 +0100 Message-ID: To: Andy Bierman Cc: Carsten Bormann , Core , Alexander Pelov Content-Type: multipart/mixed; boundary="000000000000d46dcb059dd1e165" Archived-At: Subject: Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 10:47:36 -0000 --000000000000d46dcb059dd1e165 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, In this email I am presenting the change that I am proposing regarding ".sid" file versioning that I believe we all agreed needs to be supported (the new version is available in attachment). I am planning on uploading the new version early next week. Please let me know if you have any questions comments or remarks or if you would need more time to review it and you would want me to wait for a little bit. Add ".sid" file version to the YANG file code snippet typedef sid-file-version-identifier { type uint64; description "Optional attribute that gives information about the \".sid\" file version."; } leaf sid-file-version { type sid-file-version-identifier; description "Version number of the \".sid\" file. Useful to distinguish \".sid\" files generated using different YANG module dependencies that might = not be reflected in the YANG module revision."; } list dependencies-revisions { key "module-name"; description "Information about the revision of each YANG module that the module i= n 'module-name' includes used during the \".sid\" file generation."; leaf module-name { type yang:yang-identifier; mandatory true; description "Name of the YANG module, dependency of 'module-name', for which revision information is provided."; } leaf module-revision { type revision-identifier; mandatory true; description "Revision of the YANG module, dependency of 'module-name', for whic= h revision information is provided."; } } Modifying sec 3. Each time a YANG module or one of its imported module(s) or included -sub-module(s) is updated, the ".sid" file MAY need to be updated. This upd= ate -SHOULD be performed using an automated tool. +sub-module(s) is updated, a new ".sid" file MAY need to be created. All th= e +SIDs present in the previous version of the ".sid" file MUST be present in= the +new version as well. The creation of this new version of the ".sid" file S= HOULD +be performed using an automated tool. In sec 6.4.2 add * If there is an older version of the ".sid" file, all allocated SIDs from = that version are still present in the current version of the ".sid" file. In Appendix B add 5. The "dependencies-revisions" should reflect the revision numbers of each YANG module that the YANG module imports at the moment of the generation= . and again in Appendix B modify -Changes of SID files can also be automated using the same method described above, only unassigned Y=C3=80NG items are processed at step #3. Already existing items in the SID file should not be given new SIDs. +In case of an update to an existing ".sid" file, an additional step is nee= ded +that increments the ".sid" file version number. If there was no version nu= mber +in the previous version of the ".sid" file, 0 is assumed as the version nu= mber +of the old version of the ".sid" file and the version number is 1 for the = new +".sid" file. Apart from that, changes of SID files can also be automated u= sing +the same method described above, only unassigned Y=C3=80NG items are proce= ssed at +step #3. Already existing items in the SID file should not be given new SI= Ds. Best regards, Ivaylo On Thu, Jan 23, 2020 at 11:14 AM Ivaylo Petrov wrote: > > Find my answers below > > On Wed, Jan 22, 2020 at 09:52:43AM -0800, Andy Bierman wrote: > > On Wed, Jan 22, 2020 at 3:44 AM Ivaylo Petrov wrote: > > > > > Thank you for your clarification, I think we are getting closer to > > > understanding the difference of viewpoints. Find my comments below. > > > > > > On Tue, Jan 21, 2020 at 8:29 PM Andy Bierman wro= te: > > > > > > > > > > > > > > > > On Tue, Jan 21, 2020 at 2:55 AM Ivaylo Petrov wrot= e: > > > >> > > > >> Hello Andy, > > > >> > > > >> Find my answers below > > > >> > > > >> On Sun, Jan 19, 2020 at 6:37 AM Andy Bierman > > > wrote: > > > >> > > > > >> > > > > >> > > > > >> > On Thu, Jan 16, 2020 at 9:47 AM Carsten Bormann w= rote: > > > >> >> > > > >> >> On 2020-01-16, at 13:50, Andy Bierman wrot= e: > > > >> >> > > > > >> >> > There is a significant amount of metadata needed to generate = a SID > > > file, > > > >> >> > starting with all the previous YANG revisions or SID files, a= nd > > > when/if > > > >> >> > the SID files have been reset vs. updated with preserved numb= ers. > > > >> >> > > > >> >> Well, specifically, the current YANG module and the previous SI= D > > > file; not the entire history of the universe. > > > >> >> > > > >> >> The need for the previous SID file means that there needs to be= a > > > single lineage; SID files cannot be independently progressed. This c= alls > > > for central entity (or a blockchain :-). > > > >> >> What we need to define unambiguously is who that entity is. > > > >> >> One we are at the IANA, the Designated Expert (DE) can play thi= s > > > role. > > > >> >> But we need to define the process leading up to this. > > > >> >> (Yes, that process will evolve, and we probably also need to al= low > > > exceptions. > > > >> >> But there must be strong guide rails that work for the vast maj= ority > > > of cases.) > > > >> >> > > > >> >> Adding a version number to the SID file could indeed help with > > > accidents/disasters. > > > >> >> But it could also lead to people thinking they can get away wit= h > > > concurrent lineages; thinking that version numbers will fix any fallo= ut. > > > >> >> That would be a disaster on its own, most likely leading to > > > permanent universe splits. > > > >> >> So I=E2=80=99m not so sure we want to open that Pandora=E2=80= =99s box. > > > >> >> > > > >> > > > > >> > > > > >> > We already opened Pandora's box by attempting to create a > > > 1-flat-number globally unique, multi-module, > > > >> > multi-owner object identifier. I think YANG is quite different t= han > > > the MAC address example of success > > > >> > in this endeavour because YANG modules need the numbers assigned= in > > > the development phase, > > > >> > not the manufacturing phase. > > > >> > > > > >> > YANG has many features that make it easier on the writer and har= der > > > on the tool maker, > > > >> > such as no order dependencies, but is has some guardrails. No ma= tter > > > how the writer may > > > >> > possibly alter or refactor a YANG module, nothing unintentional = can > > > change the YANG identifier for > > > >> > any defined data node. SID has no such guardrails. > > > >> > > > >> [ivaylo]: > > > >> It seems that you are implying that refactoring a YANG without cha= nging > > > the > > > >> YANG identifiers and the paths will cause changes to the .sid file= . > > > Could you > > > >> provide an example as I am not sure I see why this needs to be the= case. > > > >> Note that I added the restriction of not changing paths as otherwi= se I > > > >> believe the > > > >> NETCONF representation will also change, so CORECONF will be no > > > different. > > > >> > > > > > > > > > > > > YANG modules under development do not follow any of the "module upd= ate" > > > rules > > > > so there are no restrictions that can be relied on in real YANG > > > development. > > > > This requires the tools and developers to be more careful, especial= ly > > > > since YANG tools have no existing reason to be careful in these are= as. > > > > > > > > > > [ivaylo]: > > > If there are no restrictions to what a YANG module change can bring, = I > > > am afraid we can not provide much help for .sid files. The suggestion > > > that any implementer of pre-WGLC version of the draft might need to > > > adjust her implementation due to SIDs change seems acceptable to me a= nd > > > I don't see how we can provide anything better. > > > > > > > > > > I think that WGs will want to regenerate the files during development, = even > > though > > it often takes the IETF 2 - 5 years to complete a YANG module. Nodes g= et > > renamed a lot > > and every time that is done it creates new SIDs and leaves behind > > irrelevant SIDs. > > It might takes 5x - 10x the required range by the time the WG is done. > > > > It is not even clear that I-Ds (or RFCs) can include SID files, since t= hey > > rely on > > the imports used to generate the file. I agree that there is not much = that > > can (or should) > > be done to pretend that work-in-progress has any stability. > > > > [ivaylo]: > Maybe I failed to provide enough details and I might have been > misunderstood here, sorry if this is the case, but my idea was that > before WG adoption all bets are off for stability of a .sid file. Once a > draft is adopted, the authors should make sure they don't regenerate the > .sid file from scratch for every little change. While renaming could be > done by changing the .sid file (automatically or not) making the old SID > value point to the new name, that might cause other problems. Unless > someone believes this is something we should explicitly allow, I would > prefer to let the authors decide if this would be safe in they case or > not. Once WGLC is done, the .sid file should not reallocate SID values > unless this is discussed on the mailing list. I will add text about this > in the draft this week and publish a new version. > > > > > > > > > > > > > > >> > > > >> > > > > >> > I think there is a practical solution for deployment, which does= not > > > require the use of the > > > >> > centrally maintained SID files, which is not realistic for 4 rea= sons: > > > >> > - no way to apply changes to an incorrect SID file (without a > > > sid-file-identifier) > > > >> > > > >> [ivaylo]: > > > >> I believe currently the way to achieve this is to have a new versi= on > > > >> of the YANG module, > > > >> so that a new version of the SID file can be generated. Having a > > > >> global version of .sid > > > >> file that is an integer that progresses lineary seems as a good > > > >> solution to me. It should > > > >> also be able to accommodate your concern here I believe. As Michae= l > > > >> said, the latest > > > >> version of the .sid file should be able to handle both all clients= of > > > >> previous versions of > > > >> the YANG module and the latest one. As there could be multiple ver= sions > > > for one > > > >> version of a YANG module, errors could be corrected. Does this sou= nd > > > >> good to you? > > > > > > > > > > > > > > > > This will not work at all. > > > > There is no reason to update the YANG module. > > > > What would change? Just the revision-date? > > > > > > > > Even if we ignore all possibility that a SID file can have a flaw i= n it, > > > > there is still the problem caused when imported modules change. > > > > Reusable groupings in a common module are all the rage. > > > > It is very possible that the target module may never even change af= ter > > > release 1 > > > > > > > > module foo { > > > > ... > > > > import A { prefix a; } > > > > revision 2019-01-01; > > > > > > > > container top { > > > > uses a:grouping1; > > > > } > > > > } > > > > > > > > The SID file contents for /top are not determined by module foo. > > > > Over time, module A will keep changing and module foo will never ch= ange. > > > > All of the unspecified revisions imported by module foo determine t= he > > > expansion of 'grouping1. > > > > This approach only works within a server implementation because all= the > > > module revisions > > > > are known to the client via the YANG library. > > > > > > > > > > [ivaylo] > > > I think the difference of viewpoints here came from my assumption tha= t > > > all yang modules import specific versions of other modules. You point > > > out in your email that in practice this is not necessarily the case. = If > > > we want to be able to handle this as I believe we are, I agree that w= e > > > might need to add information in the SID file about what version of e= ach > > > of the dependent modules had been used to allocate any given SID as > > > otherwise we might have serious problems figuring this out at runtime= , > > > if this is at all possible. > > > > > > Storing this information can be solved by having many independent > > > versions of .sid files - one for a given set of YANG modules and > > > revisions or we can have each SID number allocation contain more > > > information than just the path to that node - namely the versions of = all > > > the YANG modules and the revision information. In both cases it appe= ars > > > that this will complicate how SIDs allocation. > > > > > > Andy, do you agree that I have captured the essence of your concern > > > correctly? Are there any thoughts whether we want to solve this probl= em > > > and which is the best approach (even if it is not any of the ones > > > already mentioned)? > > > > > > I might be missing some historical background here, but my personal > > > preference is to go with the second approach as it would allow for > > > linear versioning of the .sid files, which I believe is lighter on th= e > > > constrained device. It seems that your preference, Andy, is to go wit= h > > > the first one and have SIDs be more contextually dependent. > > > > > > > > > > I don't see how the 2nd approach can scale to even 20 YANG modules, let > > alone 100s. > > If there are multiple variants of every SID file, then there is no poin= t in > > an "official" SID file > > at all. Only the mappings for a specific server implementation can be > > used. Even products > > from the same vendor will use different revisions of the same imported > > module. > > > > It is quite possible that common SID files will be practical after > > development is done > > for a module and it is quite stable. There will probably be a mix of > > deployment strategies > > depending on module maturity and implementation details. > > [ivaylo]: > After some more consideration, I agree that it adds a lot of complexity > for something that I am not sure we want to support as a first class > citizen. I agree that we should have support for handling multiple > versions of the dependencies, where I am not that sure is that we should > make this as effortless as possible if that would add that much > complexity. A simpler approach that would fit that bill for me is that > each .sid file version N has all the SIDs present in version N-1 without > changes for any N>0 (assuming that 0 is the initial version). The .sid fi= le > shall also have a field with the list of versions of all the modules that > were used to generate the current version of that .sid file. That way > only traversing the .sid file versions one can discover what versions of > each YANG module were used for the generation of each SID. At the same > time we don't add too much more information to each .sid file. As > Carsten suggested, the latest version always wins. > > The drawback I see is that we might carry around a number of SIDs > that are no longer needed. While in some situations that might be > unnecessary, I believe there is no way to avoid it without risking > ambiguity or requesting a client to do even more work. > > > > > > > > > > > > > > > > >> > > > >> > > > >> > - no way for vendors to apply deviations on any YANG modules, = e,.g > > > deviation { not-supported; } > > > >> > > > >> [ivaylo]: > > > >> I am not sure I see why that is the case. In sec 3 of > > > >> draft-ietf-core-yang-library we have > > > >> > > > >> * 'feature' and 'deviation' are implemented using a SID (i.e. an > > > >> unsigned integer). > > > >> > > > >> While I agree that more details can be added here, I don't see any > > > >> reason deviations > > > >> not to be supported. > > > >> > > > >> > - the SID file generation depends on the specific revisions of= all > > > modules imported > > > >> > and submodules included by the target YANG module > > > >> > > > >> [ivaylo]: > > > >> I agree, but I believe this is a good thing. As is said sec 5.1.1= of > > > RFC6020 > > > >> > > > >> ` modules need to be imported using specific revisions`. > > > > > > > > > > > > > > > The YANG import-by-revision mechanism is fatally flawed and has been mo= stly > > worthless > > since Day One. Perhaps this will be fixed someday but until then, most > > designers do > > not specify the exact revision that must be used. > > > > [ivaylo]: > I believe my latest proposal will handle appropriately that problem. > > > > > > > > > > > > > > > > > This is not how YANG is used 95% of the time. > > > > Even if I import-by-revision, it is very common for that module to > > > > have its own imports, and I have no control over the revisions used > > > there. > > > > > > > > > > > >> > > > >> > > > >> Could you provide more details of the issue you see? > > > >> > > > >> > - vendors are already failing to deploy YANG modules from a ce= ntral > > > source model. > > > >> > The NETCONF and RESTCONF protocols have robust mechanisms to > > > discover and > > > >> > retrieve the actual YANG files used by the server, and vendo= rs > > > rely on this feature. > > > >> > Some vendors need model branching and other complexity that = make > > > SID assignment even harder > > > >> > (see > > > https://tools.ietf.org/html/draft-ietf-netmod-yang-versioning-reqs-02= ) > > > >> > > > > >> > > > >> [ivaylo]: > > > >> I believe that the envisioned .sid file retrieval mechanism is: > > > >> 1. You find the sid that you are interested in > > > >> 2. You check in which mega range it is and who is the operator of = that > > > >> mega range in > > > >> the IANA registry. > > > >> 3. You contact that mega range operator through a given protocol t= o > > > >> obtain further details. > > > >> > > > > > > > > > > > > No. I am interested in loading the SID data from each individual se= rver, > > > as needed. > > > > > > > > I understand some people want to hard-wire SIDs into their client o= r > > > server > > > > and they will not have the YANG identifiers. I am not interested i= n this > > > > deployment option for YANG-Push so the SID values will get added at > > > runtime. > > > > The client will consume or use cached the SID files at > > > session-startup-time, just like the YANG modules. > > > > > > [ivaylo]: > > > You are correct that I was looking much more from the perspective of > > > hard-wiring the SIDs on constrained devices and assume that > > > introspection will be done as needed using the central IANA registry = or > > > other server with such information. If you want to know what .sid fil= e > > > is present for each server, wouldn't the mechanism from > > > draft-ietf-core-yang-library solve that? Or maybe you would like to h= ave > > > a more compact reply that gives only the YANG module name, version an= d > > > version the SID file that can be found on a server - be it internal o= r > > > external one. If that is the need you have, we can see which is the b= est > > > approach to resolve it. > > > > > > > > > > > You can hardwire SIDs based on proprietary vendor information or IANA > > information. > > I don't see how IANA can maintain any SID files though, since the entir= e > > set of imported modules > > depends on the SID file generation date and modules available to the to= ols > > used by by > > authors submitting files to IANA > > > > [ivaylo]: > The proposal to keep track of the YANG module versions used to generate > any given .sid file handles this concern I believe. > > > > > > > > > > > > > > > > >> > > > >> Presently we believed as there are not going to be too many mega r= ange > > > >> registries and > > > >> we have no experience operating them it might be unwise to specify= the > > > >> protocol that > > > >> they need to implement in order for clients to be able to query th= em. > > > >> Specifying such a > > > >> protocol might be something we do if this is a really big concern = for > > > people. > > > >> Would that retrieval mechanism cover the cases that you were think= ing > > > >> of? Are there other > > > >> cases that you believe it should cover? > > > > > > > > > > > > > > > > I think vendors will continue to fill in the gaps with proprietary > > > mechanisms. > > > > The SID file format will get augmented, etc. to support real deploy= ment > > > scenarios. > > > > This could be considered a protocol issue and can be ignored for SI= D > > > files in general. > > > > > > > > How the client gets the YANG and SID files could be considered an > > > implementation detail. > > > > The IANA repo is there but there is no requirement to use it. > > > > > > > > > > [ivaylo]: > > > I assume that one of the participants is a constrained device, which > > > might not be exactly what you are considering, but in that case if th= e > > > constrained device is a client, it is very unlikely for it to try to > > > discover at runtime what are the SIDs that a server will support. It > > > will generally send CORECONF requests that contain some SIDs and assu= me > > > that the server or a proxy in between will be able to understand thei= r > > > meaning. That is where the IANA repository and a protocol for > > > inspection how a SID maps can be useful. > > > > > > Then assuming that the constrained device is the server, a client can > > > discover the supported SIDs either through introspection protocol, wh= ich > > > will be heavy, but might be required in some cases or more likely > > > through provisioning/bootstrap. > > > > > > It seems to me that you are considering also the question if none of = the > > > endpoints is really constrained. In that case I believe the client wi= ll > > > still be able to use the same introspection protocol as before and fi= nd > > > the YANG modules looking at the SID file. > > > > > > > > > > >> > > > >> > > > >> > CORECONF (and SID in general) needs a SID file retrieval mechani= sm. > > > >> > Perhaps based on YANG Data Instance Files > > > https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-form= at-06 > > > >> > A server will make the URI of this resource known somehow, which= can > > > be used if needed, > > > >> > before a client starts using SIDs. > > > >> > > > > >> > In addition, or instead of listing YANG modules, the data is SID > > > files, maybe 1 super-SID-file JSON object. > > > >> > It is not realistic that a client will be able to use all global= SID > > > files based on the YANG module name > > > >> > and revision date, especially in the development phase. The IANA= SID > > > file may be useful after the YANG > > > >> > module is very stable. > > > >> > > > > >> > More solution details: > > > >> > - The WG or vendor can maintain an informal public archive of = SID > > > files. > > > >> > - The YangModels repo update process should include SID files. > > > https://github.com/YangModels/yang > > > >> > - Vendors still need the public SID file for the starting poin= t, or > > > maybe use it unchanged > > > >> > - The SID files need support and probably some t= ool > > > changes in the ID-submission process > > > >> > - IANA will only archive the RFC version, just like YANG modul= es. > > > >> > > > > >> > > > > >> > > > > >> >> Gr=C3=BC=C3=9Fe, Carsten > > > >> > > > > >> > > > > >> > > > > >> > Andy > > > >> > > > > >> > > > >> -- > > > >> Best regards, > > > >> Ivaylo > > > > > > > > > > > > > > > > Andy > > > > > > > > > > -- > > > Best regards, > > > Ivaylo > > > > > > > > > Andy > > -- > Best regards, > Ivaylo --000000000000d46dcb059dd1e165 Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-core-sid-latest.txt" Content-Disposition: attachment; filename="draft-ietf-core-sid-latest.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_k696j4jh0 CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICBNLiBWZWlsbGV0dGUsIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVHJpbGxpYW50IE5ldHdvcmtzIEluYy4KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBQZWxvdiwgRWQuCkV4cGly ZXM6IEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJLiBQ ZXRyb3YsIEVkLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBY2tsaW8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDA1LCAyMDIwCgoKICAgICAgICAgICAg ICAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKQogICAgICAgICAgICAgICAg ICAgICAgICAgZHJhZnQtaWV0Zi1jb3JlLXNpZC0wOQoKQWJzdHJhY3QKCiAgIFlBTkcgU2NoZW1h IEl0ZW0gaURlbnRpZmllcnMgKFNJRCkgYXJlIGdsb2JhbGx5IHVuaXF1ZSA2My1iaXQKICAgdW5z aWduZWQgaW50ZWdlcnMgdXNlZCB0byBpZGVudGlmeSBZQU5HIGl0ZW1zLiAgVGhpcyBkb2N1bWVu dCBkZWZpbmVzCiAgIHRoZSBzZW1hbnRpY3MsIHRoZSByZWdpc3RyYXRpb24sIGFuZCBhc3NpZ25t ZW50IHByb2Nlc3NlcyBvZiBTSURzLgogICBUbyBlbmFibGUgdGhlIGltcGxlbWVudGF0aW9uIG9m IHRoZXNlIHByb2Nlc3NlcywgdGhpcyBkb2N1bWVudCBhbHNvCiAgIGRlZmluZXMgYSBmaWxlIGZv cm1hdCB1c2VkIHRvIHBlcnNpc3QgYW5kIHB1Ymxpc2ggYXNzaWduZWQgU0lEcy4KClN0YXR1cyBv ZiBUaGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwg Y29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4K CiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3Vw cyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURy YWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3Ro ZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdp bGwgZXhwaXJlIG9uIEF1Z3VzdCA4LCAyMDIwLgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJp Z2h0IChjKSAyMDIwIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhl CiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1 bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwczovL3RydXN0ZWUu aWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGlj YXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAg IGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25z IHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJh Y3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExp Y2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKCgoKVmVpbGxldHRlLCBl dCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgIFtQYWdl IDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJ RCkgICAgICBGZWJydWFyeSAyMDIwCgoKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5k IGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2lt cGxpZmllZCBCU0QgTGljZW5zZS4KClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIK ICAgMi4gIFRlcm1pbm9sb2d5IGFuZCBOb3RhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICAzCiAgIDMuICAiLnNpZCIgZmlsZSBsaWZlY3ljbGUgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICA0LiAgIi5zaWQiIGZpbGUgZm9ybWF0 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgNS4gIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDEwCiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAxMAogICAgIDYuMS4gIFJlZ2lzdGVyIFNJRCBGaWxlIEZvcm1h dCBNb2R1bGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgICA2LjIuICBDcmVhdGUg bmV3IElBTkEgUmVnaXN0cnk6ICJTSUQgTWVnYS1SYW5nZSIgcmVnaXN0cnkgLiAuIC4gIDExCiAg ICAgICA2LjIuMS4gIFN0cnVjdHVyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxMQogICAgICAgNi4yLjIuICBBbGxvY2F0aW9uIHBvbGljeSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTEKICAgICAgICAgNi4yLjIuMS4gIEZpcnN0IGFs bG9jYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgICAgICAgIDYu Mi4yLjIuICBDb25zZWN1dGl2ZSBhbGxvY2F0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxMgogICAgICAgNi4yLjMuICBJbml0aWFsIGNvbnRlbnRzIG9mIHRoZSBSZWdpc3RyeSAgLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTIKICAgICA2LjMuICBDcmVhdGUgYSBuZXcgSUFOQSBSZWdpc3Ry eTogSUVURiBTSUQgUmFuZ2UgUmVnaXN0cnkKICAgICAgICAgICAobWFuYWdlZCBieSBJQU5BKSAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgICAgICA2LjMuMS4g IFN0cnVjdHVyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MgogICAgICAgNi4zLjIuICBBbGxvY2F0aW9uIHBvbGljeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTMKICAgICAgIDYuMy4zLiAgSW5pdGlhbCBjb250ZW50cyBvZiB0aGUg cmVnaXN0cnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0CiAgICAgNi40LiAgQ3JlYXRlIG5ldyBJ QU5BIFJlZ2lzdHJ5OiAiSUVURiBTSUQgUmVnaXN0cnkiIC4gLiAuIC4gLiAuICAxNQogICAgICAg Ni40LjEuICBTdHJ1Y3R1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTYKICAgICAgIDYuNC4yLiAgQWxsb2NhdGlvbiBwb2xpY3kgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2CiAgICAgICA2LjQuMy4gIFJlY3Vyc2l2ZSBBbGxvY2F0 aW9uIG9mIFNJRCBSYW5nZSBhdCBEb2N1bWVudAogICAgICAgICAgICAgICBBZG9wdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTYKICAgICAgIDYuNC40 LiAgSW5pdGlhbCBjb250ZW50cyBvZiB0aGUgcmVnaXN0cnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDE4CiAgIDcuICBBY2tub3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxOAogICA4LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTkKICAgICA4LjEuICBOb3JtYXRpdmUg UmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5CiAgICAg OC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxOQogICBBcHBlbmRpeCBBLiAgIi5zaWQiIGZpbGUgZXhhbXBsZSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjAKICAgQXBwZW5kaXggQi4gIFNJRCBhdXRvIGdlbmVy YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI5CiAgIEFwcGVuZGl4IEMu ICAiLnNpZCIgZmlsZSBsaWZlY3ljbGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAz MAogICAgIEMuMS4gIFNJRCBGaWxlIENyZWF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMzAKICAgICBDLjIuICBTSUQgRmlsZSBVcGRhdGUgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMyCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzMwoKMS4gIElu dHJvZHVjdGlvbgoKICAgU29tZSBvZiB0aGUgaXRlbXMgZGVmaW5lZCBpbiBZQU5HIFtSRkM3OTUw XSByZXF1aXJlIHRoZSB1c2Ugb2YgYQogICB1bmlxdWUgaWRlbnRpZmllci4gIEluIGJvdGggTkVU Q09ORiBbUkZDNjI0MV0gYW5kIFJFU1RDT05GIFtSRkM4MDQwXSwKICAgdGhlc2UgaWRlbnRpZmll cnMgYXJlIGltcGxlbWVudGVkIHVzaW5nIG5hbWVzLiAgVG8gYWxsb3cgdGhlCiAgIGltcGxlbWVu dGF0aW9uIG9mIGRhdGEgbW9kZWxzIGRlZmluZWQgaW4gWUFORyBpbiBjb25zdHJhaW5lZCBkZXZp Y2VzCiAgIGFuZCBjb25zdHJhaW5lZCBuZXR3b3JrcywgYSBtb3JlIGNvbXBhY3QgbWV0aG9kIHRv IGlkZW50aWZ5IFlBTkcKICAgaXRlbXMgaXMgcmVxdWlyZWQuICBUaGlzIGNvbXBhY3QgaWRlbnRp ZmllciwgY2FsbGVkIFNJRCwgaXMgZW5jb2RlZAoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAg RXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5l dC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1 YXJ5IDIwMjAKCgogICB1c2luZyBhIDYzLWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgVGhlIGxpbWl0 YXRpb24gdG8gNjMtYml0IHVuc2lnbmVkCiAgIGludGVnZXJzIGFsbG93cyBTSURzIHRvIGJlIG1h bmlwdWxhdGVkIG1vcmUgZWFzaWx5IG9uIHBsYXRmb3JtcyB0aGF0CiAgIG1pZ2h0IG90aGVyd2lz ZSBsYWNrIG5hdGl2ZSA2NC1iaXQgdW5zaWduZWQgYXJpdGhtZXRpYy4gIFRoZSBsb3NzIG9mCiAg IGEgc2luZ2xlIGJpdCBvZiByYW5nZSBpcyBub3Qgc2lnbmlmaWNhbnQgZ2l2ZW4gdGhlIHNpemUg b2YgdGhlCiAgIHJlbWFpbmluZyBzcGFjZS4KCiAgIFRoZSBmb2xsb3dpbmcgaXRlbXMgYXJlIGlk ZW50aWZpZWQgdXNpbmcgU0lEczoKCiAgIG8gIGlkZW50aXRpZXMKCiAgIG8gIGRhdGEgbm9kZXMg KE5vdGU6IGluY2x1ZGluZyB0aG9zZSBwYXJ0cyBvZiBhIFlBTkcgdGVtcGxhdGUgYXMKICAgICAg ZGVmaW5lZCBieSB0aGUgJ3lhbmctZGF0YScgZXh0ZW5zaW9uLikKCiAgIG8gIFJQQ3MgYW5kIGFz c29jaWF0ZWQgaW5wdXQocykgYW5kIG91dHB1dChzKQoKICAgbyAgYWN0aW9ucyBhbmQgYXNzb2Np YXRlZCBpbnB1dChzKSBhbmQgb3V0cHV0KHMpCgogICBvICBub3RpZmljYXRpb25zIGFuZCBhc3Nv Y2lhdGVkIGluZm9ybWF0aW9uCgogICBvICBZQU5HIG1vZHVsZXMsIHN1Ym1vZHVsZXMgYW5kIGZl YXR1cmVzCgogICBTSURzIGFyZSBnbG9iYWxseSB1bmlxdWUgaW50ZWdlcnMsIGEgcmVnaXN0cmF0 aW9uIHN5c3RlbSBpcyB1c2VkIGluCiAgIG9yZGVyIHRvIGd1YXJhbnRlZSB0aGVpciB1bmlxdWVu ZXNzLiAgU0lEcyBhcmUgcmVnaXN0ZXJlZCBpbiBibG9ja3MKICAgY2FsbGVkICJTSUQgcmFuZ2Vz Ii4KCiAgIEFzc2lnbm1lbnQgb2YgU0lEcyB0byBZQU5HIGl0ZW1zIGNhbiBiZSBhdXRvbWF0ZWQu ICBGb3IgbW9yZSBkZXRhaWxzCiAgIGhvdyB0aGlzIGNvdWxkIGJlIGFjaGlldmVkLCBwbGVhc2Ug Y29uc3VsdCBBcHBlbmRpeCBCLgoKICAgU0lEcyBhcmUgYXNzaWduZWQgcGVybWFuZW50bHksIGl0 ZW1zIGludHJvZHVjZWQgYnkgYSBuZXcgcmV2aXNpb24gb2YKICAgYSBZQU5HIG1vZHVsZSBhcmUg YWRkZWQgdG8gdGhlIGxpc3Qgb2YgU0lEcyBhbHJlYWR5IGFzc2lnbmVkLgoKICAgU2VjdGlvbiAz IHByb3ZpZGVzIG1vcmUgZGV0YWlscyBhYm91dCB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb2YK ICAgWUFORyBtb2R1bGVzIGFuZCBhc3NvY2lhdGVkIFNJRHMuICBUbyBlbmFibGUgdGhlIGltcGxl bWVudGF0aW9uIG9mCiAgIHRoaXMgcmVnaXN0cnksIFNlY3Rpb24gNCBkZWZpbmVzIGEgc3RhbmRh cmQgZmlsZSBmb3JtYXQgdXNlZCB0byBzdG9yZQogICBhbmQgcHVibGlzaCBTSURzLgoKMi4gIFRl cm1pbm9sb2d5IGFuZCBOb3RhdGlvbgoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VM RCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZAogICAi T1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2Ny aWJlZCBpbiBCQ1AKICAgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBhbmQgb25seSB3aGVu LCB0aGV5IGFwcGVhciBpbiBhbGwKICAgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuCgogICBUaGUg Zm9sbG93aW5nIHRlcm1zIGFyZSBkZWZpbmVkIGluIFtSRkM3OTUwXToKCiAgIG8gIGFjdGlvbgoK CgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAg ICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVt IGlEZW50aWZpZXIgKFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoKICAgbyAgZmVhdHVyZQoKICAg byAgbW9kdWxlCgogICBvICBub3RpZmljYXRpb24KCiAgIG8gIFJQQwoKICAgbyAgc2NoZW1hIG5v ZGUKCiAgIG8gIHNjaGVtYSB0cmVlCgogICBvICBzdWJtb2R1bGUKCiAgIFRoZSBmb2xsb3dpbmcg dGVybSBpcyBkZWZpbmVkIGluIFtSRkM4MDQwXToKCiAgIG8gIHlhbmctZGF0YSBleHRlbnNpb24K CiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBhbHNvIG1ha2VzIHVzZSBvZiB0aGUgZm9sbG93aW5nIHRl cm1pbm9sb2d5OgoKICAgbyAgaXRlbTogQSBzY2hlbWEgbm9kZSwgYW4gaWRlbnRpdHksIGEgbW9k dWxlLCBhIHN1Ym1vZHVsZSBvciBhCiAgICAgIGZlYXR1cmUgZGVmaW5lZCB1c2luZyB0aGUgWUFO RyBtb2RlbGluZyBsYW5ndWFnZS4KCiAgIG8gIHBhdGg6IEEgcGF0aCBpcyBhIHN0cmluZyB0aGF0 IGlkZW50aWZpZXMgYSBzY2hlbWEgbm9kZSB3aXRoaW4gdGhlCiAgICAgIHNjaGVtYSB0cmVlLiAg QSBwYXRoIGNvbnNpc3RzIG9mIHRoZSBsaXN0IG9mIHNjaGVtYSBub2RlCiAgICAgIGlkZW50aWZp ZXIocykgc2VwYXJhdGVkIGJ5IHNsYXNoZXMgKCIvIikuICBTY2hlbWEgbm9kZQogICAgICBpZGVu dGlmaWVyKHMpIGFyZSBhbHdheXMgbGlzdGVkIGZyb20gdGhlIHRvcC1sZXZlbCBzY2hlbWEgbm9k ZSB1cAogICAgICB0byB0aGUgdGFyZ2V0ZWQgc2NoZW1hIG5vZGUuIChlLmcuICIvaWV0Zi1zeXN0 ZW06c3lzdGVtLQogICAgICBzdGF0ZS9jbG9jay9jdXJyZW50LWRhdGV0aW1lIikKCiAgIG8gIFlB TkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKTogVW5zaWduZWQgaW50ZWdlciB1c2VkIHRv CiAgICAgIGlkZW50aWZ5IGRpZmZlcmVudCBZQU5HIGl0ZW1zLgoKMy4gICIuc2lkIiBmaWxlIGxp ZmVjeWNsZQoKICAgWUFORyBpcyBhIGxhbmd1YWdlIGRlc2lnbmVkIHRvIG1vZGVsIGRhdGEgYWNj ZXNzZWQgdXNpbmcgb25lIG9mIHRoZQogICBjb21wYXRpYmxlIHByb3RvY29scyAoZS5nLiAgTkVU Q09ORiBbUkZDNjI0MV0sIFJFU0NPTkYgW1JGQzgwNDBdIGFuZAogICBDb1JFQ09ORiBbSS1ELmll dGYtY29yZS1jb21pXSkuICBBIFlBTkcgbW9kdWxlIGRlZmluZXMgaGllcmFyY2hpZXMgb2YKICAg ZGF0YSwgaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24sIHN0YXRlIGRhdGEsIFJQQ3MsIGFjdGlvbnMg YW5kCiAgIG5vdGlmaWNhdGlvbnMuCgogICBNYW55IFlBTkcgbW9kdWxlcyBhcmUgbm90IGNyZWF0 ZWQgaW4gdGhlIGNvbnRleHQgb2YgY29uc3RyYWluZWQKICAgYXBwbGljYXRpb25zLiAgWUFORyBt b2R1bGVzIGNhbiBiZSBpbXBsZW1lbnRlZCB1c2luZyBORVRDT05GCiAgIFtSRkM2MjQxXSBvciBS RVNUQ09ORiBbUkZDODA0MF0gd2l0aG91dCB0aGUgbmVlZCB0byBhc3NpZ24gU0lEcy4KCiAgIEFz IG5lZWRlZCwgYXV0aG9ycyBvZiBZQU5HIG1vZHVsZXMgY2FuIGFzc2lnbiBTSURzIHRvIHRoZWly IFlBTkcKICAgbW9kdWxlcy4gIEluIG9yZGVyIHRvIGRvIHRoYXQsIHRoZXkgc2hvdWxkIGZpcnN0 IG9idGFpbiBhIFNJRCByYW5nZQogICBmcm9tIGEgcmVnaXN0cnkgYW5kIHVzZSB0aGF0IHJhbmdl IHRvIGFzc2lnbiBvciBnZW5lcmF0ZSBTSURzIHRvCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAg ICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVy bmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVi cnVhcnkgMjAyMAoKCiAgIGl0ZW1zIG9mIHRoZWlyIFlBTkcgbW9kdWxlLiAgVGhlIGFzc2lnbm1l bnRzIGNhbiB0aGVuIGJlIHN0b3JlZCBpbiBhCiAgICIuc2lkIiBmaWxlLiAgRm9yIGV4YW1wbGUg aG93IHRoaXMgY291bGQgYmUgYWNoaWV2ZWQsIHBsZWFzZSByZWZlciB0bwogICBBcHBlbmRpeCBD LgoKICAgUmVnaXN0cmF0aW9uIG9mIHRoZSAiLnNpZCIgZmlsZSBhc3NvY2lhdGVkIHRvIGEgWUFO RyBtb2R1bGUgaXMKICAgb3B0aW9uYWwgYnV0IHJlY29tbWVuZGVkIHRvIHByb21vdGUgaW50ZXJv cGVyYWJpbGl0eSBiZXR3ZWVuIGRldmljZXMKICAgYW5kIHRvIGF2b2lkIGR1cGxpY2F0ZSBhbGxv Y2F0aW9uIG9mIFNJRHMgdG8gYSBzaW5nbGUgWUFORyBtb2R1bGUuCiAgIERpZmZlcmVudCByZWdp c3RyaWVzIG1pZ2h0IGhhdmUgZGlmZmVyZW50IHJlcXVpcmVtZW50cyBmb3IgdGhlCiAgIHJlZ2lz dHJhdGlvbiBhbmQgcHVibGljYXRpb24gb2YgdGhlICIuc2lkIiBmaWxlcy4gIEZvciBkaWFncmFt IG9mIG9uZQogICBvZiB0aGUgcG9zc2liaWxpdGllcywgcGxlYXNlIHJlZmVyIHRvIHRoZSBhY3Rp dml0eSBkaWFncmFtIG9uCiAgIEZpZ3VyZSAxIGluIEFwcGVuZGl4IEMuCgogICBFYWNoIHRpbWUg YSBZQU5HIG1vZHVsZSBvciBvbmUgb2YgaXRzIGltcG9ydGVkIG1vZHVsZShzKSBvciBpbmNsdWRl ZAogICBzdWItbW9kdWxlKHMpIGlzIHVwZGF0ZWQsIGEgbmV3ICIuc2lkIiBmaWxlIE1BWSBuZWVk IHRvIGJlIGNyZWF0ZWQuCiAgIEFsbCB0aGUgU0lEcyBwcmVzZW50IGluIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIG9mIHRoZSAiLnNpZCIgZmlsZSBNVVNUCiAgIGJlIHByZXNlbnQgaW4gdGhlIG5ldyB2 ZXJzaW9uIGFzIHdlbGwuICBUaGUgY3JlYXRpb24gb2YgdGhpcyBuZXcKICAgdmVyc2lvbiBvZiB0 aGUgIi5zaWQiIGZpbGUgU0hPVUxEIGJlIHBlcmZvcm1lZCB1c2luZyBhbiBhdXRvbWF0ZWQKICAg dG9vbC4KCiAgIElmIGEgbmV3IHJldmlzaW9uIHJlcXVpcmVzIG1vcmUgU0lEcyB0aGFuIGluaXRp YWxseSBhbGxvY2F0ZWQsIGEgbmV3CiAgIFNJRCByYW5nZSBNVVNUIGJlIGFkZGVkIHRvIHRoZSAn YXNzaWdubWVudC1yYW5nZXMnIGFzIGRlZmluZWQgaW4KICAgU2VjdGlvbiA0LiAgVGhlc2UgZXh0 cmEgU0lEcyBhcmUgdXNlZCBmb3Igc3Vic2VxdWVudCBhc3NpZ25tZW50cy4KCiAgIEZvciBhbiBl eGFtcGxlIG9mIHRoaXMgdXBkYXRlIHByb2Nlc3MsIHNlZSBhY3Rpdml0eSBkaWFncmFtIEZpZ3Vy ZSAyCiAgIGluIEFwcGVuZGl4IEMuCgo0LiAgIi5zaWQiIGZpbGUgZm9ybWF0CgogICAiLnNpZCIg ZmlsZXMgYXJlIHVzZWQgdG8gcGVyc2lzdCBhbmQgcHVibGlzaCBTSURzIGFzc2lnbmVkIHRvIHRo ZQogICBkaWZmZXJlbnQgWUFORyBpdGVtcyBvZiBhIHNwZWNpZmljIFlBTkcgbW9kdWxlLiAgVGhl IGZvbGxvd2luZyBZQU5HCiAgIG1vZHVsZSBkZWZpbmVkIHRoZSBzdHJ1Y3R1cmUgb2YgdGhpcyBm aWxlLCBlbmNvZGluZyBpcyBwZXJmb3JtZWQKICAgdXNpbmcgdGhlIHJ1bGVzIGRlZmluZWQgaW4g W1JGQzc5NTFdLgoKPENPREUgQkVHSU5TPiBmaWxlICJpZXRmLXNpZC1maWxlQDIwMjAtMDItMDUu eWFuZyIKbW9kdWxlIGlldGYtc2lkLWZpbGUgewogIG5hbWVzcGFjZSAidXJuOmlldGY6cGFyYW1z OnhtbDpuczp5YW5nOmlldGYtc2lkLWZpbGUiOwogIHByZWZpeCBzaWQ7CgogIGltcG9ydCBpZXRm LXlhbmctdHlwZXMgewogICAgcHJlZml4IHlhbmc7CiAgfQoKICBvcmdhbml6YXRpb24KICAgICJJ RVRGIENvcmUgV29ya2luZyBHcm91cCI7CgogIGNvbnRhY3QKICAgICJNaWNoZWwgVmVpbGxldHRl CiAgICAgPG1haWx0bzptaWNoZWwudmVpbGxldHRlQHRyaWxsaWFudC5jb20+CgoKClZlaWxsZXR0 ZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgICBb UGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVy IChTSUQpICAgICAgRmVicnVhcnkgMjAyMAoKCiAgICAgQW5keSBCaWVybWFuCiAgICAgPG1haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb20+CgogICAgIEFsZXhhbmRlciBQZWxvdgogICAgIDxtYWlsdG86 YUBhY2tsLmlvPiI7CgogIGRlc2NyaXB0aW9uCiAgICAiQ29weXJpZ2h0IChjKSAyMDE2IElFVEYg VHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMKICAgICBhdXRob3JzIG9mIHRoZSBj b2RlLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgICAgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBp biBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvcgogICAgIHdpdGhvdXQgbW9kaWZpY2F0 aW9uLCBpcyBwZXJtaXR0ZWQgcHVyc3VhbnQgdG8sIGFuZCBzdWJqZWN0IHRvCiAgICAgdGhlIGxp Y2Vuc2UgdGVybXMgY29udGFpbmVkIGluLCB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSBzZXQK ICAgICBmb3J0aCBpbiBTZWN0aW9uIDQuYyBvZiB0aGUgSUVURiBUcnVzdCdzIExlZ2FsIFByb3Zp c2lvbnMKICAgICBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAgIChodHRwczovL3RydXN0 ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKS4KCiAgICAgVGhpcyB2ZXJzaW9uIG9mIHRoaXMgWUFO RyBtb2R1bGUgaXMgcGFydCBvZiBSRkMgWFhYWAogICAgIChodHRwczovL3d3dy5yZmMtZWRpdG9y Lm9yZy9pbmZvL3JmY1hYWFgpOyBzZWUgdGhlIFJGQyBpdHNlbGYKICAgICBmb3IgZnVsbCBsZWdh bCBub3RpY2VzLgoKICAgICBUaGUga2V5IHdvcmRzICdNVVNUJywgJ01VU1QgTk9UJywgJ1JFUVVJ UkVEJywgJ1NIQUxMJywgJ1NIQUxMCiAgICAgTk9UJywgJ1NIT1VMRCcsICdTSE9VTEQgTk9UJywg J1JFQ09NTUVOREVEJywgJ05PVCBSRUNPTU1FTkRFRCcsCiAgICAgJ01BWScsIGFuZCAnT1BUSU9O QUwnIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzCiAgICAgZGVzY3Jp YmVkIGluIEJDUCAxNCAoUkZDIDIxMTkpIChSRkMgODE3NCkgd2hlbiwgYW5kIG9ubHkgd2hlbiwK ICAgICB0aGV5IGFwcGVhciBpbiBhbGwgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuCgoKICAgICBU aGlzIG1vZHVsZSBkZWZpbmVzIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIFwiLnNpZFwiIGZpbGVzLgoK ICAgICBFYWNoIFwiLnNpZFwiIGZpbGUgY29udGFpbnMgdGhlIG1hcHBpbmcgYmV0d2VlbiB0aGUg ZGlmZmVyZW50CiAgICAgc3RyaW5nIGlkZW50aWZpZXJzIGRlZmluZWQgYnkgYSBZQU5HIG1vZHVs ZSBhbmQgYQogICAgIGNvcnJlc3BvbmRpbmcgbnVtZXJpYyB2YWx1ZSBjYWxsZWQgU0lELiI7Cgog IHJldmlzaW9uIDIwMjAtMDItMDUgewogICAgZGVzY3JpcHRpb24KICAgICAgIkluaXRpYWwgcmV2 aXNpb24uIjsKICAgIHJlZmVyZW5jZQogICAgICAiW0ktRC5pZXRmLWNvcmUtc2lkXSBZQU5HIFNj aGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkiOwogIH0KCiAgdHlwZWRlZiByZXZpc2lvbi1pZGVu dGlmaWVyIHsKICAgIHR5cGUgc3RyaW5nIHsKICAgICAgcGF0dGVybiAnXGR7NH0tXGR7Mn0tXGR7 Mn0nOwogICAgfQogICAgZGVzY3JpcHRpb24KICAgICAgIlJlcHJlc2VudHMgYSBkYXRlIGluIFlZ WVktTU0tREQgZm9ybWF0LiI7CiAgfQoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJl cyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFm dCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIw MjAKCgogIHR5cGVkZWYgc2lkLWZpbGUtdmVyc2lvbi1pZGVudGlmaWVyIHsKICAgIHR5cGUgdWlu dDY0OwogICAgZGVzY3JpcHRpb24KICAgICAgIk9wdGlvbmFsIGF0dHJpYnV0ZSB0aGF0IGdpdmVz IGluZm9ybWF0aW9uIGFib3V0IHRoZSBcIi5zaWRcIiBmaWxlCiAgICAgICB2ZXJzaW9uLiI7CiAg fQoKICB0eXBlZGVmIHNpZCB7CiAgICB0eXBlIHVpbnQ2NDsKICAgIGRlc2NyaXB0aW9uCiAgICAg ICJZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIiOwogICAgcmVmZXJlbmNlCiAgICAgICJbSS1E LmlldGYtY29yZS1zaWRdIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSI7CiAgfQoK ICB0eXBlZGVmIHNjaGVtYS1ub2RlLXBhdGggewogICAgdHlwZSBzdHJpbmcgewogICAgICBwYXR0 ZXJuCiAgICAgICAgJy9bYS16QS1aX11bYS16QS1aMC05XC1fLl0qOlthLXpBLVpfXVthLXpBLVow LTlcLV8uXSonICsKICAgICAgICAnKC9bYS16QS1aX11bYS16QS1aMC05XC1fLl0qKDpbYS16QS1a X11bYS16QS1aMC05XC1fLl0qKT8pKic7CiAgICB9CiAgICBkZXNjcmlwdGlvbgogICAgICAiSWRl bnRpZmllcyBhIHNjaGVtYS1ub2RlIHBhdGggc3RyaW5nIGZvciB1c2UgaW4gdGhlCiAgICAgICBT SUQgcmVnaXN0cnkuIFRoaXMgc3RyaW5nIGZvcm1hdCBmb2xsb3dzIHRoZSBydWxlcwogICAgICAg Zm9yIGFuIGluc3RhbmNlLWlkZW50aWZpZXIsIGFzIGRlZmluZWQgaW4gUkZDIDc5NTksCiAgICAg ICBleGNlcHQgdGhhdCBubyBwcmVkaWNhdGVzIGFyZSBhbGxvd2VkLgoKICAgICAgIFRoaXMgZm9y bWF0IGlzIGludGVuZGVkIHRvIHN1cHBvcnQgdGhlIFlBTkcgMS4xIEFCTkYKICAgICAgIGZvciBh IHNjaGVtYSBub2RlIGlkZW50aWZpZXIsIGV4Y2VwdCBtb2R1bGUgbmFtZXMKICAgICAgIGFyZSB1 c2VkIGluc3RlYWQgb2YgcHJlZml4ZXMsIGFzIHNwZWNpZmllZCBpbiBSRkMgNzk1MS4iOwogICAg cmVmZXJlbmNlCiAgICAgICJSRkMgNzk1MCwgVGhlIFlBTkcgMS4xIERhdGEgTW9kZWxpbmcgTGFu Z3VhZ2U7CiAgICAgICBTZWN0aW9uIDYuNTogU2NoZW1hIE5vZGUgSWRlbnRpZmllcjsKICAgICAg IFJGQyA3OTUxLCBKU09OIEVuY29kaW5nIG9mIFlBTkcgRGF0YTsKICAgICAgIFNlY3Rpb24gNi4x MTogVGhlIGluc3RhbmNlLWlkZW50aWZpZXIgdHlwZSI7CiAgfQoKICBsZWFmIG1vZHVsZS1uYW1l IHsKICAgIHR5cGUgeWFuZzp5YW5nLWlkZW50aWZpZXI7CiAgICBkZXNjcmlwdGlvbgogICAgICAi TmFtZSBvZiB0aGUgWUFORyBtb2R1bGUgYXNzb2NpYXRlZCB3aXRoIHRoaXMgXCIuc2lkXCIgZmls ZS4iOwogIH0KCiAgbGVhZiBtb2R1bGUtcmV2aXNpb24gewogICAgdHlwZSByZXZpc2lvbi1pZGVu dGlmaWVyOwogICAgZGVzY3JpcHRpb24KICAgICAgIlJldmlzaW9uIG9mIHRoZSBZQU5HIG1vZHVs ZSBhc3NvY2lhdGVkIHdpdGggdGhpcyBcIi5zaWRcIiBmaWxlLgogICAgICAgVGhpcyBsZWFmIGlz IG5vdCBwcmVzZW50IGlmIG5vIHJldmlzaW9uIHN0YXRlbWVudCBpcwoKCgpWZWlsbGV0dGUsIGV0 IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICAgW1BhZ2Ug N10KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lE KSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICAgICAgZGVmaW5lZCBpbiB0aGUgWUFORyBtb2R1bGUu IjsKICB9CgogIGxlYWYgc2lkLWZpbGUtdmVyc2lvbiB7CiAgICB0eXBlIHNpZC1maWxlLXZlcnNp b24taWRlbnRpZmllcjsKICAgIGRlc2NyaXB0aW9uCiAgICAgICJWZXJzaW9uIG51bWJlciBvZiB0 aGUgXCIuc2lkXCIgZmlsZS4gVXNlZnVsIHRvIGRpc3Rpbmd1aXNoIFwiLnNpZFwiCiAgICAgICBm aWxlcyBnZW5lcmF0ZWQgdXNpbmcgZGlmZmVyZW50IFlBTkcgbW9kdWxlIGRlcGVuZGVuY2llcyB0 aGF0IG1pZ2h0IG5vdAogICAgICAgYmUgcmVmbGVjdGVkIGluIHRoZSBZQU5HIG1vZHVsZSByZXZp c2lvbi4iOwogIH0KCiAgbGlzdCBkZXBlbmRlbmNpZXMtcmV2aXNpb25zIHsKICAgIGtleSAibW9k dWxlLW5hbWUiOwoKICAgIGRlc2NyaXB0aW9uCiAgICAgICJJbmZvcm1hdGlvbiBhYm91dCB0aGUg cmV2aXNpb24gb2YgZWFjaCBZQU5HIG1vZHVsZSB0aGF0IHRoZSBtb2R1bGUgaW4KICAgICAgICdt b2R1bGUtbmFtZScgaW5jbHVkZXMgdXNlZCBkdXJpbmcgdGhlIFwiLnNpZFwiIGZpbGUgZ2VuZXJh dGlvbi4iOwoKICAgIGxlYWYgbW9kdWxlLW5hbWUgewogICAgICB0eXBlIHlhbmc6eWFuZy1pZGVu dGlmaWVyOwogICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAgICAgZGVzY3JpcHRpb24KICAgICAgICAi TmFtZSBvZiB0aGUgWUFORyBtb2R1bGUsIGRlcGVuZGVuY3kgb2YgJ21vZHVsZS1uYW1lJywgZm9y IHdoaWNoCiAgICAgICAgIHJldmlzaW9uIGluZm9ybWF0aW9uIGlzIHByb3ZpZGVkLiI7CiAgICB9 CiAgICBsZWFmIG1vZHVsZS1yZXZpc2lvbiB7CiAgICAgIHR5cGUgcmV2aXNpb24taWRlbnRpZmll cjsKICAgICAgbWFuZGF0b3J5IHRydWU7CiAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgIlJldmlz aW9uIG9mIHRoZSBZQU5HIG1vZHVsZSwgZGVwZW5kZW5jeSBvZiAnbW9kdWxlLW5hbWUnLCBmb3Ig d2hpY2gKICAgICAgICAgcmV2aXNpb24gaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQuIjsKICAgIH0K ICB9CgogIGxpc3QgYXNzaWdtZW50LXJhbmdlcyB7CiAgICBrZXkgImVudHJ5LXBvaW50IjsKICAg IGRlc2NyaXB0aW9uCiAgICAgICJTSUQgcmFuZ2UocykgYWxsb2NhdGVkIHRvIHRoZSBZQU5HIG1v ZHVsZSBpZGVudGlmaWVkIGJ5CiAgICAgICAnbW9kdWxlLW5hbWUnIGFuZCAnbW9kdWxlLXJldmlz aW9uJy4iOwoKICAgIGxlYWYgZW50cnktcG9pbnQgewogICAgICB0eXBlIHNpZDsKICAgICAgbWFu ZGF0b3J5IHRydWU7CiAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgIkxvd2VzdCBTSUQgYXZhaWxh YmxlIGZvciBhc3NpZ25tZW50LiI7CiAgICB9CgogICAgbGVhZiBzaXplIHsKCgoKVmVpbGxldHRl LCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgIFtQ YWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIg KFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoKICAgICAgdHlwZSB1aW50NjQ7CiAgICAgIG1hbmRh dG9yeSB0cnVlOwogICAgICBkZXNjcmlwdGlvbgogICAgICAgICJOdW1iZXIgb2YgU0lEcyBhdmFp bGFibGUgZm9yIGFzc2lnbm1lbnQuIjsKICAgIH0KICB9CgogIGxpc3QgaXRlbXMgewogICAga2V5 ICJuYW1lc3BhY2UgaWRlbnRpZmllciI7CiAgICBkZXNjcmlwdGlvbgogICAgICAiRWFjaCBlbnRy eSB3aXRoaW4gdGhpcyBsaXN0IGRlZmluZWQgdGhlIG1hcHBpbmcgYmV0d2VlbgogICAgICAgYSBZ QU5HIGl0ZW0gc3RyaW5nIGlkZW50aWZpZXIgYW5kIGEgU0lELiBUaGlzIGxpc3QgTVVTVAogICAg ICAgaW5jbHVkZSBhIG1hcHBpbmcgZW50cnkgZm9yIGVhY2ggWUFORyBpdGVtIGRlZmluZWQgYnkK ICAgICAgIHRoZSBZQU5HIG1vZHVsZSBpZGVudGlmaWVkIGJ5ICdtb2R1bGUtbmFtZScgYW5kCiAg ICAgICAnbW9kdWxlLXJldmlzaW9uJy4iOwoKICAgIGxlYWYgbmFtZXNwYWNlIHsKICAgICAgdHlw ZSBlbnVtZXJhdGlvbiB7CiAgICAgICAgZW51bSBtb2R1bGUgewogICAgICAgICAgdmFsdWUgMDsK ICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICJBbGwgbW9kdWxlIGFuZCBzdWJtb2R1 bGUgbmFtZXMgc2hhcmUgdGhlIHNhbWUKICAgICAgICAgICAgIGdsb2JhbCBtb2R1bGUgaWRlbnRp ZmllciBuYW1lc3BhY2UuIjsKICAgICAgICB9CiAgICAgICAgZW51bSBpZGVudGl0eSB7CiAgICAg ICAgICB2YWx1ZSAxOwogICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgIkFsbCBpZGVu dGl0eSBuYW1lcyBkZWZpbmVkIGluIGEgbW9kdWxlIGFuZCBpdHMKICAgICAgICAgICAgIHN1Ym1v ZHVsZXMgc2hhcmUgdGhlIHNhbWUgaWRlbnRpdHkgaWRlbnRpZmllcgogICAgICAgICAgICAgbmFt ZXNwYWNlLiI7CiAgICAgICAgfQogICAgICAgIGVudW0gZmVhdHVyZSB7CiAgICAgICAgICB2YWx1 ZSAyOwogICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgIkFsbCBmZWF0dXJlIG5hbWVz IGRlZmluZWQgaW4gYSBtb2R1bGUgYW5kIGl0cwogICAgICAgICAgICAgc3VibW9kdWxlcyBzaGFy ZSB0aGUgc2FtZSBmZWF0dXJlIGlkZW50aWZpZXIKICAgICAgICAgICAgIG5hbWVzcGFjZS4iOwog ICAgICAgIH0KICAgICAgICBlbnVtIGRhdGEgewogICAgICAgICAgdmFsdWUgMzsKICAgICAgICAg IGRlc2NyaXB0aW9uCiAgICAgICAgICAgICJUaGUgbmFtZXNwYWNlIGZvciBhbGwgZGF0YSBub2Rl cywgYXMgZGVmaW5lZCBpbiBZQU5HLiI7CiAgICAgICAgfQogICAgICB9CiAgICAgIGRlc2NyaXB0 aW9uCiAgICAgICAgIk5hbWVzcGFjZSBvZiB0aGUgWUFORyBpdGVtIGZvciB0aGlzIG1hcHBpbmcg ZW50cnkuIjsKICAgIH0KCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3Vz dCA4LCAyMDIwICAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAg WUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVicnVhcnkgMjAyMAoKCiAg ICBsZWFmIGlkZW50aWZpZXIgewogICAgICB0eXBlIHVuaW9uIHsKICAgICAgICB0eXBlIHlhbmc6 eWFuZy1pZGVudGlmaWVyOwogICAgICAgIHR5cGUgc2NoZW1hLW5vZGUtcGF0aDsKICAgICAgfQog ICAgICBkZXNjcmlwdGlvbgogICAgICAgICJTdHJpbmcgaWRlbnRpZmllciBvZiB0aGUgWUFORyBp dGVtIGZvciB0aGlzIG1hcHBpbmcgZW50cnkuCgogICAgICAgICBJZiB0aGUgY29ycmVzcG9uZGlu ZyAnbmFtZXNwYWNlJyBmaWVsZCBpcyAnbW9kdWxlJywKICAgICAgICAgJ2ZlYXR1cmUnLCBvciAn aWRlbnRpdHknLCB0aGVuIHRoaXMgZmllbGQgTVVTVAogICAgICAgICBjb250YWluIGEgdmFsaWQg WUFORyBpZGVudGlmaWVyIHN0cmluZy4KCiAgICAgICAgIElmIHRoZSBjb3JyZXNwb25kaW5nICdu YW1lc3BhY2UnIGZpZWxkIGlzICdkYXRhJywKICAgICAgICAgdGhlbiB0aGlzIGZpZWxkIE1VU1Qg Y29udGFpbiBhIHZhbGlkIHNjaGVtYSBub2RlCiAgICAgICAgIHBhdGguIjsKICAgICB9CgogICAg bGVhZiBzaWQgewogICAgICB0eXBlIHNpZDsKICAgICAgbWFuZGF0b3J5IHRydWU7CiAgICAgIGRl c2NyaXB0aW9uCiAgICAgICAgIlNJRCBhc3NpZ25lZCB0byB0aGUgWUFORyBpdGVtIGZvciB0aGlz IG1hcHBpbmcgZW50cnkuIjsKICAgIH0KICB9Cn0KPENPREUgRU5EUz4KCjUuICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IHR5cGUgb2YgaWRl bnRpZmllciB1c2VkIHRvIGVuY29kZSBkYXRhCiAgIG1vZGVscyBkZWZpbmVkIGluIFlBTkcgW1JG Qzc5NTBdLiAgQXMgc3VjaCwgdGhpcyBpZGVudGlmaWVyIGRvZXMgbm90CiAgIGNvbnRyaWJ1dGUg dG8gYW55IG5ldyBzZWN1cml0eSBpc3N1ZXMgaW4gYWRkaXRpb24gb2YgdGhvc2UgaWRlbnRpZmll ZAogICBmb3IgdGhlIHNwZWNpZmljIHByb3RvY29scyBvciBjb250ZXh0cyBmb3Igd2hpY2ggaXQg aXMgdXNlZC4KCjYuICBJQU5BIENvbnNpZGVyYXRpb25zCgo2LjEuICBSZWdpc3RlciBTSUQgRmls ZSBGb3JtYXQgTW9kdWxlCgogICBUaGlzIGRvY3VtZW50IHJlZ2lzdGVycyBvbmUgWUFORyBtb2R1 bGUgaW4gdGhlICJZQU5HIE1vZHVsZSBOYW1lcyIKICAgcmVnaXN0cnkgW1JGQzYwMjBdOgoKICAg byAgbmFtZTogaWV0Zi1zaWQtZmlsZQoKICAgbyAgbmFtZXNwYWNlOiB1cm46aWV0ZjpwYXJhbXM6 eG1sOm5zOnlhbmc6aWV0Zi1zaWQtZmlsZQoKICAgbyAgcHJlZml4OiBzaWQKCiAgIG8gIHJlZmVy ZW5jZTogW1tUSElTUkZDXV0KCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVn dXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoK Ni4yLiAgQ3JlYXRlIG5ldyBJQU5BIFJlZ2lzdHJ5OiAiU0lEIE1lZ2EtUmFuZ2UiIHJlZ2lzdHJ5 CgogICBUaGUgbmFtZSBvZiB0aGlzIHJlZ2lzdHJ5IGlzICJTSUQgTWVnYS1SYW5nZSIuICBUaGlz IHJlZ2lzdHJ5IGlzIHVzZWQKICAgdG8gcmVjb3JkIHRoZSBkZWxlZ2F0aW9uIG9mIHRoZSBtYW5h Z2VtZW50IG9mIGEgYmxvY2sgb2YgU0lEcyB0bwogICB0aGlyZCBwYXJ0aWVzIChzdWNoIGFzIFNE T3Mgb3IgcmVnaXN0cmFycykuCgo2LjIuMS4gIFN0cnVjdHVyZQoKICAgRWFjaCBlbnRyeSBpbiB0 aGlzIHJlZ2lzdHJ5IG11c3QgaW5jbHVkZToKCiAgIG8gIFRoZSBlbnRyeSBwb2ludCAoZmlyc3Qg U0lEKSBvZiB0aGUgcmVnaXN0ZXJlZCBTSUQgYmxvY2suCgogICBvICBUaGUgc2l6ZSBvZiB0aGUg cmVnaXN0ZXJlZCBTSUQgYmxvY2suICBUaGUgc2l6ZSBNVVNUIGJlIG9uZQogICAgICBtaWxsaW9u ICgxIDAwMCAwMDApIFNJRHMuCgogICBvICBUaGUgY29udGFjdCBpbmZvcm1hdGlvbiBvZiB0aGUg cmVxdWVzdGluZyBvcmdhbml6YXRpb24gaW5jbHVkaW5nOgoKICAgICAgKiAgVGhlIHBvbGljeSBv ZiBTSUQgcmFuZ2UgYWxsb2NhdGlvbnM6IFB1YmxpYywgUHJpdmF0ZSBvciBCb3RoLgoKICAgICAg KiAgT3JnYW5pemF0aW9uIG5hbWUKCiAgICAgICogIFVSTAoKICAgVGhlIGluZm9ybWF0aW9uIGFz c29jaWF0ZWQgdG8gdGhlIE9yZ2FuaXphdGlvbiBuYW1lIHNob3VsZCBub3QgYmUKICAgcHVibGlj bHkgdmlzaWJsZSBpbiB0aGUgcmVnaXN0cnksIGJ1dCBzaG91bGQgYmUgYXZhaWxhYmxlLiAgVGhp cwogICBpbmZvcm1hdGlvbiBpbmNsdWRlcyBjb250YWN0IGVtYWlsIGFuZCBwaG9uZSBudW1iZXIg YW5kIGNoYW5nZQogICBjb250cm9sbGVyIGVtYWlsIGFuZCBwaG9uZSBudW1iZXIuCgo2LjIuMi4g IEFsbG9jYXRpb24gcG9saWN5CgogICBUaGUgSUFOQSBwb2xpY3kgZm9yIGZ1dHVyZSBhZGRpdGlv bnMgdG8gdGhpcyByZWdpc3RyeSBpcyAiRXhwZXJ0CiAgIFJldmlldyIgW1JGQzgxMjZdLgoKICAg QW4gb3JnYW5pemF0aW9uIHJlcXVlc3RpbmcgdG8gbWFuYWdlIGEgU0lEIFJhbmdlIChhbmQgdGh1 cyBoYXZlIGFuCiAgIGVudHJ5IGluIHRoZSBTSUQgTWVnYS1SYW5nZSBSZWdpc3RyeSksIG11c3Qg ZW5zdXJlIHRoZSBmb2xsb3dpbmcKICAgY2FwYWNpdGllczoKCiAgIG8gIFRoZSBjYXBhY2l0eSB0 byBtYW5hZ2UgYW5kIG9wZXJhdGUgYSBTSUQgUmFuZ2UgUmVnaXN0cnkuICBBIFNJRAogICAgICBS YW5nZSBSZWdpc3RyeSBNVVNUIHByb3ZpZGUgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBmb3Ig YWxsIFNJRAogICAgICBSYW5nZXMgYWxsb2NhdGVkIGJ5IHRoZSBSZWdpc3RyeToKCiAgICAgICog IEVudHJ5IFBvaW50IG9mIGFsbG9jYXRlZCBTSUQgUmFuZ2UKCiAgICAgICogIFNpemUgb2YgYWxs b2NhdGVkIFNJRCBSYW5nZQoKICAgICAgKiAgVHlwZTogUHVibGljIG9yIFByaXZhdGUKCgoKCgpW ZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAg ICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURl bnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICAgICAgICArICBQdWJsaWMgUmFu Z2VzIE1VU1QgaW5jbHVkZSBhdCBsZWFzdCBhIHJlZmVyZW5jZSB0byB0aGUgWUFORwogICAgICAg ICAgICBtb2R1bGUgYW5kICIuc2lkIiBmaWxlcyBmb3IgdGhhdCBTSUQgUmFuZ2UuCgogICAgICAg ICArICBQcml2YXRlIFJhbmdlcyBNVVNUIGJlIG1hcmtlZCBhcyAiUHJpdmF0ZSIKCiAgIG8gIEEg UG9saWN5IG9mIGFsbG9jYXRpb24sIHdoaWNoIGNsZWFybHkgaWRlbnRpZmllcyBpZiB0aGUgU0lE IFJhbmdlCiAgICAgIGFsbG9jYXRpb25zIHdvdWxkIGJlIFByaXZhdGUsIFB1YmxpYyBvciBCb3Ro LgoKICAgbyAgVGVjaG5pY2FsIGNhcGFjaXR5IHRvIGVuc3VyZSB0aGUgc3VzdGFpbmVkIG9wZXJh dGlvbiBvZiB0aGUKICAgICAgcmVnaXN0cnkgZm9yIGEgcGVyaW9kIG9mIGF0IGxlYXN0IDUgeWVh cnMuICBJZiBQcml2YXRlCiAgICAgIFJlZ2lzdHJhdGlvbnMgYXJlIGFsbG93ZWQsIHRoZSBwZXJp b2QgbXVzdCBiZSBvZiBhdCBsZWFzdCAxMAogICAgICB5ZWFycy4KCjYuMi4yLjEuICBGaXJzdCBh bGxvY2F0aW9uCgogICBGb3IgYSBmaXJzdCBhbGxvY2F0aW9uIHRvIGJlIHByb3ZpZGVkLCB0aGUg cmVxdWVzdGluZyBvcmdhbml6YXRpb24KICAgbXVzdCBkZW1vbnN0cmF0ZSBhIGZ1bmN0aW9uYWwg cmVnaXN0cnkgaW5mcmFzdHJ1Y3R1cmUuCgo2LjIuMi4yLiAgQ29uc2VjdXRpdmUgYWxsb2NhdGlv bnMKCiAgIE9uIHN1YnNlcXVlbnQgYWxsb2NhdGlvbiByZXF1ZXN0KHMpLCB0aGUgb3JnYW5pemF0 aW9uIG11c3QKICAgZGVtb25zdHJhdGUgdGhlIGV4aGF1c3Rpb24gb2YgdGhlIHByaW9yIHJhbmdl LiAgVGhlc2UgY29uZGl0aW9ucyBuZWVkCiAgIHRvIGJlIGFzc2VydGVkIGJ5IHRoZSBhc3NpZ25l ZCBleHBlcnQocykuCgogICBJZiB0aGF0IGV4dHJhLWFsbG9jYXRpb24gaXMgZG9uZSB3aXRoaW4g MyB5ZWFycyBmcm9tIHRoZSBsYXN0CiAgIGFsbG9jYXRpb24sIHRoZSBleHBlcnRzIG5lZWQgdG8g ZGlzY3VzcyB0aGlzIHJlcXVlc3Qgb24gdGhlIENPUkUKICAgd29ya2luZyBncm91cCBtYWlsaW5n IGxpc3QgYW5kIGNvbnNlbnN1cyBuZWVkcyB0byBiZSBvYnRhaW5lZCBiZWZvcmUKICAgYWxsb2Nh dGluZyBhIG5ldyBNZWdhLVJhbmdlLgoKNi4yLjMuICBJbml0aWFsIGNvbnRlbnRzIG9mIHRoZSBS ZWdpc3RyeQoKICAgVGhlIGluaXRpYWwgZW50cnkgaW4gdGhpcyByZWdpc3RyeSBpcyBhbGxvY2F0 ZWQgdG8gSUFOQToKCiAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKwogICB8IEVudHJ5IFBvaW50IHwgU2l6ZSAgICB8 IEFsbG9jYXRpb24gfCBPcmdhbml6YXRpb24gbmFtZSB8IFVSTCAgICAgIHwKICAgKy0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0rCiAgIHwgMCAgICAgICAgICAgfCAxMDAwMDAwIHwgUHVibGljICAgICB8IElBTkEgICAgICAg ICAgICAgIHwgaWFuYS5vcmcgfAogICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSsKCjYuMy4gIENyZWF0ZSBhIG5ldyBJ QU5BIFJlZ2lzdHJ5OiBJRVRGIFNJRCBSYW5nZSBSZWdpc3RyeSAobWFuYWdlZCBieQogICAgICBJ QU5BKQoKNi4zLjEuICBTdHJ1Y3R1cmUKCiAgIEVhY2ggZW50cnkgaW4gdGhpcyByZWdpc3RyeSBt dXN0IGluY2x1ZGU6CgogICBvICBUaGUgU0lEIHJhbmdlIGVudHJ5IHBvaW50LgoKCgoKVmVpbGxl dHRlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAg W1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZp ZXIgKFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoKICAgbyAgVGhlIFNJRCByYW5nZSBzaXplLgoK ICAgbyAgVGhlIFlBTkcgbW9kdWxlIG5hbWUuCgogICBvICBEb2N1bWVudCByZWZlcmVuY2UuCgo2 LjMuMi4gIEFsbG9jYXRpb24gcG9saWN5CgogICBUaGUgZmlyc3QgbWlsbGlvbiBTSURzIGFzc2ln bmVkIHRvIElBTkEgaXMgc3ViLWRpdmlkZWQgYXMgZm9sbG93czoKCiAgIG8gIFRoZSByYW5nZSBv ZiAwIHRvIDk5OSAoc2l6ZSAxMDAwKSBpcyAiUmVzZXJ2ZWQiIGFzIGRlZmluZWQgaW4KICAgICAg W1JGQzgxMjZdLgoKICAgbyAgVGhlIHJhbmdlIG9mIDEwMDAgdG8gNTksOTk5IChzaXplIDU5LDAw MCkgaXMgcmVzZXJ2ZWQgZm9yIFlBTkcKICAgICAgbW9kdWxlcyBkZWZpbmVkIGluIFJGQ3MuICBU aGUgSUFOQSBwb2xpY3kgZm9yIGFkZGl0aW9ucyB0byB0aGlzCiAgICAgIHJlZ2lzdHJ5IGlzICJF eHBlcnQgUmV2aWV3IiBbUkZDODEyNl0uCgogICAgICAqICBUaGUgRXhwZXJ0IE1VU1QgdmVyaWZ5 IHRoYXQgdGhlIFlBTkcgbW9kdWxlIGZvciB3aGljaCB0aGlzCiAgICAgICAgIGFsbG9jYXRpb24g aXMgbWFkZSBoYXMgYW4gUkZDIChleGlzdGluZyBSRkMpIE9SIGlzIG9uIHRyYWNrIHRvCiAgICAg ICAgIGJlY29tZSBSRkMgKGVhcmx5IGFsbG9jYXRpb24gd2l0aCBhIHJlcXVlc3QgZnJvbSB0aGUg V0cgY2hhaXJzCiAgICAgICAgIGFzIGRlZmluZWQgYnkgW1JGQzcxMjBdKS4KCiAgIG8gIFRoZSBT SUQgcmFuZ2UgYWxsb2NhdGVkIGZvciBhIFlBTkcgbW9kdWxlIGNhbiBmb2xsb3cgaW4gb25lIG9m IHRoZQogICAgICBmb3VyIGNhdGVnb3JpZXM6CgogICAgICAqICBTTUFMTCAoNTAgU0lEcykKCiAg ICAgICogIE1FRElVTSAoMTAwIFNJRHMpCgogICAgICAqICBMQVJHRSAoMjUwIFNJRHMpCgogICAg ICAqICBDVVNUT00gKHJlcXVlc3RlZCBieSB0aGUgWUFORyBtb2R1bGUgYXV0aG9yLCB3aXRoIGEg bWF4aW11bSBvZgogICAgICAgICAxMDAwIFNJRHMpLiAgSW4gYWxsIGNhc2VzLCB0aGUgc2l6ZSBv ZiBhIFNJRCByYW5nZSBhc3NpZ25lZCB0bwogICAgICAgICBhIFlBTkcgbW9kdWxlIHNob3VsZCBi ZSBhdCBsZWFzdCAzMyUgYWJvdmUgdGhlIGN1cnJlbnQgbnVtYmVyCiAgICAgICAgIG9mIFlBTkcg aXRlbXMuICBUaGlzIGhlYWRyb29tIGFsbG93cyBhc3NpZ25tZW50IHdpdGhpbiB0aGUgc2FtZQog ICAgICAgICByYW5nZSBvZiBuZXcgWUFORyBpdGVtcyBpbnRyb2R1Y2VkIGJ5IHN1YnNlcXVlbnQg cmV2aXNpb25zLiAgQQogICAgICAgICBsYXJnZXIgU0lEIHJhbmdlIHNpemUgbWF5IGJlIHJlcXVl c3RlZCBieSB0aGUgYXV0aG9ycyBpZiB0aGlzCiAgICAgICAgIHJlY29tbWVuZGF0aW9uIGlzIGNv bnNpZGVyZWQgaW5zdWZmaWNpZW50LiAgSXQgaXMgaW1wb3J0YW50IHRvCiAgICAgICAgIG5vdGUg dGhhdCBhbiBhZGRpdGlvbmFsIFNJRCByYW5nZSBjYW4gYmUgYWxsb2NhdGVkIHRvIGFuCiAgICAg ICAgIGV4aXN0aW5nIFlBTkcgbW9kdWxlIGlmIHRoZSBpbml0aWFsIHJhbmdlIGlzIGV4aGF1c3Rl ZC4KCiAgIG8gIFRoZSByYW5nZSBvZiA2MCwwMDAgdG8gOTksOTk5IChzaXplIDQwLDAwMClpcyBy ZXNlcnZlZCBmb3IKICAgICAgZXhwZXJpbWVudGFsIFlBTkcgbW9kdWxlcy4gIFRoaXMgcmFuZ2Ug TVVTVCBOT1QgYmUgdXNlZCBpbgogICAgICBvcGVyYXRpb25hbCBkZXBsb3ltZW50cyBzaW5jZSB0 aGVzZSBTSURzIGFyZSBub3QgZ2xvYmFsbHkgdW5pcXVlCiAgICAgIHdoaWNoIGxpbWl0IHRoZWly IGludGVyb3BlcmFiaWxpdHkuICBUaGUgSUFOQSBwb2xpY3kgZm9yIHRoaXMKICAgICAgcmFuZ2Ug aXMgIkV4cGVyaW1lbnRhbCB1c2UiIFtSRkM4MTI2XS4KCgoKCgpWZWlsbGV0dGUsIGV0IGFsLiAg ICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAxM10KDApJ bnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAg IEZlYnJ1YXJ5IDIwMjAKCgogICBvICBUaGUgcmFuZ2Ugb2YgMTAwLDAwMCB0byA5OTksOTk5IChz aXplIDkwMCwwMDApIGlzICJSZXNlcnZlZCIgYXMKICAgICAgZGVmaW5lZCBpbiBbUkZDODEyNl0u CgogICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IEVu dHJ5IFBvaW50IHwgU2l6ZSAgICB8IElBTkEgcG9saWN5ICAgICAgfAogICArLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IDAgICAgICAgICAgIHwgMSwwMDAg ICB8IFJlc2VydmVkICAgICAgICAgfAogICB8IDEsMDAwICAgICAgIHwgNTksMDAwICB8IEV4cGVy dCBSZXZpZXcgICAgfAogICB8IDYwLDAwMCAgICAgIHwgNDAsMDAwICB8IEV4cGVyaW1lbnRhbCB1 c2UgfAogICB8IDEwMCwwMDAgICAgIHwgOTAwLDAwMCB8IFJlc2VydmVkICAgICAgICAgfAogICAr LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKwoKNi4zLjMuICBJbml0 aWFsIGNvbnRlbnRzIG9mIHRoZSByZWdpc3RyeQoKICAgSW5pdGlhbCBlbnRyaWVzIGluIHRoaXMg cmVnaXN0cnkgYXJlIGFzIGZvbGxvd3M6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAg ICAgICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRl bSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVicnVhcnkgMjAyMAoKCiAgICstLS0tLSstLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwog ICB8IEVudCB8IFNpeiB8IE1vZHVsZSBuYW1lICAgICAgICAgICAgICB8IERvY3VtZW50IHJlZmVy ZW5jZSAgICAgICAgIHwKICAgfCByeSAgfCBlICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgUG9pIHwgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IG50ICB8 ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgKy0tLS0tKy0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgMTAwIHwgMTAwIHwgaWV0Zi1jb21pICAgICAgICAg ICAgICAgIHwgW0ktRC5pZXRmLWNvcmUtY29taV0gICAgICAgfAogICB8IDAgICB8ICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg fCAxMTAgfCA1MCAgfCBpZXRmLXlhbmctdHlwZXMgICAgICAgICAgfCBbUkZDNjk5MV0gICAgICAg ICAgICAgICAgICB8CiAgIHwgMCAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDExNSB8IDUwICB8IGlldGYtaW5ldC10 eXBlcyAgICAgICAgICB8IFtSRkM2OTkxXSAgICAgICAgICAgICAgICAgIHwKICAgfCAwICAgfCAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgIHwgMTIwIHwgNTAgIHwgaWFuYS1jcnlwdC1oYXNoICAgICAgICAgIHwgW1JGQzczMTdd ICAgICAgICAgICAgICAgICAgfAogICB8IDAgICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAxMjUgfCA1MCAgfCBpZXRm LW5ldGNvbmYtYWNtICAgICAgICAgfCBbUkZDODM0MV0gICAgICAgICAgICAgICAgICB8CiAgIHwg MCAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICB8IDEzMCB8IDUwICB8IGlldGYtc2lkLWZpbGUgICAgICAgICAgICB8IFJG Q1hYWFggICAgICAgICAgICAgICAgICAgIHwKICAgfCAwICAgfCAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMTUwIHwgMTAw IHwgaWV0Zi1pbnRlcmZhY2VzICAgICAgICAgIHwgW1JGQzgzNDNdICAgICAgICAgICAgICAgICAg fAogICB8IDAgICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgfCAxNjAgfCAxMDAgfCBpZXRmLWlwICAgICAgICAgICAgICAg ICAgfCBbUkZDODM0NF0gICAgICAgICAgICAgICAgICB8CiAgIHwgMCAgIHwgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDE3 MCB8IDEwMCB8IGlldGYtc3lzdGVtICAgICAgICAgICAgICB8IFtSRkM3MzE3XSAgICAgICAgICAg ICAgICAgIHwKICAgfCAwICAgfCAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMTgwIHwgNDAwIHwgaWFuYS1pZi10eXBlICAg ICAgICAgICAgIHwgW1JGQzcyMjRdICAgICAgICAgICAgICAgICAgfAogICB8IDAgICB8ICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgfCAyNDAgfCA1MCAgfCBpZXRmLXZvdWNoZXIgICAgICAgICAgICAgfCBbUkZDODM2Nl0gICAg ICAgICAgICAgICAgICB8CiAgIHwgMCAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDI0NSB8IDUwICB8IGlldGYtY29u c3RyYWluZWQtdm91Y2hlciB8IFtJLUQuaWV0Zi1hbmltYS1jb25zdHJhaW5lIHwKICAgfCAwICAg fCAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCBkLXZvdWNoZXJdICAgICAgICAgICAg ICAgICB8CiAgIHwgMjUwIHwgNTAgIHwgaWV0Zi1jb25zdHJhaW5lZC0gICAgICAgIHwgW0ktRC5p ZXRmLWFuaW1hLWNvbnN0cmFpbmUgfAogICB8IDAgICB8ICAgICB8IHZvdWNoZXItcmVxdWVzdCAg ICAgICAgICB8IGQtdm91Y2hlcl0gICAgICAgICAgICAgICAgIHwKICAgKy0tLS0tKy0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgog ICAvLyBSRkMgRWQuOiByZXBsYWNlIFhYWFggd2l0aCBSRkMgbnVtYmVyIGFzc2lnbmVkIHRvIHRo aXMgZHJhZnQuCgogICBGb3IgYWxsb2NhdGlvbiwgUkZDIHB1YmxpY2F0aW9uIG9mIHRoZSBZQU5H IG1vZHVsZSBpcyByZXF1aXJlZCBhcyBwZXIKICAgW1JGQzgxMjZdLiAgVGhlIFlBTkcgbW9kdWxl IG11c3QgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgIllBTkcgbW9kdWxlCiAgIE5hbWUiIHJlZ2lzdHJ5 IGFjY29yZGluZyB0byB0aGUgcnVsZXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gMTQgb2YKICAgW1JG QzYwMjBdLgoKNi40LiAgQ3JlYXRlIG5ldyBJQU5BIFJlZ2lzdHJ5OiAiSUVURiBTSUQgUmVnaXN0 cnkiCgogICBUaGUgbmFtZSBvZiB0aGlzIHJlZ2lzdHJ5IGlzICJJRVRGIFNJRCBSZWdpc3RyeSIu ICBUaGlzIHJlZ2lzdHJ5IGlzCiAgIHVzZWQgdG8gcmVjb3JkIHRoZSBhbGxvY2F0aW9uIG9mIFNJ RHMgZm9yIGluZGl2aWR1YWwgWUFORyBtb2R1bGUKICAgaXRlbXMuCgoKCgoKVmVpbGxldHRlLCBl dCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2Ug MTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJ RCkgICAgICBGZWJydWFyeSAyMDIwCgoKNi40LjEuICBTdHJ1Y3R1cmUKCiAgIEVhY2ggZW50cnkg aW4gdGhpcyByZWdpc3RyeSBtdXN0IGluY2x1ZGU6CgogICBvICBUaGUgWUFORyBtb2R1bGUgbmFt ZS4gIFRoaXMgbW9kdWxlIG5hbWUgbXVzdCBiZSBwcmVzZW50IGluIHRoZQogICAgICAiTmFtZSIg Y29sdW1uIG9mIHRoZSAiWUFORyBNb2R1bGUgTmFtZXMiIHJlZ2lzdHJ5LgoKICAgbyAgQSBsaW5r IHRvIHRoZSBhc3NvY2lhdGVkICIueWFuZyIgZmlsZS4gIFRoaXMgZmlsZSBsaW5rIG11c3QgYmUK ICAgICAgcHJlc2VudCBpbiB0aGUgIkZpbGUiIGNvbHVtbiBvZiB0aGUgIllBTkcgTW9kdWxlIE5h bWVzIiByZWdpc3RyeS4KCiAgIG8gIFRoZSBsaW5rIHRvIHRoZSAiLnNpZCIgZmlsZSB3aGljaCBk ZWZpbmVzIHRoZSBhbGxvY2F0aW9uLiAgVGhlCiAgICAgICIuc2lkIiBmaWxlIGlzIHN0b3JlZCBi eSBJQU5BLgoKICAgbyAgVGhlIG51bWJlciBvZiBhY3R1YWxseSBhbGxvY2F0ZWQgU0lEcyBpbiB0 aGUgIi5zaWQiIGZpbGUuCgo2LjQuMi4gIEFsbG9jYXRpb24gcG9saWN5CgogICBUaGUgYWxsb2Nh dGlvbiBwb2xpY3kgaXMgRXhwZXJ0IHJldmlldy4gIFRoZSBFeHBlcnQgTVVTVCBlbnN1cmUgdGhh dAogICB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlIG1ldDoKCiAgIG8gIFRoZSAiLnNpZCIg ZmlsZSBoYXMgYSB2YWxpZCBzdHJ1Y3R1cmU6CgogICAgICAqICBUaGUgIi5zaWQiIGZpbGUgTVVT VCBiZSBhIHZhbGlkIEpTT04gZmlsZSBmb2xsb3dpbmcgdGhlCiAgICAgICAgIHN0cnVjdHVyZSBv ZiB0aGUgbW9kdWxlIGRlZmluZWQgaW4gUkZDWFhYWCAoUkZDIEVkOiByZXBsYWNlIFhYWAogICAg ICAgICB3aXRoIFJGQyBudW1iZXIgYXNzaWduZWQgdG8gdGhpcyBkcmFmdCkuCgogICBvICBUaGUg Ii5zaWQiIGZpbGUgYWxsb2NhdGVzIGluZGl2aWR1YWwgU0lEcyBPTkxZIGluIHRoZSBTSUQgUmFu Z2VzCiAgICAgIGZvciB0aGlzIFlBTkcgbW9kdWxlIChhcyBhbGxvY2F0ZWQgaW4gdGhlIElFVEYg U0lEIFJhbmdlCiAgICAgIFJlZ2lzdHJ5KToKCiAgICAgICogIEFsbCBTSURzIGluIHRoaXMgIi5z aWQiIGZpbGUgTVVTVCBiZSB3aXRoaW4gdGhlIHJhbmdlcwogICAgICAgICBhbGxvY2F0ZWQgdG8g dGhpcyBZQU5HIG1vZHVsZSBpbiB0aGUgIklFVEYgU0lEIFJhbmdlIFJlZ2lzdHJ5Ii4KCiAgIG8g IElmIGFub3RoZXIgIi5zaWQiIGZpbGUgaGFzIGFscmVhZHkgYWxsb2NhdGVkIFNJRHMgZm9yIHRo aXMgWUFORwogICAgICBtb2R1bGUgKGUuZy4gIGZvciBvbGRlciBvciBuZXdlciB2ZXJzaW9ucyBv ZiB0aGUgWUFORyBtb2R1bGUpLCB0aGUKICAgICAgWUFORyBpdGVtcyBhcmUgYXNzaWduZWQgdGhl IHNhbWUgU0lEcyBhcyBpbiB0aGUgb3RoZXIgIi5zaWQiIGZpbGUuCgogICBvICBJZiB0aGVyZSBp cyBhbiBvbGRlciB2ZXJzaW9uIG9mIHRoZSAiLnNpZCIgZmlsZSwgYWxsIGFsbG9jYXRlZAogICAg ICBTSURzIGZyb20gdGhhdCB2ZXJzaW9uIGFyZSBzdGlsbCBwcmVzZW50IGluIHRoZSBjdXJyZW50 IHZlcnNpb24gb2YKICAgICAgdGhlICIuc2lkIiBmaWxlLgoKICAgbyAgU0lEcyBuZXZlciBjaGFu Z2UuCgo2LjQuMy4gIFJlY3Vyc2l2ZSBBbGxvY2F0aW9uIG9mIFNJRCBSYW5nZSBhdCBEb2N1bWVu dCBBZG9wdGlvbgoKICAgRHVlIHRvIHRoZSBkaWZmaWN1bHR5IGluIGNoYW5naW5nIFNJRCB2YWx1 ZXMgZHVyaW5nIElFVEYgZG9jdW1lbnQKICAgcHJvY2Vzc2luZywgaXQgaXMgZXhwZWN0ZWQgdGhh dCBtb3N0IGRvY3VtZW50cyB3aWxsIGFzayBmb3IgU0lECiAgIGFsbG9jYXRpb25zIHVzaW5nIEVh cmx5IEFsbG9jYXRpb25zIFtSRkM3MTIwXS4gIFRoZSBkZXRhaWxzIG9mIHRoZQoKCgpWZWlsbGV0 dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICBb UGFnZSAxNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmll ciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICBFYXJseSBBbGxvY2F0aW9uIHNob3VsZCBi ZSBpbmNsdWRlZCBpbiBhbnkgV29ya2luZyBHcm91cCBBZG9wdGlvbgogICBjYWxsLiAgUHJpb3Ig dG8gV29ya2luZyBHcm91cCBBZG9wdGlvbiwgYW4gaW50ZXJuZXQgZHJhZnQgYXV0aG9ycyBjYW4K ICAgdXNlIHRoZSBleHBlcmltZW50YWwgU0lEIHJhbmdlIChhcyBwZXIgU2VjdGlvbiA2LjMuMikg Zm9yIHRoZWlyIFNJRHMKICAgYWxsb2NhdGlvbnMgb3Igb3RoZXIgdmFsdWVzIHRoYXQgZG8gbm90 IGNyZWF0ZSBhbWJpZ3VpdHkgd2l0aCBvdGhlcgogICBTSUQgdXNlcyAoZm9yIGV4YW1wbGUgdGhl eSBjYW4gdXNlIGEgcmFuZ2UgdGhhdCBjb21lcyBmcm9tIGEgbm9uLUlBTkEKICAgbWFuYWdlZCAi U0lEIE1lZ2EtUmFuZ2UiIHJlZ2lzdHJ5KS4KCiAgIEFmdGVyIFdvcmtpbmcgR3JvdXAgQWRvcHRp b24sIGFueSBtb2RpZmljYXRpb24gb2YgYSAiLnNpZCIgZmlsZSBpcwogICBleHBlY3RlZCB0byBi ZSBkaXNjdXNzZWQgb24gdGhlIG1haWxpbmcgbGlzdCBvZiB0aGUgYXBwcm9wcmlhdGUKICAgV29y a2luZyBHcm91cHMuICBTcGVjaWZpYyBhdHRlbnRpb24gc2hvdWxkIGJlIHBhaWQgdG8gaW1wbGVt ZW50ZXJzJwogICBvcGluaW9uIGFmdGVyIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGlmIGEgU0lE IHZhbHVlIGlzIHRvIGNoYW5nZSBpdHMKICAgbWVhbmluZy4gIEluIGFsbCBjYXNlcywgYSAiLnNp ZCIgZmlsZSBhbmQgdGhlIFNJRHMgYXNzb2NpYXRlZCB3aXRoIGl0CiAgIGFyZSBzdWJqZWN0IHRv IGNoYW5nZSBiZWZvcmUgdGhlIHB1YmxpY2F0aW9uIG9mIGFuIGludGVybmV0IGRyYWZ0IGFzCiAg IGFuIFJGQy4KCiAgIER1cmluZyB0aGUgZWFybHkgdXNlIG9mIFNJRHMsIG1hbnkgZXhpc3Rpbmcs IHByZXZpb3VzbHkgcHVibGlzaGVkCiAgIFlBTkcgbW9kdWxlcyB3aWxsIG5vdCBoYXZlIFNJRCBh bGxvY2F0aW9ucy4gIEZvciBhbiBhbGxvY2F0aW9uIHRvIGJlCiAgIHVzZWZ1bCB0aGUgaW5jbHVk ZWQgWUFORyBtb2R1bGVzIG1heSBhbHNvIG5lZWQgdG8gaGF2ZSBTSUQKICAgYWxsb2NhdGlvbnMg bWFkZS4KCiAgIFRoZSBFeHBlcnQgUmV2aWV3ZXIgd2hvIHBlcmZvcm1zIHRoZSAoRWFybHkpIEFs bG9jYXRpb24gYW5hbHlzaXMgd2lsbAogICBuZWVkIHRvIGdvIHRocm91Z2ggdGhlIGxpc3Qgb2Yg aW5jbHVkZWQgWUFORyBtb2R1bGVzIGFuZCBwZXJmb3JtIFNJRAogICBhbGxvY2F0aW9ucyBmb3Ig dGhvc2UgbW9kdWxlcyBhcyB3ZWxsLgoKICAgbyAgSWYgdGhlIGRvY3VtZW50IGlzIGEgcHVibGlz aGVkIFJGQywgdGhlbiB0aGUgYWxsb2NhdGlvbiBvZiBTSURzCiAgICAgIGZvciBpdHMgcmVmZXJl bmNlZCBZQU5HIG1vZHVsZXMgaXMgcGVybWFuZW50LiAgVGhlIEV4cGVydCBSZXZpZXdlcgogICAg ICBwcm92aWRlcyB0aGUgZ2VuZXJhdGVkIFNJRCBmaWxlIHRvIElBTkEgZm9yIHJlZ2lzdHJhdGlv bi4gIFRoaXMKICAgICAgcHJvY2VzcyBtYXkgYmUgdGltZSBjb25zdW1pbmcgZHVyaW5nIGEgYm9v dHN0cmFwIHBlcmlvZCAodGhlcmUgYXJlCiAgICAgIG92ZXIgMTAwIFlBTkcgbW9kdWxlcyB0byBk YXRlLCBub25lIG9mIHdoaWNoIGhhdmUgU0lECiAgICAgIGFsbG9jYXRpb25zKSwgYnV0IHNob3Vs ZCBxdWlldCBkb3duIG9uY2UgbmVlZGVkIGVudHJpZXMgYXJlCiAgICAgIGFsbG9jYXRlZC4KCiAg IG8gIElmIHRoZSBkb2N1bWVudCBpcyBhbiB1bnByb2Nlc3NlZCBJbnRlcm5ldC1EcmFmdCBhZG9w dGVkIGluIGEgV0csCiAgICAgIHRoZW4gYW4gRWFybHkgQWxsb2NhdGlvbiBpcyBwZXJmb3JtZWQg Zm9yIHRoaXMgZG9jdW1lbnQgYXMgd2VsbC4KICAgICAgRWFybHkgQWxsb2NhdGlvbnMgcmVxdWly ZSBhcHByb3ZhbCBieSBhbiBJRVNHIEFyZWEgRGlyZWN0b3IuICBBbgogICAgICBlYXJseSBhbGxv Y2F0aW9uIHdoaWNoIHJlcXVpcmVzIGFkZGl0aW9uYWwgYWxsb2NhdGlvbnMgd2lsbCBsaXN0CiAg ICAgIHRoZSBvdGhlciBhbGxvY2F0aW9ucyBpbiBpdCdzIGRlc2NyaXB0aW9uLCBhbmQgd2lsbCBi ZSBjcm9zcy0KICAgICAgcG9zdGVkIHRvIHRoZSBhbnkgb3RoZXIgd29ya2luZyBncm91cCBtYWls aW5nIGxpc3RzLgoKICAgbyAgQSBZQU5HIG1vZHVsZSB3aGljaCByZWZlcmVuY2VzIGEgbW9kdWxl IGluIGFuIGRvY3VtZW50IHdoaWNoIGhhcwogICAgICBub3QgeWV0IGJlZW4gYWRvcHRlZCBieSBh bnkgd29ya2luZyBncm91cCB3aWxsIGJlIHVuYWJsZSB0bwogICAgICBwZXJmb3JtIGFuIEVhcmx5 IEFsbG9jYXRpb24gZm9yIHRoYXQgb3RoZXIgZG9jdW1lbnQgdW50aWwgaXQgaXMKICAgICAgYWRv cHRlZCBieSBhIHdvcmtpbmcgZ3JvdXAuICBBcyBkZXNjcmliZWQgaW4gW1JGQzcxMjBdLCBhbiBB RAogICAgICBTcG9uc29yZWQgZG9jdW1lbnQgYWN0cyBhcyBpZiBpdCBoYWQgYSB3b3JraW5nIGdy b3VwLiAgVGhlCiAgICAgIGFwcHJvdmluZyBBRCBtYXkgYWxzbyBleGVtcHQgYSBkb2N1bWVudCBm cm9tIHRoaXMgcG9saWN5IGJ5CiAgICAgIGFncmVlaW5nIHRvIEFEIFNwb25zb3IgdGhlIGRvY3Vt ZW50LgoKCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIw ICAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hl bWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVicnVhcnkgMjAyMAoKCiAgIENyaXRpY2Fs bHksIHRoZSBvcmlnaW5hbCBkb2N1bWVudCBzaG91bGQgbmV2ZXIgZ2V0IHRocm91Z2ggdGhlIElF VEYKICAgcHJvY2VzcyBhbmQgdGhlbiBiZSBzdXJwcmlzZWQgdG8gYmUgcmVmZXJlbmNpbmcgYSBk b2N1bWVudCB3aG9zZQogICBwcm9ncmVzcyBpcyBub3QgY2VydGFpbi4KCiAgIEEgcHJldmlvdXNs eSBTSUQtYWxsb2NhdGVkIFlBTkcgbW9kdWxlIHdoaWNoIGNoYW5nZXMgaXRzIHJlZmVyZW5jZXMK ICAgdG8gaW5jbHVkZSBhIFlBTkcgbW9kdWxlIGZvciB3aGljaCB0aGVyZSBpcyBubyBTSUQgYWxs b2NhdGlvbiBuZWVkcwogICB0byByZXBlYXQgdGhlIEVhcmx5IEFsbG9jYXRpb24gcHJvY2Vzcy4K CiAgIEVhcmx5IEFsbG9jYXRpb25zIGFyZSBtYWRlIHdpdGggYSBvbmUteWVhciBwZXJpb2QsIGFm dGVyIHdoaWNoIHRoZXkKICAgYXJlIGV4cGlyZWQuICBbUkZDNzEyMF0gaW5kaWNhdGVzIHRoYXQg YXQgbW9zdCBvbmUgcmVuZXdhbCBtYXkgYmUKICAgbWFkZS4gIEZvciB0aGUgU0lEIGFsbG9jYXRp b24gYSBmYXIgbW9yZSBsZW5pZW50IHN0YW5jZSBpcyBkZXNpcmVkLgoKICAgMS4gIEFuIGV4dGVu c2lvbiBvZiBhIHJlZmVyZW5jaW5nIGRvY3VtZW50cyBFYXJseSBBbGxvY2F0aW9uIHNob3VsZAog ICAgICAgdXBkYXRlIGFueSByZWZlcmVuY2VkIEVhcmx5IEFsbG9jYXRpb25zIHRvIGV4cGlyZSBu byBzb29uZXIgdGhhbgogICAgICAgdGhlIHJlZmVyZW5jaW5nIGRvY3VtZW50LgoKICAgMi4gIFRo ZSBbUkZDNzEyMF0gbWVjaGFuaXNtIGFsbG93cyB0aGUgSUVTRyB0byBwcm92aWRlIGEgc2Vjb25k CiAgICAgICByZW5ld2FsLCBhbmQgc3VjaCBhbiBldmVudCBtYXkgcHJvbXB0IHNvbWUgdGhvdWdo dCBhYm91dCBob3cgdGhlCiAgICAgICBjb2xsZWN0aW9uIG9mIGRvY3VtZW50cyBhcmUgYmVpbmcg cHJvY2Vzc2VkLgoKICAgVGhpcyBpcyBkcml2ZW4gYnkgdGhlIHZlcnkgZ2VuZXJvdXMgc2l6ZSBv ZiB0aGUgU0lEIHNwYWNlIGFuZCB0aGUKICAgb2Z0ZW4gY29tcGxleCBhbmQgZGVlcCBkZXBlbmRl bmNpZXMgb2YgWUFORyBtb2R1bGVzLiAgT2Z0ZW4gYSBjb3JlCiAgIG1vZHVsZSB3aXRoIG1hbnkg ZGVwZW5kZW5jaWVzIHdpbGwgdW5kZXJnbyBleHRlbnNpdmUgcmV2aWV3LCBkZWxheWluZwogICB0 aGUgcHVibGljYXRpb24gb2Ygb3RoZXIgZG9jdW1lbnRzLgoKICAgW1JGQzcxMjBdIGFsc28gc2F5 cwoKICAgTm90ZSB0aGF0IGlmIGEgZG9jdW1lbnQgaXMgc3VibWl0dGVkIGZvciByZXZpZXcgdG8g dGhlIElFU0cgYW5kIGF0CiAgIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gc29tZSBlYXJseSBhbGxv Y2F0aW9ucyBhcmUgdmFsaWQgKG5vdAogICBleHBpcmVkKSwgdGhlc2UgYWxsb2NhdGlvbnMgc2hv dWxkIG5vdCBiZSBleHBpcmVkIHdoaWxlIHRoZSBkb2N1bWVudAogICBpcyB1bmRlciBJRVNHIGNv bnNpZGVyYXRpb24gb3Igd2FpdGluZyBpbiB0aGUgUkZDIEVkaXRvcidzIHF1ZXVlCiAgIGFmdGVy IGFwcHJvdmFsIGJ5IHRoZSBJRVNHLgoKNi40LjQuICBJbml0aWFsIGNvbnRlbnRzIG9mIHRoZSBy ZWdpc3RyeQoKICAgTm9uZS4KCjcuICBBY2tub3dsZWRnbWVudHMKCiAgIFRoZSBhdXRob3JzIHdv dWxkIGxpa2UgdG8gdGhhbmsgQW5keSBCaWVybWFuLCBDYXJzdGVuIEJvcm1hbm4sCiAgIE1pY2hh ZWwgUmljaGFyZHNvbiwgQWJoaW5hdiBTb21hcmFqdSwgUGV0ZXIgdmFuIGRlciBTdG9rLCBMYXVy ZW50CiAgIFRvdXRhaW4gYW5kIFJhbmR5IFR1cm5lciBmb3IgdGhlaXIgaGVscCBkdXJpbmcgdGhl IGRldmVsb3BtZW50IG9mCiAgIHRoaXMgZG9jdW1lbnQgYW5kIHRoZWlyIHVzZWZ1bCBjb21tZW50 cyBkdXJpbmcgdGhlIHJldmlldyBwcm9jZXNzLgoKCgoKCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAg ICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCklu dGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAg RmVicnVhcnkgMjAyMAoKCjguICBSZWZlcmVuY2VzCgo4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNl cwoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3Mg dG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJG QyAyMTE5LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LAog ICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoK ICAgW1JGQzcxMjBdICBDb3R0b24sIE0uLCAiRWFybHkgSUFOQSBBbGxvY2F0aW9uIG9mIFN0YW5k YXJkcyBUcmFjayBDb2RlCiAgICAgICAgICAgICAgUG9pbnRzIiwgQkNQIDEwMCwgUkZDIDcxMjAs IERPSSAxMC4xNzQ4Ny9SRkM3MTIwLCBKYW51YXJ5CiAgICAgICAgICAgICAgMjAxNCwgPGh0dHBz Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzEyMD4uCgogICBbUkZDNzk1MF0gIEJqb3Jr bHVuZCwgTS4sIEVkLiwgIlRoZSBZQU5HIDEuMSBEYXRhIE1vZGVsaW5nIExhbmd1YWdlIiwKICAg ICAgICAgICAgICBSRkMgNzk1MCwgRE9JIDEwLjE3NDg3L1JGQzc5NTAsIEF1Z3VzdCAyMDE2LAog ICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc5NTA+LgoK ICAgW1JGQzc5NTFdICBMaG90a2EsIEwuLCAiSlNPTiBFbmNvZGluZyBvZiBEYXRhIE1vZGVsZWQg d2l0aCBZQU5HIiwKICAgICAgICAgICAgICBSRkMgNzk1MSwgRE9JIDEwLjE3NDg3L1JGQzc5NTEs IEF1Z3VzdCAyMDE2LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9p bmZvL3JmYzc5NTE+LgoKICAgW1JGQzgxNzRdICBMZWliYSwgQi4sICJBbWJpZ3VpdHkgb2YgVXBw ZXJjYXNlIHZzIExvd2VyY2FzZSBpbiBSRkMKICAgICAgICAgICAgICAyMTE5IEtleSBXb3JkcyIs IEJDUCAxNCwgUkZDIDgxNzQsIERPSSAxMC4xNzQ4Ny9SRkM4MTc0LAogICAgICAgICAgICAgIE1h eSAyMDE3LCA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4MTc0Pi4KCjguMi4g IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJLUQuaWV0Zi1hbmltYS1jb25zdHJhaW5lZC12 b3VjaGVyXQogICAgICAgICAgICAgIFJpY2hhcmRzb24sIE0uLCBTdG9rLCBQLiwgYW5kIFAuIEth bXBhbmFraXMsICJDb25zdHJhaW5lZAogICAgICAgICAgICAgIFZvdWNoZXIgQXJ0aWZhY3RzIGZv ciBCb290c3RyYXBwaW5nIFByb3RvY29scyIsIGRyYWZ0LQogICAgICAgICAgICAgIGlldGYtYW5p bWEtY29uc3RyYWluZWQtdm91Y2hlci0wNyAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAg ICAgSmFudWFyeSAyMDIwLgoKICAgW0ktRC5pZXRmLWNvcmUtY29taV0KICAgICAgICAgICAgICBW ZWlsbGV0dGUsIE0uLCBTdG9rLCBQLiwgUGVsb3YsIEEuLCBCaWVybWFuLCBBLiwgYW5kIEkuCiAg ICAgICAgICAgICAgUGV0cm92LCAiQ29BUCBNYW5hZ2VtZW50IEludGVyZmFjZSIsIGRyYWZ0LWll dGYtY29yZS0KICAgICAgICAgICAgICBjb21pLTA4ICh3b3JrIGluIHByb2dyZXNzKSwgU2VwdGVt YmVyIDIwMTkuCgogICBbUkZDNjAyMF0gIEJqb3JrbHVuZCwgTS4sIEVkLiwgIllBTkcgLSBBIERh dGEgTW9kZWxpbmcgTGFuZ3VhZ2UgZm9yCiAgICAgICAgICAgICAgdGhlIE5ldHdvcmsgQ29uZmln dXJhdGlvbiBQcm90b2NvbCAoTkVUQ09ORikiLCBSRkMgNjAyMCwKICAgICAgICAgICAgICBET0kg MTAuMTc0ODcvUkZDNjAyMCwgT2N0b2JlciAyMDEwLAogICAgICAgICAgICAgIDxodHRwczovL3d3 dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzYwMjA+LgoKICAgW1JGQzYyNDFdICBFbm5zLCBSLiwg RWQuLCBCam9ya2x1bmQsIE0uLCBFZC4sIFNjaG9lbndhZWxkZXIsIEouLCBFZC4sCiAgICAgICAg ICAgICAgYW5kIEEuIEJpZXJtYW4sIEVkLiwgIk5ldHdvcmsgQ29uZmlndXJhdGlvbiBQcm90b2Nv bAogICAgICAgICAgICAgIChORVRDT05GKSIsIFJGQyA2MjQxLCBET0kgMTAuMTc0ODcvUkZDNjI0 MSwgSnVuZSAyMDExLAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9p bmZvL3JmYzYyNDE+LgoKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0 IDgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMTldCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZ QU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoKICAg W1JGQzY5OTFdICBTY2hvZW53YWVsZGVyLCBKLiwgRWQuLCAiQ29tbW9uIFlBTkcgRGF0YSBUeXBl cyIsCiAgICAgICAgICAgICAgUkZDIDY5OTEsIERPSSAxMC4xNzQ4Ny9SRkM2OTkxLCBKdWx5IDIw MTMsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjk5 MT4uCgogICBbUkZDNzIyNF0gIEJqb3JrbHVuZCwgTS4sICJJQU5BIEludGVyZmFjZSBUeXBlIFlB TkcgTW9kdWxlIiwKICAgICAgICAgICAgICBSRkMgNzIyNCwgRE9JIDEwLjE3NDg3L1JGQzcyMjQs IE1heSAyMDE0LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZv L3JmYzcyMjQ+LgoKICAgW1JGQzczMTddICBCaWVybWFuLCBBLiBhbmQgTS4gQmpvcmtsdW5kLCAi QSBZQU5HIERhdGEgTW9kZWwgZm9yCiAgICAgICAgICAgICAgU3lzdGVtIE1hbmFnZW1lbnQiLCBS RkMgNzMxNywgRE9JIDEwLjE3NDg3L1JGQzczMTcsIEF1Z3VzdAogICAgICAgICAgICAgIDIwMTQs IDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzczMTc+LgoKICAgW1JGQzgwNDBd ICBCaWVybWFuLCBBLiwgQmpvcmtsdW5kLCBNLiwgYW5kIEsuIFdhdHNlbiwgIlJFU1RDT05GCiAg ICAgICAgICAgICAgUHJvdG9jb2wiLCBSRkMgODA0MCwgRE9JIDEwLjE3NDg3L1JGQzgwNDAsIEph bnVhcnkgMjAxNywKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmM4MDQwPi4KCiAgIFtSRkM4MTI2XSAgQ290dG9uLCBNLiwgTGVpYmEsIEIuLCBhbmQgVC4g TmFydGVuLCAiR3VpZGVsaW5lcyBmb3IKICAgICAgICAgICAgICBXcml0aW5nIGFuIElBTkEgQ29u c2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzIiwgQkNQIDI2LAogICAgICAgICAgICAgIFJGQyA4 MTI2LCBET0kgMTAuMTc0ODcvUkZDODEyNiwgSnVuZSAyMDE3LAogICAgICAgICAgICAgIDxodHRw czovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgxMjY+LgoKICAgW1JGQzgzNDFdICBCaWVy bWFuLCBBLiBhbmQgTS4gQmpvcmtsdW5kLCAiTmV0d29yayBDb25maWd1cmF0aW9uCiAgICAgICAg ICAgICAgQWNjZXNzIENvbnRyb2wgTW9kZWwiLCBTVEQgOTEsIFJGQyA4MzQxLAogICAgICAgICAg ICAgIERPSSAxMC4xNzQ4Ny9SRkM4MzQxLCBNYXJjaCAyMDE4LAogICAgICAgICAgICAgIDxodHRw czovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgzNDE+LgoKICAgW1JGQzgzNDNdICBCam9y a2x1bmQsIE0uLCAiQSBZQU5HIERhdGEgTW9kZWwgZm9yIEludGVyZmFjZQogICAgICAgICAgICAg IE1hbmFnZW1lbnQiLCBSRkMgODM0MywgRE9JIDEwLjE3NDg3L1JGQzgzNDMsIE1hcmNoIDIwMTgs CiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODM0Mz4u CgogICBbUkZDODM0NF0gIEJqb3JrbHVuZCwgTS4sICJBIFlBTkcgRGF0YSBNb2RlbCBmb3IgSVAg TWFuYWdlbWVudCIsCiAgICAgICAgICAgICAgUkZDIDgzNDQsIERPSSAxMC4xNzQ4Ny9SRkM4MzQ0 LCBNYXJjaCAyMDE4LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9p bmZvL3JmYzgzNDQ+LgoKICAgW1JGQzgzNjZdICBXYXRzZW4sIEsuLCBSaWNoYXJkc29uLCBNLiwg UHJpdGlraW4sIE0uLCBhbmQgVC4gRWNrZXJ0LAogICAgICAgICAgICAgICJBIFZvdWNoZXIgQXJ0 aWZhY3QgZm9yIEJvb3RzdHJhcHBpbmcgUHJvdG9jb2xzIiwKICAgICAgICAgICAgICBSRkMgODM2 NiwgRE9JIDEwLjE3NDg3L1JGQzgzNjYsIE1heSAyMDE4LAogICAgICAgICAgICAgIDxodHRwczov L3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgzNjY+LgoKQXBwZW5kaXggQS4gICIuc2lkIiBm aWxlIGV4YW1wbGUKCiAgIFRoZSBmb2xsb3dpbmcgIi5zaWQiIGZpbGUgKGlldGYtc3lzdGVtQDIw MTQtMDgtMDYuc2lkKSBoYXZlIGJlZW4KICAgZ2VuZXJhdGVkIHVzaW5nIHRoZSBmb2xsb3dpbmcg eWFuZyBtb2R1bGVzOgoKICAgbyAgaWV0Zi1zeXN0ZW1AMjAxNC0wOC0wNi55YW5nCgogICBvICBp ZXRmLXlhbmctdHlwZXNAMjAxMy0wNy0xNS55YW5nCgoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAg ICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAyMF0KDApJbnRl cm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZl YnJ1YXJ5IDIwMjAKCgogICBvICBpZXRmLWluZXQtdHlwZXNAMjAxMy0wNy0xNS55YW5nCgogICBv ICBpZXRmLW5ldGNvbmYtYWNtQDIwMTItMDItMjIueWFuZwoKICAgbyAgaWFuYS1jcnlwdC1oYXNo QDIwMTQtMDQtMDQueWFuZwoKICAgewogICAgICJhc3NpZ25tZW50LXJhbmdlcyI6IFsKICAgICAg IHsKICAgICAgICAgImVudHJ5LXBvaW50IjogMTcwMCwKICAgICAgICAgInNpemUiOiAxMDAKICAg ICAgIH0KICAgICBdLAogICAgICJtb2R1bGUtbmFtZSI6ICJpZXRmLXN5c3RlbSIsCiAgICAgIm1v ZHVsZS1yZXZpc2lvbiI6ICIyMDE0LTA4LTA2IiwKICAgICAiaXRlbXMiOiBbCiAgICAgICB7CiAg ICAgICAgICJuYW1lc3BhY2UiOiAibW9kdWxlIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiaWV0 Zi1zeXN0ZW0iLAogICAgICAgICAic2lkIjogMTcwMAogICAgICAgfSwKICAgICAgIHsKICAgICAg ICAgIm5hbWVzcGFjZSI6ICJpZGVudGl0eSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogImF1dGhl bnRpY2F0aW9uLW1ldGhvZCIsCiAgICAgICAgICJzaWQiOiAxNzAxCiAgICAgICB9LAogICAgICAg ewogICAgICAgICAibmFtZXNwYWNlIjogImlkZW50aXR5IiwKICAgICAgICAgImlkZW50aWZpZXIi OiAibG9jYWwtdXNlcnMiLAogICAgICAgICAic2lkIjogMTcwMgogICAgICAgfSwKICAgICAgIHsK ICAgICAgICAgIm5hbWVzcGFjZSI6ICJpZGVudGl0eSIsCiAgICAgICAgICJpZGVudGlmaWVyIjog InJhZGl1cyIsCiAgICAgICAgICJzaWQiOiAxNzAzCiAgICAgICB9LAogICAgICAgewogICAgICAg ICAibmFtZXNwYWNlIjogImlkZW50aXR5IiwKICAgICAgICAgImlkZW50aWZpZXIiOiAicmFkaXVz LWF1dGhlbnRpY2F0aW9uLXR5cGUiLAogICAgICAgICAic2lkIjogMTcwNAogICAgICAgfSwKICAg ICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJpZGVudGl0eSIsCiAgICAgICAgICJpZGVudGlm aWVyIjogInJhZGl1cy1jaGFwIiwKICAgICAgICAgInNpZCI6IDE3MDUKICAgICAgIH0sCiAgICAg ICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiaWRlbnRpdHkiLAoKCgpWZWlsbGV0dGUsIGV0IGFs LiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAyMV0K DApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAg ICAgIEZlYnJ1YXJ5IDIwMjAKCgogICAgICAgICAiaWRlbnRpZmllciI6ICJyYWRpdXMtcGFwIiwK ICAgICAgICAgInNpZCI6IDE3MDYKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3Bh Y2UiOiAiZmVhdHVyZSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogImF1dGhlbnRpY2F0aW9uIiwK ICAgICAgICAgInNpZCI6IDE3MDcKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3Bh Y2UiOiAiZmVhdHVyZSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogImRucy11ZHAtdGNwLXBvcnQi LAogICAgICAgICAic2lkIjogMTcwOAogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVz cGFjZSI6ICJmZWF0dXJlIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAibG9jYWwtdXNlcnMiLAog ICAgICAgICAic2lkIjogMTcwOQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFj ZSI6ICJmZWF0dXJlIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAibnRwIiwKICAgICAgICAgInNp ZCI6IDE3MTAKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZmVhdHVy ZSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIm50cC11ZHAtcG9ydCIsCiAgICAgICAgICJzaWQi OiAxNzExCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImZlYXR1cmUi LAogICAgICAgICAiaWRlbnRpZmllciI6ICJyYWRpdXMiLAogICAgICAgICAic2lkIjogMTcxMgog ICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJmZWF0dXJlIiwKICAgICAg ICAgImlkZW50aWZpZXIiOiAicmFkaXVzLWF1dGhlbnRpY2F0aW9uIiwKICAgICAgICAgInNpZCI6 IDE3MTMKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZmVhdHVyZSIs CiAgICAgICAgICJpZGVudGlmaWVyIjogInRpbWV6b25lLW5hbWUiLAogICAgICAgICAic2lkIjog MTcxNAogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAg ICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnNldC1jdXJyZW50LWRhdGV0aW1lIiwK ICAgICAgICAgInNpZCI6IDE3MTUKICAgICAgIH0sCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAg ICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVy bmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVi cnVhcnkgMjAyMAoKCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAg ICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzZXQtY3VycmVudC1kYXRldGltZS8KICAg ICAgICAgICAgICAgICAgICAgICAgY3VycmVudC1kYXRldGltZSIsCiAgICAgICAgICJzaWQiOiAx NzE2CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAg ICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtIiwKICAgICAgICAgInNpZCI6 IDE3MTcKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAg ICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0tcmVzdGFydCIsCiAgICAg ICAgICJzaWQiOiAxNzE4CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjog ImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtLXNodXRk b3duIiwKICAgICAgICAgInNpZCI6IDE3MTkKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJu YW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpz eXN0ZW0tc3RhdGUiLAogICAgICAgICAic2lkIjogMTcyMAogICAgICAgfSwKICAgICAgIHsKICAg ICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYt c3lzdGVtOnN5c3RlbS1zdGF0ZS9jbG9jayIsCiAgICAgICAgICJzaWQiOiAxNzIxCiAgICAgICB9 LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRp ZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtLXN0YXRlL2Nsb2NrL2Jvb3QtZGF0ZXRpbWUiLAog ICAgICAgICAic2lkIjogMTcyMgogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFj ZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS1z dGF0ZS9jbG9jay8KICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudC1kYXRldGltZSIsCiAg ICAgICAgICJzaWQiOiAxNzIzCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNl IjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtLXN0 YXRlL3BsYXRmb3JtIiwKICAgICAgICAgInNpZCI6IDE3MjQKICAgICAgIH0sCiAgICAgICB7CgoK ClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAg ICAgICAgIFtQYWdlIDIzXQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBp RGVudGlmaWVyIChTSUQpICAgICAgRmVicnVhcnkgMjAyMAoKCiAgICAgICAgICJuYW1lc3BhY2Ui OiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0tc3Rh dGUvcGxhdGZvcm0vbWFjaGluZSIsCiAgICAgICAgICJzaWQiOiAxNzI1CiAgICAgICB9LAogICAg ICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6 ICIvaWV0Zi1zeXN0ZW06c3lzdGVtLXN0YXRlL3BsYXRmb3JtL29zLW5hbWUiLAogICAgICAgICAi c2lkIjogMTcyNgogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRh IiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS1zdGF0ZS9wbGF0 Zm9ybS9vcy1yZWxlYXNlIiwKICAgICAgICAgInNpZCI6IDE3MjcKICAgICAgIH0sCiAgICAgICB7 CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9p ZXRmLXN5c3RlbTpzeXN0ZW0tc3RhdGUvcGxhdGZvcm0vb3MtdmVyc2lvbiIsCiAgICAgICAgICJz aWQiOiAxNzI4CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEi LAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2F1dGhlbnRpY2F0 aW9uIiwKICAgICAgICAgInNpZCI6IDE3MjkKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJu YW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpz eXN0ZW0vYXV0aGVudGljYXRpb24vdXNlciIsCiAgICAgICAgICJzaWQiOiAxNzMwCiAgICAgICB9 LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRp ZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2F1dGhlbnRpY2F0aW9uLwogICAgICAgICAgICAg ICAgICAgICAgICB1c2VyLWF1dGhlbnRpY2F0aW9uLW9yZGVyIiwKICAgICAgICAgInNpZCI6IDE3 MzEKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAg ICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vYXV0aGVudGljYXRpb24vdXNl ci8KICAgICAgICAgICAgICAgICAgICAgICAgYXV0aG9yaXplZC1rZXkiLAogICAgICAgICAic2lk IjogMTczMgogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwK ICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9hdXRoZW50aWNhdGlv bi91c2VyLwogICAgICAgICAgICAgICAgICAgICAgICBhdXRob3JpemVkLWtleS9hbGdvcml0aG0i LAogICAgICAgICAic2lkIjogMTczMwogICAgICAgfSwKICAgICAgIHsKCgoKVmVpbGxldHRlLCBl dCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2Ug MjRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJ RCkgICAgICBGZWJydWFyeSAyMDIwCgoKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAg ICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9hdXRoZW50aWNhdGlvbi91 c2VyLwogICAgICAgICAgICAgICAgICAgICAgICBhdXRob3JpemVkLWtleS9rZXktZGF0YSIsCiAg ICAgICAgICJzaWQiOiAxNzM0CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNl IjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2F1 dGhlbnRpY2F0aW9uL3VzZXIvCiAgICAgICAgICAgICAgICAgICAgICAgIGF1dGhvcml6ZWQta2V5 L25hbWUiLAogICAgICAgICAic2lkIjogMTczNQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAg Im5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVt OnN5c3RlbS9hdXRoZW50aWNhdGlvbi91c2VyLwogICAgICAgICAgICAgICAgICAgICAgICBuYW1l IiwKICAgICAgICAgInNpZCI6IDE3MzYKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1l c3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0 ZW0vYXV0aGVudGljYXRpb24vdXNlci8KICAgICAgICAgICAgICAgICAgICAgICAgcGFzc3dvcmQi LAogICAgICAgICAic2lkIjogMTczNwogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVz cGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3Rl bS9jbG9jayIsCiAgICAgICAgICJzaWQiOiAxNzM4CiAgICAgICB9LAogICAgICAgewogICAgICAg ICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0 ZW06c3lzdGVtL2Nsb2NrL3RpbWV6b25lLW5hbWUiLAogICAgICAgICAic2lkIjogMTczOQogICAg ICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlk ZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9jbG9jay90aW1lem9uZS11dGMtb2Zmc2V0 IiwKICAgICAgICAgInNpZCI6IDE3NDAKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1l c3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0 ZW0vY29udGFjdCIsCiAgICAgICAgICJzaWQiOiAxNzQxCiAgICAgICB9LAogICAgICAgewogICAg ICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1z eXN0ZW06c3lzdGVtL2Rucy1yZXNvbHZlciIsCiAgICAgICAgICJzaWQiOiAxNzQyCiAgICAgICB9 LAoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAg ICAgICAgICAgICBbUGFnZSAyNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0 ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICAgICAgewogICAgICAg ICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0 ZW06c3lzdGVtL2Rucy1yZXNvbHZlci9vcHRpb25zIiwKICAgICAgICAgInNpZCI6IDE3NDMKICAg ICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJp ZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vZG5zLXJlc29sdmVyL29wdGlvbnMvCiAg ICAgICAgICAgICAgICAgICAgICAgIGF0dGVtcHRzIiwKICAgICAgICAgInNpZCI6IDE3NDQKICAg ICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJp ZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vZG5zLXJlc29sdmVyL29wdGlvbnMvCiAg ICAgICAgICAgICAgICAgICAgICAgIHRpbWVvdXQiLAogICAgICAgICAic2lkIjogMTc0NQogICAg ICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlk ZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9kbnMtcmVzb2x2ZXIvc2VhcmNoIiwKICAg ICAgICAgInNpZCI6IDE3NDYKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2Ui OiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vZG5z LXJlc29sdmVyL3NlcnZlciIsCiAgICAgICAgICJzaWQiOiAxNzQ3CiAgICAgICB9LAogICAgICAg ewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIv aWV0Zi1zeXN0ZW06c3lzdGVtL2Rucy1yZXNvbHZlci9zZXJ2ZXIvbmFtZSIsCiAgICAgICAgICJz aWQiOiAxNzQ4CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEi LAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2Rucy1yZXNvbHZl ci9zZXJ2ZXIvCiAgICAgICAgICAgICAgICAgICAgICAgIHVkcC1hbmQtdGNwIiwKICAgICAgICAg InNpZCI6IDE3NDkKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0 YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vZG5zLXJlc29s dmVyL3NlcnZlci8KICAgICAgICAgICAgICAgICAgICAgICAgdWRwLWFuZC10Y3AvYWRkcmVzcyIs CiAgICAgICAgICJzaWQiOiAxNzUwCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNw YWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVt L2Rucy1yZXNvbHZlci9zZXJ2ZXIvCiAgICAgICAgICAgICAgICAgICAgICAgIHVkcC1hbmQtdGNw L3BvcnQiLAoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAy MCAgICAgICAgICAgICAgICBbUGFnZSAyNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2No ZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICAgICAgICAi c2lkIjogMTc1MQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRh IiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9ob3N0bmFtZSIs CiAgICAgICAgICJzaWQiOiAxNzUyCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNw YWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVt L2xvY2F0aW9uIiwKICAgICAgICAgInNpZCI6IDE3NTMKICAgICAgIH0sCiAgICAgICB7CiAgICAg ICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5 c3RlbTpzeXN0ZW0vbnRwIiwKICAgICAgICAgInNpZCI6IDE3NTQKICAgICAgIH0sCiAgICAgICB7 CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9p ZXRmLXN5c3RlbTpzeXN0ZW0vbnRwL2VuYWJsZWQiLAogICAgICAgICAic2lkIjogMTc1NQogICAg ICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlk ZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9udHAvc2VydmVyIiwKICAgICAgICAgInNp ZCI6IDE3NTYKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIs CiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vbnRwL3NlcnZlci8K ICAgICAgICAgICAgICAgICAgICAgICAgYXNzb2NpYXRpb24tdHlwZSIsCiAgICAgICAgICJzaWQi OiAxNzU3CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAog ICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL250cC9zZXJ2ZXIvaWJ1 cnN0IiwKICAgICAgICAgInNpZCI6IDE3NTgKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJu YW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpz eXN0ZW0vbnRwL3NlcnZlci9uYW1lIiwKICAgICAgICAgInNpZCI6IDE3NTkKICAgICAgIH0sCiAg ICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVy IjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vbnRwL3NlcnZlci9wcmVmZXIiLAogICAgICAgICAic2lk IjogMTc2MAogICAgICAgfSwKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVn dXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMjddCgwKSW50ZXJuZXQtRHJhZnQgICAg ICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoK ICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZp ZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9udHAvc2VydmVyL3VkcCIsCiAgICAgICAgICJzaWQi OiAxNzYxCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAog ICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL250cC9zZXJ2ZXIvdWRw L2FkZHJlc3MiLAogICAgICAgICAic2lkIjogMTc2MgogICAgICAgfSwKICAgICAgIHsKICAgICAg ICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lz dGVtOnN5c3RlbS9udHAvc2VydmVyL3VkcC9wb3J0IiwKICAgICAgICAgInNpZCI6IDE3NjMKICAg ICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJp ZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vcmFkaXVzIiwKICAgICAgICAgInNpZCI6 IDE3NjQKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAg ICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vcmFkaXVzL29wdGlvbnMi LAogICAgICAgICAic2lkIjogMTc2NQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVz cGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3Rl bS9yYWRpdXMvb3B0aW9ucy9hdHRlbXB0cyIsCiAgICAgICAgICJzaWQiOiAxNzY2CiAgICAgICB9 LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRp ZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL3JhZGl1cy9vcHRpb25zL3RpbWVvdXQiLAogICAg ICAgICAic2lkIjogMTc2NwogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6 ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9yYWRp dXMvc2VydmVyIiwKICAgICAgICAgInNpZCI6IDE3NjgKICAgICAgIH0sCiAgICAgICB7CiAgICAg ICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5 c3RlbTpzeXN0ZW0vcmFkaXVzL3NlcnZlci8KICAgICAgICAgICAgICAgICAgICAgICAgYXV0aGVu dGljYXRpb24tdHlwZSIsCiAgICAgICAgICJzaWQiOiAxNzY5CiAgICAgICB9LAogICAgICAgewog ICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAg RXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAyOF0KDApJbnRlcm5l dC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1 YXJ5IDIwMjAKCgogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL3Jh ZGl1cy9zZXJ2ZXIvbmFtZSIsCiAgICAgICAgICJzaWQiOiAxNzcwCiAgICAgICB9LAogICAgICAg ewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIv aWV0Zi1zeXN0ZW06c3lzdGVtL3JhZGl1cy9zZXJ2ZXIvdWRwIiwKICAgICAgICAgInNpZCI6IDE3 NzEKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAg ICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vcmFkaXVzL3NlcnZlci91ZHAv CiAgICAgICAgICAgICAgICAgICAgICAgIGFkZHJlc3MiLAogICAgICAgICAic2lkIjogMTc3Mgog ICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAg ImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9yYWRpdXMvc2VydmVyL3VkcC8KICAg ICAgICAgICAgICAgICAgICAgICAgYXV0aGVudGljYXRpb24tcG9ydCIsCiAgICAgICAgICJzaWQi OiAxNzczCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAog ICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL3JhZGl1cy9zZXJ2ZXIv dWRwLwogICAgICAgICAgICAgICAgICAgICAgICBzaGFyZWQtc2VjcmV0IiwKICAgICAgICAgInNp ZCI6IDE3NzQKICAgICAgIH0KICAgICBdCiAgIH0KCkFwcGVuZGl4IEIuICBTSUQgYXV0byBnZW5l cmF0aW9uCgogICBBc3NpZ25tZW50IG9mIFNJRHMgdG8gWUFORyBpdGVtcyBjYW4gYmUgYXV0b21h dGVkLCB0aGUgcmVjb21tZW5kZWQKICAgcHJvY2VzcyB0byBhc3NpZ24gU0lEcyBpcyBhcyBmb2xs b3dzOgoKICAgMS4gIEEgdG9vbCBleHRyYWN0cyB0aGUgZGlmZmVyZW50IGl0ZW1zIGRlZmluZWQg Zm9yIGEgc3BlY2lmaWMgWUFORwogICAgICAgbW9kdWxlLgoKICAgMi4gIFRoZSBsaXN0IG9mIGl0 ZW1zIGlzIHNvcnRlZCBpbiBhbHBoYWJldGljYWwgb3JkZXIsICduYW1lc3BhY2UnIGluCiAgICAg ICBkZXNjZW5kaW5nIG9yZGVyLCAnaWRlbnRpZmllcicgaW4gYXNjZW5kaW5nIG9yZGVyLiAgVGhl CiAgICAgICAnbmFtZXNwYWNlJyBhbmQgJ2lkZW50aWZpZXInIGZvcm1hdHMgYXJlIGRlc2NyaWJl ZCBpbiB0aGUgWUFORwogICAgICAgbW9kdWxlICdpZXRmLXNpZC1maWxlJyBkZWZpbmVkIGluIFNl Y3Rpb24gNC4KCiAgIDMuICBTSURzIGFyZSBhc3NpZ25lZCBzZXF1ZW50aWFsbHkgZnJvbSB0aGUg ZW50cnkgcG9pbnQgdXAgdG8gdGhlCiAgICAgICBzaXplIG9mIHRoZSByZWdpc3RlcmVkIFNJRCBy YW5nZS4gIFRoaXMgYXBwcm9hY2ggaXMgcmVjb21tZW5kZWQKICAgICAgIHRvIG1pbmltaXplIHRo ZSBzZXJpYWxpemF0aW9uIG92ZXJoZWFkLCBlc3BlY2lhbGx5IHdoZW4gZGVsdGEKICAgICAgIGJl dHdlZW4gYSByZWZlcmVuY2UgU0lEIGFuZCB0aGUgY3VycmVudCBTSUQgaXMgdXNlZCBieSBwcm90 b2NvbHMKICAgICAgIGFpbWluZyB0byByZWR1Y2UgbWVzc2FnZSBzaXplLgoKCgoKVmVpbGxldHRl LCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgW1Bh Z2UgMjldCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIg KFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoKICAgNC4gIElmIHRoZSBudW1iZXIgb2YgaXRlbXMg ZXhjZWVkcyB0aGUgU0lEIHJhbmdlKHMpIGFsbG9jYXRlZCB0byBhCiAgICAgICBZQU5HIG1vZHVs ZSwgYW4gZXh0cmEgcmFuZ2UgaXMgYWRkZWQgZm9yIHN1YnNlcXVlbnQgYXNzaWdubWVudHMuCgog ICA1LiAgVGhlICJkZXBlbmRlbmNpZXMtcmV2aXNpb25zIiBzaG91bGQgcmVmbGVjdCB0aGUgcmV2 aXNpb24gbnVtYmVycwogICAgICAgb2YgZWFjaCBZQU5HIG1vZHVsZSB0aGF0IHRoZSBZQU5HIG1v ZHVsZSBpbXBvcnRzIGF0IHRoZSBtb21lbnQgb2YKICAgICAgIHRoZSBnZW5lcmF0aW9uLgoKICAg SW4gY2FzZSBvZiBhbiB1cGRhdGUgdG8gYW4gZXhpc3RpbmcgIi5zaWQiIGZpbGUsIGFuIGFkZGl0 aW9uYWwgc3RlcAogICBpcyBuZWVkZWQgdGhhdCBpbmNyZW1lbnRzIHRoZSAiLnNpZCIgZmlsZSB2 ZXJzaW9uIG51bWJlci4gIElmIHRoZXJlCiAgIHdhcyBubyB2ZXJzaW9uIG51bWJlciBpbiB0aGUg cHJldmlvdXMgdmVyc2lvbiBvZiB0aGUgIi5zaWQiIGZpbGUsIDAKICAgaXMgYXNzdW1lZCBhcyB0 aGUgdmVyc2lvbiBudW1iZXIgb2YgdGhlIG9sZCB2ZXJzaW9uIG9mIHRoZSAiLnNpZCIKICAgZmls ZSBhbmQgdGhlIHZlcnNpb24gbnVtYmVyIGlzIDEgZm9yIHRoZSBuZXcgIi5zaWQiIGZpbGUuICBB cGFydCBmcm9tCiAgIHRoYXQsIGNoYW5nZXMgb2YgU0lEIGZpbGVzIGNhbiBhbHNvIGJlIGF1dG9t YXRlZCB1c2luZyB0aGUgc2FtZQogICBtZXRob2QgZGVzY3JpYmVkIGFib3ZlLCBvbmx5IHVuYXNz aWduZWQgWUFORyBpdGVtcyBhcmUgcHJvY2Vzc2VkIGF0CiAgIHN0ZXAgIzMuICBBbHJlYWR5IGV4 aXN0aW5nIGl0ZW1zIGluIHRoZSBTSUQgZmlsZSBzaG91bGQgbm90IGJlIGdpdmVuCiAgIG5ldyBT SURzLgoKQXBwZW5kaXggQy4gICIuc2lkIiBmaWxlIGxpZmVjeWNsZQoKICAgQmVmb3JlIGFzc2ln bmluZyBTSURzIHRvIHRoZWlyIFlBTkcgbW9kdWxlcywgWUFORyBtb2R1bGUgYXV0aG9ycyBtdXN0 CiAgIGFjcXVpcmUgYSBTSUQgcmFuZ2UgZnJvbSBhICJTSUQgUmFuZ2UgUmVnaXN0cnkiLiAgSWYg dGhlIFlBTkcgbW9kdWxlCiAgIGlzIHBhcnQgb2YgYW4gSUVURiBkcmFmdCBvciBSRkMsIHRoZSBT SUQgcmFuZ2UgbmVlZCB0byBiZSBhY3F1aXJlZAogICBmcm9tIHRoZSAiSUVURiBTSUQgUmFuZ2Ug UmVnaXN0cnkiIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA2LjMuICBGb3IKICAgdGhlIG90aGVyIFlB TkcgbW9kdWxlcywgdGhlIGF1dGhvcnMgY2FuIGFjcXVpcmUgYSBTSUQgcmFuZ2UgZnJvbSBhbnkK ICAgIlNJRCBSYW5nZSBSZWdpc3RyeSIgb2YgdGhlaXIgY2hvaWNlLgoKICAgT25jZSB0aGUgU0lE IHJhbmdlIGlzIGFjcXVpcmVkLCB0aGUgb3duZXIgY2FuIHVzZSBpdCB0byBnZW5lcmF0ZQogICAi LnNpZCIgZmlsZS9zIGZvciBoaXMgWUFORyBtb2R1bGUvcy4gIEl0IGlzIHJlY29tbWVuZGVkIHRv IGxlYXZlIHNvbWUKICAgdW5hbGxvY2F0ZWQgU0lEcyBmb2xsb3dpbmcgdGhlIGFsbG9jYXRlZCBy YW5nZSBpbiBlYWNoICIuc2lkIiBmaWxlIGluCiAgIG9yZGVyIHRvIGFsbG93IGJldHRlciBldm9s dXRpb24gb2YgdGhlIFlBTkcgbW9kdWxlIGluIHRoZSBmdXR1cmUuCiAgIEdlbmVyYXRpb24gb2Yg Ii5zaWQiIGZpbGVzIHNob3VsZCBiZSBwZXJmb3JtZWQgdXNpbmcgYW4gYXV0b21hdGVkCiAgIHRv b2wuICBOb3RlIHRoYXQgIi5zaWQiIGZpbGVzIGNhbiBvbmx5IGJlIGdlbmVyYXRlZCBmb3IgWUFO RyBtb2R1bGVzCiAgIGFuZCBub3QgZm9yIHN1Ym1vZHVsZXMuCgpDLjEuICBTSUQgRmlsZSBDcmVh dGlvbgoKICAgVGhlIGZvbGxvd2luZyBhY3Rpdml0eSBkaWFncmFtIHN1bW1hcml6ZXMgdGhlIGNy ZWF0aW9uIG9mIGEgWUFORwogICBtb2R1bGUgYW5kIGl0cyBhc3NvY2lhdGVkICIuc2lkIiBmaWxl LgoKICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgTyAgICB8IENyZWF0aW9uIG9mIGEgfAogLXwt IC0+fCBZQU5HIG1vZHVsZSAgIHwKIC8gXCAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAg ICAgIHwKICAgICAgICAgICAgICAgVgogICAgICAgIC8tLS0tLS0tLS0tLS0tXAogICAgICAgLyBT dGFuZGFyZGl6ZWQgIFwgICAgIHllcwogICAgICAgXCBZQU5HIG1vZHVsZSA/IC8tLS0tLS0tLS0t LS0tKwoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAg ICAgICAgICAgICAgICBbUGFnZSAzMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1h IEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICAgICAgIFwtLS0t LS0tLS0tLS0tLyAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICB8IG5vICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgICBWICAgICAgICAgICAgICAgICAgICAgVgogICAgICAgIC8t LS0tLS0tLS0tLS0tXCAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAvIENvbnN0cmFpbmVk ICAgXCB5ZXMgfCBTSUQgcmFuZ2UgICAgIHwKICAgKy0tPlwgYXBwbGljYXRpb24gPyAvLS0tLT58 IHJlZ2lzdHJhdGlvbiAgfDwtLS0tLS0tLS0tKwogICB8ICAgIFwtLS0tLS0tLS0tLS0tLyAgICAg ICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICB8CiAgIHwgICAgICAgICAgIHwgbm8gICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgViAgICAgICAg ICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgfAogICB8ICAgKy0tLS0tLS0tLS0tLS0t LSsgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICB8CiAgICstLS18IFlBTkcgbW9kdWxl ICAgfCAgICAgfCBTSUQgc3ViLXJhbmdlIHwgICAgICAgICAgIHwKICAgICAgIHwgdXBkYXRlICAg ICAgICB8ICAgICB8IGFzc2lnbm1lbnQgICAgfDwtLS0tLS0tLS0tKwogICAgICAgKy0tLS0tLS0t LS0tLS0tLSsgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICB8CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICstLS0tLS0tLS0tLS0tKwog ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIi5zaWQiIGZpbGUgICB8ICAgIHwgUmV3b3Jr IFlBTkcgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgZ2VuZXJhdGlvbiAgICB8ICAg IHwgICAgbW9kZWwgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0rICAgICstLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICBeCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBWICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAvLS0tLS0tLS0tLVwgIHllcyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLyAgV29yayBpbiAgIFwgLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBcICBwcm9ncmVzcyAgLwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwt LS0tLS0tLS0tLwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBubwogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLy0tLS0tLS0tLS0tLS1cICAgICAgIC8tLS0tLS0tLS0tLS0tXAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAvICAgICAgUkZDICAgICAgXCBubyAgLyAgICAgT3BlbiAgICAg IFwgbm8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgcHVibGljYXRpb24/IC8tLS0t Plwgc3BlY2lmaWNhdGlvbj8vLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXC0t LS0tLS0tLS0tLS0vICAgICAgIFwtLS0tLS0tLS0tLS0tLyAgICB8CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCB5ZXMgICAgICAgICAgICAgICAgIHwgeWVzICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICArLS0tLS0tLS0tLS0t LS0tKyAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFYg ICAgIFYgICAgICAgICAgICAgICAgICAgICAgICAgICBWCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t KwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBJQU5BICAgICAgfCAgICAgICAg ICAgICAgICAgfCBUaGlyZCBwYXJ0eSAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCByZWdpc3RyYXRpb24gIHwgICAgICAgICAgICAgICAgIHwgcmVnaXN0cmF0aW9uICB8CiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tKy0tLS0tLS0rICAgICAgICAgICAgICAg ICArLS0tLS0tLSstLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtET05FXQoKICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUg MTogU0lEIExpZmVjeWNsZQoKCgoKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgIEV4cGlyZXMg QXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMzFdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICBGZWJydWFyeSAyMDIw CgoKQy4yLiAgU0lEIEZpbGUgVXBkYXRlCgogICBUaGUgZm9sbG93aW5nIEFjdGl2aXR5IGRpYWdy YW0gc3VtbWFyaXplcyB0aGUgdXBkYXRlIG9mIGEgWUFORyBtb2R1bGUKICAgYW5kIGl0cyBhc3Nv Y2lhdGVkICIuc2lkIiBmaWxlLgoKICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgTyAg ICB8IFVwZGF0ZSBvZiB0aGUgfAogICAgLXwtIC0+fCBZQU5HIG1vZHVsZSAgIHwKICAgIC8gXCAg IHwgb3IgaW5jbHVkZShzKSB8CiAgICAgICAgICB8IG9yIGltcG9ydChzKSAgfAogICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICBW CiAgICAgICAgICAgICAgLy0tLS0tLS0tLS0tLS1cCiAgICAgICAgICAgICAvICBOZXcgaXRlbXMg ICAgXCB5ZXMKICAgICAgICAgICAgIFwgIGNyZWF0ZWQgID8gICAvLS0tLS0tKwogICAgICAgICAg ICAgIFwtLS0tLS0tLS0tLS0tLyAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgIHwgbm8gICAg ICAgICAgIFYKICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAvLS0tLS0tLS0tLS0tLVwgICAg ICArLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgfCAgICAgIC8gIFNJRCBy YW5nZSAgICBcIHllcyB8IEV4dHJhIHN1Yi1yYW5nZXwKICAgICAgICAgICAgICAgICAgICAgfCAg ICAgIFwgIGV4aGF1c3RlZCA/ICAvLS0tLT58IGFzc2lnbm1lbnQgICAgIHwKICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICBcLS0tLS0tLS0tLS0tLS8gICAgICArLS0tLS0tLS0tLS0tLS0tLSsK ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCBubyAgICAgICAgICAgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLSsKICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICBWCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICArLS0t LS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAiLnNpZCIgZmlsZSAg IHwKICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwgdXBkYXRlIGJhc2VkICB8CiAgICAgICAg ICAgICAgICAgICAgIHwgICAgICB8IG9uIHByZXZpb3VzICAgfAogICAgICAgICAgICAgICAgICAg ICB8ICAgICAgfCAiLnNpZCIgZmlsZSAgIHwKICAgICAgICAgICAgICAgICAgICAgfCAgICAgICst LS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgVgogICAgICAgICAgICAgICAgICAgICB8 ICAgICAgIC8tLS0tLS0tLS0tLS0tXCAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAvICBQdWJsaWNseSAgICAgXCB5ZXMgfCBZQU5HIG1vZHVsZSAgIHwK ICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFwgIGF2YWlsYWJsZSA/ICAvLS0tLT58IHJlZ2lz dHJhdGlvbiAgfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgIFwtLS0tLS0tLS0tLS0tLyAg ICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg IHwgbm8gICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtET05FXQoKCiAgICAg ICAgICAgICAgICAgICAgRmlndXJlIDI6IFlBTkcgYW5kIFNJRCBmaWxlIHVwZGF0ZQoKCgoKCgpW ZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAg ICAgICBbUGFnZSAzMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURl bnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAg IE1pY2hlbCBWZWlsbGV0dGUgKGVkaXRvcikKICAgVHJpbGxpYW50IE5ldHdvcmtzIEluYy4KICAg NjEwIFJ1ZSBkdSBMdXhlbWJvdXJnCiAgIEdyYW5ieSwgUXVlYmVjICBKMkogMlYyCiAgIENhbmFk YQoKICAgUGhvbmU6ICsxNDUwMzc1MDU1NgogICBFbWFpbDogbWljaGVsLnZlaWxsZXR0ZUB0cmls bGlhbnQuY29tCgoKICAgQWxleGFuZGVyIFBlbG92IChlZGl0b3IpCiAgIEFja2xpbwogICAxMTM3 QSBhdmVudWUgZGVzIENoYW1wcyBCbGFuY3MKICAgQ2Vzc29uLVNldmlnbmUsIEJyZXRhZ25lICAz NTUxMAogICBGcmFuY2UKCiAgIEVtYWlsOiBhQGFja2wuaW8KCgogICBJdmF5bG8gUGV0cm92IChl ZGl0b3IpCiAgIEFja2xpbwogICAxMTM3QSBhdmVudWUgZGVzIENoYW1wcyBCbGFuY3MKICAgQ2Vz c29uLVNldmlnbmUsIEJyZXRhZ25lICAzNTUxMAogICBGcmFuY2UKCiAgIEVtYWlsOiBpdmF5bG9A YWNrbC5pbwoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICBF eHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDMzXQo= --000000000000d46dcb059dd1e165-- From nobody Wed Feb 5 04:45:45 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8D3120236 for ; Wed, 5 Feb 2020 04:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hQ3FK2fIH3n for ; Wed, 5 Feb 2020 04:45:42 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044B512013A for ; Wed, 5 Feb 2020 04:45:41 -0800 (PST) Received: from dooku.sandelman.ca (unknown [IPv6:2a02:8109:b6c0:52b8::5]) by relay.sandelman.ca (Postfix) with ESMTPS id 7D2B21F45A; Wed, 5 Feb 2020 12:45:40 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id B8547118A; Wed, 5 Feb 2020 07:45:37 -0500 (EST) From: Michael Richardson To: Ivaylo Petrov , Core cc: Andy Bierman , Alexander Pelov In-reply-to: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> <26398.1579112884@localhost> <0805B57C-3DCB-4601-976C-2D51CE812312@tzi.org> <14603.1579125396@localhost> <18568.1579133839@localhost> <5C3B4919- 5513-4342-888D-998A11366D36@tzi.org> Comments: In-reply-to Ivaylo Petrov message dated "Wed, 05 Feb 2020 11:46:59 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.1.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 05 Feb 2020 13:45:37 +0100 Message-ID: <28929.1580906737@dooku.sandelman.ca> Archived-At: Subject: Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 12:45:44 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ivaylo Petrov wrote: > leaf sid-file-version { > type sid-file-version-identifier; > description > "Version number of the \".sid\" file. Useful to distinguish \".sid\" > files generated using different YANG module dependencies that might n= ot > be reflected in the YANG module revision."; > } ... > +In case of an update to an existing ".sid" file, an additional step = is needed > +that increments the ".sid" file version number. If there was no vers= ion number > +in the previous version of the ".sid" file, 0 is assumed as the vers= ion number > +of the old version of the ".sid" file and the version number is 1 fo= r the new > +".sid" file. Apart from that, changes of SID files can also be autom= ated using > +the same method described above, only unassigned Y=C3=80NG items are= processed at > +step #3. Already existing items in the SID file should not be given = new SIDs. I don't think that this adequately makes it clear (hits them on the head...= ) that the sid-file-version-identifier is specific to the YANG module revision. Could you reword to: description "The version number of the \".sid\" file. \".sid\" files and the version sequence are specific to a given YANG module revision. This number starts at zero when there is a YANG module update. This number can distinguish updates to the SID file which are the result = of new processing, or the result of reported errata. "; =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl46uPEACgkQlUzhVv38 QpBPngf9EVVlM9Xap+kUikLkg5ZsgeYWGurzQOYlK02fIx49wSPx1qzhSS6bt/0P b25/4MxsoRru0OquWUhFA3Zx3HDZKtVaxYo97GTMawwzJLFgd/IBmP0ufuwIBQqj zYHP0zRM/7Rv+pQ+b3olGZpQ08qFMT/LksuaO6KT4fxarP0tA/3qN9A68GjV1bK+ DbZXOYy0rsODWCq/RePvZrPIRoEJYZy6TSekNayoDRswvsmLSp9S97WU/KtyR2N/ 6riwki+0KdcatG71uEqNoPBZO/00ojc36PBJKXuA0Ppm6VDeqYkawrXEiCT0Gg9f caHKRYAMhYVsq9AcZDxc4hvjX3Lqcg== =IKn1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 5 05:55:04 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40407120098 for ; Wed, 5 Feb 2020 05:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnkBNEwNa4MS for ; Wed, 5 Feb 2020 05:54:54 -0800 (PST) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 5700E120026 for ; Wed, 5 Feb 2020 05:54:53 -0800 (PST) Received: by mail-wm1-x32b.google.com with SMTP id t14so2888059wmi.5 for ; Wed, 05 Feb 2020 05:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=65JaXRFHSGjYeK0MFIYv/XysL3mlUclZA+TRR1pmdrA=; b=dTArzP218A5YltOsHJLBq2CfxZi/NBb4Rg1Lbce1qABRPh68q8sMfA+KV8WTy7eNnf t/x0imWK0/0LnT/QO/DLk5t+JQC4lITKXCa5s7KFkfMANgeVNfFPRzFZ9GtoYVeqIFzm s+Pkt+hU6PnOINwpKe3PgYDgYrL7y8pMo2bGG5EjKGKfY8LF91176U20ehZeOWnsX+a0 ZFcR2ojc1h76yyM1ztdqv7c3PC1kPNJbdQhKvz2XBUj1aKp9L1c1hg6DmpsU3V9skFM5 5TNAVkHfp+yBvwZM0amxP72ZdgOu6WPSGKEw6vFyMjoEwB/NeYYteC/mhG3tsOOOnQSx hGiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=65JaXRFHSGjYeK0MFIYv/XysL3mlUclZA+TRR1pmdrA=; b=NK/saOgRF+l/RkGKm6vZqIS5UIkj2dvP+ONZy81S7hD5KKHAxPbft6GBhY5Fds/aYy HrYCCHfk8BZe0ip6V++9wnkH6dFngU1MFin2ggexxpwi7rrVBppRnYDbSVTjABnGpy6e paRJL4qGb+RLRr9u83fOWIbYD03XR5nMQ265zNMfDLsSUCQ48/ZRQVh/ReBE7NOHUlUG vLMr3fc0DVqZmh2zuwe+43I9w0diFf2+8MlzA2+kjZzxBMiLTF0ZWt9V0gNRQAK+Vfnp LBzYOhLugw9OHIX0cHlGWDWTi9/wcWosgSEChNN9l9KCFTgcG10QNmsw/FLiyGaG3ZtY Qg6w== X-Gm-Message-State: APjAAAV4hyc9CCh53M3JkmpAUUNzMvDNwS6WGpKUzuJbhtLIrBPAJT5c WX4IfwW/serpsHmiUwZK2k5FuGnXyrbw54ZZxwnxfg== X-Google-Smtp-Source: APXvYqxIEoa/Anse74GCm1RmEEwqQmZTUbsv7lf0YP56TueFR5GnQTA1HvC4xaQJjqyZA9cF5d/9Hs4pgbXx1hcvAQg= X-Received: by 2002:a05:600c:2290:: with SMTP id 16mr5938376wmf.93.1580910891524; Wed, 05 Feb 2020 05:54:51 -0800 (PST) MIME-Version: 1.0 References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> <26398.1579112884@localhost> <0805B57C-3DCB-4601-976C-2D51CE812312@tzi.org> <14603.1579125396@localhost> <18568.1579133839@localhost> <28929.1580906737@dooku.sandelman.ca> In-Reply-To: <28929.1580906737@dooku.sandelman.ca> From: Ivaylo Petrov Date: Wed, 5 Feb 2020 14:54:25 +0100 Message-ID: To: Michael Richardson Cc: Core , Andy Bierman , Alexander Pelov Content-Type: multipart/mixed; boundary="0000000000001c9494059dd480c3" Archived-At: Subject: Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 13:55:02 -0000 --0000000000001c9494059dd480c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That really sounds better. Thank you, Michael! I updated the description in the YANG module as you suggested. I added more clarification text at the end of Appendix B: Note that ".sid" file versions are specific to a YANG module revision. For each new YANG module or each new revision of an existing YANG module, the ve= rsion number of the initial ".sid" file should either be 0 or should not be present. Best regards, Ivaylo Ivaylo Petrov Chief Architect +33 2 22 06 05 77 www.ackl.io CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). It is strictly forbidden to share any part of this message with any third party, without the written consent of the sender. If you have received this message by mistake, please notify the sender immediately by email and delete the message and any file attached to it. Thank you! On Wed, Feb 5, 2020 at 1:45 PM Michael Richardson w= rote: > > > Ivaylo Petrov wrote: > > leaf sid-file-version { > > type sid-file-version-identifier; > > description > > "Version number of the \".sid\" file. Useful to distinguish \".sid\= " > > files generated using different YANG module dependencies that might= not > > be reflected in the YANG module revision."; > > } > > ... > > +In case of an update to an existing ".sid" file, an additional ste= p is needed > > +that increments the ".sid" file version number. If there was no ve= rsion number > > +in the previous version of the ".sid" file, 0 is assumed as the ve= rsion number > > +of the old version of the ".sid" file and the version number is 1 = for the new > > +".sid" file. Apart from that, changes of SID files can also be aut= omated using > > +the same method described above, only unassigned Y=C3=80NG items a= re processed at > > +step #3. Already existing items in the SID file should not be give= n new SIDs. > > I don't think that this adequately makes it clear (hits them on the head.= ..) that the > sid-file-version-identifier is specific to the YANG module revision. > > Could you reword to: > description > "The version number of the \".sid\" file. \".sid\" files and the version > sequence are specific to a given YANG module revision. > This number starts at zero when there is a YANG module update. > This number can distinguish updates to the SID file which are the resul= t of > new processing, or the result of reported errata. "; > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > --0000000000001c9494059dd480c3 Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-core-sid-latest.txt" Content-Disposition: attachment; filename="draft-ietf-core-sid-latest.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_k69di3oi0 CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICBNLiBWZWlsbGV0dGUsIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVHJpbGxpYW50IE5ldHdvcmtzIEluYy4KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBQZWxvdiwgRWQuCkV4cGly ZXM6IEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJLiBQ ZXRyb3YsIEVkLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBY2tsaW8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDA1LCAyMDIwCgoKICAgICAgICAgICAg ICAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKQogICAgICAgICAgICAgICAg ICAgICAgICAgZHJhZnQtaWV0Zi1jb3JlLXNpZC0wOQoKQWJzdHJhY3QKCiAgIFlBTkcgU2NoZW1h IEl0ZW0gaURlbnRpZmllcnMgKFNJRCkgYXJlIGdsb2JhbGx5IHVuaXF1ZSA2My1iaXQKICAgdW5z aWduZWQgaW50ZWdlcnMgdXNlZCB0byBpZGVudGlmeSBZQU5HIGl0ZW1zLiAgVGhpcyBkb2N1bWVu dCBkZWZpbmVzCiAgIHRoZSBzZW1hbnRpY3MsIHRoZSByZWdpc3RyYXRpb24sIGFuZCBhc3NpZ25t ZW50IHByb2Nlc3NlcyBvZiBTSURzLgogICBUbyBlbmFibGUgdGhlIGltcGxlbWVudGF0aW9uIG9m IHRoZXNlIHByb2Nlc3NlcywgdGhpcyBkb2N1bWVudCBhbHNvCiAgIGRlZmluZXMgYSBmaWxlIGZv cm1hdCB1c2VkIHRvIHBlcnNpc3QgYW5kIHB1Ymxpc2ggYXNzaWduZWQgU0lEcy4KClN0YXR1cyBv ZiBUaGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwg Y29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4K CiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3Vw cyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURy YWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3Ro ZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdp bGwgZXhwaXJlIG9uIEF1Z3VzdCA4LCAyMDIwLgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJp Z2h0IChjKSAyMDIwIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhl CiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1 bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwczovL3RydXN0ZWUu aWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGlj YXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAg IGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25z IHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJh Y3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExp Y2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKCgoKVmVpbGxldHRlLCBl dCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgIFtQYWdl IDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJ RCkgICAgICBGZWJydWFyeSAyMDIwCgoKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5k IGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2lt cGxpZmllZCBCU0QgTGljZW5zZS4KClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIK ICAgMi4gIFRlcm1pbm9sb2d5IGFuZCBOb3RhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICAzCiAgIDMuICAiLnNpZCIgZmlsZSBsaWZlY3ljbGUgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICA0LiAgIi5zaWQiIGZpbGUgZm9ybWF0 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgNS4gIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDEwCiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAxMAogICAgIDYuMS4gIFJlZ2lzdGVyIFNJRCBGaWxlIEZvcm1h dCBNb2R1bGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgICA2LjIuICBDcmVhdGUg bmV3IElBTkEgUmVnaXN0cnk6ICJTSUQgTWVnYS1SYW5nZSIgcmVnaXN0cnkgLiAuIC4gIDExCiAg ICAgICA2LjIuMS4gIFN0cnVjdHVyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxMQogICAgICAgNi4yLjIuICBBbGxvY2F0aW9uIHBvbGljeSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTEKICAgICAgICAgNi4yLjIuMS4gIEZpcnN0IGFs bG9jYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgICAgICAgIDYu Mi4yLjIuICBDb25zZWN1dGl2ZSBhbGxvY2F0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxMgogICAgICAgNi4yLjMuICBJbml0aWFsIGNvbnRlbnRzIG9mIHRoZSBSZWdpc3RyeSAgLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTIKICAgICA2LjMuICBDcmVhdGUgYSBuZXcgSUFOQSBSZWdpc3Ry eTogSUVURiBTSUQgUmFuZ2UgUmVnaXN0cnkKICAgICAgICAgICAobWFuYWdlZCBieSBJQU5BKSAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgICAgICA2LjMuMS4g IFN0cnVjdHVyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MgogICAgICAgNi4zLjIuICBBbGxvY2F0aW9uIHBvbGljeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTMKICAgICAgIDYuMy4zLiAgSW5pdGlhbCBjb250ZW50cyBvZiB0aGUg cmVnaXN0cnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0CiAgICAgNi40LiAgQ3JlYXRlIG5ldyBJ QU5BIFJlZ2lzdHJ5OiAiSUVURiBTSUQgUmVnaXN0cnkiIC4gLiAuIC4gLiAuICAxNQogICAgICAg Ni40LjEuICBTdHJ1Y3R1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTYKICAgICAgIDYuNC4yLiAgQWxsb2NhdGlvbiBwb2xpY3kgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2CiAgICAgICA2LjQuMy4gIFJlY3Vyc2l2ZSBBbGxvY2F0 aW9uIG9mIFNJRCBSYW5nZSBhdCBEb2N1bWVudAogICAgICAgICAgICAgICBBZG9wdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTYKICAgICAgIDYuNC40 LiAgSW5pdGlhbCBjb250ZW50cyBvZiB0aGUgcmVnaXN0cnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDE4CiAgIDcuICBBY2tub3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxOAogICA4LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTkKICAgICA4LjEuICBOb3JtYXRpdmUg UmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5CiAgICAg OC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxOQogICBBcHBlbmRpeCBBLiAgIi5zaWQiIGZpbGUgZXhhbXBsZSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjAKICAgQXBwZW5kaXggQi4gIFNJRCBhdXRvIGdlbmVy YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI5CiAgIEFwcGVuZGl4IEMu ICAiLnNpZCIgZmlsZSBsaWZlY3ljbGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAz MAogICAgIEMuMS4gIFNJRCBGaWxlIENyZWF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMzAKICAgICBDLjIuICBTSUQgRmlsZSBVcGRhdGUgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMyCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzMwoKMS4gIElu dHJvZHVjdGlvbgoKICAgU29tZSBvZiB0aGUgaXRlbXMgZGVmaW5lZCBpbiBZQU5HIFtSRkM3OTUw XSByZXF1aXJlIHRoZSB1c2Ugb2YgYQogICB1bmlxdWUgaWRlbnRpZmllci4gIEluIGJvdGggTkVU Q09ORiBbUkZDNjI0MV0gYW5kIFJFU1RDT05GIFtSRkM4MDQwXSwKICAgdGhlc2UgaWRlbnRpZmll cnMgYXJlIGltcGxlbWVudGVkIHVzaW5nIG5hbWVzLiAgVG8gYWxsb3cgdGhlCiAgIGltcGxlbWVu dGF0aW9uIG9mIGRhdGEgbW9kZWxzIGRlZmluZWQgaW4gWUFORyBpbiBjb25zdHJhaW5lZCBkZXZp Y2VzCiAgIGFuZCBjb25zdHJhaW5lZCBuZXR3b3JrcywgYSBtb3JlIGNvbXBhY3QgbWV0aG9kIHRv IGlkZW50aWZ5IFlBTkcKICAgaXRlbXMgaXMgcmVxdWlyZWQuICBUaGlzIGNvbXBhY3QgaWRlbnRp ZmllciwgY2FsbGVkIFNJRCwgaXMgZW5jb2RlZAoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAg RXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5l dC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1 YXJ5IDIwMjAKCgogICB1c2luZyBhIDYzLWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgVGhlIGxpbWl0 YXRpb24gdG8gNjMtYml0IHVuc2lnbmVkCiAgIGludGVnZXJzIGFsbG93cyBTSURzIHRvIGJlIG1h bmlwdWxhdGVkIG1vcmUgZWFzaWx5IG9uIHBsYXRmb3JtcyB0aGF0CiAgIG1pZ2h0IG90aGVyd2lz ZSBsYWNrIG5hdGl2ZSA2NC1iaXQgdW5zaWduZWQgYXJpdGhtZXRpYy4gIFRoZSBsb3NzIG9mCiAg IGEgc2luZ2xlIGJpdCBvZiByYW5nZSBpcyBub3Qgc2lnbmlmaWNhbnQgZ2l2ZW4gdGhlIHNpemUg b2YgdGhlCiAgIHJlbWFpbmluZyBzcGFjZS4KCiAgIFRoZSBmb2xsb3dpbmcgaXRlbXMgYXJlIGlk ZW50aWZpZWQgdXNpbmcgU0lEczoKCiAgIG8gIGlkZW50aXRpZXMKCiAgIG8gIGRhdGEgbm9kZXMg KE5vdGU6IGluY2x1ZGluZyB0aG9zZSBwYXJ0cyBvZiBhIFlBTkcgdGVtcGxhdGUgYXMKICAgICAg ZGVmaW5lZCBieSB0aGUgJ3lhbmctZGF0YScgZXh0ZW5zaW9uLikKCiAgIG8gIFJQQ3MgYW5kIGFz c29jaWF0ZWQgaW5wdXQocykgYW5kIG91dHB1dChzKQoKICAgbyAgYWN0aW9ucyBhbmQgYXNzb2Np YXRlZCBpbnB1dChzKSBhbmQgb3V0cHV0KHMpCgogICBvICBub3RpZmljYXRpb25zIGFuZCBhc3Nv Y2lhdGVkIGluZm9ybWF0aW9uCgogICBvICBZQU5HIG1vZHVsZXMsIHN1Ym1vZHVsZXMgYW5kIGZl YXR1cmVzCgogICBTSURzIGFyZSBnbG9iYWxseSB1bmlxdWUgaW50ZWdlcnMsIGEgcmVnaXN0cmF0 aW9uIHN5c3RlbSBpcyB1c2VkIGluCiAgIG9yZGVyIHRvIGd1YXJhbnRlZSB0aGVpciB1bmlxdWVu ZXNzLiAgU0lEcyBhcmUgcmVnaXN0ZXJlZCBpbiBibG9ja3MKICAgY2FsbGVkICJTSUQgcmFuZ2Vz Ii4KCiAgIEFzc2lnbm1lbnQgb2YgU0lEcyB0byBZQU5HIGl0ZW1zIGNhbiBiZSBhdXRvbWF0ZWQu ICBGb3IgbW9yZSBkZXRhaWxzCiAgIGhvdyB0aGlzIGNvdWxkIGJlIGFjaGlldmVkLCBwbGVhc2Ug Y29uc3VsdCBBcHBlbmRpeCBCLgoKICAgU0lEcyBhcmUgYXNzaWduZWQgcGVybWFuZW50bHksIGl0 ZW1zIGludHJvZHVjZWQgYnkgYSBuZXcgcmV2aXNpb24gb2YKICAgYSBZQU5HIG1vZHVsZSBhcmUg YWRkZWQgdG8gdGhlIGxpc3Qgb2YgU0lEcyBhbHJlYWR5IGFzc2lnbmVkLgoKICAgU2VjdGlvbiAz IHByb3ZpZGVzIG1vcmUgZGV0YWlscyBhYm91dCB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb2YK ICAgWUFORyBtb2R1bGVzIGFuZCBhc3NvY2lhdGVkIFNJRHMuICBUbyBlbmFibGUgdGhlIGltcGxl bWVudGF0aW9uIG9mCiAgIHRoaXMgcmVnaXN0cnksIFNlY3Rpb24gNCBkZWZpbmVzIGEgc3RhbmRh cmQgZmlsZSBmb3JtYXQgdXNlZCB0byBzdG9yZQogICBhbmQgcHVibGlzaCBTSURzLgoKMi4gIFRl cm1pbm9sb2d5IGFuZCBOb3RhdGlvbgoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VM RCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZAogICAi T1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2Ny aWJlZCBpbiBCQ1AKICAgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBhbmQgb25seSB3aGVu LCB0aGV5IGFwcGVhciBpbiBhbGwKICAgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuCgogICBUaGUg Zm9sbG93aW5nIHRlcm1zIGFyZSBkZWZpbmVkIGluIFtSRkM3OTUwXToKCiAgIG8gIGFjdGlvbgoK CgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAg ICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVt IGlEZW50aWZpZXIgKFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoKICAgbyAgZmVhdHVyZQoKICAg byAgbW9kdWxlCgogICBvICBub3RpZmljYXRpb24KCiAgIG8gIFJQQwoKICAgbyAgc2NoZW1hIG5v ZGUKCiAgIG8gIHNjaGVtYSB0cmVlCgogICBvICBzdWJtb2R1bGUKCiAgIFRoZSBmb2xsb3dpbmcg dGVybSBpcyBkZWZpbmVkIGluIFtSRkM4MDQwXToKCiAgIG8gIHlhbmctZGF0YSBleHRlbnNpb24K CiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBhbHNvIG1ha2VzIHVzZSBvZiB0aGUgZm9sbG93aW5nIHRl cm1pbm9sb2d5OgoKICAgbyAgaXRlbTogQSBzY2hlbWEgbm9kZSwgYW4gaWRlbnRpdHksIGEgbW9k dWxlLCBhIHN1Ym1vZHVsZSBvciBhCiAgICAgIGZlYXR1cmUgZGVmaW5lZCB1c2luZyB0aGUgWUFO RyBtb2RlbGluZyBsYW5ndWFnZS4KCiAgIG8gIHBhdGg6IEEgcGF0aCBpcyBhIHN0cmluZyB0aGF0 IGlkZW50aWZpZXMgYSBzY2hlbWEgbm9kZSB3aXRoaW4gdGhlCiAgICAgIHNjaGVtYSB0cmVlLiAg QSBwYXRoIGNvbnNpc3RzIG9mIHRoZSBsaXN0IG9mIHNjaGVtYSBub2RlCiAgICAgIGlkZW50aWZp ZXIocykgc2VwYXJhdGVkIGJ5IHNsYXNoZXMgKCIvIikuICBTY2hlbWEgbm9kZQogICAgICBpZGVu dGlmaWVyKHMpIGFyZSBhbHdheXMgbGlzdGVkIGZyb20gdGhlIHRvcC1sZXZlbCBzY2hlbWEgbm9k ZSB1cAogICAgICB0byB0aGUgdGFyZ2V0ZWQgc2NoZW1hIG5vZGUuIChlLmcuICIvaWV0Zi1zeXN0 ZW06c3lzdGVtLQogICAgICBzdGF0ZS9jbG9jay9jdXJyZW50LWRhdGV0aW1lIikKCiAgIG8gIFlB TkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKTogVW5zaWduZWQgaW50ZWdlciB1c2VkIHRv CiAgICAgIGlkZW50aWZ5IGRpZmZlcmVudCBZQU5HIGl0ZW1zLgoKMy4gICIuc2lkIiBmaWxlIGxp ZmVjeWNsZQoKICAgWUFORyBpcyBhIGxhbmd1YWdlIGRlc2lnbmVkIHRvIG1vZGVsIGRhdGEgYWNj ZXNzZWQgdXNpbmcgb25lIG9mIHRoZQogICBjb21wYXRpYmxlIHByb3RvY29scyAoZS5nLiAgTkVU Q09ORiBbUkZDNjI0MV0sIFJFU0NPTkYgW1JGQzgwNDBdIGFuZAogICBDb1JFQ09ORiBbSS1ELmll dGYtY29yZS1jb21pXSkuICBBIFlBTkcgbW9kdWxlIGRlZmluZXMgaGllcmFyY2hpZXMgb2YKICAg ZGF0YSwgaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24sIHN0YXRlIGRhdGEsIFJQQ3MsIGFjdGlvbnMg YW5kCiAgIG5vdGlmaWNhdGlvbnMuCgogICBNYW55IFlBTkcgbW9kdWxlcyBhcmUgbm90IGNyZWF0 ZWQgaW4gdGhlIGNvbnRleHQgb2YgY29uc3RyYWluZWQKICAgYXBwbGljYXRpb25zLiAgWUFORyBt b2R1bGVzIGNhbiBiZSBpbXBsZW1lbnRlZCB1c2luZyBORVRDT05GCiAgIFtSRkM2MjQxXSBvciBS RVNUQ09ORiBbUkZDODA0MF0gd2l0aG91dCB0aGUgbmVlZCB0byBhc3NpZ24gU0lEcy4KCiAgIEFz IG5lZWRlZCwgYXV0aG9ycyBvZiBZQU5HIG1vZHVsZXMgY2FuIGFzc2lnbiBTSURzIHRvIHRoZWly IFlBTkcKICAgbW9kdWxlcy4gIEluIG9yZGVyIHRvIGRvIHRoYXQsIHRoZXkgc2hvdWxkIGZpcnN0 IG9idGFpbiBhIFNJRCByYW5nZQogICBmcm9tIGEgcmVnaXN0cnkgYW5kIHVzZSB0aGF0IHJhbmdl IHRvIGFzc2lnbiBvciBnZW5lcmF0ZSBTSURzIHRvCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAg ICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVy bmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVi cnVhcnkgMjAyMAoKCiAgIGl0ZW1zIG9mIHRoZWlyIFlBTkcgbW9kdWxlLiAgVGhlIGFzc2lnbm1l bnRzIGNhbiB0aGVuIGJlIHN0b3JlZCBpbiBhCiAgICIuc2lkIiBmaWxlLiAgRm9yIGV4YW1wbGUg aG93IHRoaXMgY291bGQgYmUgYWNoaWV2ZWQsIHBsZWFzZSByZWZlciB0bwogICBBcHBlbmRpeCBD LgoKICAgUmVnaXN0cmF0aW9uIG9mIHRoZSAiLnNpZCIgZmlsZSBhc3NvY2lhdGVkIHRvIGEgWUFO RyBtb2R1bGUgaXMKICAgb3B0aW9uYWwgYnV0IHJlY29tbWVuZGVkIHRvIHByb21vdGUgaW50ZXJv cGVyYWJpbGl0eSBiZXR3ZWVuIGRldmljZXMKICAgYW5kIHRvIGF2b2lkIGR1cGxpY2F0ZSBhbGxv Y2F0aW9uIG9mIFNJRHMgdG8gYSBzaW5nbGUgWUFORyBtb2R1bGUuCiAgIERpZmZlcmVudCByZWdp c3RyaWVzIG1pZ2h0IGhhdmUgZGlmZmVyZW50IHJlcXVpcmVtZW50cyBmb3IgdGhlCiAgIHJlZ2lz dHJhdGlvbiBhbmQgcHVibGljYXRpb24gb2YgdGhlICIuc2lkIiBmaWxlcy4gIEZvciBkaWFncmFt IG9mIG9uZQogICBvZiB0aGUgcG9zc2liaWxpdGllcywgcGxlYXNlIHJlZmVyIHRvIHRoZSBhY3Rp dml0eSBkaWFncmFtIG9uCiAgIEZpZ3VyZSAxIGluIEFwcGVuZGl4IEMuCgogICBFYWNoIHRpbWUg YSBZQU5HIG1vZHVsZSBvciBvbmUgb2YgaXRzIGltcG9ydGVkIG1vZHVsZShzKSBvciBpbmNsdWRl ZAogICBzdWItbW9kdWxlKHMpIGlzIHVwZGF0ZWQsIGEgbmV3ICIuc2lkIiBmaWxlIE1BWSBuZWVk IHRvIGJlIGNyZWF0ZWQuCiAgIEFsbCB0aGUgU0lEcyBwcmVzZW50IGluIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIG9mIHRoZSAiLnNpZCIgZmlsZSBNVVNUCiAgIGJlIHByZXNlbnQgaW4gdGhlIG5ldyB2 ZXJzaW9uIGFzIHdlbGwuICBUaGUgY3JlYXRpb24gb2YgdGhpcyBuZXcKICAgdmVyc2lvbiBvZiB0 aGUgIi5zaWQiIGZpbGUgU0hPVUxEIGJlIHBlcmZvcm1lZCB1c2luZyBhbiBhdXRvbWF0ZWQKICAg dG9vbC4KCiAgIElmIGEgbmV3IHJldmlzaW9uIHJlcXVpcmVzIG1vcmUgU0lEcyB0aGFuIGluaXRp YWxseSBhbGxvY2F0ZWQsIGEgbmV3CiAgIFNJRCByYW5nZSBNVVNUIGJlIGFkZGVkIHRvIHRoZSAn YXNzaWdubWVudC1yYW5nZXMnIGFzIGRlZmluZWQgaW4KICAgU2VjdGlvbiA0LiAgVGhlc2UgZXh0 cmEgU0lEcyBhcmUgdXNlZCBmb3Igc3Vic2VxdWVudCBhc3NpZ25tZW50cy4KCiAgIEZvciBhbiBl eGFtcGxlIG9mIHRoaXMgdXBkYXRlIHByb2Nlc3MsIHNlZSBhY3Rpdml0eSBkaWFncmFtIEZpZ3Vy ZSAyCiAgIGluIEFwcGVuZGl4IEMuCgo0LiAgIi5zaWQiIGZpbGUgZm9ybWF0CgogICAiLnNpZCIg ZmlsZXMgYXJlIHVzZWQgdG8gcGVyc2lzdCBhbmQgcHVibGlzaCBTSURzIGFzc2lnbmVkIHRvIHRo ZQogICBkaWZmZXJlbnQgWUFORyBpdGVtcyBvZiBhIHNwZWNpZmljIFlBTkcgbW9kdWxlLiAgVGhl IGZvbGxvd2luZyBZQU5HCiAgIG1vZHVsZSBkZWZpbmVkIHRoZSBzdHJ1Y3R1cmUgb2YgdGhpcyBm aWxlLCBlbmNvZGluZyBpcyBwZXJmb3JtZWQKICAgdXNpbmcgdGhlIHJ1bGVzIGRlZmluZWQgaW4g W1JGQzc5NTFdLgoKPENPREUgQkVHSU5TPiBmaWxlICJpZXRmLXNpZC1maWxlQDIwMjAtMDItMDUu eWFuZyIKbW9kdWxlIGlldGYtc2lkLWZpbGUgewogIG5hbWVzcGFjZSAidXJuOmlldGY6cGFyYW1z OnhtbDpuczp5YW5nOmlldGYtc2lkLWZpbGUiOwogIHByZWZpeCBzaWQ7CgogIGltcG9ydCBpZXRm LXlhbmctdHlwZXMgewogICAgcHJlZml4IHlhbmc7CiAgfQoKICBvcmdhbml6YXRpb24KICAgICJJ RVRGIENvcmUgV29ya2luZyBHcm91cCI7CgogIGNvbnRhY3QKICAgICJNaWNoZWwgVmVpbGxldHRl CiAgICAgPG1haWx0bzptaWNoZWwudmVpbGxldHRlQHRyaWxsaWFudC5jb20+CgoKClZlaWxsZXR0 ZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgICBb UGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVy IChTSUQpICAgICAgRmVicnVhcnkgMjAyMAoKCiAgICAgQW5keSBCaWVybWFuCiAgICAgPG1haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb20+CgogICAgIEFsZXhhbmRlciBQZWxvdgogICAgIDxtYWlsdG86 YUBhY2tsLmlvPiI7CgogIGRlc2NyaXB0aW9uCiAgICAiQ29weXJpZ2h0IChjKSAyMDE2IElFVEYg VHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMKICAgICBhdXRob3JzIG9mIHRoZSBj b2RlLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgICAgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBp biBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvcgogICAgIHdpdGhvdXQgbW9kaWZpY2F0 aW9uLCBpcyBwZXJtaXR0ZWQgcHVyc3VhbnQgdG8sIGFuZCBzdWJqZWN0IHRvCiAgICAgdGhlIGxp Y2Vuc2UgdGVybXMgY29udGFpbmVkIGluLCB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSBzZXQK ICAgICBmb3J0aCBpbiBTZWN0aW9uIDQuYyBvZiB0aGUgSUVURiBUcnVzdCdzIExlZ2FsIFByb3Zp c2lvbnMKICAgICBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAgIChodHRwczovL3RydXN0 ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKS4KCiAgICAgVGhpcyB2ZXJzaW9uIG9mIHRoaXMgWUFO RyBtb2R1bGUgaXMgcGFydCBvZiBSRkMgWFhYWAogICAgIChodHRwczovL3d3dy5yZmMtZWRpdG9y Lm9yZy9pbmZvL3JmY1hYWFgpOyBzZWUgdGhlIFJGQyBpdHNlbGYKICAgICBmb3IgZnVsbCBsZWdh bCBub3RpY2VzLgoKICAgICBUaGUga2V5IHdvcmRzICdNVVNUJywgJ01VU1QgTk9UJywgJ1JFUVVJ UkVEJywgJ1NIQUxMJywgJ1NIQUxMCiAgICAgTk9UJywgJ1NIT1VMRCcsICdTSE9VTEQgTk9UJywg J1JFQ09NTUVOREVEJywgJ05PVCBSRUNPTU1FTkRFRCcsCiAgICAgJ01BWScsIGFuZCAnT1BUSU9O QUwnIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzCiAgICAgZGVzY3Jp YmVkIGluIEJDUCAxNCAoUkZDIDIxMTkpIChSRkMgODE3NCkgd2hlbiwgYW5kIG9ubHkgd2hlbiwK ICAgICB0aGV5IGFwcGVhciBpbiBhbGwgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuCgoKICAgICBU aGlzIG1vZHVsZSBkZWZpbmVzIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIFwiLnNpZFwiIGZpbGVzLgoK ICAgICBFYWNoIFwiLnNpZFwiIGZpbGUgY29udGFpbnMgdGhlIG1hcHBpbmcgYmV0d2VlbiB0aGUg ZGlmZmVyZW50CiAgICAgc3RyaW5nIGlkZW50aWZpZXJzIGRlZmluZWQgYnkgYSBZQU5HIG1vZHVs ZSBhbmQgYQogICAgIGNvcnJlc3BvbmRpbmcgbnVtZXJpYyB2YWx1ZSBjYWxsZWQgU0lELiI7Cgog IHJldmlzaW9uIDIwMjAtMDItMDUgewogICAgZGVzY3JpcHRpb24KICAgICAgIkluaXRpYWwgcmV2 aXNpb24uIjsKICAgIHJlZmVyZW5jZQogICAgICAiW0ktRC5pZXRmLWNvcmUtc2lkXSBZQU5HIFNj aGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkiOwogIH0KCiAgdHlwZWRlZiByZXZpc2lvbi1pZGVu dGlmaWVyIHsKICAgIHR5cGUgc3RyaW5nIHsKICAgICAgcGF0dGVybiAnXGR7NH0tXGR7Mn0tXGR7 Mn0nOwogICAgfQogICAgZGVzY3JpcHRpb24KICAgICAgIlJlcHJlc2VudHMgYSBkYXRlIGluIFlZ WVktTU0tREQgZm9ybWF0LiI7CiAgfQoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJl cyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFm dCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIw MjAKCgogIHR5cGVkZWYgc2lkLWZpbGUtdmVyc2lvbi1pZGVudGlmaWVyIHsKICAgIHR5cGUgdWlu dDY0OwogICAgZGVzY3JpcHRpb24KICAgICAgIk9wdGlvbmFsIGF0dHJpYnV0ZSB0aGF0IGdpdmVz IGluZm9ybWF0aW9uIGFib3V0IHRoZSBcIi5zaWRcIiBmaWxlCiAgICAgICB2ZXJzaW9uLiI7CiAg fQoKICB0eXBlZGVmIHNpZCB7CiAgICB0eXBlIHVpbnQ2NDsKICAgIGRlc2NyaXB0aW9uCiAgICAg ICJZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIiOwogICAgcmVmZXJlbmNlCiAgICAgICJbSS1E LmlldGYtY29yZS1zaWRdIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSI7CiAgfQoK ICB0eXBlZGVmIHNjaGVtYS1ub2RlLXBhdGggewogICAgdHlwZSBzdHJpbmcgewogICAgICBwYXR0 ZXJuCiAgICAgICAgJy9bYS16QS1aX11bYS16QS1aMC05XC1fLl0qOlthLXpBLVpfXVthLXpBLVow LTlcLV8uXSonICsKICAgICAgICAnKC9bYS16QS1aX11bYS16QS1aMC05XC1fLl0qKDpbYS16QS1a X11bYS16QS1aMC05XC1fLl0qKT8pKic7CiAgICB9CiAgICBkZXNjcmlwdGlvbgogICAgICAiSWRl bnRpZmllcyBhIHNjaGVtYS1ub2RlIHBhdGggc3RyaW5nIGZvciB1c2UgaW4gdGhlCiAgICAgICBT SUQgcmVnaXN0cnkuIFRoaXMgc3RyaW5nIGZvcm1hdCBmb2xsb3dzIHRoZSBydWxlcwogICAgICAg Zm9yIGFuIGluc3RhbmNlLWlkZW50aWZpZXIsIGFzIGRlZmluZWQgaW4gUkZDIDc5NTksCiAgICAg ICBleGNlcHQgdGhhdCBubyBwcmVkaWNhdGVzIGFyZSBhbGxvd2VkLgoKICAgICAgIFRoaXMgZm9y bWF0IGlzIGludGVuZGVkIHRvIHN1cHBvcnQgdGhlIFlBTkcgMS4xIEFCTkYKICAgICAgIGZvciBh IHNjaGVtYSBub2RlIGlkZW50aWZpZXIsIGV4Y2VwdCBtb2R1bGUgbmFtZXMKICAgICAgIGFyZSB1 c2VkIGluc3RlYWQgb2YgcHJlZml4ZXMsIGFzIHNwZWNpZmllZCBpbiBSRkMgNzk1MS4iOwogICAg cmVmZXJlbmNlCiAgICAgICJSRkMgNzk1MCwgVGhlIFlBTkcgMS4xIERhdGEgTW9kZWxpbmcgTGFu Z3VhZ2U7CiAgICAgICBTZWN0aW9uIDYuNTogU2NoZW1hIE5vZGUgSWRlbnRpZmllcjsKICAgICAg IFJGQyA3OTUxLCBKU09OIEVuY29kaW5nIG9mIFlBTkcgRGF0YTsKICAgICAgIFNlY3Rpb24gNi4x MTogVGhlIGluc3RhbmNlLWlkZW50aWZpZXIgdHlwZSI7CiAgfQoKICBsZWFmIG1vZHVsZS1uYW1l IHsKICAgIHR5cGUgeWFuZzp5YW5nLWlkZW50aWZpZXI7CiAgICBkZXNjcmlwdGlvbgogICAgICAi TmFtZSBvZiB0aGUgWUFORyBtb2R1bGUgYXNzb2NpYXRlZCB3aXRoIHRoaXMgXCIuc2lkXCIgZmls ZS4iOwogIH0KCiAgbGVhZiBtb2R1bGUtcmV2aXNpb24gewogICAgdHlwZSByZXZpc2lvbi1pZGVu dGlmaWVyOwogICAgZGVzY3JpcHRpb24KICAgICAgIlJldmlzaW9uIG9mIHRoZSBZQU5HIG1vZHVs ZSBhc3NvY2lhdGVkIHdpdGggdGhpcyBcIi5zaWRcIiBmaWxlLgogICAgICAgVGhpcyBsZWFmIGlz IG5vdCBwcmVzZW50IGlmIG5vIHJldmlzaW9uIHN0YXRlbWVudCBpcwoKCgpWZWlsbGV0dGUsIGV0 IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICAgW1BhZ2Ug N10KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lE KSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICAgICAgZGVmaW5lZCBpbiB0aGUgWUFORyBtb2R1bGUu IjsKICB9CgogIGxlYWYgc2lkLWZpbGUtdmVyc2lvbiB7CiAgICB0eXBlIHNpZC1maWxlLXZlcnNp b24taWRlbnRpZmllcjsKICAgIGRlc2NyaXB0aW9uCiAgICAgICJUaGUgdmVyc2lvbiBudW1iZXIg b2YgdGhlIFwiLnNpZFwiIGZpbGUuIFwiLnNpZFwiIGZpbGVzIGFuZCB0aGUgdmVyc2lvbgogICAg ICAgc2VxdWVuY2UgYXJlIHNwZWNpZmljIHRvIGEgZ2l2ZW4gWUFORyBtb2R1bGUgcmV2aXNpb24u CiAgICAgICBUaGlzIG51bWJlciBzdGFydHMgYXQgemVybyB3aGVuIHRoZXJlIGlzIGEgWUFORyBt b2R1bGUgdXBkYXRlLgogICAgICAgVGhpcyBudW1iZXIgY2FuIGRpc3Rpbmd1aXNoIHVwZGF0ZXMg dG8gdGhlIFNJRCBmaWxlIHdoaWNoIGFyZSB0aGUgcmVzdWx0IG9mCiAgICAgICBuZXcgcHJvY2Vz c2luZywgb3IgdGhlIHJlc3VsdCBvZiByZXBvcnRlZCBlcnJhdGEuIjsKICB9CgogIGxpc3QgZGVw ZW5kZW5jaWVzLXJldmlzaW9ucyB7CiAgICBrZXkgIm1vZHVsZS1uYW1lIjsKCiAgICBkZXNjcmlw dGlvbgogICAgICAiSW5mb3JtYXRpb24gYWJvdXQgdGhlIHJldmlzaW9uIG9mIGVhY2ggWUFORyBt b2R1bGUgdGhhdCB0aGUgbW9kdWxlIGluCiAgICAgICAnbW9kdWxlLW5hbWUnIGluY2x1ZGVzIHVz ZWQgZHVyaW5nIHRoZSBcIi5zaWRcIiBmaWxlIGdlbmVyYXRpb24uIjsKCiAgICBsZWFmIG1vZHVs ZS1uYW1lIHsKICAgICAgdHlwZSB5YW5nOnlhbmctaWRlbnRpZmllcjsKICAgICAgbWFuZGF0b3J5 IHRydWU7CiAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgIk5hbWUgb2YgdGhlIFlBTkcgbW9kdWxl LCBkZXBlbmRlbmN5IG9mICdtb2R1bGUtbmFtZScsIGZvciB3aGljaAogICAgICAgICByZXZpc2lv biBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZC4iOwogICAgfQogICAgbGVhZiBtb2R1bGUtcmV2aXNp b24gewogICAgICB0eXBlIHJldmlzaW9uLWlkZW50aWZpZXI7CiAgICAgIG1hbmRhdG9yeSB0cnVl OwogICAgICBkZXNjcmlwdGlvbgogICAgICAgICJSZXZpc2lvbiBvZiB0aGUgWUFORyBtb2R1bGUs IGRlcGVuZGVuY3kgb2YgJ21vZHVsZS1uYW1lJywgZm9yIHdoaWNoCiAgICAgICAgIHJldmlzaW9u IGluZm9ybWF0aW9uIGlzIHByb3ZpZGVkLiI7CiAgICB9CiAgfQoKICBsaXN0IGFzc2lnbWVudC1y YW5nZXMgewogICAga2V5ICJlbnRyeS1wb2ludCI7CiAgICBkZXNjcmlwdGlvbgogICAgICAiU0lE IHJhbmdlKHMpIGFsbG9jYXRlZCB0byB0aGUgWUFORyBtb2R1bGUgaWRlbnRpZmllZCBieQogICAg ICAgJ21vZHVsZS1uYW1lJyBhbmQgJ21vZHVsZS1yZXZpc2lvbicuIjsKCiAgICBsZWFmIGVudHJ5 LXBvaW50IHsKICAgICAgdHlwZSBzaWQ7CiAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICBkZXNj cmlwdGlvbgogICAgICAgICJMb3dlc3QgU0lEIGF2YWlsYWJsZSBmb3IgYXNzaWdubWVudC4iOwog ICAgfQoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAg ICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1h IEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICAgbGVhZiBzaXpl IHsKICAgICAgdHlwZSB1aW50NjQ7CiAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICBkZXNjcmlw dGlvbgogICAgICAgICJOdW1iZXIgb2YgU0lEcyBhdmFpbGFibGUgZm9yIGFzc2lnbm1lbnQuIjsK ICAgIH0KICB9CgogIGxpc3QgaXRlbXMgewogICAga2V5ICJuYW1lc3BhY2UgaWRlbnRpZmllciI7 CiAgICBkZXNjcmlwdGlvbgogICAgICAiRWFjaCBlbnRyeSB3aXRoaW4gdGhpcyBsaXN0IGRlZmlu ZWQgdGhlIG1hcHBpbmcgYmV0d2VlbgogICAgICAgYSBZQU5HIGl0ZW0gc3RyaW5nIGlkZW50aWZp ZXIgYW5kIGEgU0lELiBUaGlzIGxpc3QgTVVTVAogICAgICAgaW5jbHVkZSBhIG1hcHBpbmcgZW50 cnkgZm9yIGVhY2ggWUFORyBpdGVtIGRlZmluZWQgYnkKICAgICAgIHRoZSBZQU5HIG1vZHVsZSBp ZGVudGlmaWVkIGJ5ICdtb2R1bGUtbmFtZScgYW5kCiAgICAgICAnbW9kdWxlLXJldmlzaW9uJy4i OwoKICAgIGxlYWYgbmFtZXNwYWNlIHsKICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7CiAgICAgICAg ZW51bSBtb2R1bGUgewogICAgICAgICAgdmFsdWUgMDsKICAgICAgICAgIGRlc2NyaXB0aW9uCiAg ICAgICAgICAgICJBbGwgbW9kdWxlIGFuZCBzdWJtb2R1bGUgbmFtZXMgc2hhcmUgdGhlIHNhbWUK ICAgICAgICAgICAgIGdsb2JhbCBtb2R1bGUgaWRlbnRpZmllciBuYW1lc3BhY2UuIjsKICAgICAg ICB9CiAgICAgICAgZW51bSBpZGVudGl0eSB7CiAgICAgICAgICB2YWx1ZSAxOwogICAgICAgICAg ZGVzY3JpcHRpb24KICAgICAgICAgICAgIkFsbCBpZGVudGl0eSBuYW1lcyBkZWZpbmVkIGluIGEg bW9kdWxlIGFuZCBpdHMKICAgICAgICAgICAgIHN1Ym1vZHVsZXMgc2hhcmUgdGhlIHNhbWUgaWRl bnRpdHkgaWRlbnRpZmllcgogICAgICAgICAgICAgbmFtZXNwYWNlLiI7CiAgICAgICAgfQogICAg ICAgIGVudW0gZmVhdHVyZSB7CiAgICAgICAgICB2YWx1ZSAyOwogICAgICAgICAgZGVzY3JpcHRp b24KICAgICAgICAgICAgIkFsbCBmZWF0dXJlIG5hbWVzIGRlZmluZWQgaW4gYSBtb2R1bGUgYW5k IGl0cwogICAgICAgICAgICAgc3VibW9kdWxlcyBzaGFyZSB0aGUgc2FtZSBmZWF0dXJlIGlkZW50 aWZpZXIKICAgICAgICAgICAgIG5hbWVzcGFjZS4iOwogICAgICAgIH0KICAgICAgICBlbnVtIGRh dGEgewogICAgICAgICAgdmFsdWUgMzsKICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAg ICJUaGUgbmFtZXNwYWNlIGZvciBhbGwgZGF0YSBub2RlcywgYXMgZGVmaW5lZCBpbiBZQU5HLiI7 CiAgICAgICAgfQogICAgICB9CiAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgIk5hbWVzcGFjZSBv ZiB0aGUgWUFORyBpdGVtIGZvciB0aGlzIG1hcHBpbmcgZW50cnkuIjsKICAgIH0KCgoKVmVpbGxl dHRlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAg IFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZp ZXIgKFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoKICAgIGxlYWYgaWRlbnRpZmllciB7CiAgICAg IHR5cGUgdW5pb24gewogICAgICAgIHR5cGUgeWFuZzp5YW5nLWlkZW50aWZpZXI7CiAgICAgICAg dHlwZSBzY2hlbWEtbm9kZS1wYXRoOwogICAgICB9CiAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAg IlN0cmluZyBpZGVudGlmaWVyIG9mIHRoZSBZQU5HIGl0ZW0gZm9yIHRoaXMgbWFwcGluZyBlbnRy eS4KCiAgICAgICAgIElmIHRoZSBjb3JyZXNwb25kaW5nICduYW1lc3BhY2UnIGZpZWxkIGlzICdt b2R1bGUnLAogICAgICAgICAnZmVhdHVyZScsIG9yICdpZGVudGl0eScsIHRoZW4gdGhpcyBmaWVs ZCBNVVNUCiAgICAgICAgIGNvbnRhaW4gYSB2YWxpZCBZQU5HIGlkZW50aWZpZXIgc3RyaW5nLgoK ICAgICAgICAgSWYgdGhlIGNvcnJlc3BvbmRpbmcgJ25hbWVzcGFjZScgZmllbGQgaXMgJ2RhdGEn LAogICAgICAgICB0aGVuIHRoaXMgZmllbGQgTVVTVCBjb250YWluIGEgdmFsaWQgc2NoZW1hIG5v ZGUKICAgICAgICAgcGF0aC4iOwogICAgIH0KCiAgICBsZWFmIHNpZCB7CiAgICAgIHR5cGUgc2lk OwogICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAgICAgZGVzY3JpcHRpb24KICAgICAgICAiU0lEIGFz c2lnbmVkIHRvIHRoZSBZQU5HIGl0ZW0gZm9yIHRoaXMgbWFwcGluZyBlbnRyeS4iOwogICAgfQog IH0KfQo8Q09ERSBFTkRTPgoKNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgYSBuZXcgdHlwZSBvZiBpZGVudGlmaWVyIHVzZWQgdG8gZW5jb2RlIGRh dGEKICAgbW9kZWxzIGRlZmluZWQgaW4gWUFORyBbUkZDNzk1MF0uICBBcyBzdWNoLCB0aGlzIGlk ZW50aWZpZXIgZG9lcyBub3QKICAgY29udHJpYnV0ZSB0byBhbnkgbmV3IHNlY3VyaXR5IGlzc3Vl cyBpbiBhZGRpdGlvbiBvZiB0aG9zZSBpZGVudGlmaWVkCiAgIGZvciB0aGUgc3BlY2lmaWMgcHJv dG9jb2xzIG9yIGNvbnRleHRzIGZvciB3aGljaCBpdCBpcyB1c2VkLgoKNi4gIElBTkEgQ29uc2lk ZXJhdGlvbnMKCjYuMS4gIFJlZ2lzdGVyIFNJRCBGaWxlIEZvcm1hdCBNb2R1bGUKCiAgIFRoaXMg ZG9jdW1lbnQgcmVnaXN0ZXJzIG9uZSBZQU5HIG1vZHVsZSBpbiB0aGUgIllBTkcgTW9kdWxlIE5h bWVzIgogICByZWdpc3RyeSBbUkZDNjAyMF06CgogICBvICBuYW1lOiBpZXRmLXNpZC1maWxlCgog ICBvICBuYW1lc3BhY2U6IHVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXNpZC1maWxl CgogICBvICBwcmVmaXg6IHNpZAoKICAgbyAgcmVmZXJlbmNlOiBbW1RISVNSRkNdXQoKCgpWZWls bGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAg ICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRp ZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgo2LjIuICBDcmVhdGUgbmV3IElBTkEgUmVn aXN0cnk6ICJTSUQgTWVnYS1SYW5nZSIgcmVnaXN0cnkKCiAgIFRoZSBuYW1lIG9mIHRoaXMgcmVn aXN0cnkgaXMgIlNJRCBNZWdhLVJhbmdlIi4gIFRoaXMgcmVnaXN0cnkgaXMgdXNlZAogICB0byBy ZWNvcmQgdGhlIGRlbGVnYXRpb24gb2YgdGhlIG1hbmFnZW1lbnQgb2YgYSBibG9jayBvZiBTSURz IHRvCiAgIHRoaXJkIHBhcnRpZXMgKHN1Y2ggYXMgU0RPcyBvciByZWdpc3RyYXJzKS4KCjYuMi4x LiAgU3RydWN0dXJlCgogICBFYWNoIGVudHJ5IGluIHRoaXMgcmVnaXN0cnkgbXVzdCBpbmNsdWRl OgoKICAgbyAgVGhlIGVudHJ5IHBvaW50IChmaXJzdCBTSUQpIG9mIHRoZSByZWdpc3RlcmVkIFNJ RCBibG9jay4KCiAgIG8gIFRoZSBzaXplIG9mIHRoZSByZWdpc3RlcmVkIFNJRCBibG9jay4gIFRo ZSBzaXplIE1VU1QgYmUgb25lCiAgICAgIG1pbGxpb24gKDEgMDAwIDAwMCkgU0lEcy4KCiAgIG8g IFRoZSBjb250YWN0IGluZm9ybWF0aW9uIG9mIHRoZSByZXF1ZXN0aW5nIG9yZ2FuaXphdGlvbiBp bmNsdWRpbmc6CgogICAgICAqICBUaGUgcG9saWN5IG9mIFNJRCByYW5nZSBhbGxvY2F0aW9uczog UHVibGljLCBQcml2YXRlIG9yIEJvdGguCgogICAgICAqICBPcmdhbml6YXRpb24gbmFtZQoKICAg ICAgKiAgVVJMCgogICBUaGUgaW5mb3JtYXRpb24gYXNzb2NpYXRlZCB0byB0aGUgT3JnYW5pemF0 aW9uIG5hbWUgc2hvdWxkIG5vdCBiZQogICBwdWJsaWNseSB2aXNpYmxlIGluIHRoZSByZWdpc3Ry eSwgYnV0IHNob3VsZCBiZSBhdmFpbGFibGUuICBUaGlzCiAgIGluZm9ybWF0aW9uIGluY2x1ZGVz IGNvbnRhY3QgZW1haWwgYW5kIHBob25lIG51bWJlciBhbmQgY2hhbmdlCiAgIGNvbnRyb2xsZXIg ZW1haWwgYW5kIHBob25lIG51bWJlci4KCjYuMi4yLiAgQWxsb2NhdGlvbiBwb2xpY3kKCiAgIFRo ZSBJQU5BIHBvbGljeSBmb3IgZnV0dXJlIGFkZGl0aW9ucyB0byB0aGlzIHJlZ2lzdHJ5IGlzICJF eHBlcnQKICAgUmV2aWV3IiBbUkZDODEyNl0uCgogICBBbiBvcmdhbml6YXRpb24gcmVxdWVzdGlu ZyB0byBtYW5hZ2UgYSBTSUQgUmFuZ2UgKGFuZCB0aHVzIGhhdmUgYW4KICAgZW50cnkgaW4gdGhl IFNJRCBNZWdhLVJhbmdlIFJlZ2lzdHJ5KSwgbXVzdCBlbnN1cmUgdGhlIGZvbGxvd2luZwogICBj YXBhY2l0aWVzOgoKICAgbyAgVGhlIGNhcGFjaXR5IHRvIG1hbmFnZSBhbmQgb3BlcmF0ZSBhIFNJ RCBSYW5nZSBSZWdpc3RyeS4gIEEgU0lECiAgICAgIFJhbmdlIFJlZ2lzdHJ5IE1VU1QgcHJvdmlk ZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIGZvciBhbGwgU0lECiAgICAgIFJhbmdlcyBhbGxv Y2F0ZWQgYnkgdGhlIFJlZ2lzdHJ5OgoKICAgICAgKiAgRW50cnkgUG9pbnQgb2YgYWxsb2NhdGVk IFNJRCBSYW5nZQoKICAgICAgKiAgU2l6ZSBvZiBhbGxvY2F0ZWQgU0lEIFJhbmdlCgogICAgICAq ICBUeXBlOiBQdWJsaWMgb3IgUHJpdmF0ZQoKCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICBF eHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDExXQoMCkludGVybmV0 LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVicnVh cnkgMjAyMAoKCiAgICAgICAgICsgIFB1YmxpYyBSYW5nZXMgTVVTVCBpbmNsdWRlIGF0IGxlYXN0 IGEgcmVmZXJlbmNlIHRvIHRoZSBZQU5HCiAgICAgICAgICAgIG1vZHVsZSBhbmQgIi5zaWQiIGZp bGVzIGZvciB0aGF0IFNJRCBSYW5nZS4KCiAgICAgICAgICsgIFByaXZhdGUgUmFuZ2VzIE1VU1Qg YmUgbWFya2VkIGFzICJQcml2YXRlIgoKICAgbyAgQSBQb2xpY3kgb2YgYWxsb2NhdGlvbiwgd2hp Y2ggY2xlYXJseSBpZGVudGlmaWVzIGlmIHRoZSBTSUQgUmFuZ2UKICAgICAgYWxsb2NhdGlvbnMg d291bGQgYmUgUHJpdmF0ZSwgUHVibGljIG9yIEJvdGguCgogICBvICBUZWNobmljYWwgY2FwYWNp dHkgdG8gZW5zdXJlIHRoZSBzdXN0YWluZWQgb3BlcmF0aW9uIG9mIHRoZQogICAgICByZWdpc3Ry eSBmb3IgYSBwZXJpb2Qgb2YgYXQgbGVhc3QgNSB5ZWFycy4gIElmIFByaXZhdGUKICAgICAgUmVn aXN0cmF0aW9ucyBhcmUgYWxsb3dlZCwgdGhlIHBlcmlvZCBtdXN0IGJlIG9mIGF0IGxlYXN0IDEw CiAgICAgIHllYXJzLgoKNi4yLjIuMS4gIEZpcnN0IGFsbG9jYXRpb24KCiAgIEZvciBhIGZpcnN0 IGFsbG9jYXRpb24gdG8gYmUgcHJvdmlkZWQsIHRoZSByZXF1ZXN0aW5nIG9yZ2FuaXphdGlvbgog ICBtdXN0IGRlbW9uc3RyYXRlIGEgZnVuY3Rpb25hbCByZWdpc3RyeSBpbmZyYXN0cnVjdHVyZS4K CjYuMi4yLjIuICBDb25zZWN1dGl2ZSBhbGxvY2F0aW9ucwoKICAgT24gc3Vic2VxdWVudCBhbGxv Y2F0aW9uIHJlcXVlc3QocyksIHRoZSBvcmdhbml6YXRpb24gbXVzdAogICBkZW1vbnN0cmF0ZSB0 aGUgZXhoYXVzdGlvbiBvZiB0aGUgcHJpb3IgcmFuZ2UuICBUaGVzZSBjb25kaXRpb25zIG5lZWQK ICAgdG8gYmUgYXNzZXJ0ZWQgYnkgdGhlIGFzc2lnbmVkIGV4cGVydChzKS4KCiAgIElmIHRoYXQg ZXh0cmEtYWxsb2NhdGlvbiBpcyBkb25lIHdpdGhpbiAzIHllYXJzIGZyb20gdGhlIGxhc3QKICAg YWxsb2NhdGlvbiwgdGhlIGV4cGVydHMgbmVlZCB0byBkaXNjdXNzIHRoaXMgcmVxdWVzdCBvbiB0 aGUgQ09SRQogICB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBhbmQgY29uc2Vuc3VzIG5lZWRz IHRvIGJlIG9idGFpbmVkIGJlZm9yZQogICBhbGxvY2F0aW5nIGEgbmV3IE1lZ2EtUmFuZ2UuCgo2 LjIuMy4gIEluaXRpYWwgY29udGVudHMgb2YgdGhlIFJlZ2lzdHJ5CgogICBUaGUgaW5pdGlhbCBl bnRyeSBpbiB0aGlzIHJlZ2lzdHJ5IGlzIGFsbG9jYXRlZCB0byBJQU5BOgoKICAgKy0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0rCiAgIHwgRW50cnkgUG9pbnQgfCBTaXplICAgIHwgQWxsb2NhdGlvbiB8IE9yZ2FuaXphdGlv biBuYW1lIHwgVVJMICAgICAgfAogICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSsKICAgfCAwICAgICAgICAgICB8IDEw MDAwMDAgfCBQdWJsaWMgICAgIHwgSUFOQSAgICAgICAgICAgICAgfCBpYW5hLm9yZyB8CiAgICst LS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tKwoKNi4zLiAgQ3JlYXRlIGEgbmV3IElBTkEgUmVnaXN0cnk6IElFVEYgU0lEIFJh bmdlIFJlZ2lzdHJ5IChtYW5hZ2VkIGJ5CiAgICAgIElBTkEpCgo2LjMuMS4gIFN0cnVjdHVyZQoK ICAgRWFjaCBlbnRyeSBpbiB0aGlzIHJlZ2lzdHJ5IG11c3QgaW5jbHVkZToKCiAgIG8gIFRoZSBT SUQgcmFuZ2UgZW50cnkgcG9pbnQuCgoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJl cyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFm dCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIw MjAKCgogICBvICBUaGUgU0lEIHJhbmdlIHNpemUuCgogICBvICBUaGUgWUFORyBtb2R1bGUgbmFt ZS4KCiAgIG8gIERvY3VtZW50IHJlZmVyZW5jZS4KCjYuMy4yLiAgQWxsb2NhdGlvbiBwb2xpY3kK CiAgIFRoZSBmaXJzdCBtaWxsaW9uIFNJRHMgYXNzaWduZWQgdG8gSUFOQSBpcyBzdWItZGl2aWRl ZCBhcyBmb2xsb3dzOgoKICAgbyAgVGhlIHJhbmdlIG9mIDAgdG8gOTk5IChzaXplIDEwMDApIGlz ICJSZXNlcnZlZCIgYXMgZGVmaW5lZCBpbgogICAgICBbUkZDODEyNl0uCgogICBvICBUaGUgcmFu Z2Ugb2YgMTAwMCB0byA1OSw5OTkgKHNpemUgNTksMDAwKSBpcyByZXNlcnZlZCBmb3IgWUFORwog ICAgICBtb2R1bGVzIGRlZmluZWQgaW4gUkZDcy4gIFRoZSBJQU5BIHBvbGljeSBmb3IgYWRkaXRp b25zIHRvIHRoaXMKICAgICAgcmVnaXN0cnkgaXMgIkV4cGVydCBSZXZpZXciIFtSRkM4MTI2XS4K CiAgICAgICogIFRoZSBFeHBlcnQgTVVTVCB2ZXJpZnkgdGhhdCB0aGUgWUFORyBtb2R1bGUgZm9y IHdoaWNoIHRoaXMKICAgICAgICAgYWxsb2NhdGlvbiBpcyBtYWRlIGhhcyBhbiBSRkMgKGV4aXN0 aW5nIFJGQykgT1IgaXMgb24gdHJhY2sgdG8KICAgICAgICAgYmVjb21lIFJGQyAoZWFybHkgYWxs b2NhdGlvbiB3aXRoIGEgcmVxdWVzdCBmcm9tIHRoZSBXRyBjaGFpcnMKICAgICAgICAgYXMgZGVm aW5lZCBieSBbUkZDNzEyMF0pLgoKICAgbyAgVGhlIFNJRCByYW5nZSBhbGxvY2F0ZWQgZm9yIGEg WUFORyBtb2R1bGUgY2FuIGZvbGxvdyBpbiBvbmUgb2YgdGhlCiAgICAgIGZvdXIgY2F0ZWdvcmll czoKCiAgICAgICogIFNNQUxMICg1MCBTSURzKQoKICAgICAgKiAgTUVESVVNICgxMDAgU0lEcykK CiAgICAgICogIExBUkdFICgyNTAgU0lEcykKCiAgICAgICogIENVU1RPTSAocmVxdWVzdGVkIGJ5 IHRoZSBZQU5HIG1vZHVsZSBhdXRob3IsIHdpdGggYSBtYXhpbXVtIG9mCiAgICAgICAgIDEwMDAg U0lEcykuICBJbiBhbGwgY2FzZXMsIHRoZSBzaXplIG9mIGEgU0lEIHJhbmdlIGFzc2lnbmVkIHRv CiAgICAgICAgIGEgWUFORyBtb2R1bGUgc2hvdWxkIGJlIGF0IGxlYXN0IDMzJSBhYm92ZSB0aGUg Y3VycmVudCBudW1iZXIKICAgICAgICAgb2YgWUFORyBpdGVtcy4gIFRoaXMgaGVhZHJvb20gYWxs b3dzIGFzc2lnbm1lbnQgd2l0aGluIHRoZSBzYW1lCiAgICAgICAgIHJhbmdlIG9mIG5ldyBZQU5H IGl0ZW1zIGludHJvZHVjZWQgYnkgc3Vic2VxdWVudCByZXZpc2lvbnMuICBBCiAgICAgICAgIGxh cmdlciBTSUQgcmFuZ2Ugc2l6ZSBtYXkgYmUgcmVxdWVzdGVkIGJ5IHRoZSBhdXRob3JzIGlmIHRo aXMKICAgICAgICAgcmVjb21tZW5kYXRpb24gaXMgY29uc2lkZXJlZCBpbnN1ZmZpY2llbnQuICBJ dCBpcyBpbXBvcnRhbnQgdG8KICAgICAgICAgbm90ZSB0aGF0IGFuIGFkZGl0aW9uYWwgU0lEIHJh bmdlIGNhbiBiZSBhbGxvY2F0ZWQgdG8gYW4KICAgICAgICAgZXhpc3RpbmcgWUFORyBtb2R1bGUg aWYgdGhlIGluaXRpYWwgcmFuZ2UgaXMgZXhoYXVzdGVkLgoKICAgbyAgVGhlIHJhbmdlIG9mIDYw LDAwMCB0byA5OSw5OTkgKHNpemUgNDAsMDAwKWlzIHJlc2VydmVkIGZvcgogICAgICBleHBlcmlt ZW50YWwgWUFORyBtb2R1bGVzLiAgVGhpcyByYW5nZSBNVVNUIE5PVCBiZSB1c2VkIGluCiAgICAg IG9wZXJhdGlvbmFsIGRlcGxveW1lbnRzIHNpbmNlIHRoZXNlIFNJRHMgYXJlIG5vdCBnbG9iYWxs eSB1bmlxdWUKICAgICAgd2hpY2ggbGltaXQgdGhlaXIgaW50ZXJvcGVyYWJpbGl0eS4gIFRoZSBJ QU5BIHBvbGljeSBmb3IgdGhpcwogICAgICByYW5nZSBpcyAiRXhwZXJpbWVudGFsIHVzZSIgW1JG QzgxMjZdLgoKCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAy MDIwICAgICAgICAgICAgICAgIFtQYWdlIDEzXQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBT Y2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVicnVhcnkgMjAyMAoKCiAgIG8gIFRo ZSByYW5nZSBvZiAxMDAsMDAwIHRvIDk5OSw5OTkgKHNpemUgOTAwLDAwMCkgaXMgIlJlc2VydmVk IiBhcwogICAgICBkZWZpbmVkIGluIFtSRkM4MTI2XS4KCiAgICstLS0tLS0tLS0tLS0tKy0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgRW50cnkgUG9pbnQgfCBTaXplICAgIHwgSUFO QSBwb2xpY3kgICAgICB8CiAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0rCiAgIHwgMCAgICAgICAgICAgfCAxLDAwMCAgIHwgUmVzZXJ2ZWQgICAgICAgICB8CiAg IHwgMSwwMDAgICAgICAgfCA1OSwwMDAgIHwgRXhwZXJ0IFJldmlldyAgICB8CiAgIHwgNjAsMDAw ICAgICAgfCA0MCwwMDAgIHwgRXhwZXJpbWVudGFsIHVzZSB8CiAgIHwgMTAwLDAwMCAgICAgfCA5 MDAsMDAwIHwgUmVzZXJ2ZWQgICAgICAgICB8CiAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0rCgo2LjMuMy4gIEluaXRpYWwgY29udGVudHMgb2YgdGhlIHJlZ2lz dHJ5CgogICBJbml0aWFsIGVudHJpZXMgaW4gdGhpcyByZWdpc3RyeSBhcmUgYXMgZm9sbG93czoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKVmVpbGxldHRlLCBldCBhbC4gICAg ICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICBG ZWJydWFyeSAyMDIwCgoKICAgKy0tLS0tKy0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgRW50IHwgU2l6IHwgTW9kdWxlIG5h bWUgICAgICAgICAgICAgIHwgRG9jdW1lbnQgcmVmZXJlbmNlICAgICAgICAgfAogICB8IHJ5ICB8 IGUgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgfCBQb2kgfCAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgIHwgbnQgIHwgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICArLS0tLS0rLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAg fCAxMDAgfCAxMDAgfCBpZXRmLWNvbWkgICAgICAgICAgICAgICAgfCBbSS1ELmlldGYtY29yZS1j b21pXSAgICAgICB8CiAgIHwgMCAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDExMCB8IDUwICB8IGlldGYteWFuZy10 eXBlcyAgICAgICAgICB8IFtSRkM2OTkxXSAgICAgICAgICAgICAgICAgIHwKICAgfCAwICAgfCAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgIHwgMTE1IHwgNTAgIHwgaWV0Zi1pbmV0LXR5cGVzICAgICAgICAgIHwgW1JGQzY5OTFd ICAgICAgICAgICAgICAgICAgfAogICB8IDAgICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAxMjAgfCA1MCAgfCBpYW5h LWNyeXB0LWhhc2ggICAgICAgICAgfCBbUkZDNzMxN10gICAgICAgICAgICAgICAgICB8CiAgIHwg MCAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICB8IDEyNSB8IDUwICB8IGlldGYtbmV0Y29uZi1hY20gICAgICAgICB8IFtS RkM4MzQxXSAgICAgICAgICAgICAgICAgIHwKICAgfCAwICAgfCAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMTMwIHwgNTAg IHwgaWV0Zi1zaWQtZmlsZSAgICAgICAgICAgIHwgUkZDWFhYWCAgICAgICAgICAgICAgICAgICAg fAogICB8IDAgICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgfCAxNTAgfCAxMDAgfCBpZXRmLWludGVyZmFjZXMgICAgICAg ICAgfCBbUkZDODM0M10gICAgICAgICAgICAgICAgICB8CiAgIHwgMCAgIHwgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDE2 MCB8IDEwMCB8IGlldGYtaXAgICAgICAgICAgICAgICAgICB8IFtSRkM4MzQ0XSAgICAgICAgICAg ICAgICAgIHwKICAgfCAwICAgfCAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMTcwIHwgMTAwIHwgaWV0Zi1zeXN0ZW0gICAg ICAgICAgICAgIHwgW1JGQzczMTddICAgICAgICAgICAgICAgICAgfAogICB8IDAgICB8ICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgfCAxODAgfCA0MDAgfCBpYW5hLWlmLXR5cGUgICAgICAgICAgICAgfCBbUkZDNzIyNF0gICAg ICAgICAgICAgICAgICB8CiAgIHwgMCAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDI0MCB8IDUwICB8IGlldGYtdm91 Y2hlciAgICAgICAgICAgICB8IFtSRkM4MzY2XSAgICAgICAgICAgICAgICAgIHwKICAgfCAwICAg fCAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgIHwgMjQ1IHwgNTAgIHwgaWV0Zi1jb25zdHJhaW5lZC12b3VjaGVyIHwgW0ktRC5p ZXRmLWFuaW1hLWNvbnN0cmFpbmUgfAogICB8IDAgICB8ICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICB8IGQtdm91Y2hlcl0gICAgICAgICAgICAgICAgIHwKICAgfCAyNTAgfCA1MCAgfCBp ZXRmLWNvbnN0cmFpbmVkLSAgICAgICAgfCBbSS1ELmlldGYtYW5pbWEtY29uc3RyYWluZSB8CiAg IHwgMCAgIHwgICAgIHwgdm91Y2hlci1yZXF1ZXN0ICAgICAgICAgIHwgZC12b3VjaGVyXSAgICAg ICAgICAgICAgICAgfAogICArLS0tLS0rLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgIC8vIFJGQyBFZC46IHJlcGxhY2UgWFhY WCB3aXRoIFJGQyBudW1iZXIgYXNzaWduZWQgdG8gdGhpcyBkcmFmdC4KCiAgIEZvciBhbGxvY2F0 aW9uLCBSRkMgcHVibGljYXRpb24gb2YgdGhlIFlBTkcgbW9kdWxlIGlzIHJlcXVpcmVkIGFzIHBl cgogICBbUkZDODEyNl0uICBUaGUgWUFORyBtb2R1bGUgbXVzdCBiZSByZWdpc3RlcmVkIGluIHRo ZSAiWUFORyBtb2R1bGUKICAgTmFtZSIgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBydWxlcyBz cGVjaWZpZWQgaW4gc2VjdGlvbiAxNCBvZgogICBbUkZDNjAyMF0uCgo2LjQuICBDcmVhdGUgbmV3 IElBTkEgUmVnaXN0cnk6ICJJRVRGIFNJRCBSZWdpc3RyeSIKCiAgIFRoZSBuYW1lIG9mIHRoaXMg cmVnaXN0cnkgaXMgIklFVEYgU0lEIFJlZ2lzdHJ5Ii4gIFRoaXMgcmVnaXN0cnkgaXMKICAgdXNl ZCB0byByZWNvcmQgdGhlIGFsbG9jYXRpb24gb2YgU0lEcyBmb3IgaW5kaXZpZHVhbCBZQU5HIG1v ZHVsZQogICBpdGVtcy4KCgoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1 c3QgOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAg IFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgo2 LjQuMS4gIFN0cnVjdHVyZQoKICAgRWFjaCBlbnRyeSBpbiB0aGlzIHJlZ2lzdHJ5IG11c3QgaW5j bHVkZToKCiAgIG8gIFRoZSBZQU5HIG1vZHVsZSBuYW1lLiAgVGhpcyBtb2R1bGUgbmFtZSBtdXN0 IGJlIHByZXNlbnQgaW4gdGhlCiAgICAgICJOYW1lIiBjb2x1bW4gb2YgdGhlICJZQU5HIE1vZHVs ZSBOYW1lcyIgcmVnaXN0cnkuCgogICBvICBBIGxpbmsgdG8gdGhlIGFzc29jaWF0ZWQgIi55YW5n IiBmaWxlLiAgVGhpcyBmaWxlIGxpbmsgbXVzdCBiZQogICAgICBwcmVzZW50IGluIHRoZSAiRmls ZSIgY29sdW1uIG9mIHRoZSAiWUFORyBNb2R1bGUgTmFtZXMiIHJlZ2lzdHJ5LgoKICAgbyAgVGhl IGxpbmsgdG8gdGhlICIuc2lkIiBmaWxlIHdoaWNoIGRlZmluZXMgdGhlIGFsbG9jYXRpb24uICBU aGUKICAgICAgIi5zaWQiIGZpbGUgaXMgc3RvcmVkIGJ5IElBTkEuCgogICBvICBUaGUgbnVtYmVy IG9mIGFjdHVhbGx5IGFsbG9jYXRlZCBTSURzIGluIHRoZSAiLnNpZCIgZmlsZS4KCjYuNC4yLiAg QWxsb2NhdGlvbiBwb2xpY3kKCiAgIFRoZSBhbGxvY2F0aW9uIHBvbGljeSBpcyBFeHBlcnQgcmV2 aWV3LiAgVGhlIEV4cGVydCBNVVNUIGVuc3VyZSB0aGF0CiAgIHRoZSBmb2xsb3dpbmcgY29uZGl0 aW9ucyBhcmUgbWV0OgoKICAgbyAgVGhlICIuc2lkIiBmaWxlIGhhcyBhIHZhbGlkIHN0cnVjdHVy ZToKCiAgICAgICogIFRoZSAiLnNpZCIgZmlsZSBNVVNUIGJlIGEgdmFsaWQgSlNPTiBmaWxlIGZv bGxvd2luZyB0aGUKICAgICAgICAgc3RydWN0dXJlIG9mIHRoZSBtb2R1bGUgZGVmaW5lZCBpbiBS RkNYWFhYIChSRkMgRWQ6IHJlcGxhY2UgWFhYCiAgICAgICAgIHdpdGggUkZDIG51bWJlciBhc3Np Z25lZCB0byB0aGlzIGRyYWZ0KS4KCiAgIG8gIFRoZSAiLnNpZCIgZmlsZSBhbGxvY2F0ZXMgaW5k aXZpZHVhbCBTSURzIE9OTFkgaW4gdGhlIFNJRCBSYW5nZXMKICAgICAgZm9yIHRoaXMgWUFORyBt b2R1bGUgKGFzIGFsbG9jYXRlZCBpbiB0aGUgSUVURiBTSUQgUmFuZ2UKICAgICAgUmVnaXN0cnkp OgoKICAgICAgKiAgQWxsIFNJRHMgaW4gdGhpcyAiLnNpZCIgZmlsZSBNVVNUIGJlIHdpdGhpbiB0 aGUgcmFuZ2VzCiAgICAgICAgIGFsbG9jYXRlZCB0byB0aGlzIFlBTkcgbW9kdWxlIGluIHRoZSAi SUVURiBTSUQgUmFuZ2UgUmVnaXN0cnkiLgoKICAgbyAgSWYgYW5vdGhlciAiLnNpZCIgZmlsZSBo YXMgYWxyZWFkeSBhbGxvY2F0ZWQgU0lEcyBmb3IgdGhpcyBZQU5HCiAgICAgIG1vZHVsZSAoZS5n LiAgZm9yIG9sZGVyIG9yIG5ld2VyIHZlcnNpb25zIG9mIHRoZSBZQU5HIG1vZHVsZSksIHRoZQog ICAgICBZQU5HIGl0ZW1zIGFyZSBhc3NpZ25lZCB0aGUgc2FtZSBTSURzIGFzIGluIHRoZSBvdGhl ciAiLnNpZCIgZmlsZS4KCiAgIG8gIElmIHRoZXJlIGlzIGFuIG9sZGVyIHZlcnNpb24gb2YgdGhl ICIuc2lkIiBmaWxlLCBhbGwgYWxsb2NhdGVkCiAgICAgIFNJRHMgZnJvbSB0aGF0IHZlcnNpb24g YXJlIHN0aWxsIHByZXNlbnQgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZgogICAgICB0aGUgIi5z aWQiIGZpbGUuCgogICBvICBTSURzIG5ldmVyIGNoYW5nZS4KCjYuNC4zLiAgUmVjdXJzaXZlIEFs bG9jYXRpb24gb2YgU0lEIFJhbmdlIGF0IERvY3VtZW50IEFkb3B0aW9uCgogICBEdWUgdG8gdGhl IGRpZmZpY3VsdHkgaW4gY2hhbmdpbmcgU0lEIHZhbHVlcyBkdXJpbmcgSUVURiBkb2N1bWVudAog ICBwcm9jZXNzaW5nLCBpdCBpcyBleHBlY3RlZCB0aGF0IG1vc3QgZG9jdW1lbnRzIHdpbGwgYXNr IGZvciBTSUQKICAgYWxsb2NhdGlvbnMgdXNpbmcgRWFybHkgQWxsb2NhdGlvbnMgW1JGQzcxMjBd LiAgVGhlIGRldGFpbHMgb2YgdGhlCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICBFeHBpcmVz IEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDE2XQoMCkludGVybmV0LURyYWZ0 ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVicnVhcnkgMjAy MAoKCiAgIEVhcmx5IEFsbG9jYXRpb24gc2hvdWxkIGJlIGluY2x1ZGVkIGluIGFueSBXb3JraW5n IEdyb3VwIEFkb3B0aW9uCiAgIGNhbGwuICBQcmlvciB0byBXb3JraW5nIEdyb3VwIEFkb3B0aW9u LCBhbiBpbnRlcm5ldCBkcmFmdCBhdXRob3JzIGNhbgogICB1c2UgdGhlIGV4cGVyaW1lbnRhbCBT SUQgcmFuZ2UgKGFzIHBlciBTZWN0aW9uIDYuMy4yKSBmb3IgdGhlaXIgU0lEcwogICBhbGxvY2F0 aW9ucyBvciBvdGhlciB2YWx1ZXMgdGhhdCBkbyBub3QgY3JlYXRlIGFtYmlndWl0eSB3aXRoIG90 aGVyCiAgIFNJRCB1c2VzIChmb3IgZXhhbXBsZSB0aGV5IGNhbiB1c2UgYSByYW5nZSB0aGF0IGNv bWVzIGZyb20gYSBub24tSUFOQQogICBtYW5hZ2VkICJTSUQgTWVnYS1SYW5nZSIgcmVnaXN0cnkp LgoKICAgQWZ0ZXIgV29ya2luZyBHcm91cCBBZG9wdGlvbiwgYW55IG1vZGlmaWNhdGlvbiBvZiBh ICIuc2lkIiBmaWxlIGlzCiAgIGV4cGVjdGVkIHRvIGJlIGRpc2N1c3NlZCBvbiB0aGUgbWFpbGlu ZyBsaXN0IG9mIHRoZSBhcHByb3ByaWF0ZQogICBXb3JraW5nIEdyb3Vwcy4gIFNwZWNpZmljIGF0 dGVudGlvbiBzaG91bGQgYmUgcGFpZCB0byBpbXBsZW1lbnRlcnMnCiAgIG9waW5pb24gYWZ0ZXIg V29ya2luZyBHcm91cCBMYXN0IENhbGwgaWYgYSBTSUQgdmFsdWUgaXMgdG8gY2hhbmdlIGl0cwog ICBtZWFuaW5nLiAgSW4gYWxsIGNhc2VzLCBhICIuc2lkIiBmaWxlIGFuZCB0aGUgU0lEcyBhc3Nv Y2lhdGVkIHdpdGggaXQKICAgYXJlIHN1YmplY3QgdG8gY2hhbmdlIGJlZm9yZSB0aGUgcHVibGlj YXRpb24gb2YgYW4gaW50ZXJuZXQgZHJhZnQgYXMKICAgYW4gUkZDLgoKICAgRHVyaW5nIHRoZSBl YXJseSB1c2Ugb2YgU0lEcywgbWFueSBleGlzdGluZywgcHJldmlvdXNseSBwdWJsaXNoZWQKICAg WUFORyBtb2R1bGVzIHdpbGwgbm90IGhhdmUgU0lEIGFsbG9jYXRpb25zLiAgRm9yIGFuIGFsbG9j YXRpb24gdG8gYmUKICAgdXNlZnVsIHRoZSBpbmNsdWRlZCBZQU5HIG1vZHVsZXMgbWF5IGFsc28g bmVlZCB0byBoYXZlIFNJRAogICBhbGxvY2F0aW9ucyBtYWRlLgoKICAgVGhlIEV4cGVydCBSZXZp ZXdlciB3aG8gcGVyZm9ybXMgdGhlIChFYXJseSkgQWxsb2NhdGlvbiBhbmFseXNpcyB3aWxsCiAg IG5lZWQgdG8gZ28gdGhyb3VnaCB0aGUgbGlzdCBvZiBpbmNsdWRlZCBZQU5HIG1vZHVsZXMgYW5k IHBlcmZvcm0gU0lECiAgIGFsbG9jYXRpb25zIGZvciB0aG9zZSBtb2R1bGVzIGFzIHdlbGwuCgog ICBvICBJZiB0aGUgZG9jdW1lbnQgaXMgYSBwdWJsaXNoZWQgUkZDLCB0aGVuIHRoZSBhbGxvY2F0 aW9uIG9mIFNJRHMKICAgICAgZm9yIGl0cyByZWZlcmVuY2VkIFlBTkcgbW9kdWxlcyBpcyBwZXJt YW5lbnQuICBUaGUgRXhwZXJ0IFJldmlld2VyCiAgICAgIHByb3ZpZGVzIHRoZSBnZW5lcmF0ZWQg U0lEIGZpbGUgdG8gSUFOQSBmb3IgcmVnaXN0cmF0aW9uLiAgVGhpcwogICAgICBwcm9jZXNzIG1h eSBiZSB0aW1lIGNvbnN1bWluZyBkdXJpbmcgYSBib290c3RyYXAgcGVyaW9kICh0aGVyZSBhcmUK ICAgICAgb3ZlciAxMDAgWUFORyBtb2R1bGVzIHRvIGRhdGUsIG5vbmUgb2Ygd2hpY2ggaGF2ZSBT SUQKICAgICAgYWxsb2NhdGlvbnMpLCBidXQgc2hvdWxkIHF1aWV0IGRvd24gb25jZSBuZWVkZWQg ZW50cmllcyBhcmUKICAgICAgYWxsb2NhdGVkLgoKICAgbyAgSWYgdGhlIGRvY3VtZW50IGlzIGFu IHVucHJvY2Vzc2VkIEludGVybmV0LURyYWZ0IGFkb3B0ZWQgaW4gYSBXRywKICAgICAgdGhlbiBh biBFYXJseSBBbGxvY2F0aW9uIGlzIHBlcmZvcm1lZCBmb3IgdGhpcyBkb2N1bWVudCBhcyB3ZWxs LgogICAgICBFYXJseSBBbGxvY2F0aW9ucyByZXF1aXJlIGFwcHJvdmFsIGJ5IGFuIElFU0cgQXJl YSBEaXJlY3Rvci4gIEFuCiAgICAgIGVhcmx5IGFsbG9jYXRpb24gd2hpY2ggcmVxdWlyZXMgYWRk aXRpb25hbCBhbGxvY2F0aW9ucyB3aWxsIGxpc3QKICAgICAgdGhlIG90aGVyIGFsbG9jYXRpb25z IGluIGl0J3MgZGVzY3JpcHRpb24sIGFuZCB3aWxsIGJlIGNyb3NzLQogICAgICBwb3N0ZWQgdG8g dGhlIGFueSBvdGhlciB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdHMuCgogICBvICBBIFlBTkcg bW9kdWxlIHdoaWNoIHJlZmVyZW5jZXMgYSBtb2R1bGUgaW4gYW4gZG9jdW1lbnQgd2hpY2ggaGFz CiAgICAgIG5vdCB5ZXQgYmVlbiBhZG9wdGVkIGJ5IGFueSB3b3JraW5nIGdyb3VwIHdpbGwgYmUg dW5hYmxlIHRvCiAgICAgIHBlcmZvcm0gYW4gRWFybHkgQWxsb2NhdGlvbiBmb3IgdGhhdCBvdGhl ciBkb2N1bWVudCB1bnRpbCBpdCBpcwogICAgICBhZG9wdGVkIGJ5IGEgd29ya2luZyBncm91cC4g IEFzIGRlc2NyaWJlZCBpbiBbUkZDNzEyMF0sIGFuIEFECiAgICAgIFNwb25zb3JlZCBkb2N1bWVu dCBhY3RzIGFzIGlmIGl0IGhhZCBhIHdvcmtpbmcgZ3JvdXAuICBUaGUKICAgICAgYXBwcm92aW5n IEFEIG1heSBhbHNvIGV4ZW1wdCBhIGRvY3VtZW50IGZyb20gdGhpcyBwb2xpY3kgYnkKICAgICAg YWdyZWVpbmcgdG8gQUQgU3BvbnNvciB0aGUgZG9jdW1lbnQuCgoKCgoKVmVpbGxldHRlLCBldCBh bC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMTdd CgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkg ICAgICBGZWJydWFyeSAyMDIwCgoKICAgQ3JpdGljYWxseSwgdGhlIG9yaWdpbmFsIGRvY3VtZW50 IHNob3VsZCBuZXZlciBnZXQgdGhyb3VnaCB0aGUgSUVURgogICBwcm9jZXNzIGFuZCB0aGVuIGJl IHN1cnByaXNlZCB0byBiZSByZWZlcmVuY2luZyBhIGRvY3VtZW50IHdob3NlCiAgIHByb2dyZXNz IGlzIG5vdCBjZXJ0YWluLgoKICAgQSBwcmV2aW91c2x5IFNJRC1hbGxvY2F0ZWQgWUFORyBtb2R1 bGUgd2hpY2ggY2hhbmdlcyBpdHMgcmVmZXJlbmNlcwogICB0byBpbmNsdWRlIGEgWUFORyBtb2R1 bGUgZm9yIHdoaWNoIHRoZXJlIGlzIG5vIFNJRCBhbGxvY2F0aW9uIG5lZWRzCiAgIHRvIHJlcGVh dCB0aGUgRWFybHkgQWxsb2NhdGlvbiBwcm9jZXNzLgoKICAgRWFybHkgQWxsb2NhdGlvbnMgYXJl IG1hZGUgd2l0aCBhIG9uZS15ZWFyIHBlcmlvZCwgYWZ0ZXIgd2hpY2ggdGhleQogICBhcmUgZXhw aXJlZC4gIFtSRkM3MTIwXSBpbmRpY2F0ZXMgdGhhdCBhdCBtb3N0IG9uZSByZW5ld2FsIG1heSBi ZQogICBtYWRlLiAgRm9yIHRoZSBTSUQgYWxsb2NhdGlvbiBhIGZhciBtb3JlIGxlbmllbnQgc3Rh bmNlIGlzIGRlc2lyZWQuCgogICAxLiAgQW4gZXh0ZW5zaW9uIG9mIGEgcmVmZXJlbmNpbmcgZG9j dW1lbnRzIEVhcmx5IEFsbG9jYXRpb24gc2hvdWxkCiAgICAgICB1cGRhdGUgYW55IHJlZmVyZW5j ZWQgRWFybHkgQWxsb2NhdGlvbnMgdG8gZXhwaXJlIG5vIHNvb25lciB0aGFuCiAgICAgICB0aGUg cmVmZXJlbmNpbmcgZG9jdW1lbnQuCgogICAyLiAgVGhlIFtSRkM3MTIwXSBtZWNoYW5pc20gYWxs b3dzIHRoZSBJRVNHIHRvIHByb3ZpZGUgYSBzZWNvbmQKICAgICAgIHJlbmV3YWwsIGFuZCBzdWNo IGFuIGV2ZW50IG1heSBwcm9tcHQgc29tZSB0aG91Z2h0IGFib3V0IGhvdyB0aGUKICAgICAgIGNv bGxlY3Rpb24gb2YgZG9jdW1lbnRzIGFyZSBiZWluZyBwcm9jZXNzZWQuCgogICBUaGlzIGlzIGRy aXZlbiBieSB0aGUgdmVyeSBnZW5lcm91cyBzaXplIG9mIHRoZSBTSUQgc3BhY2UgYW5kIHRoZQog ICBvZnRlbiBjb21wbGV4IGFuZCBkZWVwIGRlcGVuZGVuY2llcyBvZiBZQU5HIG1vZHVsZXMuICBP ZnRlbiBhIGNvcmUKICAgbW9kdWxlIHdpdGggbWFueSBkZXBlbmRlbmNpZXMgd2lsbCB1bmRlcmdv IGV4dGVuc2l2ZSByZXZpZXcsIGRlbGF5aW5nCiAgIHRoZSBwdWJsaWNhdGlvbiBvZiBvdGhlciBk b2N1bWVudHMuCgogICBbUkZDNzEyMF0gYWxzbyBzYXlzCgogICBOb3RlIHRoYXQgaWYgYSBkb2N1 bWVudCBpcyBzdWJtaXR0ZWQgZm9yIHJldmlldyB0byB0aGUgSUVTRyBhbmQgYXQKICAgdGhlIHRp bWUgb2Ygc3VibWlzc2lvbiBzb21lIGVhcmx5IGFsbG9jYXRpb25zIGFyZSB2YWxpZCAobm90CiAg IGV4cGlyZWQpLCB0aGVzZSBhbGxvY2F0aW9ucyBzaG91bGQgbm90IGJlIGV4cGlyZWQgd2hpbGUg dGhlIGRvY3VtZW50CiAgIGlzIHVuZGVyIElFU0cgY29uc2lkZXJhdGlvbiBvciB3YWl0aW5nIGlu IHRoZSBSRkMgRWRpdG9yJ3MgcXVldWUKICAgYWZ0ZXIgYXBwcm92YWwgYnkgdGhlIElFU0cuCgo2 LjQuNC4gIEluaXRpYWwgY29udGVudHMgb2YgdGhlIHJlZ2lzdHJ5CgogICBOb25lLgoKNy4gIEFj a25vd2xlZGdtZW50cwoKICAgVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayBBbmR5IEJp ZXJtYW4sIENhcnN0ZW4gQm9ybWFubiwKICAgTWljaGFlbCBSaWNoYXJkc29uLCBBYmhpbmF2IFNv bWFyYWp1LCBQZXRlciB2YW4gZGVyIFN0b2ssIExhdXJlbnQKICAgVG91dGFpbiBhbmQgUmFuZHkg VHVybmVyIGZvciB0aGVpciBoZWxwIGR1cmluZyB0aGUgZGV2ZWxvcG1lbnQgb2YKICAgdGhpcyBk b2N1bWVudCBhbmQgdGhlaXIgdXNlZnVsIGNvbW1lbnRzIGR1cmluZyB0aGUgcmV2aWV3IHByb2Nl c3MuCgoKCgoKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIw MjAgICAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNj aGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoKOC4gIFJlZmVy ZW5jZXMKCjguMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIs IFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAg IFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksCiAgICAgICAgICAgICAgRE9J IDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOT4uCgogICBbUkZDNzEyMF0gIENvdHRvbiwgTS4s ICJFYXJseSBJQU5BIEFsbG9jYXRpb24gb2YgU3RhbmRhcmRzIFRyYWNrIENvZGUKICAgICAgICAg ICAgICBQb2ludHMiLCBCQ1AgMTAwLCBSRkMgNzEyMCwgRE9JIDEwLjE3NDg3L1JGQzcxMjAsIEph bnVhcnkKICAgICAgICAgICAgICAyMDE0LCA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmM3MTIwPi4KCiAgIFtSRkM3OTUwXSAgQmpvcmtsdW5kLCBNLiwgRWQuLCAiVGhlIFlBTkcg MS4xIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UiLAogICAgICAgICAgICAgIFJGQyA3OTUwLCBET0kg MTAuMTc0ODcvUkZDNzk1MCwgQXVndXN0IDIwMTYsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzk1MD4uCgogICBbUkZDNzk1MV0gIExob3RrYSwgTC4s ICJKU09OIEVuY29kaW5nIG9mIERhdGEgTW9kZWxlZCB3aXRoIFlBTkciLAogICAgICAgICAgICAg IFJGQyA3OTUxLCBET0kgMTAuMTc0ODcvUkZDNzk1MSwgQXVndXN0IDIwMTYsCiAgICAgICAgICAg ICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzk1MT4uCgogICBbUkZDODE3 NF0gIExlaWJhLCBCLiwgIkFtYmlndWl0eSBvZiBVcHBlcmNhc2UgdnMgTG93ZXJjYXNlIGluIFJG QwogICAgICAgICAgICAgIDIxMTkgS2V5IFdvcmRzIiwgQkNQIDE0LCBSRkMgODE3NCwgRE9JIDEw LjE3NDg3L1JGQzgxNzQsCiAgICAgICAgICAgICAgTWF5IDIwMTcsIDxodHRwczovL3d3dy5yZmMt ZWRpdG9yLm9yZy9pbmZvL3JmYzgxNzQ+LgoKOC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoK ICAgW0ktRC5pZXRmLWFuaW1hLWNvbnN0cmFpbmVkLXZvdWNoZXJdCiAgICAgICAgICAgICAgUmlj aGFyZHNvbiwgTS4sIFN0b2ssIFAuLCBhbmQgUC4gS2FtcGFuYWtpcywgIkNvbnN0cmFpbmVkCiAg ICAgICAgICAgICAgVm91Y2hlciBBcnRpZmFjdHMgZm9yIEJvb3RzdHJhcHBpbmcgUHJvdG9jb2xz IiwgZHJhZnQtCiAgICAgICAgICAgICAgaWV0Zi1hbmltYS1jb25zdHJhaW5lZC12b3VjaGVyLTA3 ICh3b3JrIGluIHByb2dyZXNzKSwKICAgICAgICAgICAgICBKYW51YXJ5IDIwMjAuCgogICBbSS1E LmlldGYtY29yZS1jb21pXQogICAgICAgICAgICAgIFZlaWxsZXR0ZSwgTS4sIFN0b2ssIFAuLCBQ ZWxvdiwgQS4sIEJpZXJtYW4sIEEuLCBhbmQgSS4KICAgICAgICAgICAgICBQZXRyb3YsICJDb0FQ IE1hbmFnZW1lbnQgSW50ZXJmYWNlIiwgZHJhZnQtaWV0Zi1jb3JlLQogICAgICAgICAgICAgIGNv bWktMDggKHdvcmsgaW4gcHJvZ3Jlc3MpLCBTZXB0ZW1iZXIgMjAxOS4KCiAgIFtSRkM2MDIwXSAg QmpvcmtsdW5kLCBNLiwgRWQuLCAiWUFORyAtIEEgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSBmb3IK ICAgICAgICAgICAgICB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIFByb3RvY29sIChORVRDT05G KSIsIFJGQyA2MDIwLAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM2MDIwLCBPY3RvYmVy IDIwMTAsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZj NjAyMD4uCgogICBbUkZDNjI0MV0gIEVubnMsIFIuLCBFZC4sIEJqb3JrbHVuZCwgTS4sIEVkLiwg U2Nob2Vud2FlbGRlciwgSi4sIEVkLiwKICAgICAgICAgICAgICBhbmQgQS4gQmllcm1hbiwgRWQu LCAiTmV0d29yayBDb25maWd1cmF0aW9uIFByb3RvY29sCiAgICAgICAgICAgICAgKE5FVENPTkYp IiwgUkZDIDYyNDEsIERPSSAxMC4xNzQ4Ny9SRkM2MjQxLCBKdW5lIDIwMTEsCiAgICAgICAgICAg ICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjI0MT4uCgoKCgpWZWlsbGV0 dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICBb UGFnZSAxOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmll ciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICBbUkZDNjk5MV0gIFNjaG9lbndhZWxkZXIs IEouLCBFZC4sICJDb21tb24gWUFORyBEYXRhIFR5cGVzIiwKICAgICAgICAgICAgICBSRkMgNjk5 MSwgRE9JIDEwLjE3NDg3L1JGQzY5OTEsIEp1bHkgMjAxMywKICAgICAgICAgICAgICA8aHR0cHM6 Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM2OTkxPi4KCiAgIFtSRkM3MjI0XSAgQmpvcmts dW5kLCBNLiwgIklBTkEgSW50ZXJmYWNlIFR5cGUgWUFORyBNb2R1bGUiLAogICAgICAgICAgICAg IFJGQyA3MjI0LCBET0kgMTAuMTc0ODcvUkZDNzIyNCwgTWF5IDIwMTQsCiAgICAgICAgICAgICAg PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzIyND4uCgogICBbUkZDNzMxN10g IEJpZXJtYW4sIEEuIGFuZCBNLiBCam9ya2x1bmQsICJBIFlBTkcgRGF0YSBNb2RlbCBmb3IKICAg ICAgICAgICAgICBTeXN0ZW0gTWFuYWdlbWVudCIsIFJGQyA3MzE3LCBET0kgMTAuMTc0ODcvUkZD NzMxNywgQXVndXN0CiAgICAgICAgICAgICAgMjAxNCwgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2luZm8vcmZjNzMxNz4uCgogICBbUkZDODA0MF0gIEJpZXJtYW4sIEEuLCBCam9ya2x1bmQs IE0uLCBhbmQgSy4gV2F0c2VuLCAiUkVTVENPTkYKICAgICAgICAgICAgICBQcm90b2NvbCIsIFJG QyA4MDQwLCBET0kgMTAuMTc0ODcvUkZDODA0MCwgSmFudWFyeSAyMDE3LAogICAgICAgICAgICAg IDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgwNDA+LgoKICAgW1JGQzgxMjZd ICBDb3R0b24sIE0uLCBMZWliYSwgQi4sIGFuZCBULiBOYXJ0ZW4sICJHdWlkZWxpbmVzIGZvcgog ICAgICAgICAgICAgIFdyaXRpbmcgYW4gSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJG Q3MiLCBCQ1AgMjYsCiAgICAgICAgICAgICAgUkZDIDgxMjYsIERPSSAxMC4xNzQ4Ny9SRkM4MTI2 LCBKdW5lIDIwMTcsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2lu Zm8vcmZjODEyNj4uCgogICBbUkZDODM0MV0gIEJpZXJtYW4sIEEuIGFuZCBNLiBCam9ya2x1bmQs ICJOZXR3b3JrIENvbmZpZ3VyYXRpb24KICAgICAgICAgICAgICBBY2Nlc3MgQ29udHJvbCBNb2Rl bCIsIFNURCA5MSwgUkZDIDgzNDEsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzgzNDEs IE1hcmNoIDIwMTgsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2lu Zm8vcmZjODM0MT4uCgogICBbUkZDODM0M10gIEJqb3JrbHVuZCwgTS4sICJBIFlBTkcgRGF0YSBN b2RlbCBmb3IgSW50ZXJmYWNlCiAgICAgICAgICAgICAgTWFuYWdlbWVudCIsIFJGQyA4MzQzLCBE T0kgMTAuMTc0ODcvUkZDODM0MywgTWFyY2ggMjAxOCwKICAgICAgICAgICAgICA8aHR0cHM6Ly93 d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4MzQzPi4KCiAgIFtSRkM4MzQ0XSAgQmpvcmtsdW5k LCBNLiwgIkEgWUFORyBEYXRhIE1vZGVsIGZvciBJUCBNYW5hZ2VtZW50IiwKICAgICAgICAgICAg ICBSRkMgODM0NCwgRE9JIDEwLjE3NDg3L1JGQzgzNDQsIE1hcmNoIDIwMTgsCiAgICAgICAgICAg ICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODM0ND4uCgogICBbUkZDODM2 Nl0gIFdhdHNlbiwgSy4sIFJpY2hhcmRzb24sIE0uLCBQcml0aWtpbiwgTS4sIGFuZCBULiBFY2tl cnQsCiAgICAgICAgICAgICAgIkEgVm91Y2hlciBBcnRpZmFjdCBmb3IgQm9vdHN0cmFwcGluZyBQ cm90b2NvbHMiLAogICAgICAgICAgICAgIFJGQyA4MzY2LCBET0kgMTAuMTc0ODcvUkZDODM2Niwg TWF5IDIwMTgsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v cmZjODM2Nj4uCgpBcHBlbmRpeCBBLiAgIi5zaWQiIGZpbGUgZXhhbXBsZQoKICAgVGhlIGZvbGxv d2luZyAiLnNpZCIgZmlsZSAoaWV0Zi1zeXN0ZW1AMjAxNC0wOC0wNi5zaWQpIGhhdmUgYmVlbgog ICBnZW5lcmF0ZWQgdXNpbmcgdGhlIGZvbGxvd2luZyB5YW5nIG1vZHVsZXM6CgogICBvICBpZXRm LXN5c3RlbUAyMDE0LTA4LTA2LnlhbmcKCiAgIG8gIGlldGYteWFuZy10eXBlc0AyMDEzLTA3LTE1 LnlhbmcKCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIw ICAgICAgICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hl bWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVicnVhcnkgMjAyMAoKCiAgIG8gIGlldGYt aW5ldC10eXBlc0AyMDEzLTA3LTE1LnlhbmcKCiAgIG8gIGlldGYtbmV0Y29uZi1hY21AMjAxMi0w Mi0yMi55YW5nCgogICBvICBpYW5hLWNyeXB0LWhhc2hAMjAxNC0wNC0wNC55YW5nCgogICB7CiAg ICAgImFzc2lnbm1lbnQtcmFuZ2VzIjogWwogICAgICAgewogICAgICAgICAiZW50cnktcG9pbnQi OiAxNzAwLAogICAgICAgICAic2l6ZSI6IDEwMAogICAgICAgfQogICAgIF0sCiAgICAgIm1vZHVs ZS1uYW1lIjogImlldGYtc3lzdGVtIiwKICAgICAibW9kdWxlLXJldmlzaW9uIjogIjIwMTQtMDgt MDYiLAogICAgICJpdGVtcyI6IFsKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJtb2R1 bGUiLAogICAgICAgICAiaWRlbnRpZmllciI6ICJpZXRmLXN5c3RlbSIsCiAgICAgICAgICJzaWQi OiAxNzAwCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImlkZW50aXR5 IiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiYXV0aGVudGljYXRpb24tbWV0aG9kIiwKICAgICAg ICAgInNpZCI6IDE3MDEKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAi aWRlbnRpdHkiLAogICAgICAgICAiaWRlbnRpZmllciI6ICJsb2NhbC11c2VycyIsCiAgICAgICAg ICJzaWQiOiAxNzAyCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImlk ZW50aXR5IiwKICAgICAgICAgImlkZW50aWZpZXIiOiAicmFkaXVzIiwKICAgICAgICAgInNpZCI6 IDE3MDMKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiaWRlbnRpdHki LAogICAgICAgICAiaWRlbnRpZmllciI6ICJyYWRpdXMtYXV0aGVudGljYXRpb24tdHlwZSIsCiAg ICAgICAgICJzaWQiOiAxNzA0CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNl IjogImlkZW50aXR5IiwKICAgICAgICAgImlkZW50aWZpZXIiOiAicmFkaXVzLWNoYXAiLAogICAg ICAgICAic2lkIjogMTcwNQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6 ICJpZGVudGl0eSIsCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCA4 LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFO RyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVicnVhcnkgMjAyMAoKCiAgICAg ICAgICJpZGVudGlmaWVyIjogInJhZGl1cy1wYXAiLAogICAgICAgICAic2lkIjogMTcwNgogICAg ICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJmZWF0dXJlIiwKICAgICAgICAg ImlkZW50aWZpZXIiOiAiYXV0aGVudGljYXRpb24iLAogICAgICAgICAic2lkIjogMTcwNwogICAg ICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJmZWF0dXJlIiwKICAgICAgICAg ImlkZW50aWZpZXIiOiAiZG5zLXVkcC10Y3AtcG9ydCIsCiAgICAgICAgICJzaWQiOiAxNzA4CiAg ICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImZlYXR1cmUiLAogICAgICAg ICAiaWRlbnRpZmllciI6ICJsb2NhbC11c2VycyIsCiAgICAgICAgICJzaWQiOiAxNzA5CiAgICAg ICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImZlYXR1cmUiLAogICAgICAgICAi aWRlbnRpZmllciI6ICJudHAiLAogICAgICAgICAic2lkIjogMTcxMAogICAgICAgfSwKICAgICAg IHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJmZWF0dXJlIiwKICAgICAgICAgImlkZW50aWZpZXIi OiAibnRwLXVkcC1wb3J0IiwKICAgICAgICAgInNpZCI6IDE3MTEKICAgICAgIH0sCiAgICAgICB7 CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZmVhdHVyZSIsCiAgICAgICAgICJpZGVudGlmaWVyIjog InJhZGl1cyIsCiAgICAgICAgICJzaWQiOiAxNzEyCiAgICAgICB9LAogICAgICAgewogICAgICAg ICAibmFtZXNwYWNlIjogImZlYXR1cmUiLAogICAgICAgICAiaWRlbnRpZmllciI6ICJyYWRpdXMt YXV0aGVudGljYXRpb24iLAogICAgICAgICAic2lkIjogMTcxMwogICAgICAgfSwKICAgICAgIHsK ICAgICAgICAgIm5hbWVzcGFjZSI6ICJmZWF0dXJlIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAi dGltZXpvbmUtbmFtZSIsCiAgICAgICAgICJzaWQiOiAxNzE0CiAgICAgICB9LAogICAgICAgewog ICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0 Zi1zeXN0ZW06c2V0LWN1cnJlbnQtZGF0ZXRpbWUiLAogICAgICAgICAic2lkIjogMTcxNQogICAg ICAgfSwKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAg ICAgICAgICAgICAgICAgW1BhZ2UgMjJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVt YSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoKICAgICAgIHsKICAg ICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYt c3lzdGVtOnNldC1jdXJyZW50LWRhdGV0aW1lLwogICAgICAgICAgICAgICAgICAgICAgICBjdXJy ZW50LWRhdGV0aW1lIiwKICAgICAgICAgInNpZCI6IDE3MTYKICAgICAgIH0sCiAgICAgICB7CiAg ICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRm LXN5c3RlbTpzeXN0ZW0iLAogICAgICAgICAic2lkIjogMTcxNwogICAgICAgfSwKICAgICAgIHsK ICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2ll dGYtc3lzdGVtOnN5c3RlbS1yZXN0YXJ0IiwKICAgICAgICAgInNpZCI6IDE3MTgKICAgICAgIH0s CiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlm aWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0tc2h1dGRvd24iLAogICAgICAgICAic2lkIjogMTcx OQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAg ICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS1zdGF0ZSIsCiAgICAgICAgICJz aWQiOiAxNzIwCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEi LAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtLXN0YXRlL2Nsb2Nr IiwKICAgICAgICAgInNpZCI6IDE3MjEKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1l c3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0 ZW0tc3RhdGUvY2xvY2svYm9vdC1kYXRldGltZSIsCiAgICAgICAgICJzaWQiOiAxNzIyCiAgICAg ICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRl bnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtLXN0YXRlL2Nsb2NrLwogICAgICAgICAgICAg ICAgICAgICAgICBjdXJyZW50LWRhdGV0aW1lIiwKICAgICAgICAgInNpZCI6IDE3MjMKICAgICAg IH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVu dGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0tc3RhdGUvcGxhdGZvcm0iLAogICAgICAgICAi c2lkIjogMTcyNAogICAgICAgfSwKICAgICAgIHsKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAg IEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMjNdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICBGZWJy dWFyeSAyMDIwCgoKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50 aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS1zdGF0ZS9wbGF0Zm9ybS9tYWNoaW5lIiwKICAg ICAgICAgInNpZCI6IDE3MjUKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2Ui OiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0tc3Rh dGUvcGxhdGZvcm0vb3MtbmFtZSIsCiAgICAgICAgICJzaWQiOiAxNzI2CiAgICAgICB9LAogICAg ICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6 ICIvaWV0Zi1zeXN0ZW06c3lzdGVtLXN0YXRlL3BsYXRmb3JtL29zLXJlbGVhc2UiLAogICAgICAg ICAic2lkIjogMTcyNwogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJk YXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS1zdGF0ZS9w bGF0Zm9ybS9vcy12ZXJzaW9uIiwKICAgICAgICAgInNpZCI6IDE3MjgKICAgICAgIH0sCiAgICAg ICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjog Ii9pZXRmLXN5c3RlbTpzeXN0ZW0vYXV0aGVudGljYXRpb24iLAogICAgICAgICAic2lkIjogMTcy OQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAg ICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9hdXRoZW50aWNhdGlvbi91c2Vy IiwKICAgICAgICAgInNpZCI6IDE3MzAKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1l c3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0 ZW0vYXV0aGVudGljYXRpb24vCiAgICAgICAgICAgICAgICAgICAgICAgIHVzZXItYXV0aGVudGlj YXRpb24tb3JkZXIiLAogICAgICAgICAic2lkIjogMTczMQogICAgICAgfSwKICAgICAgIHsKICAg ICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYt c3lzdGVtOnN5c3RlbS9hdXRoZW50aWNhdGlvbi91c2VyLwogICAgICAgICAgICAgICAgICAgICAg ICBhdXRob3JpemVkLWtleSIsCiAgICAgICAgICJzaWQiOiAxNzMyCiAgICAgICB9LAogICAgICAg ewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIv aWV0Zi1zeXN0ZW06c3lzdGVtL2F1dGhlbnRpY2F0aW9uL3VzZXIvCiAgICAgICAgICAgICAgICAg ICAgICAgIGF1dGhvcml6ZWQta2V5L2FsZ29yaXRobSIsCiAgICAgICAgICJzaWQiOiAxNzMzCiAg ICAgICB9LAogICAgICAgewoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1 c3QgOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAyNF0KDApJbnRlcm5ldC1EcmFmdCAgICAg IFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgog ICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0 Zi1zeXN0ZW06c3lzdGVtL2F1dGhlbnRpY2F0aW9uL3VzZXIvCiAgICAgICAgICAgICAgICAgICAg ICAgIGF1dGhvcml6ZWQta2V5L2tleS1kYXRhIiwKICAgICAgICAgInNpZCI6IDE3MzQKICAgICAg IH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVu dGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vYXV0aGVudGljYXRpb24vdXNlci8KICAgICAg ICAgICAgICAgICAgICAgICAgYXV0aG9yaXplZC1rZXkvbmFtZSIsCiAgICAgICAgICJzaWQiOiAx NzM1CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAg ICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2F1dGhlbnRpY2F0aW9uL3Vz ZXIvCiAgICAgICAgICAgICAgICAgICAgICAgIG5hbWUiLAogICAgICAgICAic2lkIjogMTczNgog ICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAg ImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9hdXRoZW50aWNhdGlvbi91c2VyLwog ICAgICAgICAgICAgICAgICAgICAgICBwYXNzd29yZCIsCiAgICAgICAgICJzaWQiOiAxNzM3CiAg ICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAi aWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2Nsb2NrIiwKICAgICAgICAgInNpZCI6 IDE3MzgKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAg ICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vY2xvY2svdGltZXpvbmUt bmFtZSIsCiAgICAgICAgICJzaWQiOiAxNzM5CiAgICAgICB9LAogICAgICAgewogICAgICAgICAi bmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06 c3lzdGVtL2Nsb2NrL3RpbWV6b25lLXV0Yy1vZmZzZXQiLAogICAgICAgICAic2lkIjogMTc0MAog ICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAg ImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9jb250YWN0IiwKICAgICAgICAgInNp ZCI6IDE3NDEKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIs CiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vZG5zLXJlc29sdmVy IiwKICAgICAgICAgInNpZCI6IDE3NDIKICAgICAgIH0sCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAg ICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDI1XQoMCklu dGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAg RmVicnVhcnkgMjAyMAoKCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAg ICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vZG5zLXJlc29sdmVyL29w dGlvbnMiLAogICAgICAgICAic2lkIjogMTc0MwogICAgICAgfSwKICAgICAgIHsKICAgICAgICAg Im5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVt OnN5c3RlbS9kbnMtcmVzb2x2ZXIvb3B0aW9ucy8KICAgICAgICAgICAgICAgICAgICAgICAgYXR0 ZW1wdHMiLAogICAgICAgICAic2lkIjogMTc0NAogICAgICAgfSwKICAgICAgIHsKICAgICAgICAg Im5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVt OnN5c3RlbS9kbnMtcmVzb2x2ZXIvb3B0aW9ucy8KICAgICAgICAgICAgICAgICAgICAgICAgdGlt ZW91dCIsCiAgICAgICAgICJzaWQiOiAxNzQ1CiAgICAgICB9LAogICAgICAgewogICAgICAgICAi bmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06 c3lzdGVtL2Rucy1yZXNvbHZlci9zZWFyY2giLAogICAgICAgICAic2lkIjogMTc0NgogICAgICAg fSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50 aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9kbnMtcmVzb2x2ZXIvc2VydmVyIiwKICAgICAg ICAgInNpZCI6IDE3NDcKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAi ZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vZG5zLXJl c29sdmVyL3NlcnZlci9uYW1lIiwKICAgICAgICAgInNpZCI6IDE3NDgKICAgICAgIH0sCiAgICAg ICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjog Ii9pZXRmLXN5c3RlbTpzeXN0ZW0vZG5zLXJlc29sdmVyL3NlcnZlci8KICAgICAgICAgICAgICAg ICAgICAgICAgdWRwLWFuZC10Y3AiLAogICAgICAgICAic2lkIjogMTc0OQogICAgICAgfSwKICAg ICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIi OiAiL2lldGYtc3lzdGVtOnN5c3RlbS9kbnMtcmVzb2x2ZXIvc2VydmVyLwogICAgICAgICAgICAg ICAgICAgICAgICB1ZHAtYW5kLXRjcC9hZGRyZXNzIiwKICAgICAgICAgInNpZCI6IDE3NTAKICAg ICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJp ZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vZG5zLXJlc29sdmVyL3NlcnZlci8KICAg ICAgICAgICAgICAgICAgICAgICAgdWRwLWFuZC10Y3AvcG9ydCIsCgoKClZlaWxsZXR0ZSwgZXQg YWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDI2 XQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQp ICAgICAgRmVicnVhcnkgMjAyMAoKCiAgICAgICAgICJzaWQiOiAxNzUxCiAgICAgICB9LAogICAg ICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6 ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2hvc3RuYW1lIiwKICAgICAgICAgInNpZCI6IDE3NTIKICAg ICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJp ZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vbG9jYXRpb24iLAogICAgICAgICAic2lk IjogMTc1MwogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwK ICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9udHAiLAogICAgICAg ICAic2lkIjogMTc1NAogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJk YXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9udHAvZW5h YmxlZCIsCiAgICAgICAgICJzaWQiOiAxNzU1CiAgICAgICB9LAogICAgICAgewogICAgICAgICAi bmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06 c3lzdGVtL250cC9zZXJ2ZXIiLAogICAgICAgICAic2lkIjogMTc1NgogICAgICAgfSwKICAgICAg IHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAi L2lldGYtc3lzdGVtOnN5c3RlbS9udHAvc2VydmVyLwogICAgICAgICAgICAgICAgICAgICAgICBh c3NvY2lhdGlvbi10eXBlIiwKICAgICAgICAgInNpZCI6IDE3NTcKICAgICAgIH0sCiAgICAgICB7 CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9p ZXRmLXN5c3RlbTpzeXN0ZW0vbnRwL3NlcnZlci9pYnVyc3QiLAogICAgICAgICAic2lkIjogMTc1 OAogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAg ICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9udHAvc2VydmVyL25hbWUiLAog ICAgICAgICAic2lkIjogMTc1OQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFj ZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9u dHAvc2VydmVyL3ByZWZlciIsCiAgICAgICAgICJzaWQiOiAxNzYwCiAgICAgICB9LAoKCgpWZWls bGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAg ICBbUGFnZSAyN10KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRp ZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICAgICAgewogICAgICAgICAibmFtZXNw YWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVt L250cC9zZXJ2ZXIvdWRwIiwKICAgICAgICAgInNpZCI6IDE3NjEKICAgICAgIH0sCiAgICAgICB7 CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9p ZXRmLXN5c3RlbTpzeXN0ZW0vbnRwL3NlcnZlci91ZHAvYWRkcmVzcyIsCiAgICAgICAgICJzaWQi OiAxNzYyCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAog ICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL250cC9zZXJ2ZXIvdWRw L3BvcnQiLAogICAgICAgICAic2lkIjogMTc2MwogICAgICAgfSwKICAgICAgIHsKICAgICAgICAg Im5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVt OnN5c3RlbS9yYWRpdXMiLAogICAgICAgICAic2lkIjogMTc2NAogICAgICAgfSwKICAgICAgIHsK ICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2ll dGYtc3lzdGVtOnN5c3RlbS9yYWRpdXMvb3B0aW9ucyIsCiAgICAgICAgICJzaWQiOiAxNzY1CiAg ICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAi aWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL3JhZGl1cy9vcHRpb25zL2F0dGVtcHRz IiwKICAgICAgICAgInNpZCI6IDE3NjYKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1l c3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0 ZW0vcmFkaXVzL29wdGlvbnMvdGltZW91dCIsCiAgICAgICAgICJzaWQiOiAxNzY3CiAgICAgICB9 LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRp ZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL3JhZGl1cy9zZXJ2ZXIiLAogICAgICAgICAic2lk IjogMTc2OAogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwK ICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9yYWRpdXMvc2VydmVy LwogICAgICAgICAgICAgICAgICAgICAgICBhdXRoZW50aWNhdGlvbi10eXBlIiwKICAgICAgICAg InNpZCI6IDE3NjkKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0 YSIsCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAg ICAgICAgICAgICAgIFtQYWdlIDI4XQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEg SXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgRmVicnVhcnkgMjAyMAoKCiAgICAgICAgICJpZGVu dGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vcmFkaXVzL3NlcnZlci9uYW1lIiwKICAgICAg ICAgInNpZCI6IDE3NzAKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAi ZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vcmFkaXVz L3NlcnZlci91ZHAiLAogICAgICAgICAic2lkIjogMTc3MQogICAgICAgfSwKICAgICAgIHsKICAg ICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYt c3lzdGVtOnN5c3RlbS9yYWRpdXMvc2VydmVyL3VkcC8KICAgICAgICAgICAgICAgICAgICAgICAg YWRkcmVzcyIsCiAgICAgICAgICJzaWQiOiAxNzcyCiAgICAgICB9LAogICAgICAgewogICAgICAg ICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0 ZW06c3lzdGVtL3JhZGl1cy9zZXJ2ZXIvdWRwLwogICAgICAgICAgICAgICAgICAgICAgICBhdXRo ZW50aWNhdGlvbi1wb3J0IiwKICAgICAgICAgInNpZCI6IDE3NzMKICAgICAgIH0sCiAgICAgICB7 CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9p ZXRmLXN5c3RlbTpzeXN0ZW0vcmFkaXVzL3NlcnZlci91ZHAvCiAgICAgICAgICAgICAgICAgICAg ICAgIHNoYXJlZC1zZWNyZXQiLAogICAgICAgICAic2lkIjogMTc3NAogICAgICAgfQogICAgIF0K ICAgfQoKQXBwZW5kaXggQi4gIFNJRCBhdXRvIGdlbmVyYXRpb24KCiAgIEFzc2lnbm1lbnQgb2Yg U0lEcyB0byBZQU5HIGl0ZW1zIGNhbiBiZSBhdXRvbWF0ZWQsIHRoZSByZWNvbW1lbmRlZAogICBw cm9jZXNzIHRvIGFzc2lnbiBTSURzIGlzIGFzIGZvbGxvd3M6CgogICAxLiAgQSB0b29sIGV4dHJh Y3RzIHRoZSBkaWZmZXJlbnQgaXRlbXMgZGVmaW5lZCBmb3IgYSBzcGVjaWZpYyBZQU5HCiAgICAg ICBtb2R1bGUuCgogICAyLiAgVGhlIGxpc3Qgb2YgaXRlbXMgaXMgc29ydGVkIGluIGFscGhhYmV0 aWNhbCBvcmRlciwgJ25hbWVzcGFjZScgaW4KICAgICAgIGRlc2NlbmRpbmcgb3JkZXIsICdpZGVu dGlmaWVyJyBpbiBhc2NlbmRpbmcgb3JkZXIuICBUaGUKICAgICAgICduYW1lc3BhY2UnIGFuZCAn aWRlbnRpZmllcicgZm9ybWF0cyBhcmUgZGVzY3JpYmVkIGluIHRoZSBZQU5HCiAgICAgICBtb2R1 bGUgJ2lldGYtc2lkLWZpbGUnIGRlZmluZWQgaW4gU2VjdGlvbiA0LgoKICAgMy4gIFNJRHMgYXJl IGFzc2lnbmVkIHNlcXVlbnRpYWxseSBmcm9tIHRoZSBlbnRyeSBwb2ludCB1cCB0byB0aGUKICAg ICAgIHNpemUgb2YgdGhlIHJlZ2lzdGVyZWQgU0lEIHJhbmdlLiAgVGhpcyBhcHByb2FjaCBpcyBy ZWNvbW1lbmRlZAogICAgICAgdG8gbWluaW1pemUgdGhlIHNlcmlhbGl6YXRpb24gb3ZlcmhlYWQs IGVzcGVjaWFsbHkgd2hlbiBkZWx0YQogICAgICAgYmV0d2VlbiBhIHJlZmVyZW5jZSBTSUQgYW5k IHRoZSBjdXJyZW50IFNJRCBpcyB1c2VkIGJ5IHByb3RvY29scwogICAgICAgYWltaW5nIHRvIHJl ZHVjZSBtZXNzYWdlIHNpemUuCgoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBB dWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAyOV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgIEZlYnJ1YXJ5IDIwMjAK CgogICA0LiAgSWYgdGhlIG51bWJlciBvZiBpdGVtcyBleGNlZWRzIHRoZSBTSUQgcmFuZ2Uocykg YWxsb2NhdGVkIHRvIGEKICAgICAgIFlBTkcgbW9kdWxlLCBhbiBleHRyYSByYW5nZSBpcyBhZGRl ZCBmb3Igc3Vic2VxdWVudCBhc3NpZ25tZW50cy4KCiAgIDUuICBUaGUgImRlcGVuZGVuY2llcy1y ZXZpc2lvbnMiIHNob3VsZCByZWZsZWN0IHRoZSByZXZpc2lvbiBudW1iZXJzCiAgICAgICBvZiBl YWNoIFlBTkcgbW9kdWxlIHRoYXQgdGhlIFlBTkcgbW9kdWxlIGltcG9ydHMgYXQgdGhlIG1vbWVu dCBvZgogICAgICAgdGhlIGdlbmVyYXRpb24uCgogICBJbiBjYXNlIG9mIGFuIHVwZGF0ZSB0byBh biBleGlzdGluZyAiLnNpZCIgZmlsZSwgYW4gYWRkaXRpb25hbCBzdGVwCiAgIGlzIG5lZWRlZCB0 aGF0IGluY3JlbWVudHMgdGhlICIuc2lkIiBmaWxlIHZlcnNpb24gbnVtYmVyLiAgSWYgdGhlcmUK ICAgd2FzIG5vIHZlcnNpb24gbnVtYmVyIGluIHRoZSBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoZSAi LnNpZCIgZmlsZSwgMAogICBpcyBhc3N1bWVkIGFzIHRoZSB2ZXJzaW9uIG51bWJlciBvZiB0aGUg b2xkIHZlcnNpb24gb2YgdGhlICIuc2lkIgogICBmaWxlIGFuZCB0aGUgdmVyc2lvbiBudW1iZXIg aXMgMSBmb3IgdGhlIG5ldyAiLnNpZCIgZmlsZS4gIEFwYXJ0IGZyb20KICAgdGhhdCwgY2hhbmdl cyBvZiBTSUQgZmlsZXMgY2FuIGFsc28gYmUgYXV0b21hdGVkIHVzaW5nIHRoZSBzYW1lCiAgIG1l dGhvZCBkZXNjcmliZWQgYWJvdmUsIG9ubHkgdW5hc3NpZ25lZCBZQU5HIGl0ZW1zIGFyZSBwcm9j ZXNzZWQgYXQKICAgc3RlcCAjMy4gIEFscmVhZHkgZXhpc3RpbmcgaXRlbXMgaW4gdGhlIFNJRCBm aWxlIHNob3VsZCBub3QgYmUgZ2l2ZW4KICAgbmV3IFNJRHMuCgogICBOb3RlIHRoYXQgIi5zaWQi IGZpbGUgdmVyc2lvbnMgYXJlIHNwZWNpZmljIHRvIGEgWUFORyBtb2R1bGUKICAgcmV2aXNpb24u ICBGb3IgZWFjaCBuZXcgWUFORyBtb2R1bGUgb3IgZWFjaCBuZXcgcmV2aXNpb24gb2YgYW4KICAg ZXhpc3RpbmcgWUFORyBtb2R1bGUsIHRoZSB2ZXJzaW9uIG51bWJlciBvZiB0aGUgaW5pdGlhbCAi LnNpZCIgZmlsZQogICBzaG91bGQgZWl0aGVyIGJlIDAgb3Igc2hvdWxkIG5vdCBiZSBwcmVzZW50 LgoKQXBwZW5kaXggQy4gICIuc2lkIiBmaWxlIGxpZmVjeWNsZQoKICAgQmVmb3JlIGFzc2lnbmlu ZyBTSURzIHRvIHRoZWlyIFlBTkcgbW9kdWxlcywgWUFORyBtb2R1bGUgYXV0aG9ycyBtdXN0CiAg IGFjcXVpcmUgYSBTSUQgcmFuZ2UgZnJvbSBhICJTSUQgUmFuZ2UgUmVnaXN0cnkiLiAgSWYgdGhl IFlBTkcgbW9kdWxlCiAgIGlzIHBhcnQgb2YgYW4gSUVURiBkcmFmdCBvciBSRkMsIHRoZSBTSUQg cmFuZ2UgbmVlZCB0byBiZSBhY3F1aXJlZAogICBmcm9tIHRoZSAiSUVURiBTSUQgUmFuZ2UgUmVn aXN0cnkiIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA2LjMuICBGb3IKICAgdGhlIG90aGVyIFlBTkcg bW9kdWxlcywgdGhlIGF1dGhvcnMgY2FuIGFjcXVpcmUgYSBTSUQgcmFuZ2UgZnJvbSBhbnkKICAg IlNJRCBSYW5nZSBSZWdpc3RyeSIgb2YgdGhlaXIgY2hvaWNlLgoKICAgT25jZSB0aGUgU0lEIHJh bmdlIGlzIGFjcXVpcmVkLCB0aGUgb3duZXIgY2FuIHVzZSBpdCB0byBnZW5lcmF0ZQogICAiLnNp ZCIgZmlsZS9zIGZvciBoaXMgWUFORyBtb2R1bGUvcy4gIEl0IGlzIHJlY29tbWVuZGVkIHRvIGxl YXZlIHNvbWUKICAgdW5hbGxvY2F0ZWQgU0lEcyBmb2xsb3dpbmcgdGhlIGFsbG9jYXRlZCByYW5n ZSBpbiBlYWNoICIuc2lkIiBmaWxlIGluCiAgIG9yZGVyIHRvIGFsbG93IGJldHRlciBldm9sdXRp b24gb2YgdGhlIFlBTkcgbW9kdWxlIGluIHRoZSBmdXR1cmUuCiAgIEdlbmVyYXRpb24gb2YgIi5z aWQiIGZpbGVzIHNob3VsZCBiZSBwZXJmb3JtZWQgdXNpbmcgYW4gYXV0b21hdGVkCiAgIHRvb2wu ICBOb3RlIHRoYXQgIi5zaWQiIGZpbGVzIGNhbiBvbmx5IGJlIGdlbmVyYXRlZCBmb3IgWUFORyBt b2R1bGVzCiAgIGFuZCBub3QgZm9yIHN1Ym1vZHVsZXMuCgpDLjEuICBTSUQgRmlsZSBDcmVhdGlv bgoKICAgVGhlIGZvbGxvd2luZyBhY3Rpdml0eSBkaWFncmFtIHN1bW1hcml6ZXMgdGhlIGNyZWF0 aW9uIG9mIGEgWUFORwogICBtb2R1bGUgYW5kIGl0cyBhc3NvY2lhdGVkICIuc2lkIiBmaWxlLgoK ICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgTyAgICB8IENyZWF0aW9uIG9mIGEgfAogLXwtIC0+ fCBZQU5HIG1vZHVsZSAgIHwKIC8gXCAgICstLS0tLS0tLS0tLS0tLS0rCgoKClZlaWxsZXR0ZSwg ZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCA4LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdl IDMwXQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChT SUQpICAgICAgRmVicnVhcnkgMjAyMAoKCiAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg VgogICAgICAgIC8tLS0tLS0tLS0tLS0tXAogICAgICAgLyBTdGFuZGFyZGl6ZWQgIFwgICAgIHll cwogICAgICAgXCBZQU5HIG1vZHVsZSA/IC8tLS0tLS0tLS0tLS0tKwogICAgICAgIFwtLS0tLS0t LS0tLS0tLyAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICB8IG5vICAgICAgICAgICAgICAg ICAgfAogICAgICAgICAgICAgICBWICAgICAgICAgICAgICAgICAgICAgVgogICAgICAgIC8tLS0t LS0tLS0tLS0tXCAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAvIENvbnN0cmFpbmVkICAg XCB5ZXMgfCBTSUQgcmFuZ2UgICAgIHwKICAgKy0tPlwgYXBwbGljYXRpb24gPyAvLS0tLT58IHJl Z2lzdHJhdGlvbiAgfDwtLS0tLS0tLS0tKwogICB8ICAgIFwtLS0tLS0tLS0tLS0tLyAgICAgICst LS0tLS0tLS0tLS0tLS0rICAgICAgICAgICB8CiAgIHwgICAgICAgICAgIHwgbm8gICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgViAgICAgICAgICAg ICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgfAogICB8ICAgKy0tLS0tLS0tLS0tLS0tLSsg ICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICB8CiAgICstLS18IFlBTkcgbW9kdWxlICAg fCAgICAgfCBTSUQgc3ViLXJhbmdlIHwgICAgICAgICAgIHwKICAgICAgIHwgdXBkYXRlICAgICAg ICB8ICAgICB8IGFzc2lnbm1lbnQgICAgfDwtLS0tLS0tLS0tKwogICAgICAgKy0tLS0tLS0tLS0t LS0tLSsgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICstLS0tLS0tLS0tLS0tKwogICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIi5zaWQiIGZpbGUgICB8ICAgIHwgUmV3b3JrIFlB TkcgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgZ2VuZXJhdGlvbiAgICB8ICAgIHwg ICAgbW9kZWwgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0rICAgICstLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICBeCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBWICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAvLS0tLS0tLS0tLVwgIHllcyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLyAgV29yayBpbiAgIFwgLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBcICBwcm9ncmVzcyAgLwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwtLS0t LS0tLS0tLwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBubwogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLy0tLS0tLS0tLS0tLS1cICAgICAgIC8tLS0tLS0tLS0tLS0tXAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAvICAgICAgUkZDICAgICAgXCBubyAgLyAgICAgT3BlbiAgICAgIFwg bm8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgcHVibGljYXRpb24/IC8tLS0tPlwg c3BlY2lmaWNhdGlvbj8vLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXC0tLS0t LS0tLS0tLS0vICAgICAgIFwtLS0tLS0tLS0tLS0tLyAgICB8CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCB5ZXMgICAgICAgICAgICAgICAgIHwgeWVzICAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICArLS0tLS0tLS0tLS0tLS0t KyAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFYgICAg IFYgICAgICAgICAgICAgICAgICAgICAgICAgICBWCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBJQU5BICAgICAgfCAgICAgICAgICAg ICAgICAgfCBUaGlyZCBwYXJ0eSAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBy ZWdpc3RyYXRpb24gIHwgICAgICAgICAgICAgICAgIHwgcmVnaXN0cmF0aW9uICB8CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tKy0tLS0tLS0rICAgICAgICAgICAgICAgICAr LS0tLS0tLSstLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtET05FXQoKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgIEV4cGlyZXMg QXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMzFdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICBGZWJydWFyeSAyMDIw CgoKICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogU0lEIExpZmVjeWNsZQoKQy4y LiAgU0lEIEZpbGUgVXBkYXRlCgogICBUaGUgZm9sbG93aW5nIEFjdGl2aXR5IGRpYWdyYW0gc3Vt bWFyaXplcyB0aGUgdXBkYXRlIG9mIGEgWUFORyBtb2R1bGUKICAgYW5kIGl0cyBhc3NvY2lhdGVk ICIuc2lkIiBmaWxlLgoKICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgTyAgICB8IFVw ZGF0ZSBvZiB0aGUgfAogICAgLXwtIC0+fCBZQU5HIG1vZHVsZSAgIHwKICAgIC8gXCAgIHwgb3Ig aW5jbHVkZShzKSB8CiAgICAgICAgICB8IG9yIGltcG9ydChzKSAgfAogICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICBWCiAgICAg ICAgICAgICAgLy0tLS0tLS0tLS0tLS1cCiAgICAgICAgICAgICAvICBOZXcgaXRlbXMgICAgXCB5 ZXMKICAgICAgICAgICAgIFwgIGNyZWF0ZWQgID8gICAvLS0tLS0tKwogICAgICAgICAgICAgIFwt LS0tLS0tLS0tLS0tLyAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgIHwgbm8gICAgICAgICAg IFYKICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAvLS0tLS0tLS0tLS0tLVwgICAgICArLS0t LS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgfCAgICAgIC8gIFNJRCByYW5nZSAg ICBcIHllcyB8IEV4dHJhIHN1Yi1yYW5nZXwKICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFwg IGV4aGF1c3RlZCA/ICAvLS0tLT58IGFzc2lnbm1lbnQgICAgIHwKICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICBcLS0tLS0tLS0tLS0tLS8gICAgICArLS0tLS0tLS0tLS0tLS0tLSsKICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCBubyAgICAgICAgICAgICAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsK ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICBWCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICArLS0tLS0tLS0t LS0tLS0tKwogICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAiLnNpZCIgZmlsZSAgIHwKICAg ICAgICAgICAgICAgICAgICAgfCAgICAgIHwgdXBkYXRlIGJhc2VkICB8CiAgICAgICAgICAgICAg ICAgICAgIHwgICAgICB8IG9uIHByZXZpb3VzICAgfAogICAgICAgICAgICAgICAgICAgICB8ICAg ICAgfCAiLnNpZCIgZmlsZSAgIHwKICAgICAgICAgICAgICAgICAgICAgfCAgICAgICstLS0tLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwKICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgVgogICAgICAgICAgICAgICAgICAgICB8ICAgICAg IC8tLS0tLS0tLS0tLS0tXCAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAvICBQdWJsaWNseSAgICAgXCB5ZXMgfCBZQU5HIG1vZHVsZSAgIHwKICAgICAg ICAgICAgICAgICAgICAgfCAgICAgIFwgIGF2YWlsYWJsZSA/ICAvLS0tLT58IHJlZ2lzdHJhdGlv biAgfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgIFwtLS0tLS0tLS0tLS0tLyAgICAgICst LS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgbm8g ICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtET05FXQoKCiAgICAgICAgICAg ICAgICAgICAgRmlndXJlIDI6IFlBTkcgYW5kIFNJRCBmaWxlIHVwZGF0ZQoKCgoKVmVpbGxldHRl LCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMjAgICAgICAgICAgICAgICAgW1Bh Z2UgMzJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIg KFNJRCkgICAgICBGZWJydWFyeSAyMDIwCgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBNaWNoZWwg VmVpbGxldHRlIChlZGl0b3IpCiAgIFRyaWxsaWFudCBOZXR3b3JrcyBJbmMuCiAgIDYxMCBSdWUg ZHUgTHV4ZW1ib3VyZwogICBHcmFuYnksIFF1ZWJlYyAgSjJKIDJWMgogICBDYW5hZGEKCiAgIFBo b25lOiArMTQ1MDM3NTA1NTYKICAgRW1haWw6IG1pY2hlbC52ZWlsbGV0dGVAdHJpbGxpYW50LmNv bQoKCiAgIEFsZXhhbmRlciBQZWxvdiAoZWRpdG9yKQogICBBY2tsaW8KICAgMTEzN0EgYXZlbnVl IGRlcyBDaGFtcHMgQmxhbmNzCiAgIENlc3Nvbi1TZXZpZ25lLCBCcmV0YWduZSAgMzU1MTAKICAg RnJhbmNlCgogICBFbWFpbDogYUBhY2tsLmlvCgoKICAgSXZheWxvIFBldHJvdiAoZWRpdG9yKQog ICBBY2tsaW8KICAgMTEzN0EgYXZlbnVlIGRlcyBDaGFtcHMgQmxhbmNzCiAgIENlc3Nvbi1TZXZp Z25lLCBCcmV0YWduZSAgMzU1MTAKICAgRnJhbmNlCgogICBFbWFpbDogaXZheWxvQGFja2wuaW8K CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBB dWd1c3QgOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAzM10K --0000000000001c9494059dd480c3-- From nobody Wed Feb 5 12:07:26 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD95120100; Wed, 5 Feb 2020 12:07:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158093324348.12844.15276222590512673603.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 12:07:23 -0800 Archived-At: Subject: [core] core - New Meeting Session Request for IETF 107 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 20:07:23 -0000 A new meeting session request has just been submitted by Carsten Bormann, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: cbor t2trg cose artarea rats lake suit Technology Overlap: ace teep saag secdispatch sacm lwig 6tisch 6lo roll httpbis lpwan raw Key Participant Conflict: dnssd netconf netmod emu dots anima irtfopen People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Special Requests: Plse also avd any potntlly IoT reltd BOFs&PRGs tht mght cme up, including any "LOOPS". Prefer some time between the two meetings (48 h or more). Second meeting often is 40 people. --------------------------------------------------------- From nobody Tue Feb 11 12:56:07 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 182B2120132; Tue, 11 Feb 2020 12:56:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <158145456305.20035.11844540239631224742@ietfa.amsl.com> Date: Tue, 11 Feb 2020 12:56:03 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-more-units-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 20:56:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Additional Units for SenML Author : Carsten Bormann Filename : draft-ietf-core-senml-more-units-04.txt Pages : 8 Date : 2020-02-11 Abstract: The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for Units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-senml-more-units-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-more-units-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-more-units-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 11 13:05:17 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D445912006F for ; Tue, 11 Feb 2020 13:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UelmBC8R5k2H for ; Tue, 11 Feb 2020 13:05:07 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D85120827 for ; Tue, 11 Feb 2020 13:05:07 -0800 (PST) Received: from client-0163.vpn.uni-bremen.de (client-0163.vpn.uni-bremen.de [134.102.107.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48HFf85yfwz10sc; Tue, 11 Feb 2020 22:05:04 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <20200127170320.y5gu5hh4aqoxtzvm@EMB-918HFH01> Date: Tue, 11 Feb 2020 22:05:03 +0100 Cc: core@ietf.org, fluffy@iii.ca X-Mao-Original-Outgoing-Id: 603147903.6666451-43e1af16b3cf463bd18f507ac8669313 Content-Transfer-Encoding: quoted-printable Message-Id: <86CDA415-5152-4414-BDB2-B4493B04AB33@tzi.org> References: <20200120161000.jxfsyeiffrvih62x@EMB-918HFH01> <5e82c3f0-aa71-460c-a646-9a86427d7f40@www.fastmail.com> <20200127170320.y5gu5hh4aqoxtzvm@EMB-918HFH01> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [core] CoRE @ IETF106: Summary and Minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 21:05:14 -0000 I have submitted an update to senml-more-units that should address the = concerns: Htmlized: = https://tools.ietf.org/html/draft-ietf-core-senml-more-units-04 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-more-units Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-more-units-04 The -04 version now no longer updates RFC 8428 to allow the use of units = from the secondary registry, but leaves this to specific indicators that = announce the presence of secondary units in the SenML Pack. One early = draft with a proposal of how to do this is now available as: Htmlized: = https://tools.ietf.org/html/draft-bormann-core-senml-versions (There is no intention to couple the secondary registry to this specific = way of indicating the use of secondary units; the above draft, while = intended to be normative when it is done, is only an informational = reference in senml-more-units.) In addition, the new version is more outspoken on the advantages of = sticking to primary units in SenML packs, and it addresses the = operational concerns that would result if IoT systems frequently and = automatically updated their unit definitions directly from the IANA = registry. Thanks to all the people that made it clear in offline discussions that = this is a better way forward than just charging ahead and enabling = secondary units everywhere. (Still with author hat on only:) CoRE WG, please check whether this proposed resolution is acceptable to = the WG. Gr=C3=BC=C3=9Fe, Carsten > On 2020-01-27, at 18:03, Jaime Jim=C3=A9nez wrote: >=20 > Dear all, >=20 > Coming back to this issue, I have not seen a reply on the list > regarding this. I would like to have it concluded so that we can move > the document forward. I agree that the text should reflect that the > secondary registry is not be the preferable option if units in the > primary registry can be used. Maybe the authors could work out a > modified draft that better explains that, after which we can do the > document write up and ship it. >=20 > Ciao! > -- Jaime >=20 >=20 > On Tue, Jan 21, 2020 at 11:35:47AM +0200, Jaime Jimenez wrote: >> Sending it to the core thread.=20 >>=20 >> --=20 >> Jaime Jim=C3=A9nez >>=20 >> On Mon, Jan 20, 2020, at 6:10 PM, Jaime Jimenez wrote: >>> Hi, >>>=20 >>> comments below.=20 >>>=20 >>> On Fri, Dec 13, 2019 at 11:27:34AM -0700, Cullen Jennings wrote: >>>>=20 >>>>=20 >>>>> On Dec 9, 2019, at 3:42 PM, Carsten Bormann wrote: >>>>>=20 >>>>>=20 >>>>> Concerns had been raised about opening up the second registry for >>>>> derived units, making it harder for a SenML application to find = out >>>>> whether a unit encountered was actually of interest to it. >>>>> Discussion in the first session resulted in the tentative proposal >>>>> to mark secondary units with an asterisk (as in "*km/h", as = opposed >>>>> to unmarked "m/s"). Further discussion in the second session made >>>>> clear that while this makes the use of secondary units stand out, = it >>>>> does not really improve the situation of SenML applications that >>>>> want to quickly discard measurements for units they do not care >>>>> about, unless they track the contents of the two registries, which >>>>> would make the asterisks redundant. >>>>=20 >>>> I disagree that the asterisk does not improve the situation >>>>=20 >>>>> There also was some feedback >>>>> the asterisks would make the adoption of the SenML units registry = by >>>>> other SDOs more difficult. The in-room consensus not to go for = the >>>>> asterisks, but to include more explanatory text about = implementation >>>>> strategies, needs to confirmed on the mailing list. =20 >>>>=20 >>>> I strongly object to this. RFC 8428 has a strong assertion that = the units=20 >>>>=20 >>>> For a given type of measurement, there will only be one unit >>>> type defined. So for length, meters are defined and other >>>> lengths such as mile, foot, light year are not allowed. For >>>> most cases, the SI unit is preferred. >>>> There is running code that is based on that assumption that has = been in production for many years. You can=E2=80=99t break that = assumption without some backwards compatibility consideration that help = theses deployed applications mitigate the breakage this causes. >>>=20 >>> I believe that the assumption of having only one unit per = measurement >>> was broken already with core-senml-more-units as it creates the >>> secondary registry. So the asterisk does not fix that. =20 >>>=20 >>>> The ideas that millions of edge aggregation devices, many on far = side of slow links, would query the IANA web server to track the units = and decide how to process data seems like a very bad design. I would = expect the IESG to reject anything that lead to cases like = https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse = >>>>=20 >>>=20 >>> I also do not see how the asterisk would make parsing easier. If >>> existing edge devices are hardcoded to use a subset of all units = -just >>> the primary senml registry- then they would filter messages = containing >>> any unit they do not understand anyways.=20 >>>=20 >>> Also the asterisk does not tell an application processing a specific >>> measurement (e.g., temperature in celsius) additional information = about >>> the unit (e.g., I am temperature in fahrenheit, this is important) >>> indicating that this new unit is something it should process, it = only indicates >>> that it is part of the secondary registry. >>>=20 >>> Regarding the querying of the senml registry, I think that would = have to >>> happen anyways, as new units will be registered over time, even if = not >>> very often.=20 >>>=20 >>> I think the real issue here is whether to signal "this unit belongs = to a >>> secondary registry, not the main one" or not. Flagging a unit with = "*" or >>> having a different field like "u2" can confuse developers = unnecessarily,=20 >>> as they do not need to know about historical standard decisions. = It's >>> more of a penalty to those using it :D=20 >>>=20 >>> And if you want to convey that the secondary registry is not the >>> preferred one, then I think that is something that should be on the >>> draft itself, right? With very strong wording and so on, but not on = the >>> wire in a senml record.=20 >>>=20 >>>>=20 >>>=20 >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Tue Feb 11 13:13:00 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CD1120818 for ; Tue, 11 Feb 2020 13:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzhBp4ssdxyv for ; Tue, 11 Feb 2020 13:12:55 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::615]) (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 77B0012006F for ; Tue, 11 Feb 2020 13:12:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nOzfr8RzltcHi5fml9IvUMhvGtTxGHz3c4M4g6n4CbG2+8R0BsTW+OFOTwGNIe+6FGxTZ+pPJbvTo/USRsr1PUqkI8rqfYp15kiFP6fEWXQdiT26wyhExxvHYcDCCbNdQeR9OyQGrsvHwRi515Kthi+GDQ6EKqFUY0IS1ohy406Nya5z9/l0Qxl3tq6+BOuD/j1I0iGoxw6MNz7HEVBerKtFouxIlAB5mqVzGbLeGHMOAx+JKc/H2AQppJvXla6uSARNvmuRGc40u8wcGZTFh8CbMmZIh/yMZkU4lpQqDXEWcMRkyOUVWhpeG/rC2vLVIls2UdfR92Vn57wzO9TO8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zgqbY/6pai8yVP6VYnvyUuAplVcs0blzfyaVAAlxhNw=; b=Im7ASvDP+rqVbVxeiwMetnBPP86kOijXMKWDCTgzvRaK9WUCN34VrtNQ4/kIbYVs/qiN1vmcNxJpcSL0gRMAmTmoij6fV63QwrsMEsSIn6gI4zGEVEG2uxSg4iSMShpTORCKE1IU3ApsoC7iNAhpfkpjCDmqvq1JwPeO4lZlZL9xhH5lYmqon8xjLsw4B7PwHQ8zvH1DonEf5NqPnKY7H1DnlMhmtLO9jIocTsj8pZ1YgaOGek7vK6Rg0gZzSQOPxB1sqIWn2RPO0/ZKZ7gc5BeXcnrVFCip18YfUD8c9WSvxxy7za8fSQVPFZbjORwnSqyEK0lv8xtzJITGu6Qpzg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zgqbY/6pai8yVP6VYnvyUuAplVcs0blzfyaVAAlxhNw=; b=p0A1FHjq+v68cTgx5bzFmMfJjDA7fozjhGLMKhM344GOZT5Zc3u3Kj+YlsNGhPKuHcPoDQQ1Orn0HnMWxppcDaHGS09tic2rCKTKV+ozPAiKrPH2P6WS1A2MP85wP4MMa8z8cFfWKUBAeR//tSgpb94KQGInvIhIdWWd2wbmiAg= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB4233.eurprd07.prod.outlook.com (20.176.167.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.13; Tue, 11 Feb 2020 21:12:51 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::f901:618:7da9:efda]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::f901:618:7da9:efda%7]) with mapi id 15.20.2729.021; Tue, 11 Feb 2020 21:12:51 +0000 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Carsten Bormann CC: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org" Thread-Topic: [core] CoRE @ IETF106: Summary and Minutes Thread-Index: AQHVruHyaVG9yRtSnEmWxWx9ZzysaKe4aDUAgDy2hx6ACeraAIAX1oGAgAACLQA= Date: Tue, 11 Feb 2020 21:12:50 +0000 Message-ID: References: <86CDA415-5152-4414-BDB2-B4493B04AB33@tzi.org> In-Reply-To: <86CDA415-5152-4414-BDB2-B4493B04AB33@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-originating-ip: [2001:14bb:170:993:8814:925c:2798:d9e9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cbee08e6-36d6-4bb7-8378-08d7af37271c x-ms-traffictypediagnostic: HE1PR07MB4233: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0310C78181 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(136003)(39860400002)(346002)(396003)(189003)(199004)(85202003)(6512007)(2906002)(186003)(6506007)(53546011)(8936002)(86362001)(66616009)(66556008)(8676002)(81166006)(64756008)(81156014)(66476007)(66446008)(6486002)(54906003)(66574012)(316002)(36756003)(33656002)(66946007)(478600001)(966005)(4326008)(76116006)(6916009)(5660300002)(71200400001)(2616005)(85182001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4233; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QV6fvIEXqqw+M9gC6vOfGLlZ8lcYhBUNeno+n/zUytAjbHzVi/i3WKZ2tatkQH76kjl4sdeRM21ElodkyUxwk9MDPPhISKdZ9vl3LHEuCNPfUhhG5659sFPT/t1P5i9RY6Wjao4GqiX7trJTbEjejrfyXBswnbs42c189SywkNfw4pnoTTI2WdJDjVu7zKlgbzQD3/FnLzbQY6dFmgB6tc1Lunmh1j7PzDw/ZzyNH0ur7IoqSPz10HGe2wGdw4SByDhi5m3kjwAMzquYJ7iEDfVyvj0/qIyQ3qIsMhc3aVFFHc48QRXntS4fAavjQGTIyGH05LbkqtZVLnb3+OP+wEbBuod287uGwWsOGdO/Ken0/9B1jE/Izxg+4wra4/5n8DuKU2b1DzUFuqs3YSYxXQQoiTbZNuYfWcOcmQetBwOPyCycHpoEM0TAQUVql8gIJO7seYyd6OqUPqk6+SnEoKKwm0jTKTNBjGtQvHUsF5QefGWo6NFTqxox5BInPKeQrTooutf5CQxk23CgldMSIQ== x-ms-exchange-antispam-messagedata: e/4+7paDLvzWwgN2yoSqqPA1qyB0VlmmqKyXl4MTNG0dHoRmXxc+abtTI7BJ/42WVQcQUVtSimaKnrqeYmBiWpVPQxPA0JPymU8ReghsIoGBlyiBns2R7tQCuKzJSFZfwWr7Ts95b6FvjbpWLL5aTf4apFzfH392h7xCAgkzdUuV14WYem0kzEfsQJmRJzkeHsvgnWhrcTkVZrhOvueIEw== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; boundary=Apple-Mail-BC8110B5-244A-401A-8458-6B9C1BB6F3F6; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cbee08e6-36d6-4bb7-8378-08d7af37271c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2020 21:12:50.9587 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PsUgeh4Eriw5ppFNVjIIbxa4XSr5blCNnKDqhTFq5+gec0egjE4wmaNnUhbb0LTSrAYP0SjIAQ/Kfg3L1Y3XmoH2epcorhVxRyzxWFwQezU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4233 Archived-At: Subject: Re: [core] CoRE @ IETF106: Summary and Minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 21:12:58 -0000 --Apple-Mail-BC8110B5-244A-401A-8458-6B9C1BB6F3F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhhbmtzIENhcnN0ZW4hIEkgdGhpbmsgdGhpcyBpcyBhIGdvb2Qgd2F5IGZvcndhcmQuIA0KDQpD aGVlcnMsDQpBcmkNCg0KPiBPbiAxMS4gRmViIDIwMjAsIGF0IDIzLjA1LCBDYXJzdGVuIEJvcm1h bm4gPGNhYm9AdHppLm9yZz4gd3JvdGU6DQo+IA0KPiDvu79JIGhhdmUgc3VibWl0dGVkIGFuIHVw ZGF0ZSB0byBzZW5tbC1tb3JlLXVuaXRzIHRoYXQgc2hvdWxkIGFkZHJlc3MgdGhlIGNvbmNlcm5z Og0KPiANCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWNvcmUtc2VubWwtbW9yZS11bml0cy0wNA0KPiBIdG1saXplZDogICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWNvcmUtc2VubWwtbW9y ZS11bml0cw0KPiBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtY29yZS1zZW5tbC1tb3JlLXVuaXRzLTA0DQo+IA0KPiBUaGUgLTA0IHZl cnNpb24gbm93IG5vIGxvbmdlciB1cGRhdGVzIFJGQyA4NDI4IHRvIGFsbG93IHRoZSB1c2Ugb2Yg dW5pdHMgZnJvbSB0aGUgc2Vjb25kYXJ5IHJlZ2lzdHJ5LCBidXQgbGVhdmVzIHRoaXMgdG8gc3Bl Y2lmaWMgaW5kaWNhdG9ycyB0aGF0IGFubm91bmNlIHRoZSBwcmVzZW5jZSBvZiBzZWNvbmRhcnkg dW5pdHMgaW4gdGhlIFNlbk1MIFBhY2suICBPbmUgZWFybHkgZHJhZnQgd2l0aCBhIHByb3Bvc2Fs IG9mIGhvdyB0byBkbyB0aGlzIGlzIG5vdyBhdmFpbGFibGUgYXM6DQo+IA0KPiBIdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvcm1hbm4tY29yZS1zZW5t bC12ZXJzaW9ucw0KPiANCj4gKFRoZXJlIGlzIG5vIGludGVudGlvbiB0byBjb3VwbGUgdGhlIHNl Y29uZGFyeSByZWdpc3RyeSB0byB0aGlzIHNwZWNpZmljIHdheSBvZiBpbmRpY2F0aW5nIHRoZSB1 c2Ugb2Ygc2Vjb25kYXJ5IHVuaXRzOyB0aGUgYWJvdmUgZHJhZnQsIHdoaWxlIGludGVuZGVkIHRv IGJlIG5vcm1hdGl2ZSB3aGVuIGl0IGlzIGRvbmUsIGlzIG9ubHkgYW4gaW5mb3JtYXRpb25hbCBy ZWZlcmVuY2UgaW4gc2VubWwtbW9yZS11bml0cy4pDQo+IA0KPiBJbiBhZGRpdGlvbiwgdGhlIG5l dyB2ZXJzaW9uIGlzIG1vcmUgb3V0c3Bva2VuIG9uIHRoZSBhZHZhbnRhZ2VzIG9mIHN0aWNraW5n IHRvIHByaW1hcnkgdW5pdHMgaW4gU2VuTUwgcGFja3MsIGFuZCBpdCBhZGRyZXNzZXMgdGhlIG9w ZXJhdGlvbmFsIGNvbmNlcm5zIHRoYXQgd291bGQgcmVzdWx0IGlmIElvVCBzeXN0ZW1zIGZyZXF1 ZW50bHkgYW5kIGF1dG9tYXRpY2FsbHkgdXBkYXRlZCB0aGVpciB1bml0IGRlZmluaXRpb25zIGRp cmVjdGx5IGZyb20gdGhlIElBTkEgcmVnaXN0cnkuDQo+IA0KPiBUaGFua3MgdG8gYWxsIHRoZSBw ZW9wbGUgdGhhdCBtYWRlIGl0IGNsZWFyIGluIG9mZmxpbmUgZGlzY3Vzc2lvbnMgdGhhdCB0aGlz IGlzIGEgYmV0dGVyIHdheSBmb3J3YXJkIHRoYW4ganVzdCBjaGFyZ2luZyBhaGVhZCBhbmQgZW5h Ymxpbmcgc2Vjb25kYXJ5IHVuaXRzIGV2ZXJ5d2hlcmUuDQo+IA0KPiAoU3RpbGwgd2l0aCBhdXRo b3IgaGF0IG9uIG9ubHk6KQ0KPiBDb1JFIFdHLCBwbGVhc2UgY2hlY2sgd2hldGhlciB0aGlzIHBy b3Bvc2VkIHJlc29sdXRpb24gaXMgYWNjZXB0YWJsZSB0byB0aGUgV0cuDQo+IA0KPiBHcsO8w59l LCBDYXJzdGVuDQo+IA0KPiANCj4+IE9uIDIwMjAtMDEtMjcsIGF0IDE4OjAzLCBKYWltZSBKaW3D qW5leiA8amFpbWVAaWtpLmZpPiB3cm90ZToNCj4+IA0KPj4gRGVhciBhbGwsDQo+PiANCj4+IENv bWluZyBiYWNrIHRvIHRoaXMgaXNzdWUsIEkgaGF2ZSBub3Qgc2VlbiBhIHJlcGx5IG9uIHRoZSBs aXN0DQo+PiByZWdhcmRpbmcgdGhpcy4gSSB3b3VsZCBsaWtlIHRvIGhhdmUgaXQgY29uY2x1ZGVk IHNvIHRoYXQgd2UgY2FuIG1vdmUNCj4+IHRoZSBkb2N1bWVudCBmb3J3YXJkLiBJIGFncmVlIHRo YXQgdGhlIHRleHQgc2hvdWxkIHJlZmxlY3QgdGhhdCB0aGUNCj4+IHNlY29uZGFyeSByZWdpc3Ry eSBpcyBub3QgYmUgdGhlIHByZWZlcmFibGUgb3B0aW9uIGlmIHVuaXRzIGluIHRoZQ0KPj4gcHJp bWFyeSByZWdpc3RyeSBjYW4gYmUgdXNlZC4gTWF5YmUgdGhlIGF1dGhvcnMgY291bGQgd29yayBv dXQgYQ0KPj4gbW9kaWZpZWQgZHJhZnQgdGhhdCBiZXR0ZXIgZXhwbGFpbnMgdGhhdCwgYWZ0ZXIg d2hpY2ggd2UgY2FuIGRvIHRoZQ0KPj4gZG9jdW1lbnQgd3JpdGUgdXAgYW5kIHNoaXAgaXQuDQo+ PiANCj4+IENpYW8hDQo+PiAtLSBKYWltZQ0KPj4gDQo+PiANCj4+PiBPbiBUdWUsIEphbiAyMSwg MjAyMCBhdCAxMTozNTo0N0FNICswMjAwLCBKYWltZSBKaW1lbmV6IHdyb3RlOg0KPj4+IFNlbmRp bmcgaXQgdG8gdGhlIGNvcmUgdGhyZWFkLiANCj4+PiANCj4+PiAtLSANCj4+PiBKYWltZSBKaW3D qW5leg0KPj4+IA0KPj4+IE9uIE1vbiwgSmFuIDIwLCAyMDIwLCBhdCA2OjEwIFBNLCBKYWltZSBK aW1lbmV6IHdyb3RlOg0KPj4+PiBIaSwNCj4+Pj4gDQo+Pj4+IGNvbW1lbnRzIGJlbG93LiANCj4+ Pj4gDQo+Pj4+IE9uIEZyaSwgRGVjIDEzLCAyMDE5IGF0IDExOjI3OjM0QU0gLTA3MDAsIEN1bGxl biBKZW5uaW5ncyB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gT24gRGVjIDksIDIwMTks IGF0IDM6NDIgUE0sIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPiB3cm90ZToNCj4+Pj4+ PiANCj4+Pj4+PiANCj4+Pj4+PiBDb25jZXJucyBoYWQgYmVlbiByYWlzZWQgYWJvdXQgb3Blbmlu ZyB1cCB0aGUgc2Vjb25kIHJlZ2lzdHJ5IGZvcg0KPj4+Pj4+IGRlcml2ZWQgdW5pdHMsIG1ha2lu ZyBpdCBoYXJkZXIgZm9yIGEgU2VuTUwgYXBwbGljYXRpb24gdG8gZmluZCBvdXQNCj4+Pj4+PiB3 aGV0aGVyIGEgdW5pdCBlbmNvdW50ZXJlZCB3YXMgYWN0dWFsbHkgb2YgaW50ZXJlc3QgdG8gaXQu DQo+Pj4+Pj4gRGlzY3Vzc2lvbiBpbiB0aGUgZmlyc3Qgc2Vzc2lvbiByZXN1bHRlZCBpbiB0aGUg dGVudGF0aXZlIHByb3Bvc2FsDQo+Pj4+Pj4gdG8gbWFyayBzZWNvbmRhcnkgdW5pdHMgd2l0aCBh biBhc3RlcmlzayAoYXMgaW4gIiprbS9oIiwgYXMgb3Bwb3NlZA0KPj4+Pj4+IHRvIHVubWFya2Vk ICJtL3MiKS4gIEZ1cnRoZXIgZGlzY3Vzc2lvbiBpbiB0aGUgc2Vjb25kIHNlc3Npb24gbWFkZQ0K Pj4+Pj4+IGNsZWFyIHRoYXQgd2hpbGUgdGhpcyBtYWtlcyB0aGUgdXNlIG9mIHNlY29uZGFyeSB1 bml0cyBzdGFuZCBvdXQsIGl0DQo+Pj4+Pj4gZG9lcyBub3QgcmVhbGx5IGltcHJvdmUgdGhlIHNp dHVhdGlvbiBvZiBTZW5NTCBhcHBsaWNhdGlvbnMgdGhhdA0KPj4+Pj4+IHdhbnQgdG8gcXVpY2ts eSBkaXNjYXJkIG1lYXN1cmVtZW50cyBmb3IgdW5pdHMgdGhleSBkbyBub3QgY2FyZQ0KPj4+Pj4+ IGFib3V0LCB1bmxlc3MgdGhleSB0cmFjayB0aGUgY29udGVudHMgb2YgdGhlIHR3byByZWdpc3Ry aWVzLCB3aGljaA0KPj4+Pj4+IHdvdWxkIG1ha2UgdGhlIGFzdGVyaXNrcyByZWR1bmRhbnQuDQo+ Pj4+PiANCj4+Pj4+IEkgZGlzYWdyZWUgdGhhdCB0aGUgYXN0ZXJpc2sgZG9lcyBub3QgaW1wcm92 ZSB0aGUgc2l0dWF0aW9uDQo+Pj4+PiANCj4+Pj4+PiBUaGVyZSBhbHNvIHdhcyBzb21lIGZlZWRi YWNrDQo+Pj4+Pj4gdGhlIGFzdGVyaXNrcyB3b3VsZCBtYWtlIHRoZSBhZG9wdGlvbiBvZiB0aGUg U2VuTUwgdW5pdHMgcmVnaXN0cnkgYnkNCj4+Pj4+PiBvdGhlciBTRE9zIG1vcmUgZGlmZmljdWx0 LiAgVGhlIGluLXJvb20gY29uc2Vuc3VzIG5vdCB0byBnbyBmb3IgdGhlDQo+Pj4+Pj4gYXN0ZXJp c2tzLCBidXQgdG8gaW5jbHVkZSBtb3JlIGV4cGxhbmF0b3J5IHRleHQgYWJvdXQgaW1wbGVtZW50 YXRpb24NCj4+Pj4+PiBzdHJhdGVnaWVzLCBuZWVkcyB0byBjb25maXJtZWQgb24gdGhlIG1haWxp bmcgbGlzdC4gIA0KPj4+Pj4gDQo+Pj4+PiBJIHN0cm9uZ2x5IG9iamVjdCB0byB0aGlzLiAgUkZD IDg0MjggaGFzIGEgc3Ryb25nIGFzc2VydGlvbiB0aGF0IHRoZSB1bml0cyANCj4+Pj4+IA0KPj4+ Pj4gICAgICAgRm9yIGEgZ2l2ZW4gdHlwZSBvZiBtZWFzdXJlbWVudCwgdGhlcmUgd2lsbCBvbmx5 IGJlIG9uZSB1bml0DQo+Pj4+PiAgICAgICB0eXBlIGRlZmluZWQuICBTbyBmb3IgbGVuZ3RoLCBt ZXRlcnMgYXJlIGRlZmluZWQgYW5kIG90aGVyDQo+Pj4+PiAgICAgICBsZW5ndGhzIHN1Y2ggYXMg bWlsZSwgZm9vdCwgbGlnaHQgeWVhciBhcmUgbm90IGFsbG93ZWQuICBGb3INCj4+Pj4+ICAgICAg IG1vc3QgY2FzZXMsIHRoZSBTSSB1bml0IGlzIHByZWZlcnJlZC4NCj4+Pj4+IFRoZXJlIGlzIHJ1 bm5pbmcgY29kZSB0aGF0IGlzIGJhc2VkIG9uIHRoYXQgYXNzdW1wdGlvbiB0aGF0IGhhcyBiZWVu IGluIHByb2R1Y3Rpb24gZm9yIG1hbnkgeWVhcnMuIFlvdSBjYW7igJl0IGJyZWFrIHRoYXQgYXNz dW1wdGlvbiB3aXRob3V0IHNvbWUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgY29uc2lkZXJhdGlv biB0aGF0IGhlbHAgdGhlc2VzIGRlcGxveWVkIGFwcGxpY2F0aW9ucyBtaXRpZ2F0ZSB0aGUgYnJl YWthZ2UgdGhpcyBjYXVzZXMuDQo+Pj4+IA0KPj4+PiBJIGJlbGlldmUgdGhhdCB0aGUgYXNzdW1w dGlvbiBvZiBoYXZpbmcgb25seSBvbmUgdW5pdCBwZXIgbWVhc3VyZW1lbnQNCj4+Pj4gd2FzIGJy b2tlbiBhbHJlYWR5IHdpdGggY29yZS1zZW5tbC1tb3JlLXVuaXRzIGFzIGl0IGNyZWF0ZXMgdGhl DQo+Pj4+IHNlY29uZGFyeSByZWdpc3RyeS4gU28gdGhlIGFzdGVyaXNrIGRvZXMgbm90IGZpeCB0 aGF0LiAgDQo+Pj4+IA0KPj4+Pj4gVGhlIGlkZWFzIHRoYXQgbWlsbGlvbnMgb2YgZWRnZSBhZ2dy ZWdhdGlvbiBkZXZpY2VzLCBtYW55IG9uIGZhciBzaWRlIG9mIHNsb3cgbGlua3MsIHdvdWxkIHF1 ZXJ5IHRoZSBJQU5BIHdlYiBzZXJ2ZXIgdG8gdHJhY2sgdGhlIHVuaXRzIGFuZCBkZWNpZGUgaG93 IHRvIHByb2Nlc3MgZGF0YSBzZWVtcyBsaWtlIGEgdmVyeSBiYWQgZGVzaWduLiBJIHdvdWxkIGV4 cGVjdCB0aGUgSUVTRyB0byByZWplY3QgYW55dGhpbmcgdGhhdCBsZWFkIHRvIGNhc2VzIGxpa2Ug aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvTlRQX3NlcnZlcl9taXN1c2VfYW5kX2FidXNl IDxodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9OVFBfc2VydmVyX21pc3VzZV9hbmRfYWJ1 c2U+DQo+Pj4+PiANCj4+Pj4gDQo+Pj4+IEkgYWxzbyBkbyBub3Qgc2VlIGhvdyB0aGUgYXN0ZXJp c2sgd291bGQgbWFrZSBwYXJzaW5nIGVhc2llci4gSWYNCj4+Pj4gZXhpc3RpbmcgZWRnZSBkZXZp Y2VzIGFyZSBoYXJkY29kZWQgdG8gdXNlIGEgc3Vic2V0IG9mIGFsbCB1bml0cyAtanVzdA0KPj4+ PiB0aGUgcHJpbWFyeSBzZW5tbCByZWdpc3RyeS0gdGhlbiB0aGV5IHdvdWxkIGZpbHRlciBtZXNz YWdlcyBjb250YWluaW5nDQo+Pj4+IGFueSB1bml0IHRoZXkgZG8gbm90IHVuZGVyc3RhbmQgYW55 d2F5cy4NCj4+Pj4gDQo+Pj4+IEFsc28gdGhlIGFzdGVyaXNrIGRvZXMgbm90IHRlbGwgYW4gYXBw bGljYXRpb24gcHJvY2Vzc2luZyBhIHNwZWNpZmljDQo+Pj4+IG1lYXN1cmVtZW50IChlLmcuLCB0 ZW1wZXJhdHVyZSBpbiBjZWxzaXVzKSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0DQo+Pj4+ IHRoZSB1bml0IChlLmcuLCBJIGFtIHRlbXBlcmF0dXJlIGluIGZhaHJlbmhlaXQsIHRoaXMgaXMg aW1wb3J0YW50KQ0KPj4+PiBpbmRpY2F0aW5nIHRoYXQgdGhpcyBuZXcgdW5pdCAgaXMgc29tZXRo aW5nIGl0IHNob3VsZCBwcm9jZXNzLCBpdCBvbmx5IGluZGljYXRlcw0KPj4+PiB0aGF0IGl0IGlz IHBhcnQgb2YgdGhlIHNlY29uZGFyeSByZWdpc3RyeS4NCj4+Pj4gDQo+Pj4+IFJlZ2FyZGluZyB0 aGUgcXVlcnlpbmcgb2YgdGhlIHNlbm1sIHJlZ2lzdHJ5LCBJIHRoaW5rIHRoYXQgd291bGQgaGF2 ZSB0bw0KPj4+PiBoYXBwZW4gYW55d2F5cywgYXMgbmV3IHVuaXRzIHdpbGwgYmUgcmVnaXN0ZXJl ZCBvdmVyIHRpbWUsIGV2ZW4gaWYgbm90DQo+Pj4+IHZlcnkgb2Z0ZW4uIA0KPj4+PiANCj4+Pj4g SSB0aGluayB0aGUgcmVhbCBpc3N1ZSBoZXJlIGlzIHdoZXRoZXIgdG8gc2lnbmFsICJ0aGlzIHVu aXQgYmVsb25ncyB0byBhDQo+Pj4+IHNlY29uZGFyeSByZWdpc3RyeSwgbm90IHRoZSBtYWluIG9u ZSIgb3Igbm90LiBGbGFnZ2luZyBhIHVuaXQgd2l0aCAiKiIgb3INCj4+Pj4gaGF2aW5nIGEgZGlm ZmVyZW50IGZpZWxkIGxpa2UgInUyIiBjYW4gY29uZnVzZSBkZXZlbG9wZXJzIHVubmVjZXNzYXJp bHksIA0KPj4+PiBhcyB0aGV5IGRvIG5vdCBuZWVkIHRvIGtub3cgYWJvdXQgaGlzdG9yaWNhbCBz dGFuZGFyZCBkZWNpc2lvbnMuIEl0J3MNCj4+Pj4gbW9yZSBvZiBhIHBlbmFsdHkgdG8gdGhvc2Ug dXNpbmcgaXQgOkQgDQo+Pj4+IA0KPj4+PiBBbmQgaWYgeW91IHdhbnQgdG8gY29udmV5IHRoYXQg dGhlIHNlY29uZGFyeSByZWdpc3RyeSBpcyBub3QgdGhlDQo+Pj4+IHByZWZlcnJlZCBvbmUsIHRo ZW4gSSB0aGluayB0aGF0IGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBiZSBvbiB0aGUNCj4+Pj4g ZHJhZnQgaXRzZWxmLCByaWdodD8gV2l0aCB2ZXJ5IHN0cm9uZyB3b3JkaW5nIGFuZCBzbyBvbiwg YnV0IG5vdCBvbiB0aGUNCj4+Pj4gd2lyZSBpbiBhIHNlbm1sIHJlY29yZC4gDQo+Pj4+IA0KPj4+ Pj4gDQo+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pj4+IGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4+PiBjb3JlQGlldGYub3JnDQo+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4+Pj4gDQo+ Pj4+IA0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4gY29yZSBtYWlsaW5nIGxpc3QNCj4+PiBjb3JlQGlldGYub3JnDQo+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlz dA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY29yZQ0K --Apple-Mail-BC8110B5-244A-401A-8458-6B9C1BB6F3F6 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDMAw ggX2MIID3qADAgECAhA3E3FzLlznzicd63Rv9v4YMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMDQxNDEzNDRaFw0yMDEyMDQxNDEzNDNaMGUxETAPBgNVBAoMCEVyaWNzc29u MRUwEwYDVQQDDAxBcmkgS2Vyw6RuZW4xJzAlBgkqhkiG9w0BCQEWGGFyaS5rZXJhbmVuQGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWFyaWtlcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AIUlV66I5z1/qGYdhiIGfyvv8aaZexDetFCPlauUh5ugtp7Pf7ynpPRIK1FeWaoKs+IJ3E9R/9wT APFzjzjXpjyHHoBUdp8ZBuL/kt60cUTHTD4AScJGUHEgy70/Uf2YEj3JJjrTBbFnqDcXWTFF1n2Y edmhZDBdzZQJ18tlIjJmxgAJB1clI0nEg1gBnhl8mVdQp+ar6GjvxXfRuA1+uOpxa3y4zUpzF+ha LmaC4a5AbOsROtr7Uad8/pCzulAvAmPXvEJ/3JusafQfiqxNv1J/fT6W7sS8dBjF6vv3LgeAnYj5 /imtl9BOurFol0aIic+AjptfNoVf2pDhgYxn808CAwEAAaOCAb4wggG6MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCMGA1UdEQQcMBqBGGFyaS5rZXJhbmVuQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYB BQUHAwIwHQYDVR0OBBYEFNHQXDyNP/SSyF6+EMLvo07phb3FMB8GA1UdIwQYMBaAFBx7GZ6XnHas ID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAVVggYWTwdz5B iMeBRYLop6Jo3Ji9YmfonCRFiyfw8he+efYc59IwzU9eIBRFSiWf87eqcZZJjcwWjHuju3MvzWsp 1qHnirszOtcNrUflFBoY7N3r19tG+z2bE/bjjZPituSIgCoX28IgLZLpIcnYg7niWXnwR3xGiphs EPO3mR3p7f+XLtdy+1qU/rAjZoW36mZuYk1lV6nIt9GfhuH1/yIQd5pxTDj54j3TOLv/KrEKwCFQ YLkho6zrOicpJk7DkjYGNLwmaDTRxuehMQHKDW+fXi1xi7/eScV0YnELjxXGuE3HojEkLB8Offfa /5TICfBN2HTASXJ0YsbpnAxPTyjExmKzl3mudQz6x5wP6THhM0sltX8wHVQEhU5w0uyLfT9yqWVY KTq+9GI02S9kzD+u1AWtftbWK2CQIGUAE43faZGrCchkT+fnYz5b1Ppyf5H45r/psmsA9J63iFCz nilKlo9M47fQPEsqpFWvDfE4jdobqSmQXp/aK7cvYoAEhcj5vOqR/bPNum7wWegQZdDsfy35vZl8 +vtRrKAk/6bmUfaiazqQoGq+DF1OL7sQlb1HbMmkJblrrBf8Csh6wdEVFey6vegBSIwtOnmcAFN9 2NlKp24f8rJxM17M9pWNG6OsmCGhxyo4k1BHn69nXXQfSN7QdqLpGfhQfpJL3LgwggbCMIIEqqAD AgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29u ZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1 MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3Q3cY VVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldkUgUg MKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZYzwN v/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKHMgZq QvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6kmH/ KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup5dpX bxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS3b6O Moc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOq QFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3Nw LnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1 c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYB Af8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9y ZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0 cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQc exmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkq hkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bO ULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9jWQk MrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/ajdbiR sehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzICfsSr Z4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZcdAOZ oviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBdLoo4 gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTomgCF z/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJzqgb 8ToH7WLoOzmPRCmPlpAxggLNMIICyQIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQNxNxcy5c584nHet0 b/b+GDANBglghkgBZQMEAgEFAKCCAUMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMjAwMjExMjExMjUwWjAvBgkqhkiG9w0BCQQxIgQg8zQHrQ50esgD/FYPcxf+Njep XO0Uhug8lkYr+u7NNNYwagYJKwYBBAGCNxAEMV0wWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEDcTcXMuXOfO Jx3rdG/2/hgwbAYLKoZIhvcNAQkQAgsxXaBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQNxNxcy5c584nHet0 b/b+GDANBgkqhkiG9w0BAQEFAASCAQBciDX/FCDOzzLtBfjaojucjPNOsyntxDHuIp3+sWEG0I2g tCTE2eFYFB4+pGTBvccTWFUR6hjNkYfAGl8d2IaxRWAx/PVXSRmH5j+m7yHHiDXBiyJART08tDWJ A2Y4ZC1ZJ4WQkhJfTCkeRdrXzZorV/D0fo13vAwLhqf8mtAI9Zwq7eEYI0ccYZcTYxcVGUrPpBAG PEJLPLxJVM0/dudq0WOzWozVL7rZLTD8Rq9nyFSng0fCV9MPk7nm4/Mi4V/55slJWnmvmnSm6wuJ DE2kMeJKj8i/uiSpY+ot2tWoyIpIBxxwTc8IhkiIpavengXjJXMURkIXLqAXDbQmU7XSAAAAAAAA --Apple-Mail-BC8110B5-244A-401A-8458-6B9C1BB6F3F6-- From nobody Wed Feb 12 06:53:47 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA5E1200C3; Wed, 12 Feb 2020 06:53:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <158151922255.18124.16288065902707911532@ietfa.amsl.com> Date: Wed, 12 Feb 2020 06:53:42 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 14:53:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : YANG Schema Item iDentifier (SID) Authors : Michel Veillette Alexander Pelov Ivaylo Petrov Filename : draft-ietf-core-sid-10.txt Pages : 33 Date : 2020-02-12 Abstract: YANG Schema Item iDentifiers (SID) are globally unique 63-bit unsigned integers used to identify YANG items. This document defines the semantics, the registration, and assignment processes of SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned SIDs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-sid-10 https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 12 07:03:53 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6C71200A3 for ; Wed, 12 Feb 2020 07:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxTl7TDFcmUI for ; Wed, 12 Feb 2020 07:03:48 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 0393A120048 for ; Wed, 12 Feb 2020 07:03:48 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id y17so2768467wrh.5 for ; Wed, 12 Feb 2020 07:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IevCw6wKd/hzVWzc4Nq3vkCYjwK4gJhI54kmpByUlSU=; b=evkEJFO3LCAigkaDZ3I1cIw1uB0yFnNPK0IbKcIRdA7bnuOgbcj+4XZbasTg/a8uQE FHsgdpeh0wR3AsmuBIPhgAYH+v6FUbm8byv8FWBYAtRK0Nd2k6/9i3OjY0e44Bd7A/8M fi30NKGlmxnaNkpkXMoNFnVYX3KvKC809ZIgA7aA0zZ9/mYpMKLPre/ToXhu7csvobAx KSxhebavsI6uYMJFdYAwa62OWGApWpaR8zLYoRqtaqHFwGEw+okYyTUSQeLrnnIi/Zb4 dVJ3OxmS8tMeCJ+lSfLVYfDzWn9zeWrNLY6b/2idusln72p0nyIESyORcz5QqjZfqcVF DAow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IevCw6wKd/hzVWzc4Nq3vkCYjwK4gJhI54kmpByUlSU=; b=o59XtyjDE3YnjAX4tU++HK8aX78n6RY4y1bg5eYXTnrgP5BtDDREtv19uapnhqa1Jg 1LFmQYb0ia0Z1kz9xFqbAf7ENM5uYxVK6Ixu9N2jNi8wHXgsB3KeX8+GBWjxCujj6hYR 9OfIg2+KG6Ua2WdEWNkONlEQf5otfI8I68Ieeecyl4Va/pTg0N/y5igI86BshY4J4gE6 hoMTQkyZxOdq6aH1lUGBpxjIfvRgftOTILe1evGtefYj00rqeu1eDo3Dlu3VAMimi+JV YIaldr7RGFlQwvf/bHRgFy7Qlh4/4bIFkUfzOqkKrtQgEFxAfjpTPM5gMeSyexOuHdVv hXPA== X-Gm-Message-State: APjAAAW7nYnRdLbIMTmitxj+HKbY0sL5pi33u5hXYBSnXPrDuO/FrZi6 3HUuF17d6FqoBDdOXcbjGMPZULc78mBEMFbHVGcc9g0z X-Google-Smtp-Source: APXvYqwbH/OHQjz2K2hkD0MvDYLWzOc+muih6gkrrB88D1SSaN+TV6cpjOUxsSXSGWvjKR+1Yf/UysBWPjt0NjHfd70= X-Received: by 2002:a05:6000:12c7:: with SMTP id l7mr14930578wrx.136.1581519825871; Wed, 12 Feb 2020 07:03:45 -0800 (PST) MIME-Version: 1.0 References: <158151922293.18124.16532089945914076050.idtracker@ietfa.amsl.com> In-Reply-To: <158151922293.18124.16532089945914076050.idtracker@ietfa.amsl.com> From: Ivaylo Petrov Date: Wed, 12 Feb 2020 16:03:19 +0100 Message-ID: To: core Content-Type: multipart/alternative; boundary="0000000000006d3b1f059e6247de" Archived-At: Subject: [core] Fwd: New Version Notification for draft-ietf-core-sid-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 15:03:51 -0000 --0000000000006d3b1f059e6247de Content-Type: text/plain; charset="UTF-8" Dear all, In the latest version I believe we have addressed Andy's comments regarding .sid file versioning. I consider this to be the last comment that was still pending before we can go for a working group last call for the sid draft and the cluster of drafts known as CORECONF in general. Please let us know if there are still points that you consider should be handled before the WGLC. In the absence of further comments, I would like to ask the working group chairs to consider going for a last call. Thank you in advance! Best regards, Ivaylo ---------- Forwarded message --------- From: Date: Wed, Feb 12, 2020 at 3:53 PM Subject: New Version Notification for draft-ietf-core-sid-10.txt To: Ivaylo Petrov , Alexander Pelov , Michel Veillette A new version of I-D, draft-ietf-core-sid-10.txt has been successfully submitted by Ivaylo Petrov and posted to the IETF repository. Name: draft-ietf-core-sid Revision: 10 Title: YANG Schema Item iDentifier (SID) Document date: 2020-02-12 Group: core Pages: 33 URL: https://www.ietf.org/internet-drafts/draft-ietf-core-sid-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ Htmlized: https://tools.ietf.org/html/draft-ietf-core-sid-10 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-core-sid Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-10 Abstract: YANG Schema Item iDentifiers (SID) are globally unique 63-bit unsigned integers used to identify YANG items. This document defines the semantics, the registration, and assignment processes of SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned SIDs. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000006d3b1f059e6247de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

In the= latest version I believe we have addressed Andy's comments regarding .= sid file versioning. I consider this to be=C2=A0the last comment that was s= till pending before we can go for a working group last call for the sid dra= ft and the cluster of drafts known as CORECONF in general. Please let us kn= ow if there are still points that you consider should be handled before the= WGLC. In the absence of further comments, I would like to ask the working = group chairs to consider going for a last call.

Thank you in advance!

Best regards,<= /div>
Ivaylo
<= div dir=3D"ltr">
=

--------= -- Forwarded message ---------
From: <internet-drafts@ietf.org<= /a>>
Date: Wed, Feb 12, 2020 at 3:53 PM
Subject: New Versio= n Notification for draft-ietf-core-sid-10.txt
To: Ivaylo Petrov <ivaylo@ackl.io>, Ale= xander Pelov <a@ackl.io>, Michel Veillette <michel.veillette@trilliant.com>

<= br>
A new version of I-D, draft-ietf-core-sid-10.txt
has been successfully submitted by Ivaylo Petrov and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-core-sid
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A010
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 YANG Schema Item iDentifier (SID)<= br> Document date:=C2=A0 2020-02-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 core
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 33
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-core-sid-10.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/draft-ietf-core-sid/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.= ietf.org/html/draft-ietf-core-sid-10
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/html/draft-ietf-core-sid
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-sid-10

Abstract:
=C2=A0 =C2=A0YANG Schema Item iDentifiers (SID) are globally unique 63-bit<= br> =C2=A0 =C2=A0unsigned integers used to identify YANG items.=C2=A0 This docu= ment defines
=C2=A0 =C2=A0the semantics, the registration, and assignment processes of S= IDs.
=C2=A0 =C2=A0To enable the implementation of these processes, this document= also
=C2=A0 =C2=A0defines a file format used to persist and publish assigned SID= s.




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

The IETF Secretariat

--0000000000006d3b1f059e6247de-- From nobody Thu Feb 13 15:19:34 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4960812026E; Thu, 13 Feb 2020 15:19:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime@iki.fi, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158163597329.20645.17157404867852325414.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2020 15:19:33 -0800 Archived-At: Subject: [core] Barry Leiba's Yes on draft-ietf-core-senml-more-units-04: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 23:19:33 -0000 Barry Leiba has entered the following ballot position for draft-ietf-core-senml-more-units-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- You have a typo in section 4: "obove", where "above" is meant. From nobody Mon Feb 17 18:20:25 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6C1120043; Sun, 16 Feb 2020 13:56:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime@iki.fi, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158189016668.5801.9076714957132086502.idtracker@ietfa.amsl.com> Date: Sun, 16 Feb 2020 13:56:06 -0800 Archived-At: Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-senml-more-units-04=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2020 21:56:07 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-core-senml-more-units-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Short, simple, and easy to read while being useful. Just a nit, please use a section on its own for acknowledgments (at least the HTML version does not show it was a section) Thank you for the time writing this doc -éric From nobody Mon Feb 17 18:21:34 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D9012002E; Sun, 16 Feb 2020 14:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIpgcw3kM-DK; Sun, 16 Feb 2020 14:38:31 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24ECD120043; Sun, 16 Feb 2020 14:38:31 -0800 (PST) Received: from [172.18.209.113] (unknown [46.183.103.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48LMTb5Kttz11by; Sun, 16 Feb 2020 23:38:27 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <158189016668.5801.9076714957132086502.idtracker@ietfa.amsl.com> Date: Sun, 16 Feb 2020 23:38:26 +0100 Cc: The IESG , draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 603585506.381116-1469c381b1f56e285735b31fc8b56652 Content-Transfer-Encoding: quoted-printable Message-Id: <1155B948-D11C-48A7-9EB3-F340306B0688@tzi.org> References: <158189016668.5801.9076714957132086502.idtracker@ietfa.amsl.com> To: =?utf-8?Q?=C3=89ric_Vyncke?= X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-senml-more-units-04=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2020 22:38:34 -0000 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Short, simple, and easy to read while being useful. Thank you. > Just a nit, please use a section on its own for acknowledgments (at = least the > HTML version does not show it was a section) Interesting. As per RFC 7322, this is an unnumbered section, but I = neglected to move it into the appendix, so the tools intersperse the = (numbered) References section. I didn=E2=80=99t even know that XML2RFC = allows mixing numbered and unnumbered sections=E2=80=A6 Fixed in = https://github.com/core-wg/senml-more-units/commit/8db245d4483fcda38dcfd04= 3e047238401fea178 Gr=C3=BC=C3=9Fe, Carsten > Thank you for the time writing this doc >=20 > -=C3=A9ric >=20 >=20 From nobody Mon Feb 17 18:38:44 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C840120018; Mon, 17 Feb 2020 07:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=O7gjq992; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ObW5ubdW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILr4FTTsYfsn; Mon, 17 Feb 2020 07:48:14 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0AB120072; Mon, 17 Feb 2020 07:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12431; q=dns/txt; s=iport; t=1581954494; x=1583164094; h=from:to:subject:date:message-id:mime-version; bh=Moc1rvc34KnOxAObMOqbXTiDMklkT2QaANTx9iF64sU=; b=O7gjq992Y+saoXF6AdypVUh+5jwD6bNJHpGsw/USqjQuCMvWrZmQrVo5 DHD0VwZfspg2Ezq7AXoKH16GXYk5cKCmnDz52pek2dUFT9c7iS18fLMGz hOVcIDBqW+voyODpOYcRZ0V+r3CBvNXVbo7RDsDH0amZ4KMfj2objWcg2 g=; IronPort-PHdr: =?us-ascii?q?9a23=3Az21aSRGGQ9wrzdxUlORKqZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeT1bigmG8JqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBGACGtUpe/5FdJa1mHgELHIMgL1A?= =?us-ascii?q?FbFggBAsqCodQA4p6TpVBhGGCUgNUCQEBAQwBAS0CBAEBhEACggQkOBMCAw0?= =?us-ascii?q?BAQUBAQECAQUEbYU3DIV5BhsTAQE4EQGBACYBBAEaGoMFgX1NAy4BAqEWAoE?= =?us-ascii?q?5iGKCJ4J/AQEFhQ8YggwJgTiMJBqBQT+BWIdXg0CCLJZGmTwKgjqWb5sajmm?= =?us-ascii?q?bMQIEAgQFAg4BAQWBaSKBWHAVGoMNUBgNjh2Dc4pTdIEpjGcBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,453,1574121600"; d="scan'208,217";a="430836072" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Feb 2020 15:48:11 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 01HFmBMM031819 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Feb 2020 15:48:11 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Feb 2020 09:48:10 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Feb 2020 10:48:09 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 17 Feb 2020 10:48:09 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ScY51JBuHB5EXU3YlVsDa4ty+PO/03IZLPmB+Cz+arUt4fXlIjmc3gMkiUheeUxyGUjMnNqLaIsxMRhJCSjqM5mh/nkJ3CGR17SDXpoyxYiyfzuuz2q/51NP438Uy23ETEa5K8BoWA3I3vPHncb0/Jc/dedHwW3n06uRbZN6FU8wovCZ2NWo3PiixNpA/BXutZYkoMSl0+BRMVRjQNwJ7LNd4znqLRRwKCqNSZ1N8PD8CqlLeJFG+iLA8aFytexVf8VuotCcoT2ih8C8E9hBGVBkHQ9n2u0UDKyheVwZ8YLMZhDMmt6T2nvK6DoqdTVL1gcW531tW1OCrLPabdSNpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vB4yVMl00b9RhnvZu3OT52qeOT369NyzrWkcqRKLoXk=; b=U0RAbJIKvI3YkUMzea89BlOZv/aSpUEs8MxojiVkXL2tX+4qxHRaNgMDommqsS58zgwd21d5No/nPKsIP8BmEfXDYqqizb5/6yYHWitW0s44K4ZFx4v58UE6CtUly7ZLUS9gerHcKZr5LYjQh13MxUR1xr4V6I/v8OAW480Fu11HsiXB00ESlTdpt6Wp5DMw+1ddRZx1+YX/S1E63ytRh7Y4JhHlq3CYlf2Hx5cZHVZE29TgeLoOnVAICdItZD/XHws16EWHdRTGZE5wM8zmThAdG6frMGUnmw4J+KPCVIKtJYOl9+K2yuVSOER1zbQRPujgLpbesCL2Xxz9bSxUEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vB4yVMl00b9RhnvZu3OT52qeOT369NyzrWkcqRKLoXk=; b=ObW5ubdWb5TPXsYUyZLuhb3xV/WnNYGXFgp3ySlzMQxPn8dFPDI/gpWXCvX6EBdR9i3d0oDiSf5DWu8Qw2L+aasjL4ainESzag5FJYe/E8ej5ITAB/+kKEo8yvNQD55TGCJYCNHoN59fbiqEM0Lsli3RCOEVcGaQcGYCUZF2vMA= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4046.namprd11.prod.outlook.com (20.179.151.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.25; Mon, 17 Feb 2020 15:48:08 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2729.031; Mon, 17 Feb 2020 15:48:08 +0000 From: "Rob Wilton (rwilton)" To: "core@ietf.org" , "core-chairs@ietf.org" , The IESG , "draft-ietf-core-senml-more-units@ietf.org" Thread-Topic: RobW comments on draft-ietf-core-senml-more-units-04 Thread-Index: AdXlqZeHMIQG61iWSRmLAl4AWyIkfw== Date: Mon, 17 Feb 2020 15:48:08 +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=rwilton@cisco.com; x-originating-ip: [173.38.220.42] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e3ce6066-d8b1-4c6e-5a15-08d7b3c0c90b x-ms-traffictypediagnostic: MN2PR11MB4046: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0316567485 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(366004)(376002)(136003)(396003)(189003)(199004)(186003)(9686003)(316002)(55016002)(8676002)(2906002)(86362001)(71200400001)(8936002)(110136005)(6506007)(26005)(7696005)(33656002)(9326002)(450100002)(52536014)(478600001)(76116006)(66946007)(66476007)(66556008)(81166006)(81156014)(5660300002)(64756008)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4046; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dDmm1rGG6T3d7bo4CP3wx44tVwaAUybm4+cYcUjTWCzCk014L7SOiUyeiRPTxDqIRxQTQQXAv0a/PxO2xGplS3tNO82oxgE1GzgiUellN6DjriR5gPmVqYeigkpIpGxMJrESoZQ6PDdpw1PshEol8qYlYlu1EZ89dld1g+btJw6KXp7WnimH9SDAjl2lZ4im82kXqR0V1TdGV/PvYqLdxJTJZ7fO3Mm+WTeGjrSSZfSXdTV8LhOQ7O8KP4x4ro2GgzdPznzN8iL7pdtirBOZyqEqExC+4n5HQW9r9yOIyw3sjZ6xemRvQPlBC+zB9jW/HmcojrVAOQSDmeSJde6piy1NtfPwIIZYLEsmHUs+NWhJF+lfYvE/v8p+uDMM2PHEK4YDjL0ff/fUtEeBUECEtPaf/ED+mj8wqnZx8j6UpN2BMgXq3R5K+5SQeOuSHWCu x-ms-exchange-antispam-messagedata: M/JoJhNMGvXIUnDaozYiff/BYt+WN/EqWCpRxKRreo+4ifiAscT57OnGgrJ0HJTxah7oiY+Ki3GYNQ16AuZN7P4bk0mMIqgKmMlp5/YMQX2C+wBFTkfhGh00sb0zaK0nYaA/TvSYHKu48TOfhFG/BA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366F25989E1D4062BBFBA1AB5160MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e3ce6066-d8b1-4c6e-5a15-08d7b3c0c90b X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2020 15:48:08.2332 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hk0faFk9SaKla821g8CZN7Na2SCqsAIqmCeuKnjk7lGH5txVAe/eHG4xhejAD2wvjbiXY2kMrJy6K7jChkYPUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4046 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: [core] RobW comments on draft-ietf-core-senml-more-units-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 15:48:18 -0000 --_000_MN2PR11MB4366F25989E1D4062BBFBA1AB5160MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Carsten, I'm providing some comments as an incoming Ops and Mgmt AD. I found this document well written but think that it may be helpful to high= light the protocol usage of secondary units earlier in the document, i.e. i= n the introduction. My understanding is that this document introduces both extra primary unit n= ames, and also a new concept of secondary unit names, which I presume came = about from deployment considerations. Comments: 1. As per above, I think that it would be useful to add a comment in the= introduction about how secondary units could be used. E.g. may be extend "The document also defines a registry for secondary Unit names that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry." with the sentence "Although SenML version 10 [RFC8428] does not allow for t= he direct use of secondary units, they are planned to be supported via the = use of SenML protocol extensions, such as [I-D.bormann-core-senml-versions]= ." 1. The introduction introduces the term "primary Unit names", but then d= oesn't refer to them using this term in the rest of the document. It might= be helpful if the title of section 2 was changed from "New Units" to "New = primary Units", and the description could be changed from "... assign new u= nits ..." to "... assign new primary unit names ...". 1. My reading of the "3. Rationale" section is that it relates to the ne= w primary units, rather than secondary units. The structure of the documen= t might be clearer if this was made a subsection of the section 2 rather th= an its own top level section. 1. I would suggest renaming the section 4 title from "New Registry" to "= New Registry for Secondary Units". 1. Regarding section 4 on secondary units: * I observe that these are not using a generalized mechanism of usin= g SI prefixes for scaling, but propose a separate custom mapping instead, w= hich in some cases are just making use of SI prefixes. I presume that ther= e is a good reason for not wanting to generically use SI prefixes, perhaps = for a bit more homogeneity in the scaling factors, but it might be helpful = for the document to explain the rationale behind this. * I note that you have similar units but with different scaling fact= ors (e.g. KiB, GB, Mbit/s, MB/s). Do we anticipate other scaling factors o= f these units? E.g. if MB was requested as a secondary unit, then would th= at be added? Would it make sense to define any more of these common scalin= g factors now? * I also note that the names of some of the secondary units would ov= erlap with SI prefixes (e.g. "min") for minutes. This is okay, but would l= ikely be an annoyance if it was ever desirable to use SI prefixes in a gene= ric way. * I wasn't sure whether "h" is really a great shorthand for hour, I = would have gone for "hr" instead, but perhaps this is already widely used e= lsewhere? Regards, Rob --_000_MN2PR11MB4366F25989E1D4062BBFBA1AB5160MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Carsten,

 

I’m providing some comments as an incoming Ops= and Mgmt AD.

 

I found this document well written but think that it= may be helpful to highlight the protocol usage of secondary units earlier = in the document, i.e. in the introduction.

 

My understanding is that this document introduces bo= th extra primary unit names, and also a new concept of secondary unit names= , which I presume came about from deployment considerations.

 

Comments:

  1. As per above, I think that it would be useful to add a comment in the= introduction about how secondary units could be used.  E.g. may be ex= tend

 

“The document also defines a registry f= or secondary Unit names that

   cannot be in SenML's main regist= ry as they are derived by linear

   transformation from units alread= y in that registry.”

 

with the sentence “Although SenML versi= on 10 [RFC8428] does not allow for the direct use of secondary units, they = are planned to be supported via the use of SenML protocol extensions, such = as [I-D.bormann-core-senml-versions].”

 

  1. The introduction introduces the term “primary Unit names”= , but then doesn’t refer to them using this term in the rest of the d= ocument.  It might be helpful if the title of section 2 was changed from “New Units” to “New primary UnitsR= 21;, and the description could be changed from “… assign new un= its …” to “… assign new primary unit names …&= #8221;.

 

  1. My reading of the “3. Rationale” section is that it relat= es to the new primary units, rather than secondary units.  The structu= re of the document might be clearer if this was made a subsection of the section 2 rather than its own top level section.<= /o:p>

 

  1. I would suggest renaming the section 4 title from “New Registry= ” to “New Registry for Secondary Units”.
    2. <= /ol>

     

     

    1. Regarding section 4 on secondary units:
      1. I observe that these are not using a generalized mechanism of using S= I prefixes for scaling, but propose a separate custom mapping instead, whic= h in some cases are just making use of SI prefixes.  I presume that there is a good reason for not wantin= g to generically use SI prefixes, perhaps for a bit more homogeneity in the= scaling factors, but it might be helpful for the document to explain the r= ationale behind this.
      2. I note that you have similar u= nits but with different scaling factors (e.g. KiB, GB, Mbit/s, MB/s). = Do we anticipate other scaling factors of these units?  E.g. if MB wa= s requested as a secondary unit, then would that be added?  Would it make sense t= o define any more of these common scaling factors now?
      3. I also note that the names of some of the secondary units would overlap wi= th SI prefixes (e.g. “min”) for minutes.  This is okay, bu= t would likely be an annoyance if it was ever desirable to use SI prefixes in a generic way.
      4. I wasn’t s= ure whether “h” is really a great shorthand for hour, I would h= ave gone for “hr” instead, but perhaps this is already widely u= sed elsewhere?

     

    Regards,

    Rob

--_000_MN2PR11MB4366F25989E1D4062BBFBA1AB5160MN2PR11MB4366namp_-- From nobody Mon Feb 17 18:44:18 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E19120860 for ; Mon, 17 Feb 2020 10:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMfCfVLgOnYE for ; Mon, 17 Feb 2020 10:05:30 -0800 (PST) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 ACC4712008F for ; Mon, 17 Feb 2020 10:05:30 -0800 (PST) Received: by mail-yb1-xb29.google.com with SMTP id p123so9095134ybp.2 for ; Mon, 17 Feb 2020 10:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5obz3/AlAho5n4Y0jG68AUBkXwW20+dolEDiStH2RI4=; b=f8Gd0HOtsKpLZ8Ps+SIx0S/H3KbtKBf1Zv4LtIrbQGftyxjr+ynOEA4ghIUpLLbI3t +jEYlpfka79AnKem/xyz4l/PSVEg7Ky3PGkseWIHPpToa5/FbRlUB++UhxoW81ZA/ov1 D/sU20Eq+EQpSt7T2/1e0wAECWgFzju1fdQwrBKFR1V01bTRpHr3qN6pmnTwQ/uJQxap WVpixcK9K6WIv24w4TiVWNlhIJng+7XwQIaJLnbDaesydLlak4rW1K7hvToyGWRkoHlL KaJ00R/R2zWJdcprvFCkw7JWFJv33AYhIl34HeDoNAzvvihEnTJHgFV2fFx1pRjFwU+3 qV4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5obz3/AlAho5n4Y0jG68AUBkXwW20+dolEDiStH2RI4=; b=HREdV7xcf/n5OEUGfjxd1IVqjKkV1XGFidJVwzh+1fUW/LDw0+cl5N1cPhGHWKvSwU GWKd+MIYps+Z6PsWHqF5BAh73iGr0aNdWQ8+wmKS/K+RZETt9W+luBCXfikCxSnp6CeQ cGaQlgvxxFBwtkaMLRXWSHFGhEK4IISb/85Hr5/gXcd9ijeW/KX1v/XkLmFGct+UjLye h6mJxdExwSmv8fonPkDdSmN9AgDBODQPDF2Ee6U6hAl7UMnTfWJmrPe5Z8KymNobTZbe ZUvoSQOQC1Br7+Bvz3rmW59rlNr8gMrq4legftndy/agiyXgU3v/xOpgis/NuKn1haUM IrnQ== X-Gm-Message-State: APjAAAVmyQyVFKC0FYx81eZI6A/0hmtQR9AzVxPkwexoFO2eDkS8rVuF ERbqDODR3dhaE1/EDz9EDIaWYfDZf9VFSVw9U+7JEg== X-Google-Smtp-Source: APXvYqxG2KjzoIEMXdTbsy8JwHcGfhBp6qYDaqIqjgMD/wQ11Y5SXBgGP5DtQTLor757rT7b/6i8bpxaNc1qvNi8XWM= X-Received: by 2002:a25:1544:: with SMTP id 65mr14762859ybv.107.1581962729592; Mon, 17 Feb 2020 10:05:29 -0800 (PST) MIME-Version: 1.0 References: <158151922293.18124.16532089945914076050.idtracker@ietfa.amsl.com> In-Reply-To: From: Andy Bierman Date: Mon, 17 Feb 2020 10:05:18 -0800 Message-ID: To: Ivaylo Petrov Cc: core Content-Type: multipart/alternative; boundary="0000000000008bb7da059ec9669f" Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-ietf-core-sid-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 18:05:42 -0000 --0000000000008bb7da059ec9669f Content-Type: text/plain; charset="UTF-8" Hi, Here are my comments on draft-ietf-core-sid-10: sec 1: YANG modules, submodules and features * Should it be noted somewhere that these 3 constructs are numbered for YANG library purposes and are not used in protocol messages like the other constructs listed? sec 4: * The intro should contain a YANG Tree Diagram [RFC 8340] module: ietf-sid-file +--rw module-name? yang:yang-identifier +--rw module-revision? revision-identifier +--rw sid-file-version? sid-file-version-identifier +--rw dependencies-revisions* [module-name] | +--rw module-name yang:yang-identifier | +--rw module-revision revision-identifier +--rw assigment-ranges* [entry-point] | +--rw entry-point sid | +--rw size uint64 +--rw items* [namespace identifier] +--rw namespace enumeration +--rw identifier union +--rw sid sid * The SID file construct needs a wrapper container instead of 6 to-level data nodes. A yang-data extension (from ietf-restconf.yang in RFC 8040) should be used. There is an update to rc:yang-data, but it is not published yet. rc:yang-data sid-file { // all 6 fields defined here } * The IETF Trust Copyright is for 2016. There is probably a new template. * Nit: list names are usually singular (dependencies-revisions, assignment-ranges, items) * The description-stmt for assignment-ranges should be expanded: - specify that the SID range for each entry is SID entry-point to entry-point + (size - 1) - the SID ranges specified by all assignment-rages MUST NOT overlap * The type for /assignment-ranges/size should not allow zero-length ranges. s/uint64/uint64 { range 1..max; }/ sec 6.3.2 Allocation Policy * the range 1000 to 59,999 is rather small for the pool of all YANG modules published in RFCs. Likewise, 40K for all experimental numbers seems really small. The SID range is uint64 * Not sure these characterizations of small, medium, large are helpful. Also max allocation of 1000 seems rather arbitrary. Better to say requestors need to justify the size of each request. sec 6.4.2 Allocation Policy SIDs never change * The IETF has shown very little ability to get all the names and module structure correct on the first try. Or the first 15 tries. Modules get refactored and names get changed -- a lot. This statement is unclear. (SID 42 is always SID 42? Or do you mean SID assignments never change?) * This section should say that reassignment of SIDs within an allocated SID range MAY change during YANG module development. next section has text about this issue. 6.4.3 * Should an early allocation be given if the adopted module imports unadopted modules? This seems to force the WG to adopt or not use the allocated SID range * Not sure how to fix the following sentence, but maybe just remove it since it is unclear Critically, the original document should never get through the IETF process and then be surprised to be referencing a document whose progress is not certain. * Not sure what "expired" means. It means they are burned and never reallocated right? It would punish early adopters to do otherwise. Early Allocations are made with a one-year period, after which they are expired. Appendix A The example is rather long (8+ pages). Do not have a suggestion for a shorter module though Appendix B It should be stated that SID generation for RPC or action "input" and "output" schema nodes should always be done, even if no parameters are defined in the original RPC or action. Another module can augment these nodes (but cannot add "input" or "output" with augment). Andy On Wed, Feb 12, 2020 at 7:04 AM Ivaylo Petrov wrote: > Dear all, > > In the latest version I believe we have addressed Andy's comments > regarding .sid file versioning. I consider this to be the last comment that > was still pending before we can go for a working group last call for the > sid draft and the cluster of drafts known as CORECONF in general. Please > let us know if there are still points that you consider should be handled > before the WGLC. In the absence of further comments, I would like to ask > the working group chairs to consider going for a last call. > > Thank you in advance! > > Best regards, > Ivaylo > > > ---------- Forwarded message --------- > From: > Date: Wed, Feb 12, 2020 at 3:53 PM > Subject: New Version Notification for draft-ietf-core-sid-10.txt > To: Ivaylo Petrov , Alexander Pelov , Michel > Veillette > > > > A new version of I-D, draft-ietf-core-sid-10.txt > has been successfully submitted by Ivaylo Petrov and posted to the > IETF repository. > > Name: draft-ietf-core-sid > Revision: 10 > Title: YANG Schema Item iDentifier (SID) > Document date: 2020-02-12 > Group: core > Pages: 33 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-core-sid-10.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ > Htmlized: https://tools.ietf.org/html/draft-ietf-core-sid-10 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-core-sid > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-10 > > Abstract: > YANG Schema Item iDentifiers (SID) are globally unique 63-bit > unsigned integers used to identify YANG items. This document defines > the semantics, the registration, and assignment processes of SIDs. > To enable the implementation of these processes, this document also > defines a file format used to persist and publish assigned SIDs. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000008bb7da059ec9669f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Here are my commen= ts on=C2=A0draft-ietf-core-sid-10:

sec 1:=C2=A0=C2= =A0
      YANG modules, submodules an=
d features

* Should it be noted somewhere that these =C2=A03 constructs are num=
bered for YANG library
  purpos=
es and are not used in protocol messages like the other constructs listed?<=
/span>

sec 4:

<= /font>
* The intro should contain a YANG Tree Diagram [RFC 8340]

module: ietf-sid-file
=C2=
=A0 +--rw module-name? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang=
:yang-identifier
=C2=A0 +--rw module-revision? =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0revision-identifier
=C2=A0 +--rw sid-file-version? =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 sid-file-version-identifier
=C2=A0 +--rw dependencies-=
revisions* [module-name]
=C2=A0 | =C2=A0+--rw module-name =C2=A0 =C2=A0 =
=C2=A0 =C2=A0yang:yang-identifier
=C2=A0 | =C2=A0+--rw module-revision =
=C2=A0 =C2=A0revision-identifier
=C2=A0 +--rw assigment-ranges* [entry-p=
oint]
=C2=A0 | =C2=A0+--rw entry-point =C2=A0 =C2=A0sid
=C2=A0 | =C2=
=A0+--rw size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64
=C2=A0 +--rw ite=
ms* [namespace identifier]
=C2=A0 =C2=A0 =C2=A0+--rw namespace =C2=A0 =
=C2=A0 enumeration
=C2=A0 =C2=A0 =C2=A0+--rw identifier =C2=A0 =C2=A0uni=
on
=C2=A0 =C2=A0 =C2=A0+--rw sid =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sid<=
br>

* The SID file construct needs a wrapper container inst=
ead of 6 to-level data nodes.
  A yang-data extension (from ietf-r=
estconf.yang in RFC 8040) should be used.
  There is an=
 update to rc:yang-data, but it is not published yet.

     rc:yang-data sid-file {
         // all 6 fields de=
fined here
     }


* The IETF Trust Copyright is for 2016. There is probably a ne=
w template.

* Nit: list names are usually singular (depende=
ncies-revisions, assignment-ranges, items)


* The =
description-stmt for assignment-ranges should be expanded:  - spe=
cify that the SID range for each entry is SID entry-point to entry-point + =
(size - 1)
  - the SID ranges specified by all assignment-rages MU=
ST NOT overlap

* The type for /assignment-ranges/siz=
e should not allow zero-length ranges.  s/uint64/uint64 { range 1..max; }/<=
/font>

sec 6.3.2 Allocation Policy

<=
/div>
* the range 1000 to 59,999 is rather small for the pool of all YA=
NG modules published in RFCs.
=C2=A0 Likewise, 40K for all experi=
mental numbers seems really small. The SID range is uint64

* Not sure these characterizations of small, medium, large are=C2=
=A0helpful. Also max allocation of 1000
=C2=A0 seems rather arbit=
rary.=C2=A0 Better to say requestors need to justify the size of each reque=
st.

sec 6.4.2 Allocation Policy

=C2=A0 =C2=A0SIDs never change

=C2=A0 * The=
 IETF has shown very little ability to get all the names and module structu=
re correct on the first try.
=C2=A0 =C2=A0 =C2=A0Or the first 15 =
tries.=C2=A0 Modules get refactored and names get changed -- a lot.=C2=A0 T=
his statement is unclear.
=C2=A0 =C2=A0 =C2=A0(SID 42 is always S=
ID 42? Or do you mean SID assignments never change?)

=C2=A0 * This section should say that reassignment of SIDs within an all=
ocated SID range MAY change during
=C2=A0 =C2=A0 =C2=A0YANG modul=
e development. next section has text about this issue.

=

6.4.3

=C2=A0* Should an early allocation be g=
iven if the adopted module imports unadopted modules?
=C2=A0 =C2=
=A0This seems to force the WG to adopt or not use the allocated SID range

* Not sure how to fix the following=C2=A0 sentence,=
 but maybe just remove it since it is unclear

=

   Critically, the orig=
inal document should never get through the IETF
   process and then be surprised to be referencing a document whose
   progress is not certain.


=C2=A0* Not =
sure what "expired" means. It means they are burned and never rea=
llocated right?
 It would punish early adopters to =
do otherwise.
   Early Allocations are made with a one-year period, after which they
   are expired.

Appendix A

The example is rather long (8+ pages).
Do n=
ot have a=C2=A0suggestion for a=C2=A0shorter module though

Appendix B

It should be stated that SID g=
eneration for RPC or action "input" and "output" schema=
 nodes
should always be done, even if no parameters are defined i=
n the original RPC or action.
Another module can augment these no=
des (but cannot add "input" or "output" with augment).<=
/div>


Andy


<=
/div>


On Wed, Feb 12, 2020 at 7:04 AM Ivaylo Petrov <ivaylo@ackl.io> wrote:=

Dear a=
ll,

In the latest version I believe we have addressed Andy's comments re=
garding .sid file versioning. I consider this to be=C2=A0the last comment t=
hat was still pending before we can go for a working group last call for th=
e sid draft and the cluster of drafts known as CORECONF in general. Please =
let us know if there are still points that you consider should be handled b=
efore the WGLC. In the absence of further comments, I would like to ask the=
 working group chairs to consider going for a last call.

Thank you in advan=
ce!

Best regards,
Ivaylo
=



---------- Forwarded message ---------
Fro=
m: <internet-drafts@ietf.org>
Date: Wed, Feb 12, =
2020 at 3:53 PM
Subject: New Version Notification for draft-ietf-core-si=
d-10.txt
To: Ivaylo Petrov <ivaylo@ackl.io>, Alexander Pelov <a@ackl.io>, Michel Veillette <michel.veillet=
te@trilliant.com>




A new version of I-D, draft-ietf-core-sid-10.txt

has been successfully submitted by Ivaylo Petrov and posted to the

IETF repository.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-core-sid

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A010

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 YANG Schema Item iDentifier (SID)<=
br>
Document date:=C2=A0 2020-02-12

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 core

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 33

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-core-sid-10.txt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:=
//datatracker.ietf.org/doc/draft-ietf-core-sid/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.=
ietf.org/html/draft-ietf-core-sid-10

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/=
/datatracker.ietf.org/doc/html/draft-ietf-core-sid

Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-sid-10



Abstract:

=C2=A0 =C2=A0YANG Schema Item iDentifiers (SID) are globally unique 63-bit<=
br>
=C2=A0 =C2=A0unsigned integers used to identify YANG items.=C2=A0 This docu=
ment defines

=C2=A0 =C2=A0the semantics, the registration, and assignment processes of S=
IDs.

=C2=A0 =C2=A0To enable the implementation of these processes, this document=
 also

=C2=A0 =C2=A0defines a file format used to persist and publish assigned SID=
s.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat





_______________________________________________

core mailing list

core@ietf.org

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




--0000000000008bb7da059ec9669f--


From nobody Tue Feb 18 04:04:02 2020
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89425120111; Tue, 18 Feb 2020 04:03:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= 
To: "The IESG" 
Cc: draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime@iki.fi, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= 
Message-ID: <158202743151.14138.7139954130434566804.idtracker@ietfa.amsl.com>
Date: Tue, 18 Feb 2020 04:03:51 -0800
Archived-At: 
Subject: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-core-senml-more-units-04=3A_=28with_COMMENT=29?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2020 12:03:52 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-core-senml-more-units-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The shepherd write-up says: "The document is intended for Standards Track and
updates RFC8428." However, this document doesn't seem to update RFC8422. I
assume this is correct and the write-up is a bit outdated? Just wanted to
double-check...



From nobody Tue Feb 18 05:44:46 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320AA12018B; Tue, 18 Feb 2020 05:44:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn1QquBAn-_D; Tue, 18 Feb 2020 05:44:41 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AD0120026; Tue, 18 Feb 2020 05:44:41 -0800 (PST)
Received: from [192.168.1.19] (client-141-23-178-142.wlan.tu-berlin.de [141.23.178.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48MMXl26xnz185K; Tue, 18 Feb 2020 14:44:39 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <158202743151.14138.7139954130434566804.idtracker@ietfa.amsl.com>
Date: Tue, 18 Feb 2020 14:44:39 +0100
Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-senml-more-units@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 603726279.036818-6dac32210ec645ad221f8d3b12ddec6f
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <158202743151.14138.7139954130434566804.idtracker@ietfa.amsl.com>
To: =?utf-8?Q?Mirja_K=C3=BChlewind?= 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [core]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-core-senml-more-units-04=3A_=28with_COMMENT=29?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2020 13:44:44 -0000

Hi Mirja,

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> The shepherd write-up says: "The document is intended for Standards =
Track and
> updates RFC8428." However, this document doesn't seem to update =
RFC8422. I
> assume this is correct and the write-up is a bit outdated? Just wanted =
to
> double-check...

The proposed resolution of the most recent discussion was indeed that we =
don=E2=80=99t update RFC 8422 here, but leave that to version =
number/must-understand field specifications.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Tue Feb 18 05:45:50 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE348120026; Tue, 18 Feb 2020 05:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_FSE5_Q-mi0; Tue, 18 Feb 2020 05:45:44 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 4CDEF1200C1; Tue, 18 Feb 2020 05:45:44 -0800 (PST)
Received: from [129.192.10.3] (helo=[10.149.0.124]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j43C0-0007B3-LM; Tue, 18 Feb 2020 14:45:40 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind 
In-Reply-To: 
Date: Tue, 18 Feb 2020 14:45:39 +0100
Cc: core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-senml-more-units@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <158202743151.14138.7139954130434566804.idtracker@ietfa.amsl.com> 
To: Carsten Bormann 
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1582033544;fedd9973;
X-HE-SMSGID: 1j43C0-0007B3-LM
Archived-At: 
Subject: Re: [core]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-core-senml-more-units-04=3A_=28with_COMMENT=29?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2020 13:45:48 -0000

Hi Carsten,

That=E2=80=99s fine. Thanks for confirming!

Mirja


> On 18. Feb 2020, at 14:44, Carsten Bormann  wrote:
>=20
> Hi Mirja,
>=20
>> =
----------------------------------------------------------------------
>> COMMENT:
>> =
----------------------------------------------------------------------
>>=20
>> The shepherd write-up says: "The document is intended for Standards =
Track and
>> updates RFC8428." However, this document doesn't seem to update =
RFC8422. I
>> assume this is correct and the write-up is a bit outdated? Just =
wanted to
>> double-check...
>=20
> The proposed resolution of the most recent discussion was indeed that =
we don=E2=80=99t update RFC 8422 here, but leave that to version =
number/must-understand field specifications.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
>=20


From nobody Tue Feb 18 07:21:59 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C80120811; Tue, 18 Feb 2020 07:21:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level: 
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=UwI4B4y1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mfU5Z+C9
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoYuvB_M8BuH; Tue, 18 Feb 2020 07:21:54 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176E9120130; Tue, 18 Feb 2020 07:21:54 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 38B6C22007; Tue, 18 Feb 2020 10:21:53 -0500 (EST)
Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Tue, 18 Feb 2020 10:21:53 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=BTD71 ZuuVyMfsJAO0qmD42ylw9lVlTY0MwFcQBzLeMk=; b=UwI4B4y1mw9rVPN6WIMr1 WQ9ihbGKp3x44a2+5O6ClOisj4dqNUhO6rSgfnB2F5ULC9bZN5922ErKaBwko3MB p+BzuaPgx/9+OELW5TWNYuWwvYy4cqHHVM3lcdC91ltTQUlrMg3Z0yAZ8ydmNWSF GptKOsVUphrJCLR2evabraaXzzHQW4Hzugdr2hdnTia6EHatRnYPbIEMvet3ZB84 hMej8xo8iroRyqrn09Fvi3iusT8Jufage/NWBVlCY+Rwuz5WecMrUKezhhG0Q4WR TiXe0lJAS9ZRcAbGv2X3cLtp5JWqp4m2FxLsZM68syE646JPC4AnJf0gHBWIXQ2o g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=BTD71ZuuVyMfsJAO0qmD42ylw9lVlTY0MwFcQBzLe Mk=; b=mfU5Z+C99GlZ2F2TU885BA50nPEbUui44ziPmbAFJbPT1UXbYbYV+8hHX 07JJcWWM8LGJuc698Ro3IKBDOjPUdmADeP4IaNMB0AoWmNGc8kIlMG3WAA0MdvmH T/QsXXB7BqN3S5aEJV3lBcM9rt5Svgt9PybUrPfANYSPLXDhXVJm+enPyJ/Mh2zy o4Ut8pn6oWkFro8RcV/Fet7PrwPUJ183QNSBAPYYoI79MSnS1rJu3CMVymniVH1k QDrB4xs3hVCDi2VeJDv9zeu0t8KsWJ7R1Ts332hQ3n2FtvNowAlHb6kbuYryAuQE oG/uCqKC2PdZa02phE1BS7WkoBc5Q==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrjeekgdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 62D6866006B; Tue, 18 Feb 2020 10:21:52 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1
Mime-Version: 1.0
Message-Id: <42ef449f-9494-4045-a48d-0030dcaf1c77@www.fastmail.com>
In-Reply-To: 
References: <158202743151.14138.7139954130434566804.idtracker@ietfa.amsl.com>  
Date: Tue, 18 Feb 2020 15:21:20 +0000
From: "Alexey Melnikov" 
To: "Mirja Kuehlewind" , "Carsten Bormann" , "Jaime Jimenez" 
Cc: core-chairs@ietf.org, "The IESG" , core@ietf.org, draft-ietf-core-senml-more-units@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [core]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-core-senml-more-units-04=3A_=28with_COMMENT=29?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2020 15:21:56 -0000

Hi all,

On Tue, Feb 18, 2020, at 1:45 PM, Mirja Kuehlewind wrote:
> Hi Carsten,
>=20
> That=E2=80=99s fine. Thanks for confirming!

I removed "update RFC8422" from the IESG ballot, but I haven't updated t=
he write-up.

Jaime, can you please update the write-up to match the latest draft vers=
ion?

Best Regards,
Alexey

> Mirja
>=20
>=20
> > On 18. Feb 2020, at 14:44, Carsten Bormann  wrote:
> >=20
> > Hi Mirja,
> >=20
> >> -------------------------------------------------------------------=
---
> >> COMMENT:
> >> -------------------------------------------------------------------=
---
> >>=20
> >> The shepherd write-up says: "The document is intended for Standards=
 Track and
> >> updates RFC8428." However, this document doesn't seem to update RFC=
8422. I
> >> assume this is correct and the write-up is a bit outdated? Just wan=
ted to
> >> double-check...
> >=20
> > The proposed resolution of the most recent discussion was indeed tha=
t we don=E2=80=99t update RFC 8422 here, but leave that to version numbe=
r/must-understand field specifications.
> >=20
> > Gr=C3=BC=C3=9Fe, Carsten
> >=20
> >=20
>=20
>


From nobody Tue Feb 18 16:22:33 2020
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 603A8120058; Tue, 18 Feb 2020 16:22:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker 
To: "The IESG" 
Cc: draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime@iki.fi, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk 
Message-ID: <158207175238.13976.4748538225663851323.idtracker@ietfa.amsl.com>
Date: Tue, 18 Feb 2020 16:22:32 -0800
Archived-At: 
Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-more-units-04: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 00:22:32 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-senml-more-units-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

   +-----------+-------------------+-------+-----------+-----+---------+
   | secondary | description       | SenML |     scale | off | refer-  |
   | unit      |                   | unit  |           | set | ence    |
   +-----------+-------------------+-------+-----------+-----+---------+
   [...]
   | km        | kilometer         | km    |      1000 |   0 | RFCthis |

The associated SenML unit would be just 'm', not 'km'.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I appreciate the compromise position that was achieved after the long
last-call discussions questioning the need for this work.  It seems like
a reasonably shaped "escape hatch" to me.

Section 2

I assume this is just a product of my personal background, but I am more
used to "mass density" than "mass concentration" for dimensionalities
such as kg/m3.

Section 3

   o  The Byte.  [IEC-80000-13] defines both the bit (item 13-9.b) and
      the byte (item 13-9.c, also called octet) as alternative names for
      the coherent unit one for the purpose of giving storage capacity
      and related quantities.  While the name octet is associated with

nit: is "one" misplaced, here?

Section 4

   o  scale, offset: two rational numbers, expressed in decimal
      (optionally, with a decimal exponent given) or as a fraction
      divided by a "/" character.

nit: doesn't "a fraction divided by a '/' character" involve two '/'
characters?  That is, "1/2" is a fraction, so "1/2 divided by a '/'
character" would be like "1/2/" or "1/2/2" or something nonsensical like
that.


It's a little surprising to see kibibyte and gigabyte defined but not
gibibyte.

   names.  Guidelines to the difference between units (which can go into
   the registry) and quantities are widely available, see for instance
   [RS] and [BIPM].

I suggest a parenthetical "(which cannot)" after "quantities".

   Where the benefits of directly using a secondary unit in a SenML pack
   outweigh the obove considerations, the use of secondary units in "u"

nit: s/obove/above/

   specifically allows this and/or by using a field with a label name
   that ends with the "_" character ("must-understand" field) that
   specifically allows this.  The definition of these versions and

I suggest "whose definition specifically allows this".

   fields is outside the scope of the present specification; one such
   definition is provided in [I-D.bormann-core-senml-versions].

nit: I suggest "proposed definition" or "possible definition", as
internet-drafts are "works in progress".

Section 5

   potential single point of failure.  Instead of pulling the registry
   in each individual instance of the code, the software update
   mechanism (or a similar, less frequently triggered mechanism) SHOULD
   be used to disseminate updated units registries obtained from IANA
   towards the instances via common repositories.

I like how this blandly assumes that a software update mechanism is
available.  Optimistic for the present-day world, but still probably the
right thing to say.
nit: as written, "less frequently triggered mechanism" means "less
frequently triggered than the software update mechanism", which I
suspect is not the intent.

Section 6

I suggest reiterating the implications of the requirements at the end of
section 4, namely, that use of new units is "fail-safe", in that an
implementation processing a pack using secondary units is guaranteed to
have been developed with an awareness of the risks of having multiple
units available for the same logical type.  (It is not, of course,
guaranteed to know about the specific secondary unit in question when
just the "SenML Version" check is used, in the same way that current
SenML applications are not guaranteed to know about units not in the
initial allocation from RFC 8428.)

   The security considerations of [RFC8428] apply.  The introduction of
   new measurement units poses no additional security considerations
   except from a possible potential for additional confusion about the
   proper unit to use.

Nitpicking, but I think there's a related risk of confusion in terms of
what quantity has been measured and is indicated in a SenML pack, as
alluded to by the previous mention of "trigger[ing] on the presence of a
quantity in a certain unit".



From nobody Tue Feb 18 20:31:15 2020
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B961208A4; Tue, 18 Feb 2020 20:31:05 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Suresh Krishnan via Datatracker 
To: "The IESG" 
Cc: draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime@iki.fi, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Suresh Krishnan 
Message-ID: <158208666560.19245.17358062449999549234.idtracker@ietfa.amsl.com>
Date: Tue, 18 Feb 2020 20:31:05 -0800
Archived-At: 
Subject: [core] Suresh Krishnan's No Objection on draft-ietf-core-senml-more-units-04: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 04:31:06 -0000

Suresh Krishnan has entered the following ballot position for
draft-ietf-core-senml-more-units-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I could not read the normative references to IEC-80000-6 and 13 as I do not
have access . I trust the sponsoring AD to have gone through them and verified
that the item number references are correct.

Also the following text in Section 3 seems very handwavy and not particularly
helpful. Is this necessary?

"    It is not presently known to this author how
      the upcoming revision of IEC 80000-6 will update this, but it has
      became clear that there is strong interest in using this unit
      specifically for the imaginary content of complex power, reactive
      power [IEEE-1459]"



From nobody Wed Feb 19 04:51:12 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9802A12003F; Wed, 19 Feb 2020 04:51:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UthAIQwI9y35; Wed, 19 Feb 2020 04:51:00 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26828120019; Wed, 19 Feb 2020 04:51:00 -0800 (PST)
Received: from client-0171.vpn.uni-bremen.de (client-0171.vpn.uni-bremen.de [134.102.107.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48MyJL1pcmzyV6; Wed, 19 Feb 2020 13:50:58 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <158207175238.13976.4748538225663851323.idtracker@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 13:50:57 +0100
Cc: The IESG , draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 603809457.787553-71f13adf809e79555dbeba34af29dde0
Content-Transfer-Encoding: quoted-printable
Message-Id: <89E1D428-FF1B-4B42-BF1A-2BEF9B2C0B1B@tzi.org>
References: <158207175238.13976.4748538225663851323.idtracker@ietfa.amsl.com>
To: Benjamin Kaduk 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-more-units-04: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 12:51:04 -0000

Hi Ben,

thank you for your in-depth review.

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>=20
>   =
+-----------+-------------------+-------+-----------+-----+---------+
>   | secondary | description       | SenML |     scale | off | refer-  =
|
>   | unit      |                   | unit  |           | set | ence    =
|
>   =
+-----------+-------------------+-------+-----------+-----+---------+
>   [...]
>   | km        | kilometer         | km    |      1000 |   0 | RFCthis =
|
>=20
> The associated SenML unit would be just 'm', not 'km'.

Oops.  Obviously, it is a consistency requirement that anything in =
column 3 needs to be present in the primary unit name registration =
table.

Fixed in =
https://github.com/core-wg/senml-more-units/commit/78c714ab6a6526291265ec1=
976807ab3e8aa3138


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> I appreciate the compromise position that was achieved after the long
> last-call discussions questioning the need for this work.  It seems =
like
> a reasonably shaped "escape hatch" to me.
>=20
> Section 2
>=20
> I assume this is just a product of my personal background, but I am =
more
> used to "mass density" than "mass concentration" for dimensionalities
> such as kg/m3.

True, the unit can be used for both quantities.
(The actual request leading up to this was for particle concentration =
meters, hence the mass concentration label.)
That factoid is actually covered in
https://www.iso.org/obp/ui/#iso:std:iso:80000:-1:ed-1:v1:en
Section 3.7, example 2.
Since the registry captures units, not quantities, I propose adding mass =
density to the parenthesis.

Now in =
https://github.com/core-wg/senml-more-units/commit/25072a9e5757ea0d4aff75d=
2415afb40a17a9e37

> Section 3
>=20
>   o  The Byte.  [IEC-80000-13] defines both the bit (item 13-9.b) and
>      the byte (item 13-9.c, also called octet) as alternative names =
for
>      the coherent unit one for the purpose of giving storage capacity
>      and related quantities.  While the name octet is associated with
>=20
> nit: is "one" misplaced, here?

The coherent unit actually is =E2=80=9Cone=E2=80=9D; see Section 3.8, =
Note 3, and Section 3.12, Note 4 in ISO 80000-1 as cited above.
To make this easier to read, we could place it in quotes, except it is =
not a string, it is really the number 1.

> Section 4
>=20
>   o  scale, offset: two rational numbers, expressed in decimal
>      (optionally, with a decimal exponent given) or as a fraction
>      divided by a "/" character.
>=20
> nit: doesn't "a fraction divided by a '/' character" involve two '/'
> characters?  That is, "1/2" is a fraction, so "1/2 divided by a '/'
> character" would be like "1/2/" or "1/2/2" or something nonsensical =
like
> that.

=E2=80=9Cdivided=E2=80=9D as in =E2=80=9Cseparated into two halves=E2=80=9D=
, i.e., =E2=80=9C1/2=E2=80=9D is divided by a =E2=80=9C/=E2=80=9C into a =
1 and a 2.  Maybe we need better phrasing here.

> It's a little surprising to see kibibyte and gigabyte defined but not
> gibibyte.

It=E2=80=99s a registry, nobody asked for it yet=E2=80=A6
We could do some more proactive registering.

>   names.  Guidelines to the difference between units (which can go =
into
>   the registry) and quantities are widely available, see for instance
>   [RS] and [BIPM].
>=20
> I suggest a parenthetical "(which cannot)" after "quantities".

Very good.

Now in =
https://github.com/core-wg/senml-more-units/commit/25072a9e5757ea0d4aff75d=
2415afb40a17a9e37

>=20
>   Where the benefits of directly using a secondary unit in a SenML =
pack
>   outweigh the obove considerations, the use of secondary units in "u"
>=20
> nit: s/obove/above/

(Covered earlier.)

>   specifically allows this and/or by using a field with a label name
>   that ends with the "_" character ("must-understand" field) that
>   specifically allows this.  The definition of these versions and
>=20
> I suggest "whose definition specifically allows this".

Good point.

Now in
=
https://github.com/core-wg/senml-more-units/commit/76f51849541b5a18a6ef298=
4507284d92514eb54

>=20
>   fields is outside the scope of the present specification; one such
>   definition is provided in [I-D.bormann-core-senml-versions].
>=20
> nit: I suggest "proposed definition" or "possible definition", as
> internet-drafts are "works in progress".

Maybe shorter =E2=80=9C..is proposed in=E2=80=9D?
I=E2=80=99ve put that into
=
https://github.com/core-wg/senml-more-units/commit/8f2163a311e088a8cdfc30f=
a37df3a9f175c87e3

> Section 5
>=20
>   potential single point of failure.  Instead of pulling the registry
>   in each individual instance of the code, the software update
>   mechanism (or a similar, less frequently triggered mechanism) SHOULD
>   be used to disseminate updated units registries obtained from IANA
>   towards the instances via common repositories.
>=20
> I like how this blandly assumes that a software update mechanism is
> available.  Optimistic for the present-day world, but still probably =
the
> right thing to say.
> nit: as written, "less frequently triggered mechanism" means "less
> frequently triggered than the software update mechanism", which I
> suspect is not the intent.

I have turned this into

(or a similar
mechanism visiting IANA less frequently)

in =
https://github.com/core-wg/senml-more-units/commit/8656620080aa6d0d2a42247=
6a7a5693e931e6f3e

> Section 6
>=20
> I suggest reiterating the implications of the requirements at the end =
of
> section 4, namely, that use of new units is "fail-safe", in that an
> implementation processing a pack using secondary units is guaranteed =
to
> have been developed with an awareness of the risks of having multiple
> units available for the same logical type.  (It is not, of course,
> guaranteed to know about the specific secondary unit in question when
> just the "SenML Version" check is used, in the same way that current
> SenML applications are not guaranteed to know about units not in the
> initial allocation from RFC 8428.)
>=20
>   The security considerations of [RFC8428] apply.  The introduction of
>   new measurement units poses no additional security considerations
>   except from a possible potential for additional confusion about the
>   proper unit to use.
>=20
> Nitpicking, but I think there's a related risk of confusion in terms =
of
> what quantity has been measured and is indicated in a SenML pack, as
> alluded to by the previous mention of "trigger[ing] on the presence of =
a
> quantity in a certain unit".

I have tried to cover this in
=
https://github.com/core-wg/senml-more-units/commit/532dce8315bf9c75af1d115=
0d078d2f91e6444c0

Gr=C3=BC=C3=9Fe, Carsten



From nobody Wed Feb 19 06:54:54 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F005120120; Wed, 19 Feb 2020 06:54:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm27xHqrf8sJ; Wed, 19 Feb 2020 06:54:42 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97DD1200B5; Wed, 19 Feb 2020 06:54:41 -0800 (PST)
Received: from client-0171.vpn.uni-bremen.de (client-0171.vpn.uni-bremen.de [134.102.107.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48N1330GRtzyfd; Wed, 19 Feb 2020 15:54:39 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 19 Feb 2020 15:54:38 +0100
Cc: "core@ietf.org" , "core-chairs@ietf.org" , The IESG , "draft-ietf-core-senml-more-units@ietf.org" 
X-Mao-Original-Outgoing-Id: 603816878.788707-19c5195bd82d5a72f11f8f261be0d211
Content-Transfer-Encoding: quoted-printable
Message-Id: <156DEE7A-BF0A-4644-B072-0D574D56BE3C@tzi.org>
References: 
To: "Rob Wilton (rwilton)" 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [core] RobW comments on draft-ietf-core-senml-more-units-04
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 14:54:44 -0000

Hi Rob,

sorry for not processing the comments in order of arrival.

> I=E2=80=99m providing some comments as an incoming Ops and Mgmt AD.
> =20
> I found this document well written but think that it may be helpful to =
highlight the protocol usage of secondary units earlier in the document, =
i.e. in the introduction.
> =20
> My understanding is that this document introduces both extra primary =
unit names, and also a new concept of secondary unit names, which I =
presume came about from deployment considerations.
> =20
> Comments:
> 	=E2=80=A2 As per above, I think that it would be useful to add a =
comment in the introduction about how secondary units could be used.  =
E.g. may be extend
> =20
> =E2=80=9CThe document also defines a registry for secondary Unit names =
that
>    cannot be in SenML's main registry as they are derived by linear
>    transformation from units already in that registry.=E2=80=9D
> =20
> with the sentence =E2=80=9CAlthough SenML version 10 [RFC8428] does =
not allow for the direct use of secondary units, they are planned to be =
supported via the use of SenML protocol extensions, such as =
[I-D.bormann-core-senml-versions].=E2=80=9D

Very nice addition.  Slightly edited now in
=
https://github.com/core-wg/senml-more-units/commit/344430b74f738213a541f08=
7baede716c1afed30
=20
> 	=E2=80=A2 The introduction introduces the term =E2=80=9Cprimary =
Unit names=E2=80=9D, but then doesn=E2=80=99t refer to them using this =
term in the rest of the document.  It might be helpful if the title of =
section 2 was changed from =E2=80=9CNew Units=E2=80=9D to =E2=80=9CNew =
primary Units=E2=80=9D, and the description could be changed from =E2=80=9C=
=E2=80=A6 assign new units =E2=80=A6=E2=80=9D to =E2=80=9C=E2=80=A6 =
assign new primary unit names =E2=80=A6=E2=80=9D.

I=E2=80=99m with you here except for the instruction to IANA: That=E2=80=99=
s not agreeing with the name of that registry, and I wasn=E2=80=99t =
trying to change that.
=20
> 	=E2=80=A2 My reading of the =E2=80=9C3. Rationale=E2=80=9D =
section is that it relates to the new primary units, rather than =
secondary units.  The structure of the document might be clearer if this =
was made a subsection of the section 2 rather than its own top level =
section.

I made it a Section 2.1.  (OCD would require making it section 2.2, but =
then we=E2=80=99d need glue to properly anchor section 2.1.)
=20
> 	=E2=80=A2 I would suggest renaming the section 4 title from =
=E2=80=9CNew Registry=E2=80=9D to =E2=80=9CNew Registry for Secondary =
Units=E2=80=9D.

Yes!
=20
> 	=E2=80=A2 Regarding section 4 on secondary units:
> 		=E2=80=A2 I observe that these are not using a =
generalized mechanism of using SI prefixes for scaling, but propose a =
separate custom mapping instead, which in some cases are just making use =
of SI prefixes.  I presume that there is a good reason for not wanting =
to generically use SI prefixes, perhaps for a bit more homogeneity in =
the scaling factors, but it might be helpful for the document to explain =
the rationale behind this.

Actually, I=E2=80=99d like to push back a bit on this, as SI prefixes =
are not an obvious way to handle many of the secondary units that are =
being proposed by other SDOs.

(Defining a scheme for parsing unit names would have been a possibility, =
but with ambiguities like m (milli) vs. m (meter) this is just too hard =
to get right.)

> 		=E2=80=A2 I note that you have similar units but with =
different scaling factors (e.g. KiB, GB, Mbit/s, MB/s).  Do we =
anticipate other scaling factors of these units?  E.g. if MB was =
requested as a secondary unit, then would that be added? =20

Yes.  The list that is in this draft is somewhat incidental: It is what =
is needed to allow LWM2M/IPSO to use the SenML registry.  And they =
happened not to have MB (which today rarely is useful).

> Would it make sense to define any more of these common scaling factors =
now?

Yes, we could go for some proactive registration, e.g. where we have one =
SI range prefix, we could register all reasonable ones.

> 		=E2=80=A2 I also note that the names of some of the =
secondary units would overlap with SI prefixes (e.g. =E2=80=9Cmin=E2=80=9D=
) for minutes.  This is okay, but would likely be an annoyance if it was =
ever desirable to use SI prefixes in a generic way.

Yes, so it is better to have a designated expert look at each =
registration.

> 		=E2=80=A2 I wasn=E2=80=99t sure whether =E2=80=9Ch=E2=80=9D=
 is really a great shorthand for hour, I would have gone for =E2=80=9Chr=E2=
=80=9D instead, but perhaps this is already widely used elsewhere?

It is the standard one, as in km/h etc.
(See Section 6.5.6 of ISO 80000-1:2009, which apparently is not online.)

The structural/heading changes I took from this are in:
=
https://github.com/core-wg/senml-more-units/commit/08c3edc91883569cb1f48bc=
216c3049d77ea962e

We could additionally go ahead with some more proactive registration.
I propose to wait for the telechat with deciding whether we should.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Wed Feb 19 07:05:17 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C521200F8; Wed, 19 Feb 2020 07:05:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v90G7IrHG4kx; Wed, 19 Feb 2020 07:05:04 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5953A120026; Wed, 19 Feb 2020 07:05:04 -0800 (PST)
Received: from client-0171.vpn.uni-bremen.de (client-0171.vpn.uni-bremen.de [134.102.107.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48N1H2334Xzyfx; Wed, 19 Feb 2020 16:05:02 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <158208666560.19245.17358062449999549234.idtracker@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 16:05:02 +0100
Cc: The IESG , draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 603817502.134087-4520790a4c2bd1e4939fbbef8263e579
Content-Transfer-Encoding: quoted-printable
Message-Id: <29B49223-7D7F-4DDB-984D-2A2F5D8A78A5@tzi.org>
References: <158208666560.19245.17358062449999549234.idtracker@ietfa.amsl.com>
To: Suresh Krishnan 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [core] Suresh Krishnan's No Objection on draft-ietf-core-senml-more-units-04: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 15:05:07 -0000

Hi Suresh,

it is somewhat unfortunate that we are only in the middle of the =
transition from closed to more openly available standards in the SI/ISQ =
space.  I wish I had a better answer about the IEC ones, ISO is one step =
ahead (at least with the recent versions).

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> I could not read the normative references to IEC-80000-6 and 13 as I =
do not
> have access . I trust the sponsoring AD to have gone through them and =
verified
> that the item number references are correct.

One of the few advantages of being associated with a university is that =
we have a library.
So I can pretend I got my copies from there...

> Also the following text in Section 3 seems very handwavy and not =
particularly
> helpful. Is this necessary?
>=20
> "    It is not presently known to this author how
>      the upcoming revision of IEC 80000-6 will update this, but it has
>      became clear that there is strong interest in using this unit
>      specifically for the imaginary content of complex power, reactive
>      power [IEEE-1459]"

I would like to keep the reference to IEEE 1459 (which is almost =
reasonably accessible), but I agree that the lamenting about IEC is not =
needed.

Now in
=
https://github.com/core-wg/senml-more-units/commit/d3ceb1bde39307c74f81b1a=
50724c05f2db49c8d

Thank you!

Gr=C3=BC=C3=9Fe, Carsten


From nobody Wed Feb 19 07:14:50 2020
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1D31200B5; Wed, 19 Feb 2020 07:14:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: core@ietf.org
Message-ID: <158212528877.17624.3675498765524794709@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 07:14:48 -0800
Archived-At: 
Subject: [core] I-D Action: draft-ietf-core-senml-more-units-05.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 15:14:49 -0000

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

        Title           : Additional Units for SenML
        Author          : Carsten Bormann
	Filename        : draft-ietf-core-senml-more-units-05.txt
	Pages           : 9
	Date            : 2020-02-19

Abstract:
   The Sensor Measurement Lists (SenML) media type supports the
   indication of units for a quantity represented.  This short document
   registers a number of additional unit names in the IANA registry for
   Units in SenML.  It also defines a registry for secondary units that
   cannot be in SenML's main registry as they are derived by linear
   transformation from units already in that registry.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-senml-more-units-05
https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-more-units-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-more-units-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 Wed Feb 19 07:20:53 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2680A1200B5 for ; Wed, 19 Feb 2020 07:20:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mew-kiDELaGT for ; Wed, 19 Feb 2020 07:20:49 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03D8120026 for ; Wed, 19 Feb 2020 07:20:48 -0800 (PST)
Received: from client-0171.vpn.uni-bremen.de (client-0171.vpn.uni-bremen.de [134.102.107.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48N1dC4WrgzyfY; Wed, 19 Feb 2020 16:20:47 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <158212528877.17624.3675498765524794709@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 16:20:47 +0100
X-Mao-Original-Outgoing-Id: 603818447.379673-a68c24b6ad21b5e0982a15c05b753f1d
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <158212528877.17624.3675498765524794709@ietfa.amsl.com>
To: Core 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [core] I-D Action: draft-ietf-core-senml-more-units-05.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 15:20:51 -0000

(With author hat only:)

This is a roll-up of the changes that resulted from IESG (or =
IESG-related) comments before tomorrow=E2=80=99s telechat.
If there is anything that needs to be fixed, please reply to the list =
(or to me).

Gr=C3=BC=C3=9Fe, Carsten


> On 2020-02-19, at 16:14, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Constrained RESTful Environments WG =
of the IETF.
>=20
>        Title           : Additional Units for SenML
>        Author          : Carsten Bormann
> 	Filename        : draft-ietf-core-senml-more-units-05.txt
> 	Pages           : 9
> 	Date            : 2020-02-19
>=20
> Abstract:
>   The Sensor Measurement Lists (SenML) media type supports the
>   indication of units for a quantity represented.  This short document
>   registers a number of additional unit names in the IANA registry for
>   Units in SenML.  It also defines a registry for secondary units that
>   cannot be in SenML's main registry as they are derived by linear
>   transformation from units already in that registry.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-core-senml-more-units-05
> =
https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-more-units-05
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-more-units-05
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From nobody Wed Feb 19 07:30:43 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C60212010F; Wed, 19 Feb 2020 07:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lOPEZbp1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cEtWNQHl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCh0zcxWJTUg; Wed, 19 Feb 2020 07:30:31 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424C0120026; Wed, 19 Feb 2020 07:30:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8240; q=dns/txt; s=iport; t=1582126231; x=1583335831; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QR0Xg+q0khu5uMqH+48D5HPhz8RJhr/AdvXosz0MmAM=; b=lOPEZbp1J0dYMd/N6I3UTOIzW2mNjl8tGIy0zLKnP2oIiFd+RfEAxhyM Wy/o+8zRRqaaZ02RFBAsLf1ri1EISS0qxnzF1t6eBSSiYLCGLxBz6qhVK i+PQkpAcgH+JUbZ/y/bt43j5R1yWw2HgXgxtbii6D5QlL+fMYEWbvRwx6 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3AO0RmVxQCf3IIBk8AVUq9f02LjNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjYlHcBeU1lN9HCgOk8TE8H7NBXf?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0BQB5U01e/4oNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFbFggBAsqCoNKQINGA4pxgl+YEYJSA1QJAQEBDAEBHw4?= =?us-ascii?q?CBAEBhEACF4FtJDgTAgMNAQEFAQEBAgEFBG2FNwyFZgEBAQECAQwGEREMAQE?= =?us-ascii?q?pDgELBAIBBgIOAwQBAQMCJgICAjAVCAgBAQQOBQgagwWCSgMOIAECDJFpkGc?= =?us-ascii?q?CgTmIYnWBMoJ/AQEFhTEYggwDBoEOKowkGoFBP4ERR4FOfj6CZAKBZxWCeTK?= =?us-ascii?q?CLI1qM4JGhhSZHgqCO4dPhU2JYIJJiBuQR5dokkwCBAIEBQIOAQEFgWkigVh?= =?us-ascii?q?wFRohgmxQGA2OHYNzilIBdIEpjFoBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.70,459,1574121600"; d="scan'208";a="637801225"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Feb 2020 15:30:30 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 01JFUURO027200 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Feb 2020 15:30:30 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Feb 2020 09:30:29 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Feb 2020 10:30:28 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 19 Feb 2020 09:30:28 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YgG0c8ZrmQt04ko0GxDVGXn+7IwiMsDh6Wzja0Y5Zfs2u9T+Q/I1Br1u0Su3B+pdZI76qZJEixcIFXWPZTiIqTaSEkJinOY4fZc8j85maa7Ygn4ff3sVEVfvTXWJi9UdBROYxAQt/kuA0yd9kLxfoGcHsfcEQDD829ZJF8kofdtXWT6A1df4MLi4tc2a8W8D2P2vSqB9ZBCGPnD2VORAcmuHRTJj/jmTOKYb9y9mHe7UzWve2KC0Uzj/3uqRkH29PIVq3ARiVemFQ1LUtfk6pbdjbaLGXHx5CiLDowidBII4jpPeGP89QTvxWadGnEsdj9kgJC0ZRQkvJFfaN7JpTQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QR0Xg+q0khu5uMqH+48D5HPhz8RJhr/AdvXosz0MmAM=; b=Gzr8H2O2C4kT5Gzt8uDcuPctVBhRzSOnUSVnrraR0koXf4Y+8et3tp5xnjZf1L3t6VKA3hyt7nKrg9SBrQw5UmQvWC2vlXkAghkbB5LZYSTRWd8Gg9xmMmDQ5XEZEh/uKpX/OP18j8E+RfPRv924+u7PjaEL6qXU+EilcCzFULu/uy1/LDdw2n+R0SlGO3x2JeqCc81sC8LusNdO9HPAuXC4wTrIQSWx70ULiDk576NsDcjK6Gu4KT59qSD0nuyaSujn3qBd6PGLJ6AC+yBgt/u1iklikpOPJoh5htIg98x9XVt1f/hfGcn74hNUuCxmDdfa2jWG67fafBn+NdsMSw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QR0Xg+q0khu5uMqH+48D5HPhz8RJhr/AdvXosz0MmAM=; b=cEtWNQHlqyYFGqmYUfJMS3G71xfjxhZpo/hYu/AI5ASyig8XH0YvWdVFuJIkUvngsY3OjNJIedFWeVKY6CH9MiRandFpLVsPa8dZ9cpSDg6eqh7IvbozlrSD2SzYdlcp6YmITRaN7dPbu3f9Sw49266I0yBsmaRDyiucFmDHEDQ=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3968.namprd11.prod.outlook.com (10.255.180.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18; Wed, 19 Feb 2020 15:30:27 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2729.032; Wed, 19 Feb 2020 15:30:27 +0000
From: "Rob Wilton (rwilton)" 
To: Carsten Bormann 
CC: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-senml-more-units@ietf.org" 
Thread-Topic: RobW comments on draft-ietf-core-senml-more-units-04
Thread-Index: AdXlqZeHMIQG61iWSRmLAl4AWyIkfwBiupQAAAAhvGA=
Date: Wed, 19 Feb 2020 15:30:27 +0000
Message-ID: 
References:  <156DEE7A-BF0A-4644-B072-0D574D56BE3C@tzi.org>
In-Reply-To: <156DEE7A-BF0A-4644-B072-0D574D56BE3C@tzi.org>
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=rwilton@cisco.com; 
x-originating-ip: [173.38.220.36]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 843eefa5-6550-4598-a766-08d7b550a58b
x-ms-traffictypediagnostic: MN2PR11MB3968:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0318501FAE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(376002)(346002)(396003)(136003)(199004)(189003)(81156014)(81166006)(8676002)(71200400001)(8936002)(33656002)(7696005)(86362001)(6916009)(316002)(966005)(54906003)(478600001)(76116006)(9686003)(55016002)(5660300002)(64756008)(52536014)(66446008)(186003)(26005)(2906002)(66946007)(4326008)(66476007)(66556008)(53546011)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3968; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hrZ+A3lh9tXcpdgMfIvRIwGIALB9y3+ao3oOeSKg8YfiiOxSm5YZQRPxmQHjWoX8egwXsHQpE1Z70W0Jp5UVw33+B7juEh8QGz7Ne+GC8pIVO6E2Ynk+ALxFzXpWZO01vqIdN46peuSYQpURVbd6aktve6VQ0nb/rx9pDQ/jni3H6mc41SMJvV+63N9ew4ZE2r7K94xJb4Gt/bnlVhqjVoRDDrMvPLPAmBESwub8+BUIyW7TiM1kGG4HpVl1cCbRQ40TZt5nhcWwR223ijnyg93Cq6CfKXJaYjD5tB99yRyuVS2ZvI7Zq4lSY7AT6hxHvzAz84xVIrn+56jLXukVP5/KijHS1JCrk8VsaM7CH7H2Weg2BaAmhY4nHFw3OjU06gBT7a6+FwAYhgsUOdTOUWammXv0n1efpdhmJyUeAYcln9WpY0OeKTHw6BJO4v9lm/6UG8Dy32MShprhaolDczQdDsAq1ea8jI+1iRvQALeyZ+/Jt4y308/vUI07rf9LySDIVV9n5qzmwvH7KKaGoA==
x-ms-exchange-antispam-messagedata: 5E74AeDzICZWeqe8KxzuTQaxG9TMr+0/aR4HOq3gbOMr3otWbyhYyVZqIOZo/Ad+o424Ck4Y1p5jDrE+oKo1q0uC4CwxzdxlVa2LUIErYWDuOdEI0yjd5XTK3c1dP2juBYl8/kFqcJWd2CueAWyRuw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 843eefa5-6550-4598-a766-08d7b550a58b
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2020 15:30:27.4609 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WFgCwy0u6EnPFT7DsFnr4wPLEaq9P7QmTwSuZ/7fBiWC/6KIl0k+z1vqjzDj11YpoRla86EbMCaa+XqPO4jH6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3968
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: 
Subject: Re: [core] RobW comments on draft-ietf-core-senml-more-units-04
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 15:30:34 -0000

SGkgQ2Fyc3RlbiwNCg0KUGxlYXNlIHNlZSBpbmxpbmUgLi4uDQoNCj4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVzZyA8aWVzZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh
bGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQo+IFNlbnQ6IDE5IEZlYnJ1YXJ5IDIwMjAgMTQ6NTUNCj4g
VG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT4NCj4gQ2M6IGNvcmUt
Y2hhaXJzQGlldGYub3JnOyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGNvcmVAaWV0Zi5vcmc7
IGRyYWZ0LQ0KPiBpZXRmLWNvcmUtc2VubWwtbW9yZS11bml0c0BpZXRmLm9yZw0KPiBTdWJqZWN0
OiBSZTogUm9iVyBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWNvcmUtc2VubWwtbW9yZS11bml0cy0w
NA0KPiANCj4gSGkgUm9iLA0KPiANCj4gc29ycnkgZm9yIG5vdCBwcm9jZXNzaW5nIHRoZSBjb21t
ZW50cyBpbiBvcmRlciBvZiBhcnJpdmFsLg0KPiANCj4gPiBJ4oCZbSBwcm92aWRpbmcgc29tZSBj
b21tZW50cyBhcyBhbiBpbmNvbWluZyBPcHMgYW5kIE1nbXQgQUQuDQo+ID4NCj4gPiBJIGZvdW5k
IHRoaXMgZG9jdW1lbnQgd2VsbCB3cml0dGVuIGJ1dCB0aGluayB0aGF0IGl0IG1heSBiZSBoZWxw
ZnVsIHRvDQo+IGhpZ2hsaWdodCB0aGUgcHJvdG9jb2wgdXNhZ2Ugb2Ygc2Vjb25kYXJ5IHVuaXRz
IGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50LA0KPiBpLmUuIGluIHRoZSBpbnRyb2R1Y3Rpb24uDQo+
ID4NCj4gPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyBkb2N1bWVudCBpbnRyb2R1Y2Vz
IGJvdGggZXh0cmEgcHJpbWFyeQ0KPiB1bml0IG5hbWVzLCBhbmQgYWxzbyBhIG5ldyBjb25jZXB0
IG9mIHNlY29uZGFyeSB1bml0IG5hbWVzLCB3aGljaCBJDQo+IHByZXN1bWUgY2FtZSBhYm91dCBm
cm9tIGRlcGxveW1lbnQgY29uc2lkZXJhdGlvbnMuDQo+ID4NCj4gPiBDb21tZW50czoNCj4gPiAJ
4oCiIEFzIHBlciBhYm92ZSwgSSB0aGluayB0aGF0IGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBhZGQg
YSBjb21tZW50IGluDQo+IHRoZSBpbnRyb2R1Y3Rpb24gYWJvdXQgaG93IHNlY29uZGFyeSB1bml0
cyBjb3VsZCBiZSB1c2VkLiAgRS5nLiBtYXkgYmUNCj4gZXh0ZW5kDQo+ID4NCj4gPiDigJxUaGUg
ZG9jdW1lbnQgYWxzbyBkZWZpbmVzIGEgcmVnaXN0cnkgZm9yIHNlY29uZGFyeSBVbml0IG5hbWVz
IHRoYXQNCj4gPiAgICBjYW5ub3QgYmUgaW4gU2VuTUwncyBtYWluIHJlZ2lzdHJ5IGFzIHRoZXkg
YXJlIGRlcml2ZWQgYnkgbGluZWFyDQo+ID4gICAgdHJhbnNmb3JtYXRpb24gZnJvbSB1bml0cyBh
bHJlYWR5IGluIHRoYXQgcmVnaXN0cnku4oCdDQo+ID4NCj4gPiB3aXRoIHRoZSBzZW50ZW5jZSDi
gJxBbHRob3VnaCBTZW5NTCB2ZXJzaW9uIDEwIFtSRkM4NDI4XSBkb2VzIG5vdCBhbGxvdw0KPiBm
b3IgdGhlIGRpcmVjdCB1c2Ugb2Ygc2Vjb25kYXJ5IHVuaXRzLCB0aGV5IGFyZSBwbGFubmVkIHRv
IGJlIHN1cHBvcnRlZA0KPiB2aWEgdGhlIHVzZSBvZiBTZW5NTCBwcm90b2NvbCBleHRlbnNpb25z
LCBzdWNoIGFzIFtJLUQuYm9ybWFubi1jb3JlLXNlbm1sLQ0KPiB2ZXJzaW9uc10u4oCdDQo+IA0K
PiBWZXJ5IG5pY2UgYWRkaXRpb24uICBTbGlnaHRseSBlZGl0ZWQgbm93IGluDQo+IGh0dHBzOi8v
Z2l0aHViLmNvbS9jb3JlLXdnL3Nlbm1sLW1vcmUtDQo+IHVuaXRzL2NvbW1pdC8zNDQ0MzBiNzRm
NzM4MjEzYTU0MWYwODdiYWVkZTcxNmMxYWZlZDMwDQo+IA0KW1JXXQ0KTG9va3MgZ29vZC4NCg0K
DQo+ID4gCeKAoiBUaGUgaW50cm9kdWN0aW9uIGludHJvZHVjZXMgdGhlIHRlcm0g4oCccHJpbWFy
eSBVbml0IG5hbWVz4oCdLCBidXQNCj4gdGhlbiBkb2VzbuKAmXQgcmVmZXIgdG8gdGhlbSB1c2lu
ZyB0aGlzIHRlcm0gaW4gdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50Lg0KPiBJdCBtaWdodCBiZSBo
ZWxwZnVsIGlmIHRoZSB0aXRsZSBvZiBzZWN0aW9uIDIgd2FzIGNoYW5nZWQgZnJvbSDigJxOZXcg
VW5pdHPigJ0NCj4gdG8g4oCcTmV3IHByaW1hcnkgVW5pdHPigJ0sIGFuZCB0aGUgZGVzY3JpcHRp
b24gY291bGQgYmUgY2hhbmdlZCBmcm9tIOKAnOKApg0KPiBhc3NpZ24gbmV3IHVuaXRzIOKApuKA
nSB0byDigJzigKYgYXNzaWduIG5ldyBwcmltYXJ5IHVuaXQgbmFtZXMg4oCm4oCdLg0KDQo+IA0K
PiBJ4oCZbSB3aXRoIHlvdSBoZXJlIGV4Y2VwdCBmb3IgdGhlIGluc3RydWN0aW9uIHRvIElBTkE6
IFRoYXTigJlzIG5vdCBhZ3JlZWluZw0KPiB3aXRoIHRoZSBuYW1lIG9mIHRoYXQgcmVnaXN0cnks
IGFuZCBJIHdhc27igJl0IHRyeWluZyB0byBjaGFuZ2UgdGhhdC4NCg0KW1JXXQ0KT2theS4gIEkg
c2VlIHRoYXQgeW91IGhhdmUgdXBkYXRlZCB0aGUgdGl0bGUgZm9yIHRoaXMgc2VjdGlvbiwgc28g
SSB0aGluayB0aGF0IHNob3VsZCBtYWtlIGl0IGNsZWFyLg0KDQo+IA0KPiA+IAnigKIgTXkgcmVh
ZGluZyBvZiB0aGUg4oCcMy4gUmF0aW9uYWxl4oCdIHNlY3Rpb24gaXMgdGhhdCBpdCByZWxhdGVz
IHRvIHRoZQ0KPiBuZXcgcHJpbWFyeSB1bml0cywgcmF0aGVyIHRoYW4gc2Vjb25kYXJ5IHVuaXRz
LiAgVGhlIHN0cnVjdHVyZSBvZiB0aGUNCj4gZG9jdW1lbnQgbWlnaHQgYmUgY2xlYXJlciBpZiB0
aGlzIHdhcyBtYWRlIGEgc3Vic2VjdGlvbiBvZiB0aGUgc2VjdGlvbiAyDQo+IHJhdGhlciB0aGFu
IGl0cyBvd24gdG9wIGxldmVsIHNlY3Rpb24uDQo+IA0KPiBJIG1hZGUgaXQgYSBTZWN0aW9uIDIu
MS4gIChPQ0Qgd291bGQgcmVxdWlyZSBtYWtpbmcgaXQgc2VjdGlvbiAyLjIsIGJ1dA0KPiB0aGVu
IHdl4oCZZCBuZWVkIGdsdWUgdG8gcHJvcGVybHkgYW5jaG9yIHNlY3Rpb24gMi4xLikNCltSV10g
DQpPa2F5Lg0KDQo+IA0KPiA+IAnigKIgSSB3b3VsZCBzdWdnZXN0IHJlbmFtaW5nIHRoZSBzZWN0
aW9uIDQgdGl0bGUgZnJvbSDigJxOZXcgUmVnaXN0cnnigJ0NCj4gdG8g4oCcTmV3IFJlZ2lzdHJ5
IGZvciBTZWNvbmRhcnkgVW5pdHPigJ0uDQo+IA0KPiBZZXMhDQpbUlddIA0KVGhhbmtzLg0KDQo+
IA0KPiA+IAnigKIgUmVnYXJkaW5nIHNlY3Rpb24gNCBvbiBzZWNvbmRhcnkgdW5pdHM6DQo+ID4g
CQnigKIgSSBvYnNlcnZlIHRoYXQgdGhlc2UgYXJlIG5vdCB1c2luZyBhIGdlbmVyYWxpemVkIG1l
Y2hhbmlzbQ0KPiBvZiB1c2luZyBTSSBwcmVmaXhlcyBmb3Igc2NhbGluZywgYnV0IHByb3Bvc2Ug
YSBzZXBhcmF0ZSBjdXN0b20gbWFwcGluZw0KPiBpbnN0ZWFkLCB3aGljaCBpbiBzb21lIGNhc2Vz
IGFyZSBqdXN0IG1ha2luZyB1c2Ugb2YgU0kgcHJlZml4ZXMuICBJDQo+IHByZXN1bWUgdGhhdCB0
aGVyZSBpcyBhIGdvb2QgcmVhc29uIGZvciBub3Qgd2FudGluZyB0byBnZW5lcmljYWxseSB1c2Ug
U0kNCj4gcHJlZml4ZXMsIHBlcmhhcHMgZm9yIGEgYml0IG1vcmUgaG9tb2dlbmVpdHkgaW4gdGhl
IHNjYWxpbmcgZmFjdG9ycywgYnV0DQo+IGl0IG1pZ2h0IGJlIGhlbHBmdWwgZm9yIHRoZSBkb2N1
bWVudCB0byBleHBsYWluIHRoZSByYXRpb25hbGUgYmVoaW5kIHRoaXMuDQo+IA0KPiBBY3R1YWxs
eSwgSeKAmWQgbGlrZSB0byBwdXNoIGJhY2sgYSBiaXQgb24gdGhpcywgYXMgU0kgcHJlZml4ZXMg
YXJlIG5vdCBhbg0KPiBvYnZpb3VzIHdheSB0byBoYW5kbGUgbWFueSBvZiB0aGUgc2Vjb25kYXJ5
IHVuaXRzIHRoYXQgYXJlIGJlaW5nIHByb3Bvc2VkDQo+IGJ5IG90aGVyIFNET3MuDQo+IA0KPiAo
RGVmaW5pbmcgYSBzY2hlbWUgZm9yIHBhcnNpbmcgdW5pdCBuYW1lcyB3b3VsZCBoYXZlIGJlZW4g
YSBwb3NzaWJpbGl0eSwNCj4gYnV0IHdpdGggYW1iaWd1aXRpZXMgbGlrZSBtIChtaWxsaSkgdnMu
IG0gKG1ldGVyKSB0aGlzIGlzIGp1c3QgdG9vIGhhcmQgdG8NCj4gZ2V0IHJpZ2h0LikNCltSV10g
DQpPa2F5LCBJIGRvbid0IGZlZWwgdG9vIHN0cm9uZ2x5IG9uIHRoaXMuDQoNCkJ1dCBldmVuIHRo
ZSB0d28gcGFyYWdyYXBocyB0aGF0IHlvdSBoYXZlIHdyaXR0ZW4gYWJvdmUgaGVscCBjbGFyaWZ5
IHdoeSB0aGUgY3VycmVudCBhcHByb2FjaCBoYXMgYmVlbiB0YWtlbiwgYW5kIHdvdWxkIHBvdGVu
dGlhbGx5IGhlbHAgb3RoZXIgcmVhZGVyIHVuZGVyc3RhbmQgdGhlIHJhdGlvbmFsZSBiZWhpbmQg
dGhlIHNlY29uZGFyeSB1bml0cy4NCg0KPiANCj4gPiAJCeKAoiBJIG5vdGUgdGhhdCB5b3UgaGF2
ZSBzaW1pbGFyIHVuaXRzIGJ1dCB3aXRoIGRpZmZlcmVudA0KPiBzY2FsaW5nIGZhY3RvcnMgKGUu
Zy4gS2lCLCBHQiwgTWJpdC9zLCBNQi9zKS4gIERvIHdlIGFudGljaXBhdGUgb3RoZXINCj4gc2Nh
bGluZyBmYWN0b3JzIG9mIHRoZXNlIHVuaXRzPyAgRS5nLiBpZiBNQiB3YXMgcmVxdWVzdGVkIGFz
IGEgc2Vjb25kYXJ5DQo+IHVuaXQsIHRoZW4gd291bGQgdGhhdCBiZSBhZGRlZD8NCj4gDQo+IFll
cy4gIFRoZSBsaXN0IHRoYXQgaXMgaW4gdGhpcyBkcmFmdCBpcyBzb21ld2hhdCBpbmNpZGVudGFs
OiBJdCBpcyB3aGF0IGlzDQo+IG5lZWRlZCB0byBhbGxvdyBMV00yTS9JUFNPIHRvIHVzZSB0aGUg
U2VuTUwgcmVnaXN0cnkuICBBbmQgdGhleSBoYXBwZW5lZA0KPiBub3QgdG8gaGF2ZSBNQiAod2hp
Y2ggdG9kYXkgcmFyZWx5IGlzIHVzZWZ1bCkuDQpbUlddIA0KT2theS4gIFRoYW5rcywgSSB3YXNu
J3QgYXdhcmUgb2YgdGhlIGhpc3RvcnkuDQoNCg0KPiANCj4gPiBXb3VsZCBpdCBtYWtlIHNlbnNl
IHRvIGRlZmluZSBhbnkgbW9yZSBvZiB0aGVzZSBjb21tb24gc2NhbGluZyBmYWN0b3JzDQo+IG5v
dz8NCj4gDQo+IFllcywgd2UgY291bGQgZ28gZm9yIHNvbWUgcHJvYWN0aXZlIHJlZ2lzdHJhdGlv
biwgZS5nLiB3aGVyZSB3ZSBoYXZlIG9uZQ0KPiBTSSByYW5nZSBwcmVmaXgsIHdlIGNvdWxkIHJl
Z2lzdGVyIGFsbCByZWFzb25hYmxlIG9uZXMuDQo+IA0KPiA+IAkJ4oCiIEkgYWxzbyBub3RlIHRo
YXQgdGhlIG5hbWVzIG9mIHNvbWUgb2YgdGhlIHNlY29uZGFyeSB1bml0cw0KPiB3b3VsZCBvdmVy
bGFwIHdpdGggU0kgcHJlZml4ZXMgKGUuZy4g4oCcbWlu4oCdKSBmb3IgbWludXRlcy4gIFRoaXMg
aXMgb2theSwNCj4gYnV0IHdvdWxkIGxpa2VseSBiZSBhbiBhbm5veWFuY2UgaWYgaXQgd2FzIGV2
ZXIgZGVzaXJhYmxlIHRvIHVzZSBTSQ0KPiBwcmVmaXhlcyBpbiBhIGdlbmVyaWMgd2F5Lg0KPiAN
Cj4gWWVzLCBzbyBpdCBpcyBiZXR0ZXIgdG8gaGF2ZSBhIGRlc2lnbmF0ZWQgZXhwZXJ0IGxvb2sg
YXQgZWFjaA0KPiByZWdpc3RyYXRpb24uDQpbUlddIA0KT2theS4NCg0KPiANCj4gPiAJCeKAoiBJ
IHdhc27igJl0IHN1cmUgd2hldGhlciDigJxo4oCdIGlzIHJlYWxseSBhIGdyZWF0IHNob3J0aGFu
ZCBmb3INCj4gaG91ciwgSSB3b3VsZCBoYXZlIGdvbmUgZm9yIOKAnGhy4oCdIGluc3RlYWQsIGJ1
dCBwZXJoYXBzIHRoaXMgaXMgYWxyZWFkeQ0KPiB3aWRlbHkgdXNlZCBlbHNld2hlcmU/DQo+IA0K
PiBJdCBpcyB0aGUgc3RhbmRhcmQgb25lLCBhcyBpbiBrbS9oIGV0Yy4NCj4gKFNlZSBTZWN0aW9u
IDYuNS42IG9mIElTTyA4MDAwMC0xOjIwMDksIHdoaWNoIGFwcGFyZW50bHkgaXMgbm90IG9ubGlu
ZS4pDQpbUlddIA0KQWgsIHllcy4gIEl0IHNlZW1zIG9idmlvdXMgd2hlbiBJIHNlZSBpdCBsaWtl
IHRoYXQuDQoNCj4gDQo+IFRoZSBzdHJ1Y3R1cmFsL2hlYWRpbmcgY2hhbmdlcyBJIHRvb2sgZnJv
bSB0aGlzIGFyZSBpbjoNCj4gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvc2VubWwtbW9yZS0N
Cj4gdW5pdHMvY29tbWl0LzA4YzNlZGM5MTg4MzU2OWNiMWY0OGJjMjE2YzMwNDlkNzdlYTk2MmUN
CltSV10gDQpMb29rcyBnb29kLg0KDQo+IA0KPiBXZSBjb3VsZCBhZGRpdGlvbmFsbHkgZ28gYWhl
YWQgd2l0aCBzb21lIG1vcmUgcHJvYWN0aXZlIHJlZ2lzdHJhdGlvbi4NCj4gSSBwcm9wb3NlIHRv
IHdhaXQgZm9yIHRoZSB0ZWxlY2hhdCB3aXRoIGRlY2lkaW5nIHdoZXRoZXIgd2Ugc2hvdWxkLg0K
W1JXXSANClRoYXQgbWFrZXMgc2Vuc2UuDQoNClRoYW5rcyBmb3IgdGhlIGRvYyB1cGRhdGVzLg0K
Um9iDQoNCg0KPiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KDQo=


From nobody Wed Feb 19 07:45:25 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB8F12013A for ; Wed, 19 Feb 2020 07:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLp0njkBdkh3 for ; Wed, 19 Feb 2020 07:45:22 -0800 (PST)
Received: from smtp84.iad3a.emailsrvr.com (smtp84.iad3a.emailsrvr.com [173.203.187.84]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9E212012D for ; Wed, 19 Feb 2020 07:45:18 -0800 (PST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp35.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E0FB959DF;  Wed, 19 Feb 2020 10:45:16 -0500 (EST)
X-Sender-Id: fluffy@iii.ca
Received: from dhcp-10-154-140-92.cisco.com ([UNAVAILABLE]. [128.107.241.172]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 19 Feb 2020 10:45:17 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Cullen Jennings 
In-Reply-To: <86CDA415-5152-4414-BDB2-B4493B04AB33@tzi.org>
Date: Wed, 19 Feb 2020 07:45:13 -0800
Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , core@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CCAFB9A-2487-4A6C-89FD-D70BEC92E81F@iii.ca>
References:   <20200120161000.jxfsyeiffrvih62x@EMB-918HFH01> <5e82c3f0-aa71-460c-a646-9a86427d7f40@www.fastmail.com> <20200127170320.y5gu5hh4aqoxtzvm@EMB-918HFH01> <86CDA415-5152-4414-BDB2-B4493B04AB33@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [core] CoRE @ IETF106: Summary and Minutes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 15:45:25 -0000

I do not think this is a good way forward - it is too vague about how to =
do this and will result in different implication doing it differnt ways =
that are not interoperable.=20

> On Feb 11, 2020, at 1:05 PM, Carsten Bormann  wrote:
>=20
> I have submitted an update to senml-more-units that should address the =
concerns:
>=20
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-core-senml-more-units-04
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-more-units
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-more-units-04
>=20
> The -04 version now no longer updates RFC 8428 to allow the use of =
units from the secondary registry, but leaves this to specific =
indicators that announce the presence of secondary units in the SenML =
Pack.  One early draft with a proposal of how to do this is now =
available as:
>=20
> Htmlized:       =
https://tools.ietf.org/html/draft-bormann-core-senml-versions
>=20
> (There is no intention to couple the secondary registry to this =
specific way of indicating the use of secondary units; the above draft, =
while intended to be normative when it is done, is only an informational =
reference in senml-more-units.)
>=20
> In addition, the new version is more outspoken on the advantages of =
sticking to primary units in SenML packs, and it addresses the =
operational concerns that would result if IoT systems frequently and =
automatically updated their unit definitions directly from the IANA =
registry.
>=20
> Thanks to all the people that made it clear in offline discussions =
that this is a better way forward than just charging ahead and enabling =
secondary units everywhere.
>=20
> (Still with author hat on only:)
> CoRE WG, please check whether this proposed resolution is acceptable =
to the WG.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
>=20
>> On 2020-01-27, at 18:03, Jaime Jim=C3=A9nez  wrote:
>>=20
>> Dear all,
>>=20
>> Coming back to this issue, I have not seen a reply on the list
>> regarding this. I would like to have it concluded so that we can move
>> the document forward. I agree that the text should reflect that the
>> secondary registry is not be the preferable option if units in the
>> primary registry can be used. Maybe the authors could work out a
>> modified draft that better explains that, after which we can do the
>> document write up and ship it.
>>=20
>> Ciao!
>> -- Jaime
>>=20
>>=20
>> On Tue, Jan 21, 2020 at 11:35:47AM +0200, Jaime Jimenez wrote:
>>> Sending it to the core thread.=20
>>>=20
>>> --=20
>>> Jaime Jim=C3=A9nez
>>>=20
>>> On Mon, Jan 20, 2020, at 6:10 PM, Jaime Jimenez wrote:
>>>> Hi,
>>>>=20
>>>> comments below.=20
>>>>=20
>>>> On Fri, Dec 13, 2019 at 11:27:34AM -0700, Cullen Jennings wrote:
>>>>>=20
>>>>>=20
>>>>>> On Dec 9, 2019, at 3:42 PM, Carsten Bormann  wrote:
>>>>>>=20
>>>>>>=20
>>>>>> Concerns had been raised about opening up the second registry for
>>>>>> derived units, making it harder for a SenML application to find =
out
>>>>>> whether a unit encountered was actually of interest to it.
>>>>>> Discussion in the first session resulted in the tentative =
proposal
>>>>>> to mark secondary units with an asterisk (as in "*km/h", as =
opposed
>>>>>> to unmarked "m/s").  Further discussion in the second session =
made
>>>>>> clear that while this makes the use of secondary units stand out, =
it
>>>>>> does not really improve the situation of SenML applications that
>>>>>> want to quickly discard measurements for units they do not care
>>>>>> about, unless they track the contents of the two registries, =
which
>>>>>> would make the asterisks redundant.
>>>>>=20
>>>>> I disagree that the asterisk does not improve the situation
>>>>>=20
>>>>>> There also was some feedback
>>>>>> the asterisks would make the adoption of the SenML units registry =
by
>>>>>> other SDOs more difficult.  The in-room consensus not to go for =
the
>>>>>> asterisks, but to include more explanatory text about =
implementation
>>>>>> strategies, needs to confirmed on the mailing list. =20
>>>>>=20
>>>>> I strongly object to this.  RFC 8428 has a strong assertion that =
the units=20
>>>>>=20
>>>>>       For a given type of measurement, there will only be one unit
>>>>>       type defined.  So for length, meters are defined and other
>>>>>       lengths such as mile, foot, light year are not allowed.  For
>>>>>       most cases, the SI unit is preferred.
>>>>> There is running code that is based on that assumption that has =
been in production for many years. You can=E2=80=99t break that =
assumption without some backwards compatibility consideration that help =
theses deployed applications mitigate the breakage this causes.
>>>>=20
>>>> I believe that the assumption of having only one unit per =
measurement
>>>> was broken already with core-senml-more-units as it creates the
>>>> secondary registry. So the asterisk does not fix that. =20
>>>>=20
>>>>> The ideas that millions of edge aggregation devices, many on far =
side of slow links, would query the IANA web server to track the units =
and decide how to process data seems like a very bad design. I would =
expect the IESG to reject anything that lead to cases like =
https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse =

>>>>>=20
>>>>=20
>>>> I also do not see how the asterisk would make parsing easier. If
>>>> existing edge devices are hardcoded to use a subset of all units =
-just
>>>> the primary senml registry- then they would filter messages =
containing
>>>> any unit they do not understand anyways.=20
>>>>=20
>>>> Also the asterisk does not tell an application processing a =
specific
>>>> measurement (e.g., temperature in celsius) additional information =
about
>>>> the unit (e.g., I am temperature in fahrenheit, this is important)
>>>> indicating that this new unit  is something it should process, it =
only indicates
>>>> that it is part of the secondary registry.
>>>>=20
>>>> Regarding the querying of the senml registry, I think that would =
have to
>>>> happen anyways, as new units will be registered over time, even if =
not
>>>> very often.=20
>>>>=20
>>>> I think the real issue here is whether to signal "this unit belongs =
to a
>>>> secondary registry, not the main one" or not. Flagging a unit with =
"*" or
>>>> having a different field like "u2" can confuse developers =
unnecessarily,=20
>>>> as they do not need to know about historical standard decisions. =
It's
>>>> more of a penalty to those using it :D=20
>>>>=20
>>>> And if you want to convey that the secondary registry is not the
>>>> preferred one, then I think that is something that should be on the
>>>> draft itself, right? With very strong wording and so on, but not on =
the
>>>> wire in a senml record.=20
>>>>=20
>>>>>=20
>>>>=20
>>>>> _______________________________________________
>>>>> core mailing list
>>>>> core@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/core
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>=20


From nobody Wed Feb 19 08:44:36 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE0112080D; Wed, 19 Feb 2020 08:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI1sXxwVl9uH; Wed, 19 Feb 2020 08:44:25 -0800 (PST)
Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660096.outbound.protection.outlook.com [40.107.66.96]) (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 D62E5120232; Wed, 19 Feb 2020 08:44:24 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RD7X1+58AK6hmxVS/VlSwLMdU45zY0hbPzhyGozjSl8XjyOfSKiVmWIDMDxafr3+znAsXFlj8Dc1ExvW380LpFDLDhs9PiPPCc0Rgw/4GrvxahcclvfZTS76JPznaniXHhVVDhH1aLKpvSWHhD1l3e/Xh6wwt9bkvVUR+IeECh44qEkO5Z5qJxE1LSYzG4Br/4U+1RNL3vJ5L1V1TQLxb9LH+u8A3QJAPI2SzK1NbFmW5YpJPd01ZP7rJZmiFT4f3arQwI3rzSt05u4TPQ24CxFUPdHhM/CpLbbNw/mw/AWHRuBF0lu/HeMXvQF7lOmED8ZnCs/UU//uFjRP09mE7w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MWRsmoRBEznELEd9+EsnHZ4aGBoqlSIW94vAGtRmXFs=; b=H5VyMeo+urdfHc70nPQZ2ds8aYwFGAstzISe0vEVTqkLtGqC+2TmeZrZMyDUnSiB8xl37fSmV3RVa9i0uCp/82gkL5xtTMgBcPgtzvXXxZVulFyexU6XrJjtvsQmsSQlTocTgQ1NsiaCuY+eGs8eRcWsv5AX+p4js2eCMfsnzwfN8gQGOJvsW3Wd9dQH34xHV9DUgLufk8VZ313tN2dDF4bHJ4C+tlSGw7ZRBC3cx4f1OshcGKKP4P7ln0s1dA/BkKkryWXfisWuZZQBuxp6AQVDpdWKEF6i45nigLJenz4z5B57VxssqmoV4mRW8obuhfB0QOmLtYM0mW7h2JtqBA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kaloom.com; dmarc=pass action=none header.from=kaloom.com; dkim=pass header.d=kaloom.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MWRsmoRBEznELEd9+EsnHZ4aGBoqlSIW94vAGtRmXFs=; b=Jwcde1tjQWN7lMaXCrbGvo6rCd4JUZ+P7ASJ7mKBSjDHGOcsFYVuh56aKd03+oGgRtgbNWOyGYfuovtWAzontTQhA3IP9yaBR0DDu4qpyJFYHEnaM9XNt++NnwCeBHW1i9YvkB9Kr4Ds8iGSZ9mDkZtbxpkm6Bo30i8SqTuVAS4=
Received: from YTXPR0101MB1615.CANPRD01.PROD.OUTLOOK.COM (52.132.33.14) by YTXPR0101MB1135.CANPRD01.PROD.OUTLOOK.COM (52.132.34.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.17; Wed, 19 Feb 2020 16:44:22 +0000
Received: from YTXPR0101MB1615.CANPRD01.PROD.OUTLOOK.COM ([fe80::90ee:fc62:858:74c7]) by YTXPR0101MB1615.CANPRD01.PROD.OUTLOOK.COM ([fe80::90ee:fc62:858:74c7%6]) with mapi id 15.20.2729.032; Wed, 19 Feb 2020 16:44:22 +0000
From: Suresh Krishnan 
To: Carsten Bormann 
CC: The IESG , "draft-ietf-core-senml-more-units@ietf.org" , Jaime Jimenez , "core-chairs@ietf.org" , "core@ietf.org" 
Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-core-senml-more-units-04: (with COMMENT)
Thread-Index: AQHV5zX4V/i5Apd+Nk6gVQGD8G/7QqgiuT+A
Date: Wed, 19 Feb 2020 16:44:22 +0000
Message-ID: 
References: <158208666560.19245.17358062449999549234.idtracker@ietfa.amsl.com> <29B49223-7D7F-4DDB-984D-2A2F5D8A78A5@tzi.org>
In-Reply-To: <29B49223-7D7F-4DDB-984D-2A2F5D8A78A5@tzi.org>
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=Suresh@kaloom.com; 
x-originating-ip: [45.19.110.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7d0c91eb-ca4b-4933-a2fb-08d7b55af8e8
x-ms-traffictypediagnostic: YTXPR0101MB1135:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0318501FAE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(366004)(39850400004)(346002)(396003)(199004)(189003)(6506007)(6486002)(8936002)(316002)(2616005)(6512007)(2906002)(86362001)(71200400001)(53546011)(966005)(33656002)(508600001)(81166006)(66946007)(64756008)(66446008)(66476007)(91956017)(76116006)(54906003)(66556008)(26005)(5660300002)(36756003)(4326008)(81156014)(6916009)(186003)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:YTXPR0101MB1135; H:YTXPR0101MB1615.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: elVLoT9AtMbKyvSWidkEaMLxhQBOKE36zPDLn3DTaG9/wfSivRFBTHCczamWCvHMRquB5adMhDGA/QntC97UtfEMwaJ8dhntH8HeWPzTz5gnta8x/WxKBV/u0oFnb3FemxtgO+3tEPA2INdu1822fhhZjZ6h0jEnyDPt11poaHJNcyKELJEdxYk5QdRbpVf7YySIg4xWNc5vSwcrv23YKQ5uVT4mk8OLjn3QjIIgp7vrTy0+QkHhAmn0L2r8LKYDI/eJ6TzlvWQVwMZnq7CRpSyDrRCI2IPk7qEkRg3t3hO0dePVXv+Q6f+kaH0Vff+ap6r7iLpvyHTGcEY33ZcQEb0QBQBOkcjGjEt7TdHOKrKoejFEuxDeaBuuc5q/hVZz7TG1Wf5woF7yiTB3bVYwQYq7//+xeE6IZ/8G/ao6NHTvGFmF//ODxsKKdN+IhqsKzOxdxihyxbEmjNo+32CT5rYb0dxTN2Izhkbv++umxaXkXRKpA2pRg1e2UAbhDsNuylwnIhRmhcbwxn/xk1Ak2A==
x-ms-exchange-antispam-messagedata: zFph1t7YS1v6jWhhzpUOlt4zbFraDuot6mQTesu/LPJ8WRPH+dcIc2OJAmay682Rq87fcrhsbZqKK/snCIGngOiMlCZKNNOwyioEDjCuYjR8N8KfbXcOLcQxZjpZVOm6crOeurcK3bOoe7XoOu06uQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: kaloom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d0c91eb-ca4b-4933-a2fb-08d7b55af8e8
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2020 16:44:22.2916 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Fkaxb/lbZS73/eSzgjQofAk0BNnbUKHbCNK4jXFMOse6AP7MafsTeLWhABrzsCnK24l7N51bhM+jXMOO1aZ3aw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB1135
Archived-At: 
Subject: Re: [core] Suresh Krishnan's No Objection on draft-ietf-core-senml-more-units-04: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 16:44:27 -0000

Hi Carsten,

> On Feb 19, 2020, at 10:05 AM, Carsten Bormann  wrote:
>=20
> Hi Suresh,
>=20
> it is somewhat unfortunate that we are only in the middle of the transiti=
on from closed to more openly available standards in the SI/ISQ space.  I w=
ish I had a better answer about the IEC ones, ISO is one step ahead (at lea=
st with the recent versions).

No worries. I would have been more worried if this was more than a referenc=
e to just terminology but this is not a big issue for me.

>=20
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>=20
>> I could not read the normative references to IEC-80000-6 and 13 as I do =
not
>> have access . I trust the sponsoring AD to have gone through them and ve=
rified
>> that the item number references are correct.
>=20
> One of the few advantages of being associated with a university is that w=
e have a library.
> So I can pretend I got my copies from there...

:-)

>=20
>> Also the following text in Section 3 seems very handwavy and not particu=
larly
>> helpful. Is this necessary?
>>=20
>> "    It is not presently known to this author how
>>     the upcoming revision of IEC 80000-6 will update this, but it has
>>     became clear that there is strong interest in using this unit
>>     specifically for the imaginary content of complex power, reactive
>>     power [IEEE-1459]"
>=20
> I would like to keep the reference to IEEE 1459 (which is almost reasonab=
ly accessible), but I agree that the lamenting about IEC is not needed.
>=20
> Now in
> https://github.com/core-wg/senml-more-units/commit/d3ceb1bde39307c74f81b1=
a50724c05f2db49c8d
>=20
> Thank you!

Thanks. Looks good to me.

Regards
Suresh


From nobody Wed Feb 19 09:01:52 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C589F120914; Wed, 19 Feb 2020 09:01:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsIx-YoBxaDG; Wed, 19 Feb 2020 09:01:32 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 22EC41208CE; Wed, 19 Feb 2020 09:01:31 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01JH1RgZ008251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Feb 2020 12:01:29 -0500
Date: Wed, 19 Feb 2020 09:01:26 -0800
From: Benjamin Kaduk 
To: Carsten Bormann 
Cc: The IESG , draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org
Message-ID: <20200219170126.GE11645@kduck.mit.edu>
References: <158207175238.13976.4748538225663851323.idtracker@ietfa.amsl.com> <89E1D428-FF1B-4B42-BF1A-2BEF9B2C0B1B@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <89E1D428-FF1B-4B42-BF1A-2BEF9B2C0B1B@tzi.org>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-more-units-04: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 17:01:44 -0000

Hi Carsten,

Thanks for the updates; the changes in the -05 look good with just one
exception.  That, and some other comments, inline.

On Wed, Feb 19, 2020 at 01:50:57PM +0100, Carsten Bormann wrote:
> Hi Ben,
> 
> thank you for your in-depth review.
> 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> >   +-----------+-------------------+-------+-----------+-----+---------+
> >   | secondary | description       | SenML |     scale | off | refer-  |
> >   | unit      |                   | unit  |           | set | ence    |
> >   +-----------+-------------------+-------+-----------+-----+---------+
> >   [...]
> >   | km        | kilometer         | km    |      1000 |   0 | RFCthis |
> > 
> > The associated SenML unit would be just 'm', not 'km'.
> 
> Oops.  Obviously, it is a consistency requirement that anything in column 3 needs to be present in the primary unit name registration table.
> 
> Fixed in https://github.com/core-wg/senml-more-units/commit/78c714ab6a6526291265ec1976807ab3e8aa3138
> 
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > I appreciate the compromise position that was achieved after the long
> > last-call discussions questioning the need for this work.  It seems like
> > a reasonably shaped "escape hatch" to me.
> > 
> > Section 2
> > 
> > I assume this is just a product of my personal background, but I am more
> > used to "mass density" than "mass concentration" for dimensionalities
> > such as kg/m3.
> 
> True, the unit can be used for both quantities.
> (The actual request leading up to this was for particle concentration meters, hence the mass concentration label.)
> That factoid is actually covered in
> https://www.iso.org/obp/ui/#iso:std:iso:80000:-1:ed-1:v1:en
> Section 3.7, example 2.
> Since the registry captures units, not quantities, I propose adding mass density to the parenthesis.
> 
> Now in https://github.com/core-wg/senml-more-units/commit/25072a9e5757ea0d4aff75d2415afb40a17a9e37
> 
> > Section 3
> > 
> >   o  The Byte.  [IEC-80000-13] defines both the bit (item 13-9.b) and
> >      the byte (item 13-9.c, also called octet) as alternative names for
> >      the coherent unit one for the purpose of giving storage capacity
> >      and related quantities.  While the name octet is associated with
> > 
> > nit: is "one" misplaced, here?
> 
> The coherent unit actually is “one”; see Section 3.8, Note 3, and Section 3.12, Note 4 in ISO 80000-1 as cited above.
> To make this easier to read, we could place it in quotes, except it is not a string, it is really the number 1.

I guess I kind of gave it away that I didn't follow the reference, here :)
It's probably too verbose to try something like "the coherent unit used for
dimensionless quantities and indicated by the numeral one".

> > Section 4
> > 
> >   o  scale, offset: two rational numbers, expressed in decimal
> >      (optionally, with a decimal exponent given) or as a fraction
> >      divided by a "/" character.
> > 
> > nit: doesn't "a fraction divided by a '/' character" involve two '/'
> > characters?  That is, "1/2" is a fraction, so "1/2 divided by a '/'
> > character" would be like "1/2/" or "1/2/2" or something nonsensical like
> > that.
> 
> “divided” as in “separated into two halves”, i.e., “1/2” is divided by a “/“ into a 1 and a 2.  Maybe we need better phrasing here.

Perhaps, "a fraction represented using a '/' character to separtae
numerator and denominator"?

> > It's a little surprising to see kibibyte and gigabyte defined but not
> > gibibyte.
> 
> It’s a registry, nobody asked for it yet…
> We could do some more proactive registering.
> 
> >   names.  Guidelines to the difference between units (which can go into
> >   the registry) and quantities are widely available, see for instance
> >   [RS] and [BIPM].
> > 
> > I suggest a parenthetical "(which cannot)" after "quantities".
> 
> Very good.
> 
> Now in https://github.com/core-wg/senml-more-units/commit/25072a9e5757ea0d4aff75d2415afb40a17a9e37
> 
> > 
> >   Where the benefits of directly using a secondary unit in a SenML pack
> >   outweigh the obove considerations, the use of secondary units in "u"
> > 
> > nit: s/obove/above/
> 
> (Covered earlier.)
> 
> >   specifically allows this and/or by using a field with a label name
> >   that ends with the "_" character ("must-understand" field) that
> >   specifically allows this.  The definition of these versions and
> > 
> > I suggest "whose definition specifically allows this".
> 
> Good point.
> 
> Now in
> https://github.com/core-wg/senml-more-units/commit/76f51849541b5a18a6ef2984507284d92514eb54
> 
> > 
> >   fields is outside the scope of the present specification; one such
> >   definition is provided in [I-D.bormann-core-senml-versions].
> > 
> > nit: I suggest "proposed definition" or "possible definition", as
> > internet-drafts are "works in progress".
> 
> Maybe shorter “..is proposed in”?
> I’ve put that into
> https://github.com/core-wg/senml-more-units/commit/8f2163a311e088a8cdfc30fa37df3a9f175c87e3

Sure.

> > Section 5
> > 
> >   potential single point of failure.  Instead of pulling the registry
> >   in each individual instance of the code, the software update
> >   mechanism (or a similar, less frequently triggered mechanism) SHOULD
> >   be used to disseminate updated units registries obtained from IANA
> >   towards the instances via common repositories.
> > 
> > I like how this blandly assumes that a software update mechanism is
> > available.  Optimistic for the present-day world, but still probably the
> > right thing to say.
> > nit: as written, "less frequently triggered mechanism" means "less
> > frequently triggered than the software update mechanism", which I
> > suspect is not the intent.
> 
> I have turned this into
> 
> (or a similar
> mechanism visiting IANA less frequently)

This is better, but I think that "less frequently" is still an implied
comparison, and the comparison against software-update is more local than
the (intended) comparison against the generic/abstract "usual frequency" or
"every time an instance of the system starts up or checks".  I might
suggest "a similar mechanims that only visits IANA infrequently".

> in https://github.com/core-wg/senml-more-units/commit/8656620080aa6d0d2a422476a7a5693e931e6f3e
> 
> > Section 6
> > 
> > I suggest reiterating the implications of the requirements at the end of
> > section 4, namely, that use of new units is "fail-safe", in that an
> > implementation processing a pack using secondary units is guaranteed to
> > have been developed with an awareness of the risks of having multiple
> > units available for the same logical type.  (It is not, of course,
> > guaranteed to know about the specific secondary unit in question when
> > just the "SenML Version" check is used, in the same way that current
> > SenML applications are not guaranteed to know about units not in the
> > initial allocation from RFC 8428.)
> > 
> >   The security considerations of [RFC8428] apply.  The introduction of
> >   new measurement units poses no additional security considerations
> >   except from a possible potential for additional confusion about the
> >   proper unit to use.
> > 
> > Nitpicking, but I think there's a related risk of confusion in terms of
> > what quantity has been measured and is indicated in a SenML pack, as
> > alluded to by the previous mention of "trigger[ing] on the presence of a
> > quantity in a certain unit".
> 
> I have tried to cover this in
> https://github.com/core-wg/senml-more-units/commit/532dce8315bf9c75af1d1150d078d2f91e6444c0

Thanks for all the updates; I've removed my Discuss accordingly.

-Ben


From nobody Wed Feb 19 10:07:27 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0938112083F; Wed, 19 Feb 2020 10:07:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBCSn1Yu696K; Wed, 19 Feb 2020 10:07:22 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5331208B3; Wed, 19 Feb 2020 10:07:21 -0800 (PST)
Received: from client-0044.vpn.uni-bremen.de (client-0044.vpn.uni-bremen.de [134.102.107.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48N5KJ4BgPzyRm; Wed, 19 Feb 2020 19:07:16 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <20200219170126.GE11645@kduck.mit.edu>
Date: Wed, 19 Feb 2020 19:07:15 +0100
Cc: The IESG , draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 603828435.299191-de11cc49f0886353e5fb78c322b16ce4
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B006531-021E-46AE-BCD9-DDD298EAEDCE@tzi.org>
References: <158207175238.13976.4748538225663851323.idtracker@ietfa.amsl.com> <89E1D428-FF1B-4B42-BF1A-2BEF9B2C0B1B@tzi.org> <20200219170126.GE11645@kduck.mit.edu>
To: Benjamin Kaduk 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-more-units-04: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 18:07:25 -0000

Hi Ben,

> On 2020-02-19, at 18:01, Benjamin Kaduk  wrote:
>=20
> Hi Carsten,
>=20
> Thanks for the updates; the changes in the -05 look good with just one
> exception.  That, and some other comments, inline.
>=20
>>=20
>>> =
----------------------------------------------------------------------
>>> COMMENT:
>>> =
----------------------------------------------------------------------
>>>=20
>>=20
>>> Section 3
>>>=20
>>>  o  The Byte.  [IEC-80000-13] defines both the bit (item 13-9.b) and
>>>     the byte (item 13-9.c, also called octet) as alternative names =
for
>>>     the coherent unit one for the purpose of giving storage capacity
>>>     and related quantities.  While the name octet is associated with
>>>=20
>>> nit: is "one" misplaced, here?
>>=20
>> The coherent unit actually is =E2=80=9Cone=E2=80=9D; see Section 3.8, =
Note 3, and Section 3.12, Note 4 in ISO 80000-1 as cited above.
>> To make this easier to read, we could place it in quotes, except it =
is not a string, it is really the number 1.
>=20
> I guess I kind of gave it away that I didn't follow the reference, =
here :)
> It's probably too verbose to try something like "the coherent unit =
used for
> dimensionless quantities and indicated by the numeral one".

Maybe not the whole thing, but I like "the coherent unit used for
dimensionless quantities=E2=80=9D instead of "coherent unit one=E2=80=9D. =
 People who understand the latter will always understand the former.

>>> Section 4
>>>=20
>>>  o  scale, offset: two rational numbers, expressed in decimal
>>>     (optionally, with a decimal exponent given) or as a fraction
>>>     divided by a "/" character.
>>>=20
>>> nit: doesn't "a fraction divided by a '/' character" involve two '/'
>>> characters?  That is, "1/2" is a fraction, so "1/2 divided by a '/'
>>> character" would be like "1/2/" or "1/2/2" or something nonsensical =
like
>>> that.
>>=20
>> =E2=80=9Cdivided=E2=80=9D as in =E2=80=9Cseparated into two =
halves=E2=80=9D, i.e., =E2=80=9C1/2=E2=80=9D is divided by a =E2=80=9C/=E2=
=80=9C into a 1 and a 2.  Maybe we need better phrasing here.
>=20
> Perhaps, "a fraction represented using a '/' character to separtae
> numerator and denominator"?

That works very well.

>> [=E2=80=A6]
>> I have turned this into
>>=20
>> (or a similar
>> mechanism visiting IANA less frequently)
>=20
> This is better, but I think that "less frequently" is still an implied
> comparison, and the comparison against software-update is more local =
than
> the (intended) comparison against the generic/abstract "usual =
frequency" or
> "every time an instance of the system starts up or checks".  I might
> suggest "a similar mechanims that only visits IANA infrequently".

I think the criticism of visiting IANA from every instance should be =
clear here, so it seems to me people should be able to relate the =
=E2=80=9Cvisit IANA less frequently=E2=80=9D to the =E2=80=9Cdownload =
=E2=80=A6 from IANA frequently=E2=80=9D above.  (I=E2=80=99m not sure =
what infrequently means; I think once an hour would be fine for a major =
software package that then distributes updates via software update =
mechanism.)
Maybe =E2=80=9Cthat leads to less frequent IANA visits=E2=80=9D is even =
clearer?
(Because it=E2=80=99s not the software update mechanism itself that =
visits IANA.)

[=E2=80=A6]

Proposed updates in
=
https://github.com/core-wg/senml-more-units/commit/ebb13e358e59327d243f4df=
f617c9b19b5168cd9

Gr=C3=BC=C3=9Fe, Carsten


From nobody Wed Feb 19 11:24:30 2020
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 970CF12004C; Wed, 19 Feb 2020 11:24:25 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker 
To: "The IESG" 
Cc: draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime@iki.fi, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alissa Cooper 
Message-ID: <158214026560.17758.14708027057984145572.idtracker@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 11:24:25 -0800
Archived-At: 
Subject: [core] Alissa Cooper's Discuss on draft-ietf-core-senml-more-units-05: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 19:24:26 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-core-senml-more-units-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have some questions and comments about the text below, which seems like it
creates significant scope for interoperability failures:

"Where the benefits of directly using a secondary unit in a SenML pack
   outweigh the above considerations, the use of secondary units in "u"
   fields MAY be enabled by indicating a new SenML version that
   specifically allows this and/or by using a field with a label name
   that ends with the "_" character ("must-understand" field) whose
   definition specifically allows this.  The definition of these
   versions and fields is outside the scope of the present
   specification; one such definition is proposed in
   [I-D.bormann-core-senml-versions]."

Do I understand correctly that this allows secondary units in (1) SenML packs
that use some version number besides 10, and (2) SenML fields named with "_"
that are in packs where the version number is 10? What is the motivation for
providing two different mechanisms to signal that secondary units are in use?
I.e., why isn't one or the other of these mechanisms sufficient?

Without defining either a new version that supports secondary units or fields
with "_", I don't understand how this update to RFC 8428 is complete enough to
be implementable. It says other versions and fields are out of scope, but don't
some need to be defined in order for the normative MAY in this text to be
actionable?

The label names registry policy is Expert Review, which does not require formal
documentation of the registry entry. Where is the "definition [that]
specifically allows this" expected to occur?

Presumably some implementations are already using SenML. What is an
implementation supposed to do if it encounters a label name containing "_" that
it does not understand in a version 10 pack?

It looks like this text went in a week ago but it's a pretty significant change
to the extensibility story for SenML, so I'm wondering if the WG had a chance
to come to consensus on it?

I'm not super familiar with SenML so apologies if the answers to some of these
questions are obvious.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

'The unit "degrees" is in wide use in practice for plane angles (as in
   heading, bearing, etc.).  It is marked with an asterisk because the
   preferred coherent SI unit is radian ("rad").'

Is this asterisk notation meant to be common across all units that have this
same property? If so, that seems worth specifying more generally, not just for
degrees.



From nobody Wed Feb 19 11:27:58 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FE6120086; Wed, 19 Feb 2020 11:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Ty1alwsy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HDw7NtVa
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cfvvon1NQBj; Wed, 19 Feb 2020 11:27:47 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A79120045; Wed, 19 Feb 2020 11:27:47 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C023721E92; Wed, 19 Feb 2020 14:27:46 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 19 Feb 2020 14:27:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=hhRPLq7N9pA5wP1d3eCPnDE dUKM1kqekb2aWVqj2nUE=; b=Ty1alwsyfe6Mx9DXaTpXpSrq0mWG5sBB4XC42og pZpxAudFS+jW1vyvuuLAXHr4dmKehM0LrLYXYMWdMaDYHdujqxEQybrcEi9NZwgg lnDFx5IzHKzoO6EGFDdEzVME+KcjqE++O1xKGDdks2Vh3N8tyHXDVVAdrf/nOfoh r3kNy6c1sdOYPYtjNnSvd2nspEVyUB7NLWeBWKgm5dCPeJM5E00raaMVO3URckdR uPWVrkhnsi6KYztK1qnX14B9oOzy9dY3wJUR1KHgqZ8b1VE24Awi4FaYF6w/GiEE OaU9ht2WnLsmLLqx7QU2JIMBF8gfM4BnNXz5tQMvhekClvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=hhRPLq 7N9pA5wP1d3eCPnDEdUKM1kqekb2aWVqj2nUE=; b=HDw7NtVaryArudFs6sKVOD HMuDLQLMLVAi39rhDsWO5eCU5wswlXkl+cNbZiLmN5VaxID2WbcFAIlXeqXD28cd R8YHTZohFGKywRzRbNc+3Ro3VeCJLEAOxPJfNMPkJoBzwIC/C2RgSUcVjkXKNupv zOi3G9ZR7pdm5J+qJlbgH17gnQmXBlAduADLPvCH89UEpuVvB+Nv406jfJDj2juq dmve7bUekLRxSt1rb+cdvuTtJwzs9p8PaeCCsNVJjJK4Of7oWp5a7Xk4gottVw0v 6EQDgzFX5TkHGUyrUcDr+rxrQ/5i+82aVMJDkszU5ff8ZDDXx5uzR+pzVJs+jgOQ ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkedtgdduvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekvdenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghooh hpvghrfidrihhn
X-ME-Proxy:    
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id A5FC33280063; Wed, 19 Feb 2020 14:27:45 -0500 (EST)
From: Alissa Cooper 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_4EAB7FE2-15F9-47F5-85FA-AE7B61F023DB"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 19 Feb 2020 14:27:46 -0500
In-Reply-To: <0C6A661E-CDA5-4E99-96E4-5DDC1A03B6A1@tzi.org>
Cc: last-call@ietf.org, General Area Review Team , draft-ietf-core-senml-more-units.all@ietf.org, core@ietf.org
To: Carsten Bormann , Linda Dunbar 
References: <157254010642.30489.13409170000311799067@ietfa.amsl.com> <0C6A661E-CDA5-4E99-96E4-5DDC1A03B6A1@tzi.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [core] [Gen-art] Genart last call review of draft-ietf-core-senml-more-units-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 19:27:50 -0000

--Apple-Mail=_4EAB7FE2-15F9-47F5-85FA-AE7B61F023DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Linda, thanks for your review. Carsten, thanks for your response. I =
entered a DISCUSS ballot to ask some questions about interoperability.

Best,
Alissa


> On Oct 31, 2019, at 1:21 PM, Carsten Bormann  wrote:
>=20
> Hi Linda,
>=20
> thank you for this review.
>=20
>> On Oct 31, 2019, at 17:41, Linda Dunbar via Datatracker =
 wrote:
>>=20
>> Reviewer: Linda Dunbar
>> Review result: Ready
>>=20
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>=20
>> For more information, please see the FAQ at
>>=20
>> .
>>=20
>> Document: draft-ietf-core-senml-more-units-??
>> Reviewer: Linda Dunbar
>> Review Date: 2019-10-31
>> IETF LC End Date: 2019-10-30
>> IESG Telechat date: Not scheduled for a telechat
>>=20
>> Summary:  The document is very light, describing IANA registration =
for acronyms
>> for various UNITs, such as "ms" for Millisecond, "min" for Minute, =
"kW" for
>> Kilowatt, etc. While there is no problem of those acronyms, I don't =
really
>> understand why it is necessary to have an RFC for this purpose. Many =
IETF areas
>> don=E2=80=99t even allow Gap Analysis drafts to be published as RFCs.
>=20
> Registrations to an existing registry indeed do not require an RFC.
>=20
> However, beyond registering a few values, this draft also
>=20
> =E2=80=94 creates a new registry and defines its expert review =
instructions,
> =E2=80=94 updates Standards Track RFC 8428 to accept values from this =
registry in a place previously governed only by a different registry.
>=20
> While there is still some ongoing debate about whether this was the =
right approach to address the requirements, if we uphold this approach =
we will require an RFC.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org 
> https://www.ietf.org/mailman/listinfo/gen-art =


--Apple-Mail=_4EAB7FE2-15F9-47F5-85FA-AE7B61F023DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Linda, thanks for your review. Carsten, thanks for your =
response. I entered a DISCUSS ballot to ask some questions about =
interoperability.

Best,
Alissa


On Oct 31, 2019, at 1:21 PM, Carsten Bormann <cabo@tzi.org> =
wrote:

Hi Linda,

thank you for this =
review.

On =
Oct 31, 2019, at 17:41, Linda Dunbar via Datatracker <noreply@ietf.org> =
wrote:

Reviewer: Linda Dunbar
Review result: Ready

I am the =
assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being =
processed
by the IESG for the IETF Chair.  Please =
treat these comments just
like any other last call =
comments.

For more information, please see =
the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: =
draft-ietf-core-senml-more-units-??
Reviewer: Linda =
Dunbar
Review Date: 2019-10-31
IETF LC End =
Date: 2019-10-30
IESG Telechat date: Not scheduled for a =
telechat

Summary:  The document is =
very light, describing IANA registration for acronyms
for =
various UNITs, such as "ms" for Millisecond, "min" for Minute, "kW" =
for
Kilowatt, etc. While there is no problem of those =
acronyms, I don't really
understand why it is necessary to =
have an RFC for this purpose. Many IETF areas
don=E2=80=99t =
even allow Gap Analysis drafts to be published as RFCs.

Registrations to an existing registry indeed do not require =
an RFC.

However, =
beyond registering a few values, this draft also

=E2=80=94 creates a new registry =
and defines its expert review instructions,
=E2=80=94 updates Standards =
Track RFC 8428 to accept values from this registry in a place previously =
governed only by a different registry.

While there is still some ongoing debate about whether this =
was the right approach to address the requirements, if we uphold this =
approach we will require an RFC.

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

=

--Apple-Mail=_4EAB7FE2-15F9-47F5-85FA-AE7B61F023DB--


From nobody Wed Feb 19 11:40:32 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C72B120130; Wed, 19 Feb 2020 11:40:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N0BMn3w6fDD; Wed, 19 Feb 2020 11:40:20 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448D8120112; Wed, 19 Feb 2020 11:40:20 -0800 (PST)
Received: from client-0044.vpn.uni-bremen.de (client-0044.vpn.uni-bremen.de [134.102.107.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48N7Nd5Br0z10t0; Wed, 19 Feb 2020 20:40:17 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <158214026560.17758.14708027057984145572.idtracker@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 20:40:16 +0100
Cc: The IESG , draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 603834016.45249-e7bce1bd1497a3ad5b9f7876fc942b97
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A0DCEE2-15B0-475F-BE7B-706CFEE886D4@tzi.org>
References: <158214026560.17758.14708027057984145572.idtracker@ietfa.amsl.com>
To: Alissa Cooper 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [core] Alissa Cooper's Discuss on draft-ietf-core-senml-more-units-05: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 19:40:24 -0000

Hi Alissa,

Thank you for your concern about interoperability.

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>=20
> I have some questions and comments about the text below, which seems =
like it
> creates significant scope for interoperability failures:
>=20
> "Where the benefits of directly using a secondary unit in a SenML pack
>   outweigh the above considerations, the use of secondary units in "u"
>   fields MAY be enabled by indicating a new SenML version that
>   specifically allows this and/or by using a field with a label name
>   that ends with the "_" character ("must-understand" field) whose
>   definition specifically allows this.  The definition of these
>   versions and fields is outside the scope of the present
>   specification; one such definition is proposed in
>   [I-D.bormann-core-senml-versions]."
>=20
> Do I understand correctly that this allows secondary units in (1) =
SenML packs
> that use some version number besides 10,

(If that version specifically allows the use of secondary units)

> and (2) SenML fields named with "_"
> that are in packs where the version number is 10?

(Or any other version number that may not on its own specifically allow =
the use of secondary units)
(If that =E2=80=9Cmust-understand=E2=80=9D field specifically allows the =
use of secondary units)

> What is the motivation for
> providing two different mechanisms to signal that secondary units are =
in use?
> I.e., why isn't one or the other of these mechanisms sufficient?

Because we don=E2=80=99t want to prejudice the decision how this is =
indicated.
(If we had known about the considerations about enabling secondary units =
earlier, we could have done that in time for this specification.  The =
tight timeline of this specification is based on the use of the same =
secondary units registry in data model specifications that underly data =
exchanged in SenML and other formats.  So there is no need to decide =
this mechanism right now for the initial use of the registry.)

> Without defining either a new version that supports secondary units or =
fields
> with "_", I don't understand how this update to RFC 8428 is complete =
enough to
> be implementable.

We decided that this draft is not updating RFC 8428, so it is not =
implementable without defining either of the mechanisms or the data =
models defined by other SDOs.
draft-bormann-core-senml-versions-00 is my best guess of where we will =
come out with the discussion of the former; the latter is in progress, =
waiting for this draft to be published.

> It says other versions and fields are out of scope, but don't
> some need to be defined in order for the normative MAY in this text to =
be
> actionable?

See above.

> The label names registry policy is Expert Review, which does not =
require formal
> documentation of the registry entry. Where is the "definition [that]
> specifically allows this" expected to occur?

In the definition of the label.
If the label definition is not known by an implementation, it cannot =
accept SenML with such a =E2=80=9Cmust-understand=E2=80=9D label, so =
false interoperability is effectively excluded.

> Presumably some implementations are already using SenML. What is an
> implementation supposed to do if it encounters a label name containing =
"_" that
> it does not understand in a version 10 pack?

Do not accept the pack.  (Note that this kind of =E2=80=9Cmust-understand=E2=
=80=9D label is a feature of RFC 8428, not of this draft.)

> It looks like this text went in a week ago but it's a pretty =
significant change
> to the extensibility story for SenML, so I'm wondering if the WG had a =
chance
> to come to consensus on it?

The WG consensus was more on the side of simply accepting SenML packs =
with secondary units.
But it was rough consensus, and a simple solution could be found, so we =
went for this.  We did announce the intent to make this change on the WG =
list, on 2020-02-11, after extensive discussion between many of the main =
stakeholders.

[=E2=80=A6]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> 'The unit "degrees" is in wide use in practice for plane angles (as in
>   heading, bearing, etc.).  It is marked with an asterisk because the
>   preferred coherent SI unit is radian ("rad").'
>=20
> Is this asterisk notation meant to be common across all units that =
have this
> same property? If so, that seems worth specifying more generally, not =
just for
> degrees.

The asterisk indication is defined in Section 12.1 of RFC 8428, for =
which this section is a registration.

Gr=C3=BC=C3=9Fe, Carsten



From nobody Wed Feb 19 12:16:38 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48267120639; Wed, 19 Feb 2020 12:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=AZPyZ7PA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yd/fZWEI
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9AJ2ZYDKD3i; Wed, 19 Feb 2020 12:16:27 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2718412016E; Wed, 19 Feb 2020 12:16:27 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 47C0971D; Wed, 19 Feb 2020 15:16:25 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 19 Feb 2020 15:16:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=p AJ8q2mRTP+Ppu4MFK2fDYw2qTUNvmeY3kbHb7PS1JQ=; b=AZPyZ7PAIv6wqpU1H wD6HCwkuUx8mBxi/5wd6tRWEWDIh7pWTCqporp/9+HQLUD5BuEbXDg2faI+MCtbn efbopX/I6VilvjdGUXXx9WnPivNjd/wCSWlzYsjrlCukfNNCKRndiZKhFyyLBj6z 6d486/Ecng3tUhz7ckJNjSXeCYPrn5Z0bFYszvPL6Io1xEbn2G749agEofjsV3oZ vBOml3a2xOO2TwMmUXZAB3iNWGAY8euhHyESEex+0jG4jX5HY6otvqKMsKeTgJrt dJk0qc2QRuhFwLgeT6B+6J/3rZnA98fjOdEmCHbO41HM8ZtxoEDhUh0JgHiScPYI nhebQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=pAJ8q2mRTP+Ppu4MFK2fDYw2qTUNvmeY3kbHb7PS1 JQ=; b=yd/fZWEInUd9pmuEh2KaQhqdNa1gd/Ae99Sn+bB4ZF7xMhzKRUJU2xNWT DgMM6vYAZr3yyYXJV4HD8BrJfYtRbXe0jEpRE28b9/KbqpwgfDnEnen/K7eFiFJQ WH7StNF3fvsp/PocPw6ele4pk+zo1cvVpkiqFlvYovxDwlTljk6AezCd+lsIUMdL R4i1bvVrd3Jfj1pDmNWx6ydWb7Vv/AzB9IwJyc1Ugsvff0oDyL3rhNdbiql+hvtf dwj6hxWas//b1EQ8eEZ57CrHZwH/YgPbSC6xH7vjXkePNpi1nCQcGl4Jze13Brda nEmphBsK5ku0MQJh7GjtDepIhizrw==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkedtgddufeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepsghorhhmrghnnhdqtghorhgvqdhsvghnmhhlqdhvvghrshhiohhnshdrughonecu kfhppedujeefrdefkedruddujedrkedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh
X-ME-Proxy:    
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id 2D431328005A; Wed, 19 Feb 2020 15:16:24 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper 
In-Reply-To: <0A0DCEE2-15B0-475F-BE7B-706CFEE886D4@tzi.org>
Date: Wed, 19 Feb 2020 15:16:25 -0500
Cc: IESG , draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <158214026560.17758.14708027057984145572.idtracker@ietfa.amsl.com> <0A0DCEE2-15B0-475F-BE7B-706CFEE886D4@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [core] Alissa Cooper's Discuss on draft-ietf-core-senml-more-units-05: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 20:16:30 -0000

Hi Carsten,

A few responses below.

> On Feb 19, 2020, at 2:40 PM, Carsten Bormann  wrote:
>=20
> Hi Alissa,
>=20
> Thank you for your concern about interoperability.
>=20
>> =
----------------------------------------------------------------------
>> DISCUSS:
>> =
----------------------------------------------------------------------
>>=20
>> I have some questions and comments about the text below, which seems =
like it
>> creates significant scope for interoperability failures:
>>=20
>> "Where the benefits of directly using a secondary unit in a SenML =
pack
>>  outweigh the above considerations, the use of secondary units in "u"
>>  fields MAY be enabled by indicating a new SenML version that
>>  specifically allows this and/or by using a field with a label name
>>  that ends with the "_" character ("must-understand" field) whose
>>  definition specifically allows this.  The definition of these
>>  versions and fields is outside the scope of the present
>>  specification; one such definition is proposed in
>>  [I-D.bormann-core-senml-versions]."
>>=20
>> Do I understand correctly that this allows secondary units in (1) =
SenML packs
>> that use some version number besides 10,
>=20
> (If that version specifically allows the use of secondary units)
>=20
>> and (2) SenML fields named with "_"
>> that are in packs where the version number is 10?
>=20
> (Or any other version number that may not on its own specifically =
allow the use of secondary units)
> (If that =E2=80=9Cmust-understand=E2=80=9D field specifically allows =
the use of secondary units)
>=20
>> What is the motivation for
>> providing two different mechanisms to signal that secondary units are =
in use?
>> I.e., why isn't one or the other of these mechanisms sufficient?
>=20
> Because we don=E2=80=99t want to prejudice the decision how this is =
indicated.

Why not? What value is derived from having two ways of doing the same =
thing?

> (If we had known about the considerations about enabling secondary =
units earlier, we could have done that in time for this specification.  =
The tight timeline of this specification is based on the use of the same =
secondary units registry in data model specifications that underly data =
exchanged in SenML and other formats.  So there is no need to decide =
this mechanism right now for the initial use of the registry.)

What is the timeline, exactly? What is driving it?

>=20
>> Without defining either a new version that supports secondary units =
or fields
>> with "_", I don't understand how this update to RFC 8428 is complete =
enough to
>> be implementable.
>=20
> We decided that this draft is not updating RFC 8428, so it is not =
implementable without defining either of the mechanisms or the data =
models defined by other SDOs.

I don=E2=80=99t understand how this draft could not be updating RFC =
8428. RFC 8428 says:

"Systems reading one of the objects MUST check for the Base Version
   field.  If this value is a version number larger than the version
   that the system understands, the system MUST NOT use this object.
   This allows the version number to indicate that the object contains
   structure or semantics that is different from what is defined in the
   present document beyond just making use of the extension points
   provided here."

This drafts seems to be saying you can include fields with different =
structure and semantics from what is specified in RFC 8428, but still =
use version 10.

> draft-bormann-core-senml-versions-00 is my best guess of where we will =
come out with the discussion of the former; the latter is in progress, =
waiting for this draft to be published.
>=20
>> It says other versions and fields are out of scope, but don't
>> some need to be defined in order for the normative MAY in this text =
to be
>> actionable?
>=20
> See above.
>=20
>> The label names registry policy is Expert Review, which does not =
require formal
>> documentation of the registry entry. Where is the "definition [that]
>> specifically allows this" expected to occur?
>=20
> In the definition of the label.

So, that can be in a private email to the designated expert? If that is =
what is envisioned, the text in the draft is misleading.

> If the label definition is not known by an implementation, it cannot =
accept SenML with such a =E2=80=9Cmust-understand=E2=80=9D label, so =
false interoperability is effectively excluded.
>=20
>> Presumably some implementations are already using SenML. What is an
>> implementation supposed to do if it encounters a label name =
containing "_" that
>> it does not understand in a version 10 pack?
>=20
> Do not accept the pack.  (Note that this kind of =E2=80=9Cmust-understan=
d=E2=80=9D label is a feature of RFC 8428, not of this draft.)

Apologies, I see this now in RFC 8428.

Alissa


>=20
>> It looks like this text went in a week ago but it's a pretty =
significant change
>> to the extensibility story for SenML, so I'm wondering if the WG had =
a chance
>> to come to consensus on it?
>=20
> The WG consensus was more on the side of simply accepting SenML packs =
with secondary units.
> But it was rough consensus, and a simple solution could be found, so =
we went for this.  We did announce the intent to make this change on the =
WG list, on 2020-02-11, after extensive discussion between many of the =
main stakeholders.
>=20
> [=E2=80=A6]
>> =
----------------------------------------------------------------------
>> COMMENT:
>> =
----------------------------------------------------------------------
>>=20
>> 'The unit "degrees" is in wide use in practice for plane angles (as =
in
>>  heading, bearing, etc.).  It is marked with an asterisk because the
>>  preferred coherent SI unit is radian ("rad").'
>>=20
>> Is this asterisk notation meant to be common across all units that =
have this
>> same property? If so, that seems worth specifying more generally, not =
just for
>> degrees.
>=20
> The asterisk indication is defined in Section 12.1 of RFC 8428, for =
which this section is a registration.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
>=20


From nobody Wed Feb 19 14:14:04 2020
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AE6120860; Wed, 19 Feb 2020 14:14:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker 
To: "The IESG" 
Cc: draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime@iki.fi, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba 
Message-ID: <158215044208.17616.16546091696291519854.idtracker@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 14:14:02 -0800
Archived-At: 
Subject: [core] Barry Leiba's Yes on draft-ietf-core-senml-more-units-05: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 22:14:02 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-core-senml-more-units-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

You have a typo in section 4: "obove", where "above" is meant.

 + + + + + + + + + + + + + + + + + + + +

The following are comments from Murray Kucherawy, incoming ART AD.  Murray is
getting an early start on doing reviews, and I’m including his comments into my
ballots during the overlap period before he’s officially an Area Director.

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

Section 2: Just out of curiosity, why are some of the newly registered "VA"s
all-caps and some all-lowercase?

Section 4: I'm a bit uneasy about saying the rules for this new registry are
the same as for that older registry, with exceptions.  That means if the rules
for the old registry change, someone needs to remember to consider whether the
rules for the new registry should change in parallel, or whether something else
should happen.  But if there's precedent for doing that, or the result is
unambiguous, then we're probably fine.

Also, "six columns" followed by five bullets... I think I'd rather coax the
scale/offset line apart.

Seems to me that Section 2 and all but the last two paragraphs of Section 4
should be in Section 7.  I've never seen an "IANA Considerations" section be a
complete indirection like that.  But if we allow that, then OK.



From nobody Wed Feb 19 17:10:43 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC5C120041; Wed, 19 Feb 2020 17:10:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vxM35oCgj1C; Wed, 19 Feb 2020 17:10:32 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1ABF12029C; Wed, 19 Feb 2020 17:10:31 -0800 (PST)
Received: from client-0041.vpn.uni-bremen.de (client-0041.vpn.uni-bremen.de [134.102.107.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48NGjW65Cwz17y6; Thu, 20 Feb 2020 02:10:23 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <158215044208.17616.16546091696291519854.idtracker@ietfa.amsl.com>
Date: Thu, 20 Feb 2020 02:10:22 +0100
Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-senml-more-units@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 603853822.690876-fab891a1a7db756a9d6f29d793943684
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F29D0EF-AACE-40EB-BD28-A488BAD57854@tzi.org>
References: <158215044208.17616.16546091696291519854.idtracker@ietfa.amsl.com>
To: Barry Leiba 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [core] Barry Leiba's Yes on draft-ietf-core-senml-more-units-05: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Feb 2020 01:10:35 -0000

Hi Barry,

Thanks for relaying Murray=E2=80=99s input.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> You have a typo in section 4: "obove", where "above" is meant.

Fixed in =
https://github.com/core-wg/senml-more-units/commit/b31940f791e4a6da5e05d8d=
92e6eeea842820209 (now in -05).

>=20
> + + + + + + + + + + + + + + + + + + + +
>=20
> The following are comments from Murray Kucherawy, incoming ART AD.  =
Murray is
> getting an early start on doing reviews, and I=E2=80=99m including his =
comments into my
> ballots during the overlap period before he=E2=80=99s officially an =
Area Director.
>=20
> - - - - - - - - - - - - - - - - - - - -
>=20
> Section 2: Just out of curiosity, why are some of the newly registered =
"VA"s
> all-caps and some all-lowercase?

I don=E2=80=99t really know the history of the =E2=80=9Cvar=E2=80=9D =
moniker, but =E2=80=9CVA=E2=80=9D is just the product of =E2=80=9CV=E2=80=9D=
 and =E2=80=9CA=E2=80=9D =E2=80=94 the same coherent unit as =E2=80=9CW=E2=
=80=9D, but not meant as real power transfer ("active power"), but as =
=E2=80=9Capparent power=E2=80=9D.  V is for volt and A for ampere, two =
units that have been named after humans and therefore are always written =
in uppercase according to SI unit naming logic.=20

=E2=80=9Cvar=E2=80=9D is an acronym/shorthand for =E2=80=9CVA =
reactive=E2=80=9D, i.e. the imaginary part of the apparent power if =
viewed as a complex number (=E2=80=9Ccomplex power=E2=80=9D), and since =
it=E2=80=99s not named after a real person (Hal Varian? :-), it is in =
lower case, as are other artificial unit names such as meter (m), liter =
(l (*)), etc.  IEEE 1459 is the definitive document here, and IEC =
80000-6 has legitimized this under item 6-60.b (in turn pointing to IEC =
60050-131, which I don=E2=80=99t have).

> Section 4: I'm a bit uneasy about saying the rules for this new =
registry are
> the same as for that older registry, with exceptions.  That means if =
the rules
> for the old registry change, someone needs to remember to consider =
whether the
> rules for the new registry should change in parallel, or whether =
something else
> should happen.  But if there's precedent for doing that, or the result =
is
> unambiguous, then we're probably fine.

I don=E2=80=99t know about precedent, but I agree that any future =
updates to the rules for the primary registry should be considered for =
potential inclusion (or not) to an update to the rules for the secondary =
registry.  Since both are subregistries of the same top level registry, =
this will be hard to miss.

> Also, "six columns" followed by five bullets... I think I'd rather =
coax the
> scale/offset line apart.

I think any potential confusion is alleviated by the table that =
immediately follows and really has six columns.

> Seems to me that Section 2 and all but the last two paragraphs of =
Section 4
> should be in Section 7.  I've never seen an "IANA Considerations" =
section be a
> complete indirection like that.  But if we allow that, then OK.

Since the whole document is about creating registries and registering =
items, completely avoiding indirections would put everything into the =
IANA considerations section.
I=E2=80=99ll leave it to IANA to say whether the instructions are clear =
the way they are=E2=80=A6
(We definitely have precedent with Security Considerations sections =
saying that a document is entirely about security.)

Gr=C3=BC=C3=9Fe, Carsten

(*) I hit on the reluctantly granted exception here: according to some, =
but not other sources, liter may exceptionally also be abbreviated as =
=E2=80=9CL=E2=80=9D to make it typographically more different from =
=E2=80=9C1=E2=80=9D.

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


From nobody Wed Feb 19 17:31:20 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93186120143; Wed, 19 Feb 2020 17:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkvsePUqLAwv; Wed, 19 Feb 2020 17:31:12 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D10C1200F5; Wed, 19 Feb 2020 17:31:12 -0800 (PST)
Received: from client-0041.vpn.uni-bremen.de (client-0041.vpn.uni-bremen.de [134.102.107.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48NH9T63ftz17yK; Thu, 20 Feb 2020 02:31:09 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: 
Date: Thu, 20 Feb 2020 02:31:08 +0100
Cc: IESG , draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 603855068.657143-0b16c7109f804bfba6067c113041d9fb
Content-Transfer-Encoding: quoted-printable
Message-Id: <35697939-E603-431C-A9AA-88617ED107D5@tzi.org>
References: <158214026560.17758.14708027057984145572.idtracker@ietfa.amsl.com> <0A0DCEE2-15B0-475F-BE7B-706CFEE886D4@tzi.org> 
To: Alissa Cooper 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [core] Alissa Cooper's Discuss on draft-ietf-core-senml-more-units-05: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Feb 2020 01:31:18 -0000

Hi Alissa,

Let me try to answer this quickly, but there is a complex history around =
this that may easier be explained in person.

> On 2020-02-19, at 21:16, Alissa Cooper  wrote:
>=20
> Hi Carsten,
>=20
> A few responses below.
>=20
>> On Feb 19, 2020, at 2:40 PM, Carsten Bormann  wrote:
>>=20
>> Hi Alissa,
>>=20
>> Thank you for your concern about interoperability.
>>=20
>>> =
----------------------------------------------------------------------
>>> DISCUSS:
>>> =
----------------------------------------------------------------------
>>>=20
>>> I have some questions and comments about the text below, which seems =
like it
>>> creates significant scope for interoperability failures:
>>>=20
>>> "Where the benefits of directly using a secondary unit in a SenML =
pack
>>> outweigh the above considerations, the use of secondary units in "u"
>>> fields MAY be enabled by indicating a new SenML version that
>>> specifically allows this and/or by using a field with a label name
>>> that ends with the "_" character ("must-understand" field) whose
>>> definition specifically allows this.  The definition of these
>>> versions and fields is outside the scope of the present
>>> specification; one such definition is proposed in
>>> [I-D.bormann-core-senml-versions]."
>>>=20
>>> Do I understand correctly that this allows secondary units in (1) =
SenML packs
>>> that use some version number besides 10,
>>=20
>> (If that version specifically allows the use of secondary units)
>>=20
>>> and (2) SenML fields named with "_"
>>> that are in packs where the version number is 10?
>>=20
>> (Or any other version number that may not on its own specifically =
allow the use of secondary units)
>> (If that =E2=80=9Cmust-understand=E2=80=9D field specifically allows =
the use of secondary units)
>>=20
>>> What is the motivation for
>>> providing two different mechanisms to signal that secondary units =
are in use?
>>> I.e., why isn't one or the other of these mechanisms sufficient?
>>=20
>> Because we don=E2=80=99t want to prejudice the decision how this is =
indicated.
>=20
> Why not? What value is derived from having two ways of doing the same =
thing?

I don=E2=80=99t think we will have two ways in the end.  If we agree =
that draft-bormann-core-senml-versions is a good way to do this, I =
don=E2=80=99t think people will come up with other ways of specifically =
indicating this.  (There may be contexts outside of SenML packs where =
SenML units are being used that might merit other ways of indicating =
primary-only vs. primary/secondary.  So far I haven=E2=80=99t met =
those.)

>> (If we had known about the considerations about enabling secondary =
units earlier, we could have done that in time for this specification.  =
The tight timeline of this specification is based on the use of the same =
secondary units registry in data model specifications that underly data =
exchanged in SenML and other formats.  So there is no need to decide =
this mechanism right now for the initial use of the registry.)
>=20
> What is the timeline, exactly?

=E2=80=9CASAP=E2=80=9D=E2=80=A6 (I think the original timeline was CES =
2020, and we are already behind it.)

> What is driving it?

The use of the SenML unit registry as a general purpose registry for =
units used in IoT standards, specifically those being developed by other =
SDOs (OMA LWM2M/IPSO is leading this).

>>> Without defining either a new version that supports secondary units =
or fields
>>> with "_", I don't understand how this update to RFC 8428 is complete =
enough to
>>> be implementable.
>>=20
>> We decided that this draft is not updating RFC 8428, so it is not =
implementable without defining either of the mechanisms or the data =
models defined by other SDOs.
>=20
> I don=E2=80=99t understand how this draft could not be updating RFC =
8428. RFC 8428 says:
>=20
> "Systems reading one of the objects MUST check for the Base Version
>   field.  If this value is a version number larger than the version
>   that the system understands, the system MUST NOT use this object.
>   This allows the version number to indicate that the object contains
>   structure or semantics that is different from what is defined in the
>   present document beyond just making use of the extension points
>   provided here."
>=20
> This drafts seems to be saying you can include fields with different =
structure and semantics from what is specified in RFC 8428, but still =
use version 10.

RFC 8428 is not too specific on what the semantics for a newly defined =
field could be.
I would expect that it can supply additional semantics to existing =
fields, opening the avenue of using must-understand fields for what =
could also be considered version upgrades.
Section 12.2 of RFC 8428 says:

   Extensions that are mandatory to understand to correctly process the
   Pack MUST have a label name that ends with the "_" character.

I personally would prefer us going the draft-bormann-core-senml-versions =
way, where the version number is strengthened to be the main extension =
point, but consensus building on this has only just begun.

>> draft-bormann-core-senml-versions-00 is my best guess of where we =
will come out with the discussion of the former; the latter is in =
progress, waiting for this draft to be published.
>>=20
>>> It says other versions and fields are out of scope, but don't
>>> some need to be defined in order for the normative MAY in this text =
to be
>>> actionable?
>>=20
>> See above.
>>=20
>>> The label names registry policy is Expert Review, which does not =
require formal
>>> documentation of the registry entry. Where is the "definition [that]
>>> specifically allows this" expected to occur?
>>=20
>> In the definition of the label.
>=20
> So, that can be in a private email to the designated expert?

Yes, RFC 8428 allows that.  But that secrecy would make a =
=E2=80=9Cmust-understand=E2=80=9D field (with a label ending in =E2=80=9C_=
=E2=80=9D) hard to use except by those that are privy to this =
specification.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Thu Feb 20 04:37:22 2020
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 639681200F7; Thu, 20 Feb 2020 04:37:05 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Valery Smyslov via Datatracker 
To: 
Cc: last-call@ietf.org, draft-ietf-core-senml-more-units.all@ietf.org, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Valery Smyslov 
Message-ID: <158220222533.12408.17424909984121572707@ietfa.amsl.com>
Date: Thu, 20 Feb 2020 04:37:05 -0800
Archived-At: 
Subject: [core] Secdir telechat review of draft-ietf-core-senml-more-units-05
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Feb 2020 12:37:06 -0000

Reviewer: Valery Smyslov
Review result: Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

For some reason I've got the assignment to re-review this document past its
deadline (I've got the assignment today, 20 February, and the indicated
deadline for the review is 18 February, so I'm not sure whether this review is
still useful).

Anyway, the document has received some changes from -02 version which I
reviewed last time. In particular, Security Considerations section is enhanced
with the text describing a potential for a confusion about the proper unit to
use. While I'm not sure it's really a security condideration and not an
interoperability consideration, I agree that there are no additional threats
from security point of view.

And my concern about improper use of normative language is resolved.



From nobody Fri Feb 21 13:10:39 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C806412008A; Fri, 21 Feb 2020 13:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Pkct3U+q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E4GdnmFW
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM9PLAVyIgOx; Fri, 21 Feb 2020 13:10:35 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3624012008B; Fri, 21 Feb 2020 13:10:35 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 09CA56DD; Fri, 21 Feb 2020 16:10:33 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 21 Feb 2020 16:10:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=V m/TXv2q3Frb2PO6uumCSXFWsJuetzNYOFqVdaV4q60=; b=Pkct3U+q26iRjpvsQ ZzMjEDWj1+U7yQ8LZ/cIgDou2u9iT94l4A5d2PtS05NUWRUa//zu3dVrb8d6IwZZ TbxLBVhYM3JQUayMZXk/4dif4ZGVin8CV9f7IA6sbFoz/6cEjPSuYeHxT0c+/o2u M8bVubakZzwFdhQ8ewyee3svJR8Xuw+dQydy+SWmw0KONNXxZwY+67dJSV3JtoVJ OkFNvreQH9D8cefivkWNLXPabX1LU+izd83Zhaq15ViRpcGJERttaC6wC2XlUdao 94daxAIfC1XcufGilzl3ZZmEVBKHRgvIXsAfgC8ZbjRvRBzf7mDQPrXjqBgimzCt kTUbQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Vm/TXv2q3Frb2PO6uumCSXFWsJuetzNYOFqVdaV4q 60=; b=E4GdnmFWYfN8kvXVajA+kpl/scMQOlY8nqGXlhJBhsMgY91fqZx3N2I2s X5pBRj2TqLbQKgmwBbvr0BhoEqOc8/62R75i11EY3cOMMGgyajC1hIlV/X0olhfV JHQGr55VdqjSwL3ZSoQ99I2Uli90e3bzqFqwgGmNa55m5mhgqAT2ZP/K0fwyrszu Psr8upev7eMucCRHq1qSANfmnFlwvXm+SANo6qt1/UbFOpDPQlx/niMTvwmMR9N6 knw2knZZPs2XS5xBP/0O00xiXZ1vVRIPkhGH1ppyVNc4Bfl3TrPiTRW7gRcHzsEP i4KPF50OnRD4iimeC+O5IJSsZSDqg==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeeggddugeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepsghorhhmrghnnhdqtghorhgvqdhsvghnmhhlqdhvvghrshhiohhnshdrughonecu kfhppedutdekrdehuddruddtuddrleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh
X-ME-Proxy:    
Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id F1D57328005A; Fri, 21 Feb 2020 16:10:32 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper 
In-Reply-To: <35697939-E603-431C-A9AA-88617ED107D5@tzi.org>
Date: Fri, 21 Feb 2020 16:10:31 -0500
Cc: IESG , draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <158214026560.17758.14708027057984145572.idtracker@ietfa.amsl.com> <0A0DCEE2-15B0-475F-BE7B-706CFEE886D4@tzi.org>  <35697939-E603-431C-A9AA-88617ED107D5@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [core] Alissa Cooper's Discuss on draft-ietf-core-senml-more-units-05: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Feb 2020 21:10:38 -0000

Hi Carsten, all,

I guess I=E2=80=99m not really following the logic here. If it=E2=80=99s =
so urgent that this specification be approved today, are there =
implementations out there ready to interpret version 10 SenML packs =
containing fields labeled with =E2=80=9C_=E2=80=9D that are using =
secondary units? If so, why can=E2=80=99t this spec just update RFC 8428 =
to clarify the ambiguity that you can have different structure/semantics =
without changing the version number, and drop the idea of signaling =
secondary units with a new version number? Conversely, if there aren=E2=80=
=99t implementations prepared to use =E2=80=9C_=E2=80=9D fields for =
secondary units, why can=E2=80=99t the WG take the time to specify =
versioning correctly and use versioning as the signaling mechanism?

Thanks,
Alissa


> On Feb 19, 2020, at 8:31 PM, Carsten Bormann  wrote:
>=20
> Hi Alissa,
>=20
> Let me try to answer this quickly, but there is a complex history =
around this that may easier be explained in person.
>=20
>> On 2020-02-19, at 21:16, Alissa Cooper  wrote:
>>=20
>> Hi Carsten,
>>=20
>> A few responses below.
>>=20
>>> On Feb 19, 2020, at 2:40 PM, Carsten Bormann  wrote:
>>>=20
>>> Hi Alissa,
>>>=20
>>> Thank you for your concern about interoperability.
>>>=20
>>>> =
----------------------------------------------------------------------
>>>> DISCUSS:
>>>> =
----------------------------------------------------------------------
>>>>=20
>>>> I have some questions and comments about the text below, which =
seems like it
>>>> creates significant scope for interoperability failures:
>>>>=20
>>>> "Where the benefits of directly using a secondary unit in a SenML =
pack
>>>> outweigh the above considerations, the use of secondary units in =
"u"
>>>> fields MAY be enabled by indicating a new SenML version that
>>>> specifically allows this and/or by using a field with a label name
>>>> that ends with the "_" character ("must-understand" field) whose
>>>> definition specifically allows this.  The definition of these
>>>> versions and fields is outside the scope of the present
>>>> specification; one such definition is proposed in
>>>> [I-D.bormann-core-senml-versions]."
>>>>=20
>>>> Do I understand correctly that this allows secondary units in (1) =
SenML packs
>>>> that use some version number besides 10,
>>>=20
>>> (If that version specifically allows the use of secondary units)
>>>=20
>>>> and (2) SenML fields named with "_"
>>>> that are in packs where the version number is 10?
>>>=20
>>> (Or any other version number that may not on its own specifically =
allow the use of secondary units)
>>> (If that =E2=80=9Cmust-understand=E2=80=9D field specifically allows =
the use of secondary units)
>>>=20
>>>> What is the motivation for
>>>> providing two different mechanisms to signal that secondary units =
are in use?
>>>> I.e., why isn't one or the other of these mechanisms sufficient?
>>>=20
>>> Because we don=E2=80=99t want to prejudice the decision how this is =
indicated.
>>=20
>> Why not? What value is derived from having two ways of doing the same =
thing?
>=20
> I don=E2=80=99t think we will have two ways in the end.  If we agree =
that draft-bormann-core-senml-versions is a good way to do this, I =
don=E2=80=99t think people will come up with other ways of specifically =
indicating this.  (There may be contexts outside of SenML packs where =
SenML units are being used that might merit other ways of indicating =
primary-only vs. primary/secondary.  So far I haven=E2=80=99t met =
those.)
>=20
>>> (If we had known about the considerations about enabling secondary =
units earlier, we could have done that in time for this specification.  =
The tight timeline of this specification is based on the use of the same =
secondary units registry in data model specifications that underly data =
exchanged in SenML and other formats.  So there is no need to decide =
this mechanism right now for the initial use of the registry.)
>>=20
>> What is the timeline, exactly?
>=20
> =E2=80=9CASAP=E2=80=9D=E2=80=A6 (I think the original timeline was CES =
2020, and we are already behind it.)
>=20
>> What is driving it?
>=20
> The use of the SenML unit registry as a general purpose registry for =
units used in IoT standards, specifically those being developed by other =
SDOs (OMA LWM2M/IPSO is leading this).
>=20
>>>> Without defining either a new version that supports secondary units =
or fields
>>>> with "_", I don't understand how this update to RFC 8428 is =
complete enough to
>>>> be implementable.
>>>=20
>>> We decided that this draft is not updating RFC 8428, so it is not =
implementable without defining either of the mechanisms or the data =
models defined by other SDOs.
>>=20
>> I don=E2=80=99t understand how this draft could not be updating RFC =
8428. RFC 8428 says:
>>=20
>> "Systems reading one of the objects MUST check for the Base Version
>>  field.  If this value is a version number larger than the version
>>  that the system understands, the system MUST NOT use this object.
>>  This allows the version number to indicate that the object contains
>>  structure or semantics that is different from what is defined in the
>>  present document beyond just making use of the extension points
>>  provided here."
>>=20
>> This drafts seems to be saying you can include fields with different =
structure and semantics from what is specified in RFC 8428, but still =
use version 10.
>=20
> RFC 8428 is not too specific on what the semantics for a newly defined =
field could be.
> I would expect that it can supply additional semantics to existing =
fields, opening the avenue of using must-understand fields for what =
could also be considered version upgrades.
> Section 12.2 of RFC 8428 says:
>=20
>   Extensions that are mandatory to understand to correctly process the
>   Pack MUST have a label name that ends with the "_" character.
>=20
> I personally would prefer us going the =
draft-bormann-core-senml-versions way, where the version number is =
strengthened to be the main extension point, but consensus building on =
this has only just begun.
>=20
>>> draft-bormann-core-senml-versions-00 is my best guess of where we =
will come out with the discussion of the former; the latter is in =
progress, waiting for this draft to be published.
>>>=20
>>>> It says other versions and fields are out of scope, but don't
>>>> some need to be defined in order for the normative MAY in this text =
to be
>>>> actionable?
>>>=20
>>> See above.
>>>=20
>>>> The label names registry policy is Expert Review, which does not =
require formal
>>>> documentation of the registry entry. Where is the "definition =
[that]
>>>> specifically allows this" expected to occur?
>>>=20
>>> In the definition of the label.
>>=20
>> So, that can be in a private email to the designated expert?
>=20
> Yes, RFC 8428 allows that.  But that secrecy would make a =
=E2=80=9Cmust-understand=E2=80=9D field (with a label ending in =E2=80=9C_=
=E2=80=9D) hard to use except by those that are privy to this =
specification.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20


From nobody Fri Feb 21 21:56:02 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DC51200F1; Fri, 21 Feb 2020 21:55:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5QaVWKgjEGE; Fri, 21 Feb 2020 21:55:47 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2019D12006D; Fri, 21 Feb 2020 21:55:47 -0800 (PST)
Received: from [172.16.42.113] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48Pcxq6fHVz182Z; Sat, 22 Feb 2020 06:55:43 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: 
Date: Sat, 22 Feb 2020 06:55:43 +0100
Cc: IESG , draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 604043743.368928-2fd42512d163fcd9c5a9549a08a8d6a5
Content-Transfer-Encoding: quoted-printable
Message-Id: <42592C5F-C4F2-4905-971A-51CE600C8C0C@tzi.org>
References: <158214026560.17758.14708027057984145572.idtracker@ietfa.amsl.com> <0A0DCEE2-15B0-475F-BE7B-706CFEE886D4@tzi.org>  <35697939-E603-431C-A9AA-88617ED107D5@tzi.org> 
To: Alissa Cooper 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [core] Alissa Cooper's Discuss on draft-ietf-core-senml-more-units-05: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Feb 2020 05:55:53 -0000

On 2020-02-21, at 22:10, Alissa Cooper  wrote:
>=20
> Hi Carsten, all,
>=20
> I guess I=E2=80=99m not really following the logic here. If it=E2=80=99s=
 so urgent that this specification be approved today, are there =
implementations out there ready to interpret version 10 SenML packs =
containing fields labeled with =E2=80=9C_=E2=80=9D that are using =
secondary units?

Hi Alissa,

the initial user of this spec will be OMA, with the IPSO objects.  These =
use SenML in an interesting way: Unit information (and other meta =
information) is maintained at the data model level, so the actual Packs =
interchanged do not contain =E2=80=9Cu=E2=80=9D fields, at least not =
now.  So senml-more-units becomes immediately applicable for the unit =
names in those data models, before we define how to do interchange with =
unit names in the data packets.  The data models currently use primary =
SenML units and/or the units that will constitute the secondary =
registry, currently by maintaining their own copy/subset of the =
secondary registry at =
https://github.com/OpenMobileAlliance/lwm2m-registry/blob/test/LWM2M_senml=
_units.xml
We need to get rid of this duplication (and potential for divergence), =
which is also pretty much a prerequisite for other SDOs accepting SenML =
units as the common way to go for their data model initiatives.

Eventually, =E2=80=9Cu=E2=80=9D fields *will* need to turn up in some of =
the SenML data being interchanged, and that is the time when we will =
have to have developed a common position on how to indicate usage of =
this feature in a SenML Pack.

> If so, why can=E2=80=99t this spec just update RFC 8428 to clarify the =
ambiguity that you can have different structure/semantics without =
changing the version number, and drop the idea of signaling secondary =
units with a new version number? Conversely, if there aren=E2=80=99t =
implementations prepared to use =E2=80=9C_=E2=80=9D fields for secondary =
units, why can=E2=80=99t the WG take the time to specify versioning =
correctly and use versioning as the signaling mechanism?

That is a discussion still to be had, and =
draft-bormann-core-senml-versions is a result of preliminary discussions =
how to best do this.  I know I have an opinion on this, after a month or =
so of discussion of the specific proposals developed so far, but we need =
to finish this discussion and run a normal IETF decision process on this =
and any other proposals coming up.

What we need to do now is establish the second registry, make this =
available for data modeling projects in OMA/IPSO and the other =
organizations participating in the One Data Model liaison group, and =
continue to register any additional secondary units that may be needed =
for the latter.  The specific way these secondary units are enabled for =
use directly in SenML Packs can be left open for a short while, even if =
this may seem unusual; the important thing is to make the SenML =
ecosystem available now as the supplier of the harmonized unit names =
used all over IoT.

Gr=C3=BC=C3=9Fe, Carsten




>=20
> Thanks,
> Alissa
>=20
>=20
>> On Feb 19, 2020, at 8:31 PM, Carsten Bormann  wrote:
>>=20
>> Hi Alissa,
>>=20
>> Let me try to answer this quickly, but there is a complex history =
around this that may easier be explained in person.
>>=20
>>> On 2020-02-19, at 21:16, Alissa Cooper  wrote:
>>>=20
>>> Hi Carsten,
>>>=20
>>> A few responses below.
>>>=20
>>>> On Feb 19, 2020, at 2:40 PM, Carsten Bormann  wrote:
>>>>=20
>>>> Hi Alissa,
>>>>=20
>>>> Thank you for your concern about interoperability.
>>>>=20
>>>>> =
----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> =
----------------------------------------------------------------------
>>>>>=20
>>>>> I have some questions and comments about the text below, which =
seems like it
>>>>> creates significant scope for interoperability failures:
>>>>>=20
>>>>> "Where the benefits of directly using a secondary unit in a SenML =
pack
>>>>> outweigh the above considerations, the use of secondary units in =
"u"
>>>>> fields MAY be enabled by indicating a new SenML version that
>>>>> specifically allows this and/or by using a field with a label name
>>>>> that ends with the "_" character ("must-understand" field) whose
>>>>> definition specifically allows this.  The definition of these
>>>>> versions and fields is outside the scope of the present
>>>>> specification; one such definition is proposed in
>>>>> [I-D.bormann-core-senml-versions]."
>>>>>=20
>>>>> Do I understand correctly that this allows secondary units in (1) =
SenML packs
>>>>> that use some version number besides 10,
>>>>=20
>>>> (If that version specifically allows the use of secondary units)
>>>>=20
>>>>> and (2) SenML fields named with "_"
>>>>> that are in packs where the version number is 10?
>>>>=20
>>>> (Or any other version number that may not on its own specifically =
allow the use of secondary units)
>>>> (If that =E2=80=9Cmust-understand=E2=80=9D field specifically =
allows the use of secondary units)
>>>>=20
>>>>> What is the motivation for
>>>>> providing two different mechanisms to signal that secondary units =
are in use?
>>>>> I.e., why isn't one or the other of these mechanisms sufficient?
>>>>=20
>>>> Because we don=E2=80=99t want to prejudice the decision how this is =
indicated.
>>>=20
>>> Why not? What value is derived from having two ways of doing the =
same thing?
>>=20
>> I don=E2=80=99t think we will have two ways in the end.  If we agree =
that draft-bormann-core-senml-versions is a good way to do this, I =
don=E2=80=99t think people will come up with other ways of specifically =
indicating this.  (There may be contexts outside of SenML packs where =
SenML units are being used that might merit other ways of indicating =
primary-only vs. primary/secondary.  So far I haven=E2=80=99t met =
those.)
>>=20
>>>> (If we had known about the considerations about enabling secondary =
units earlier, we could have done that in time for this specification.  =
The tight timeline of this specification is based on the use of the same =
secondary units registry in data model specifications that underly data =
exchanged in SenML and other formats.  So there is no need to decide =
this mechanism right now for the initial use of the registry.)
>>>=20
>>> What is the timeline, exactly?
>>=20
>> =E2=80=9CASAP=E2=80=9D=E2=80=A6 (I think the original timeline was =
CES 2020, and we are already behind it.)
>>=20
>>> What is driving it?
>>=20
>> The use of the SenML unit registry as a general purpose registry for =
units used in IoT standards, specifically those being developed by other =
SDOs (OMA LWM2M/IPSO is leading this).
>>=20
>>>>> Without defining either a new version that supports secondary =
units or fields
>>>>> with "_", I don't understand how this update to RFC 8428 is =
complete enough to
>>>>> be implementable.
>>>>=20
>>>> We decided that this draft is not updating RFC 8428, so it is not =
implementable without defining either of the mechanisms or the data =
models defined by other SDOs.
>>>=20
>>> I don=E2=80=99t understand how this draft could not be updating RFC =
8428. RFC 8428 says:
>>>=20
>>> "Systems reading one of the objects MUST check for the Base Version
>>> field.  If this value is a version number larger than the version
>>> that the system understands, the system MUST NOT use this object.
>>> This allows the version number to indicate that the object contains
>>> structure or semantics that is different from what is defined in the
>>> present document beyond just making use of the extension points
>>> provided here."
>>>=20
>>> This drafts seems to be saying you can include fields with different =
structure and semantics from what is specified in RFC 8428, but still =
use version 10.
>>=20
>> RFC 8428 is not too specific on what the semantics for a newly =
defined field could be.
>> I would expect that it can supply additional semantics to existing =
fields, opening the avenue of using must-understand fields for what =
could also be considered version upgrades.
>> Section 12.2 of RFC 8428 says:
>>=20
>>  Extensions that are mandatory to understand to correctly process the
>>  Pack MUST have a label name that ends with the "_" character.
>>=20
>> I personally would prefer us going the =
draft-bormann-core-senml-versions way, where the version number is =
strengthened to be the main extension point, but consensus building on =
this has only just begun.
>>=20
>>>> draft-bormann-core-senml-versions-00 is my best guess of where we =
will come out with the discussion of the former; the latter is in =
progress, waiting for this draft to be published.
>>>>=20
>>>>> It says other versions and fields are out of scope, but don't
>>>>> some need to be defined in order for the normative MAY in this =
text to be
>>>>> actionable?
>>>>=20
>>>> See above.
>>>>=20
>>>>> The label names registry policy is Expert Review, which does not =
require formal
>>>>> documentation of the registry entry. Where is the "definition =
[that]
>>>>> specifically allows this" expected to occur?
>>>>=20
>>>> In the definition of the label.
>>>=20
>>> So, that can be in a private email to the designated expert?
>>=20
>> Yes, RFC 8428 allows that.  But that secrecy would make a =
=E2=80=9Cmust-understand=E2=80=9D field (with a label ending in =E2=80=9C_=
=E2=80=9D) hard to use except by those that are privy to this =
specification.
>>=20
>> Gr=C3=BC=C3=9Fe, Carsten
>>=20
>=20


From nobody Fri Feb 21 22:21:44 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7907E120125; Fri, 21 Feb 2020 22:21:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrVerdp7WFPq; Fri, 21 Feb 2020 22:21:23 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5128F12006D; Fri, 21 Feb 2020 22:21:23 -0800 (PST)
Received: from [172.16.42.113] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48PdWP672dz183C; Sat, 22 Feb 2020 07:21:21 +0100 (CET)
From: Carsten Bormann 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mao-Original-Outgoing-Id: 604045281.409403-48d283213530afe9b09ae2a1c8a06238
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Sat, 22 Feb 2020 07:21:21 +0100
Message-Id: 
To: ace@ietf.org, Core , cose@ietf.org, cbor@ietf.org, t2trg@irtf.org
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: [core] Constrained Node/Network Cluster @ IETF107: DRAFT AGENDA
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Feb 2020 06:21:27 -0000

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF107.  Remember that there is still quite some potential for
changes.

Conflicts that meet the eye:  ROLL vs. COSE/TEEP, LPWAN vs. RATS, and
LAKE vs. RATS, WPACK vs. ACE.  The latter two might be a bigger
problem, while the first two are displaying the inevitable split
between security vs. other IoT issues, as is MODEL-T vs. CORE and
TXAUTH vs. T2TRG.

All times are in PDT =3D=3D UTC - 7 hours.  Note that North America is =
on
DST already during the IETF, while Europe will only go there on March
29, so we are in the three-week period of DST confusion (where the US
is one hour closer to the EU than the rest of the year).
(Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are
useful for those who want to listen from remote.)

Gr=C3=BC=C3=9Fe, Carsten

FRIDAY, March 20, 2020
0900-1800 T2TRG/W3C WoT Workshop =
https://github.com/t2trg/2020-03-vancouver

SATURDAY, March 21, 2020
0830-2200  IETF Hackathon - Plaza Ballroom

SUNDAY, March 22, 2020
0830-1600  IETF Hackathon - Plaza Ballroom
1700-1900  Welcome Reception - Regency A/B/C/D
1800-2000  Hot RFC Lightning Talks -- Plaza B/C

MONDAY, March 23, 2020

1000-1200  Morning Session I
Regency D	ART	dispatch	Dispatch WG - Joint with ARTAREA
Regency C	INT	6man	IPv6 Maintenance WG
Plaza B/C	IRTF	pearg	Privacy Enhancements and Assessments =
Research Group
Regency E	SEC ***	suit	Software Updates for Internet of Things =
WG

1330-1530  Afternoon Session I
Regency C	INT ***	lpwan	IPv6 over Low Power Wide-Area Networks =
WG
Regency D	IRTF	irtfopen	IRTF Open Meeting
Georgia A	SEC	mls	Messaging Layer Security WG
Georgia B	SEC	oauth	Web Authorization Protocol WG
Plaza A 	SEC ***	rats	Remote ATtestation ProcedureS WG

1550-1750  Afternoon Session II
Regency F	ART	webtrans	WebTransport WG
Regency C	IRTF	maprg	Measurement and Analysis for Protocols
Regency E	OPS	anima	Autonomic Networking Integrated Model =
and Approach WG
Plaza A 	RTG	raw	Reliable and Available Wireless WG
Plaza B/C	SEC	secdispatch	Security Dispatch WG

1810-1910  Afternoon Session III
Georgia A	RTG ***	roll	Routing Over Low power and Lossy =
networks WG
Georgia B	SEC ***	cose	CBOR Object Signing and Encryption WG
Plaza B/C	SEC	tls	Transport Layer Security WG
Regency C	TSV	tsvarea	Transport Area Open Meeting

TUESDAY, March 24, 2020

1000-1200  Morning Session I
Georgia A	INT	add	Adaptive DNS Discovery WG
Regency D	IRTF***	dinrg	Decentralized Internet Infrastructure
Regency F	SEC	acme	Automated Certificate Management =
Environment WG
Regency E	SEC ***	teep	Trusted Execution Environment =
Provisioning WG
Plaza B/C	TSV	quic	QUIC WG

1330-1530  Afternoon Session I
Regency C	INT	masque	Multiplexed Application Substrate over =
QUIC Encryption BOF
Regency D	IRTF	coinrg	Computing in the Network Research Group
Georgia B	RTG ***	roll	Routing Over Low power and Lossy =
networks WG
Georgia A	SEC	emu	EAP Method Update WG
Plaza A 	SEC ***	teep	Trusted Execution Environment =
Provisioning WG

1550-1720  Afternoon Session II
Regency F	ART ***	core	Constrained RESTful Environments WG
Plaza A 	IRTF	qirg	Quantum Internet Proposed Research Group
Georgia B	SEC	oauth	Web Authorization Protocol WG
Regency C	TSV	tsvwg	Transport Area Working Group WG

1740-1840  Afternoon Session III
Plaza B/C	INT	6man	IPv6 Maintenance WG
Georgia A	RTG	babel	Babel routing protocol WG
Regency D	RTG	detnet	Deterministic Networking WG
Regency E	RTG	rift	Routing In Fat Trees WG
Regency C	TSV	quic	QUIC WG

WEDNESDAY, March 25, 2020

0830-0945  Side Meetings / Open Time
Regency C		tdd	Technology Deep Dive

1000-1200  Morning Session I
Regency F	IRTF***	t2trg	Thing-to-Thing
Georgia B	RTG	bier	Bit Indexed Explicit Replication WG
Regency D	SEC	txauth	Transactional Authorization and =
Delegation BOF
Regency C	TSV	quic	QUIC WG

1330-1500  Afternoon Session I
Regency C	ART	wpack	Web Packaging BOF
Regency E	IRTF	panrg	Path Aware Networking RG
Georgia A	SEC ***	ace	Authentication and Authorization for =
Constrained Environments WG

1520-1650  Afternoon Session II
Georgia A		model-t	Internet Threat Model
Plaza A 	ART ***	core	Constrained RESTful Environments WG
Plaza B/C	RTG	rtgarea	Routing Area Open Meeting

1710-1940  IETF Plenary - Regency C/D/E/F

THURSDAY, March 26, 2020

1000-1200  Morning Session I
Georgia A	ART ***	cbor	Concise Binary Object Representation =
Maintenance and Extensions WG
Georgia B	INT	dnssd	Extensions for Scalable DNS Service =
Discovery WG - Joint with HOMENET
Georgia B	INT	homenet	Home Networking WG - Joint with DNSSD
Regency E	IRTF	icnrg	Information-Centric Networking
Regency C	SEC	privacypass	privacy-pass BOF
Plaza B/C	TSV	tsvwg	Transport Area Working Group WG

1330-1530  Afternoon Session I
Regency F	OPS	v6ops	IPv6 Operations WG
Regency D	SEC	saag	Security Area Open Meeting
Georgia B	TSV	taps	Transport Services WG

1550-1720  Afternoon Session II
Regency C	ART	httpbis	HTTP WG
Regency F	INT	intarea	Internet Area Working Group WG
Regency E	IRTF	cfrg	Crypto Forum
Plaza B/C	RTG	detnet	Deterministic Networking WG

1740-1840  Afternoon Session III
Regency E	ART	uta	Using TLS in Applications WG
Georgia B	INT ***	drip	Drone Remote ID Protocol WG
Regency D	OPS	anima	Autonomic Networking Integrated Model =
and Approach WG

FRIDAY, March 27, 2020

1000-1200  Morning Session I
Plaza B/C	INT ***	6lo	IPv6 over Networks of =
Resource-constrained Nodes WG
Regency C	SEC	tls	Transport Layer Security WG

1220-1350  Morning Session II
Regency D	ART	httpbis	HTTP WG
Regency C	IRTF	coinrg	Computing in the Network Research Group
Regency F	SEC ***	lake	Lightweight Authenticated Key Exchange =
WG
Georgia A	SEC ***	rats	Remote ATtestation ProcedureS WG



From nobody Tue Feb 25 05:19:38 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDBC3A09AA for ; Tue, 25 Feb 2020 05:19:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdQl-i67nk_0 for ; Tue, 25 Feb 2020 05:19:35 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B193A0C2C for ; Tue, 25 Feb 2020 05:19:35 -0800 (PST)
Received: from [192.168.217.147] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48RffY3JyRz1006; Tue, 25 Feb 2020 14:19:33 +0100 (CET)
From: Carsten Bormann 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mao-Original-Outgoing-Id: 604329572.953993-62417ffff4a07333dfa909ed9107d1ce
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Tue, 25 Feb 2020 14:19:33 +0100
Message-Id: <2554B0B8-1C32-453E-AB28-90AB61242450@tzi.org>
To: Core 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: [core] Consensus on using Echo to mitigate NoSec amplification?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2020 13:19:38 -0000

In draft-ietf-core-echo-request-tag-08.txt, Section 2.4 item 3 places a =
SHOULD on a "server that sends large responses to unauthenticated =
peers=E2=80=9D to mitigate the amplification threat using the Echo =
Option procedure.

draft-ietf-core-echo-request-tag already is flagged to update RFC7252, =
but this is called out in the abstract and introduction only for Token =
processing.  The SHOULD in Section 2.4 item 3 is a bit hidden for my =
taste.  My esteemed co-chair pointed out to me that we don=E2=80=99t =
really advertise a mitigation for the substantial amplification =
opportunities posed by those installations that do not translate the =
discussion in Section 11.3 of RFC 7252 into active behavior.  There are =
now people out there that believe CoAP ranks with DNS and NTP in the =
DDoS threat generated.


Would the CoRE WG be fine with expanding the =E2=80=9Cupdates 7252=E2=80=9D=
 text in draft-ietf-core-echo-request-tag to also include recommending =
this mitigation?  If you have a position on this, please reply to the =
list (or to the chairs) by March 2nd.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Tue Feb 25 22:50:27 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B210B3A0F04 for ; Tue, 25 Feb 2020 22:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLeHddNDaPY9 for ; Tue, 25 Feb 2020 22:50:24 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 933083A0F02 for ; Tue, 25 Feb 2020 22:50:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1582699818; bh=B2+7vChqOEDuLJhqGIh2kTc5Y0gN5vmcz1SfuBg0yK4=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=fINkUhfa6YKpYk4/Fv6sQNDxaOz8GE/kUSfoT/iwr6JjKAlMfRz7ebpHNckJxfZXs /NQzxvcMaXno/His/nwsXMNGZoNQ/PJorHxGMX7XJlbPcp6A8eH98YFy2JWwPaWSh4 8rg2EhiazEhFtDFmNZyY9Nq9Mf9y6cLAk8QnNTUQ=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([94.216.229.249]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M8ygY-1j0mQg0HWI-00698l; Wed, 26 Feb 2020 07:45:04 +0100
To: Carsten Bormann , Core 
References: <2554B0B8-1C32-453E-AB28-90AB61242450@tzi.org>
From: Achim Kraus 
Message-ID: <3c35523f-6e31-f74e-51bb-7b63e5ea7bb4@gmx.net>
Date: Wed, 26 Feb 2020 07:45:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <2554B0B8-1C32-453E-AB28-90AB61242450@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:mc4AD2itn6EP0XoeAj5fldrj6dj2Fqw7fl6l04eh/kyxc+rYRJW ahjvRZ+KtbRDwjWzLGkXVxo8CTcRj7YxXpj84y26slLyaN8PQLKuwSLkUf6eyzkAYGMJQvv C9hws3PThM2XsDCPNFkW/Ux7gJG5ac211Ox1sQj8FgMmIqaujo+cdlkRd5KxIKDRY4InMUy 8BX7XlrF+WDpCXKNOAeXQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:7z+i2LqKS0U=:ROukKIv5fuREOcFRs0zqKI td/G4o03fC0BokP4IHeMTMnEv//VLgMeo6jWbyMxQqkz1jioI12eNeW+pbzB96a6UtarF7pyF jLjpDTlVpVFb2lCM/tNaolxZKe1QbUOn/IPtiFxHJDfmY0U8LHoT22s2yK80bHEFF/arfyB0n hl3VPgrzOoZ8TphnAnPcpi9dXXACpEGT/1ftEy0yXNqFPSNeoiggtcglB4gYJ+OOZPzEU57Ek LgH6KPCL+KUirTSF7TLEj1SFZMbP8Zvz/UbOnHT5+d6wMri/NeFEu/udQr4XX8K5sciy7tgw7 xvMAk8CRobsVRUV9FwTM3TE3QfGlBvmyvhoedbFKWxDjyPYxMDksfNoAxg60GoqyiEdxWas2a ub9vPBmq33doTwXhPYJfvBhECbfC7HtctImJ+Y/+NhePTiFr8mgbkXThqNLjtDQCOfiBsdmcw x6mlhXqsG/hQzhIGXuKDVU31VMJTmiRbpi3Rx9+bWyTHMyYB63b21lDyiLisWD5DrcmmDWVQe PhEuFXRtj3saCSPwfwRHSrXpsMdEU92j04cRJ5MBk62iDDFy454TYc+xJMCUhaC4KbitKeOjh 9WpMSBTpdnOYKepRH02wo/v8TM3Hv2B/jHmiM+KhC/yhdkHVIEAyQyfbpDcWYh5s/B75iBxkA pC2WF8ZVnzuMuhcWZweLt8QRapNvRSTZ1nI0wJ2/AfZiI4RU3ycG0iuFbm+s5hpCKJWSlaMJN vx83hUI/1YcwNehHTZTusyyB2vYH7H75Qiz/sCod2Ue6iHRtjBWjAc4GufhvOCdfpu5gMvY25 BbznpntLWLekfSlpCqHuQHuDexiI2Lgk1bty9vNyeKyeMdsPsZPvVXVd5viRLKTwB0zLoFYY4 k58v2czMX7XFXlan2pfQ2kx/cGgB01tHba9a+EAzq9Q2vO7YFxeD9SlP3Za+x0M6Yo5aYpMzI CTa5jZx8gRR78+r9QIcfo88KvOB5uKWyvF8/8+98o0Yd/zh4WNO2/l8dQ1SdtEwrmWboGMpzZ hnRA2/DBX/03rozy+b9/z/Z/Y02/mF5/j9eoYkhHVQca9KbqdEdsXhkPi77rHqr9GaklJvVXo UbcjZooMkBYyfEHy/6qgHHp4UFJrVH6kRrOHvEntc17alqFKASWpeAMkttfmFS+gM9nsc/K3V Tdo+gRgCLGNgxozvZSCAcNV9gqMWR3RXPdM5GE8o2YjwumONH/+oDTrFKwpZxaog+zJwT5F2c XTYzOsVUPvHIkXHcS
Archived-At: 
Subject: Re: [core] Consensus on using Echo to mitigate NoSec amplification?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2020 06:50:26 -0000

Hello Carsten
Hello List,

 > There are now people out there that believe CoAP ranks with DNS and
NTP in the DDoS threat generated.

It seems to be indeed important to have such security mechanisms at a
prominent place. Otherwise researchers may fail to read it.

For example, the document "The Fragility of Industrial IoT's Data
Backbone" from late 2018, cites on page 24, the RFC 7959, page 6, with
"Both sides have a say in the block size that actually will be used."
and concludes "This means that the attacker could craft a request packet
asking for the maximum block size.". That conclusion is not according
RFC7959. The researcher would have to read through page 10-11 to find
"(The effect is that, if the server uses the smaller of (1) its
preferred block size and (2) the block size requested, all blocks for a
body use the same block size.)"

So, have it in a prominent place, will really pay off.

best regards
Achim Kraus


Am 25.02.20 um 14:19 schrieb Carsten Bormann:
> In draft-ietf-core-echo-request-tag-08.txt, Section 2.4 item 3 places a =
SHOULD on a "server that sends large responses to unauthenticated peers=E2=
=80=9D to mitigate the amplification threat using the Echo Option procedur=
e.
>
> draft-ietf-core-echo-request-tag already is flagged to update RFC7252, b=
ut this is called out in the abstract and introduction only for Token proc=
essing.  The SHOULD in Section 2.4 item 3 is a bit hidden for my taste.  M=
y esteemed co-chair pointed out to me that we don=E2=80=99t really adverti=
se a mitigation for the substantial amplification opportunities posed by t=
hose installations that do not translate the discussion in Section 11.3 of=
 RFC 7252 into active behavior.  There are now people out there that belie=
ve CoAP ranks with DNS and NTP in the DDoS threat generated.
>
> 
> Would the CoRE WG be fine with expanding the =E2=80=9Cupdates 7252=E2=80=
=9D text in draft-ietf-core-echo-request-tag to also include recommending =
this mitigation?  If you have a position on this, please reply to the list=
 (or to the chairs) by March 2nd.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>


From nobody Wed Feb 26 08:13:27 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1763A0997 for ; Wed, 26 Feb 2020 08:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.876
X-Spam-Level: 
X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FILL_THIS_FORM_SHORT=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_HTML_ATTACH=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60IZ7L7AQLXu for ; Wed, 26 Feb 2020 08:13:10 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 782233A0A2D for ; Wed, 26 Feb 2020 08:12:41 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id z12so3704830wmi.4 for ; Wed, 26 Feb 2020 08:12:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2zyj59T/yO1JhjBSgZiIHEk3MAnpOwFQAH9paC+LTqg=; b=RRa8Fjt1e+7Xft8/oPCcEECo9QAvC5INcPRptyJmM/Unx6lC2qObx4Xc9ZUkyuvIPk liz6dmGuZ8Zs9BUEL+cHsH0gEllbLDRr7BXvPwzqvb6UgPPEH0SG3JFkY/Cm6frLvbJE bP5/c4dvSkaLlRre7vmdxjBjEkUojmcn6KFmHg9xCPTDWdbeUAvQ9fQgE+MNu1BwTvZ0 X+Fxzu4pUSddECkP4zTK6xhbBpBk05OoaodRt5uJ37i22gP5f9gCCvyoPy7/nh9Jrleu G4LdFiWP6w0G9FXDC5tQrSZny9+Iy4NKPmBiXHJhZqHluDCvjFUF2dZ8xSyvNB1w8wXH RqNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2zyj59T/yO1JhjBSgZiIHEk3MAnpOwFQAH9paC+LTqg=; b=GiQ7yTa49jmji3zlY486fHxgfaW0Zd9pSPCBiK1px7h+u8NNNxI6iC8AHcLIYpZ3wB PDIsGaJqNWt7DyPfOcUDoGgvF1ApmfJqmmylRJWLXHS5K3LVdh2M1QFUPB7ihDRPvpZ+ m3X3HODr89U/NaoKT50uzQs/LFvfSKa9s/QLIYaaEjJyk3dAQ5rlkquvxliGsTjSh6tT M2iR+xC0IFAvkUy1O7N+UpuicegqC/017xTtoq0dQiWGBWZMv3tk7PL87eIPTUzVAKC6 TPFvxLI8XItPQ8e3h8xtGYH8hwOkbgrKgjUs2MHPxNeEhbhhpayd6ZdfRgA1y41WrF9h S+6A==
X-Gm-Message-State: APjAAAVUfTERF/2UEn2v7TvN27v//IkRMr5fCxdatSUhAapEdXxJluyf TB01JW3eSfZL94zz6vhN1He2+l8xeZI=
X-Google-Smtp-Source: APXvYqycxw9adymqwGq6Cifa6GCzPzEgZsSD9fyDway2gVax6ybGIlIOYCJmsH1EiMG0aw8bE5G5xw==
X-Received: by 2002:a1c:a443:: with SMTP id n64mr6011337wme.141.1582733555912;  Wed, 26 Feb 2020 08:12:35 -0800 (PST)
Received: from white-fang ([185.122.161.249]) by smtp.gmail.com with ESMTPSA id t10sm3622053wru.59.2020.02.26.08.12.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 26 Feb 2020 08:12:33 -0800 (PST)
Date: Wed, 26 Feb 2020 17:12:31 +0100
From: Ivaylo Petrov 
To: Andy Bierman 
Cc: core 
Message-ID: <20200226161231.otjaqg4vigsb4sim@white-fang>
References: <158151922293.18124.16532089945914076050.idtracker@ietfa.amsl.com>  
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="turc4kgeatbxhx3k"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [core] Fwd: New Version Notification for draft-ietf-core-sid-10.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2020 16:13:25 -0000

--turc4kgeatbxhx3k
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

Hi Andy,

Sorry for the slight delay. Please find my answers below.

I am adding as attachments txt and html version of the text with the
proposed changes.

On Mon, Feb 17, 2020 at 10:05:18AM -0800, Andy Bierman wrote:
> Hi,
> 
> Here are my comments on draft-ietf-core-sid-10:
> 
> sec 1:
> 
>       YANG modules, submodules and features
> 
> 
> * Should it be noted somewhere that these  3 constructs are numbered
> for YANG library purposes and are not used in protocol messages like
> the other constructs listed?
> 

[IP]:
I can see how this information would avoid some people wondering why
those items really need SID assignment. It seems to me that we were
aiming at a specification that is very loosely coupled with the CoMI and
YANG library purposes. Therefore, I could agree that we can give them as
examples for the different uses - say that data node SIDs for example are
used in CoMI and module, submodule and features SIDs are used in YANG
library. 

I could for example imagine to have the following text right after the
text that you cited.

    It is possible that some protocols use only a subset of the assigned SIDs, for
    example, for protocols equivalent to NETCONF {{RFC6241}} like {{-comi}} the
    transportation of YANG modules SIDs might be unnecessary. Others protocols
    might need to be able to transport this information, for example protocols
    related to discovery such as Constrained YANG Module Library {{-yang-library}}.

> 
> sec 4:
> 
> 
> * The intro should contain a YANG Tree Diagram [RFC 8340]
> 
> 
> module: ietf-sid-file
>   +--rw module-name?              yang:yang-identifier
>   +--rw module-revision?          revision-identifier
>   +--rw sid-file-version?         sid-file-version-identifier
>   +--rw dependencies-revisions* [module-name]
>   |  +--rw module-name        yang:yang-identifier
>   |  +--rw module-revision    revision-identifier
>   +--rw assigment-ranges* [entry-point]
>   |  +--rw entry-point    sid
>   |  +--rw size           uint64
>   +--rw items* [namespace identifier]
>      +--rw namespace     enumeration
>      +--rw identifier    union
>      +--rw sid           sid

[IP]:
Thanks for pointing this out! It is updated now.

> 
> 
> * The SID file construct needs a wrapper container instead of 6
> to-level data nodes.
> 
>   A yang-data extension (from ietf-restconf.yang in RFC 8040) should be used.
> 
>   There is an update to rc:yang-data, but it is not published yet.
> 
> 
>      rc:yang-data sid-file {
> 
>          // all 6 fields defined here
> 
>      }
> 
> 

[IP]:
That makes sense, thank you for bringing our attention to this!

> 
> * The IETF Trust Copyright is for 2016. There is probably a new template.
> 
> 

[IP]:
If I recall correctly, I checked one of the YANG file validation tool that was
printing a warning and added the Copyright statement based on that, replacing
the year with the first version when the YANG module was published. Could you
tell me how to find the latest template and if I should instead put 2020
instead of 2016.

> * Nit: list names are usually singular (dependencies-revisions,
> assignment-ranges, items)
> 

[IP]:
Unless someone objects because of the possible breaking of some already
existing .sid files, I will modify the assignment-ranges and items
lists. In any case I will rename dependencies-revisions to comply with
this best practice.

> 
> * The description-stmt for assignment-ranges should be expanded:
> 
>   - specify that the SID range for each entry is SID entry-point to
> entry-point + (size - 1)
> 
>   - the SID ranges specified by all assignment-rages MUST NOT overlap
> 
> 
> * The type for /assignment-ranges/size should not allow zero-length
> ranges.  s/uint64/uint64 { range 1..max; }/
> 

[IP]:
Done.

> 
> sec 6.3.2 Allocation Policy
> 
> * the range 1000 to 59,999 is rather small for the pool of all YANG modules
> published in RFCs.
>   Likewise, 40K for all experimental numbers seems really small. The SID
> range is uint64
> 
> * Not sure these characterizations of small, medium, large are helpful.
> Also max allocation of 1000
>   seems rather arbitrary.  Better to say requestors need to justify the
> size of each request.

[IP]:
I will contact Alexander about that part as I don't have enough context
to judge why those exact values were selected and what was the reason
behind him proposing the use of on small, medium and large sizes.

> 
> sec 6.4.2 Allocation Policy
> 
>    SIDs never change
> 
>   * The IETF has shown very little ability to get all the names and module
> structure correct on the first try.
>      Or the first 15 tries.  Modules get refactored and names get changed
> -- a lot.  This statement is unclear.
>      (SID 42 is always SID 42? Or do you mean SID assignments never change?)

[IP]:
The intended meaning was that the assignment never changes.  As I
believe that this section should be focused solely on the Allocation
Policy and as I believe the previous three points make it clear that
Experts should check that the meaning of a SID number does not change, I
consider this can be entirely removed.

> 
>   * This section should say that reassignment of SIDs within an allocated
> SID range MAY change during
>      YANG module development. next section has text about this issue.

[IP]:
I believe this is handled by my previous comment.

> 
> 6.4.3
> 
>  * Should an early allocation be given if the adopted module imports
> unadopted modules?
>    This seems to force the WG to adopt or not use the allocated SID range
> 

[IP]:
While for me this case is unlikely, my view on this is that if the
working group chairs consider it acceptable to depend on a module that
is defined in a draft that is still not adopted and they can convince
the responsible AD to sponsor that document, that is fine. Let me know
if you think that the text around this is not clear enough:

    A YANG module which references a module in an document which has not yet been
    adopted by any working group will be unable to perform an Early Allocation
    for that other document until it is adopted by a working group.  As described
    in {{-BCP100}}, an AD Sponsored document acts as if it had a working group.  The
    approving AD may also exempt a document from this policy by agreeing to AD
    Sponsor the document.

> * Not sure how to fix the following  sentence, but maybe just remove it
> since it is unclear
> 
>    Critically, the original document should never get through the IETF
>    process and then be surprised to be referencing a document whose
>    progress is not certain.
> 

[IP]:
I can see how this text can be difficult to understand unambiguously.
How about rephrasing it like:

    At the end of the IETF process all the dependencies of a given module for which
    SIDs are assigned, should also have SIDs assigned. Those dependencies'
    assignments should be permanent (not Early Allocation).

> 
>  * Not sure what "expired" means. It means they are burned and never
> reallocated right?
> 
>  It would punish early adopters to do otherwise.
> 
>    Early Allocations are made with a one-year period, after which they
>    are expired.
> 

[IP]:
My understanding is that after the early allocation period is over, if
it is not extended, the SIDs will be available for re-allocation. Note
that while this could in theory lead to confusion about the meaning of a
number of SIDs, this expectation is clearly outlined for me and it is
acceptable. As always, Early Adopters should consider the possible risks
and benefits.

> 
> Appendix A
> 
> The example is rather long (8+ pages).
> Do not have a suggestion for a shorter module though

[IP]:
I agree that it is rather long. For the time being we will I think we
will keep it as it is and we will try to think about a shorter example
in the future.

> 
> Appendix B
> 
> It should be stated that SID generation for RPC or action "input" and
> "output" schema nodes
> should always be done, even if no parameters are defined in the original
> RPC or action.
> Another module can augment these nodes (but cannot add "input" or "output"
> with augment).

[IP]:
Done.

> 
> 
> Andy
> 
> 
> 
> 
> On Wed, Feb 12, 2020 at 7:04 AM Ivaylo Petrov  wrote:
> 
> > Dear all,
> >
> > In the latest version I believe we have addressed Andy's comments
> > regarding .sid file versioning. I consider this to be the last comment that
> > was still pending before we can go for a working group last call for the
> > sid draft and the cluster of drafts known as CORECONF in general. Please
> > let us know if there are still points that you consider should be handled
> > before the WGLC. In the absence of further comments, I would like to ask
> > the working group chairs to consider going for a last call.
> >
> > Thank you in advance!
> >
> > Best regards,
> > Ivaylo
> >
> >
> > ---------- Forwarded message ---------
> > From: 
> > Date: Wed, Feb 12, 2020 at 3:53 PM
> > Subject: New Version Notification for draft-ietf-core-sid-10.txt
> > To: Ivaylo Petrov , Alexander Pelov , Michel
> > Veillette 
> >
> >
> >
> > A new version of I-D, draft-ietf-core-sid-10.txt
> > has been successfully submitted by Ivaylo Petrov and posted to the
> > IETF repository.
> >
> > Name:           draft-ietf-core-sid
> > Revision:       10
> > Title:          YANG Schema Item iDentifier (SID)
> > Document date:  2020-02-12
> > Group:          core
> > Pages:          33
> > URL:
> > https://www.ietf.org/internet-drafts/draft-ietf-core-sid-10.txt
> > Status:         https://datatracker.ietf.org/doc/draft-ietf-core-sid/
> > Htmlized:       https://tools.ietf.org/html/draft-ietf-core-sid-10
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-core-sid
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-10
> >
> > Abstract:
> >    YANG Schema Item iDentifiers (SID) are globally unique 63-bit
> >    unsigned integers used to identify YANG items.  This document defines
> >    the semantics, the registration, and assignment processes of SIDs.
> >    To enable the implementation of these processes, this document also
> >    defines a file format used to persist and publish assigned SIDs.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
> >

--
Best regards,
Ivaylo

--turc4kgeatbxhx3k
Content-Type: text/html; charset=utf-8
Content-Disposition: attachment; filename="draft-ietf-core-sid-latest.html"





  

  YANG Schema Item iDentifier (SID)

  

  


































  
  

  
  
  
  
  





  

    
    
    	

Internet Engineering Task Force
M. Veillette, Ed.




Internet-Draft
Trilliant Networks Inc.




Intended status: Standards Track
A. Pelov, Ed.




Expires: August 29, 2020
I. Petrov, Ed.





Acklio





February 26, 2020



    	
    
  


  
YANG Schema Item iDentifier (SID)

  draft-ietf-core-sid-10

  
  
Abstract


YANG Schema Item iDentifiers (SID) are globally unique 63-bit unsigned integers used to identify YANG items.  This document defines the semantics, the registration, and assignment processes of SIDs.  To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned SIDs.


Status of This Memo


This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.


Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).  Note that other groups may also distribute working documents as Internet-Drafts.  The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.


Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.  It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."


This Internet-Draft will expire on August 29, 2020.


Copyright Notice


Copyright (c) 2020 IETF Trust and the persons identified as the document authors.  All rights reserved.


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.  Please review these documents carefully, as they describe your rights and restrictions with respect to this document.  Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


  
  

  
Table of Contents

  

  

1. Introduction



Some of the items defined in YANG [RFC7950] require the use of a unique identifier.  In both NETCONF [RFC6241] and RESTCONF [RFC8040], these identifiers are implemented using names.  To allow the implementation of data models defined in YANG in constrained devices and constrained networks, a more compact method to identify YANG items is required. This compact identifier, called SID, is encoded using a 63-bit unsigned integer. The limitation to 63-bit unsigned integers allows SIDs to be manipulated more easily on platforms that might otherwise lack native 64-bit unsigned arithmetic. The loss of a single bit of range is not significant given the size of the remaining space.


The following items are identified using SIDs:





    

  • identities
    • 

  • data nodes (Note: including those parts of a YANG template as defined by the ‘yang-data’ extension.)
    • 

  • RPCs and associated input(s) and output(s)
    • 

  • actions and associated input(s) and output(s)
    • 

  • notifications and associated information
    • 

  • YANG modules, submodules and features
    • 



It is possible that some protocols use only a subset of the assigned SIDs, for example, for protocols equivalent to NETCONF [RFC6241] like [I-D.ietf-core-comi] the transportation of YANG modules SIDs might be unnecessary. Others protocols might need to be able to transport this information, for example protocols related to discovery such as Constrained YANG Module Library [I-D.ietf-core-yang-library].


SIDs are globally unique integers, a registration system is used in order to guarantee their uniqueness. SIDs are registered in blocks called “SID ranges”.


Assignment of SIDs to YANG items can be automated. For more details how this could be achieved, please consult Appendix B.


SIDs are assigned permanently, items introduced by a new revision of a YANG module are added to the list of SIDs already assigned.


Section 3 provides more details about the registration process of YANG modules and associated SIDs. To enable the implementation of this registry, Section 4 defines a standard file format used to store and publish SIDs.



2. Terminology and Notation



The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.


The following terms are defined in [RFC7950]:





    

  • action
    • 

  • feature
    • 

  • module
    • 

  • notification
    • 

  • RPC
    • 

  • schema node
    • 

  • schema tree
    • 

  • submodule
    • 



The following term is defined in [RFC8040]:





  • yang-data extension


This specification also makes use of the following terminology:





    

  • item:  A schema node, an identity, a module, a submodule or a feature defined using the YANG modeling language.
    • 

  • path: A path is a string that identifies a schema node within the schema tree. A path consists of the list of schema node identifier(s) separated by slashes (“/”). Schema node identifier(s) are always listed from the top-level schema node up to the targeted schema node. (e.g. “/ietf-system:system-state/clock/current-datetime”)
    • 

  • YANG Schema Item iDentifier (SID): Unsigned integer used to identify different YANG items.
    • 




3. “.sid” file lifecycle



YANG is a language designed to model data accessed using one of the compatible protocols (e.g. NETCONF [RFC6241], RESCONF [RFC8040] and CoRECONF [I-D.ietf-core-comi]). A YANG module defines hierarchies of data, including configuration, state data, RPCs, actions and notifications.


Many YANG modules are not created in the context of constrained applications. YANG modules can be implemented using NETCONF [RFC6241] or RESTCONF [RFC8040] without the need to assign SIDs.


As needed, authors of YANG modules can assign SIDs to their YANG modules. In order to do that, they should first obtain a SID range from a registry and use that range to assign or generate SIDs to items of their YANG module. The assignments can then be stored in a “.sid” file. For example how this could be achieved, please refer to Appendix C.


Registration of the “.sid” file associated to a YANG module is optional but recommended to promote interoperability between devices and to avoid duplicate allocation of SIDs to a single YANG module. Different registries might have different requirements for the registration and publication of the “.sid” files. For diagram of one of the possibilities, please refer to the activity diagram on Figure 1 in Appendix C.


Each time a YANG module or one of its imported module(s) or included sub-module(s) is updated, a new “.sid” file MAY need to be created. All the SIDs present in the previous version of the “.sid” file MUST be present in the new version as well. The creation of this new version of the “.sid” file SHOULD be performed using an automated tool.


If a new revision requires more SIDs than initially allocated, a new SID range MUST be added to the ‘assignment-ranges’ as defined in Section 4.  These extra SIDs are used for subsequent assignments.


For an example of this update process, see activity diagram Figure 2 in Appendix C.



4. “.sid” file format



“.sid” files are used to persist and publish SIDs assigned to the different YANG items of a specific YANG module. It has the following structure.


module: ietf-sid-file
  +--rw module-name?              yang:yang-identifier
  +--rw module-revision?          revision-identifier
  +--rw sid-file-version?         sid-file-version-identifier
  +--rw dependency-revision* [module-name]
  |  +--rw module-name        yang:yang-identifier
  |  +--rw module-revision    revision-identifier
  +--rw assigment-ranges* [entry-point]
  |  +--rw entry-point    sid
  |  +--rw size           uint64
  +--rw items* [namespace identifier]
     +--rw namespace     enumeration
     +--rw identifier    union
     +--rw sid           sid



The following YANG module defined the structure of this file, encoding is performed using the rules defined in [RFC7951].


<CODE BEGINS> file "ietf-sid-file@2020-02-05.yang"
module ietf-sid-file {
  namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file";
  prefix sid;

  import ietf-yang-types {
    prefix yang;
  }
  import ietf-restconf {
    prefix rc;
  }

  organization
    "IETF Core Working Group";

  contact
    "Michel Veillette
     <mailto:michel.veillette@trilliant.com>

     Andy Bierman
     <mailto:andy@yumaworks.com>

     Alexander Pelov
     <mailto:a@ackl.io>";

  description
    "Copyright (c) 2020 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Simplified BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.


     This module defines the structure of the .sid files.

     Each .sid file contains the mapping between the different
     string identifiers defined by a YANG module and a
     corresponding numeric value called SID.";

  revision 2020-02-05 {
    description
      "Initial revision.";
    reference
      "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)";
  }

  typedef revision-identifier {
    type string {
      pattern '\d{4}-\d{2}-\d{2}';
    }
    description
      "Represents a date in YYYY-MM-DD format.";
  }

  typedef sid-file-version-identifier {
    type uint64;
    description
      "Optional attribute that gives information about the .sid file
       version.";
  }

  typedef sid {
    type uint64;
    description
      "YANG Schema Item iDentifier";
    reference
      "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)";
  }

  typedef schema-node-path {
    type string {
      pattern
        '/[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*' +
        '(/[a-zA-Z_][a-zA-Z0-9\-_.]*(:[a-zA-Z_][a-zA-Z0-9\-_.]*)?)*';
    }
    description
      "Identifies a schema-node path string for use in the
       SID registry. This string format follows the rules
       for an instance-identifier, as defined in RFC 7959,
       except that no predicates are allowed.

       This format is intended to support the YANG 1.1 ABNF
       for a schema node identifier, except module names
       are used instead of prefixes, as specified in RFC 7951.";
    reference
      "RFC 7950, The YANG 1.1 Data Modeling Language;
       Section 6.5: Schema Node Identifier;
       RFC 7951, JSON Encoding of YANG Data;
       Section 6.11: The instance-identifier type";
  }

  rc:yang-data sid-file {
    leaf module-name {
      type yang:yang-identifier;
      description
        "Name of the YANG module associated with this .sid file.";
    }

    leaf module-revision {
      type revision-identifier;
      description
        "Revision of the YANG module associated with this .sid file.
        This leaf is not present if no revision statement is
        defined in the YANG module.";
    }

    leaf sid-file-version {
      type sid-file-version-identifier;
      description
        "The version number of the .sid file. .sid files and the version
        sequence are specific to a given YANG module revision.
        This number starts at zero when there is a YANG module update.
        This number can distinguish updates to the SID file which are the result of
        new processing, or the result of reported errata.";
    }

    list dependency-revision {
      key "module-name";

      description
        "Information about the revision of each YANG module that the module in
        'module-name' includes used during the .sid file generation.";

      leaf module-name {
        type yang:yang-identifier;
        mandatory true;
        description
          "Name of the YANG module, dependency of 'module-name', for which
          revision information is provided.";
      }
      leaf module-revision {
        type revision-identifier;
        mandatory true;
        description
          "Revision of the YANG module, dependency of 'module-name', for which
          revision information is provided.";
      }
    }

    list assigment-ranges {
      key "entry-point";
      description
        "SID range(s) allocated to the YANG module identified by
        'module-name' and 'module-revision'.

        - The SID range first available value is entry-point and the the last
          available value in the range is (entry-point + size - 1).
        - The SID ranges specified by all assignment-rages MUST NOT overlap.";

      leaf entry-point {
        type sid;
        mandatory true;
        description
          "Lowest SID available for assignment.";
      }

      leaf size {
        type uint64;
        mandatory true;
        description
          "Number of SIDs available for assignment.";
      }
    }

    list items {
      key "namespace identifier";
      description
        "Each entry within this list defined the mapping between
        a YANG item string identifier and a SID. This list MUST
        include a mapping entry for each YANG item defined by
        the YANG module identified by 'module-name' and
        'module-revision'.";

      leaf namespace {
        type enumeration {
          enum module {
            value 0;
            description
              "All module and submodule names share the same
              global module identifier namespace.";
          }
          enum identity {
            value 1;
            description
              "All identity names defined in a module and its
              submodules share the same identity identifier
              namespace.";
          }
          enum feature {
            value 2;
            description
              "All feature names defined in a module and its
              submodules share the same feature identifier
              namespace.";
          }
          enum data {
            value 3;
            description
              "The namespace for all data nodes, as defined in YANG.";
          }
        }
        description
          "Namespace of the YANG item for this mapping entry.";
      }

      leaf identifier {
        type union {
          type yang:yang-identifier;
          type schema-node-path;
        }
        description
          "String identifier of the YANG item for this mapping entry.

          If the corresponding 'namespace' field is 'module',
          'feature', or 'identity', then this field MUST
          contain a valid YANG identifier string.

          If the corresponding 'namespace' field is 'data',
          then this field MUST contain a valid schema node
          path.";
      }

      leaf sid {
        type sid;
        mandatory true;
        description
          "SID assigned to the YANG item for this mapping entry.";
      }
    }
  }
}
<CODE ENDS>




5. Security Considerations



This document defines a new type of identifier used to encode data models defined in YANG [RFC7950]. As such, this identifier does not contribute to any new security issues in addition of those identified for the specific protocols or contexts for which it is used.



6. IANA Considerations




6.1. Register SID File Format Module



This document registers one YANG module in the “YANG Module Names” registry [RFC6020]:





    

  • name:         ietf-sid-file
    • 

  • namespace:    urn:ietf:params:xml:ns:yang:ietf-sid-file
    • 

  • prefix:       sid
    • 

  • reference:    [[THISRFC]]
    • 




6.2. Create new IANA Registry: “SID Mega-Range” registry



The name of this registry is “SID Mega-Range”. This registry is used to record the delegation of the management of a block of SIDs to third parties (such as SDOs or registrars).



6.2.1. Structure



Each entry in this registry must include:





    

  • The entry point (first SID) of the registered SID block.
    • 

  • The size of the registered SID block. The size MUST be one million (1 000 000) SIDs.
    • 

  • The contact information of the requesting organization including: 
      

    • The policy of SID range allocations: Public, Private or Both.
      • 

    • Organization name
      • 

    • URL
      • 

    

    • 



The information associated to the Organization name should not be publicly visible in the registry, but should be available. This information includes contact email and phone number and change controller email and phone number.



6.2.2. Allocation policy



The IANA policy for future additions to this registry is “Expert Review” [RFC8126].


An organization requesting to manage a SID Range (and thus have an entry in the SID Mega-Range Registry), must ensure the following capacities:





    

  • The capacity to manage and operate a SID Range Registry. A SID Range Registry MUST provide the following information for all SID Ranges allocated by the Registry: 
      

    • Entry Point of allocated SID Range
      • 

    • Size of allocated SID Range
      • 

    • Type: Public or Private 
        

      • Public Ranges MUST include at least a reference to the YANG module and “.sid” files for that SID Range.
        • 

      • Private Ranges MUST be marked as “Private”
        • 

      

      • 

    

    • 

  • A Policy of allocation, which clearly identifies if the SID Range allocations would be Private, Public or Both.
    • 

  • Technical capacity to ensure the sustained operation of the registry for a period of at least 5 years. If Private Registrations are allowed, the period must be of at least 10 years.
    • 




6.2.2.1. First allocation



For a first allocation to be provided, the requesting organization must demonstrate a functional registry infrastructure.



6.2.2.2. Consecutive allocations



On subsequent allocation request(s), the organization must demonstrate the exhaustion of the prior range. These conditions need to be asserted by the assigned expert(s).


If that extra-allocation is done within 3 years from the last allocation, the experts need to discuss this request on the CORE working group mailing list and consensus needs to be obtained before allocating a new Mega-Range.



6.2.3. Initial contents of the Registry



The initial entry in this registry is allocated to IANA:





Entry Point
Size
Allocation
Organization name
URL




0
1000000
Public
IANA
iana.org






6.3. Create a new IANA Registry: IETF SID Range Registry (managed by IANA)




6.3.1. Structure



Each entry in this registry must include:





    

  • The SID range entry point.
    • 

  • The SID range size.
    • 

  • The YANG module name.
    • 

  • Document reference.
    • 




6.3.2. Allocation policy



The first million SIDs assigned to IANA is sub-divided as follows:





    

  • The range of 0 to 999 (size 1000) is “Reserved” as defined in [RFC8126].
    • 

  • The range of 1000 to 59,999 (size 59,000) is reserved for YANG modules defined in RFCs. The IANA policy for additions to this registry is “Expert Review” [RFC8126].  
    • The Expert MUST verify that the YANG module for which this allocation is made has an RFC (existing RFC) OR is on track to become RFC (early allocation with a request from the WG chairs as defined by [RFC7120]).
    

    • 

  • The SID range allocated for a YANG module can follow in one of the four categories: 
      

    • SMALL (50 SIDs)
      • 

    • MEDIUM (100 SIDs)
      • 

    • LARGE (250 SIDs)
      • 

    • CUSTOM (requested by the YANG module author, with a maximum of 1000 SIDs).  In all cases, the size of a SID range assigned to a YANG module should be at least 33% above the current number of YANG items. This headroom allows assignment within the same range of new YANG items introduced by subsequent revisions. A larger SID range size may be requested by the authors if this recommendation is considered insufficient. It is important to note that an additional SID range can be allocated to an existing YANG module if the initial range is exhausted.
      • 

    

    • 

  • The range of 60,000 to 99,999 (size 40,000)is reserved for experimental YANG modules. This range MUST NOT be used in operational deployments since these SIDs are not globally unique which limit their interoperability. The IANA policy for this range is “Experimental use” [RFC8126].
    • 

  • The range of 100,000 to 999,999 (size 900,000) is “Reserved” as defined in [RFC8126].
    • 






Entry Point
Size
IANA policy





0
1,000
Reserved




1,000
59,000
Expert Review




60,000
40,000
Experimental use




100,000
900,000
Reserved







6.3.3. Initial contents of the registry



Initial entries in this registry are as follows:





Entry Point
Size
Module name
Document reference





1000
100
ietf-comi
[I-D.ietf-core-comi]




1100
50
ietf-yang-types
[RFC6991]




1150
50
ietf-inet-types
[RFC6991]




1200
50
iana-crypt-hash
[RFC7317]




1250
50
ietf-netconf-acm
[RFC8341]




1300
50
ietf-sid-file
RFCXXXX




1500
100
ietf-interfaces
[RFC8343]




1600
100
ietf-ip
[RFC8344]




1700
100
ietf-system
[RFC7317]




1800
400
iana-if-type
[RFC7224]




2400
50
ietf-voucher
[RFC8366]




2450
50
ietf-constrained-voucher
[I-D.ietf-anima-constrained-voucher]




2500
50
ietf-constrained-voucher-request
[I-D.ietf-anima-constrained-voucher]






// RFC Ed.: replace XXXX with RFC number assigned to this draft.


For allocation, RFC publication of the YANG module is required as per [RFC8126]. The YANG module must be registered in the “YANG module Name” registry according to the rules specified in section 14 of [RFC6020].



6.4. Create new IANA Registry: “IETF SID Registry”



The name of this registry is “IETF SID Registry”.  This registry is used to record the allocation of SIDs for individual YANG module items.



6.4.1. Structure



Each entry in this registry must include:





    

  • The YANG module name. This module name must be present in the “Name” column of the “YANG Module Names” registry.
    • 

  • A link to the associated “.yang” file.  This file link must be present in the “File” column of the “YANG Module Names” registry.
    • 

  • The link to the “.sid” file which defines the allocation. The “.sid” file is stored by IANA.
    • 

  • The number of actually allocated SIDs in the “.sid” file.
    • 




6.4.2. Allocation policy



The allocation policy is Expert review. The Expert MUST ensure that the following conditions are met:





    

  • The “.sid” file has a valid structure: 
    • The “.sid” file MUST be a valid JSON file following the structure of the module defined in RFCXXXX (RFC Ed: replace XXX with RFC number assigned to this draft).
    

    • 

  • The “.sid” file allocates individual SIDs ONLY in the SID Ranges for this YANG module (as allocated in the IETF SID Range Registry): 
    • All SIDs in this “.sid” file MUST be within the ranges allocated to this YANG module in the “IETF SID Range Registry”.
    

    • 

  • If another “.sid” file has already allocated SIDs for this YANG module (e.g.  for older or newer versions of the YANG module), the YANG items are assigned the same SIDs as in the other “.sid” file.
    • 

  • If there is an older version of the “.sid” file, all allocated SIDs from that version are still present in the current version of the “.sid” file.
    • 




6.4.3. Recursive Allocation of SID Range at Document Adoption



Due to the difficulty in changing SID values during IETF document processing, it is expected that most documents will ask for SID allocations using Early Allocations [RFC7120]. The details of the Early Allocation should be included in any Working Group Adoption call. Prior to Working Group Adoption, an internet draft authors can use the experimental SID range (as per Section 6.3.2) for their SIDs allocations or other values that do not create ambiguity with other SID uses (for example they can use a range that comes from a non-IANA managed “SID Mega-Range” registry).


After Working Group Adoption, any modification of a “.sid” file is expected to be discussed on the mailing list of the appropriate Working Groups. Specific attention should be paid to implementers’ opinion after Working Group Last Call if a SID value is to change its meaning. In all cases, a “.sid” file and the SIDs associated with it are subject to change before the publication of an internet draft as an RFC.


During the early use of SIDs, many existing, previously published YANG modules will not have SID allocations.  For an allocation to be useful the included YANG modules may also need to have SID allocations made.


The Expert Reviewer who performs the (Early) Allocation analysis will need to go through the list of included YANG modules and perform SID allocations for those modules as well.





    

  • If the document is a published RFC, then the allocation of SIDs for its referenced YANG modules is permanent.  The Expert Reviewer provides the generated SID file to IANA for registration.  This process may be time consuming during a bootstrap period (there are over 100 YANG modules to date, none of which have SID allocations), but should quiet down once needed entries are allocated.
    • 

  • If the document is an unprocessed Internet-Draft adopted in a WG, then an Early Allocation is performed for this document as well. Early Allocations require approval by an IESG Area Director.  An early allocation which requires additional allocations will list the other allocations in it’s description, and will be cross-posted to the any other working group mailing lists.
    • 

  • A YANG module which references a module in an document which has not yet been adopted by any working group will be unable to perform an Early Allocation for that other document until it is adopted by a working group.  As described in [RFC7120], an AD Sponsored document acts as if it had a working group.  The approving AD may also exempt a document from this policy by agreeing to AD Sponsor the document.
    • 



At the end of the IETF process all the dependencies of a given module for which SIDs are assigned, should also have SIDs assigned. Those dependencies’ assignments should be permanent (not Early Allocation).


A previously SID-allocated YANG module which changes its references to include a YANG module for which there is no SID allocation needs to repeat the Early Allocation process.


Early Allocations are made with a one-year period, after which they are expired.  [RFC7120] indicates that at most one renewal may be made.  For the SID allocation a far more lenient stance is desired.





    

  1. An extension of a referencing documents Early Allocation should update any referenced Early Allocations to expire no sooner than the referencing document.
    2. 

  2. The [RFC7120] mechanism allows the IESG to provide a second renewal, and such an event may prompt some thought about how the collection of documents are being processed.
    3. 



This is driven by the very generous size of the SID space and the often complex and deep dependencies of YANG modules.  Often a core module with many dependencies will undergo extensive review, delaying the publication of other documents.


[RFC7120] also says


Note that if a document is submitted for review to the IESG and at
the time of submission some early allocations are valid (not
expired), these allocations should not be expired while the document
is under IESG consideration or waiting in the RFC Editor's queue
after approval by the IESG.




6.4.4. Initial contents of the registry



None.



7. Acknowledgments



The authors would like to thank Andy Bierman, Carsten Bormann, Michael Richardson, Abhinav Somaraju, Peter van der Stok, Laurent Toutain and Randy Turner for their help during the development of this document and their useful comments during the review process.



8. References



8.1. Normative References





[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.




[RFC7120]

Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014.




[RFC7950]

Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016.




[RFC7951]

Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016.




[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.






8.2. Informative References





[I-D.ietf-anima-constrained-voucher]

Richardson, M., Stok, P. and P. Kampanakis, "Constrained Voucher Artifacts for Bootstrapping Protocols", Internet-Draft draft-ietf-anima-constrained-voucher-07, January 2020.




[I-D.ietf-core-comi]

Veillette, M., Stok, P., Pelov, A., Bierman, A. and I. Petrov, "CoAP Management Interface", Internet-Draft draft-ietf-core-comi-08, September 2019.




[I-D.ietf-core-yang-library]

Veillette, M. and I. Petrov, "Constrained YANG Module Library", Internet-Draft draft-ietf-core-yang-library-01, January 2020.




[RFC6020]

Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010.




[RFC6241]

Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011.




[RFC6991]

Schoenwaelder, J., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013.




[RFC7224]

Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, DOI 10.17487/RFC7224, May 2014.




[RFC7317]

Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014.




[RFC8040]

Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017.




[RFC8126]

Cotton, M., Leiba, B. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017.




[RFC8341]

Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018.




[RFC8343]

Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018.




[RFC8344]

Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018.




[RFC8366]

Watsen, K., Richardson, M., Pritikin, M. and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, May 2018.






Appendix A. “.sid” file example



The following “.sid” file (ietf-system@2014-08-06.sid) have been generated using the following yang modules:





    

  • ietf-system@2014-08-06.yang
    • 

  • ietf-yang-types@2013-07-15.yang
    • 

  • ietf-inet-types@2013-07-15.yang
    • 

  • ietf-netconf-acm@2012-02-22.yang
    • 

  • iana-crypt-hash@2014-04-04.yang
    • 



{
  "assignment-ranges": [
    {
      "entry-point": 1700,
      "size": 100
    }
  ],
  "module-name": "ietf-system",
  "module-revision": "2014-08-06",
  "items": [
    {
      "namespace": "module",
      "identifier": "ietf-system",
      "sid": 1700
    },
    {
      "namespace": "identity",
      "identifier": "authentication-method",
      "sid": 1701
    },
    {
      "namespace": "identity",
      "identifier": "local-users",
      "sid": 1702
    },
    {
      "namespace": "identity",
      "identifier": "radius",
      "sid": 1703
    },
    {
      "namespace": "identity",
      "identifier": "radius-authentication-type",
      "sid": 1704
    },
    {
      "namespace": "identity",
      "identifier": "radius-chap",
      "sid": 1705
    },
    {
      "namespace": "identity",
      "identifier": "radius-pap",
      "sid": 1706
    },
    {
      "namespace": "feature",
      "identifier": "authentication",
      "sid": 1707
    },
    {
      "namespace": "feature",
      "identifier": "dns-udp-tcp-port",
      "sid": 1708
    },
    {
      "namespace": "feature",
      "identifier": "local-users",
      "sid": 1709
    },
    {
      "namespace": "feature",
      "identifier": "ntp",
      "sid": 1710
    },
    {
      "namespace": "feature",
      "identifier": "ntp-udp-port",
      "sid": 1711
    },
    {
      "namespace": "feature",
      "identifier": "radius",
      "sid": 1712
    },
    {
      "namespace": "feature",
      "identifier": "radius-authentication",
      "sid": 1713
    },
    {
      "namespace": "feature",
      "identifier": "timezone-name",
      "sid": 1714
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:set-current-datetime",
      "sid": 1715
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:set-current-datetime/
                     current-datetime",
      "sid": 1716
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system",
      "sid": 1717
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system-restart",
      "sid": 1718
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system-shutdown",
      "sid": 1719
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system-state",
      "sid": 1720
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system-state/clock",
      "sid": 1721
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system-state/clock/boot-datetime",
      "sid": 1722
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system-state/clock/
                     current-datetime",
      "sid": 1723
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system-state/platform",
      "sid": 1724
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system-state/platform/machine",
      "sid": 1725
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system-state/platform/os-name",
      "sid": 1726
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system-state/platform/os-release",
      "sid": 1727
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system-state/platform/os-version",
      "sid": 1728
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/authentication",
      "sid": 1729
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/authentication/user",
      "sid": 1730
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/authentication/
                     user-authentication-order",
      "sid": 1731
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/authentication/user/
                     authorized-key",
      "sid": 1732
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/authentication/user/
                     authorized-key/algorithm",
      "sid": 1733
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/authentication/user/
                     authorized-key/key-data",
      "sid": 1734
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/authentication/user/
                     authorized-key/name",
      "sid": 1735
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/authentication/user/
                     name",
      "sid": 1736
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/authentication/user/
                     password",
      "sid": 1737
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/clock",
      "sid": 1738
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/clock/timezone-name",
      "sid": 1739
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/clock/timezone-utc-offset",
      "sid": 1740
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/contact",
      "sid": 1741
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/dns-resolver",
      "sid": 1742
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/dns-resolver/options",
      "sid": 1743
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/dns-resolver/options/
                     attempts",
      "sid": 1744
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/dns-resolver/options/
                     timeout",
      "sid": 1745
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/dns-resolver/search",
      "sid": 1746
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/dns-resolver/server",
      "sid": 1747
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/dns-resolver/server/name",
      "sid": 1748
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/dns-resolver/server/
                     udp-and-tcp",
      "sid": 1749
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/dns-resolver/server/
                     udp-and-tcp/address",
      "sid": 1750
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/dns-resolver/server/
                     udp-and-tcp/port",
      "sid": 1751
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/hostname",
      "sid": 1752
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/location",
      "sid": 1753
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/ntp",
      "sid": 1754
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/ntp/enabled",
      "sid": 1755
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/ntp/server",
      "sid": 1756
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/ntp/server/
                     association-type",
      "sid": 1757
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/ntp/server/iburst",
      "sid": 1758
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/ntp/server/name",
      "sid": 1759
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/ntp/server/prefer",
      "sid": 1760
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/ntp/server/udp",
      "sid": 1761
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/ntp/server/udp/address",
      "sid": 1762
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/ntp/server/udp/port",
      "sid": 1763
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/radius",
      "sid": 1764
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/radius/options",
      "sid": 1765
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/radius/options/attempts",
      "sid": 1766
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/radius/options/timeout",
      "sid": 1767
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/radius/server",
      "sid": 1768
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/radius/server/
                     authentication-type",
      "sid": 1769
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/radius/server/name",
      "sid": 1770
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/radius/server/udp",
      "sid": 1771
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/radius/server/udp/
                     address",
      "sid": 1772
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/radius/server/udp/
                     authentication-port",
      "sid": 1773
    },
    {
      "namespace": "data",
      "identifier": "/ietf-system:system/radius/server/udp/
                     shared-secret",
      "sid": 1774
    }
  ]
}




Appendix B. SID auto generation



Assignment of SIDs to YANG items can be automated, the recommended process to assign SIDs is as follows:





    

  1. A tool extracts the different items defined for a specific YANG module.
    2. 

  2. The list of items is sorted in alphabetical order, ‘namespace’ in descending order, ‘identifier’ in ascending order. The ‘namespace’ and ‘identifier’ formats are described in the YANG module ‘ietf-sid-file’ defined in Section 4.
    3. 

  3. SIDs are assigned sequentially from the entry point up to the size of the registered SID range. This approach is recommended to minimize the serialization overhead, especially when delta between a reference SID and the current SID is used by protocols aiming to reduce message size.
    4. 

  4. If the number of items exceeds the SID range(s) allocated to a YANG module, an extra range is added for subsequent assignments.
    5. 

  5. The “dependency-revision” should reflect the revision numbers of each YANG module that the YANG module imports at the moment of the generation.
    6. 



In case of an update to an existing “.sid” file, an additional step is needed that increments the “.sid” file version number. If there was no version number in the previous version of the “.sid” file, 0 is assumed as the version number of the old version of the “.sid” file and the version number is 1 for the new “.sid” file. Apart from that, changes of SID files can also be automated using the same method described above, only unassigned YÀNG items are processed at step #3. Already existing items in the SID file should not be given new SIDs.


Note that “.sid” file versions are specific to a YANG module revision. For each new YANG module or each new revision of an existing YANG module, the version number of the initial “.sid” file should either be 0 or should not be present.


Note also that RPC or action “input” and “output” data nodes MUST always be assigned SID even if they don’t contain data nodes. The reason for this requirement is that other modules can augment the given module and those SIDs might be necessary.



Appendix C. “.sid” file lifecycle



Before assigning SIDs to their YANG modules, YANG module authors must acquire a SID range from a “SID Range Registry”. If the YANG module is part of an IETF draft or RFC, the SID range need to be acquired from the “IETF SID Range Registry” as defined in Section 6.3. For the other YANG modules, the authors can acquire a SID range from any “SID Range Registry” of their choice.


Once the SID range is acquired, the owner can use it to generate “.sid” file/s for his YANG module/s.  It is recommended to leave some unallocated SIDs following the allocated range in each “.sid” file in order to allow better evolution of the YANG module in the future.  Generation of “.sid” files should be performed using an automated tool.  Note that “.sid” files can only be generated for YANG modules and not for submodules.



C.1. SID File Creation



The following activity diagram summarizes the creation of a YANG module and its associated “.sid” file.






       +---------------+
  O    | Creation of a |
 -|- ->| YANG module   |
 / \   +---------------+
               |
               V
        /-------------\
       / Standardized  \     yes
       \ YANG module ? /-------------+
        \-------------/              |
               | no                  |
               V                     V
        /-------------\      +---------------+
       / Constrained   \ yes | SID range     |
   +-->\ application ? /---->| registration  |<----------+
   |    \-------------/      +---------------+           |
   |           | no                  |                   |
   |           V                     V                   |
   |   +---------------+     +---------------+           |
   +---| YANG module   |     | SID sub-range |           |
       | update        |     | assignment    |<----------+
       +---------------+     +---------------+           |
                                     |                   |
                                     V                   |
                             +---------------+    +-------------+
                             | ".sid" file   |    | Rework YANG |
                             | generation    |    |    model    |
                             +---------------+    +-------------+
                                     |                   ^
                                     V                   |
                                /----------\  yes        |
                               /  Work in   \ -----------+
                               \  progress  /
                                \----------/
                                     | no
                                     V
                               /-------------\       /-------------\
                              /      RFC      \ no  /     Open      \ no
                              \  publication? /---->\ specification?/---+
                               \-------------/       \-------------/    |
                                      | yes                 | yes       |
                                      |     +---------------+           |
                                      V     V                           V
                              +---------------+                 +---------------+
                              |     IANA      |                 | Third party   |
                              | registration  |                 | registration  |
                              +-------+-------+                 +-------+-------+
                                      |                                 |
                                      +---------------------------------+
                                      V
                                    [DONE]



Figure 1: SID Lifecycle



C.2. SID File Update



The following Activity diagram summarizes the update of a YANG module and its associated “.sid” file.






       +---------------+
  O    | Update of the |
 -|- ->| YANG module   |
 / \   | or include(s) |
       | or import(s)  |
       +---------------+
               |
               V
           /-------------\
          /  New items    \ yes
          \  created  ?   /------+
           \-------------/       |
                  | no           V
                  |       /-------------\      +----------------+
                  |      /  SID range    \ yes | Extra sub-range|
                  |      \  exhausted ?  /---->| assignment     |
                  |       \-------------/      +----------------+
                  |              | no                  |
                  |              +---------------------+
                  |              |
                  |              V
                  |      +---------------+
                  |      | ".sid" file   |
                  |      | update based  |
                  |      | on previous   |
                  |      | ".sid" file   |
                  |      +---------------+
                  |              |
                  |              V
                  |       /-------------\      +---------------+
                  |      /  Publicly     \ yes | YANG module   |
                  |      \  available ?  /---->| registration  |
                  |       \-------------/      +---------------+
                  |              | no                  |
                  +--------------+---------------------+
                                 |
                               [DONE]




Figure 2: YANG and SID file update


Authors' Addresses



  

	
	  Michel Veillette (editor)
	  
	
	Trilliant Networks Inc.
	
	  610 Rue du Luxembourg

	  
		Granby,  
		Quebec 
		J2J 2V2
	  
	  Canada
	
	Phone: +14503750556

EMail: michel.veillette@trilliant.com

  



  

	
	  Alexander Pelov (editor)
	  
	
	Acklio
	
	  1137A avenue des Champs Blancs

	  
		Cesson-Sevigne,  
		Bretagne 
		35510
	  
	  France
	
	EMail: a@ackl.io

  



  

	
	  Ivaylo Petrov (editor)
	  
	
	Acklio
	
	  1137A avenue des Champs Blancs

	  
		Cesson-Sevigne,  
		Bretagne 
		35510
	  
	  France
	
	EMail: ivaylo@ackl.io

  







--turc4kgeatbxhx3k
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="draft-ietf-core-sid-latest.txt"





Internet Engineering Task Force                        M. Veillette, Ed.
Internet-Draft                                   Trilliant Networks Inc.
Intended status: Standards Track                           A. Pelov, Ed.
Expires: August 29, 2020                                  I. Petrov, Ed.
                                                                  Acklio
                                                       February 26, 2020


                   YANG Schema Item iDentifier (SID)
                         draft-ietf-core-sid-10

Abstract

   YANG Schema Item iDentifiers (SID) are globally unique 63-bit
   unsigned integers used to identify YANG items.  This document defines
   the semantics, the registration, and assignment processes of SIDs.
   To enable the implementation of these processes, this document also
   defines a file format used to persist and publish assigned SIDs.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 29, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Veillette, et al.        Expires August 29, 2020                [Page 1]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Notation  . . . . . . . . . . . . . . . . . .   3
   3.  ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . .   4
   4.  ".sid" file format  . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Register SID File Format Module . . . . . . . . . . . . .  11
     6.2.  Create new IANA Registry: "SID Mega-Range" registry . . .  12
       6.2.1.  Structure . . . . . . . . . . . . . . . . . . . . . .  12
       6.2.2.  Allocation policy . . . . . . . . . . . . . . . . . .  12
         6.2.2.1.  First allocation  . . . . . . . . . . . . . . . .  13
         6.2.2.2.  Consecutive allocations . . . . . . . . . . . . .  13
       6.2.3.  Initial contents of the Registry  . . . . . . . . . .  13
     6.3.  Create a new IANA Registry: IETF SID Range Registry
           (managed by IANA) . . . . . . . . . . . . . . . . . . . .  13
       6.3.1.  Structure . . . . . . . . . . . . . . . . . . . . . .  13
       6.3.2.  Allocation policy . . . . . . . . . . . . . . . . . .  14
       6.3.3.  Initial contents of the registry  . . . . . . . . . .  15
     6.4.  Create new IANA Registry: "IETF SID Registry" . . . . . .  16
       6.4.1.  Structure . . . . . . . . . . . . . . . . . . . . . .  17
       6.4.2.  Allocation policy . . . . . . . . . . . . . . . . . .  17
       6.4.3.  Recursive Allocation of SID Range at Document
               Adoption  . . . . . . . . . . . . . . . . . . . . . .  17
       6.4.4.  Initial contents of the registry  . . . . . . . . . .  19
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Appendix A.  ".sid" file example  . . . . . . . . . . . . . . . .  21
   Appendix B.  SID auto generation  . . . . . . . . . . . . . . . .  30
   Appendix C.  ".sid" file lifecycle  . . . . . . . . . . . . . . .  31
     C.1.  SID File Creation . . . . . . . . . . . . . . . . . . . .  31
     C.2.  SID File Update . . . . . . . . . . . . . . . . . . . . .  33
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34

1.  Introduction

   Some of the items defined in YANG [RFC7950] require the use of a
   unique identifier.  In both NETCONF [RFC6241] and RESTCONF [RFC8040],
   these identifiers are implemented using names.  To allow the
   implementation of data models defined in YANG in constrained devices
   and constrained networks, a more compact method to identify YANG
   items is required.  This compact identifier, called SID, is encoded



Veillette, et al.        Expires August 29, 2020                [Page 2]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   using a 63-bit unsigned integer.  The limitation to 63-bit unsigned
   integers allows SIDs to be manipulated more easily on platforms that
   might otherwise lack native 64-bit unsigned arithmetic.  The loss of
   a single bit of range is not significant given the size of the
   remaining space.

   The following items are identified using SIDs:

   o  identities

   o  data nodes (Note: including those parts of a YANG template as
      defined by the 'yang-data' extension.)

   o  RPCs and associated input(s) and output(s)

   o  actions and associated input(s) and output(s)

   o  notifications and associated information

   o  YANG modules, submodules and features

   It is possible that some protocols use only a subset of the assigned
   SIDs, for example, for protocols equivalent to NETCONF [RFC6241] like
   [I-D.ietf-core-comi] the transportation of YANG modules SIDs might be
   unnecessary.  Others protocols might need to be able to transport
   this information, for example protocols related to discovery such as
   Constrained YANG Module Library [I-D.ietf-core-yang-library].

   SIDs are globally unique integers, a registration system is used in
   order to guarantee their uniqueness.  SIDs are registered in blocks
   called "SID ranges".

   Assignment of SIDs to YANG items can be automated.  For more details
   how this could be achieved, please consult Appendix B.

   SIDs are assigned permanently, items introduced by a new revision of
   a YANG module are added to the list of SIDs already assigned.

   Section 3 provides more details about the registration process of
   YANG modules and associated SIDs.  To enable the implementation of
   this registry, Section 4 defines a standard file format used to store
   and publish SIDs.

2.  Terminology and Notation

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



Veillette, et al.        Expires August 29, 2020                [Page 3]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The following terms are defined in [RFC7950]:

   o  action

   o  feature

   o  module

   o  notification

   o  RPC

   o  schema node

   o  schema tree

   o  submodule

   The following term is defined in [RFC8040]:

   o  yang-data extension

   This specification also makes use of the following terminology:

   o  item: A schema node, an identity, a module, a submodule or a
      feature defined using the YANG modeling language.

   o  path: A path is a string that identifies a schema node within the
      schema tree.  A path consists of the list of schema node
      identifier(s) separated by slashes ("/").  Schema node
      identifier(s) are always listed from the top-level schema node up
      to the targeted schema node. (e.g. "/ietf-system:system-
      state/clock/current-datetime")

   o  YANG Schema Item iDentifier (SID): Unsigned integer used to
      identify different YANG items.

3.  ".sid" file lifecycle

   YANG is a language designed to model data accessed using one of the
   compatible protocols (e.g.  NETCONF [RFC6241], RESCONF [RFC8040] and
   CoRECONF [I-D.ietf-core-comi]).  A YANG module defines hierarchies of
   data, including configuration, state data, RPCs, actions and
   notifications.




Veillette, et al.        Expires August 29, 2020                [Page 4]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   Many YANG modules are not created in the context of constrained
   applications.  YANG modules can be implemented using NETCONF
   [RFC6241] or RESTCONF [RFC8040] without the need to assign SIDs.

   As needed, authors of YANG modules can assign SIDs to their YANG
   modules.  In order to do that, they should first obtain a SID range
   from a registry and use that range to assign or generate SIDs to
   items of their YANG module.  The assignments can then be stored in a
   ".sid" file.  For example how this could be achieved, please refer to
   Appendix C.

   Registration of the ".sid" file associated to a YANG module is
   optional but recommended to promote interoperability between devices
   and to avoid duplicate allocation of SIDs to a single YANG module.
   Different registries might have different requirements for the
   registration and publication of the ".sid" files.  For diagram of one
   of the possibilities, please refer to the activity diagram on
   Figure 1 in Appendix C.

   Each time a YANG module or one of its imported module(s) or included
   sub-module(s) is updated, a new ".sid" file MAY need to be created.
   All the SIDs present in the previous version of the ".sid" file MUST
   be present in the new version as well.  The creation of this new
   version of the ".sid" file SHOULD be performed using an automated
   tool.

   If a new revision requires more SIDs than initially allocated, a new
   SID range MUST be added to the 'assignment-ranges' as defined in
   Section 4.  These extra SIDs are used for subsequent assignments.

   For an example of this update process, see activity diagram Figure 2
   in Appendix C.

4.  ".sid" file format

   ".sid" files are used to persist and publish SIDs assigned to the
   different YANG items of a specific YANG module.  It has the following
   structure.













Veillette, et al.        Expires August 29, 2020                [Page 5]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   module: ietf-sid-file
     +--rw module-name?              yang:yang-identifier
     +--rw module-revision?          revision-identifier
     +--rw sid-file-version?         sid-file-version-identifier
     +--rw dependency-revision* [module-name]
     |  +--rw module-name        yang:yang-identifier
     |  +--rw module-revision    revision-identifier
     +--rw assigment-ranges* [entry-point]
     |  +--rw entry-point    sid
     |  +--rw size           uint64
     +--rw items* [namespace identifier]
        +--rw namespace     enumeration
        +--rw identifier    union
        +--rw sid           sid

   The following YANG module defined the structure of this file,
   encoding is performed using the rules defined in [RFC7951].

 file "ietf-sid-file@2020-02-05.yang"
module ietf-sid-file {
  namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file";
  prefix sid;

  import ietf-yang-types {
    prefix yang;
  }
  import ietf-restconf {
    prefix rc;
  }

  organization
    "IETF Core Working Group";

  contact
    "Michel Veillette
     

     Andy Bierman
     

     Alexander Pelov
     ";

  description
    "Copyright (c) 2020 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or



Veillette, et al.        Expires August 29, 2020                [Page 6]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Simplified BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.


     This module defines the structure of the .sid files.

     Each .sid file contains the mapping between the different
     string identifiers defined by a YANG module and a
     corresponding numeric value called SID.";

  revision 2020-02-05 {
    description
      "Initial revision.";
    reference
      "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)";
  }

  typedef revision-identifier {
    type string {
      pattern '\d{4}-\d{2}-\d{2}';
    }
    description
      "Represents a date in YYYY-MM-DD format.";
  }

  typedef sid-file-version-identifier {
    type uint64;
    description
      "Optional attribute that gives information about the .sid file
       version.";
  }

  typedef sid {
    type uint64;
    description



Veillette, et al.        Expires August 29, 2020                [Page 7]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


      "YANG Schema Item iDentifier";
    reference
      "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)";
  }

  typedef schema-node-path {
    type string {
      pattern
        '/[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*' +
        '(/[a-zA-Z_][a-zA-Z0-9\-_.]*(:[a-zA-Z_][a-zA-Z0-9\-_.]*)?)*';
    }
    description
      "Identifies a schema-node path string for use in the
       SID registry. This string format follows the rules
       for an instance-identifier, as defined in RFC 7959,
       except that no predicates are allowed.

       This format is intended to support the YANG 1.1 ABNF
       for a schema node identifier, except module names
       are used instead of prefixes, as specified in RFC 7951.";
    reference
      "RFC 7950, The YANG 1.1 Data Modeling Language;
       Section 6.5: Schema Node Identifier;
       RFC 7951, JSON Encoding of YANG Data;
       Section 6.11: The instance-identifier type";
  }

  rc:yang-data sid-file {
    leaf module-name {
      type yang:yang-identifier;
      description
        "Name of the YANG module associated with this .sid file.";
    }

    leaf module-revision {
      type revision-identifier;
      description
        "Revision of the YANG module associated with this .sid file.
        This leaf is not present if no revision statement is
        defined in the YANG module.";
    }

    leaf sid-file-version {
      type sid-file-version-identifier;
      description
        "The version number of the .sid file. .sid files and the version
        sequence are specific to a given YANG module revision.
        This number starts at zero when there is a YANG module update.



Veillette, et al.        Expires August 29, 2020                [Page 8]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


        This number can distinguish updates to the SID file which are the result of
        new processing, or the result of reported errata.";
    }

    list dependency-revision {
      key "module-name";

      description
        "Information about the revision of each YANG module that the module in
        'module-name' includes used during the .sid file generation.";

      leaf module-name {
        type yang:yang-identifier;
        mandatory true;
        description
          "Name of the YANG module, dependency of 'module-name', for which
          revision information is provided.";
      }
      leaf module-revision {
        type revision-identifier;
        mandatory true;
        description
          "Revision of the YANG module, dependency of 'module-name', for which
          revision information is provided.";
      }
    }

    list assigment-ranges {
      key "entry-point";
      description
        "SID range(s) allocated to the YANG module identified by
        'module-name' and 'module-revision'.

        - The SID range first available value is entry-point and the the last
          available value in the range is (entry-point + size - 1).
        - The SID ranges specified by all assignment-rages MUST NOT overlap.";

      leaf entry-point {
        type sid;
        mandatory true;
        description
          "Lowest SID available for assignment.";
      }

      leaf size {
        type uint64;
        mandatory true;
        description



Veillette, et al.        Expires August 29, 2020                [Page 9]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


          "Number of SIDs available for assignment.";
      }
    }

    list items {
      key "namespace identifier";
      description
        "Each entry within this list defined the mapping between
        a YANG item string identifier and a SID. This list MUST
        include a mapping entry for each YANG item defined by
        the YANG module identified by 'module-name' and
        'module-revision'.";

      leaf namespace {
        type enumeration {
          enum module {
            value 0;
            description
              "All module and submodule names share the same
              global module identifier namespace.";
          }
          enum identity {
            value 1;
            description
              "All identity names defined in a module and its
              submodules share the same identity identifier
              namespace.";
          }
          enum feature {
            value 2;
            description
              "All feature names defined in a module and its
              submodules share the same feature identifier
              namespace.";
          }
          enum data {
            value 3;
            description
              "The namespace for all data nodes, as defined in YANG.";
          }
        }
        description
          "Namespace of the YANG item for this mapping entry.";
      }

      leaf identifier {
        type union {
          type yang:yang-identifier;



Veillette, et al.        Expires August 29, 2020               [Page 10]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


          type schema-node-path;
        }
        description
          "String identifier of the YANG item for this mapping entry.

          If the corresponding 'namespace' field is 'module',
          'feature', or 'identity', then this field MUST
          contain a valid YANG identifier string.

          If the corresponding 'namespace' field is 'data',
          then this field MUST contain a valid schema node
          path.";
      }

      leaf sid {
        type sid;
        mandatory true;
        description
          "SID assigned to the YANG item for this mapping entry.";
      }
    }
  }
}


5.  Security Considerations

   This document defines a new type of identifier used to encode data
   models defined in YANG [RFC7950].  As such, this identifier does not
   contribute to any new security issues in addition of those identified
   for the specific protocols or contexts for which it is used.

6.  IANA Considerations

6.1.  Register SID File Format Module

   This document registers one YANG module in the "YANG Module Names"
   registry [RFC6020]:

   o  name: ietf-sid-file

   o  namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file

   o  prefix: sid

   o  reference: [[THISRFC]]





Veillette, et al.        Expires August 29, 2020               [Page 11]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


6.2.  Create new IANA Registry: "SID Mega-Range" registry

   The name of this registry is "SID Mega-Range".  This registry is used
   to record the delegation of the management of a block of SIDs to
   third parties (such as SDOs or registrars).

6.2.1.  Structure

   Each entry in this registry must include:

   o  The entry point (first SID) of the registered SID block.

   o  The size of the registered SID block.  The size MUST be one
      million (1 000 000) SIDs.

   o  The contact information of the requesting organization including:

      *  The policy of SID range allocations: Public, Private or Both.

      *  Organization name

      *  URL

   The information associated to the Organization name should not be
   publicly visible in the registry, but should be available.  This
   information includes contact email and phone number and change
   controller email and phone number.

6.2.2.  Allocation policy

   The IANA policy for future additions to this registry is "Expert
   Review" [RFC8126].

   An organization requesting to manage a SID Range (and thus have an
   entry in the SID Mega-Range Registry), must ensure the following
   capacities:

   o  The capacity to manage and operate a SID Range Registry.  A SID
      Range Registry MUST provide the following information for all SID
      Ranges allocated by the Registry:

      *  Entry Point of allocated SID Range

      *  Size of allocated SID Range

      *  Type: Public or Private





Veillette, et al.        Expires August 29, 2020               [Page 12]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


         +  Public Ranges MUST include at least a reference to the YANG
            module and ".sid" files for that SID Range.

         +  Private Ranges MUST be marked as "Private"

   o  A Policy of allocation, which clearly identifies if the SID Range
      allocations would be Private, Public or Both.

   o  Technical capacity to ensure the sustained operation of the
      registry for a period of at least 5 years.  If Private
      Registrations are allowed, the period must be of at least 10
      years.

6.2.2.1.  First allocation

   For a first allocation to be provided, the requesting organization
   must demonstrate a functional registry infrastructure.

6.2.2.2.  Consecutive allocations

   On subsequent allocation request(s), the organization must
   demonstrate the exhaustion of the prior range.  These conditions need
   to be asserted by the assigned expert(s).

   If that extra-allocation is done within 3 years from the last
   allocation, the experts need to discuss this request on the CORE
   working group mailing list and consensus needs to be obtained before
   allocating a new Mega-Range.

6.2.3.  Initial contents of the Registry

   The initial entry in this registry is allocated to IANA:

   +-------------+---------+------------+-------------------+----------+
   | Entry Point | Size    | Allocation | Organization name | URL      |
   +-------------+---------+------------+-------------------+----------+
   | 0           | 1000000 | Public     | IANA              | iana.org |
   +-------------+---------+------------+-------------------+----------+

6.3.  Create a new IANA Registry: IETF SID Range Registry (managed by
      IANA)

6.3.1.  Structure

   Each entry in this registry must include:

   o  The SID range entry point.




Veillette, et al.        Expires August 29, 2020               [Page 13]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   o  The SID range size.

   o  The YANG module name.

   o  Document reference.

6.3.2.  Allocation policy

   The first million SIDs assigned to IANA is sub-divided as follows:

   o  The range of 0 to 999 (size 1000) is "Reserved" as defined in
      [RFC8126].

   o  The range of 1000 to 59,999 (size 59,000) is reserved for YANG
      modules defined in RFCs.  The IANA policy for additions to this
      registry is "Expert Review" [RFC8126].

      *  The Expert MUST verify that the YANG module for which this
         allocation is made has an RFC (existing RFC) OR is on track to
         become RFC (early allocation with a request from the WG chairs
         as defined by [RFC7120]).

   o  The SID range allocated for a YANG module can follow in one of the
      four categories:

      *  SMALL (50 SIDs)

      *  MEDIUM (100 SIDs)

      *  LARGE (250 SIDs)

      *  CUSTOM (requested by the YANG module author, with a maximum of
         1000 SIDs).  In all cases, the size of a SID range assigned to
         a YANG module should be at least 33% above the current number
         of YANG items.  This headroom allows assignment within the same
         range of new YANG items introduced by subsequent revisions.  A
         larger SID range size may be requested by the authors if this
         recommendation is considered insufficient.  It is important to
         note that an additional SID range can be allocated to an
         existing YANG module if the initial range is exhausted.

   o  The range of 60,000 to 99,999 (size 40,000)is reserved for
      experimental YANG modules.  This range MUST NOT be used in
      operational deployments since these SIDs are not globally unique
      which limit their interoperability.  The IANA policy for this
      range is "Experimental use" [RFC8126].





Veillette, et al.        Expires August 29, 2020               [Page 14]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   o  The range of 100,000 to 999,999 (size 900,000) is "Reserved" as
      defined in [RFC8126].

   +-------------+---------+------------------+
   | Entry Point | Size    | IANA policy      |
   +-------------+---------+------------------+
   | 0           | 1,000   | Reserved         |
   | 1,000       | 59,000  | Expert Review    |
   | 60,000      | 40,000  | Experimental use |
   | 100,000     | 900,000 | Reserved         |
   +-------------+---------+------------------+

6.3.3.  Initial contents of the registry

   Initial entries in this registry are as follows:




































Veillette, et al.        Expires August 29, 2020               [Page 15]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   +-----+-----+--------------------------+----------------------------+
   | Ent | Siz | Module name              | Document reference         |
   | ry  | e   |                          |                            |
   | Poi |     |                          |                            |
   | nt  |     |                          |                            |
   +-----+-----+--------------------------+----------------------------+
   | 100 | 100 | ietf-comi                | [I-D.ietf-core-comi]       |
   | 0   |     |                          |                            |
   | 110 | 50  | ietf-yang-types          | [RFC6991]                  |
   | 0   |     |                          |                            |
   | 115 | 50  | ietf-inet-types          | [RFC6991]                  |
   | 0   |     |                          |                            |
   | 120 | 50  | iana-crypt-hash          | [RFC7317]                  |
   | 0   |     |                          |                            |
   | 125 | 50  | ietf-netconf-acm         | [RFC8341]                  |
   | 0   |     |                          |                            |
   | 130 | 50  | ietf-sid-file            | RFCXXXX                    |
   | 0   |     |                          |                            |
   | 150 | 100 | ietf-interfaces          | [RFC8343]                  |
   | 0   |     |                          |                            |
   | 160 | 100 | ietf-ip                  | [RFC8344]                  |
   | 0   |     |                          |                            |
   | 170 | 100 | ietf-system              | [RFC7317]                  |
   | 0   |     |                          |                            |
   | 180 | 400 | iana-if-type             | [RFC7224]                  |
   | 0   |     |                          |                            |
   | 240 | 50  | ietf-voucher             | [RFC8366]                  |
   | 0   |     |                          |                            |
   | 245 | 50  | ietf-constrained-voucher | [I-D.ietf-anima-constraine |
   | 0   |     |                          | d-voucher]                 |
   | 250 | 50  | ietf-constrained-        | [I-D.ietf-anima-constraine |
   | 0   |     | voucher-request          | d-voucher]                 |
   +-----+-----+--------------------------+----------------------------+

   // RFC Ed.: replace XXXX with RFC number assigned to this draft.

   For allocation, RFC publication of the YANG module is required as per
   [RFC8126].  The YANG module must be registered in the "YANG module
   Name" registry according to the rules specified in section 14 of
   [RFC6020].

6.4.  Create new IANA Registry: "IETF SID Registry"

   The name of this registry is "IETF SID Registry".  This registry is
   used to record the allocation of SIDs for individual YANG module
   items.





Veillette, et al.        Expires August 29, 2020               [Page 16]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


6.4.1.  Structure

   Each entry in this registry must include:

   o  The YANG module name.  This module name must be present in the
      "Name" column of the "YANG Module Names" registry.

   o  A link to the associated ".yang" file.  This file link must be
      present in the "File" column of the "YANG Module Names" registry.

   o  The link to the ".sid" file which defines the allocation.  The
      ".sid" file is stored by IANA.

   o  The number of actually allocated SIDs in the ".sid" file.

6.4.2.  Allocation policy

   The allocation policy is Expert review.  The Expert MUST ensure that
   the following conditions are met:

   o  The ".sid" file has a valid structure:

      *  The ".sid" file MUST be a valid JSON file following the
         structure of the module defined in RFCXXXX (RFC Ed: replace XXX
         with RFC number assigned to this draft).

   o  The ".sid" file allocates individual SIDs ONLY in the SID Ranges
      for this YANG module (as allocated in the IETF SID Range
      Registry):

      *  All SIDs in this ".sid" file MUST be within the ranges
         allocated to this YANG module in the "IETF SID Range Registry".

   o  If another ".sid" file has already allocated SIDs for this YANG
      module (e.g.  for older or newer versions of the YANG module), the
      YANG items are assigned the same SIDs as in the other ".sid" file.

   o  If there is an older version of the ".sid" file, all allocated
      SIDs from that version are still present in the current version of
      the ".sid" file.

6.4.3.  Recursive Allocation of SID Range at Document Adoption

   Due to the difficulty in changing SID values during IETF document
   processing, it is expected that most documents will ask for SID
   allocations using Early Allocations [RFC7120].  The details of the
   Early Allocation should be included in any Working Group Adoption
   call.  Prior to Working Group Adoption, an internet draft authors can



Veillette, et al.        Expires August 29, 2020               [Page 17]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   use the experimental SID range (as per Section 6.3.2) for their SIDs
   allocations or other values that do not create ambiguity with other
   SID uses (for example they can use a range that comes from a non-IANA
   managed "SID Mega-Range" registry).

   After Working Group Adoption, any modification of a ".sid" file is
   expected to be discussed on the mailing list of the appropriate
   Working Groups.  Specific attention should be paid to implementers'
   opinion after Working Group Last Call if a SID value is to change its
   meaning.  In all cases, a ".sid" file and the SIDs associated with it
   are subject to change before the publication of an internet draft as
   an RFC.

   During the early use of SIDs, many existing, previously published
   YANG modules will not have SID allocations.  For an allocation to be
   useful the included YANG modules may also need to have SID
   allocations made.

   The Expert Reviewer who performs the (Early) Allocation analysis will
   need to go through the list of included YANG modules and perform SID
   allocations for those modules as well.

   o  If the document is a published RFC, then the allocation of SIDs
      for its referenced YANG modules is permanent.  The Expert Reviewer
      provides the generated SID file to IANA for registration.  This
      process may be time consuming during a bootstrap period (there are
      over 100 YANG modules to date, none of which have SID
      allocations), but should quiet down once needed entries are
      allocated.

   o  If the document is an unprocessed Internet-Draft adopted in a WG,
      then an Early Allocation is performed for this document as well.
      Early Allocations require approval by an IESG Area Director.  An
      early allocation which requires additional allocations will list
      the other allocations in it's description, and will be cross-
      posted to the any other working group mailing lists.

   o  A YANG module which references a module in an document which has
      not yet been adopted by any working group will be unable to
      perform an Early Allocation for that other document until it is
      adopted by a working group.  As described in [RFC7120], an AD
      Sponsored document acts as if it had a working group.  The
      approving AD may also exempt a document from this policy by
      agreeing to AD Sponsor the document.

   At the end of the IETF process all the dependencies of a given module
   for which SIDs are assigned, should also have SIDs assigned.  Those
   dependencies' assignments should be permanent (not Early Allocation).



Veillette, et al.        Expires August 29, 2020               [Page 18]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   A previously SID-allocated YANG module which changes its references
   to include a YANG module for which there is no SID allocation needs
   to repeat the Early Allocation process.

   Early Allocations are made with a one-year period, after which they
   are expired.  [RFC7120] indicates that at most one renewal may be
   made.  For the SID allocation a far more lenient stance is desired.

   1.  An extension of a referencing documents Early Allocation should
       update any referenced Early Allocations to expire no sooner than
       the referencing document.

   2.  The [RFC7120] mechanism allows the IESG to provide a second
       renewal, and such an event may prompt some thought about how the
       collection of documents are being processed.

   This is driven by the very generous size of the SID space and the
   often complex and deep dependencies of YANG modules.  Often a core
   module with many dependencies will undergo extensive review, delaying
   the publication of other documents.

   [RFC7120] also says

   Note that if a document is submitted for review to the IESG and at
   the time of submission some early allocations are valid (not
   expired), these allocations should not be expired while the document
   is under IESG consideration or waiting in the RFC Editor's queue
   after approval by the IESG.

6.4.4.  Initial contents of the registry

   None.

7.  Acknowledgments

   The authors would like to thank Andy Bierman, Carsten Bormann,
   Michael Richardson, Abhinav Somaraju, Peter van der Stok, Laurent
   Toutain and Randy Turner for their help during the development of
   this document and their useful comments during the review process.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              .



Veillette, et al.        Expires August 29, 2020               [Page 19]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
              Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
              2014, .

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              .

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, DOI 10.17487/RFC7951, August 2016,
              .

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, .

8.2.  Informative References

   [I-D.ietf-anima-constrained-voucher]
              Richardson, M., Stok, P., and P. Kampanakis, "Constrained
              Voucher Artifacts for Bootstrapping Protocols", draft-
              ietf-anima-constrained-voucher-07 (work in progress),
              January 2020.

   [I-D.ietf-core-comi]
              Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.
              Petrov, "CoAP Management Interface", draft-ietf-core-
              comi-08 (work in progress), September 2019.

   [I-D.ietf-core-yang-library]
              Veillette, M. and I. Petrov, "Constrained YANG Module
              Library", draft-ietf-core-yang-library-01 (work in
              progress), January 2020.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              .

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              .

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              .




Veillette, et al.        Expires August 29, 2020               [Page 20]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   [RFC7224]  Bjorklund, M., "IANA Interface Type YANG Module",
              RFC 7224, DOI 10.17487/RFC7224, May 2014,
              .

   [RFC7317]  Bierman, A. and M. Bjorklund, "A YANG Data Model for
              System Management", RFC 7317, DOI 10.17487/RFC7317, August
              2014, .

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              .

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              .

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              .

   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
              .

   [RFC8344]  Bjorklund, M., "A YANG Data Model for IP Management",
              RFC 8344, DOI 10.17487/RFC8344, March 2018,
              .

   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
              "A Voucher Artifact for Bootstrapping Protocols",
              RFC 8366, DOI 10.17487/RFC8366, May 2018,
              .

Appendix A.  ".sid" file example

   The following ".sid" file (ietf-system@2014-08-06.sid) have been
   generated using the following yang modules:

   o  ietf-system@2014-08-06.yang

   o  ietf-yang-types@2013-07-15.yang

   o  ietf-inet-types@2013-07-15.yang

   o  ietf-netconf-acm@2012-02-22.yang




Veillette, et al.        Expires August 29, 2020               [Page 21]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   o  iana-crypt-hash@2014-04-04.yang

   {
     "assignment-ranges": [
       {
         "entry-point": 1700,
         "size": 100
       }
     ],
     "module-name": "ietf-system",
     "module-revision": "2014-08-06",
     "items": [
       {
         "namespace": "module",
         "identifier": "ietf-system",
         "sid": 1700
       },
       {
         "namespace": "identity",
         "identifier": "authentication-method",
         "sid": 1701
       },
       {
         "namespace": "identity",
         "identifier": "local-users",
         "sid": 1702
       },
       {
         "namespace": "identity",
         "identifier": "radius",
         "sid": 1703
       },
       {
         "namespace": "identity",
         "identifier": "radius-authentication-type",
         "sid": 1704
       },
       {
         "namespace": "identity",
         "identifier": "radius-chap",
         "sid": 1705
       },
       {
         "namespace": "identity",
         "identifier": "radius-pap",
         "sid": 1706
       },
       {



Veillette, et al.        Expires August 29, 2020               [Page 22]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


         "namespace": "feature",
         "identifier": "authentication",
         "sid": 1707
       },
       {
         "namespace": "feature",
         "identifier": "dns-udp-tcp-port",
         "sid": 1708
       },
       {
         "namespace": "feature",
         "identifier": "local-users",
         "sid": 1709
       },
       {
         "namespace": "feature",
         "identifier": "ntp",
         "sid": 1710
       },
       {
         "namespace": "feature",
         "identifier": "ntp-udp-port",
         "sid": 1711
       },
       {
         "namespace": "feature",
         "identifier": "radius",
         "sid": 1712
       },
       {
         "namespace": "feature",
         "identifier": "radius-authentication",
         "sid": 1713
       },
       {
         "namespace": "feature",
         "identifier": "timezone-name",
         "sid": 1714
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:set-current-datetime",
         "sid": 1715
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:set-current-datetime/
                        current-datetime",



Veillette, et al.        Expires August 29, 2020               [Page 23]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


         "sid": 1716
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system",
         "sid": 1717
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system-restart",
         "sid": 1718
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system-shutdown",
         "sid": 1719
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system-state",
         "sid": 1720
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system-state/clock",
         "sid": 1721
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system-state/clock/boot-datetime",
         "sid": 1722
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system-state/clock/
                        current-datetime",
         "sid": 1723
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system-state/platform",
         "sid": 1724
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system-state/platform/machine",
         "sid": 1725
       },



Veillette, et al.        Expires August 29, 2020               [Page 24]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


       {
         "namespace": "data",
         "identifier": "/ietf-system:system-state/platform/os-name",
         "sid": 1726
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system-state/platform/os-release",
         "sid": 1727
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system-state/platform/os-version",
         "sid": 1728
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/authentication",
         "sid": 1729
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/authentication/user",
         "sid": 1730
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/authentication/
                        user-authentication-order",
         "sid": 1731
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/authentication/user/
                        authorized-key",
         "sid": 1732
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/authentication/user/
                        authorized-key/algorithm",
         "sid": 1733
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/authentication/user/
                        authorized-key/key-data",
         "sid": 1734



Veillette, et al.        Expires August 29, 2020               [Page 25]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/authentication/user/
                        authorized-key/name",
         "sid": 1735
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/authentication/user/
                        name",
         "sid": 1736
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/authentication/user/
                        password",
         "sid": 1737
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/clock",
         "sid": 1738
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/clock/timezone-name",
         "sid": 1739
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/clock/timezone-utc-offset",
         "sid": 1740
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/contact",
         "sid": 1741
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/dns-resolver",
         "sid": 1742
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/dns-resolver/options",
         "sid": 1743



Veillette, et al.        Expires August 29, 2020               [Page 26]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/dns-resolver/options/
                        attempts",
         "sid": 1744
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/dns-resolver/options/
                        timeout",
         "sid": 1745
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/dns-resolver/search",
         "sid": 1746
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/dns-resolver/server",
         "sid": 1747
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/dns-resolver/server/name",
         "sid": 1748
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/dns-resolver/server/
                        udp-and-tcp",
         "sid": 1749
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/dns-resolver/server/
                        udp-and-tcp/address",
         "sid": 1750
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/dns-resolver/server/
                        udp-and-tcp/port",
         "sid": 1751
       },
       {
         "namespace": "data",



Veillette, et al.        Expires August 29, 2020               [Page 27]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


         "identifier": "/ietf-system:system/hostname",
         "sid": 1752
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/location",
         "sid": 1753
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/ntp",
         "sid": 1754
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/ntp/enabled",
         "sid": 1755
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/ntp/server",
         "sid": 1756
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/ntp/server/
                        association-type",
         "sid": 1757
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/ntp/server/iburst",
         "sid": 1758
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/ntp/server/name",
         "sid": 1759
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/ntp/server/prefer",
         "sid": 1760
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/ntp/server/udp",
         "sid": 1761



Veillette, et al.        Expires August 29, 2020               [Page 28]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/ntp/server/udp/address",
         "sid": 1762
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/ntp/server/udp/port",
         "sid": 1763
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/radius",
         "sid": 1764
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/radius/options",
         "sid": 1765
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/radius/options/attempts",
         "sid": 1766
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/radius/options/timeout",
         "sid": 1767
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/radius/server",
         "sid": 1768
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/radius/server/
                        authentication-type",
         "sid": 1769
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/radius/server/name",
         "sid": 1770
       },
       {



Veillette, et al.        Expires August 29, 2020               [Page 29]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


         "namespace": "data",
         "identifier": "/ietf-system:system/radius/server/udp",
         "sid": 1771
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/radius/server/udp/
                        address",
         "sid": 1772
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/radius/server/udp/
                        authentication-port",
         "sid": 1773
       },
       {
         "namespace": "data",
         "identifier": "/ietf-system:system/radius/server/udp/
                        shared-secret",
         "sid": 1774
       }
     ]
   }

Appendix B.  SID auto generation

   Assignment of SIDs to YANG items can be automated, the recommended
   process to assign SIDs is as follows:

   1.  A tool extracts the different items defined for a specific YANG
       module.

   2.  The list of items is sorted in alphabetical order, 'namespace' in
       descending order, 'identifier' in ascending order.  The
       'namespace' and 'identifier' formats are described in the YANG
       module 'ietf-sid-file' defined in Section 4.

   3.  SIDs are assigned sequentially from the entry point up to the
       size of the registered SID range.  This approach is recommended
       to minimize the serialization overhead, especially when delta
       between a reference SID and the current SID is used by protocols
       aiming to reduce message size.

   4.  If the number of items exceeds the SID range(s) allocated to a
       YANG module, an extra range is added for subsequent assignments.





Veillette, et al.        Expires August 29, 2020               [Page 30]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   5.  The "dependency-revision" should reflect the revision numbers of
       each YANG module that the YANG module imports at the moment of
       the generation.

   In case of an update to an existing ".sid" file, an additional step
   is needed that increments the ".sid" file version number.  If there
   was no version number in the previous version of the ".sid" file, 0
   is assumed as the version number of the old version of the ".sid"
   file and the version number is 1 for the new ".sid" file.  Apart from
   that, changes of SID files can also be automated using the same
   method described above, only unassigned YANG items are processed at
   step #3.  Already existing items in the SID file should not be given
   new SIDs.

   Note that ".sid" file versions are specific to a YANG module
   revision.  For each new YANG module or each new revision of an
   existing YANG module, the version number of the initial ".sid" file
   should either be 0 or should not be present.

   Note also that RPC or action "input" and "output" data nodes MUST
   always be assigned SID even if they don't contain data nodes.  The
   reason for this requirement is that other modules can augment the
   given module and those SIDs might be necessary.

Appendix C.  ".sid" file lifecycle

   Before assigning SIDs to their YANG modules, YANG module authors must
   acquire a SID range from a "SID Range Registry".  If the YANG module
   is part of an IETF draft or RFC, the SID range need to be acquired
   from the "IETF SID Range Registry" as defined in Section 6.3.  For
   the other YANG modules, the authors can acquire a SID range from any
   "SID Range Registry" of their choice.

   Once the SID range is acquired, the owner can use it to generate
   ".sid" file/s for his YANG module/s.  It is recommended to leave some
   unallocated SIDs following the allocated range in each ".sid" file in
   order to allow better evolution of the YANG module in the future.
   Generation of ".sid" files should be performed using an automated
   tool.  Note that ".sid" files can only be generated for YANG modules
   and not for submodules.

C.1.  SID File Creation

   The following activity diagram summarizes the creation of a YANG
   module and its associated ".sid" file.

       +---------------+
  O    | Creation of a |



Veillette, et al.        Expires August 29, 2020               [Page 31]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


 -|- ->| YANG module   |
 / \   +---------------+
               |
               V
        /-------------\
       / Standardized  \     yes
       \ YANG module ? /-------------+
        \-------------/              |
               | no                  |
               V                     V
        /-------------\      +---------------+
       / Constrained   \ yes | SID range     |
   +-->\ application ? /---->| registration  |<----------+
   |    \-------------/      +---------------+           |
   |           | no                  |                   |
   |           V                     V                   |
   |   +---------------+     +---------------+           |
   +---| YANG module   |     | SID sub-range |           |
       | update        |     | assignment    |<----------+
       +---------------+     +---------------+           |
                                     |                   |
                                     V                   |
                             +---------------+    +-------------+
                             | ".sid" file   |    | Rework YANG |
                             | generation    |    |    model    |
                             +---------------+    +-------------+
                                     |                   ^
                                     V                   |
                                /----------\  yes        |
                               /  Work in   \ -----------+
                               \  progress  /
                                \----------/
                                     | no
                                     V
                               /-------------\       /-------------\
                              /      RFC      \ no  /     Open      \ no
                              \  publication? /---->\ specification?/---+
                               \-------------/       \-------------/    |
                                      | yes                 | yes       |
                                      |     +---------------+           |
                                      V     V                           V
                              +---------------+                 +---------------+
                              |     IANA      |                 | Third party   |
                              | registration  |                 | registration  |
                              +-------+-------+                 +-------+-------+
                                      |                                 |
                                      +---------------------------------+
                                      V



Veillette, et al.        Expires August 29, 2020               [Page 32]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


                                    [DONE]

                          Figure 1: SID Lifecycle

C.2.  SID File Update

   The following Activity diagram summarizes the update of a YANG module
   and its associated ".sid" file.











































Veillette, et al.        Expires August 29, 2020               [Page 33]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


          +---------------+
     O    | Update of the |
    -|- ->| YANG module   |
    / \   | or include(s) |
          | or import(s)  |
          +---------------+
                  |
                  V
              /-------------\
             /  New items    \ yes
             \  created  ?   /------+
              \-------------/       |
                     | no           V
                     |       /-------------\      +----------------+
                     |      /  SID range    \ yes | Extra sub-range|
                     |      \  exhausted ?  /---->| assignment     |
                     |       \-------------/      +----------------+
                     |              | no                  |
                     |              +---------------------+
                     |              |
                     |              V
                     |      +---------------+
                     |      | ".sid" file   |
                     |      | update based  |
                     |      | on previous   |
                     |      | ".sid" file   |
                     |      +---------------+
                     |              |
                     |              V
                     |       /-------------\      +---------------+
                     |      /  Publicly     \ yes | YANG module   |
                     |      \  available ?  /---->| registration  |
                     |       \-------------/      +---------------+
                     |              | no                  |
                     +--------------+---------------------+
                                    |
                                  [DONE]


                    Figure 2: YANG and SID file update

Authors' Addresses









Veillette, et al.        Expires August 29, 2020               [Page 34]

Internet-Draft      YANG Schema Item iDentifier (SID)      February 2020


   Michel Veillette (editor)
   Trilliant Networks Inc.
   610 Rue du Luxembourg
   Granby, Quebec  J2J 2V2
   Canada

   Phone: +14503750556
   Email: michel.veillette@trilliant.com


   Alexander Pelov (editor)
   Acklio
   1137A avenue des Champs Blancs
   Cesson-Sevigne, Bretagne  35510
   France

   Email: a@ackl.io


   Ivaylo Petrov (editor)
   Acklio
   1137A avenue des Champs Blancs
   Cesson-Sevigne, Bretagne  35510
   France

   Email: ivaylo@ackl.io

























Veillette, et al.        Expires August 29, 2020               [Page 35]

--turc4kgeatbxhx3k--


From nobody Thu Feb 27 12:40:31 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BAD3A0B94; Thu, 27 Feb 2020 12:40:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etE1IMQJqklN; Thu, 27 Feb 2020 12:40:27 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258D43A0B93; Thu, 27 Feb 2020 12:40:24 -0800 (PST)
Received: from [192.168.217.147] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48T4LG1kwhzyx1; Thu, 27 Feb 2020 21:40:22 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <2D679FD0-F95F-488E-BCC4-0B90693FDA3A@tzi.org>
Date: Thu, 27 Feb 2020 21:40:21 +0100
X-Mao-Original-Outgoing-Id: 604528821.628999-371b0a9e957cd4dac97a078f7cff9f8d
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F01EBBE-B43C-4140-9E97-6477F6812B97@tzi.org>
References:  <2D679FD0-F95F-488E-BCC4-0B90693FDA3A@tzi.org>
To: "core@ietf.org WG" 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [core]  =?utf-8?q?=F0=9F=94=94_CoRE_Working_Group_Adoption_call_f?= =?utf-8?q?or_draft-jarvinen-core-fasor-02?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Feb 2020 20:40:29 -0000

On 2019-12-09, at 18:17, Carsten Bormann  wrote:
>=20
> I know we are entering the slow season,

Well, waiting some more did provide some more positive voices, and no =
negative ones.

The chairs believe we have (barely, but positively) crossed the =
threshold for adoption. =20
Some more pronounced energy will be needed in further processing this =
specification; I hope that everybody was just waiting for adoption.

Authors: Please resubmit the specification as draft-ietf-core-fasor-00

Gr=C3=BC=C3=9Fe, Carsten


From nobody Fri Feb 28 14:38:59 2020
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 598EF3A1FAA; Fri, 28 Feb 2020 14:35:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: core@ietf.org, aamelnikov@fastmail.fm
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158292932335.19931.5534167319202799145@ietfa.amsl.com>
Date: Fri, 28 Feb 2020 14:35:23 -0800
Archived-At: 
Subject: [core] core - Requested sessions have been scheduled for IETF 107
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2020 22:35:29 -0000

Dear Carsten Bormann,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


    core Session 1 (1:30 requested)
    Tuesday, 24 March 2020, Afternoon Session II 1550-1720
    Room Name: Regency F size: 150
    ---------------------------------------------
    core Session 2 (1:30 requested)
    Wednesday, 25 March 2020, Afternoon Session II 1520-1650
    Room Name: Plaza A size: 100
    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/107/sessions/core.ics

Request Information:


---------------------------------------------------------
Working Group Name: Constrained RESTful Environments
Area Name: Applications and Real-Time Area
Session Requester: Carsten Bormann

Number of Sessions: 2
Length of Session(s):  1.5 Hours, 1.5 Hours
Number of Attendees: 60
Conflicts to Avoid: 
 Chair Conflict: cbor t2trg cose artarea rats lake suit
 Technology Overlap: ace teep saag secdispatch sacm lwig 6tisch 6lo roll httpbis lpwan raw
 Key Participant Conflict: dnssd netconf netmod emu dots anima irtfopen


People who must be present:
  Carsten Bormann
  Alexey Melnikov
  Jaime Jimenez

Resources Requested:

Special Requests:
  Plse also avd any potntlly IoT reltd BOFs&PRGs tht mght cme up, including any "LOOPS".
Prefer some time between the two meetings (48 h or more).
Second meeting often is 40 people.
---------------------------------------------------------



From nobody Fri Feb 28 14:54:11 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FC43A1FB9; Fri, 28 Feb 2020 14:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94c9vceH8_7K; Fri, 28 Feb 2020 14:53:52 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C2E3A0DBA; Fri, 28 Feb 2020 14:53:52 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 6346FF40714; Fri, 28 Feb 2020 14:53:36 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, core@ietf.org
Content-type: text/plain; charset=UTF-8
Message-Id: <20200228225336.6346FF40714@rfc-editor.org>
Date: Fri, 28 Feb 2020 14:53:36 -0800 (PST)
Archived-At: 
Subject: [core] =?utf-8?q?RFC_8710_on_Multipart_Content-Format_for_the_Co?= =?utf-8?q?nstrained_Application_Protocol_=28CoAP=29?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2020 22:54:01 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 8710

        Title:      Multipart Content-Format for the Constrained 
                    Application Protocol (CoAP) 
        Author:     T. Fossati,
                    K. Hartke,
                    C. Bormann
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2020
        Mailbox:    thomas.fossati@arm.com, 
                    klaus.hartke@ericsson.com, 
                    cabo@tzi.org
        Pages:      9
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-core-multipart-ct-04.txt

        URL:        https://www.rfc-editor.org/info/rfc8710

        DOI:        10.17487/RFC8710

This memo defines application/multipart-core, an
application-independent media type that can be used to combine
representations of zero or more different media types (each with a
Constrained Application Protocol (CoAP) Content-Format identifier)
into a single representation, with minimal framing overhead.

This document is a product of the Constrained RESTful Environments Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


From nobody Fri Feb 28 15:14:18 2020
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6AD3A1D7B; Fri, 28 Feb 2020 15:14:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES3ef0pgZ7Ge; Fri, 28 Feb 2020 15:14:02 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3B93A1E33; Fri, 28 Feb 2020 15:14:01 -0800 (PST)
Received: from [172.16.42.113] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48Tlj32lpmz1802; Sat, 29 Feb 2020 00:13:59 +0100 (CET)
From: Carsten Bormann 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mao-Original-Outgoing-Id: 604624438.807252-ba49cb160872526025462a7291810c55
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Sat, 29 Feb 2020 00:13:58 +0100
Message-Id: <0CE57F79-ADE0-45D5-9142-D79F687DC2A1@tzi.org>
To: Ace Wg , "core@ietf.org WG" , cose@ietf.org,  cbor@ietf.org, t2trg@irtf.org
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: [core] Constrained Node/Network Cluster @ IETF107: FINAL AGENDA
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2020 23:14:06 -0000

Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF107.  Remember that, occasionally, futher agenda changes do
happen.

Not much change from the DRAFT AGENDA.  SUIT has moved to Friday, now
on top of 6lo.  The other security/not-so-much-security conflicts in
the IoT space remain or have just been rearranged: ROLL vs. COSE/TEEP,
LPWAN vs. SAAG, and LAKE vs. RATS, WPACK vs. ACE; as are MODEL-T
vs. CORE and TXAUTH vs. T2TRG.  (A lot of the rooms have changed.)

All times are in PDT =3D=3D UTC - 7 hours.  Note that North America is =
on
DST already during the IETF, while Europe will only go there on March
29, so we are in the three-week period of DST confusion (where the US
is one hour closer to the EU than the rest of the year).
(Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are
useful for those who want to listen from remote.)

Gr=C3=BC=C3=9Fe, Carsten

FRIDAY, March 20, 2020
0900-1800 T2TRG/W3C WoT Workshop =
https://github.com/t2trg/2020-03-vancouver

SATURDAY, March 21, 2020
0830-2200  IETF Hackathon - Plaza Ballroom

SUNDAY, March 22, 2020
0830-1600  IETF Hackathon - Plaza Ballroom
1700-1900  Welcome Reception - Regency A/B/C/D
1800-2000  Hot RFC Lightning Talks -- Plaza B/C

MONDAY, March 23, 2020

1000-1200  Morning Session I
Regency D	ART	dispatch	Dispatch WG - Joint with ARTAREA
Regency C	INT	6man	IPv6 Maintenance WG
Plaza B/C	IRTF	pearg	Privacy Enhancements and Assessments =
Research Group

1330-1530  Afternoon Session I
Regency C	ART	webtrans	WebTransport WG
Regency D	IRTF	maprg	Measurement and Analysis for Protocols
Georgia B	SEC	mls	Messaging Layer Security WG
Regency E	SEC	oauth	Web Authorization Protocol WG
Plaza A 	SEC ***	rats	Remote ATtestation ProcedureS WG

1550-1750  Afternoon Session II
Regency F	INT	add	Adaptive DNS Discovery WG
Regency C	IRTF	irtfopen	IRTF Open Meeting
Regency E	OPS	anima	Autonomic Networking Integrated Model =
and Approach WG
Plaza A 	RTG	raw	Reliable and Available Wireless WG
Plaza B/C	SEC	secdispatch	Security Dispatch WG

1810-1910  Afternoon Session III
Plaza A 	RTG ***	roll	Routing Over Low power and Lossy =
networks WG
Georgia B	SEC ***	cose	CBOR Object Signing and Encryption WG
Plaza B/C	SEC	tls	Transport Layer Security WG
Regency C	TSV	tsvarea	Transport Area Open Meeting

TUESDAY, March 24, 2020

0830-0945  Side Meetings / Open Time
Regency C		tdd	Technology Deep Dive

1000-1200  Morning Session I
Regency D	IRTF***	dinrg	Decentralized Internet Infrastructure
Regency F	SEC	acme	Automated Certificate Management =
Environment WG
Regency E	SEC ***	teep	Trusted Execution Environment =
Provisioning WG
Plaza B/C	TSV	quic	QUIC WG

1330-1530  Afternoon Session I
Regency C	INT	masque	Multiplexed Application Substrate over =
QUIC Encryption BOF
Regency D	IRTF	coinrg	Computing in the Network Research Group
Georgia A	RTG ***	roll	Routing Over Low power and Lossy =
networks WG
Regency E	SEC	emu	EAP Method Update WG
Georgia B	SEC ***	teep	Trusted Execution Environment =
Provisioning WG

1550-1720  Afternoon Session II
Regency F	ART ***	core	Constrained RESTful Environments WG
Plaza A 	IRTF	qirg	Quantum Internet Proposed Research Group
Georgia B	SEC	oauth	Web Authorization Protocol WG
Regency C	TSV	tsvwg	Transport Area Working Group WG

1740-1840  Afternoon Session III
Regency C	INT	6man	IPv6 Maintenance WG
Georgia B	INT ***	drip	Drone Remote ID Protocol WG
Georgia A	RTG	babel	Babel routing protocol WG
Regency D	RTG	detnet	Deterministic Networking WG
Regency E	RTG	rift	Routing In Fat Trees WG
Plaza B/C	TSV	quic	QUIC WG

WEDNESDAY, March 25, 2020

1000-1200  Morning Session I
Georgia B	IRTF***	t2trg	Thing-to-Thing
Georgia A	RTG	bier	Bit Indexed Explicit Replication WG
Regency D	SEC	txauth	Transactional Authorization and =
Delegation BOF
Plaza B/C	TSV	quic	QUIC WG

1330-1500  Afternoon Session I
Regency C	ART	wpack	Web Packaging BOF
Regency E	IRTF	panrg	Path Aware Networking RG
Georgia A	SEC ***	ace	Authentication and Authorization for =
Constrained Environments WG

1520-1650  Afternoon Session II
Plaza A 	ART ***	core	Constrained RESTful Environments WG
Georgia A	IAB	model-t	Internet Threat Model
Plaza B/C	RTG	rtgarea	Routing Area Open Meeting

1710-1940  IETF Plenary - Regency C/D/E/F

THURSDAY, March 26, 2020

1000-1200  Morning Session I
Georgia A	ART ***	cbor	Concise Binary Object Representation =
Maintenance and Extensions WG
Georgia B	INT	dnssd	Extensions for Scalable DNS Service =
Discovery WG - Joint with HOMENET
Georgia B	INT	homenet	Home Networking WG - Joint with DNSSD
Regency E	IRTF	icnrg	Information-Centric Networking
Regency C	SEC	privacypass	privacy-pass BOF
Plaza B/C	TSV	taps	Transport Services WG

1330-1530  Afternoon Session I
Regency E	INT ***	lpwan	IPv6 over Low Power Wide-Area Networks =
WG
Regency F	OPS	v6ops	IPv6 Operations WG
Regency D	SEC	saag	Security Area Open Meeting

1550-1720  Afternoon Session II
Regency C	ART	httpbis	HTTP WG
Regency E	INT	intarea	Internet Area Working Group WG
Regency D	IRTF	cfrg	Crypto Forum
Plaza B/C	RTG	detnet	Deterministic Networking WG

1740-1840  Afternoon Session III
Plaza A 	ART	uta	Using TLS in Applications WG
Regency D	OPS	anima	Autonomic Networking Integrated Model =
and Approach WG

FRIDAY, March 27, 2020

1000-1200  Morning Session I
Regency F	INT ***	6lo	IPv6 over Networks of =
Resource-constrained Nodes WG
Regency E	SEC ***	suit	Software Updates for Internet of Things =
WG
Regency C	SEC	tls	Transport Layer Security WG
Plaza B/C	TSV	tsvwg	Transport Area Working Group WG

1220-1350  Morning Session II
Regency D	ART	httpbis	HTTP WG
Regency C	IRTF	coinrg	Computing in the Network Research Group
Regency F	SEC ***	lake	Lightweight Authenticated Key Exchange =
WG
Plaza A 	SEC ***	rats	Remote ATtestation ProcedureS WG