From nobody Fri Jan 3 21:45: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 121A41200B4 for ; Fri, 3 Jan 2020 21:45:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BREzXejAbEin for ; Fri, 3 Jan 2020 21:44:58 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9FE120020 for ; Fri, 3 Jan 2020 21:44:57 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 3 Jan 2020 21:44:52 -0800 From: Jim Schaad To: References: <157811644385.9055.11245305033866793986.idtracker@ietfa.amsl.com> In-Reply-To: <157811644385.9055.11245305033866793986.idtracker@ietfa.amsl.com> Date: Fri, 3 Jan 2020 21:44:50 -0800 Message-ID: <014701d5c2c2$167b9720$4372c560$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJBs+XzqpQA93F+3h2bkftH4+EGcacCG2nQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] FW: New Version Notification for draft-schaad-core-reef-00.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: Sat, 04 Jan 2020 05:45:00 -0000 I have not really been happy with how Klaus has outlined his core app = documents. I have therefore done a start of how I think that a core app = should be documented and have used the Resource Directory as an example. I have adhered closer to the current RD document than what Klaus did, it = is not by any means a complete document but it should be sufficient for = people to look at and understand what I am shooting for. I am more interested in how a core app document is done than in the RD = document itself, but would like to hear comments on both. Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Friday, January 3, 2020 9:41 PM To: Jim Schaad Subject: New Version Notification for draft-schaad-core-reef-00.txt A new version of I-D, draft-schaad-core-reef-00.txt has been = successfully submitted by Jim Schaad and posted to the IETF repository. Name: draft-schaad-core-reef Revision: 00 Title: CoAP Application version of Resource Directory Document date: 2020-01-03 Group: Individual Submission Pages: 17 URL: = https://www.ietf.org/internet-drafts/draft-schaad-core-reef-00.txt Status: https://datatracker.ietf.org/doc/draft-schaad-core-reef/ Htmlized: https://tools.ietf.org/html/draft-schaad-core-reef-00 Htmlized: = https://datatracker.ietf.org/doc/html/draft-schaad-core-reef Abstract: This is a draft of what I think a CoRE Application should look like. = =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. The IETF Secretariat From nobody Wed Jan 8 02:23: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 CF91D12006E for ; Wed, 8 Jan 2020 02:23:51 -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 ygtIPEE9zRX4 for ; Wed, 8 Jan 2020 02:23:50 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 B22A7120018 for ; Wed, 8 Jan 2020 02:23:49 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id f129so1884714wmf.2 for ; Wed, 08 Jan 2020 02:23:49 -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=51MI8oWyAtgiDieuwD9YvPJeZwy18b3lR72bCKpLszk=; b=q865noLVMaDZ7lCheSDq89tK+739UK/v4/82bVcR4eQxK10TeP8lN8KVr5cjQAFHkg eWm0lgCfSPXoSZ6z1gVP+VtKojISJA84szBRykGr26g4IvPpRnHoHymtGakvCqNSnCiX psj7QXkVOli2eQ3nPrUTVK5oaLaOHI+VQ75dSnx+uELHdERF6ckA6KWAUpRY5Taq6gXv FUnvCdHYjRJclZmYsPZ1aoHIqMqIpruCF0/Z2z7iU2z9+oGtuNXHjdvgj1AM5v1sahne C7EJuRZKymm/E8035IR8gNb3KmZ4mbVn0TyBz4I9p8pH1REAn7Y48vbgsBf3M2r5V4x9 LTaA== 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=51MI8oWyAtgiDieuwD9YvPJeZwy18b3lR72bCKpLszk=; b=RHYuAiFCrGZiWVO+nVmIDCJy6QmnMvnffEEofH1kRVfv2V43vSMxyzaUy3xLQr+z/X XAxKNH9beeczgl7OG6QK+jDSaN+xM4VoIQ0JrOB3gZ5I4wrwJvcVtWtnLyPzANy3TwO4 CWmPezUQqa4At+v6HlOiXxE+BUE4HsZDBRZmDvbQGH+ULyDDrC0797BDKSkzjOpz/x/Z ofqCjBcfPM+BGbOp1V5LuQNMfP85kxpomm1c4FWRsthhfhnrGUwLitPk+VVR/M4PC51M tLF5AKjJQDh/QIvPj5/h8xuGVyJ4ajuDIoM/7TlC93sb51UYs87aNJ9qA5GQJ6vZG/Tl TBaA== X-Gm-Message-State: APjAAAUVi36/65gxd8RYKSmCKaPLg1ZdFCnWHlDvpH1s3GI5/2KFZbGk 9alOH4q18nzXx6HIvEtXWnHptYWC+X7JSNsC2QNp6w== X-Google-Smtp-Source: APXvYqzFeEg7C26386g6YbwRXRjXJRmDVnEaBuuijJARjLegKvnA8GPcqZvpL9l/+hBXES2Y6+Pc3ZT4+gNxrHLNnwA= X-Received: by 2002:a1c:3c8b:: with SMTP id j133mr2988732wma.66.1578479027741; Wed, 08 Jan 2020 02:23:47 -0800 (PST) MIME-Version: 1.0 References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <0bfb0f10f1a5001a588047a79d6db792@bbhmail.nl> In-Reply-To: <0bfb0f10f1a5001a588047a79d6db792@bbhmail.nl> From: Ivaylo Petrov Date: Wed, 8 Jan 2020 11:23:21 +0100 Message-ID: To: consultancy@vanderstok.org Cc: Michael Richardson , core , Michel Veillette , Alexander Pelov Content-Type: multipart/alternative; boundary="000000000000bc1c80059b9e490c" 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, 08 Jan 2020 10:23:52 -0000 --000000000000bc1c80059b9e490c Content-Type: text/plain; charset="UTF-8" Hello, I am working on a new version of the SID draft that would address the comments related to 63bit SIDs and looking to clarify how are .sid files passed to IANA. Those are the only comments that I have received and I believe they are not blocking the WGLC. What I heard during the last IETF was that this draft is WGLC material, https://youtu.be/YIHoiHhz2Ys?t=1280 and I was expecting the CoRE chairs to go ahead with this. If you believe there is some misunderstanding on my side and there are other issues that need to be resolved before the WGLC, please let me know. Best regards, Ivaylo 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 Mon, Dec 30, 2019 at 11:08 AM Peter van der Stok wrote: > > I have not seen any progress on: > 1) https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ > 2) https://datatracker.ietf.org/doc/draft-ietf-core-sid/ > > At IETF105, it seemed that the documents were unstuck, and would progress > to WGLC soon. Is there something holding this up other than author time? > > > > I also want to express my concern about the VERY slow progress of these > documents. > It is quite possible and understandable that the authors are occupied with > too many other tasks. > > An additional author may be the answer to unstick the progress. > > Greetings, > > Peter > > --000000000000bc1c80059b9e490c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I am work= ing on a new version of the SID draft that would address the comments relat= ed to 63bit SIDs and looking to clarify how are .sid files passed to IANA. = Those are the only comments that=C2=A0I have received and I believe they ar= e not blocking the WGLC. What I heard during the last IETF was that this dr= aft is WGLC material,=C2=A0https://youtu.be/YIHoiHhz2Ys?t=3D1280 and I was expecting the CoRE ch= airs to go ahead with this. If you believe there is some misunderstanding o= n my side and there are other issues that need to be resolved before the WG= LC, please let me know.

Best regards,
Ivaylo

=
=
<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt;te= xt-align:justify">CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for t= he sole use of the intended recipient(s).

It is strictly forbidden to share any part o= f this message with any third party, without the written consent of the sen= der.

If you have received this mess= age by mistake, please notify the sender immediately by email and delete th= e message and any file attached to it. Thank you!

=
=


On Mon, Dec 30, 2019 at 11:08 AM= Peter van der Stok <stokcons@bbh= mail.nl> wrote:

I have not = seen any progress on:
=C2=A0=C2=A01) https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/
= =C2=A0=C2=A02) https://datatracker.iet= f.org/doc/draft-ietf-core-sid/

At IETF105, it seemed that the do= cuments were unstuck, and would progress
to WGLC soon.=C2=A0 Is there so= mething holding this up other than author time?



I also want to = express my concern about the VERY slow progress of these documents.
It i= s quite possible and understandable that the authors are occupied with too = many other tasks.

An additional author may be the answer to unstick = the progress.

Greetings,

Peter
--000000000000bc1c80059b9e490c-- From nobody Wed Jan 8 03:01:08 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 05639120854 for ; Wed, 8 Jan 2020 03:01:04 -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 86xFuWefCu1f for ; Wed, 8 Jan 2020 03:01: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 5354B12083D for ; Wed, 8 Jan 2020 03:01:00 -0800 (PST) Received: from client-0236.vpn.uni-bremen.de (client-0236.vpn.uni-bremen.de [134.102.107.236]) (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 47t5rp2P43z16JC; Wed, 8 Jan 2020 12:00:58 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 8 Jan 2020 12:00:56 +0100 Cc: peter van der Stok , core Content-Transfer-Encoding: quoted-printable Message-Id: <0445EBA6-CB2E-4331-AE23-3E54D0923552@tzi.org> References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <0bfb0f10f1a5001a588047a79d6db792@bbhmail.nl> To: Ivaylo Petrov X-Mailer: Apple Mail (2.3608.40.2.2.4) 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, 08 Jan 2020 11:01:06 -0000 Hi Ivaylo, The minutes indeed say: * draft-ietf-core-yang-cbor-11, draft-ietf-core-yang-library-00, draft-ietf-core-comi-08, draft-ietf-core-sid-07: Now ready for WGLC, to be sent to CoRE as well as netconf/netmod (with the discussion to happen on CoRE). (One comment on the numeric range of SIDs still to be taken care of.) The parenthesis may have been a bit cryptic, but the intention was = indeed to have I-D versions with all known issues (including the 63-bit = one) addressed. Is there a reason this will need more time? Gr=C3=BC=C3=9Fe, Carsten > On 2020-01-08, at 11:23, Ivaylo Petrov wrote: >=20 > Hello, >=20 > I am working on a new version of the SID draft that would address the = comments related to 63bit SIDs and looking to clarify how are .sid files = passed to IANA. Those are the only comments that I have received and I = believe they are not blocking the WGLC. What I heard during the last = IETF was that this draft is WGLC material, = https://youtu.be/YIHoiHhz2Ys?t=3D1280 and I was expecting the CoRE = chairs to go ahead with this. If you believe there is some = misunderstanding on my side and there are other issues that need to be = resolved before the WGLC, please let me know. >=20 > Best regards, > Ivaylo >=20 > 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! >=20 >=20 > On Mon, Dec 30, 2019 at 11:08 AM Peter van der Stok = wrote: >>=20 >> I have not seen any progress on: >> 1) https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ >> 2) https://datatracker.ietf.org/doc/draft-ietf-core-sid/ >>=20 >> At IETF105, it seemed that the documents were unstuck, and would = progress >> to WGLC soon. Is there something holding this up other than author = time? >>=20 >>=20 >>=20 >> I also want to express my concern about the VERY slow progress of = these documents. >> It is quite possible and understandable that the authors are occupied = with too many other tasks. >>=20 >> An additional author may be the answer to unstick the progress. >>=20 >> Greetings, >>=20 >> Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Jan 8 04:51:08 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 C506312011C for ; Wed, 8 Jan 2020 04:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 (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 gqJSelatil1h for ; Wed, 8 Jan 2020 04:51:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 9A1CC120026 for ; Wed, 8 Jan 2020 04:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578487860; bh=yNBVonVyUqkbdl/WDjoj5EN0dfNjIwKZSqlu6dQhRmE=; h=X-UI-Sender-Class:To:From:Subject:Date; b=QbdCYvSDyddilKDG93L1fp7tqAWHAqXkHFZ5+Se53LmgqpHo1a4wuOFWYXRd6y/J8 1GYw8S74Z8M8OvHkP/92hfwxW0jQCFCYc7N5CJovxanN6Msqxl7iFIEklEzPub1v5U 7Rx2muRY739PW8BAL1e1BBeFFLdBAAFgx+flz7hs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([178.2.231.191]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1McH9i-1jPLZ223lk-00clra for ; Wed, 08 Jan 2020 13:51:00 +0100 To: "core@ietf.org" From: Achim Kraus Message-ID: <324677e1-06d4-a4d6-b79c-9a55c01adcbb@gmx.net> Date: Wed, 8 Jan 2020 13:50:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:cC+bo8SCU0xJWrYc6i5cLgrRjBm+JfPnbC5kjXFNZP3KcfvwhCt Nq8ZnU86QQ01iu8pVE2uNiGrAfa/HLOQiBFSRK+Rwm10AHy4O1Y7lGSJOSksAjZ2n89vuri eGpCZW/p29piH5OcFp+zghInWI7aZUGuUYOFecpUjjT/G9VRkvke2prQjjNP3VjEFJQXEmi ZyhVeZFiDjMcG+kCwwfLw== X-UI-Out-Filterresults: notjunk:1;V03:K0:iWIzhQxpmD4=:hANxf3YpinJ5EEAczM5F7l AsHmV1Q+GQ8dltzMfe318iG4e+LgwUMU6SaeBlujvziaXoeLvut3Usu0nUib7DVXtFUhTrZBR cazoQrh6QhQdA5JWXYDvKvlzIujohQSupM8IfK6RJTBfyWRADQgwYK4JJ932/JIh90jJe2O2q U+pS9MwWzQVJboOKLavckEsuTR3Po6MNhSK1B8wRBttQXJHMcuHdMwrdVKGe3IMBvUG9tbpiv KQZFNHWRoxE1S2xkvzdVt8ZAFP1maqZwSU8SFhqfeIXiopeE9m/TX4+xmhRExQSgAYLYwmajY iEZ5jf0cDzLYLd43rqAiopUYk67s9hS12aaCgJY7QP+ZRDhRCuGKvd9vR56EdLr60P5m+a2IR JswHSMV5wTsDzlTvZrkgJ9lEPLNlOx0wgTuGDA+MjnFQsPLdO1TffWDVC0aaAB096941Tb7Tl 9JN+wOfzW9rI1oLsQiiOC4vz8DNCX0rH4WsVRSX1c912/sZ6+cPCT2CwVgOud0Q8QUIAp6Ab0 jqmip2MeeKqrXebqw6OioMM0BeKAgHEIODayTxNeARHpClqmS6kivQJ6HSjLeDjt6MKj/6pg5 /lkEArPNFWMvLyOHgSkwwDvbQc8mMOu1EF0jHFgIDcA8cFNxxF/O5akdHlF179iKktmfrv2Iu uKUW9D0m+mLNXSdN5JdM7T4TD46WkcvnC5CdKE/CTwrDYOMjUFkQuuFOyxZz2AJ55HRaUaIo9 nhtoNFo0rytkM//LHfdZRU2wrX8vOp8r6pR7wst6/gWDAUl03AJ52qCQrUrFbMu6BPCQggEzO RCFZiih95PSLdAwTt/XrhUbx+lAmxWkclcrRnx9LdelvIt+F9YupgAXQ8yJEkTh79zmeJyD0h mN2AAGPBePhGqPR9sO9O4TAxecFdW83v2Dl2CyyUOAPoDwvt0T8cPwcN43N2l1cEJxlXHBO+9 hfWXJpWtOkgqrIriZLr1dh/PAQTH1fQazoOIs8gjobW1ZQM5Jmyw9Ofw8Kx0i0y7EJR8wYU+r +i8ZbZxv+3Msuad3+ttl1ofN3x5lp30ZYloySJsOSut/jIqaLLY6Mz6Nh0a/UJbCQCcxCuO/0 oIh2DF2T6QaQsRJ8by5Fed1MNaJu8A6MSYBKf8NDb70nzDiNvk2l45/oVdnl2MR70uQQLKaBo m75GarB2sJ+qCqtQtoDZVVpFdYPidXzxaSTHtrQpyj4yS1vPs1R754FHcWGP2WZwQqhcSlKQA V4WJrKW6IJgFNmjy1Q4BqYhTFr4dlUsBR/3NuHreZ22I6WTGcMLzGNxnMqjk= Archived-At: Subject: [core] RFC 7252 - Forward Proxies 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, 08 Jan 2020 12:51:07 -0000 Dear Core-List, I'm currently try to spend some time in working on Californium's "Forward Proxies" support according https://tools.ietf.org/html/rfc7252#section-5.7.2. Studying this section in combination with "Decomposing URIs into Options" according https://tools.ietf.org/html/rfc7252#section-6.4 I'm not sure, if 6.4 requires some more clarification considering 5.7.2. Point 5 in 6.4 describes the processing for the host: "5. If the component of |url| does not represent the request's destination IP address as an IP-literal or IPv4address, include a Uri-Host Option and let that option's value be the value of the component of |url|, converted to ASCII lowercase, and then convert all percent-encodings ("%" followed by two hexadecimal digits) to the corresponding characters. NOTE: In the usual case where the request's destination IP address is derived from the host part, this ensures that a Uri- Host Option is only used for a component of the form reg- name." A informal description would be in my opinion, add the uri-host option, if it's not the IP-literal of the destination (that assumes, that the term "destination" refers to the actual proxy to send the request to). But the text seems not to differentiate between the request's (which maybe the proxy) and the URI destination (which will be the "final destination", or something like that). I'm also not sure, what the "or IPv4address" refers to. For me it seems, that stick strict to 6.4 would cause different option values, if a proxy is used and the "final destination" URI contains also a (different) literal IP address. For me "strict" will then result in a wrong request to the proxy. Point 6 in 6.4 describes the processing for the port: 6. If |url| has a component, then let |port| be that component's value interpreted as a decimal integer; otherwise, let |port| be the default port for the scheme. "6 ... otherwise": if a Proxy-Scheme is used, should that default port be use? Or still the URI-Scheme's port? If the Proxy-Scheme is to be considered, that default port maybe unclear/unknown by the client implementation. Best regards Achim Kraus From nobody Wed Jan 8 08:51:58 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 087DF120144; Wed, 8 Jan 2020 08:51:57 -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.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <157850231689.22615.15931536625261379445@ietfa.amsl.com> Date: Wed, 08 Jan 2020 08:51:57 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-coral-02.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, 08 Jan 2020 16:51:57 -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 : The Constrained RESTful Application Language (CoRAL) Author : Klaus Hartke Filename : draft-ietf-core-coral-02.txt Pages : 40 Date : 2020-01-08 Abstract: The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as two specialized serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coral/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-coral-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-coral-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coral-02 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 Jan 8 08:52: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 DFA63120863; Wed, 8 Jan 2020 08:52: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.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <157850232385.22469.17608607824373225606@ietfa.amsl.com> Date: Wed, 08 Jan 2020 08:52:03 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-href-02.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, 08 Jan 2020 16:52:10 -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 : Constrained Resource Identifiers Author : Klaus Hartke Filename : draft-ietf-core-href-02.txt Pages : 14 Date : 2020-01-08 Abstract: Constrained Resource Identifiers (CoRIs) are an alternate serialization of Uniform Resource Identifiers (URIs) that encodes the URI components in Concise Binary Object Representation (CBOR) instead of a string of characters. This simplifies parsing, reference resolution, and comparison of URIs in environments with severe limitations on processing power, code size, and memory size. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-href/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-href-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-href-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-href-02 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 Jan 8 14:19:03 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 888F51200C7; Wed, 8 Jan 2020 14:19:01 -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.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <157852194147.22579.14430890704683067786@ietfa.amsl.com> Date: Wed, 08 Jan 2020 14:19:01 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-08.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, 08 Jan 2020 22:19:02 -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-08.txt Pages : 29 Date : 2020-01-08 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-08 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 Jan 8 14:25: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 6AF5112010C for ; Wed, 8 Jan 2020 14:25:00 -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 OXy1PxNF2sWv for ; Wed, 8 Jan 2020 14:24:58 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 D879E1200C7 for ; Wed, 8 Jan 2020 14:24:57 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id a5so688696wmb.0 for ; Wed, 08 Jan 2020 14:24:57 -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=kDem4OJiRJhtZjADmGZawO9ndUOjH1E8kWIGFsl5Y+A=; b=0zaPgAFJgMHgKQIDWK7YHcLBshFRx5DzzUXAG4PaJxS3+b/p0GwRVhud/FXJGh2CIr 3dBMRIcikaEVfG510ij+aQG3AWdzZpfADRTG6BnVMsObfeIwjmP2d+2r5PTMQ/WgJbNB Er6ylAuaXYJATbeRLMHv3vEPfSphoPDLYBqk13cq0VvgS5tLdnOjjV30aQN2XpTBwqKl 2uvZe4Jf5Zv/whzxa5KXWIivqht7IBQr0EahZlU3RFbS2x7YfyC2OfqrpUmg0VOLiYl7 QpBFfIXqP4oGoMJNFb1e9CRAf7wNYP9S2NVMhVNWX3exJPU/3avmB7hS9Z8cYs3lj4G1 3jQA== 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=kDem4OJiRJhtZjADmGZawO9ndUOjH1E8kWIGFsl5Y+A=; b=KaJtZ0pf13HFdds6VCxyMTTBKngbIabr/vP+oWXBJzQmp6h5TbGAL2/KhiQAb7prkc YF4STVL3LNeTvvkWJNgowUWDOJUrUJF/iOIugDu3DaUPiJCnoY041xEyO8myQpr2CdtX i6j3AYARfL8rsqvy554tkvwbBI/EgjtgYmzwA2jrbhpryiqnRHf4JdEakyeSI7cCB2Jk JSaARaiLlIzWaDhpJ6DKC9gNaH5lePO9xeEHPacT2RIBAip6VnEdlDMRrUKK5qOYrjJg Tx1F94j6RWOyiyk1yu9VNS2MIRtQzKDxO27fz4khKhIsbT4d6OacsfXSnn+m4BhW86Dy 8d9Q== X-Gm-Message-State: APjAAAWT0sLydAbi/jcCvdI5k/DtMt2j6yFe5aP/7KQxYV626l6wDPlw VT4Vjv6G2fxhVzluWh05xLsbutaDMuWsO+6midO+SPbUOyk= X-Google-Smtp-Source: APXvYqyUSg3fDSqCeb+9HXRHz1oMgcmviovVS+n/slapU/ibiOD0HC5Ei34ZQfTBZZ9Uzs1+jBpUDYWif+J2UMjrhkc= X-Received: by 2002:a1c:9814:: with SMTP id a20mr881226wme.94.1578522296370; Wed, 08 Jan 2020 14:24:56 -0800 (PST) MIME-Version: 1.0 References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <0bfb0f10f1a5001a588047a79d6db792@bbhmail.nl> <0445EBA6-CB2E-4331-AE23-3E54D0923552@tzi.org> In-Reply-To: <0445EBA6-CB2E-4331-AE23-3E54D0923552@tzi.org> From: Ivaylo Petrov Date: Wed, 8 Jan 2020 23:24:30 +0100 Message-ID: To: Carsten Bormann Cc: peter van der Stok , core Content-Type: multipart/alternative; boundary="000000000000bee551059ba85cd5" 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, 08 Jan 2020 22:25:01 -0000 --000000000000bee551059ba85cd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Carsten, I was not aware that this is the blocking point and that is why I had put much less priority to this modification. I should have read more carefully the minutes, my bad. I have uploaded a new version now that addresses this issue. Best regards, Ivaylo On Wed, Jan 8, 2020 at 12:00 PM Carsten Bormann wrote: > Hi Ivaylo, > > The minutes indeed say: > > * draft-ietf-core-yang-cbor-11, draft-ietf-core-yang-library-00, > draft-ietf-core-comi-08, draft-ietf-core-sid-07: Now ready for WGLC, > to be sent to CoRE as well as netconf/netmod (with the discussion to > happen on CoRE). (One comment on the numeric range of SIDs still to > be taken care of.) > > The parenthesis may have been a bit cryptic, but the intention was indeed > to have I-D versions with all known issues (including the 63-bit one) > addressed. Is there a reason this will need more time? > > Gr=C3=BC=C3=9Fe, Carsten > > > > On 2020-01-08, at 11:23, Ivaylo Petrov wrote: > > > > Hello, > > > > I am working on a new version of the SID draft that would address the > comments related to 63bit SIDs and looking to clarify how are .sid files > passed to IANA. Those are the only comments that I have received and I > believe they are not blocking the WGLC. What I heard during the last IETF > was that this draft is WGLC material, https://youtu.be/YIHoiHhz2Ys?t=3D12= 80 > and I was expecting the CoRE chairs to go ahead with this. If you believe > there is some misunderstanding on my side and there are other issues that > need to be resolved before the WGLC, please let me know. > > > > Best regards, > > Ivaylo > > > > 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 Mon, Dec 30, 2019 at 11:08 AM Peter van der Stok > wrote: > >> > >> I have not seen any progress on: > >> 1) https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ > >> 2) https://datatracker.ietf.org/doc/draft-ietf-core-sid/ > >> > >> At IETF105, it seemed that the documents were unstuck, and would > progress > >> to WGLC soon. Is there something holding this up other than author > time? > >> > >> > >> > >> I also want to express my concern about the VERY slow progress of thes= e > documents. > >> It is quite possible and understandable that the authors are occupied > with too many other tasks. > >> > >> An additional author may be the answer to unstick the progress. > >> > >> Greetings, > >> > >> Peter > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > --000000000000bee551059ba85cd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello=C2=A0Carsten,

I was not aware that this is the blocking point and that is why I had p= ut much less priority to this modification. I should have read more careful= ly the minutes, my bad. I have uploaded a new version now that addresses th= is=C2=A0issue.

Best regards,
Ivaylo
=


On Wed, Jan 8, 20= 20 at 12:00 PM Carsten Bormann <cabo@tzi.org> wrote:
Hi Ivaylo,

The minutes indeed say:

* draft-ietf-core-yang-cbor-11, draft-ietf-core-yang-library-00,
=C2=A0 draft-ietf-core-comi-08, draft-ietf-core-sid-07: Now ready for WGLC,=
=C2=A0 to be sent to CoRE as well as netconf/netmod (with the discussion to=
=C2=A0 happen on CoRE).=C2=A0 (One comment on the numeric range of SIDs sti= ll to
=C2=A0 be taken care of.)

The parenthesis may have been a bit cryptic, but the intention was indeed t= o have I-D versions with all known issues (including the 63-bit one) addres= sed.=C2=A0 Is there a reason this will need more time?

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


> On 2020-01-08, at 11:23, Ivaylo Petrov <ivaylo@ackl.io> wrote:
>
> Hello,
>
> I am working on a new version of the SID draft that would address the = comments related to 63bit SIDs and looking to clarify how are .sid files pa= ssed to IANA. Those are the only comments that I have received and I believ= e they are not blocking the WGLC. What I heard during the last IETF was tha= t this draft is WGLC material, https://youtu.be/YIHoiHhz2Ys?t= =3D1280 and I was expecting the CoRE chairs to go ahead with this. If y= ou believe there is some misunderstanding on my side and there are other is= sues that need to be resolved before the WGLC, please let me know.
>
> Best regards,
> Ivaylo
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s).
> It is strictly forbidden to share any part of this message with any th= ird 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. T= hank you!
>
>
> On Mon, Dec 30, 2019 at 11:08 AM Peter van der Stok <stokcons@bbhmail.nl> wrot= e:
>>
>> I have not seen any progress on:
>>=C2=A0 =C2=A01) https://datatrack= er.ietf.org/doc/draft-ietf-core-yang-cbor/
>>=C2=A0 =C2=A02) https://datatracker.iet= f.org/doc/draft-ietf-core-sid/
>>
>> At IETF105, it seemed that the documents were unstuck, and would p= rogress
>> to WGLC soon.=C2=A0 Is there something holding this up other than = author time?
>>
>>
>>
>> I also want to express my concern about the VERY slow progress of = these documents.
>> It is quite possible and understandable that the authors are occup= ied with too many other tasks.
>>
>> An additional author may be the answer to unstick the progress. >>
>> Greetings,
>>
>> Peter
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core

--000000000000bee551059ba85cd5-- From nobody Wed Jan 8 15:01: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 936F212012A for ; Wed, 8 Jan 2020 15:00:35 -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 a_kIIArNJHzK for ; Wed, 8 Jan 2020 15:00:30 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 30A2E120072 for ; Wed, 8 Jan 2020 15:00:30 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id d16so5225304wre.10 for ; Wed, 08 Jan 2020 15:00:29 -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=bWYlNj6pmXWNv9YK1JhPixxGrwqXfpuaTpWWrzDf3oY=; b=LqRvcK7pH5EUIjXKMVgJG6Cs7Xf7mUepzj3ZSy4hoF4HYIYmbDY1PYJ7LcMUAlyTcT yC1e1yfzp40Sxyvhe/EmuhUBcbPXvV9Fl3eoea40EOAP/Xun8pQS+n9tcjl6X9qrPujX oH7vdrS5vX4rrXe1uRjpJ4bSJCgzw+OGluQoJh6h5hHFDx4BZBhgdIrF18IpvPNgqkfk jNPj9mL/uB0taPcq2/RX3524Ny5QaBHAnCcH9oDQpwtUkc72NZg+sYcl8RNda/tYpI5o dSvQ/T2PS6gAWvor2bCUDLEEzgcwFzutIYQrJt5uQtMz4lRSUT9rQNSMltMEnadfsHZH frhA== 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=bWYlNj6pmXWNv9YK1JhPixxGrwqXfpuaTpWWrzDf3oY=; b=WjKbbDDuKlTmeQUW0VsCYYGU/I/9k20j85X3iiynAgOiTLOnAwCil/aKLcnkdy0PsM RdKSlHYdcMnO4RHmQwAG5SpbQF+RlPerPsJDO/UUuf9Zucs4iCFMgyT0idCXmE0xokwh W3EiqHoCxTO9JwsKvvArGVxkMNdyCSFJrH3rbiw0zTI1sH9XUVgjiNtM/pqi5fugdsi0 PCqRO7SVK1sJu7LY5ceVnX+TB+h+lDYCRsgFg5q1VWPIbcKGIM5HmrforxKA8nswALk8 74Tb+1OK55u6Whl9V2Urycoz5mEuC7jQJJ5SfrfpsdFuX+rBlCLQCMEDnQWeTLUyc3ZT WGiA== X-Gm-Message-State: APjAAAVrNtj9Yh8IvqFbXofWeoa84D9UAFAtbM0UcZ5BSwBcD+j/mStH s4W9IFLkEPfIVjpt5iJ8hNfWZrpQzfiBxVvd3O6OSw== X-Google-Smtp-Source: APXvYqyTLtqArrnga5lgXqbFbiq237E9Jnly3/o1/9r6flqU6jBxnEloukU3BwJRVoCT1v59qRBtEmXwCZPvKzB49xQ= X-Received: by 2002:adf:f850:: with SMTP id d16mr7298932wrq.161.1578524428532; Wed, 08 Jan 2020 15:00:28 -0800 (PST) MIME-Version: 1.0 References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> In-Reply-To: <18990.1577231446@localhost> From: Ivaylo Petrov Date: Thu, 9 Jan 2020 00:00:02 +0100 Message-ID: To: Michael Richardson Cc: core , Michel Veillette , "a@ackl.io" , consultancy Content-Type: multipart/alternative; boundary="000000000000d51181059ba8dbc8" 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, 08 Jan 2020 23:00:36 -0000 --000000000000d51181059ba8dbc8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Michael, See my comment below. Best regards, Ivaylo On Wed, Dec 25, 2019 at 12:50 AM Michael Richardson wrote: > > {trying to clear out my inbox} > > Michel Veillette laments: > > The file "ietf-constrained-voucher@2019-08-01.yang" is constructed > with > > an "import ietf-voucher" and a "uses v:voucher-artifact-grouping". > For > > this reason, part of the "yang-data voucher-constrained-artifact" i= s > > defined in "ietf-voucher" with SIDs assigned within the scope of th= is > > module. > > > This example raises an interesting point. "ietf-voucher" have been > > defined without considering a possible constrained implementation a= nd > > have no SID list or .sid file included in RFC 8366. SIDs has been > > assigned after the fact, as allowed by > > https://tools.ietf.org/html/draft-ietf-core-sid-07#section-3. If we > > include a SID list or .sid file for > > "ietf-constrained-voucher@2019-08-01.yang", part of the SIDs will > be in > > a RFC, the rest won't. To avoid such situation, we should rely > entirely > > on an IANA registry for all .sid files defined by RFCs. > > I am still uncertain how this is going to work. > IP: Let me try to summarize how the sid range obtaining and allowaction process is currently defined and please let me know if it is still not clear enough or if you have any concerns. After that I share some thoughts for module updates. * In order for a draft author to obtain a SID range from IANA prior to publication, the person needs to convince the chairs or AD that this early allocation is needed as described in RFC7120. After that this request can be forwarded to the designated experts that will approve it and it will be reflected on the IANA registry. If the author does not want to go through the trouble of early allocation there are two cases: - the RFC is already published - then as it is specified in sec 6.3.2 , the experts will check that there is an RFC and the registration will be done upon request. - the RFC is being processed by IANA right before publication - then the same procedure is triggered by IANA as if the RFC is already published and another party requests the range. * Once the author has the range, he can generate the .sid file. Once there is a published RFC or IANA is processing a document that is ready for publication, the experts will be contacted and after that the .sid file will be added to "IETF SID Registry=E2=80=9D. I can see how it could be dif= ficult to generate the .sid file if you don't have the range, but for me this can be achieved with appropriate instructions to the RFC editor. I am not sure to correctly understand the citation in your email, so please forgive me if I have completely missing the point, but for me it should either be covered by what I have written so far or it should be related to updating a YANG module. For me it is simpler if a module is updated to have its .sid file updated as well (provided it has one). If this is done, the situation where a module M1 is updated and it is used by another module M2 would not cause issues as it is should match the case where the SIDs are generated for the first time. On the other hand, if someone else generates a .sid file that includes the extra values that come from the new version of module M1, this is not going to cause real issues as there could be two SID values that represent the same YANG item, which means that the .sid file for M1 can still be updated. > > I have not seen any progress on: > 1) https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ > 2) https://datatracker.ietf.org/doc/draft-ietf-core-sid/ > > At IETF105, it seemed that the documents were unstuck, and would progress > to WGLC soon. Is there something holding this up other than author time? > > IP: I believe that this is resolved now. > I think that allocations were made for ietf-anima-constrained-voucher, bu= t > I > guess that was in the github version only. > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > --000000000000d51181059ba8dbc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Michael,
<= br>
See my comment below.

B= est=C2=A0regards,
Ivaylo

On Wed, Dec 25, 2019 at 12:50 A= M Michael Richardson <mcr+iet= f@sandelman.ca> wrote:

{trying to clear out my inbox}

Michel Veillette <Michel.Veillette@trilliant.com> laments:
=C2=A0 =C2=A0 > The file "ietf-constrained-voucher@2019-08-01.yang&= quot; is constructed with
=C2=A0 =C2=A0 > an "import ietf-voucher" and a "uses v:vo= ucher-artifact-grouping". For
=C2=A0 =C2=A0 > this reason, part of the "yang-data voucher-constra= ined-artifact" is
=C2=A0 =C2=A0 > defined in "ietf-voucher" with SIDs assigned w= ithin the scope of this
=C2=A0 =C2=A0 > module.

=C2=A0 =C2=A0 > This example raises an interesting point. "ietf-vou= cher" have been
=C2=A0 =C2=A0 > defined without considering a possible constrained imple= mentation and
=C2=A0 =C2=A0 > have no SID list or .sid file included in RFC 8366. SIDs= has been
=C2=A0 =C2=A0 > assigned after the fact, as allowed by
=C2=A0 =C2=A0 > https://tools.ietf.or= g/html/draft-ietf-core-sid-07#section-3. If we
=C2=A0 =C2=A0 > include a SID list or .sid file for
=C2=A0 =C2=A0 > "ietf-constrained-voucher@2019-08-01.yang", pa= rt of the SIDs will be in
=C2=A0 =C2=A0 > a RFC, the rest won't. To avoid such situation, we s= hould rely entirely
=C2=A0 =C2=A0 > on an IANA registry for all .sid files defined by RFCs.<= br>
I am still uncertain how this is going to work.

IP: Let me try to summarize how the sid range obtaining= and allowaction process is currently defined and please let me know if it = is still not clear enough or if you have any concerns. After that I share s= ome thoughts for module updates.

* In order for a draft author to obtain a SID range from IANA prior t= o publication, the person needs to convince the chairs or AD that this earl= y allocation is needed as described in RFC7120. After that this request can= be forwarded to the designated experts that will approve it and it will be= reflected on the IANA registry.
If the author does no= t want to go through the trouble of early allocation there are two cases:
=C2=A0 - the RFC is already published - then as it is s= pecified in sec 6.3.2 , the experts will check that there is an RFC and the= registration will be done upon request.
=C2=A0 - the = RFC is being processed by IANA right before publication - then the same pro= cedure is triggered by IANA as if the RFC is already published and another = party requests the range.
* Once the author has the ra= nge, he can generate the .sid file. Once there is a published RFC or IANA i= s processing a document that is ready for publication, the experts will be = contacted and after that the .sid file will be added to "IETF SID Regi= stry=E2=80=9D. I can see how it could be difficult to generate the .sid fil= e if you don't have the range, but for me this can be achieved with app= ropriate instructions to the RFC editor.

I am not sure to correctly understand the citation in your ema= il, so please forgive me if I have completely missing the point, but for me= it should either be covered by what I have written so far or it should be = related to updating a YANG module. For me it is simpler if a module is upda= ted to have its .sid file updated as well (provided it has one).

If this is done, the situation where a= module M1 is updated and it is used by another module M2 would not cause i= ssues as it is should match the case where the SIDs are generated for the f= irst time. On the other hand, if someone else generates a .sid file that in= cludes the extra values that come from the new version of module M1, this i= s not going to cause real issues as there could be two SID values that repr= esent the same YANG item, which means that the .sid file for M1 can still b= e updated.

I have not seen any progress on:
=C2=A0 1) https://datatracker.ietf.org/do= c/draft-ietf-core-yang-cbor/
=C2=A0 2) https://datatracker.ietf.org/doc/draf= t-ietf-core-sid/

At IETF105, it seemed that the documents were unstuck, and would progress to WGLC soon.=C2=A0 Is there something holding this up other than author ti= me?

IP: I believe that this is resolved = now.=C2=A0
=C2=A0
I think that allocations were made for ietf-anima-constrained-voucher, but = I
guess that was in the github version only.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



--000000000000d51181059ba8dbc8-- From nobody Thu Jan 9 19:15:15 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 9CC1C1200A3 for ; Thu, 9 Jan 2020 19:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, 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 idrKVFdQzC4i for ; Thu, 9 Jan 2020 19:15:11 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C151202A0 for ; Thu, 9 Jan 2020 19:15:10 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1EEB63897D; Thu, 9 Jan 2020 22:14:19 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 33A6A104F; Thu, 9 Jan 2020 22:14:41 -0500 (EST) From: Michael Richardson To: core , Ivaylo Petrov In-Reply-To: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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: Fri, 10 Jan 2020 03:15:13 -0000 --=-=-= Content-Type: text/plain {AD+Chair action requested below} Ivaylo Petrov wrote: >> This example raises an interesting point. "ietf-voucher" have been >> defined without considering a possible constrained implementation and >> have no SID list or .sid file included in RFC 8366. SIDs has been >> assigned after the fact, as allowed by >> https://tools.ietf.org/html/draft-ietf-core-sid-07#section-3. If we >> include a SID list or .sid file for >> "ietf-constrained-voucher@2019-08-01.yang", part of the SIDs will be in >> a RFC, the rest won't. To avoid such situation, we should rely entirely >> on an IANA registry for all .sid files defined by RFCs. mcr> I am still uncertain how this is going to work. I think that the major issue is that I am still not convinced that IANA is prepared to operate pyang itself. Conversations at IETF105 and IETF106 did not convince me that they (IANA) completely understood what they are being asked to do. For instance, I'm not convinced that there is a support process for IANA to get bugs fixed in the sid.py module. (I would be pleased to be convinced otherwise) ivaylo> IP: Let me try to summarize how the sid range obtaining and ivaylo> allowaction process is currently defined and please let me know ivaylo> if it is still not clear enough or if you have any ivaylo> concerns. After that I share some thoughts for module updates. Yes, I understand the early allocation process. ivaylo> - the RFC is already published - then as it is specified in sec 6.3.2 , ivaylo> the experts will check that there is an RFC and the registration will ivaylo> be done upon request. Early Allocations are done for a limited period of time, IANA is allowed to reclaim the space if the document does not proceed. If when an author asks for early allocation for a YANG module that references other modules which are already published, then there are multiple things that could happen: 1) IANA could do a permanent allocation for the referenced modules, entering the sid file in as well. {this may cause a recursion quite deep initially} 2) IANA could do an early allocation for the referenced modules, marking them as such, and potentially reclaiming. (1) has the problem that it may cause a bunch of pollution. (2) has the problem that the referenced allocation will need to be reference counted for all/any documents that reference it. I suspect that the problem will be short-lived pain, and that doing (1) is the right thing, and that we might want to take the hit in WG and Expert Review in a proactive manner. (I am happy to help here) But, there is also: (3) a document could ask for an early SID allocation, referencing a YANG module which is in another WG, or worse, not yet adopted, and therefore not subject to Early Adoption rules! This may be a problem we do not to fix (Just get the document adopted), but I think that we should be clear about this. My recommendation is that all YANG modules, upon being *ADOPTED* by a WG, have a SID allocation done. Yes, the document will get revised, but the SID system is designed to deal with this. I think that doing this requires an IESG and IANA decision. I think that getting through this before March is important. The CORE WG has had a series of virtual interims (I see none scheduled, I assume that is an oversight), and maybe we could invite IANA and a couple of IESG ADs to confer and get clarity here. > If this is done, the situation where a module M1 is updated and it is > used by another module M2 would not cause issues as it is should match > the case where the SIDs are generated for the first time. On the other > hand, if someone else generates a .sid file that includes the extra > values that come from the new version of module M1, this is not going > to cause real issues as there could be two SID values that represent > the same YANG item, which means that the .sid file for M1 can still be > updated. Agreed! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4X7CAACgkQgItw+93Q 3WWfXwf8Dp4D0oj7vxuogqU2wR3xWsbkAa6dbdNSai2JxXepo1FbHWmjOniv6Ubo wqS/0zZHhNU0mG3YJDCg7XLBPjKMvBBnOC+8+XgYE2O+EiZhmHJKo+jVcCAcJPBV w7Zvhqba9oYLAewg/QIwoqFkpca0IVtGQYdQ9vC/ZeyMXNq0N1l8cObNavWCrCNG 2OIbyclOKAHMus5VMva/eMwM3B+5Qd7miD+jxXkh+WEAg0wUYbcu1hgxHIpgD/9z mnkqGz4O+3y4YdcREdWa6sEVKiskRIvHrLIPh5lvnH1CD+GQGrWPUUc4n7bJ/H1z 4uTl2PETlLSOojxcKmelLPbkinpZKA== =fAXF -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 10 01:48:41 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 29C1F120814 for ; Fri, 10 Jan 2020 01:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 tMiRz101BJoC for ; Fri, 10 Jan 2020 01:48:38 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 E0C681200FD for ; Fri, 10 Jan 2020 01:48:37 -0800 (PST) Received: from mail-qk1-f172.google.com ([209.85.222.172]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1ipquB-0004XD-4M; Fri, 10 Jan 2020 10:48:35 +0100 Received: by mail-qk1-f172.google.com with SMTP id c16so1256155qko.6 for ; Fri, 10 Jan 2020 01:48:35 -0800 (PST) X-Gm-Message-State: APjAAAULRZJ/QZ/jePviunYTMP9HGBD6OtusP8ZRl1XP44x9ixaZcmEy vaPLuSK8v/taaMmFc0EtCXcndg5iKSgvcliO35U= X-Google-Smtp-Source: APXvYqyZtdJNAMctXVotZSuW4Ds8g1IG8vZT2MV9Bmgd4MbCfhbPREGgX0Ba15AV1M6LT/8N/h/Btgjj6BPknj/7eQk= X-Received: by 2002:a37:6d5:: with SMTP id 204mr2045745qkg.448.1578649713880; Fri, 10 Jan 2020 01:48:33 -0800 (PST) MIME-Version: 1.0 References: <324677e1-06d4-a4d6-b79c-9a55c01adcbb@gmx.net> In-Reply-To: <324677e1-06d4-a4d6-b79c-9a55c01adcbb@gmx.net> From: Klaus Hartke Date: Fri, 10 Jan 2020 10:47:57 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Achim Kraus Cc: "core@ietf.org" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1578649717; 52c44423; X-HE-SMSGID: 1ipquB-0004XD-4M Archived-At: Subject: Re: [core] RFC 7252 - Forward Proxies 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, 10 Jan 2020 09:48:40 -0000 Hej Achim! Achim Kraus wrote: > A informal description would be in my opinion, add the uri-host option, > if it's not the IP-literal of the destination Yes. A bit more precisely: The Uri-Host option is omitted in a request if and only if its value equals the destination IP address of the containing UDP datagram. > (that assumes, that the > term "destination" refers to the actual proxy to send the request to). Yes. When sending a CoAP request to a forward proxy, the destination of the UDP datagram is set to the IP address and UDP port number of the forward proxy. > But the text seems not to differentiate between the request's (which > maybe the proxy) and the URI destination (which will be the "final > destination", or something like that). The CoAP options always encode the request URI, i.e., the URI of the target resource. For example, if a client wants to GET a representation of , then the CoAP options always encode , regardless of whether the destination of the UDP datagram is (198.51.100.1, 12345) or the IP address and UDP port number of a forward proxy. > I'm also not sure, what the "or > IPv4address" refers to. This refers to the syntax rules for hosts in RFC 3986: host = IP-literal / IPv4address / reg-name Example IP-literal: "[2001:db8::1]" Example IPv4address: "198.51.100.1" Example reg-name: "example.com" > For me it seems, that stick strict to 6.4 would cause different option > values, if a proxy is used and the "final destination" URI contains also > a (different) literal IP address. For me "strict" will then result in a > wrong request to the proxy. This may need a bit clarification. When a request is intended for a server, the request URI is encoded using the Uri-Host, Uri-Port, Uri-Path, and Uri-Query options. (So, all the request URI components are present, except for the scheme.) When a request is intended for a forward proxy, the request URI is either encoded using the Proxy-Uri option or the Proxy-Scheme, Uri-Host, Uri-Port, Uri-Path, and Uri-Query options. (So, all the request URI components are present, including the scheme.) Even though some of these options have the word "Proxy" in their name, they still contain the components of the request URI, not the IP address or UDP port number of the forward proxy. > "6 ... otherwise": if a Proxy-Scheme is used, should that default port > be use? Or still the URI-Scheme's port? If the Proxy-Scheme is to be > considered, that default port maybe unclear/unknown by the client > implementation. It's the port number of the request URI (or, if the port number in the request URI is omitted, the default port number for the scheme of the request URI). It's not the port number of the forward proxy. Does that answer your questions? Best regards, Klaus From nobody Fri Jan 10 07:37:42 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 C7E25120026 for ; Fri, 10 Jan 2020 07:37:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 fvcnq3XxX14i for ; Fri, 10 Jan 2020 07:37:38 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 D099812006B for ; Fri, 10 Jan 2020 07:37:37 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id 20so2433437wmj.4 for ; Fri, 10 Jan 2020 07:37:37 -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=Ch+kYvgEEHclu+uJUDHA/eBabNViuFqc71qEg5IW8GQ=; b=nNp1Brt9iTVm+5zzqhoCkD9Ek9RlmNHQLSpSfoCrmhA13Vsrkem+H4aAxC717IEh8m omS5wpd9KC3BGdaXdrOFVzdONVvCKcRF1ai6DkJpSL1XplooxJ3g82Bf9pj9ti+RKVCD 8ap1HQWgVegkAbOSiFpt2SYa7vF9b4ANYhcjgHN9MO/bwBrUuxFwga/PWStbfBXIRem8 Pz/fy5WpMNV+M8PwyJ+6GU7SklstSsYKh5tuI8N1/cPQ5j6gAy5e5YSBlh4GD+4gMOKN xVrzEIB55QVkjwGi43//C00MaErb1tvUU11CtMGBMk4EQDTWjkZCz2+DnNRoad3qjIBg h8nw== 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=Ch+kYvgEEHclu+uJUDHA/eBabNViuFqc71qEg5IW8GQ=; b=dU1HhjpCKAykLCYJd1OZ0BruOAh9t9Bg0itIhX8gYZAdCRIuCP5yjwftuP+ygqO9/B lj8E64+nLT+eZFiKUfEbBkw6BUaPP5ln8wJGgWUs795tiaeZNSGiarfu8o3pcDMpUNCW 24I8j9dPm1garV4VvtjcrHTuVEuObm8GN8eo2A1tD/IhMf6rZtPKYl5tUQPM2K+JlP2z McNTo8EB7r92QSAEANQI1iGac3WiuUEpcmwzMCxeTXAW0/WFI0f/shUkTfDHDWTK/aqw o42WVtFXbhbWgHEHdD7jJAv/TOrF5mcl3Jj4HYMYODbanvK5084Rs2Grq9NGOW3U6VsO yLfA== X-Gm-Message-State: APjAAAVWSNSmiYdfa0VbZx/rqCGWz51PyoVvwCkmm4bjf4FF2enC79Ux i9lgGAATVoJqn6F+idMrRymwLLuuyEtsOfSbY2CRsQ== X-Google-Smtp-Source: APXvYqx6HW3uTrxpqE/Hsmk3vuG4uL95XhO3t1nQvTs4kfUCt8QJCQWIg1zr6ILsvyrXcoAwCIPoIMwvuHJRdy51ebM= X-Received: by 2002:a1c:3c8b:: with SMTP id j133mr5126730wma.66.1578670655988; Fri, 10 Jan 2020 07:37:35 -0800 (PST) MIME-Version: 1.0 References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> In-Reply-To: <22612.1578626081@localhost> From: Ivaylo Petrov Date: Fri, 10 Jan 2020 16:37:09 +0100 Message-ID: To: Michael Richardson Cc: core , Michel Veillette , Alexey Melnikov , "a@ackl.io" , consultancy Content-Type: text/plain; charset="UTF-8" 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: Fri, 10 Jan 2020 15:37:41 -0000 Hi Michael, Thank you for the detailed explanation! I understand your concerns now. Please find my comments below. On Fri, Jan 10, 2020 at 4:14 AM Michael Richardson wrote: > > > {AD+Chair action requested below} > > Ivaylo Petrov wrote: > >> This example raises an interesting point. "ietf-voucher" have been > >> defined without considering a possible constrained implementation and > >> have no SID list or .sid file included in RFC 8366. SIDs has been > >> assigned after the fact, as allowed by > >> https://tools.ietf.org/html/draft-ietf-core-sid-07#section-3. If we > >> include a SID list or .sid file for > >> "ietf-constrained-voucher@2019-08-01.yang", part of the SIDs will be in > >> a RFC, the rest won't. To avoid such situation, we should rely entirely > >> on an IANA registry for all .sid files defined by RFCs. > > mcr> I am still uncertain how this is going to work. > > I think that the major issue is that I am still not convinced that IANA is > prepared to operate pyang itself. Conversations at IETF105 and IETF106 did > not convince me that they (IANA) completely understood what they are being > asked to do. > For instance, I'm not convinced that there is a support process for IANA to > get bugs fixed in the sid.py module. > > (I would be pleased to be convinced otherwise) I remember that during the discussion with IANA we considered that the authors and the expert will be responsible for the running of the pyang tool and IANA will only take the .sid file and store it. The .sid files will be provided to IANA when there is a request to register the .sid file - however that is done. Do you see an error in our reasoning other that the fact that we might be burdening the authors too much? Does this seem acceptable to you? > > ivaylo> IP: Let me try to summarize how the sid range obtaining and > ivaylo> allowaction process is currently defined and please let me know > ivaylo> if it is still not clear enough or if you have any > ivaylo> concerns. After that I share some thoughts for module updates. > > Yes, I understand the early allocation process. > > ivaylo> - the RFC is already published - then as it is specified in sec 6.3.2 , > ivaylo> the experts will check that there is an RFC and the registration will > ivaylo> be done upon request. > > Early Allocations are done for a limited period of time, IANA is allowed to > reclaim the space if the document does not proceed. > > If when an author asks for early allocation for a YANG module that references > other modules which are already published, then there are multiple things that could > happen: > > 1) IANA could do a permanent allocation for the referenced modules, entering > the sid file in as well. > {this may cause a recursion quite deep initially} > > 2) IANA could do an early allocation for the referenced modules, marking them > as such, and potentially reclaiming. > > (1) has the problem that it may cause a bunch of pollution. > (2) has the problem that the referenced allocation will need to be reference > counted for all/any documents that reference it. > > I suspect that the problem will be short-lived pain, and that doing (1) is > the right thing, and that we might want to take the hit in WG and Expert > Review in a proactive manner. (I am happy to help here) > > But, there is also: > > (3) a document could ask for an early SID allocation, referencing a YANG > module which is in another WG, or worse, not yet adopted, and therefore > not subject to Early Adoption rules! > This may be a problem we do not to fix (Just get the document adopted), > but I think that we should be clear about this. > > > My recommendation is that all YANG modules, upon being *ADOPTED* by a WG, > have a SID allocation done. Yes, the document will get revised, but the > SID system is designed to deal with this. Yes, that issue does not seem obvious. Currently I don't see a blocking issue with allocating SIDs for all YANG modules once a draft is adopted, so maybe this is truly our best way to avoid problems. > > I think that doing this requires an IESG and IANA decision. > I think that getting through this before March is important. > > The CORE WG has had a series of virtual interims (I see none scheduled, I > assume that is an oversight), and maybe we could invite IANA and a couple of > IESG ADs to confer and get clarity here. > > > If this is done, the situation where a module M1 is updated and it is > > used by another module M2 would not cause issues as it is should match > > the case where the SIDs are generated for the first time. On the other > > hand, if someone else generates a .sid file that includes the extra > > values that come from the new version of module M1, this is not going > > to cause real issues as there could be two SID values that represent > > the same YANG item, which means that the .sid file for M1 can still be > > updated. > > Agreed! > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- Best regards, Ivaylo From nobody Sat Jan 11 02: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 0C4171200FB for ; Sat, 11 Jan 2020 02:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 2Oq-thtKojQ5 for ; Sat, 11 Jan 2020 02:30:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 BDE39120033 for ; Sat, 11 Jan 2020 02:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578738633; bh=pQxkLDd3Wq++g5CCwNt291NaG387dg75lGF77Z+MkH0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Op6vymW7xJUoUfo2XcdNos5eaeR54pZkJ6zPLjuttN6A6i8LzJ9JLtsBfKcYxpdLq 4qy7Dze3cNumYrcDgmr+oGkCbhUNgCz10oarSPVPc4OZuyhb/RL/E8puFBAnYv1jiv uMhfac46sEW2KqTqsyG0+yUShz8ws/oySxr9eyj0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([178.10.248.240]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MfYPi-1jIiAL2Zbc-00g2wx; Sat, 11 Jan 2020 11:30:33 +0100 To: Klaus Hartke Cc: "core@ietf.org" References: <324677e1-06d4-a4d6-b79c-9a55c01adcbb@gmx.net> From: Achim Kraus Message-ID: Date: Sat, 11 Jan 2020 11:30:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:cuu6q397UZcX9/RwQhQ0ErBi9fM665UdkPYwdRzvYoZur9pbOFm sLtgwjrjuQIvEXy2uxdzwiRzq3Bc2EqKkT325rg4U593D/eRn+1HMMaKTQh8spUik0n9pS1 cNgcf7NFHL09K6io4Up4jZ2qdp5RlY5zhj3UYHHb1V0WfqXU0HLceOKB1CrhbDO9/mOYQ5K j/17sCoj7qRX3i0U6aYjg== X-UI-Out-Filterresults: notjunk:1;V03:K0:fypes+CVgyI=:Oo7+YSrXFN1/p2YeNhDnbc 7Sm6RJQmWN5qiyScbOJYQzEwWGmtdKm4/L4I9hFS+dAcOiXbWxypnp2U7K8ZpF/l0tgSh7rqv NOcrtfaOhPb2r9gXnUK6+MNwU5Q/qqwm8LebiUNAKFAtUVYe8xCwZM1rqbK2W1nJ2mEJOdxJj iO1PYuuqm9Uq2deINTF1E/hlzeo2IL+SGm7Al0Y3pLnBmLTFlAIqNUc/ucTXsrPWro34iTqV+ 0N8+l83LkAB4Vfp0IBDM91EFJaf+WP5CKRFla1fooITg7G92ZTRs2w8hCNO5mUS3P9ok8a6SU t0fWxN6k1+b4CqWGMwVPtRNoSmG8kMaepPFs6XbFqDLxBHDYQt2V6O/duJSqXZBhiFioyoUio k10SR6kbnP1pCTrDspfQg9JKp97MVMi9EH2ZlqVkKgsUfq2HCa/6a2fCxVy9cui5ZKujAzcOg HTXg3lYxJop8vajUPjD00FZfPHcfrfguqxSaTNN/zaD4IoWkah8HWL+cy5t/h1nx/AEv7BIf0 J5j2ZuVkuHgFKNjuHbDzIW6ZPL1+1d2UMy8287I/kujFvbDJNfkg85tvpXfURGyVk8uwPa0lp 8EX5IOVOZKgGQAuebj5R2fW/okNVPDJcOMFt1nUPVhf5OSqmbR7Fklb2t4PzDlj5qXlQQAf/f 1uTv20KnD/2UnS5LPxvQDuAHfxpLQl1wEvpDyZO8EJs5hShip8Ig9uO08L0DDWCXgArLpJtEk /bvf66ej4v9+vbeUSpM2L1U/MZ4cX+gViVxdV88AVJIs8C4UwVp6xtJ1/ElK0mfFqh538FIQB Hn942/kwFRN4fUN1Oixd3v9l+8pQMbYT8TSK95YpUyn4b4mcPKorPIRxFiKH4esD2ErjXd4Ka 2f6ncI8VNohPTPFttn4jEQW4kijWbnoOalw/ETY8suL4IDLjKbf+PTv+w6F0DkogYOyryDihT tVBbNaC4oVXG+zEHh1+1WQ2WtDT5v9MAuGXwtqpe/1DShxG9iA/PQo+h3ZiDUq3rUZNJMX3TC qsQ8ZZSX9DvGGB5dkfN7eYDkhkr622FkmtvYYxRZU5mYom2uC28DIxajPVrDKxRehAz6EW6RI pkgQhOuo/xykyycG8BAINn4vmShk6lvuNxQAZm7ThwYf79d/9lZwixV6XN0/mTl28JNqyygWz UJ7salDr+5C9HiQVlkN21nUAkSPeBl355LxUrQKR88UKxKi9ZzZnFk5UK2oRbLrOI7QQsd9Y3 BDcWjHoEauH/1u5E+w+HcNOZuzQWqjztwqxYMF3tDakdHkwf5sG474w4jBH0= Archived-At: Subject: Re: [core] RFC 7252 - Forward Proxies 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, 11 Jan 2020 10:30:41 -0000 Hi Klaus, thanks for your answers and reference explaining the term "IPv4address"! > For example, if a client wants to GET a representation of , then the CoAP options always encode , regardless of whether the destination of the UDP datagram is (198.51.100.1, 12345) or the IP address and UDP port number of a forward proxy. In my understanding the, CoAP URI-Host option will be "example.com" and not "198.51.100.1", otherwise hosts with multiple virtual server will not be able to differentiate the logical request destination. Also in my understanding, the port, IP-literal and IPv4address (the none regname variants), are only included, if they differ from the destination (which will be the porxy's address in case of a proxy). Otherwise the note to point 5 of https://tools.ietf.org/html/rfc7252#section-6.4 "NOTE: In the usual case where the request's destination IP address is derived from the host part, this ensures that a Uri- Host Option is only used for a component of the form regname." will not make sense. >> "6 ... otherwise": if a Proxy-Scheme is used, should that default port >> be use? Or still the URI-Scheme's port? If the Proxy-Scheme is to be >> considered, that default port maybe unclear/unknown by the client >> implementation. > It's the port number of the request URI (or, if the port number in the request URI is omitted, the default port number for the scheme of the request URI). It's not the port number of the forward proxy. My question was rather, if it's the default port of the proxy scheme (maybe http), or the requests coap-uri-scheme. My intention of the question is: "logical URI" =3D> "http://example.com/test" Will be either: Proxy-Scheme : "http" CoAP-URI: "coap://example.com/test" or Proxy-Scheme : "http" CoAP-URI: "coap://example.com:80/test" Best regards Achim Kraus Am 10.01.20 um 10:47 schrieb Klaus Hartke: > Hej Achim! > > Achim Kraus wrote: >> A informal description would be in my opinion, add the uri-host option, >> if it's not the IP-literal of the destination > > Yes. A bit more precisely: The Uri-Host option is omitted in a request > if and only if its value equals the destination IP address of the > containing UDP datagram. > >> (that assumes, that the >> term "destination" refers to the actual proxy to send the request to). > > Yes. When sending a CoAP request to a forward proxy, the destination > of the UDP datagram is set to the IP address and UDP port number of > the forward proxy. > >> But the text seems not to differentiate between the request's (which >> maybe the proxy) and the URI destination (which will be the "final >> destination", or something like that). > > The CoAP options always encode the request URI, i.e., the URI of the > target resource. For example, if a client wants to GET a > representation of , then > the CoAP options always encode > , regardless of whether > the destination of the UDP datagram is (198.51.100.1, 12345) or the IP > address and UDP port number of a forward proxy. > >> I'm also not sure, what the "or >> IPv4address" refers to. > > This refers to the syntax rules for hosts in RFC 3986: > > host =3D IP-literal / IPv4address / reg-name > > Example IP-literal: "[2001:db8::1]" > Example IPv4address: "198.51.100.1" > Example reg-name: "example.com" > >> For me it seems, that stick strict to 6.4 would cause different option >> values, if a proxy is used and the "final destination" URI contains als= o >> a (different) literal IP address. For me "strict" will then result in a >> wrong request to the proxy. > > This may need a bit clarification. When a request is intended for a > server, the request URI is encoded using the Uri-Host, Uri-Port, > Uri-Path, and Uri-Query options. (So, all the request URI components > are present, except for the scheme.) When a request is intended for a > forward proxy, the request URI is either encoded using the Proxy-Uri > option or the Proxy-Scheme, Uri-Host, Uri-Port, Uri-Path, and > Uri-Query options. (So, all the request URI components are present, > including the scheme.) Even though some of these options have the word > "Proxy" in their name, they still contain the components of the > request URI, not the IP address or UDP port number of the forward > proxy. > >> "6 ... otherwise": if a Proxy-Scheme is used, should that default port >> be use? Or still the URI-Scheme's port? If the Proxy-Scheme is to be >> considered, that default port maybe unclear/unknown by the client >> implementation. > > It's the port number of the request URI (or, if the port number in the > request URI is omitted, the default port number for the scheme of the > request URI). It's not the port number of the forward proxy. > > Does that answer your questions? > > Best regards, > Klaus > From nobody Sat Jan 11 05:04:10 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 CCEE3120046 for ; Sat, 11 Jan 2020 05:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 OB3EG1RAR0o8 for ; Sat, 11 Jan 2020 05:04:03 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 36824120013 for ; Sat, 11 Jan 2020 05:04:02 -0800 (PST) Received: from mail-qk1-f170.google.com ([209.85.222.170]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1iqGQp-0003qi-00; Sat, 11 Jan 2020 14:03:59 +0100 Received: by mail-qk1-f170.google.com with SMTP id x1so4493818qkl.12 for ; Sat, 11 Jan 2020 05:03:58 -0800 (PST) X-Gm-Message-State: APjAAAVTD063WDJsXDnqaGaYKUEBBMQjIGJ4p3imgepVDymjWw7dY/Bh mtLsRJGfXS9eMyKJiva5wW8ytATWNba7XQI3xZU= X-Google-Smtp-Source: APXvYqw4cIOBGX7KR/r/j7DgAk8vbyYlkXKA6vYj8YwBG+f8moYps+ZlbC2mplNTjN0OVMRL9Yyx2s8NEGenTdJG7ek= X-Received: by 2002:a05:620a:6db:: with SMTP id 27mr7746604qky.453.1578747837850; Sat, 11 Jan 2020 05:03:57 -0800 (PST) MIME-Version: 1.0 References: <324677e1-06d4-a4d6-b79c-9a55c01adcbb@gmx.net> In-Reply-To: From: Klaus Hartke Date: Sat, 11 Jan 2020 14:03:21 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Achim Kraus Cc: "core@ietf.org" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1578747843; 61040539; X-HE-SMSGID: 1iqGQp-0003qi-00 Archived-At: Subject: Re: [core] RFC 7252 - Forward Proxies 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, 11 Jan 2020 13:04:08 -0000 Achim Kraus wrote: > In my understanding the, CoAP URI-Host option will be "example.com" and > not "198.51.100.1", otherwise hosts with multiple virtual server will > not be able to differentiate the logical request destination. Oh, sorry. I changed the example at some point from "example.com" to "198.51.100.1" and apparently didn't change all instances. Here's the corrected example: If a client wants to GET a representation of , then the CoAP options always encode , regardless of the destination of the UDP datagram. Of course, the same is true for "example.com": If a client wants to GET a representation of , then the CoAP options always encode , regardless of the destination of the UDP datagram. > Also in my understanding, the port, IP-literal and IPv4address (the none > regname variants), are only included, if they differ from the > destination (which will be the porxy's address in case of a proxy). Yes, exactly. In pseudo-code: |url| = the request URI |scheme| = the component of |url| |host| = the component of |url| if the component of |url| is present then |port| = the component of |url| else |port| = the default port number for |scheme| endif if a forward-proxy is configured then include a Proxy-Scheme option with value |scheme| |transfer-protocol| = the protocol of the forward proxy |destination-host| = the IP address of the forward proxy |destination-port| = the port number of the forward proxy else do not include a Proxy-Scheme option |transfer-protocol| = the protocol indicated by |scheme| |destination-host| = |host| resolved to an IP address |destination-port| = |port| endif if |host| equals |destination-host| then do not include a Uri-Host option else include a Uri-Host option with value |host| endif if |port| equals |destination-port| then do not include a Uri-Port option else include a Uri-Port option with value |port| endif (Necessary data conversions omitted for brevity.) > > It's the port number of the request URI (or, if the port number in > the request URI is omitted, the default port number for the scheme of > the request URI). It's not the port number of the forward proxy. > > My question was rather, if it's the default port of the proxy scheme > (maybe http), or the requests coap-uri-scheme. It's the default port number for the scheme of the request URI. Klaus From nobody Sat Jan 11 12:37: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 659F7120019; Sat, 11 Jan 2020 12:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4v0FY7ou2L0; Sat, 11 Jan 2020 12:37:10 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A9312004C; Sat, 11 Jan 2020 12:37:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B662ABE24; Sat, 11 Jan 2020 20:37:06 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCcmOzuHa_FA; Sat, 11 Jan 2020 20:37:04 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3AF4BBE20; Sat, 11 Jan 2020 20:37:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578775023; bh=+pfd4Owh8V6bNthiDDhbA2SmmA+wQ/w6f9cZI2tar5U=; h=Subject:References:To:From:Date:In-Reply-To:From; b=ESDHpImwUcGAb8FjVbYynxLrxvh4p/kRcHAIO58h2T4ybM8DLZJGGL10DkVtp/bR2 t4HqXFzXmbvMYTDR2zz5SWP3Vn8tr0wKSVA+h8Usn1mJNBBpkKWpbbFDQwi6AqEXDj vOHdZQmjcLuS4rTLfqn+vC8/CbsZ27Vajzcx6snM= References: <829e7169-d1b9-c971-94b4-4f661b5a2c8e@cs.tcd.ie> To: "ace@ietf.org" , lpwan@ietf.org, lwig@ietf.org, 6tisch@ietf.org, core WG , "tls@ietf.org" From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== X-Forwarded-Message-Id: <829e7169-d1b9-c971-94b4-4f661b5a2c8e@cs.tcd.ie> Message-ID: <53124783-0d5a-c531-0b1f-cd63a8a1c704@cs.tcd.ie> Date: Sat, 11 Jan 2020 20:37:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <829e7169-d1b9-c971-94b4-4f661b5a2c8e@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rwI2pelNHuJLfJh8CnnbmpJxwj1eSR2qo" Archived-At: Subject: [core] Fwd: lake wg jan 16th virtual interim 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, 11 Jan 2020 20:37:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rwI2pelNHuJLfJh8CnnbmpJxwj1eSR2qo Content-Type: multipart/mixed; boundary="RLM84vciukC4xZMWSkylzr4qp4ZwTdHmS"; protected-headers="v1" From: Stephen Farrell To: "ace@ietf.org" , lpwan@ietf.org, lwig@ietf.org, 6tisch@ietf.org, core WG , "tls@ietf.org" Message-ID: <53124783-0d5a-c531-0b1f-cd63a8a1c704@cs.tcd.ie> Subject: Fwd: lake wg jan 16th virtual interim References: <829e7169-d1b9-c971-94b4-4f661b5a2c8e@cs.tcd.ie> In-Reply-To: <829e7169-d1b9-c971-94b4-4f661b5a2c8e@cs.tcd.ie> --RLM84vciukC4xZMWSkylzr4qp4ZwTdHmS Content-Type: multipart/mixed; boundary="------------3A3AEBD3B471977F177AA9E0" Content-Language: en-US This is a multi-part message in MIME format. --------------3A3AEBD3B471977F177AA9E0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, The LAKE WG [1] has a virtual interim next week to discuss requirements. LAKE aims to define an authenticted key exchange mechanmism suitable for environments needed a more "lightweight" approach. If you're interested, please do join in. If you can't make the call feel free to raise issues in the github repo for the requirements draft or send mail to the lake list (or even to me in extremis:-). Details of the call and repo are in the attached. Cheers, S. PS: Sorry for the spam. This is sent to the lists of the set of WGs mentioned in the LAKE charter is my excuse:-) -------- Forwarded Message -------- Subject: [Lake] lake wg jan 16th virtual interim Date: Sat, 11 Jan 2020 20:31:49 +0000 From: Stephen Farrell To: lake@ietf.org --------------3A3AEBD3B471977F177AA9E0 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" VGhpcyBpcyBhbiBPcGVuUEdQL01JTUUgc2lnbmVkIG1lc3NhZ2UgKFJGQyA0ODgwIGFuZCAz MTU2KQotLTJtcXU3Z2lhN2gyUVdqMGVHaDJVTUpKVnlVb25VUTVGMApDb250ZW50LVR5cGU6 IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9IlI3VnhSTUJnamtaUVZ1UG0xNVFkNG1SZnVK UHU2SmRXTSI7CiBwcm90ZWN0ZWQtaGVhZGVycz0idjEiCkZyb206IFN0ZXBoZW4gRmFycmVs bCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4KVG86ICJsYWtlQGlldGYub3JnIiA8bGFr ZUBpZXRmLm9yZz4KTWVzc2FnZS1JRDogPDgyOWU3MTY5LWQxYjktYzk3MS05NGI0LTRmNjYx YjVhMmM4ZUBjcy50Y2QuaWU+ClN1YmplY3Q6IGxha2Ugd2cgamFuIDE2dGggdmlydHVhbCBp bnRlcmltCgotLVI3VnhSTUJnamtaUVZ1UG0xNVFkNG1SZnVKUHU2SmRXTQpDb250ZW50LVR5 cGU6IG11bHRpcGFydC9taXhlZDsKIGJvdW5kYXJ5PSItLS0tLS0tLS0tLS1FMTYxMjdDRUI4 QjM3MDE3NEI4NUYzNDkiCkNvbnRlbnQtTGFuZ3VhZ2U6IGVuLVVTCgpUaGlzIGlzIGEgbXVs dGktcGFydCBtZXNzYWdlIGluIE1JTUUgZm9ybWF0LgotLS0tLS0tLS0tLS0tLUUxNjEyN0NF QjhCMzcwMTc0Qjg1RjM0OQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXRm LTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQoKCkhpIGFs bCwKCk1hbGk9QzU9QTFhIGFuZCBJIGhhdmUgdXBsb2FkZWQgYSBkcmFmdCBhZ2VuZGEgWzFd IGZvciBvdXIKdmlydHVhbCBtZWV0aW5nIG5leHQgd2Vlaywgd2hpY2ggaXMgVGh1cnNkYXkg MTYwMCBVVEMuClN1Z2dlc3RlZCBjaGFuZ2VzL2FkZGl0aW9ucyBhcmUgdmVyeSB3ZWxjb21l LCBqdXN0IHNlbmQKdG8gdGhlIGxpc3QuCgpJbiBhZGRpdGlvbiwgRz1DMz1CNnJhbiBhaW1z IHRvIHRyYW5zbGF0ZSBzb21lIG9mIHRoZSByZWNlbnQKbGlzdCBkaXNjdXNzaW9uIGludG8g Z2l0aHViIGlzc3VlcyBvbiB0aGUgcmVxdWlyZW1lbnRzCmRyYWZ0IFsyXS4gWW91IGFyZSBh bGwgYWxzbyB2ZXJ5IHdlbGNvbWUgdG8gY3JlYXRlIGlzc3Vlcwp0aGVyZSBzbyB3ZSBjYW4g ZW5zdXJlIHRob3NlIGdldCBkaXNjdXNzZWQgbmV4dCB3ZWVrIG9yCnRoZXJlYWZ0ZXIuCgpD aGVlcnMsClMuCgpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvYWdlbmRh LWludGVyaW0tMjAyMC1sYWtlLTAxLWxha2UtMDEvPQoKWzJdIGh0dHBzOi8vZ2l0aHViLmNv bS9sYWtlLXdnL3JlcXMKCgotLS0tLS0tLS0tLS0tLUUxNjEyN0NFQjhCMzcwMTc0Qjg1RjM0 OQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3BncC1rZXlzOwogbmFtZT0iMHg1QUIyRkFG MTdCMTcyQkVBLmFzYyIKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50 YWJsZQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OwogZmlsZW5hbWU9IjB4NUFC MkZBRjE3QjE3MkJFQS5hc2MiCgotLS0tLUJFR0lOIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0t LS0KCm1RSU5CRm85VURJQkVBRFVINFpQY1VuWDVXV1JXTzRrRWtIZWE1WTVlRXZaalN3ZS9Z QStHMG5yVHVPVTluZW0KQ1A1UE12bWg1Q2c4Z0JUeVd5TjRaMitPMjVwOVRqYTV6VWIrdlBN V1l2T3Rva1JycDQ2eWhGWk9taVM1YjZrVApxMElxWXpzRXY1SEk1OFMrUXRhRnE5NzhDUmE0 eEg5R2k5dTR5elVtVDAzUU5JR0RYRTM3aG9uY0FNNE1PRXRFCmd2dzRmVmhWV0p1eXkzdy8v MEYydHpLckVNam1MNVZHdUQvUTkrRy83YWJ1WGlZTk5kOVpGanY0NjI1QVVXd3kKK3BBaDRF S3pTMUZFN0JPWnA5ZGFNdTlNVVFtRHF0WlViVXYwUStEblFBQi80dE5uY2VqSlB6MHAyejNN V0NwNQppU3dIaVF2eXRZZ2F0TXAzNGE1MGw2Q1dxYTEzbjZ2WThWY1BsSXFPVnorN0wrV2lW ZnhMYmVWcUJ3Vis0dUw5CnRvOXpMRjlJeVV2bDk0bEN4cHNjUjJrZ1JncE02QTVMeWxSRGtS NkUwb3VkRm5KZ2IwOTdaYU55dVkxRVRnaFYKQjVVaXIxR0NZQ2hzOE5VTnVtVEhYaU9rdXpr K0dzNERBSHgvYTc4WXhCb2xLSGkrZXNMSDhyMms0THlNMmxwNQpGbUJLakc3Y0djcEJHbVdh dkFDWUVhN3J3QWFkZzR1Qng5U0hNVjVpMzN2RFhRVVpjbVcwdnNsUTJJczAyTk1LCjd1QjdF N0hsVkUxSU0xek5rVlRZWUdrS3JlVThEVlF1OHFOT3RQVkUvQ2RhQ0ovcGJYb1llSHoyQjFO dmJsOXQKbHlXeG41WGlIekZQSmxlWGMwa3NiOVNrSm9rQWZ3VFNaelR4ZVFQRVI4bGE1bHNF RVBiVS9jRFRjd0FSQVFBQgp0Q0ZUZEdWd2FHVnVJRVpoY25KbGJHd2dQSE4wWlhCb1pXNUFh bVZzYkM1cFpUNkpBajBFRXdFSUFDY0ZBbG85ClVZd0NHd01GQ1FtVUpnQUZDd2tJQndJR0ZR Z0pDZ3NDQkJZQ0F3RUNIZ0VDRjRBQUNna1FXckw2OFhzWEsrcUcKQ3hBQXBZSFdZZ0dPSUwz RzYvT3BrZWpkQWtRb0NWUUFLOExKVVNmNnZ6d29zdDRpVmZ4SUtjS1cvM1JxS05LawpyUmw4 YmVKN2oxQ1dYQXo5K1ZYQU9zRTkrek54WElEZ0dBN0hsdkpuaGZmbCtxd2liVmdpSGdVY0pG aENTYkJyCnNqQysxdVVMYVRVOHpZRXlFVC8vR09HUExGK1grZGVna0Uvc2VzaDR6Y0VBakY3 ZkdQbmxuY2RDQ0gzdHZQWloKc2RUY2p3T0NSVm9uS3NEZ1F6QlRDTXovUlBCZkVGWDQ0SFp4 NGcxVVFBY0NBNHhsdWNZOFFrSkV5Q3JTTkdwRwpudkdLOERjR1NtbnN0bDEvYTlmbmxocGRG eGllWDNvWTJwaEoxV0trWVRuNkFkdnJlazNVUDcxQ0t4cGd0UG1rCmQzaVVVei9WWmEwQ3Y2 WXhRWHNrc3BSRFZFdmRDTVlTUUJ0SlBRNHkyKzVVeFZSOUdJUVhlbndZcDlBUDJuaXYKVm9o K0lUc0RXV2VXbm52WU1xMDdyU0RqcTBuR2RqNDFNSmtOWCtZYjJQWFZ5WEl0Y2o1eWJFM1Qy K3kzcFNCRwpGRVpZSkd1YUw0Tnd0QkpGTU9kT3RCbVVPUGJldFMyOTcxRUwzSXp4YjdpYk9a V0R3ZXh2KzhSNlNXWWZQMXdWCk4zcDQ2UnlCUXVYcUpWOGNjRTExbTZ2dFpUR1NZZ25MVVVG Wk1SUVlIKzBod3VZZTBUM0FBMTh4RGRTWXNhOHYKb3ZDQ2QzbDVTNFVOeklNMlBNQ2hxR3JF ekthcFVwWmc3KzhBQ2N4UlUzYjlJaGQ3V1lqSitwUVBDb1dZS296dgp0RXZlbmJOcEUvZ292 Ty9FRDNCMTRlK1IyeWV2UlBqUnJzTjdQSnpTZjE1ZlFMdUpBUndFRUFFSUFBWUZBbG85ClVx QUFDZ2tRTHp5SE5vQmZqYUxyU3dmK01JSGJGUlE0TzVjbUxZUjVzSUJ5V2VsTjNTdVJOL2dX OHJwS285T2sKQ3o2QW44dVYvaUNYeTV0Tk1MenppMEJGbDhmMjJEd0JjQzVxeTlxbmxJQWRv Z1dhbTFxV29UQW9BRDh2ZUVxbQp1S2hZcnFKc0NjQXlOcktZbUswaFAzcnBIeHgxTHlTRG1L WVhtdy84cXRCWEtIVG91TW0rNXRTc3puaHlrUk1UCkFBcjJwN1BTYUhnbytoSVZhVy9yS1Nz cEhqRGhoWlMrRzltdE9aYWQxSUgyOU02RzFRMU5DTzBZd2U4a3JLTFEKSUFRbEZ4dGd2T3Fw UE9aTnplS0JhLytLYkU4VEdnTVdya09oQzhPZUVNNVBWemREaGxoRDlrUHpCL3BDS0RGNQpE b2ZKL1pScW5EcGJLUFEwYnNXMzhBT2lnM2tPYzBBMjdhd2lCRXczdXJxUjFZa0NNd1FRQVFn QUhSWWhCSDRYCkNnUmNoTTlHRGl0NW9CRHZlZG45ZzFNU0JRSmJ0eVNjQUFvSkVCRHZlZG45 ZzFNU0kvb1AvMEE5Sjlucm5CTXEKWnBtODU3bGZZV3crcnNoTEsrdHllUDRPUWVPcW5ERnZz OWplUHBjeUpMRzNERjJyNlZiVktQUXErQUU2VWY1aApjSkJERU42QmpFaFJQU2JMY3FHM0Ex Y3ovbk53bThyUG1OcCtvS2htYUJCUUd4d2NpTUxtemd5bnNEeWRualBwCk15RXMwNHp2c2Jz bDR2cnAyMDk1bzEwNWw4S2NycnhRcmlvRmpid3ZlR3dIUUs5YnhKS2h4OUQrZ0lrK01vdUIK dXI0NVVES1Raa01acnI5RkdydGt5WENHQXh2S2RjTkM1T2E4ejlzajFyY1VKZkcvT3BWQU1X aEFyZGxaYkZVUQp5b1g2cFUyWmIxQ1IycXBXQVZlckdTZkJobWZDeVN0akFScWFLeGxmdGpP K0JqM0pqNzNDcjVlcWVqM3FCNStWCjRCQ3NQanI0Ukx2VmJZVUNQc1JkeFdjK25CTGxmVllr UlVSdTIxZzFoRm01S0ZQamdVa3lvMXM0dmpVT1k4RHkKSSt4TEdGN2YvSWhVQkc2bCtWc3do cHd1N3lkYWxaa2VGaVB4NXhuYTVOZmJFWXh2c0lmNzFEdmlwR3ZJT2FIdgpYNGVnV29GZ204 bi85YzNyY014SnRwd0hQU3NVdDVkZ0xzeXU2VkUwSWJ2T0FjM2RON0NXSjM1NURWRkpxOVpn CjJZVmYwaXpTcHl5ekplR3Nna2ZqVzZ4cG1kdlp4dVQyVWNONEJUY202dllxdWVBU0dyYjNs Zmh6QzVncGVWc2MKL01vU2pUUzY1dk5XYnB6T05aV01adUxFRnJheFdKekMwSnJESzNOQ2Qw Vk4za3N0cUdrVmJVSWlZT25VbThWdQo0em9WTUxsR1d6SExJR29QUkcyblJlem4xWXlOZnli NWlRR2NCQkFCQ2dBR0JRSmJ4Y2ZsQUFvSkVHbzdFVGs4CnBLMWdFN1FML0FwQzVQNjhXNURy STE3ODdXSlZadjF1NHQvZzM5dlRyN1hlcjNVTVRWUWcxMHZwYTdwbXFPR2gKaklEekRNZzNQ ZTNLM003ZlZ6ZkFsVUExcXc2bmU0UkN1ZVZvUktwdWJlRjRBbFliTXIwSzZoTkNQanQ1dUF4 bQpiQlZ1ZWpLVGM2cHJ1NXJ2NWdLTDBuRGJyK1NuZnQ1eHQ3anVCTFNTaW13MC80MXNabmtq Q3hvOXJGL1JBL3Y2Cit1V3lLMTcxUkttc0VZdThmRnR3MWVxVU50L1hqNzkyVFVpeEUzcHhY aGVOdFF0WkdrLzlQM1c4M0NoaEc0RmgKNUVRc24wcEloOXdaSUFiTVJMcGdSS3lXODdmV0ha QzgvWUg4aDdhZmFydm45VGhsNXBGVWxkQ2UyMm1OSmo2SwpMQ2huMmFFSFFkK1BkWTFHQnBa RWNtTkVVUHVvdnd6YXRNMGg2NGhDelRtNDFlRHFSZmloWlZCVDdUYmZYUW52CjhyeXdhNDJN azc1NlJHenpFWmNRRWh3UVhaY01RVWZ4SVFRMlZ5Sm8wekczNlZkWlRRRjdURi80THo3LzNj SjUKNmpPSW0rZHdQWHR1K0Myd0FRdUQ0VVNPTHQ0SldQWXBxekRmSFlKSU5ELzQ5N1A5WjlT dVFlYWhyMmV6M0RSQgpnM3FzSEVqQlY3UXlVM1JsY0dobGJpQkdZWEp5Wld4c0lDZ3lNREUz S1NBOGMzUmxjR2hsYmk1bVlYSnlaV3hzClFHTnpMblJqWkM1cFpUNkpBa0FFRXdFSUFDb0NH d01GQ1FtVUpnQUZDd2tJQndJR0ZRZ0pDZ3NDQkJZQ0F3RUMKSGdFQ0Y0QUZBbG8rbzNjQ0dR RUFDZ2tRV3JMNjhYc1hLK3FPMEEvL1pzZlF6eVhyWmx1L2VFVjVqVTYyMHllTwpNM1A3U1cz QzNVUVlkQ2daL1RsdnhHZ0tvdzVvRFNYZ2pNaVV5cTljc0dxYlBCeGxEWVN4RlpITmVEVktZ SXVQCjJaSzI0dHc1azZkdVRoNCtzRndVdWFsVE1sY3AwekJDSXpuM2hSY3NSdnVQS0hmbDUr Nm9PaTAreHF4M2pYL3MKLzY5TC9mdkhtZFNLZXQ1TElVQXhvWWFaa1RDcnVGclBXYjAxdGdB bDVKRXhXa2htQ1k5OGlEK0VlaUlNQVdCagpNdzF4VitwMHVDd05iTjZYRHpjVG9LN3dzbSt0 QUlpV1V5M0RwUDYwYTZXYlZ3ZFYwSE50MldacTVVNUpkaDJrCjRTK3NOMkNuWWs0dFRXN2pI anNXYXJWM0ZMSVNDT09iQURadUI3bGpVNGtZZmR3WitXemVuWFk0TEdseEdRU2wKQWJsR2p3 WmU0RUlrQ1hBSlV0ekpob0ZVdUdhRi9QbFdqeHFWM1VGUmNnVEVSWlRpamd1VnlSRXJlOEdO RVJOZwp2RHhadnVYc3NFanZ6OVg1SmZjSVpESUpwZHpoTGlFSWo5bm9VYmZ4MVN6QjVLRFBR ajBPN2VsTUhhMTY3MS9yCndXY3BHci9NZlZQVE9pazRIN0Y4cmNWSmVsY2VaVHpDNHR2eWE3 TStqTTRmeUZXV3Q4WTRhdFRpeFVpUDdVOW8KNHVCWkNRMEd6dnNtRkE0WExxbjJwQTVyVml6 TVhuR2JHT2p1ZkFQL2VmRUo0dWwzcXZqWWU4eWU4RFhFRGpLQQp4by90dUhZdGsxOVhDaTgz UXpGaFdsczVUVCtYUWVWVE1FdlZxbzlXZWs4eW94bzY3cXZMS0txSWNHOWdpdlFkCjhNeFlO QWJOWWdTUHRrYmhaOFNKQVJ3RUVBRUlBQVlGQWxvOVVxQUFDZ2tRTHp5SE5vQmZqYUx6SEFn QWxXVDYKTlhFR3R3L3IxbWlLTkdjb3B6dnpJTFE5b0I4cktJOVU5RUw2dE9mL3kyVjVvWWVl L0d5UURiM1pkb1B4eFlZYwpKZitSeWlIMW5Nb3FVSVppWkphZjNiSlhpbkRaNStBZGZFKytV UjJOQnZxYU55QzZ1M3IyNGpvMUIvc2FnS2JZCnRXZ3NZdFJxSExENElXaTM3TVpyVnlqQnVG N3UxNFEwNyt1aGpxNm1YMk8vdEhwQ1l3L1E4MnRiZVRSUHlVZjEKV1FPQWZEMWtmQnBXOVB2 QXZhNUl3OUZXZVhwQ1hSend4bkNaaFlmR2ZxdHVTdzZDUEJZTGRiaWtxTUw2Rlo3RQpEdVRC Yi84dW0xd0s3WTliZ2VJUUMrQ1lqaFlCNVJYYTF0REpSYWIySnM0bHVDdlNSMHcvQ2dIdzI2 MjkzdGx2CmUyUTZVVHJtSHhQNVUyMkRsb2tDUFFRVEFRZ0FKd1VDV2oxUU1nSWJBd1VKQ1pR bUFBVUxDUWdIQWdZVkNBa0sKQ3dJRUZnSURBUUllQVFJWGdBQUtDUkJhc3ZyeGV4Y3I2dEpw RC80cnJJTEgrbWVQMDd2cng4d1c1ZVl1cUNpUApHWW5oL0NYeElGOGVMcmZiZTVkNFFSZ3Rx K3c2VWVRUE15ektSSVJpQ29CWEIyb0pMQlpIeXhCUHhabGczM2RUCk1yRUduOFFXS3gyaU51 ejlyWk1YeU9TV0ZldHVPMDFkL2FVUGQ1Qm5iTGJJeUs1b2Y4eENRbFhNNktIOGJjKzkKZ1E3 ZWRSOW1mTFRkdkJmMkZSNTIyaGc4QlJCTTFpbUtjM3ZPOHYzOStxSUhIUmp1aXd4QkJDQU9o SHRIUnNaWApyaXBTMHVGQTA3ZE00Nk9pL0U4b3NqeDZmUXQvbEg1ei9QTisyYWR4WVNyTFNB WGZyMW9EM1J4WU5odVdneUdGCkw2NC9WQ1FiMVlHamYwWjVNQlBuV205amdVb09ZNUs5ZU5T UzBMODNXZUpqbEY1K1EvV09nQityYjQ5UHJtMkQKRmVvOStTOWYyVjUzTGx6MVdJc3BYSmc2 ZituOWxtSEU5NE1mUWoxR0FIQ3pJMEZlTDE5bHZNK0xoRDhqSlNDYgpockMzK3lvYnl5L0FV T3M1WjNFK25qalgxRkYvVkNWQXM2aU9hNmkrWEcrWTFoaDNpcjJ5MWtja0o1YXVUMTBNClNV OEdFWnU5YXlVNE0zbzNOOXl4T2phb1AwTnVRNE1NTEwvbi91NHU5NEFlWmFIUE5CWG4vaFZm VlJSbXBSWHQKR0t2SnRGQUVwcEdFWWV6QitiTEtJbTZYbHBQa2hud1l6bGVMWjdBTUVjbzJD NlFNOFFQQjNnM0pwUzNzcVJoQQo1ckVQNGxMMTZCbWlqbUYrQ0hvUEUvendnS1piS3B5VkRx dklXNUlEZ3ZmSUMyWDRwYlpEUnZHSVVLYUdTQjQrCmtzWmdVVW5OeXZmUXIycDdqb2tDTXdR UUFRZ0FIUlloQkg0WENnUmNoTTlHRGl0NW9CRHZlZG45ZzFNU0JRSmIKdHlTYkFBb0pFQkR2 ZWRuOWcxTVNlS2tRQUptNDRqdDFrd0hnUWdlREJLZGpkdmwwQWpFMHhWRVF4cmlaNmxQLwps Ly8zNFlUMGF1RmZ6c1lJckNoU3BRWEFFdG9iQkFyNE9odzFVcytCWmUrSDVQOHZtNkxSdVB3 b3pDM1Nqd2ZYCjRJZWM4KzlvdDZ0SVZnNHNiZWREU2diL0NDRlZqc21JR2NRMVA3M0pMSlRC SjZteFlDVi9nbjNRQzZid0RPRm8KN2tEOUZESENqUk44WGZoSFE0UTljWXl0MDZ1RjMxcUcv YXVtZ1dZQzlnZUNHZ0F3aUhnd3hOWWI5R29KMGlaagpDUk93Yll2TFRjUWdzVlVXMmJUbXNW UjEzVVZLRHNkbDAyc1JWN3FjVllXNlIwYTNSYThLdWRYK250MjVINURSCkdkMzgyS1o1Vzhw eWRzeS92aVR2RDl6NnYwdWxDaEJZeEFlZEl2R0lDbHJoYnhsTEVQbUlnNEltVk9MR3FzVWcK Vm0zMko5NVdPakVrazRQRVoxMnhTREJ0d2hTSnFtSk5ib1dsZm13NDNLZEliWTh6TmhmZklP M042TzdGc2RHeAptcXlIZUxvVHBxWSt5U1ZVUHBidXlXOHVqbkkvSi8vKzZoZFRaOWRRc0VK UWxXbmdLdVdPUTVtYTU4TVBTTjg4CnpsbHNxaFpBRlFqTnhxbmtTekw2WlErdi9qdnVSUmUx NkI4MEFlTzU1RHNtYldzTXYvWUxMRDFtU2k3K0toeTIKRXRNQmhnb2pXd3JHTXZkTE42WDNt bnpOSkVzY1l5THhNOXRTaytpeVNQMnNMdGhLMEJWZ3BBekJTZGFmL2V6SQp6NjBQK25lSER6 dGVORmY4TW43bG1nWWsxYW12Wm9KMjlzNStuMkh3eHlSTDVkVk15TWR5UW1udHViYmN0ZnFy ClowdElpUUdjQkJBQkNnQUdCUUpieGNmbEFBb0pFR283RVRrOHBLMWduQ1lNQUpZNEZlSVlq bElYR2doRld6c0IKNGZZd0sxK2lhRnBVM2ZTdG81cWNycVZ0VlBqWHB3cWN6cUJXZVhHeVF4 aUIwa2FuNE9WQVh5ZEllYVA4RUF1RgpDQTdwYVAzczlTVExKQk8zS3Vya3d5UmtQVzV6bzBY N3hWcWFWVG9Sc1gyVWw5OEtWSm9IWVFEMUtkZXpFdHdsCnZwTndpaUJyNDJBWVI3NTFWbTZK QlZBYlFYdUZwQjNjOGJVVjBPa2tSeE5GdEw4LzJQaWVIYXI1OG41ZG50R2sKYlBsUGt6dGFo c0Zxa3RnYWNJZ1hIWDV2YVQrN1llZVoxRFdMT1lqR08wd05oa09TZXJvQ214d0pVaWtVN2pv QgpwODIzTDdyNUtmcHFXVFBwU0N6VnN0UUtaVUdtbW9FMXFDc3dZL1VkNXd2cDlTY2NwSUlM a1JYajByWlJ0Zm5FCjVNcEwzaGptdE56ZkRkOXFJc0p0QkpsU0IyaFp3QXNWbTFsK0VXTjlo RzN0cXlBNDNuaVVNeTJuNnE2OTBvZjMKYmVyU2lRK2t2WS9hQzlIeDhJK2JLek9WOS9KMlZV VHFmYVBaYTRVeTJyVlg1UTJwNjluL1BNajdtRWVyMHJDTAozajlWMTZKOWMrczBCU2tYb0tk dFlkQjBUV1ZoQmdVeWJkOXF0WWN3SFd2aFA3UXVVM1JsY0dobGJpQkdZWEp5ClpXeHNJRHh6 ZEdWd2FHVnVRSFJ2YkdWeVlXNTBibVYwZDI5eWEzTXVZMjl0UG9rQ1BRUVRBUWdBSndVQ1dq MVIKV2dJYkF3VUpDWlFtQUFVTENRZ0hBZ1lWQ0FrS0N3SUVGZ0lEQVFJZUFRSVhnQUFLQ1JC YXN2cnhleGNyNmpzYwpFQURFY0IwV1FFWm4yQWtyekRzMVJoTDBMcDZjWmkwQmlnb2ZrYmNH ZmRoSnlNU3MxOUMwZGh2bmNyQUZDbFZJCjYvVWR3M3lGdER5WXRPQ2YyVzNNM0ExSzYvUmZF aXpDTHpUc2RGSWhuaTlnT0pMbFVwWFZpUXRncmxzdGprN2gKcVZWM09vejRCbENxUzRjRzdy ZnFmNExRUVBwVEF1RlVFVjlJMjhGQlVCMmlycUMrdjRnVHlzSWdwTXcwYkExeQpCVTlzWDVq RS90Umt6cW51elpya3dpb2JEdFJGSjlxcCs3TzJKdGNZNEVzVnRMQXNhb2RKS2M1Y0Y4UjRP dkIxCm42NnZ4eGNnZzlFaDRKTldaNDd4c2FDbUFHbzFCY2IyaklZMzVPdGdBTDdnQ0dMUlNN S1R0QWFQeTEvZkVnSXEKaENsako5eDQwRmtuLzNyMkJYMjFXQzlIRlNQRlRCejJSbHVMUnp4 ZGd4T3JrWUs4RWlIVVBvRTViMUFFelpLdwoyQWJlWGZyNTdmNXpZc04zSXFmYlFMVWpNWXRV TjF3SzNQamIraWREOTcyd3lYTVd0OHVPemxJN2I5T2N1K25ZCm0yd2hCZkp2OVBtcDNRWVRt UHorTEI5bEg2NVZOVlVTeFNYVnI1aVdYTzNxeDFIdEVpR0Vxa3Bvck1RQ1RoM1QKNVVkM1B2 TVNSQkZGS05zOVdoSi9MeHorU1YzMFdMd0c2ZHI1bVFxbHpBaGI0UGhjL3pla1p5WFJkUy9v REtyQgpMVXVjUzM2Ty8vNDlKZXlSaTFRdk9meG5mbUlxUklBZi9rM1BvWUptVG81RTgyLy9y NVFqM1lHbFJ1NzhiYTBICkFyeHMrQUNENkFuRUhIY2Jzd3BidFZFS1l6bFN1MEFyMERjN3ZS V00vSXlRZElrQkhBUVFBUWdBQmdVQ1dqMVMKb0FBS0NSQXZQSWMyZ0YrTm9zSXNCLzlmLzI5 Rk5sYTNCSmZHSUVJRG5ocnFHRDBpOWJTYTg5U3FCZCsrdUcwNgpUUWdXNXdzcXROY3J3bjgx eVpUcTZYRTZpOVZ0RDRHS2ZxQzBkNEtaSnI5Ym5iZUQ4MWNJNjRWT2RMOHpKV0pzCjB2ajVF SVhDb2JLeVg3NEtiNHVlUFV5WnF3VDJRNzRJMTE2dS9Id0E5L0ZYc1BvNWlzYmg0WnFENHQw VkhwV2sKbWZxMUZQVDlhL0pQeVg0NnFLcUIyRmNlLzdReStTUVAxTmZrdVVsYmhVSC9KRzlh U1NZdmszbHpuTmlINDF4OQpNK0ZEbEwxMDZpdFhPdWJybDNvaTJmVDNmc1NlZHE3dXp0K0lW MERRRWVOYW9RQVV1d0VoZEI4SVdPTXFOMndvCkRqR1ZLSmZ0ZnNTV1k5aWxacm5EQk5EcnAw dlJxY3gzM0xVTWtJdzRkN2lCaVFJekJCQUJDQUFkRmlFRWZoY0sKQkZ5RXowWU9LM21nRU85 NTJmMkRVeElGQWx1M0pKd0FDZ2tRRU85NTJmMkRVeEpqdXcvNkFwSFNzVlRXRDRhMApINkZK MjNBOUZ0cHkrYVhaNHZZbHprU3Jmc24yRUNyRWZLM2xYUWgvdXp3akpVRFlaZUIxL0JRc0Za dGNZTlFPCkpTU0hiUTQ5QkZSTHdiMUovd0JaRzRiYm1ya0x4bk5iS0RLUXZ6eEVwY2xrTVcw RGowSjZvN2tHcm16SUdHcmgKQitKSk45OUFjaW5lSFJ1ZzhaU0ZJRVJSQ21pZ3hkaEFLVTBC RkQ3UCs1SE5IbHRTTDNERjFjMmZGT2YySnJnQgpLVm9FKzlSaE1aaldOYllldEZGTENralhi NVJwYXk5emVNbTFEeGZTVEdBbnVPd1VYVzZxcTRobmw1K1ZDLzQ4CmNlRFpFbExMZnU3UlFV WnY0NHBrU1RPV1pzK2lRb0ppSE1GSGs5d1BxeUIyVm9rMXlKMmEyajI3V2hYckpsUHcKblpi Z0pPNVJ5V0RHM3AvZVZtcGw1VXVjMmRzZklwUjE3S25BdVdwZ2hLNlYrY3lGbmNEb0dDbC9Z RzJNdm9vbApzVzA4RmlaaDNFajRkbkpqajI1VFprZUZHNzRKSkRYTHZNWXBKZlNCR25tRVR2 NERoY20yeFBxVk11RnVMMXFKCmxNYlZMck1vMkdYZW8wM096Tnl2YnMrdThXTElhR201aEM3 TjFDWFk4d1pzNGpvNk9KL2V4cHZuYzA3ZEV1d3MKNHpUM0FpV3YzbklvdVdSZVJTdFp5OVFr YXZEb2NxYnlQbWlsY2RQQ1lrNEJzT2x6cHd3Tzc0aE5HN2l5bDBLZApBbHdUeEdRN3kwckpv dTZIWWExVG1SaElFcjN2S3ZsVytKZlVVcnF0alhnc3VhY1RYbzQrSXJhMkpVRXJMMmNZCnpR TXExajRyMVp5aEZudXo5M3M3UnN4L053MCswWXVKQVp3RUVBRUtBQVlGQWx2RngrVUFDZ2tR YWpzUk9UeWsKcldDSnF3ditOTFZQRTRzRDRzREEyLzZFazdVc1JJVWtnK1MzOWZocVdzTGM0 cnR3L21EdW52OFVuNjFJM0swNApmWjJSeTRuRjloWk0wYTcxMFV2WEZiU3R2cnpSSk8zRUFB Y2RKUjlMVENkMTllOFVlcnVRYkllZTNZVDkxVTROCmtDOUpNcGVjZnE2Mi90ZU9BVTJlNVAz ZldZYUxzNVpYN3pDTHdXdUJjVzJsM1N5b2xqUWN6TTg1SGhKM1hIbSsKRm53UTZEOXhSbGUr bHZXVGN1QzlkMXlBeVViOElPb3NwY0wybEpUbXk4ZTNyNzlSMjRoUGxTQjRMRGUwd0VOOApB WGJhZ3JjQVFaand5YUh5V3hqSmJUd1owYjQzV0dkZklxWjFFbE9lb2ZmYmtldFBHUm1Xdng1 eFV2YjJBTEZCCkJkRVR6VjI3MGdzNVhESmdKMVNJSUtPeURBRHh3dnJvVGUyakQ4Qy84NDFl RXFsNVFTb3czcy9VM3pScWszbXQKdHRvOFF3L0RONzFhZWg2ZG1ZU3N2ZDJVanNIdy92b2ZP UFJCR3haTEVrS1RFdk1uaG1NVzloaUtQa1BpYStRZwpldllFMDIwcXBLU3hMRWRXQThucHJI d3htR2lETmVzQ2ZYU0M2dm0xcWZ5ajVnOEh6eFNja3E5WmFNaEtNQ283CnZ4ZmxVRUR1dVFJ TkJGbzlVRElCRUFENkRkSFFmTWF2OE9YZmhqVHRlb2FyT3JsSlRTZGNpNzI3eGllekdQdUIK SG1wdmNlQlJaZ1Jhc2RiYU1jNEhKZWUrUjkrNXgvbkxQQ3V5L0R4RHlJandJVWVKTmdjK2w3 TGpJOVdmcEhURAo4VTR4eGp2UjVNaTcrVG9RUVVPVU51elQwTzBweXV4UDF1WTNSZWhIRWhP VmZCWk81OWlwU2VaTDVpUUM2VDVNCnNLMVNLZnM1MXBMYTVUb0MxcmM4dEJKNHpabXhSQXla aVljL0FIMnVaLzZyWWpUVGtBbjFEVkk5RFlvMkQvekUKNGJHalhkSlc1cEtwaEZCMmxYM2RH NEk3T0RpKzVlMUg2QS9RcEN1Nno4L1prSVErOVQxeGNYL1l3aUZlQTdQYgpUdVcvZUlUYk1i STFlVjMrZnl5bTlhVDdSc2ZsbXAzMVp4dHIrc1p3R0daZjAwb29NQkZtcU9TLy9OVVEvVmYz CnZEVWV3MWg1UVUxeURhV1QzTkFwdmkrWFdQSDlUUHk2VE1mWkEyRlRoSGYxMXNYL2dEQmE1 SldRWmJwdFBFY20Kb2F6cGlLWnQ5MUNyRlBPYW9YRFBjay9RNjFkZm1yL29QaWtmQnlZbkFT SU0zT3dFdVhxeVE5SkRSZktyZW01cgorb0Evd3hXYjVqRUxFbEFoT3BueXFNTXZPaDd1ejFm b1Vzc0w4TUF2MlRHWG14cFZKOE51NGplNndmOTZaMjJmClEwRDM4enVkK0NLSDNiTVAzYXlY WEpCY2RQb0VOcnpGYldQNUZUZy80VFRESjN2T0FIWlI1aUN1bllnaHg4YjcKRmZhNFVia3ds RCtkaDhHaUlBdHZUNTFBYzBjTzBXYzBaamM1N3pQVXoxemxvTWJmK3piMUJzbjdEdUVRb3Fq MQpnd0FSQVFBQmlRSWxCQmdCQ0FBUEJRSmFQVkF5QWhzTUJRa0psQ1lBQUFvSkVGcXkrdkY3 Rnl2cXJDOFAvMXRGCjZUZVI4M3hENk1hc3FYeXJCandjTG16aWFGME1sa2o4ay9ZVWlaL2tu YjUzbjk3eFFuaDl5eFB2MFRUOFdwZmQKbjNCbXZxR3loOCtvdUhYOWpNT3hpUmtNZE5oSWF1 VllZLzhqbVJmQlNZV2NGa2ZNemRZYXN2ZEx0bVlKZ3gyNQoySEtURmRlT3Jzem9PaldqRXp3 bWgrdGNhM0FGTXUvbkIrKy9LQW1pNVVKVjd6c1o3dVlKNWptOTdMVjVTTGpOCkpJWFhNK2xI cUNEcmpEYURoTmN6bXExTENSbFU2L1dEanZrdXdhVmhaRzRsWHhNRHJ2S25YTWtqc2VRMm9L ancKcklkZlFNODZIMXo1SjMxbGZocW9wK29mMGNpbWNJc0JnU0NQdStoOTZMSHVBemVSQkNi REtlcXJmWnRBWkFHcwpva1JpbmE5OTQ3ZlJXeFhIaDNPNjZJTG1YS05SeHhXYkRrUHZZblFX VWF0OFNiU1REb1BXckRJR0RSSUF5cHFZCm8zcGNOMk9FMEMxY2hxZ0RaUXhrcis5a1laUXB1 cE9BTjJUUitmTTdKdmJPOWNvS0k4VXFvZzhDb3BvTWVEUWsKZDBZamNxbEIxRTBzdk9ESFR6 Y1NvUnpvZ0RCWURxTkxQN3FWa05YcGNPQVhTVmlvQmdpU0RmN281UmRTL3FtVQp5WEJJZXE2 STV6OHhCY2QrQlEvbi85RnJrbTZLN0lLUDNuZ1VQNHdFb2lQeDVaRTUrZlBJU2NHbVZVY1pJ TWhrCnZNdmVtOVhYaDF5eWhxTjE0Z2ZqbUx3UEdkV2JyZ0c4UVVlMHMyV2VXSXlzczZ1VGl5 RitaYkpTbzJYT0tWYzMKWUZNVlVVZmd5dWRxQVYxd1dkWmluVWsrSDNwa3FPS29IQXkvOGZT VAo9M0RZelFZCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0tLS0KCi0tLS0tLS0t LS0tLS0tRTE2MTI3Q0VCOEIzNzAxNzRCODVGMzQ5LS0KCi0tUjdWeFJNQmdqa1pRVnVQbTE1 UWQ0bVJmdUpQdTZKZFdNLS0KCi0tMm1xdTdnaWE3aDJRV2owZUdoMlVNSkpWeVVvblVRNUYw CkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vcGdwLXNpZ25hdHVyZTsgbmFtZT0ic2lnbmF0 dXJlLmFzYyIKQ29udGVudC1EZXNjcmlwdGlvbjogT3BlblBHUCBkaWdpdGFsIHNpZ25hdHVy ZQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFtZT0ic2lnbmF0dXJl LmFzYyIKCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tCgppUUl6QkFFQkNnQWRGaUVF VzdXbTZsZGwwc1dHUEs0bldyTDY4WHNYSytvRkFsNGFNTFlBQ2drUVdyTDY4WHNYCksrcDlM dy8rUEdDcWdoQzl6dE5BZjRoSk5TeUtvUms3ampWaFdmSS9mTWVLRnFPcGt3WkZCVUpNQllr bDdYMFEKOGw4TGkydVlqcWttQ0psUGZCa3ZOOVBXeEtNU3FGQ3kxUjJhNlRkMmo2N1RyVENR T2FDOTJIVWNKSFNIVFAwbwo2eHorTUQrYzAvWXhJOXRnY292U1lkbmVzaXV4eTFkYUxEUy9m aVFTaThBMGFyMEduQUlaaHpvMXJPV1pEc3Y3Ci9odWpjTmQ5ZXNlYzVjSDNWVFpEWUJ2MHpK bHRKRUpHcEhPVUR2N2k1WWszWlZUeVVUQUZpRVJBSkRIVVdqaEQKWXQzcElqSXlpZ3NMdGZO MTQ5Rm1NUmVDZG5CV292N0NobXR4enNCcitvSXRuc21QalJRSjBGa3A5Y1lXK1YvMwpzeWpN Q3F3MmNVdU40bmE5YThBRDFBM3lCamUvUTdRdTZuMEVvalJnVWo5bGRaanBvRXZiNkdDby9F SGVITHFDCnY2OG9JMGJSTzIreHZ2YzZsNDU3Z2Zscmg5SUZ4SG1lb2NBRVdXVTU3MGZ4Z2xy TnRzNTd2b25ieEcwWVpwRFIKSndSRkJ3RGg0TlhibWd1S3ZIR3BXVkE5QS9ndW1OdWVEU21U bGZjdkNvbVh6MUNkeWIxUGNxaDhEWmU3TUtuTwpzUVlacXREMXpZdjNFZkNqMVhpRmZPOUp4 WFJuRVlEMVpTdDczZUdOaFc1RW14cXkyZ2dYNkxNQWw4S2ZFN3dWCldiRUFkYlM0a0x5WmxF emFRSmtDRXZQaUpMY2F5NkJuTkNkWU96Ylgzb3FNK05QejRscmtVdmZia3FkR0pUK28KR01v VkJiTWluSituVXRxWitZbmt6M2JoQWMwS1draWhEcmtTMmRMQUtWOVRVaTJPeVhRPQo9N3dS YQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0KCi0tMm1xdTdnaWE3aDJRV2owZUdoMlVN SkpWeVVvblVRNUYwLS0KCgo= --------------3A3AEBD3B471977F177AA9E0 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" LS0gCkxha2UgbWFpbGluZyBsaXN0Ckxha2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sYWtlCgo= --------------3A3AEBD3B471977F177AA9E0 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------3A3AEBD3B471977F177AA9E0-- --RLM84vciukC4xZMWSkylzr4qp4ZwTdHmS-- --rwI2pelNHuJLfJh8CnnbmpJxwj1eSR2qo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4aMe4ACgkQWrL68XsX K+rXgA//XuDb1FBy1WZ8cmlO8yB8uO6Ty1QJxRBoKhjWqdovQaXKtP8+LUaxeka9 eNWcy2h0F9RzShgtm91SEyGt/7pcBPE9q9hWPJb43m7xGutCshSTOkjiVXnqOXqq YstVU9RquReuhU6VqcorhElKFNfbu5WkKsXAPyQoC0NMWX8gexp+Jz8wQoN8ujG7 dgUjC5PaTFR6cu66cuu+i4PvBeU2fYsMuU1E272yES9ps/32+u0fJLl9YxjprKeu vmHMTyjmln6JerSk5lOMXntrAq1Zqmz+uVqKC985YK0RRrhGgu2vH6aWI0+CyBxo roDo8BNmZX9ASTDXek6xKRfJFTDeY1TKKnghDkIftSITKuEsyeKJYPkUU7RlL5FQ waPhzwpuX4PATnCjuopS9cxHYCVh/FSvkHsidldAJokaC/hxb6Gl0CUYtNdmGC+R BnbHsXjY1uhbzqfrRCm0rIaTs7PQILiTdSrCe4MX+b/+EVQQCYQha1gt0+zw2MZ9 qjM+SPKcLE23NH4NNxc1/G6beU5fzvId+naOVAuj2zEwNY3CwONwPCfjmEUSpo4y sKDazSGpvSenUx7fwdVI28Cg+nHyR3YBdcFK3SjKkOLkVnCnRdjD6xcqjG2f29IQ 7xfxV7oQxr7fd4Vw9bTVuUm5o04oXFKo2TVZYdRYNrTKBOjhYLo= =TfZK -----END PGP SIGNATURE----- --rwI2pelNHuJLfJh8CnnbmpJxwj1eSR2qo-- From nobody Sat Jan 11 16:30: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 E5DD012004E for ; Sat, 11 Jan 2020 16:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, 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 Dgrvd7k58CEX for ; Sat, 11 Jan 2020 16:30:14 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C419312004D for ; Sat, 11 Jan 2020 16:30:14 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A7F503897D; Sat, 11 Jan 2020 19:29:49 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 543AA431; Sat, 11 Jan 2020 19:30:13 -0500 (EST) From: Michael Richardson To: core , Ivaylo Petrov In-Reply-To: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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: Sun, 12 Jan 2020 00:30:17 -0000 --=-=-= Content-Type: text/plain Ivaylo Petrov wrote: >> I think that the major issue is that I am still not convinced that >> IANA is prepared to operate pyang itself. Conversations at IETF105 >> and IETF106 did not convince me that they (IANA) completely understood >> what they are being asked to do. For instance, I'm not convinced that >> there is a support process for IANA to get bugs fixed in the sid.py >> module. >> >> (I would be pleased to be convinced otherwise) > I remember that during the discussion with IANA we considered that the > authors and the expert will be responsible for the running of the pyang > tool and IANA will only take the .sid file and store it. The .sid files > will be provided to IANA when there is a request to register the .sid > file - however that is done. Do you see an error in our reasoning other > that the fact that we might be burdening the authors too much? Does > this seem acceptable to you? okay, so the expert reviewer needs to be able to run pyang --generate-sid-file, etc. I don't know if IANA has a process to accept files online, but I guess attachments to tickets will work. >> (3) a document could ask for an early SID allocation, referencing a >> YANG module which is in another WG, or worse, not yet adopted, and >> therefore not subject to Early Adoption rules! This may be a problem >> we do not to fix (Just get the document adopted), but I think that we >> should be clear about this. >> >> >> My recommendation is that all YANG modules, upon being *ADOPTED* by a >> WG, have a SID allocation done. Yes, the document will get revised, >> but the SID system is designed to deal with this. > Yes, that issue does not seem obvious. Currently I don't see a blocking > issue with allocating SIDs for all YANG modules once a draft is > adopted, so maybe this is truly our best way to avoid problems. okay, if we are in agreement, then I think that we need text in the SID document's IANA Considerations that says this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4aaJUACgkQgItw+93Q 3WVi4Af+Knw2WBl2bBx5yWiaoxErQRQncZ+M9EaL6BupkyGntgnc0qAG8/oSyGFC 4lgtyt5wwi+eNpiXjfFoI58k1ANdFBpnRpP90NYB0uKqn2nDpXiOdVXJQ0uNLNTv s1wHMKyAJixe/jIqSCxQepo2kntl9ZcqEv7IS9Qty/XiFj+swDWQP4W6EKR8D3nq LyZqJYybBziHHX0a59wILzwJFrAPOEx+B2H2abX3ICrxY3cO7R0W+wlRT2yNvuwf yW7hIx8YgwLYsKXpTAeMXd82wJJvLksYhdsCi+/QvaozUYmnj7pr1xRhMXMAn/Q7 uOFjVRQa83QiRWqqR011JDGM8TVVRg== =SR4G -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jan 11 21:04:01 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 A8E371200FA; Sat, 11 Jan 2020 21:03:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 xdhUsjQuFX8x; Sat, 11 Jan 2020 21:03:57 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398DD1200F9; Sat, 11 Jan 2020 21:03:57 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 11 Jan 2020 21:03:50 -0800 From: Jim Schaad To: CC: Date: Sat, 11 Jan 2020 21:03:48 -0800 Message-ID: <000101d5c905$adec9480$09c5bd80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdXIs79pSA2qqTgBQICxmqfOpB28Lw== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Review of draft-ietf-core-coral -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: Sun, 12 Jan 2020 05:04:00 -0000 Klaus, The change of text by adding the last paragraph of section 3.1.1 took me by surprise. It does not match what my understanding of how things are going to be parsed. It took me quite a while to realize that there is a set of conflicting statements here. To me, the text appears to state that when parsing document there is a single environment, and that environment consists of two variables. However, when parsing a link or a form there is a new pair of variables that are added to this environment. Thus in my mind the environment consists of a stack of variable pairs not just a single pair of variables. Section 3.2.1 - There is a MUST NOT in the last paragraph, is the receiver of a document supposed to enforce this in some manner if it is in a location that it does not currently care about. Some things can be checked such as an integer where a text string is required, but for form fields this would seem to be not generally enforceable. Section 4.2.3.3 - I think I might be missing some restrictions here and want to verify. Consider the following document: #using a = a:2#tag In this case, is the result of the processing ? Jim From nobody Sun Jan 12 03:27:13 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 8F18F12004A; Sun, 12 Jan 2020 03:27:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 mEbdjXrTWmGV; Sun, 12 Jan 2020 03:27:09 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 5CF8C120043; Sun, 12 Jan 2020 03:27:08 -0800 (PST) Received: from mail-qk1-f180.google.com ([209.85.222.180]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1iqbOb-0002zG-Gf; Sun, 12 Jan 2020 12:27:05 +0100 Received: by mail-qk1-f180.google.com with SMTP id a203so6141602qkc.3; Sun, 12 Jan 2020 03:27:05 -0800 (PST) X-Gm-Message-State: APjAAAVe3ndDna2AFhx4qFkxFeO9wOQQdEk3NipQUIgSZu8s6E9NUOGj ppJtSysYLheOYmqesTV5ld9TKycKixq7iFI2qO4= X-Google-Smtp-Source: APXvYqxtjJYLhEYeUcy1ni7RNsxdoOXx0EmoAiqOh+dclXcAWKQkNq/wDc0GaYGdLTEtd6F0qLJIxxcekBulX+HlABs= X-Received: by 2002:a37:9bc2:: with SMTP id d185mr6920497qke.422.1578828424139; Sun, 12 Jan 2020 03:27:04 -0800 (PST) MIME-Version: 1.0 References: <000101d5c905$adec9480$09c5bd80$@augustcellars.com> In-Reply-To: <000101d5c905$adec9480$09c5bd80$@augustcellars.com> From: Klaus Hartke Date: Sun, 12 Jan 2020 12:26:28 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: draft-ietf-core-coral@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1578828429; f66fa92e; X-HE-SMSGID: 1iqbOb-0002zG-Gf Archived-At: Subject: Re: [core] Review of draft-ietf-core-coral -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: Sun, 12 Jan 2020 11:27:11 -0000 Jim Schaad wrote: > The change of text by adding the last paragraph of section 3.1.1 took me by > surprise. It does not match what my understanding of how things are going > to be parsed. It took me quite a while to realize that there is a set of > conflicting statements here. To me, the text appears to state that when > parsing document there is a single environment, and that environment > consists of two variables. However, when parsing a link or a form there is > a new pair of variables that are added to this environment. Thus in my mind > the environment consists of a stack of variable pairs not just a single pair > of variables. In draft-ietf-core-coral-02, the environment consists of the two variables, but each scope creates a new environment that is discarded at the end of the scope. So, yes, there's a stack of environments involved, not just a single environment. (This hasn't changed since draft-hartke-t2trg-coral-03.) The idea behind this is that a processor should be able to skip over an entire sub-tree without having to process all the directives in it. Before CoRAL used CBOR, each sub-tree used to be prefixed by its number of bytes rather than its number of data items, so skipping over a sub-tree could be implemented by simply bumping a pointer and doing a bounds check. > Section 3.2.1 - There is a MUST NOT in the last paragraph, is the receiver > of a document supposed to enforce this in some manner if it is in a location > that it does not currently care about. Some things can be checked such as > an integer where a text string is required, but for form fields this would > seem to be not generally enforceable. The intention here was to say that the MUST NOT applies to data types that are syntactically not allowed (like a Boolean as a link relation type) but not to data types that are semantically not allowed (like a Boolean as a form field value that is supposed to indicate a content format). > Section 4.2.3.3 - I think I might be missing some restrictions here and want > to verify. Consider the following document: > > #using a = > > a:2#tag > > In this case, is the result of the processing > ? According to the ABNF in section 4.1, the second line would tokenize as identifier("a") punctuator(":") integer(2) punctuator("#") identifier("tag") iriref("/tos") Section 4.2.3.3 requires two identifiers separated by a colon, so this line is currently a syntax error. If you, for example, have #using a = a:b2 instead, the second line would tokenize as identifier("a") punctuator(":") identifier("b2") iriref("/tos") \______________________________________________/ qualified-name \______________________________________________/ \____________/ IRI IRI \______________________________________________/ \____________/ relation-type link-target \_____________________________________________________________/ link and the result of processing a:b2 would be . Best regards, Klaus From nobody Sun Jan 12 04:21: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 006C2120043 for ; Sun, 12 Jan 2020 04:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 AM6fWx_6vGav for ; Sun, 12 Jan 2020 04:21:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 D08DA12003E for ; Sun, 12 Jan 2020 04:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578831699; bh=uEMEyhrQ/LIUDi24xPYrtfeteFIcvICkNsIIsTwijW4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=R1xiTJKsvAkqiuVwiG/Fqysle67S6iVqpqbrwDCPVMr9qXUnPzMFFIKUDW+8yWVd9 xfIxnORfSH1aZDvhJES6wqOXbOVtwrbR98uQbuBIL+2T7+UG1l7Tbf6oucVJYYHNxl 3cW9LZNuB599EaGjlbr/xPf44ugpF/dGwVjI8SJo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([94.216.249.196]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mq2nK-1jTqoi3UDi-00n9Uf; Sun, 12 Jan 2020 13:21:38 +0100 To: Klaus Hartke Cc: "core@ietf.org" References: <324677e1-06d4-a4d6-b79c-9a55c01adcbb@gmx.net> From: Achim Kraus Message-ID: <6eeba0d2-7cce-44b1-cc47-70886277739d@gmx.net> Date: Sun, 12 Jan 2020 13:21:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:gaRFJ7nN0zEjqxWcNLxmNWQWJaR0TcSOWNPE9o5poxcbbk5Ox2k 0n6oDFasnChRm6mKYl462J7ve5n8wJDH8/ol2guKay8XRNXVDKTaa6x9sJcDBfo6XUKOKgu mRwPfAuUjbXhapRxt8kb2lropbFoeHc3B8fNJyBHJA/TgagkNoTKdFLFA+vuAoTN2VvzPu+ PwrnRIz4B/S+waKr6xGog== X-UI-Out-Filterresults: notjunk:1;V03:K0:Rlt8G7yEppQ=:uYRrgoCZBjteV2ILUz4vZU PW/bUD1+7d6IBxkalW+JJvzOLbtBDLRXWAFEEOWwHmnKAL9/XKOWYmjeGeMlGbvo1cJqVZKWd Ekq0bYqm+9Jrp36hBsGVgjMXFkp0/pFEho9oFcXCl0V52/Mb6RviUHUlKOTBILBT5KUCw7zaI s4cX1tEsASuo+W8j3O/dfTxel2mm4g7PY1kmc2Ak1ibP84Br2ntGs2M5zvRP1eBWZ99Fl24Ct 8HZGWILwn3gG7jagPTQCO2qQQDtIsPL9Prax9V5jx3N0aQnFMXgkubF8w6E1bjKLE4v1n/BTs ZMqtXcZ+8qwuxdiVYDZ6e3VPukjcnTdfxk8+PCkTGKXFsd86hhoD3c5Qoubf20S5oX7ZPkkpk JOm0LXgFVQCNwKOaHnvQc0O/qZx4c7XmLwJ08Zla0OP81DpNJdoilq/wEY6SZIiltLM4vlX0j CNDgkBgno8hzBJk2GyydhQ3QFpWFdjCIh8qQ2qE8YvkWO81jgB22YsqnAoyhvbcdtzPX68cCq ZUxL+q+f9St+qZs/9nOqSWreUhBBXH08fOpdGzaGGUYvv+1MIOVW8TDSPqbxmdCrrdXhjIjYg ce8UsqygAE8iXBonrngXcLPUn84eAeL0T3iaF3L4yVG5Vbj+44HkoAn0Q5uNo0uXahjtSHgHc pyksnBVcAVQZhno9jsyrInAnLixdk2JUHEli3bVAqd7+gLpjroWi5KIdVrXW6Y2VZxFSU1LQC QbK1F09L8Nkuxv8rY5uOCvY8gSr2VPKDw5GvDf5puv+bTzmGdAu2KnhiAE9f5uhnze/VEKhAF ajJwaa3ZcXkf1W9TuKWaa9j3V/snRpI2AvbvZ6MPBL+kADb/37Ztkp32PSdQjxYyMnKGWgBYB mhCy1B9jMkT4U/fGzcbTjRjUlT07Td1HDfp15QYd7FSGC9fXDxHlpp4bmu1idPai0tk0zV4SR prMDWokEi0wOrWZ357BzZFKfjHepy41mL0FBrTuRqX9VYB7hANui/6PLGzJSmLQ6g/H5RAp9k YXkR1SujooFso9KEiJgfGvyluKYCPu4OswM9/AGLSIKyUss0XEMvV/2SCNBdzT0lVfDh1KnU4 6aBeAg7s6BEHs6iEe59dcBsS+Tt+gsPfQ+peHMbqFtQI4gP67zdoSbMFr+yqe1JmUY0Eb/zZj zmNiOhS0tY4UYBp79PJRcAqhsI6GwO63J3eaFgXLsS86d6KEl57/uf/6QvoSKGdttEV+rUXBd TE1ASBfja5Zq1z3lRvOdr74YMKf3D7pxxhcIZbfHKX9VuRf0OT7mRxWTlNYU= Archived-At: Subject: Re: [core] RFC 7252 - Forward Proxies 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, 12 Jan 2020 12:21:45 -0000 Hi Klaus, thanks again for the clarifications! best regards Achim Am 11.01.20 um 14:03 schrieb Klaus Hartke: > Achim Kraus wrote: >> In my understanding the, CoAP URI-Host option will be "example.com" and >> not "198.51.100.1", otherwise hosts with multiple virtual server will >> not be able to differentiate the logical request destination. > > Oh, sorry. I changed the example at some point from "example.com" to > "198.51.100.1" and apparently didn't change all instances. Here's the > corrected example: > > If a client wants to GET a representation of > , > then the CoAP options always encode > , > regardless of the destination of the UDP datagram. > > Of course, the same is true for "example.com": > > If a client wants to GET a representation of > , > then the CoAP options always encode > , > regardless of the destination of the UDP datagram. > >> Also in my understanding, the port, IP-literal and IPv4address (the non= e >> regname variants), are only included, if they differ from the >> destination (which will be the porxy's address in case of a proxy). > > Yes, exactly. In pseudo-code: > > |url| =3D the request URI > |scheme| =3D the component of |url| > |host| =3D the component of |url| > if the component of |url| is present then > |port| =3D the component of |url| > else > |port| =3D the default port number for |scheme| > endif > > if a forward-proxy is configured then > include a Proxy-Scheme option with value |scheme| > |transfer-protocol| =3D the protocol of the forward proxy > |destination-host| =3D the IP address of the forward proxy > |destination-port| =3D the port number of the forward proxy > else > do not include a Proxy-Scheme option > |transfer-protocol| =3D the protocol indicated by |scheme| > |destination-host| =3D |host| resolved to an IP address > |destination-port| =3D |port| > endif > > if |host| equals |destination-host| then > do not include a Uri-Host option > else > include a Uri-Host option with value |host| > endif > > if |port| equals |destination-port| then > do not include a Uri-Port option > else > include a Uri-Port option with value |port| > endif > > (Necessary data conversions omitted for brevity.) > >> > It's the port number of the request URI (or, if the port number in >> the request URI is omitted, the default port number for the scheme of >> the request URI). It's not the port number of the forward proxy. >> >> My question was rather, if it's the default port of the proxy scheme >> (maybe http), or the requests coap-uri-scheme. > > It's the default port number for the scheme of the request URI. > > > Klaus > From nobody Sun Jan 12 09: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 74D7E120048; Sun, 12 Jan 2020 09:30:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 wdRZaJi5axWv; Sun, 12 Jan 2020 09:30:39 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD4512001B; Sun, 12 Jan 2020 09:30:39 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 12 Jan 2020 09:30:31 -0800 From: Jim Schaad To: 'Klaus Hartke' CC: , References: <000101d5c905$adec9480$09c5bd80$@augustcellars.com> In-Reply-To: Date: Sun, 12 Jan 2020 09:30:29 -0800 Message-ID: <001601d5c96d$fdea59f0$f9bf0dd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJMauJut099jN8u5qvrhYg2yf/mdwDPbVj4pvOFXgA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Review of draft-ietf-core-coral -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: Sun, 12 Jan 2020 17:30:41 -0000 -----Original Message----- From: Klaus Hartke =20 Sent: Sunday, January 12, 2020 3:26 AM To: Jim Schaad Cc: draft-ietf-core-coral@ietf.org; core@ietf.org WG Subject: Re: [core] Review of draft-ietf-core-coral -02 Jim Schaad wrote: > The change of text by adding the last paragraph of section 3.1.1 took=20 > me by surprise. It does not match what my understanding of how things = > are going to be parsed. It took me quite a while to realize that=20 > there is a set of conflicting statements here. To me, the text=20 > appears to state that when parsing document there is a single=20 > environment, and that environment consists of two variables. However, = > when parsing a link or a form there is a new pair of variables that=20 > are added to this environment. Thus in my mind the environment=20 > consists of a stack of variable pairs not just a single pair of = variables. In draft-ietf-core-coral-02, the environment consists of the two = variables, but each scope creates a new environment that is discarded at = the end of the scope. So, yes, there's a stack of environments involved, = not just a single environment. (This hasn't changed since draft-hartke-t2trg-coral-03.) The idea behind this is that a processor should be able to skip over an = entire sub-tree without having to process all the directives in it. Before CoRAL used CBOR, each sub-tree used to be prefixed by its number = of bytes rather than its number of data items, so skipping over a = sub-tree could be implemented by simply bumping a pointer and doing a = bounds check. [JLS] What changed is not how things work, but the specific text that = was added to section 3.1.1 - that is the text that got me confused short = term. > Section 3.2.1 - There is a MUST NOT in the last paragraph, is the=20 > receiver of a document supposed to enforce this in some manner if it=20 > is in a location that it does not currently care about. Some things=20 > can be checked such as an integer where a text string is required, but = > for form fields this would seem to be not generally enforceable. The intention here was to say that the MUST NOT applies to data types = that are syntactically not allowed (like a Boolean as a link relation type) but not to data types that are semantically not allowed (like a = Boolean as a form field value that is supposed to indicate a content = format). [JLS] Could be clearer. =20 > Section 4.2.3.3 - I think I might be missing some restrictions here=20 > and want to verify. Consider the following document: > > #using a =3D > > a:2#tag > > In this case, is the result of the processing=20 > ? According to the ABNF in section 4.1, the second line would tokenize as identifier("a") punctuator(":") integer(2) punctuator("#") identifier("tag") iriref("/tos") Section 4.2.3.3 requires two identifiers separated by a colon, so this = line is currently a syntax error. If you, for example, have #using a =3D a:b2 instead, the second line would tokenize as identifier("a") punctuator(":") identifier("b2") iriref("/tos") \______________________________________________/ qualified-name \______________________________________________/ \____________/ IRI IRI \______________________________________________/ \____________/ relation-type link-target \_____________________________________________________________/ link and the result of processing a:b2 would be . [JLS] I should have looked at the ABNF, sorry about that. I don't = believe that there is any way to use this with = but I don't think that is a real = problem. Jim Best regards, Klaus From nobody Sun Jan 12 09:55: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 8DF1612002F; Sun, 12 Jan 2020 09:55:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 6HPYv4M_A57Q; Sun, 12 Jan 2020 09:55:07 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 F089B12001B; Sun, 12 Jan 2020 09:55:06 -0800 (PST) Received: from mail-qt1-f177.google.com ([209.85.160.177]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1iqhS2-0006X5-9e; Sun, 12 Jan 2020 18:55:02 +0100 Received: by mail-qt1-f177.google.com with SMTP id w30so7085853qtd.12; Sun, 12 Jan 2020 09:55:02 -0800 (PST) X-Gm-Message-State: APjAAAWv+GEQcRBHfaMP/svwzotDyF4QNT8jlp3PHewWYpGR5jXVr9O/ /GynmxymzaUQyEe+I5vRreBxi9eUZ4nh36IFXAA= X-Google-Smtp-Source: APXvYqxTY0fYODZGNTadQmLykhqjzwXfBPZPNRASogNmzYJEyrfX16rTbKjc0XbkAcl4Rctf2uKYNk+dSR2qak8ZMfs= X-Received: by 2002:ac8:750b:: with SMTP id u11mr11020632qtq.174.1578851701261; Sun, 12 Jan 2020 09:55:01 -0800 (PST) MIME-Version: 1.0 References: <000101d5c905$adec9480$09c5bd80$@augustcellars.com> <001601d5c96d$fdea59f0$f9bf0dd0$@augustcellars.com> In-Reply-To: <001601d5c96d$fdea59f0$f9bf0dd0$@augustcellars.com> From: Klaus Hartke Date: Sun, 12 Jan 2020 18:54:25 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: draft-ietf-core-coral@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1578851707; 5804b60f; X-HE-SMSGID: 1iqhS2-0006X5-9e Archived-At: Subject: Re: [core] Review of draft-ietf-core-coral -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: Sun, 12 Jan 2020 17:55:10 -0000 >> The intention here was to say that the MUST NOT applies to data types that are syntactically not allowed (like a Boolean as a link relation >> type) but not to data types that are semantically not allowed (like a Boolean as a form field value that is supposed to indicate a content format). > > [JLS] Could be clearer. I've made an attempt for a small clarification here: . If you think that can be further improved, a pull request would be very welcome :) Klaus From nobody Mon Jan 13 02:36: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 B12D61200CD for ; Mon, 13 Jan 2020 02:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1G4ekD32WUNa for ; Mon, 13 Jan 2020 02:35:58 -0800 (PST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 9E7A3120072 for ; Mon, 13 Jan 2020 02:35:58 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id m24so9026627wmc.3 for ; Mon, 13 Jan 2020 02:35:58 -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=8i/bdGuSYoBv/7WXAxPLWEz2R5ilaxm6dt6gDoYUM0w=; b=JtKk1XgzqrPhOAHL1aG5OWJOYiDPLbig5ZQTbETqfssO7R4xbQB/Mu+2BXOOGAWjcP RaTgz0RF+oYuSXS/CHJB5nvYDGOxmGTCq21bAX5F79w7zf61CHykMUi9+A6UikSlwDiI G9JPZZH3O2o/lkFVkRnraEDUMMJEN7kEDCJoyERtiV3oKkr338GJQjRvgxkTSUqLgfA5 BBoMdOJPiKVvqgnrGq0YKLGMrDK9tjQq6U/oY2/UAFtm3yXNXAUPjdIksp0xw0pZgDTK QtVo2dClflmcTvSrN4crtfKJfNkYDMIKmA2o4FXqk40FVGUegveZfAkdci4pqKaDRnqy Ylwg== 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=8i/bdGuSYoBv/7WXAxPLWEz2R5ilaxm6dt6gDoYUM0w=; b=pT3f2Pn9GwRkLpHdYCAeOwTKWmCNcclstLrWWWa/sK57ErbDKajFrgTW1M2sijrFSo hV1Kv0qImCPFQ9lyqlcgNcROEDoCkQfv/r7sLcmLj59F14NMaghkNnODL3gCKm18nA84 L4sTO83JKkuyvfdp8J20KryBUonOIHbNP/eS/uWHOeLrj7n4FnmfW/24ZXP8jX8gmXAc I2HGXJ1PUIpBlBuK07ItEFWdB40/xr7SFlqgP5qPEek2RDPyolHz3CuQW7DqGgjRurUv xALebXQmGZa78UYyevp8fcFGyzuxr8+DEEWN1vHE6CM3vfL64khQZm+PZpzpe7U7Hocp hQ8Q== X-Gm-Message-State: APjAAAXMC60UA/OyLHJt4aiZoatDRbA/GKOddty4BnlAuFTWOf8VmCjO W/siE/H3vksljSHSwM54EQCsAg4iLO0r3z4581dAcQ== X-Google-Smtp-Source: APXvYqxEgz10lTsAniW2GrsOcpMzf76ohqHCXq/I7JYpJ6Td1SB0Wr/WHMvjzOUp+f1gN7tQJlqg2RFh0MkhIrVX68c= X-Received: by 2002:a7b:cb0d:: with SMTP id u13mr19991860wmj.68.1578911757136; Mon, 13 Jan 2020 02:35:57 -0800 (PST) MIME-Version: 1.0 References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> In-Reply-To: <15754.1578789013@localhost> From: Ivaylo Petrov Date: Mon, 13 Jan 2020 11:35:30 +0100 Message-ID: To: Michael Richardson Cc: core , Michel Veillette , Alexey Melnikov , "a@ackl.io" , consultancy Content-Type: text/plain; charset="UTF-8" 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: Mon, 13 Jan 2020 10:36:01 -0000 OK, a question to the chairs below. On Sun, Jan 12, 2020 at 1:30 AM Michael Richardson wrote: > > > Ivaylo Petrov wrote: > >> I think that the major issue is that I am still not convinced that > >> IANA is prepared to operate pyang itself. Conversations at IETF105 > >> and IETF106 did not convince me that they (IANA) completely understood > >> what they are being asked to do. For instance, I'm not convinced that > >> there is a support process for IANA to get bugs fixed in the sid.py > >> module. > >> > >> (I would be pleased to be convinced otherwise) > > > I remember that during the discussion with IANA we considered that the > > authors and the expert will be responsible for the running of the pyang > > tool and IANA will only take the .sid file and store it. The .sid files > > will be provided to IANA when there is a request to register the .sid > > file - however that is done. Do you see an error in our reasoning other > > that the fact that we might be burdening the authors too much? Does > > this seem acceptable to you? > > okay, so the expert reviewer needs to be able to run pyang --generate-sid-file, etc. > I don't know if IANA has a process to accept files online, but I guess > attachments to tickets will work. > > >> (3) a document could ask for an early SID allocation, referencing a > >> YANG module which is in another WG, or worse, not yet adopted, and > >> therefore not subject to Early Adoption rules! This may be a problem > >> we do not to fix (Just get the document adopted), but I think that we > >> should be clear about this. > >> > >> > >> My recommendation is that all YANG modules, upon being *ADOPTED* by a > >> WG, have a SID allocation done. Yes, the document will get revised, > >> but the SID system is designed to deal with this. > > > Yes, that issue does not seem obvious. Currently I don't see a blocking > > issue with allocating SIDs for all YANG modules once a draft is > > adopted, so maybe this is truly our best way to avoid problems. > > okay, if we are in agreement, then I think that we need text in the SID > document's IANA Considerations that says this. Do you see any issues adding such a text and do you want me to add it before you can start a WGLC or how do you want this to happen? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- Best regards, Ivaylo From nobody Mon Jan 13 10:11:56 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 3E43912089F for ; Mon, 13 Jan 2020 10:11:54 -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 eoCEhe5siFyU for ; Mon, 13 Jan 2020 10:11:52 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBB412088C for ; Mon, 13 Jan 2020 10:11:52 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 15A963897D; Mon, 13 Jan 2020 13:11:26 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 234A9A3B; Mon, 13 Jan 2020 13:11:51 -0500 (EST) From: Michael Richardson To: core@ietf.org, Ivaylo Petrov In-Reply-To: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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: Mon, 13 Jan 2020 18:11:54 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I think you should just ahead and add the text. The document can change during WGLC. Some edits I suggest: } The reason not to use 64-bit } using SIDs: unsigned integers is that otherwise protocols doing } arithmetical } operations with the SIDs could be very difficult to implement. Change to: The use of 63-bit unsigned integers allows SIDs to be manipulated more ea= sily on architectures that might otherwise lack native 64-bit unsigned arithme= tic. The loss a single bit of precision is not significant given the size of t= he space. Maybe you pointed me at github.com of the XML before, but I lost the link, = so I'll do this the old fashioned way. For the IANA section, I suggest the fol= lowing: 6.4.1. Structure (no change) 6.4.2. Allocation policy (one pointed added at end) 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=20 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 the other ".sid" file. o SIDs never change. o IANA is expected to store the SID files and make them available along with the associated YANG files in the YANG Module Names registr= y. ADD: 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 [BCP100]. The details of the Early Allocation should be included in any Working Group Adoption call. 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 ne= ed 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 is permanent.=20 The Expert Reviewer provides the generated SID file to IANA for registration.=20=20=20=20 This process may be someone busy during a bootstrap period (there are ov= er 100 YANG modules to date, none of which have SID allocations), but should quiet down once needed entries are allocated.=20 If the document is an unprocessed Internet-Draft adopted in a WG, then an Early Allocation is performed for this document as well.=20=20=20 Early Allocations require approval by an IESG Area Director.=20 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 grou= p. 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. =20=20=20 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. =20=20 A previously SID-allocated YANG module which changes it's references to include a YANG module for which there is no SID allocation needs to repe= at the Early Allocation process. Early Allocations are made with a one-year period, after which they are expired. [BCP100] 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 updat= e any referenced Early Allocations to expire no sooner than the referencing document. 2) The [BCP100] 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. =20=20=20 This is driven by the very generous size of the SID space and the often = complex and deep depencies of YANG modules. Often a core module with many dependancies will undergo extensive review, delaying the publication of other documents. [BCP100] 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. =20=20=20 =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4csuYACgkQgItw+93Q 3WWkgwgAn4YJObqWEoc4+GLhgvAJfQ/OAF8YIFftcyt5uuqh8xW1POGl9xsBBo/B T48mzwOZupQYQOA31dR4cshoYGgLbqQVwjDGA9rd4lgl0wvErNEP4no7aWo4KMqZ 1CqbfrMhYOMhIxWH5fhrGo3ujAJyB11OxEhSZUZJYn1K+nwXMW96fvqF512rPX63 aEP/vQkdaqFWOSS+RnvbjPpnT/9cYY7WpJPeGEVzqmCQWllG6rikxFPCktzopNbM SsUKfVnNRdCU7PV0LBHgPjYUnqdWdLWLKh1/UT3weC3IbyHc4G64+/sk3eMIBZPT onajASszLYzz8Vo+Tm+oipK5FpiW+g== =+7Fg -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 13 10:15:35 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 9EB371208E3 for ; Mon, 13 Jan 2020 10:15: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 h2lPVsnUC6qw for ; Mon, 13 Jan 2020 10:15:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D957C1208C5 for ; Mon, 13 Jan 2020 10:15:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 016343897D; Mon, 13 Jan 2020 13:15:05 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0D197A3B; Mon, 13 Jan 2020 13:15:31 -0500 (EST) From: Michael Richardson To: Ivaylo Petrov , core In-Reply-To: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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: Mon, 13 Jan 2020 18:15:34 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ivaylo, In section 6.3.3, you have no allocation for constrained-voucher. You had given us 2500:2550 --- constrained-voucher-request. And 2400 -- 2440:2500 --- constrained-voucher. I thought that this was going to be in the initial allocation. Maybe this causes some problem, and we need to do this some other way? We can't do an Early Allocation until this is published. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4cs8IACgkQgItw+93Q 3WUhSAf+OY1a+ByJ9shK+I6oJ7X3aULpbuKBaSE10VaBhmOldRIbKeDLnhAntkY3 Fq9qPeyvfJ3cf1KTjsxfd1ecBJS/LeDCc7N5yZKCMoXurp1cmcDkSTKoUn8eCzHz oizW/z6+UTtrZPfMSSvS+QMVZ7V2/Yr+rJkDYcFEH6P3cRHJA7pMLeGNcmsiWSbT 1etdEzAmcySZuWsbq0PO1lBEf0fycst7e7Tjn9FPyBzrdQAmludCIcyWTDwCSE7c oKKWNFDmcRZtmuiYjG2qPyQpY3xj0OWBXWeau7L/VmW4Fmkz+AuRw0Y7wDACGySI w12/V/ZSvyaNBVlKldRO8WSmYUD3xQ== =1/qX -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 15 04:56:47 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 5C14E120142 for ; Wed, 15 Jan 2020 04:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 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, 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 47lyhSlbu0Rl for ; Wed, 15 Jan 2020 04:56:39 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 9DC631200A3 for ; Wed, 15 Jan 2020 04:56:38 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id c9so15638746wrw.8 for ; Wed, 15 Jan 2020 04:56:38 -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=FyfpJjxoYWH/2LUmV3M8GqCqJERPvrqVFvfJ+0D6/R8=; b=DG4PViMpweJt0tbzRu+Y4Ta3CCADtg6bbngCAzXqcOMipzZ7Fd1Dg2VzFp9pN9qtTC 6WTwFP4bX0WFXfX30PZwoR5VqihyfGbTa1mlhr77CfRD4GnXc4cBl92Y5GUe2YenpeA0 tdPQTaDH0TUNR1c5GXrJkHwHvHB5i+km1zjQP28qBI7WsiRXXTvuOGaIwUMOsJ5hqXZs /UuLbSfm9rVkLiHezzer9JMK2DkwvuqC2FVbeDNOKg3NRVW/U7u2Jg5G9box7dvTuUd/ 16M2B+HfQBgyhgEdY5lBlZL7wnA8bHoT+AEL2buvD+tTzXiOXe6E+35fai9E/qQ3NyJF po7g== 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=FyfpJjxoYWH/2LUmV3M8GqCqJERPvrqVFvfJ+0D6/R8=; b=VR+Hz8THXLagQWiQUdc525laKYNOEcwIWGs/OxZplwO8ZOMD7xIgnnKNXIB3u4rAOX ZdVvHp5UaLR9KCOAyFqOfdIk/oJ4ddoktpzI6FgxWI79v/9KayP8703agNiZ0pHd3lQ9 Dr7m53I0ItRw6/eohou8gi06jhw05FRAq9RTga9mGdO8TVp+JOke6//xgem1e3vk0rfd wR6aLpCwzoipG5o1Ky7vXtI1ZLOiX4AhB/OrG10WYJ0LGDkbBnqER9nUu5Qtm87nYH9i a2B3b2kUo/LhhnRLrWaFXUsReaYjGJH1rcDgWLfAMz+GhGTgB1i9sRMwCWk4Nhwqaupf sAkg== X-Gm-Message-State: APjAAAUiqjqKeUSX/8B+VNP9jXnXCApIAhpmzpr3/RdFQpoCxo5MHZM+ GpbGcCaDTY1x+taxTZNmQi+CZ6jNNSmaAh9qL69qNw== X-Google-Smtp-Source: APXvYqwH05YTAePB/X1XPwTLAP5B0wecO2i5YLJArcEG7nz94V91/aTaTcZYLHdGhdwPB5hl1dFb9dexhmmpO30wRac= X-Received: by 2002:a05:6000:11c5:: with SMTP id i5mr30621197wrx.102.1579092997112; Wed, 15 Jan 2020 04:56:37 -0800 (PST) MIME-Version: 1.0 References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6950.1578939331@localhost> In-Reply-To: <6950.1578939331@localhost> From: Ivaylo Petrov Date: Wed, 15 Jan 2020 13:56:10 +0100 Message-ID: To: Michael Richardson Cc: core , Michel Veillette , Alexey Melnikov , "a@ackl.io" , consultancy Content-Type: multipart/mixed; boundary="000000000000294898059c2d3d93" 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, 15 Jan 2020 12:56:44 -0000 --000000000000294898059c2d3d93 Content-Type: multipart/alternative; boundary="000000000000294895059c2d3d91" --000000000000294895059c2d3d91 Content-Type: text/plain; charset="UTF-8" Hello Michael, Thank you very much for the proposed text! I have applied the changes that you proposed with slight modifications where I felt the need. You can find the proposed version in attachment and the changes here [1]. We are using markdown to build the draft, therefore there is no XML version that you can directly edit, but here you would find the one we are using in case you want to propose further modifications [2]. If the proposed changes are good for you, I will publish -09 right away. Please notice that the change you proposed for sec 6.4.2. seemed out of place there and I modified slightly sec 6.4.1 to address what I believe was your concern. Please let me know if further changes are required. Best regards, Ivaylo [1]: https://github.com/core-wg/yang-cbor/commit/05611792ff852438072bf13e2309c34ba5b8b159 [2]: https://github.com/core-wg/yang-cbor/tree/sid-09 On Mon, Jan 13, 2020 at 7:15 PM Michael Richardson wrote: > > Ivaylo, > In section 6.3.3, you have no allocation for constrained-voucher. > You had given us 2500:2550 --- constrained-voucher-request. > And 2400 -- 2440:2500 --- constrained-voucher. > > I thought that this was going to be in the initial allocation. > Maybe this causes some problem, and we need to do this some other way? > > We can't do an Early Allocation until this is published. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > > --000000000000294895059c2d3d91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Michael,

T= hank you very much for the proposed text! I have applied the changes that y= ou proposed with slight modifications where I felt the need. You can find t= he proposed version in attachment and the changes here [1]. We are using ma= rkdown to build the draft, therefore there is no XML version that you can d= irectly edit, but here you would find the one we are using in case you want= to propose further modifications [2]. If the proposed changes are good for= you, I will publish -09 right away.

Pleas= e notice that the change you proposed for sec=C2=A06.4.2. seemed out of pla= ce there and I modified slightly sec 6.4.1 to address what I believe was yo= ur concern. Please let me know if further=C2=A0changes are required.
<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif;color:#= 0b5394">
Best regards,
Ivaylo

[1]:=C2=A0https://github.com/core= -wg/yang-cbor/commit/05611792ff852438072bf13e2309c34ba5b8b159
[2]:=C2=A0https://github.com/core-wg/yang-cbor/tree/sid-09


<= div dir=3D"ltr">
On Mon, Jan 13, 2020 at 7:15 PM Michael Richardson <mcr+ietf@sandelman.ca> wrot= e:

Ivaylo,
In section 6.3.3, you have no allocation for constrained-voucher.
You had given us 2500:2550 --- constrained-voucher-request.
=C2=A0 =C2=A0 =C2=A0And 2400 -- 2440:2500 --- constrained-voucher.

I thought that this was going to be in the initial allocation.
Maybe this causes some problem, and we need to do this some other way?

We can't do an Early Allocation until this is published.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [




--000000000000294895059c2d3d91-- --000000000000294898059c2d3d93 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_k5fb4w880 CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICBNLiBWZWlsbGV0dGUsIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVHJpbGxpYW50IE5ldHdvcmtzIEluYy4KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBQZWxvdiwgRWQuCkV4cGly ZXM6IEp1bHkgMTgsIDIwMjAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJLiBQ ZXRyb3YsIEVkLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBY2tsaW8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDE1LCAyMDIwCgoKICAgICAgICAgICAg ICAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKQogICAgICAgICAgICAgICAg ICAgICAgICAgZHJhZnQtaWV0Zi1jb3JlLXNpZC0wOQoKQWJzdHJhY3QKCiAgIFlBTkcgU2NoZW1h IEl0ZW0gaURlbnRpZmllcnMgKFNJRCkgYXJlIGdsb2JhbGx5IHVuaXF1ZSA2My1iaXQKICAgdW5z aWduZWQgaW50ZWdlcnMgdXNlZCB0byBpZGVudGlmeSBZQU5HIGl0ZW1zLiAgVGhpcyBkb2N1bWVu dCBkZWZpbmVzCiAgIHRoZSBzZW1hbnRpY3MsIHRoZSByZWdpc3RyYXRpb24sIGFuZCBhc3NpZ25t ZW50IHByb2Nlc3NlcyBvZiBTSURzLgogICBUbyBlbmFibGUgdGhlIGltcGxlbWVudGF0aW9uIG9m IHRoZXNlIHByb2Nlc3NlcywgdGhpcyBkb2N1bWVudCBhbHNvCiAgIGRlZmluZXMgYSBmaWxlIGZv cm1hdCB1c2VkIHRvIHBlcnNpc3QgYW5kIHB1Ymxpc2ggYXNzaWduZWQgU0lEcy4KClN0YXR1cyBv ZiBUaGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwg Y29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4K CiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3Vw cyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURy YWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3Ro ZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdp bGwgZXhwaXJlIG9uIEp1bHkgMTgsIDIwMjAuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmln aHQgKGMpIDIwMjAgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUK ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3Vt ZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFBy b3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHBzOi8vdHJ1c3RlZS5p ZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNh dGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAg Y2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMg d2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFj dGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGlj ZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgoKCgpWZWlsbGV0dGUsIGV0 IGFsLiAgICAgICAgIEV4cGlyZXMgSnVseSAxOCwgMjAyMCAgICAgICAgICAgICAgICAgW1BhZ2Ug MV0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lE KSAgICAgICBKYW51YXJ5IDIwMjAKCgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQg YXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1w bGlmaWVkIEJTRCBMaWNlbnNlLgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rp b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgog ICAyLiAgVGVybWlub2xvZ3kgYW5kIE5vdGF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDMKICAgMy4gICIuc2lkIiBmaWxlIGxpZmVjeWNsZSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgIDQuICAiLnNpZCIgZmlsZSBmb3JtYXQg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICA1LiAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDkKICAgNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgICAgNi4xLiAgUmVnaXN0ZXIgU0lEIEZpbGUgRm9ybWF0 IE1vZHVsZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQogICAgIDYuMi4gIENyZWF0ZSBu ZXcgSUFOQSBSZWdpc3RyeTogIlNJRCBNZWdhLVJhbmdlIiByZWdpc3RyeSAuIC4gLiAgIDkKICAg ICAgIDYuMi4xLiAgU3RydWN0dXJlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA5CiAgICAgICA2LjIuMi4gIEFsbG9jYXRpb24gcG9saWN5IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMAogICAgICAgICA2LjIuMi4xLiAgRmlyc3QgYWxs b2NhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgICAgICAgNi4y LjIuMi4gIENvbnNlY3V0aXZlIGFsbG9jYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDExCiAgICAgICA2LjIuMy4gIEluaXRpYWwgY29udGVudHMgb2YgdGhlIFJlZ2lzdHJ5ICAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMQogICAgIDYuMy4gIENyZWF0ZSBhIG5ldyBJQU5BIFJlZ2lzdHJ5 OiBJRVRGIFNJRCBSYW5nZSBSZWdpc3RyeQogICAgICAgICAgIChtYW5hZ2VkIGJ5IElBTkEpIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTEKICAgICAgIDYuMy4xLiAg U3RydWN0dXJlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEx CiAgICAgICA2LjMuMi4gIEFsbG9jYXRpb24gcG9saWN5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxMQogICAgICAgNi4zLjMuICBJbml0aWFsIGNvbnRlbnRzIG9mIHRoZSBy ZWdpc3RyeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTIKICAgICA2LjQuICBDcmVhdGUgbmV3IElB TkEgUmVnaXN0cnk6ICJJRVRGIFNJRCBSZWdpc3RyeSIgLiAuIC4gLiAuIC4gIDEzCiAgICAgICA2 LjQuMS4gIFN0cnVjdHVyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxNAogICAgICAgNi40LjIuICBBbGxvY2F0aW9uIHBvbGljeSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQKICAgICAgIDYuNC4zLiAgUmVjdXJzaXZlIEFsbG9jYXRp b24gb2YgU0lEIFJhbmdlIGF0IERvY3VtZW50CiAgICAgICAgICAgICAgIEFkb3B0aW9uICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNAogICAgICAgNi40LjQu ICBJbml0aWFsIGNvbnRlbnRzIG9mIHRoZSByZWdpc3RyeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAg MTYKICAgNy4gIEFja25vd2xlZGdtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDE2CiAgIDguICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNgogICAgIDguMS4gIE5vcm1hdGl2ZSBS ZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTYKICAgICA4 LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDE3CiAgIEFwcGVuZGl4IEEuICAiLnNpZCIgZmlsZSBleGFtcGxlICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOAogICBBcHBlbmRpeCBCLiAgU0lEIGF1dG8gZ2VuZXJh dGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjcKICAgQXBwZW5kaXggQy4g ICIuc2lkIiBmaWxlIGxpZmVjeWNsZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI3 CiAgICAgQy4xLiAgU0lEIEZpbGUgQ3JlYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAyOAogICAgIEMuMi4gIFNJRCBGaWxlIFVwZGF0ZSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjkKICAgQXV0aG9ycycgQWRkcmVzc2VzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMwCgoxLiAgSW50 cm9kdWN0aW9uCgogICBTb21lIG9mIHRoZSBpdGVtcyBkZWZpbmVkIGluIFlBTkcgW1JGQzc5NTBd IHJlcXVpcmUgdGhlIHVzZSBvZiBhCiAgIHVuaXF1ZSBpZGVudGlmaWVyLiAgSW4gYm90aCBORVRD T05GIFtSRkM2MjQxXSBhbmQgUkVTVENPTkYgW1JGQzgwNDBdLAogICB0aGVzZSBpZGVudGlmaWVy cyBhcmUgaW1wbGVtZW50ZWQgdXNpbmcgbmFtZXMuICBUbyBhbGxvdyB0aGUKICAgaW1wbGVtZW50 YXRpb24gb2YgZGF0YSBtb2RlbHMgZGVmaW5lZCBpbiBZQU5HIGluIGNvbnN0cmFpbmVkIGRldmlj ZXMKICAgYW5kIGNvbnN0cmFpbmVkIG5ldHdvcmtzLCBhIG1vcmUgY29tcGFjdCBtZXRob2QgdG8g aWRlbnRpZnkgWUFORwogICBpdGVtcyBpcyByZXF1aXJlZC4gIFRoaXMgY29tcGFjdCBpZGVudGlm aWVyLCBjYWxsZWQgU0lELCBpcyBlbmNvZGVkCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICAg RXhwaXJlcyBKdWx5IDE4LCAyMDIwICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0 LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgIEphbnVh cnkgMjAyMAoKCiAgIHVzaW5nIGEgNjMtYml0IHVuc2lnbmVkIGludGVnZXIuICBUaGUgdXNlIG9m IDYzLWJpdCB1bnNpZ25lZCBpbnRlZ2VycwogICBhbGxvd3MgU0lEcyB0byBiZSBtYW5pcHVsYXRl ZCBtb3JlIGVhc2lseSBvbiBhcmNoaXRlY3R1cmVzIHRoYXQgbWlnaHQKICAgb3RoZXJ3aXNlIGxh Y2sgbmF0aXZlIDY0LWJpdCB1bnNpZ25lZCBhcml0aG1ldGljLiAgVGhlIGxvc3MgYSBzaW5nbGUK ICAgYml0IG9mIHByZWNpc2lvbiBpcyBub3Qgc2lnbmlmaWNhbnQgZ2l2ZW4gdGhlIHNpemUgb2Yg dGhlIHNwYWNlLgoKICAgVGhlIGZvbGxvd2luZyBpdGVtcyBhcmUgaWRlbnRpZmllZCB1c2luZyBT SURzOgoKICAgbyAgaWRlbnRpdGllcwoKICAgbyAgZGF0YSBub2RlcyAoTm90ZTogaW5jbHVkaW5n IHRob3NlIHBhcnRzIG9mIGEgWUFORyB0ZW1wbGF0ZSBhcwogICAgICBkZWZpbmVkIGJ5IHRoZSAn eWFuZy1kYXRhJyBleHRlbnNpb24uKQoKICAgbyAgUlBDcyBhbmQgYXNzb2NpYXRlZCBpbnB1dChz KSBhbmQgb3V0cHV0KHMpCgogICBvICBhY3Rpb25zIGFuZCBhc3NvY2lhdGVkIGlucHV0KHMpIGFu ZCBvdXRwdXQocykKCiAgIG8gIG5vdGlmaWNhdGlvbnMgYW5kIGFzc29jaWF0ZWQgaW5mb3JtYXRp b24KCiAgIG8gIFlBTkcgbW9kdWxlcywgc3VibW9kdWxlcyBhbmQgZmVhdHVyZXMKCiAgIFNJRHMg YXJlIGdsb2JhbGx5IHVuaXF1ZSBpbnRlZ2VycywgYSByZWdpc3RyYXRpb24gc3lzdGVtIGlzIHVz ZWQgaW4KICAgb3JkZXIgdG8gZ3VhcmFudGVlIHRoZWlyIHVuaXF1ZW5lc3MuICBTSURzIGFyZSBy ZWdpc3RlcmVkIGluIGJsb2NrcwogICBjYWxsZWQgIlNJRCByYW5nZXMiLgoKICAgQXNzaWdubWVu dCBvZiBTSURzIHRvIFlBTkcgaXRlbXMgY2FuIGJlIGF1dG9tYXRlZC4gIEZvciBtb3JlIGRldGFp bHMKICAgaG93IHRoaXMgY291bGQgYmUgYWNoaWV2ZWQsIHBsZWFzZSBjb25zdWx0IEFwcGVuZGl4 IEIuCgogICBTSURzIGFyZSBhc3NpZ25lZCBwZXJtYW5lbnRseSwgaXRlbXMgaW50cm9kdWNlZCBi eSBhIG5ldyByZXZpc2lvbiBvZgogICBhIFlBTkcgbW9kdWxlIGFyZSBhZGRlZCB0byB0aGUgbGlz dCBvZiBTSURzIGFscmVhZHkgYXNzaWduZWQuCgogICBTZWN0aW9uIDMgcHJvdmlkZXMgbW9yZSBk ZXRhaWxzIGFib3V0IHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBvZgogICBZQU5HIG1vZHVsZXMg YW5kIGFzc29jaWF0ZWQgU0lEcy4gIFRvIGVuYWJsZSB0aGUgaW1wbGVtZW50YXRpb24gb2YKICAg dGhpcyByZWdpc3RyeSwgU2VjdGlvbiA0IGRlZmluZXMgYSBzdGFuZGFyZCBmaWxlIGZvcm1hdCB1 c2VkIHRvIHN0b3JlCiAgIGFuZCBwdWJsaXNoIFNJRHMuCgoyLiAgVGVybWlub2xvZ3kgYW5kIE5v dGF0aW9uCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwg IlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1F TkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kCiAgICJPUFRJT05BTCIgaW4gdGhp cyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIEJDUAogICAx NCBbUkZDMjExOV0gW1JGQzgxNzRdIHdoZW4sIGFuZCBvbmx5IHdoZW4sIHRoZXkgYXBwZWFyIGlu IGFsbAogICBjYXBpdGFscywgYXMgc2hvd24gaGVyZS4KCiAgIFRoZSBmb2xsb3dpbmcgdGVybXMg YXJlIGRlZmluZWQgaW4gW1JGQzc5NTBdOgoKICAgbyAgYWN0aW9uCgogICBvICBmZWF0dXJlCgoK ClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBKdWx5IDE4LCAyMDIwICAgICAgICAg ICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBp RGVudGlmaWVyIChTSUQpICAgICAgIEphbnVhcnkgMjAyMAoKCiAgIG8gIG1vZHVsZQoKICAgbyAg bm90aWZpY2F0aW9uCgogICBvICBSUEMKCiAgIG8gIHNjaGVtYSBub2RlCgogICBvICBzY2hlbWEg dHJlZQoKICAgbyAgc3VibW9kdWxlCgogICBUaGUgZm9sbG93aW5nIHRlcm0gaXMgZGVmaW5lZCBp biBbUkZDODA0MF06CgogICBvICB5YW5nLWRhdGEgZXh0ZW5zaW9uCgogICBUaGlzIHNwZWNpZmlj YXRpb24gYWxzbyBtYWtlcyB1c2Ugb2YgdGhlIGZvbGxvd2luZyB0ZXJtaW5vbG9neToKCiAgIG8g IGl0ZW06IEEgc2NoZW1hIG5vZGUsIGFuIGlkZW50aXR5LCBhIG1vZHVsZSwgYSBzdWJtb2R1bGUg b3IgYQogICAgICBmZWF0dXJlIGRlZmluZWQgdXNpbmcgdGhlIFlBTkcgbW9kZWxpbmcgbGFuZ3Vh Z2UuCgogICBvICBwYXRoOiBBIHBhdGggaXMgYSBzdHJpbmcgdGhhdCBpZGVudGlmaWVzIGEgc2No ZW1hIG5vZGUgd2l0aGluIHRoZQogICAgICBzY2hlbWEgdHJlZS4gIEEgcGF0aCBjb25zaXN0cyBv ZiB0aGUgbGlzdCBvZiBzY2hlbWEgbm9kZQogICAgICBpZGVudGlmaWVyKHMpIHNlcGFyYXRlZCBi eSBzbGFzaGVzICgiLyIpLiAgU2NoZW1hIG5vZGUKICAgICAgaWRlbnRpZmllcihzKSBhcmUgYWx3 YXlzIGxpc3RlZCBmcm9tIHRoZSB0b3AtbGV2ZWwgc2NoZW1hIG5vZGUgdXAKICAgICAgdG8gdGhl IHRhcmdldGVkIHNjaGVtYSBub2RlLiAoZS5nLiAiL2lldGYtc3lzdGVtOnN5c3RlbS0KICAgICAg c3RhdGUvY2xvY2svY3VycmVudC1kYXRldGltZSIpCgogICBvICBZQU5HIFNjaGVtYSBJdGVtIGlE ZW50aWZpZXIgKFNJRCk6IFVuc2lnbmVkIGludGVnZXIgdXNlZCB0bwogICAgICBpZGVudGlmeSBk aWZmZXJlbnQgWUFORyBpdGVtcy4KCjMuICAiLnNpZCIgZmlsZSBsaWZlY3ljbGUKCiAgIFlBTkcg aXMgYSBsYW5ndWFnZSBkZXNpZ25lZCB0byBtb2RlbCBkYXRhIGFjY2Vzc2VkIHVzaW5nIG9uZSBv ZiB0aGUKICAgY29tcGF0aWJsZSBwcm90b2NvbHMgKGUuZy4gIE5FVENPTkYgW1JGQzYyNDFdLCBS RVNDT05GIFtSRkM4MDQwXSBhbmQKICAgQ29SRUNPTkYgW0ktRC5pZXRmLWNvcmUtY29taV0pLiAg QSBZQU5HIG1vZHVsZSBkZWZpbmVzIGhpZXJhcmNoaWVzIG9mCiAgIGRhdGEsIGluY2x1ZGluZyBj b25maWd1cmF0aW9uLCBzdGF0ZSBkYXRhLCBSUENzLCBhY3Rpb25zIGFuZAogICBub3RpZmljYXRp b25zLgoKICAgTWFueSBZQU5HIG1vZHVsZXMgYXJlIG5vdCBjcmVhdGVkIGluIHRoZSBjb250ZXh0 IG9mIGNvbnN0cmFpbmVkCiAgIGFwcGxpY2F0aW9ucy4gIFlBTkcgbW9kdWxlcyBjYW4gYmUgaW1w bGVtZW50ZWQgdXNpbmcgTkVUQ09ORgogICBbUkZDNjI0MV0gb3IgUkVTVENPTkYgW1JGQzgwNDBd IHdpdGhvdXQgdGhlIG5lZWQgdG8gYXNzaWduIFNJRHMuCgogICBBcyBuZWVkZWQsIGF1dGhvcnMg b2YgWUFORyBtb2R1bGVzIGNhbiBhc3NpZ24gU0lEcyB0byB0aGVpciBZQU5HCiAgIG1vZHVsZXMu ICBJbiBvcmRlciB0byBkbyB0aGF0LCB0aGV5IHNob3VsZCBmaXJzdCBvYnRhaW4gYSBTSUQgcmFu Z2UKICAgZnJvbSBhIHJlZ2lzdHJ5IGFuZCB1c2UgdGhhdCByYW5nZSB0byBhc3NpZ24gb3IgZ2Vu ZXJhdGUgU0lEcyB0bwogICBpdGVtcyBvZiB0aGVpciBZQU5HIG1vZHVsZS4gIEZvciBleGFtcGxl IGhvdyB0aGlzIGNvdWxkIGJlIGFjaGlldmVkLAogICBwbGVhc2UgcmVmZXIgdG8gQXBwZW5kaXgg Qy4KCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEp1bHkgMTgsIDIwMjAgICAg ICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJ dGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICAgSmFudWFyeSAyMDIwCgoKICAgUmVnaXN0cmF0aW9u IG9mIHRoZSAuc2lkIGZpbGUgYXNzb2NpYXRlZCB0byBhIFlBTkcgbW9kdWxlIGlzIG9wdGlvbmFs CiAgIGJ1dCByZWNvbW1lbmRlZCB0byBwcm9tb3RlIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBk ZXZpY2VzIGFuZCB0bwogICBhdm9pZCBkdXBsaWNhdGUgYWxsb2NhdGlvbiBvZiBTSURzIHRvIGEg c2luZ2xlIFlBTkcgbW9kdWxlLgogICBEaWZmZXJlbnQgcmVnaXN0cmllcyBtaWdodCBoYXZlIGRp ZmZlcmVudCByZXF1aXJlbWVudHMgZm9yIHRoZQogICByZWdpc3RyYXRpb24gYW5kIHB1YmxpY2F0 aW9uIG9mIHRoZSAiLnNpZCIgZmlsZXMuICBGb3IgZGlhZ3JhbSBvZiBvbmUKICAgb2YgdGhlIHBv c3NpYmlsaXRpZXMsIHBsZWFzZSByZWZlciB0byB0aGUgYWN0aXZpdHkgZGlhZ3JhbSBvbgogICBG aWd1cmUgMSBpbiBBcHBlbmRpeCBDLgoKICAgRWFjaCB0aW1lIGEgWUFORyBtb2R1bGUgb3Igb25l IG9mIGl0cyBpbXBvcnRlZCBtb2R1bGUocykgb3IgaW5jbHVkZWQKICAgc3ViLW1vZHVsZShzKSBp cyB1cGRhdGVkLCB0aGUgIi5zaWQiIGZpbGUgTUFZIG5lZWQgdG8gYmUgdXBkYXRlZC4KICAgVGhp cyB1cGRhdGUgU0hPVUxEIGJlIHBlcmZvcm1lZCB1c2luZyBhbiBhdXRvbWF0ZWQgdG9vbC4KCiAg IElmIGEgbmV3IHJldmlzaW9uIHJlcXVpcmVzIG1vcmUgU0lEcyB0aGFuIGluaXRpYWxseSBhbGxv Y2F0ZWQsIGEgbmV3CiAgIFNJRCByYW5nZSBNVVNUIGJlIGFkZGVkIHRvIHRoZSAnYXNzaWdubWVu dC1yYW5nZXMnIGFzIGRlZmluZWQgaW4KICAgU2VjdGlvbiA0LiAgVGhlc2UgZXh0cmEgU0lEcyBh cmUgdXNlZCBmb3Igc3Vic2VxdWVudCBhc3NpZ25tZW50cy4KCiAgIEZvciBhbiBleGFtcGxlIG9m IHRoaXMgdXBkYXRlIHByb2Nlc3MsIHNlZSBhY3Rpdml0eSBkaWFncmFtIEZpZ3VyZSAyCiAgIGlu IEFwcGVuZGl4IEMuCgo0LiAgIi5zaWQiIGZpbGUgZm9ybWF0CgogICAiLnNpZCIgZmlsZXMgYXJl IHVzZWQgdG8gcGVyc2lzdCBhbmQgcHVibGlzaCBTSURzIGFzc2lnbmVkIHRvIHRoZQogICBkaWZm ZXJlbnQgWUFORyBpdGVtcyBvZiBhIHNwZWNpZmljIFlBTkcgbW9kdWxlLiAgVGhlIGZvbGxvd2lu ZyBZQU5HCiAgIG1vZHVsZSBkZWZpbmVkIHRoZSBzdHJ1Y3R1cmUgb2YgdGhpcyBmaWxlLCBlbmNv ZGluZyBpcyBwZXJmb3JtZWQKICAgdXNpbmcgdGhlIHJ1bGVzIGRlZmluZWQgaW4gW1JGQzc5NTFd LgoKICAgPENPREUgQkVHSU5TPiBmaWxlICJpZXRmLXNpZC1maWxlQDIwMTctMTEtMjYueWFuZyIK ICAgbW9kdWxlIGlldGYtc2lkLWZpbGUgewogICAgIG5hbWVzcGFjZSAidXJuOmlldGY6cGFyYW1z OnhtbDpuczp5YW5nOmlldGYtc2lkLWZpbGUiOwogICAgIHByZWZpeCBzaWQ7CgogICAgIGltcG9y dCBpZXRmLXlhbmctdHlwZXMgewogICAgICAgcHJlZml4IHlhbmc7CiAgICAgfQoKICAgICBvcmdh bml6YXRpb24KICAgICAgICJJRVRGIENvcmUgV29ya2luZyBHcm91cCI7CgogICAgIGNvbnRhY3QK ICAgICAgICJNaWNoZWwgVmVpbGxldHRlCiAgICAgICAgPG1haWx0bzptaWNoZWwudmVpbGxldHRl QHRyaWxsaWFudC5jb20+CgogICAgICAgIEFuZHkgQmllcm1hbgogICAgICAgIDxtYWlsdG86YW5k eUB5dW1hd29ya3MuY29tPgoKICAgICAgICBBbGV4YW5kZXIgUGVsb3YKICAgICAgICA8bWFpbHRv OmFAYWNrbC5pbz4iOwoKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEp1bHkg MTgsIDIwMjAgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZ QU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICAgSmFudWFyeSAyMDIwCgoKICAg ICBkZXNjcmlwdGlvbgogICAgICAgIlRoaXMgbW9kdWxlIGRlZmluZXMgdGhlIHN0cnVjdHVyZSBv ZiB0aGUgLnNpZCBmaWxlcy4KCiAgICAgICAgRWFjaCAuc2lkIGZpbGUgY29udGFpbnMgdGhlIG1h cHBpbmcgYmV0d2VlbiB0aGUgZGlmZmVyZW50CiAgICAgICAgc3RyaW5nIGlkZW50aWZpZXJzIGRl ZmluZWQgYnkgYSBZQU5HIG1vZHVsZSBhbmQgYQogICAgICAgIGNvcnJlc3BvbmRpbmcgbnVtZXJp YyB2YWx1ZSBjYWxsZWQgU0lELiI7CgogICAgIHJldmlzaW9uIDIwMTctMTEtMjYgewogICAgICAg ZGVzY3JpcHRpb24KICAgICAgICAgIkluaXRpYWwgcmV2aXNpb24uIjsKICAgICAgIHJlZmVyZW5j ZQogICAgICAgICAiW0ktRC5pZXRmLWNvcmUtc2lkXSBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZp ZXIgKFNJRCkiOwogICAgIH0KCiAgICAgdHlwZWRlZiByZXZpc2lvbi1pZGVudGlmaWVyIHsKICAg ICAgIHR5cGUgc3RyaW5nIHsKICAgICAgICAgcGF0dGVybiAnXGR7NH0tXGR7Mn0tXGR7Mn0nOwog ICAgICAgfQogICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgIlJlcHJlc2VudHMgYSBkYXRlIGlu IFlZWVktTU0tREQgZm9ybWF0LiI7CiAgICAgfQoKICAgICB0eXBlZGVmIHNpZCB7CiAgICAgICB0 eXBlIHVpbnQ2NDsKICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICJZQU5HIFNjaGVtYSBJdGVt IGlEZW50aWZpZXIiOwogICAgICAgcmVmZXJlbmNlCiAgICAgICAgICJbSS1ELmlldGYtY29yZS1z aWRdIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSI7CiAgICAgfQoKICAgICB0eXBl ZGVmIHNjaGVtYS1ub2RlLXBhdGggewogICAgICAgdHlwZSBzdHJpbmcgewogICAgICAgICBwYXR0 ZXJuCiAgICAgICAgICAgJy9bYS16QS1aX11bYS16QS1aMC05XC1fLl0qOlthLXpBLVpfXVthLXpB LVowLTlcLV8uXSonICsKICAgICAgICAgICAnKC9bYS16QS1aX11bYS16QS1aMC05XC1fLl0qKDpb YS16QS1aX11bYS16QS1aMC05XC1fLl0qKT8pKic7CiAgICAgICB9CiAgICAgICBkZXNjcmlwdGlv bgogICAgICAgICAiSWRlbnRpZmllcyBhIHNjaGVtYS1ub2RlIHBhdGggc3RyaW5nIGZvciB1c2Ug aW4gdGhlCiAgICAgICAgICBTSUQgcmVnaXN0cnkuIFRoaXMgc3RyaW5nIGZvcm1hdCBmb2xsb3dz IHRoZSBydWxlcwogICAgICAgICAgZm9yIGFuIGluc3RhbmNlLWlkZW50aWZpZXIsIGFzIGRlZmlu ZWQgaW4gUkZDIDc5NTksCiAgICAgICAgICBleGNlcHQgdGhhdCBubyBwcmVkaWNhdGVzIGFyZSBh bGxvd2VkLgoKICAgICAgICAgIFRoaXMgZm9ybWF0IGlzIGludGVuZGVkIHRvIHN1cHBvcnQgdGhl IFlBTkcgMS4xIEFCTkYKICAgICAgICAgIGZvciBhIHNjaGVtYSBub2RlIGlkZW50aWZpZXIsIGV4 Y2VwdCBtb2R1bGUgbmFtZXMKICAgICAgICAgIGFyZSB1c2VkIGluc3RlYWQgb2YgcHJlZml4ZXMs IGFzIHNwZWNpZmllZCBpbiBSRkMgNzk1MS4iOwogICAgICAgcmVmZXJlbmNlCiAgICAgICAgICJS RkMgNzk1MCwgVGhlIFlBTkcgMS4xIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2U7CiAgICAgICAgICBT ZWN0aW9uIDYuNTogU2NoZW1hIE5vZGUgSWRlbnRpZmllcjsKCgoKVmVpbGxldHRlLCBldCBhbC4g ICAgICAgICBFeHBpcmVzIEp1bHkgMTgsIDIwMjAgICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwK SW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAg ICAgSmFudWFyeSAyMDIwCgoKICAgICAgICAgIFJGQyA3OTUxLCBKU09OIEVuY29kaW5nIG9mIFlB TkcgRGF0YTsKICAgICAgICAgIFNlY3Rpb24gNi4xMTogVGhlIGluc3RhbmNlLWlkZW50aWZpZXIg dHlwZSI7CiAgICAgfQoKICAgICBsZWFmIG1vZHVsZS1uYW1lIHsKICAgICAgIHR5cGUgeWFuZzp5 YW5nLWlkZW50aWZpZXI7CiAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAiTmFtZSBvZiB0aGUg WUFORyBtb2R1bGUgYXNzb2NpYXRlZCB3aXRoIHRoaXMgLnNpZCBmaWxlLiI7CiAgICAgfQoKICAg ICBsZWFmIG1vZHVsZS1yZXZpc2lvbiB7CiAgICAgICB0eXBlIHJldmlzaW9uLWlkZW50aWZpZXI7 CiAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAiUmV2aXNpb24gb2YgdGhlIFlBTkcgbW9kdWxl IGFzc29jaWF0ZWQgd2l0aCB0aGlzIC5zaWQgZmlsZS4KICAgICAgICAgIFRoaXMgbGVhZiBpcyBu b3QgcHJlc2VudCBpZiBubyByZXZpc2lvbiBzdGF0ZW1lbnQgaXMKICAgICAgICAgIGRlZmluZWQg aW4gdGhlIFlBTkcgbW9kdWxlLiI7CiAgICAgfQoKICAgICBsaXN0IGFzc2lnbWVudC1yYW5nZXMg ewogICAgICAga2V5ICJlbnRyeS1wb2ludCI7CiAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAi U0lEIHJhbmdlKHMpIGFsbG9jYXRlZCB0byB0aGUgWUFORyBtb2R1bGUgaWRlbnRpZmllZCBieQog ICAgICAgICAgJ21vZHVsZS1uYW1lJyBhbmQgJ21vZHVsZS1yZXZpc2lvbicuIjsKCiAgICAgICBs ZWFmIGVudHJ5LXBvaW50IHsKICAgICAgICAgdHlwZSBzaWQ7CiAgICAgICAgIG1hbmRhdG9yeSB0 cnVlOwogICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICJMb3dlc3QgU0lEIGF2YWlsYWJs ZSBmb3IgYXNzaWdubWVudC4iOwogICAgICAgfQoKICAgICAgIGxlYWYgc2l6ZSB7CiAgICAgICAg IHR5cGUgdWludDY0OwogICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAgICAgICAgZGVzY3JpcHRp b24KICAgICAgICAgICAiTnVtYmVyIG9mIFNJRHMgYXZhaWxhYmxlIGZvciBhc3NpZ25tZW50LiI7 CiAgICAgICB9CiAgICAgfQoKICAgICBsaXN0IGl0ZW1zIHsKICAgICAgIGtleSAibmFtZXNwYWNl IGlkZW50aWZpZXIiOwogICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgIkVhY2ggZW50cnkgd2l0 aGluIHRoaXMgbGlzdCBkZWZpbmVkIHRoZSBtYXBwaW5nIGJldHdlZW4KICAgICAgICAgIGEgWUFO RyBpdGVtIHN0cmluZyBpZGVudGlmaWVyIGFuZCBhIFNJRC4gVGhpcyBsaXN0IE1VU1QKICAgICAg ICAgIGluY2x1ZGUgYSBtYXBwaW5nIGVudHJ5IGZvciBlYWNoIFlBTkcgaXRlbSBkZWZpbmVkIGJ5 CiAgICAgICAgICB0aGUgWUFORyBtb2R1bGUgaWRlbnRpZmllZCBieSAnbW9kdWxlLW5hbWUnIGFu ZAogICAgICAgICAgJ21vZHVsZS1yZXZpc2lvbicuIjsKCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAg ICAgICAgRXhwaXJlcyBKdWx5IDE4LCAyMDIwICAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCklu dGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAg IEphbnVhcnkgMjAyMAoKCiAgICAgICBsZWFmIG5hbWVzcGFjZSB7CiAgICAgICAgIHR5cGUgZW51 bWVyYXRpb24gewogICAgICAgICAgIGVudW0gbW9kdWxlIHsKICAgICAgICAgICAgIHZhbHVlIDA7 CiAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAiQWxsIG1vZHVsZSBhbmQg c3VibW9kdWxlIG5hbWVzIHNoYXJlIHRoZSBzYW1lCiAgICAgICAgICAgICAgICBnbG9iYWwgbW9k dWxlIGlkZW50aWZpZXIgbmFtZXNwYWNlLiI7CiAgICAgICAgICAgfQogICAgICAgICAgIGVudW0g aWRlbnRpdHkgewogICAgICAgICAgICAgdmFsdWUgMTsKICAgICAgICAgICAgIGRlc2NyaXB0aW9u CiAgICAgICAgICAgICAgICJBbGwgaWRlbnRpdHkgbmFtZXMgZGVmaW5lZCBpbiBhIG1vZHVsZSBh bmQgaXRzCiAgICAgICAgICAgICAgICBzdWJtb2R1bGVzIHNoYXJlIHRoZSBzYW1lIGlkZW50aXR5 IGlkZW50aWZpZXIKICAgICAgICAgICAgICAgIG5hbWVzcGFjZS4iOwogICAgICAgICAgIH0KICAg ICAgICAgICBlbnVtIGZlYXR1cmUgewogICAgICAgICAgICAgdmFsdWUgMjsKICAgICAgICAgICAg IGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICJBbGwgZmVhdHVyZSBuYW1lcyBkZWZpbmVkIGlu IGEgbW9kdWxlIGFuZCBpdHMKICAgICAgICAgICAgICAgIHN1Ym1vZHVsZXMgc2hhcmUgdGhlIHNh bWUgZmVhdHVyZSBpZGVudGlmaWVyCiAgICAgICAgICAgICAgICBuYW1lc3BhY2UuIjsKICAgICAg ICAgICB9CiAgICAgICAgICAgZW51bSBkYXRhIHsKICAgICAgICAgICAgIHZhbHVlIDM7CiAgICAg ICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAiVGhlIG5hbWVzcGFjZSBmb3IgYWxs IGRhdGEgbm9kZXMsIGFzIGRlZmluZWQgaW4gWUFORy4iOwogICAgICAgICAgIH0KICAgICAgICAg fQogICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICJOYW1lc3BhY2Ugb2YgdGhlIFlBTkcg aXRlbSBmb3IgdGhpcyBtYXBwaW5nIGVudHJ5LiI7CiAgICAgICB9CgogICAgICAgbGVhZiBpZGVu dGlmaWVyIHsKICAgICAgICAgdHlwZSB1bmlvbiB7CiAgICAgICAgICAgdHlwZSB5YW5nOnlhbmct aWRlbnRpZmllcjsKICAgICAgICAgICB0eXBlIHNjaGVtYS1ub2RlLXBhdGg7CiAgICAgICAgIH0K ICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAiU3RyaW5nIGlkZW50aWZpZXIgb2YgdGhl IFlBTkcgaXRlbSBmb3IgdGhpcyBtYXBwaW5nIGVudHJ5LgoKICAgICAgICAgICAgSWYgdGhlIGNv cnJlc3BvbmRpbmcgJ25hbWVzcGFjZScgZmllbGQgaXMgJ21vZHVsZScsCiAgICAgICAgICAgICdm ZWF0dXJlJywgb3IgJ2lkZW50aXR5JywgdGhlbiB0aGlzIGZpZWxkIE1VU1QKICAgICAgICAgICAg Y29udGFpbiBhIHZhbGlkIFlBTkcgaWRlbnRpZmllciBzdHJpbmcuCgogICAgICAgICAgICBJZiB0 aGUgY29ycmVzcG9uZGluZyAnbmFtZXNwYWNlJyBmaWVsZCBpcyAnZGF0YScsCiAgICAgICAgICAg IHRoZW4gdGhpcyBmaWVsZCBNVVNUIGNvbnRhaW4gYSB2YWxpZCBzY2hlbWEgbm9kZQogICAgICAg ICAgICBwYXRoLiI7CiAgICAgICAgfQoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgIEV4cGly ZXMgSnVseSAxOCwgMjAyMCAgICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFm dCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgICBKYW51YXJ5IDIw MjAKCgogICAgICAgbGVhZiBzaWQgewogICAgICAgICB0eXBlIHNpZDsKICAgICAgICAgbWFuZGF0 b3J5IHRydWU7CiAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgIlNJRCBhc3NpZ25lZCB0 byB0aGUgWUFORyBpdGVtIGZvciB0aGlzIG1hcHBpbmcgZW50cnkuIjsKICAgICAgIH0KICAgICB9 CiAgIH0KICAgPENPREUgRU5EUz4KCjUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhp cyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IHR5cGUgb2YgaWRlbnRpZmllciB1c2VkIHRvIGVuY29k ZSBkYXRhCiAgIG1vZGVscyBkZWZpbmVkIGluIFlBTkcgW1JGQzc5NTBdLiAgQXMgc3VjaCwgdGhp cyBpZGVudGlmaWVyIGRvZXMgbm90CiAgIGNvbnRyaWJ1dGUgdG8gYW55IG5ldyBzZWN1cml0eSBp c3N1ZXMgaW4gYWRkaXRpb24gb2YgdGhvc2UgaWRlbnRpZmllZAogICBmb3IgdGhlIHNwZWNpZmlj IHByb3RvY29scyBvciBjb250ZXh0cyBmb3Igd2hpY2ggaXQgaXMgdXNlZC4KCjYuICBJQU5BIENv bnNpZGVyYXRpb25zCgo2LjEuICBSZWdpc3RlciBTSUQgRmlsZSBGb3JtYXQgTW9kdWxlCgogICBU aGlzIGRvY3VtZW50IHJlZ2lzdGVycyBvbmUgWUFORyBtb2R1bGUgaW4gdGhlICJZQU5HIE1vZHVs ZSBOYW1lcyIKICAgcmVnaXN0cnkgW1JGQzYwMjBdOgoKICAgbyAgbmFtZTogaWV0Zi1zaWQtZmls ZQoKICAgbyAgbmFtZXNwYWNlOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1zaWQt ZmlsZQoKICAgbyAgcHJlZml4OiBzaWQKCiAgIG8gIHJlZmVyZW5jZTogW1tUSElTUkZDXV0KCjYu Mi4gIENyZWF0ZSBuZXcgSUFOQSBSZWdpc3RyeTogIlNJRCBNZWdhLVJhbmdlIiByZWdpc3RyeQoK ICAgVGhlIG5hbWUgb2YgdGhpcyByZWdpc3RyeSBpcyAiU0lEIE1lZ2EtUmFuZ2UiLiAgVGhpcyBy ZWdpc3RyeSBpcyB1c2VkCiAgIHRvIHJlY29yZCB0aGUgZGVsZWdhdGlvbiBvZiB0aGUgbWFuYWdl bWVudCBvZiBhIGJsb2NrIG9mIFNJRHMgdG8KICAgdGhpcmQgcGFydGllcyAoc3VjaCBhcyBTRE9z IG9yIHJlZ2lzdHJhcnMpLgoKNi4yLjEuICBTdHJ1Y3R1cmUKCiAgIEVhY2ggZW50cnkgaW4gdGhp cyByZWdpc3RyeSBtdXN0IGluY2x1ZGU6CgogICBvICBUaGUgZW50cnkgcG9pbnQgKGZpcnN0IFNJ RCkgb2YgdGhlIHJlZ2lzdGVyZWQgU0lEIGJsb2NrLgoKICAgbyAgVGhlIHNpemUgb2YgdGhlIHJl Z2lzdGVyZWQgU0lEIGJsb2NrLiAgVGhlIHNpemUgTVVTVCBiZSBvbmUKICAgICAgbWlsbGlvbiAo MSAwMDAgMDAwKSBTSURzLgoKICAgbyAgVGhlIGNvbnRhY3QgaW5mb3JtYXRpb24gb2YgdGhlIHJl cXVlc3Rpbmcgb3JnYW5pemF0aW9uIGluY2x1ZGluZzoKCgoKVmVpbGxldHRlLCBldCBhbC4gICAg ICAgICBFeHBpcmVzIEp1bHkgMTgsIDIwMjAgICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50 ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICAg SmFudWFyeSAyMDIwCgoKICAgICAgKiAgVGhlIHBvbGljeSBvZiBTSUQgcmFuZ2UgYWxsb2NhdGlv bnM6IFB1YmxpYywgUHJpdmF0ZSBvciBCb3RoLgoKICAgICAgKiAgT3JnYW5pemF0aW9uIG5hbWUK CiAgICAgICogIFVSTAoKICAgVGhlIGluZm9ybWF0aW9uIGFzc29jaWF0ZWQgdG8gdGhlIE9yZ2Fu aXphdGlvbiBuYW1lIHNob3VsZCBub3QgYmUKICAgcHVibGljbHkgdmlzaWJsZSBpbiB0aGUgcmVn aXN0cnksIGJ1dCBzaG91bGQgYmUgYXZhaWxhYmxlLiAgVGhpcwogICBpbmZvcm1hdGlvbiBpbmNs dWRlcyBjb250YWN0IGVtYWlsIGFuZCBwaG9uZSBudW1iZXIgYW5kIGNoYW5nZQogICBjb250cm9s bGVyIGVtYWlsIGFuZCBwaG9uZSBudW1iZXIuCgo2LjIuMi4gIEFsbG9jYXRpb24gcG9saWN5Cgog ICBUaGUgSUFOQSBwb2xpY3kgZm9yIGZ1dHVyZSBhZGRpdGlvbnMgdG8gdGhpcyByZWdpc3RyeSBp cyAiRXhwZXJ0CiAgIFJldmlldyIgW1JGQzgxMjZdLgoKICAgQW4gb3JnYW5pemF0aW9uIHJlcXVl c3RpbmcgdG8gbWFuYWdlIGEgU0lEIFJhbmdlIChhbmQgdGh1cyBoYXZlIGFuCiAgIGVudHJ5IGlu IHRoZSBTSUQgTWVnYS1SYW5nZSBSZWdpc3RyeSksIG11c3QgZW5zdXJlIHRoZSBmb2xsb3dpbmcK ICAgY2FwYWNpdGllczoKCiAgIG8gIFRoZSBjYXBhY2l0eSB0byBtYW5hZ2UgYW5kIG9wZXJhdGUg YSBTSUQgUmFuZ2UgUmVnaXN0cnkuICBBIFNJRAogICAgICBSYW5nZSBSZWdpc3RyeSBNVVNUIHBy b3ZpZGUgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBmb3IgYWxsIFNJRAogICAgICBSYW5nZXMg YWxsb2NhdGVkIGJ5IHRoZSBSZWdpc3RyeToKCiAgICAgICogIEVudHJ5IFBvaW50IG9mIGFsbG9j YXRlZCBTSUQgUmFuZ2UKCiAgICAgICogIFNpemUgb2YgYWxsb2NhdGVkIFNJRCBSYW5nZQoKICAg ICAgKiAgVHlwZTogUHVibGljIG9yIFByaXZhdGUKCiAgICAgICAgICsgIFB1YmxpYyBSYW5nZXMg TVVTVCBpbmNsdWRlIGF0IGxlYXN0IGEgcmVmZXJlbmNlIHRvIHRoZSBZQU5HCiAgICAgICAgICAg IG1vZHVsZSBhbmQgIi5zaWQiIGZpbGVzIGZvciB0aGF0IFNJRCBSYW5nZS4KCiAgICAgICAgICsg IFByaXZhdGUgUmFuZ2VzIE1VU1QgYmUgbWFya2VkIGFzICJQcml2YXRlIgoKICAgbyAgQSBQb2xp Y3kgb2YgYWxsb2NhdGlvbiwgd2hpY2ggY2xlYXJseSBpZGVudGlmaWVzIGlmIHRoZSBTSUQgUmFu Z2UKICAgICAgYWxsb2NhdGlvbnMgd291bGQgYmUgUHJpdmF0ZSwgUHVibGljIG9yIEJvdGguCgog ICBvICBUZWNobmljYWwgY2FwYWNpdHkgdG8gZW5zdXJlIHRoZSBzdXN0YWluZWQgb3BlcmF0aW9u IG9mIHRoZQogICAgICByZWdpc3RyeSBmb3IgYSBwZXJpb2Qgb2YgYXQgbGVhc3QgNSB5ZWFycy4g IElmIFByaXZhdGUKICAgICAgUmVnaXN0cmF0aW9ucyBhcmUgYWxsb3dlZCwgdGhlIHBlcmlvZCBt dXN0IGJlIG9mIGF0IGxlYXN0IDEwCiAgICAgIHllYXJzLgoKNi4yLjIuMS4gIEZpcnN0IGFsbG9j YXRpb24KCiAgIEZvciBhIGZpcnN0IGFsbG9jYXRpb24gdG8gYmUgcHJvdmlkZWQsIHRoZSByZXF1 ZXN0aW5nIG9yZ2FuaXphdGlvbgogICBtdXN0IGRlbW9uc3RyYXRlIGEgZnVuY3Rpb25hbCByZWdp c3RyeSBpbmZyYXN0cnVjdHVyZS4KCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICAgRXhwaXJl cyBKdWx5IDE4LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0 ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgIEphbnVhcnkgMjAy MAoKCjYuMi4yLjIuICBDb25zZWN1dGl2ZSBhbGxvY2F0aW9ucwoKICAgT24gc3Vic2VxdWVudCBh bGxvY2F0aW9uIHJlcXVlc3QocyksIHRoZSBvcmdhbml6YXRpb24gbXVzdAogICBkZW1vbnN0cmF0 ZSB0aGUgZXhoYXVzdGlvbiBvZiB0aGUgcHJpb3IgcmFuZ2UuICBUaGVzZSBjb25kaXRpb25zIG5l ZWQKICAgdG8gYmUgYXNzZXJ0ZWQgYnkgdGhlIGFzc2lnbmVkIGV4cGVydChzKS4KCiAgIElmIHRo YXQgZXh0cmEtYWxsb2NhdGlvbiBpcyBkb25lIHdpdGhpbiAzIHllYXJzIGZyb20gdGhlIGxhc3QK ICAgYWxsb2NhdGlvbiwgdGhlIGV4cGVydHMgbmVlZCB0byBkaXNjdXNzIHRoaXMgcmVxdWVzdCBv biB0aGUgQ09SRQogICB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBhbmQgY29uc2Vuc3VzIG5l ZWRzIHRvIGJlIG9idGFpbmVkIGJlZm9yZQogICBhbGxvY2F0aW5nIGEgbmV3IE1lZ2EtUmFuZ2Uu Cgo2LjIuMy4gIEluaXRpYWwgY29udGVudHMgb2YgdGhlIFJlZ2lzdHJ5CgogICBUaGUgaW5pdGlh bCBlbnRyeSBpbiB0aGlzIHJlZ2lzdHJ5IGlzIGFsbG9jYXRlZCB0byBJQU5BOgoKICAgKy0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0rCiAgIHwgRW50cnkgUG9pbnQgfCBTaXplICAgIHwgQWxsb2NhdGlvbiB8IE9yZ2FuaXph dGlvbiBuYW1lIHwgVVJMICAgICAgfAogICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSsKICAgfCAwICAgICAgICAgICB8 IDEwMDAwMDAgfCBQdWJsaWMgICAgIHwgSUFOQSAgICAgICAgICAgICAgfCBpYW5hLm9yZyB8CiAg ICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tKwoKNi4zLiAgQ3JlYXRlIGEgbmV3IElBTkEgUmVnaXN0cnk6IElFVEYgU0lE IFJhbmdlIFJlZ2lzdHJ5IChtYW5hZ2VkIGJ5CiAgICAgIElBTkEpCgo2LjMuMS4gIFN0cnVjdHVy ZQoKICAgRWFjaCBlbnRyeSBpbiB0aGlzIHJlZ2lzdHJ5IG11c3QgaW5jbHVkZToKCiAgIG8gIFRo ZSBTSUQgcmFuZ2UgZW50cnkgcG9pbnQuCgogICBvICBUaGUgU0lEIHJhbmdlIHNpemUuCgogICBv ICBUaGUgWUFORyBtb2R1bGUgbmFtZS4KCiAgIG8gIERvY3VtZW50IHJlZmVyZW5jZS4KCjYuMy4y LiAgQWxsb2NhdGlvbiBwb2xpY3kKCiAgIFRoZSBmaXJzdCBtaWxsaW9uIFNJRHMgYXNzaWduZWQg dG8gSUFOQSBpcyBzdWItZGl2aWRlZCBhcyBmb2xsb3dzOgoKICAgbyAgVGhlIHJhbmdlIG9mIDAg dG8gOTk5IChzaXplIDEwMDApIGlzICJSZXNlcnZlZCIgYXMgZGVmaW5lZCBpbgogICAgICBbUkZD ODEyNl0uCgogICBvICBUaGUgcmFuZ2Ugb2YgMTAwMCB0byA1OSw5OTkgKHNpemUgNTksMDAwKSBp cyByZXNlcnZlZCBmb3IgWUFORwogICAgICBtb2R1bGVzIGRlZmluZWQgaW4gUkZDcy4gIFRoZSBJ QU5BIHBvbGljeSBmb3IgYWRkaXRpb25zIHRvIHRoaXMKICAgICAgcmVnaXN0cnkgaXMgIkV4cGVy dCBSZXZpZXciIFtSRkM4MTI2XS4KCgoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgIEV4cGly ZXMgSnVseSAxOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFm dCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgICBKYW51YXJ5IDIw MjAKCgogICAgICAqICBUaGUgRXhwZXJ0IE1VU1QgdmVyaWZ5IHRoYXQgdGhlIFlBTkcgbW9kdWxl IGZvciB3aGljaCB0aGlzCiAgICAgICAgIGFsbG9jYXRpb24gaXMgbWFkZSBoYXMgYW4gUkZDIChl eGlzdGluZyBSRkMpIE9SIGlzIG9uIHRyYWNrIHRvCiAgICAgICAgIGJlY29tZSBSRkMgKGVhcmx5 IGFsbG9jYXRpb24gd2l0aCBhIHJlcXVlc3QgZnJvbSB0aGUgV0cgY2hhaXJzCiAgICAgICAgIGFz IGRlZmluZWQgYnkgW1JGQzcxMjBdKS4KCiAgIG8gIFRoZSBTSUQgcmFuZ2UgYWxsb2NhdGVkIGZv ciBhIFlBTkcgbW9kdWxlIGNhbiBmb2xsb3cgaW4gb25lIG9mIHRoZQogICAgICBmb3VyIGNhdGVn b3JpZXM6CgogICAgICAqICBTTUFMTCAoNTAgU0lEcykKCiAgICAgICogIE1FRElVTSAoMTAwIFNJ RHMpCgogICAgICAqICBMQVJHRSAoMjUwIFNJRHMpCgogICAgICAqICBDVVNUT00gKHJlcXVlc3Rl ZCBieSB0aGUgWUFORyBtb2R1bGUgYXV0aG9yLCB3aXRoIGEgbWF4aW11bSBvZgogICAgICAgICAx MDAwIFNJRHMpLiAgSW4gYWxsIGNhc2VzLCB0aGUgc2l6ZSBvZiBhIFNJRCByYW5nZSBhc3NpZ25l ZCB0bwogICAgICAgICBhIFlBTkcgbW9kdWxlIHNob3VsZCBiZSBhdCBsZWFzdCAzMyUgYWJvdmUg dGhlIGN1cnJlbnQgbnVtYmVyCiAgICAgICAgIG9mIFlBTkcgaXRlbXMuICBUaGlzIGhlYWRyb29t IGFsbG93cyBhc3NpZ25tZW50IHdpdGhpbiB0aGUgc2FtZQogICAgICAgICByYW5nZSBvZiBuZXcg WUFORyBpdGVtcyBpbnRyb2R1Y2VkIGJ5IHN1YnNlcXVlbnQgcmV2aXNpb25zLiAgQQogICAgICAg ICBsYXJnZXIgU0lEIHJhbmdlIHNpemUgbWF5IGJlIHJlcXVlc3RlZCBieSB0aGUgYXV0aG9ycyBp ZiB0aGlzCiAgICAgICAgIHJlY29tbWVuZGF0aW9uIGlzIGNvbnNpZGVyZWQgaW5zdWZmaWNpZW50 LiAgSXQgaXMgaW1wb3J0YW50IHRvCiAgICAgICAgIG5vdGUgdGhhdCBhbiBhZGRpdGlvbmFsIFNJ RCByYW5nZSBjYW4gYmUgYWxsb2NhdGVkIHRvIGFuCiAgICAgICAgIGV4aXN0aW5nIFlBTkcgbW9k dWxlIGlmIHRoZSBpbml0aWFsIHJhbmdlIGlzIGV4aGF1c3RlZC4KCiAgIG8gIFRoZSByYW5nZSBv ZiA2MCwwMDAgdG8gOTksOTk5IChzaXplIDQwLDAwMClpcyByZXNlcnZlZCBmb3IKICAgICAgZXhw ZXJpbWVudGFsIFlBTkcgbW9kdWxlcy4gIFRoaXMgcmFuZ2UgTVVTVCBOT1QgYmUgdXNlZCBpbgog ICAgICBvcGVyYXRpb25hbCBkZXBsb3ltZW50cyBzaW5jZSB0aGVzZSBTSURzIGFyZSBub3QgZ2xv YmFsbHkgdW5pcXVlCiAgICAgIHdoaWNoIGxpbWl0IHRoZWlyIGludGVyb3BlcmFiaWxpdHkuICBU aGUgSUFOQSBwb2xpY3kgZm9yIHRoaXMKICAgICAgcmFuZ2UgaXMgIkV4cGVyaW1lbnRhbCB1c2Ui IFtSRkM4MTI2XS4KCiAgIG8gIFRoZSByYW5nZSBvZiAxMDAsMDAwIHRvIDk5OSw5OTkgKHNpemUg OTAwLDAwMCkgaXMgIlJlc2VydmVkIiBhcwogICAgICBkZWZpbmVkIGluIFtSRkM4MTI2XS4KCiAg ICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgRW50cnkg UG9pbnQgfCBTaXplICAgIHwgSUFOQSBwb2xpY3kgICAgICB8CiAgICstLS0tLS0tLS0tLS0tKy0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgMCAgICAgICAgICAgfCAxLDAwMCAgIHwg UmVzZXJ2ZWQgICAgICAgICB8CiAgIHwgMSwwMDAgICAgICAgfCA1OSwwMDAgIHwgRXhwZXJ0IFJl dmlldyAgICB8CiAgIHwgNjAsMDAwICAgICAgfCA0MCwwMDAgIHwgRXhwZXJpbWVudGFsIHVzZSB8 CiAgIHwgMTAwLDAwMCAgICAgfCA5MDAsMDAwIHwgUmVzZXJ2ZWQgICAgICAgICB8CiAgICstLS0t LS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0rCgo2LjMuMy4gIEluaXRpYWwg Y29udGVudHMgb2YgdGhlIHJlZ2lzdHJ5CgogICBJbml0aWFsIGVudHJpZXMgaW4gdGhpcyByZWdp c3RyeSBhcmUgYXMgZm9sbG93czoKCgoKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgICBFeHBp cmVzIEp1bHkgMTgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICAgSmFudWFyeSAy MDIwCgoKICAgKy0tLS0tKy0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgRW50IHwgU2l6IHwgTW9kdWxlIG5hbWUgICAgICAg ICAgICAgIHwgRG9jdW1lbnQgcmVmZXJlbmNlICAgICAgICAgfAogICB8IHJ5ICB8IGUgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg fCBQb2kgfCAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgIHwgbnQgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICArLS0tLS0rLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgfCAxMDAgfCAx MDAgfCBpZXRmLWNvbWkgICAgICAgICAgICAgICAgfCBbSS1ELmlldGYtY29yZS1jb21pXSAgICAg ICB8CiAgIHwgMCAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICB8IDExMCB8IDUwICB8IGlldGYteWFuZy10eXBlcyAgICAg ICAgICB8IFtSRkM2OTkxXSAgICAgICAgICAgICAgICAgIHwKICAgfCAwICAgfCAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwg MTE1IHwgNTAgIHwgaWV0Zi1pbmV0LXR5cGVzICAgICAgICAgIHwgW1JGQzY5OTFdICAgICAgICAg ICAgICAgICAgfAogICB8IDAgICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAxMjAgfCA1MCAgfCBpYW5hLWNyeXB0LWhh c2ggICAgICAgICAgfCBbUkZDNzMxN10gICAgICAgICAgICAgICAgICB8CiAgIHwgMCAgIHwgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICB8IDEyNSB8IDUwICB8IGlldGYtbmV0Y29uZi1hY20gICAgICAgICB8IFtSRkM4MzQxXSAg ICAgICAgICAgICAgICAgIHwKICAgfCAwICAgfCAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMTMwIHwgNTAgIHwgaWV0Zi1z aWQtZmlsZSAgICAgICAgICAgIHwgUkZDWFhYWCAgICAgICAgICAgICAgICAgICAgfAogICB8IDAg ICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgfCAxNTAgfCAxMDAgfCBpZXRmLWludGVyZmFjZXMgICAgICAgICAgfCBbUkZD ODM0M10gICAgICAgICAgICAgICAgICB8CiAgIHwgMCAgIHwgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDE2MCB8IDEwMCB8 IGlldGYtaXAgICAgICAgICAgICAgICAgICB8IFtSRkM4MzQ0XSAgICAgICAgICAgICAgICAgIHwK ICAgfCAwICAgfCAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgIHwgMTcwIHwgMTAwIHwgaWV0Zi1zeXN0ZW0gICAgICAgICAgICAg IHwgW1JGQzczMTddICAgICAgICAgICAgICAgICAgfAogICB8IDAgICB8ICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAxODAg fCA0MDAgfCBpYW5hLWlmLXR5cGUgICAgICAgICAgICAgfCBbUkZDNzIyNF0gICAgICAgICAgICAg ICAgICB8CiAgIHwgMCAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfAogICB8IDI0MCB8IDUwICB8IGlldGYtdm91Y2hlciAgICAg ICAgICAgICB8IFtSRkM4MzY2XSAgICAgICAgICAgICAgICAgIHwKICAgfCAwICAgfCAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg IHwgMjQ1IHwgNTAgIHwgaWV0Zi1jb25zdHJhaW5lZC12b3VjaGVyIHwgW0ktRC5pZXRmLWFuaW1h LWNvbnN0cmFpbmUgfAogICB8IDAgICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8 IGQtdm91Y2hlcl0gICAgICAgICAgICAgICAgIHwKICAgfCAyNTAgfCA1MCAgfCBpZXRmLWNvbnN0 cmFpbmVkLSAgICAgICAgfCBbSS1ELmlldGYtYW5pbWEtY29uc3RyYWluZSB8CiAgIHwgMCAgIHwg ICAgIHwgdm91Y2hlci1yZXF1ZXN0ICAgICAgICAgIHwgZC12b3VjaGVyXSAgICAgICAgICAgICAg ICAgfAogICArLS0tLS0rLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgIC8vIFJGQyBFZC46IHJlcGxhY2UgWFhYWCB3aXRoIFJG QyBudW1iZXIgYXNzaWduZWQgdG8gdGhpcyBkcmFmdC4KCiAgIEZvciBhbGxvY2F0aW9uLCBSRkMg cHVibGljYXRpb24gb2YgdGhlIFlBTkcgbW9kdWxlIGlzIHJlcXVpcmVkIGFzIHBlcgogICBbUkZD ODEyNl0uICBUaGUgWUFORyBtb2R1bGUgbXVzdCBiZSByZWdpc3RlcmVkIGluIHRoZSAiWUFORyBt b2R1bGUKICAgTmFtZSIgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBydWxlcyBzcGVjaWZpZWQg aW4gc2VjdGlvbiAxNCBvZgogICBbUkZDNjAyMF0uCgo2LjQuICBDcmVhdGUgbmV3IElBTkEgUmVn aXN0cnk6ICJJRVRGIFNJRCBSZWdpc3RyeSIKCiAgIFRoZSBuYW1lIG9mIHRoaXMgcmVnaXN0cnkg aXMgIklFVEYgU0lEIFJlZ2lzdHJ5Ii4gIFRoaXMgcmVnaXN0cnkgaXMKICAgdXNlZCB0byByZWNv cmQgdGhlIGFsbG9jYXRpb24gb2YgU0lEcyBmb3IgaW5kaXZpZHVhbCBZQU5HIG1vZHVsZQogICBp dGVtcy4KCgoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSnVseSAxOCwgMjAy MCAgICAgICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2No ZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgICBKYW51YXJ5IDIwMjAKCgo2LjQuMS4gIFN0 cnVjdHVyZQoKICAgRWFjaCBlbnRyeSBpbiB0aGlzIHJlZ2lzdHJ5IG11c3QgaW5jbHVkZToKCiAg IG8gIFRoZSBZQU5HIG1vZHVsZSBuYW1lLiAgVGhpcyBtb2R1bGUgbmFtZSBtdXN0IGJlIHByZXNl bnQgaW4gdGhlCiAgICAgICJOYW1lIiBjb2x1bW4gb2YgdGhlICJZQU5HIE1vZHVsZSBOYW1lcyIg cmVnaXN0cnkuCgogICBvICBBIGxpbmsgdG8gdGhlIGFzc29jaWF0ZWQgIi55YW5nIiBmaWxlLiAg VGhpcyBmaWxlIGxpbmsgbXVzdCBiZQogICAgICBwcmVzZW50IGluIHRoZSAiRmlsZSIgY29sdW1u IG9mIHRoZSAiWUFORyBNb2R1bGUgTmFtZXMiIHJlZ2lzdHJ5LgoKICAgbyAgVGhlIGxpbmsgdG8g dGhlICIuc2lkIiBmaWxlIHdoaWNoIGRlZmluZXMgdGhlIGFsbG9jYXRpb24uICBUaGUKICAgICAg Ii5zaWQiIGZpbGUgaXMgc3RvcmVkIGJ5IElBTkEuCgogICBvICBUaGUgbnVtYmVyIG9mIGFjdHVh bGx5IGFsbG9jYXRlZCBTSURzIGluIHRoZSAiLnNpZCIgZmlsZS4KCjYuNC4yLiAgQWxsb2NhdGlv biBwb2xpY3kKCiAgIFRoZSBhbGxvY2F0aW9uIHBvbGljeSBpcyBFeHBlcnQgcmV2aWV3LiAgVGhl IEV4cGVydCBNVVNUIGVuc3VyZSB0aGF0CiAgIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucyBhcmUg bWV0OgoKICAgbyAgVGhlICIuc2lkIiBmaWxlIGhhcyBhIHZhbGlkIHN0cnVjdHVyZToKCiAgICAg ICogIFRoZSAiLnNpZCIgZmlsZSBNVVNUIGJlIGEgdmFsaWQgSlNPTiBmaWxlIGZvbGxvd2luZyB0 aGUKICAgICAgICAgc3RydWN0dXJlIG9mIHRoZSBtb2R1bGUgZGVmaW5lZCBpbiBSRkNYWFhYIChS RkMgRWQ6IHJlcGxhY2UgWFhYCiAgICAgICAgIHdpdGggUkZDIG51bWJlciBhc3NpZ25lZCB0byB0 aGlzIGRyYWZ0KS4KCiAgIG8gIFRoZSAiLnNpZCIgZmlsZSBhbGxvY2F0ZXMgaW5kaXZpZHVhbCBT SURzIE9OTFkgaW4gdGhlIFNJRCBSYW5nZXMKICAgICAgZm9yIHRoaXMgWUFORyBtb2R1bGUgKGFz IGFsbG9jYXRlZCBpbiB0aGUgSUVURiBTSUQgUmFuZ2UKICAgICAgUmVnaXN0cnkpOgoKICAgICAg KiAgQWxsIFNJRHMgaW4gdGhpcyAiLnNpZCIgZmlsZSBNVVNUIGJlIHdpdGhpbiB0aGUgcmFuZ2Vz CiAgICAgICAgIGFsbG9jYXRlZCB0byB0aGlzIFlBTkcgbW9kdWxlIGluIHRoZSAiSUVURiBTSUQg UmFuZ2UgUmVnaXN0cnkiLgoKICAgbyAgSWYgYW5vdGhlciAiLnNpZCIgZmlsZSBoYXMgYWxyZWFk eSBhbGxvY2F0ZWQgU0lEcyBmb3IgdGhpcyBZQU5HCiAgICAgIG1vZHVsZSAoZS5nLiAgZm9yIG9s ZGVyIG9yIG5ld2VyIHZlcnNpb25zIG9mIHRoZSBZQU5HIG1vZHVsZSksIHRoZQogICAgICBZQU5H IGl0ZW1zIGFyZSBhc3NpZ25lZCB0aGUgc2FtZSBTSURzIGFzIGluIHRoZSB0aGUgb3RoZXIgIi5z aWQiCiAgICAgIGZpbGUuCgogICBvICBTSURzIG5ldmVyIGNoYW5nZS4KCjYuNC4zLiAgUmVjdXJz aXZlIEFsbG9jYXRpb24gb2YgU0lEIFJhbmdlIGF0IERvY3VtZW50IEFkb3B0aW9uCgogICBEdWUg dG8gdGhlIGRpZmZpY3VsdHkgaW4gY2hhbmdpbmcgU0lEIHZhbHVlcyBkdXJpbmcgSUVURiBkb2N1 bWVudAogICBwcm9jZXNzaW5nLCBpdCBpcyBleHBlY3RlZCB0aGF0IG1vc3QgZG9jdW1lbnRzIHdp bGwgYXNrIGZvciBTSUQKICAgYWxsb2NhdGlvbnMgdXNpbmcgRWFybHkgQWxsb2NhdGlvbnMgW0JD UDEwMF0uICBUaGUgZGV0YWlscyBvZiB0aGUKICAgRWFybHkgQWxsb2NhdGlvbiBzaG91bGQgYmUg aW5jbHVkZWQgaW4gYW55IFdvcmtpbmcgR3JvdXAgQWRvcHRpb24KICAgY2FsbC4KCgoKClZlaWxs ZXR0ZSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBKdWx5IDE4LCAyMDIwICAgICAgICAgICAgICAg IFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlm aWVyIChTSUQpICAgICAgIEphbnVhcnkgMjAyMAoKCiAgIER1cmluZyB0aGUgZWFybHkgdXNlIG9m IFNJRHMsIG1hbnkgZXhpc3RpbmcsIHByZXZpb3VzbHkgcHVibGlzaGVkCiAgIFlBTkcgbW9kdWxl cyB3aWxsIG5vdCBoYXZlIFNJRCBhbGxvY2F0aW9ucy4gIEZvciBhbiBhbGxvY2F0aW9uIHRvIGJl CiAgIHVzZWZ1bCB0aGUgaW5jbHVkZWQgWUFORyBtb2R1bGVzIG1heSBhbHNvIG5lZWQgdG8gaGF2 ZSBTSUQKICAgYWxsb2NhdGlvbnMgbWFkZS4KCiAgIFRoZSBFeHBlcnQgUmV2aWV3ZXIgd2hvIHBl cmZvcm1zIHRoZSAoRWFybHkpIEFsbG9jYXRpb24gYW5hbHlzaXMgd2lsbAogICBuZWVkIHRvIGdv IHRocm91Z2ggdGhlIGxpc3Qgb2YgaW5jbHVkZWQgWUFORyBtb2R1bGVzIGFuZCBwZXJmb3JtIFNJ RAogICBhbGxvY2F0aW9ucyBmb3IgdGhvc2UgbW9kdWxlcyBhcyB3ZWxsLgoKICAgbyAgSWYgdGhl IGRvY3VtZW50IGlzIGEgcHVibGlzaGVkIFJGQywgdGhlbiB0aGUgYWxsb2NhdGlvbiBvZiBTSURz CiAgICAgIGZvciBpdHMgcmVmZXJlbmNlZCBZQU5HIG1vZHVsZXMgaXMgcGVybWFuZW50LiAgVGhl IEV4cGVydCBSZXZpZXdlcgogICAgICBwcm92aWRlcyB0aGUgZ2VuZXJhdGVkIFNJRCBmaWxlIHRv IElBTkEgZm9yIHJlZ2lzdHJhdGlvbi4gIFRoaXMKICAgICAgcHJvY2VzcyBtYXkgYmUgdGltZSBj b25zdW1pbmcgZHVyaW5nIGEgYm9vdHN0cmFwIHBlcmlvZCAodGhlcmUgYXJlCiAgICAgIG92ZXIg MTAwIFlBTkcgbW9kdWxlcyB0byBkYXRlLCBub25lIG9mIHdoaWNoIGhhdmUgU0lECiAgICAgIGFs bG9jYXRpb25zKSwgYnV0IHNob3VsZCBxdWlldCBkb3duIG9uY2UgbmVlZGVkIGVudHJpZXMgYXJl CiAgICAgIGFsbG9jYXRlZC4KCiAgIG8gIElmIHRoZSBkb2N1bWVudCBpcyBhbiB1bnByb2Nlc3Nl ZCBJbnRlcm5ldC1EcmFmdCBhZG9wdGVkIGluIGEgV0csCiAgICAgIHRoZW4gYW4gRWFybHkgQWxs b2NhdGlvbiBpcyBwZXJmb3JtZWQgZm9yIHRoaXMgZG9jdW1lbnQgYXMgd2VsbC4KICAgICAgRWFy bHkgQWxsb2NhdGlvbnMgcmVxdWlyZSBhcHByb3ZhbCBieSBhbiBJRVNHIEFyZWEgRGlyZWN0b3Iu ICBBbgogICAgICBlYXJseSBhbGxvY2F0aW9uIHdoaWNoIHJlcXVpcmVzIGFkZGl0aW9uYWwgYWxs b2NhdGlvbnMgd2lsbCBsaXN0CiAgICAgIHRoZSBvdGhlciBhbGxvY2F0aW9ucyBpbiBpdCdzIGRl c2NyaXB0aW9uLCBhbmQgd2lsbCBiZSBjcm9zcy0KICAgICAgcG9zdGVkIHRvIHRoZSBhbnkgb3Ro ZXIgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3RzLgoKICAgbyAgQSBZQU5HIG1vZHVsZSB3aGlj aCByZWZlcmVuY2VzIGEgbW9kdWxlIGluIGFuIGRvY3VtZW50IHdoaWNoIGhhcwogICAgICBub3Qg eWV0IGJlZW4gYWRvcHRlZCBieSBhbnkgd29ya2luZyBncm91cCB3aWxsIGJlIHVuYWJsZSB0bwog ICAgICBwZXJmb3JtIGFuIEVhcmx5IEFsbG9jYXRpb24gZm9yIHRoYXQgb3RoZXIgZG9jdW1lbnQg dW50aWwgaXQgaXMKICAgICAgYWRvcHRlZCBieSBhIHdvcmtpbmcgZ3JvdXAuICBBcyBkZXNjcmli ZWQgaW4gW0JDUDEwMF0sIGFuIEFECiAgICAgIFNwb25zb3JlZCBkb2N1bWVudCBhY3RzIGFzIGlm IGl0IGhhZCBhIHdvcmtpbmcgZ3JvdXAuICBUaGUKICAgICAgYXBwcm92aW5nIEFEIG1heSBhbHNv IGV4ZW1wdCBhIGRvY3VtZW50IGZyb20gdGhpcyBwb2xpY3kgYnkKICAgICAgYWdyZWVpbmcgdG8g QUQgU3BvbnNvciB0aGUgZG9jdW1lbnQuCgogICBDcml0aWNhbGx5LCB0aGUgb3JpZ2luYWwgZG9j dW1lbnQgc2hvdWxkIG5ldmVyIGdldCB0aHJvdWdoIHRoZSBJRVRGCiAgIHByb2Nlc3MgYW5kIHRo ZW4gYmUgc3VycHJpc2VkIHRvIGJlIHJlZmVyZW5jaW5nIGEgZG9jdW1lbnQgd2hvc2UKICAgcHJv Z3Jlc3MgaXMgbm90IGNlcnRhaW4uCgogICBBIHByZXZpb3VzbHkgU0lELWFsbG9jYXRlZCBZQU5H IG1vZHVsZSB3aGljaCBjaGFuZ2VzIGl0cyByZWZlcmVuY2VzCiAgIHRvIGluY2x1ZGUgYSBZQU5H IG1vZHVsZSBmb3Igd2hpY2ggdGhlcmUgaXMgbm8gU0lEIGFsbG9jYXRpb24gbmVlZHMKICAgdG8g cmVwZWF0IHRoZSBFYXJseSBBbGxvY2F0aW9uIHByb2Nlc3MuCgogICBFYXJseSBBbGxvY2F0aW9u cyBhcmUgbWFkZSB3aXRoIGEgb25lLXllYXIgcGVyaW9kLCBhZnRlciB3aGljaCB0aGV5CiAgIGFy ZSBleHBpcmVkLiAgW0JDUDEwMF0gaW5kaWNhdGVzIHRoYXQgYXQgbW9zdCBvbmUgcmVuZXdhbCBt YXkgYmUKICAgbWFkZS4gIEZvciB0aGUgU0lEIGFsbG9jYXRpb24gYSBmYXIgbW9yZSBsZW5pZW50 IHN0YW5jZSBpcyBkZXNpcmVkLgoKICAgMS4gIEFuIGV4dGVuc2lvbiBvZiBhIHJlZmVyZW5jaW5n IGRvY3VtZW50cyBFYXJseSBBbGxvY2F0aW9uIHNob3VsZAogICAgICAgdXBkYXRlIGFueSByZWZl cmVuY2VkIEVhcmx5IEFsbG9jYXRpb25zIHRvIGV4cGlyZSBubyBzb29uZXIgdGhhbgogICAgICAg dGhlIHJlZmVyZW5jaW5nIGRvY3VtZW50LgoKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgICBF eHBpcmVzIEp1bHkgMTgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQt RHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICAgSmFudWFy eSAyMDIwCgoKICAgMi4gIFRoZSBbQkNQMTAwXSBtZWNoYW5pc20gYWxsb3dzIHRoZSBJRVNHIHRv IHByb3ZpZGUgYSBzZWNvbmQKICAgICAgIHJlbmV3YWwsIGFuZCBzdWNoIGFuIGV2ZW50IG1heSBw cm9tcHQgc29tZSB0aG91Z2h0IGFib3V0IGhvdyB0aGUKICAgICAgIGNvbGxlY3Rpb24gb2YgZG9j dW1lbnRzIGFyZSBiZWluZyBwcm9jZXNzZWQuCgogICBUaGlzIGlzIGRyaXZlbiBieSB0aGUgdmVy eSBnZW5lcm91cyBzaXplIG9mIHRoZSBTSUQgc3BhY2UgYW5kIHRoZQogICBvZnRlbiBjb21wbGV4 IGFuZCBkZWVwIGRlcGVuZGVuY2llcyBvZiBZQU5HIG1vZHVsZXMuICBPZnRlbiBhIGNvcmUKICAg bW9kdWxlIHdpdGggbWFueSBkZXBlbmRlbmNpZXMgd2lsbCB1bmRlcmdvIGV4dGVuc2l2ZSByZXZp ZXcsIGRlbGF5aW5nCiAgIHRoZSBwdWJsaWNhdGlvbiBvZiBvdGhlciBkb2N1bWVudHMuCgogICBb QkNQMTAwXSBhbHNvIHNheXMKCiAgIE5vdGUgdGhhdCBpZiBhIGRvY3VtZW50IGlzIHN1Ym1pdHRl ZCBmb3IgcmV2aWV3IHRvIHRoZSBJRVNHIGFuZCBhdAogICB0aGUgdGltZSBvZiBzdWJtaXNzaW9u IHNvbWUgZWFybHkgYWxsb2NhdGlvbnMgYXJlIHZhbGlkIChub3QKICAgZXhwaXJlZCksIHRoZXNl IGFsbG9jYXRpb25zIHNob3VsZCBub3QgYmUgZXhwaXJlZCB3aGlsZSB0aGUgZG9jdW1lbnQKICAg aXMgdW5kZXIgSUVTRyBjb25zaWRlcmF0aW9uIG9yIHdhaXRpbmcgaW4gdGhlIFJGQyBFZGl0b3In cyBxdWV1ZQogICBhZnRlciBhcHByb3ZhbCBieSB0aGUgSUVTRy4KCjYuNC40LiAgSW5pdGlhbCBj b250ZW50cyBvZiB0aGUgcmVnaXN0cnkKCiAgIE5vbmUuCgo3LiAgQWNrbm93bGVkZ21lbnRzCgog ICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIEFuZHkgQmllcm1hbiwgQ2Fyc3RlbiBC b3JtYW5uLAogICBNaWNoYWVsIFJpY2hhcmRzb24sIEFiaGluYXYgU29tYXJhanUsIFBldGVyIHZh biBkZXIgU3RvaywgTGF1cmVudAogICBUb3V0YWluIGFuZCBSYW5keSBUdXJuZXIgZm9yIHRoZWly IGhlbHAgZHVyaW5nIHRoZSBkZXZlbG9wbWVudCBvZgogICB0aGlzIGRvY3VtZW50IGFuZCB0aGVp ciB1c2VmdWwgY29tbWVudHMgZHVyaW5nIHRoZSByZXZpZXcgcHJvY2Vzcy4KCjguICBSZWZlcmVu Y2VzCgo4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBT LiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBS ZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LAogICAgICAgICAgICAgIERPSSAx MC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5y ZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoKICAgW1JGQzcxMjBdICBDb3R0b24sIE0uLCAi RWFybHkgSUFOQSBBbGxvY2F0aW9uIG9mIFN0YW5kYXJkcyBUcmFjayBDb2RlCiAgICAgICAgICAg ICAgUG9pbnRzIiwgQkNQIDEwMCwgUkZDIDcxMjAsIERPSSAxMC4xNzQ4Ny9SRkM3MTIwLCBKYW51 YXJ5CiAgICAgICAgICAgICAgMjAxNCwgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v cmZjNzEyMD4uCgogICBbUkZDNzk1MF0gIEJqb3JrbHVuZCwgTS4sIEVkLiwgIlRoZSBZQU5HIDEu MSBEYXRhIE1vZGVsaW5nIExhbmd1YWdlIiwKICAgICAgICAgICAgICBSRkMgNzk1MCwgRE9JIDEw LjE3NDg3L1JGQzc5NTAsIEF1Z3VzdCAyMDE2LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5y ZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc5NTA+LgoKICAgW1JGQzc5NTFdICBMaG90a2EsIEwuLCAi SlNPTiBFbmNvZGluZyBvZiBEYXRhIE1vZGVsZWQgd2l0aCBZQU5HIiwKICAgICAgICAgICAgICBS RkMgNzk1MSwgRE9JIDEwLjE3NDg3L1JGQzc5NTEsIEF1Z3VzdCAyMDE2LAogICAgICAgICAgICAg IDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc5NTE+LgoKCgpWZWlsbGV0dGUs IGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSnVseSAxOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFn ZSAxNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAo U0lEKSAgICAgICBKYW51YXJ5IDIwMjAKCgogICBbUkZDODE3NF0gIExlaWJhLCBCLiwgIkFtYmln dWl0eSBvZiBVcHBlcmNhc2UgdnMgTG93ZXJjYXNlIGluIFJGQwogICAgICAgICAgICAgIDIxMTkg S2V5IFdvcmRzIiwgQkNQIDE0LCBSRkMgODE3NCwgRE9JIDEwLjE3NDg3L1JGQzgxNzQsCiAgICAg ICAgICAgICAgTWF5IDIwMTcsIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgx NzQ+LgoKOC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0ktRC5pZXRmLWFuaW1hLWNv bnN0cmFpbmVkLXZvdWNoZXJdCiAgICAgICAgICAgICAgUmljaGFyZHNvbiwgTS4sIFN0b2ssIFAu LCBhbmQgUC4gS2FtcGFuYWtpcywgIkNvbnN0cmFpbmVkCiAgICAgICAgICAgICAgVm91Y2hlciBB cnRpZmFjdHMgZm9yIEJvb3RzdHJhcHBpbmcgUHJvdG9jb2xzIiwgZHJhZnQtCiAgICAgICAgICAg ICAgaWV0Zi1hbmltYS1jb25zdHJhaW5lZC12b3VjaGVyLTA2ICh3b3JrIGluIHByb2dyZXNzKSwK ICAgICAgICAgICAgICBKYW51YXJ5IDIwMjAuCgogICBbSS1ELmlldGYtY29yZS1jb21pXQogICAg ICAgICAgICAgIFZlaWxsZXR0ZSwgTS4sIFN0b2ssIFAuLCBQZWxvdiwgQS4sIEJpZXJtYW4sIEEu LCBhbmQgSS4KICAgICAgICAgICAgICBQZXRyb3YsICJDb0FQIE1hbmFnZW1lbnQgSW50ZXJmYWNl IiwgZHJhZnQtaWV0Zi1jb3JlLQogICAgICAgICAgICAgIGNvbWktMDggKHdvcmsgaW4gcHJvZ3Jl c3MpLCBTZXB0ZW1iZXIgMjAxOS4KCiAgIFtSRkM2MDIwXSAgQmpvcmtsdW5kLCBNLiwgRWQuLCAi WUFORyAtIEEgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSBmb3IKICAgICAgICAgICAgICB0aGUgTmV0 d29yayBDb25maWd1cmF0aW9uIFByb3RvY29sIChORVRDT05GKSIsIFJGQyA2MDIwLAogICAgICAg ICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM2MDIwLCBPY3RvYmVyIDIwMTAsCiAgICAgICAgICAgICAg PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjAyMD4uCgogICBbUkZDNjI0MV0g IEVubnMsIFIuLCBFZC4sIEJqb3JrbHVuZCwgTS4sIEVkLiwgU2Nob2Vud2FlbGRlciwgSi4sIEVk LiwKICAgICAgICAgICAgICBhbmQgQS4gQmllcm1hbiwgRWQuLCAiTmV0d29yayBDb25maWd1cmF0 aW9uIFByb3RvY29sCiAgICAgICAgICAgICAgKE5FVENPTkYpIiwgUkZDIDYyNDEsIERPSSAxMC4x NzQ4Ny9SRkM2MjQxLCBKdW5lIDIwMTEsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2luZm8vcmZjNjI0MT4uCgogICBbUkZDNjk5MV0gIFNjaG9lbndhZWxkZXIsIEou LCBFZC4sICJDb21tb24gWUFORyBEYXRhIFR5cGVzIiwKICAgICAgICAgICAgICBSRkMgNjk5MSwg RE9JIDEwLjE3NDg3L1JGQzY5OTEsIEp1bHkgMjAxMywKICAgICAgICAgICAgICA8aHR0cHM6Ly93 d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM2OTkxPi4KCiAgIFtSRkM3MjI0XSAgQmpvcmtsdW5k LCBNLiwgIklBTkEgSW50ZXJmYWNlIFR5cGUgWUFORyBNb2R1bGUiLAogICAgICAgICAgICAgIFJG QyA3MjI0LCBET0kgMTAuMTc0ODcvUkZDNzIyNCwgTWF5IDIwMTQsCiAgICAgICAgICAgICAgPGh0 dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzIyND4uCgogICBbUkZDNzMxN10gIEJp ZXJtYW4sIEEuIGFuZCBNLiBCam9ya2x1bmQsICJBIFlBTkcgRGF0YSBNb2RlbCBmb3IKICAgICAg ICAgICAgICBTeXN0ZW0gTWFuYWdlbWVudCIsIFJGQyA3MzE3LCBET0kgMTAuMTc0ODcvUkZDNzMx NywgQXVndXN0CiAgICAgICAgICAgICAgMjAxNCwgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2luZm8vcmZjNzMxNz4uCgogICBbUkZDODA0MF0gIEJpZXJtYW4sIEEuLCBCam9ya2x1bmQsIE0u LCBhbmQgSy4gV2F0c2VuLCAiUkVTVENPTkYKICAgICAgICAgICAgICBQcm90b2NvbCIsIFJGQyA4 MDQwLCBET0kgMTAuMTc0ODcvUkZDODA0MCwgSmFudWFyeSAyMDE3LAogICAgICAgICAgICAgIDxo dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgwNDA+LgoKICAgW1JGQzgxMjZdICBD b3R0b24sIE0uLCBMZWliYSwgQi4sIGFuZCBULiBOYXJ0ZW4sICJHdWlkZWxpbmVzIGZvcgogICAg ICAgICAgICAgIFdyaXRpbmcgYW4gSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3Mi LCBCQ1AgMjYsCiAgICAgICAgICAgICAgUkZDIDgxMjYsIERPSSAxMC4xNzQ4Ny9SRkM4MTI2LCBK dW5lIDIwMTcsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v cmZjODEyNj4uCgoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSnVseSAxOCwg MjAyMCAgICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcg U2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgICBKYW51YXJ5IDIwMjAKCgogICBbUkZD ODM0MV0gIEJpZXJtYW4sIEEuIGFuZCBNLiBCam9ya2x1bmQsICJOZXR3b3JrIENvbmZpZ3VyYXRp b24KICAgICAgICAgICAgICBBY2Nlc3MgQ29udHJvbCBNb2RlbCIsIFNURCA5MSwgUkZDIDgzNDEs CiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzgzNDEsIE1hcmNoIDIwMTgsCiAgICAgICAg ICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODM0MT4uCgogICBbUkZD ODM0M10gIEJqb3JrbHVuZCwgTS4sICJBIFlBTkcgRGF0YSBNb2RlbCBmb3IgSW50ZXJmYWNlCiAg ICAgICAgICAgICAgTWFuYWdlbWVudCIsIFJGQyA4MzQzLCBET0kgMTAuMTc0ODcvUkZDODM0Mywg TWFyY2ggMjAxOCwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmM4MzQzPi4KCiAgIFtSRkM4MzQ0XSAgQmpvcmtsdW5kLCBNLiwgIkEgWUFORyBEYXRhIE1v ZGVsIGZvciBJUCBNYW5hZ2VtZW50IiwKICAgICAgICAgICAgICBSRkMgODM0NCwgRE9JIDEwLjE3 NDg3L1JGQzgzNDQsIE1hcmNoIDIwMTgsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2luZm8vcmZjODM0ND4uCgogICBbUkZDODM2Nl0gIFdhdHNlbiwgSy4sIFJpY2hh cmRzb24sIE0uLCBQcml0aWtpbiwgTS4sIGFuZCBULiBFY2tlcnQsCiAgICAgICAgICAgICAgIkEg Vm91Y2hlciBBcnRpZmFjdCBmb3IgQm9vdHN0cmFwcGluZyBQcm90b2NvbHMiLAogICAgICAgICAg ICAgIFJGQyA4MzY2LCBET0kgMTAuMTc0ODcvUkZDODM2NiwgTWF5IDIwMTgsCiAgICAgICAgICAg ICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODM2Nj4uCgpBcHBlbmRpeCBB LiAgIi5zaWQiIGZpbGUgZXhhbXBsZQoKICAgVGhlIGZvbGxvd2luZyAuc2lkIGZpbGUgKGlldGYt c3lzdGVtQDIwMTQtMDgtMDYuc2lkKSBoYXZlIGJlZW4KICAgZ2VuZXJhdGVkIHVzaW5nIHRoZSBm b2xsb3dpbmcgeWFuZyBtb2R1bGVzOgoKICAgbyAgaWV0Zi1zeXN0ZW1AMjAxNC0wOC0wNi55YW5n CgogICBvICBpZXRmLXlhbmctdHlwZXNAMjAxMy0wNy0xNS55YW5nCgogICBvICBpZXRmLWluZXQt dHlwZXNAMjAxMy0wNy0xNS55YW5nCgogICBvICBpZXRmLW5ldGNvbmYtYWNtQDIwMTItMDItMjIu eWFuZwoKICAgbyAgaWFuYS1jcnlwdC1oYXNoQDIwMTQtMDQtMDQueWFuZwoKICAgewogICAgICJh c3NpZ25tZW50LXJhbmdlcyI6IFsKICAgICAgIHsKICAgICAgICAgImVudHJ5LXBvaW50IjogMTcw MCwKICAgICAgICAgInNpemUiOiAxMDAKICAgICAgIH0KICAgICBdLAogICAgICJtb2R1bGUtbmFt ZSI6ICJpZXRmLXN5c3RlbSIsCiAgICAgIm1vZHVsZS1yZXZpc2lvbiI6ICIyMDE0LTA4LTA2IiwK ICAgICAiaXRlbXMiOiBbCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAibW9kdWxlIiwK ICAgICAgICAgImlkZW50aWZpZXIiOiAiaWV0Zi1zeXN0ZW0iLAogICAgICAgICAic2lkIjogMTcw MAogICAgICAgfSwKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEp1bHkgMTgs IDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5H IFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICAgSmFudWFyeSAyMDIwCgoKICAgICAg IHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJpZGVudGl0eSIsCiAgICAgICAgICJpZGVudGlmaWVy IjogImF1dGhlbnRpY2F0aW9uLW1ldGhvZCIsCiAgICAgICAgICJzaWQiOiAxNzAxCiAgICAgICB9 LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImlkZW50aXR5IiwKICAgICAgICAgImlk ZW50aWZpZXIiOiAibG9jYWwtdXNlcnMiLAogICAgICAgICAic2lkIjogMTcwMgogICAgICAgfSwK ICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJpZGVudGl0eSIsCiAgICAgICAgICJpZGVu dGlmaWVyIjogInJhZGl1cyIsCiAgICAgICAgICJzaWQiOiAxNzAzCiAgICAgICB9LAogICAgICAg ewogICAgICAgICAibmFtZXNwYWNlIjogImlkZW50aXR5IiwKICAgICAgICAgImlkZW50aWZpZXIi OiAicmFkaXVzLWF1dGhlbnRpY2F0aW9uLXR5cGUiLAogICAgICAgICAic2lkIjogMTcwNAogICAg ICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJpZGVudGl0eSIsCiAgICAgICAg ICJpZGVudGlmaWVyIjogInJhZGl1cy1jaGFwIiwKICAgICAgICAgInNpZCI6IDE3MDUKICAgICAg IH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiaWRlbnRpdHkiLAogICAgICAgICAi aWRlbnRpZmllciI6ICJyYWRpdXMtcGFwIiwKICAgICAgICAgInNpZCI6IDE3MDYKICAgICAgIH0s CiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZmVhdHVyZSIsCiAgICAgICAgICJpZGVu dGlmaWVyIjogImF1dGhlbnRpY2F0aW9uIiwKICAgICAgICAgInNpZCI6IDE3MDcKICAgICAgIH0s CiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZmVhdHVyZSIsCiAgICAgICAgICJpZGVu dGlmaWVyIjogImRucy11ZHAtdGNwLXBvcnQiLAogICAgICAgICAic2lkIjogMTcwOAogICAgICAg fSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJmZWF0dXJlIiwKICAgICAgICAgImlk ZW50aWZpZXIiOiAibG9jYWwtdXNlcnMiLAogICAgICAgICAic2lkIjogMTcwOQogICAgICAgfSwK ICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJmZWF0dXJlIiwKICAgICAgICAgImlkZW50 aWZpZXIiOiAibnRwIiwKCgoKVmVpbGxldHRlLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEp1bHkg MTgsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMTldCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZ QU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkgICAgICAgSmFudWFyeSAyMDIwCgoKICAg ICAgICAgInNpZCI6IDE3MTAKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2Ui OiAiZmVhdHVyZSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIm50cC11ZHAtcG9ydCIsCiAgICAg ICAgICJzaWQiOiAxNzExCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjog ImZlYXR1cmUiLAogICAgICAgICAiaWRlbnRpZmllciI6ICJyYWRpdXMiLAogICAgICAgICAic2lk IjogMTcxMgogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJmZWF0dXJl IiwKICAgICAgICAgImlkZW50aWZpZXIiOiAicmFkaXVzLWF1dGhlbnRpY2F0aW9uIiwKICAgICAg ICAgInNpZCI6IDE3MTMKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAi ZmVhdHVyZSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogInRpbWV6b25lLW5hbWUiLAogICAgICAg ICAic2lkIjogMTcxNAogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJk YXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnNldC1jdXJyZW50LWRh dGV0aW1lIiwKICAgICAgICAgInNpZCI6IDE3MTUKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAg ICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3Rl bTpzZXQtY3VycmVudC1kYXRldGltZS8KICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudC1k YXRldGltZSIsCiAgICAgICAgICJzaWQiOiAxNzE2CiAgICAgICB9LAogICAgICAgewogICAgICAg ICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0 ZW06c3lzdGVtIiwKICAgICAgICAgInNpZCI6IDE3MTcKICAgICAgIH0sCiAgICAgICB7CiAgICAg ICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5 c3RlbTpzeXN0ZW0tcmVzdGFydCIsCiAgICAgICAgICJzaWQiOiAxNzE4CiAgICAgICB9LAogICAg ICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6 ICIvaWV0Zi1zeXN0ZW06c3lzdGVtLXNodXRkb3duIiwKICAgICAgICAgInNpZCI6IDE3MTkKICAg ICAgIH0sCgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBKdWx5IDE4LCAyMDIw ICAgICAgICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hl bWEgSXRlbSBpRGVudGlmaWVyIChTSUQpICAgICAgIEphbnVhcnkgMjAyMAoKCiAgICAgICB7CiAg ICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRm LXN5c3RlbTpzeXN0ZW0tc3RhdGUiLAogICAgICAgICAic2lkIjogMTcyMAogICAgICAgfSwKICAg ICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIi OiAiL2lldGYtc3lzdGVtOnN5c3RlbS1zdGF0ZS9jbG9jayIsCiAgICAgICAgICJzaWQiOiAxNzIx CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAg ICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtLXN0YXRlL2Nsb2NrL2Jvb3QtZGF0 ZXRpbWUiLAogICAgICAgICAic2lkIjogMTcyMgogICAgICAgfSwKICAgICAgIHsKICAgICAgICAg Im5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVt OnN5c3RlbS1zdGF0ZS9jbG9jay8KICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudC1kYXRl dGltZSIsCiAgICAgICAgICJzaWQiOiAxNzIzCiAgICAgICB9LAogICAgICAgewogICAgICAgICAi bmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06 c3lzdGVtLXN0YXRlL3BsYXRmb3JtIiwKICAgICAgICAgInNpZCI6IDE3MjQKICAgICAgIH0sCiAg ICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVy IjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0tc3RhdGUvcGxhdGZvcm0vbWFjaGluZSIsCiAgICAgICAg ICJzaWQiOiAxNzI1CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRh dGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtLXN0YXRlL3Bs YXRmb3JtL29zLW5hbWUiLAogICAgICAgICAic2lkIjogMTcyNgogICAgICAgfSwKICAgICAgIHsK ICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2ll dGYtc3lzdGVtOnN5c3RlbS1zdGF0ZS9wbGF0Zm9ybS9vcy1yZWxlYXNlIiwKICAgICAgICAgInNp ZCI6IDE3MjcKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIs CiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0tc3RhdGUvcGxhdGZv cm0vb3MtdmVyc2lvbiIsCiAgICAgICAgICJzaWQiOiAxNzI4CiAgICAgICB9LAogICAgICAgewog ICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAg IEV4cGlyZXMgSnVseSAxOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAyMV0KDApJbnRlcm5l dC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgICBKYW51 YXJ5IDIwMjAKCgogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2F1 dGhlbnRpY2F0aW9uIiwKICAgICAgICAgInNpZCI6IDE3MjkKICAgICAgIH0sCiAgICAgICB7CiAg ICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRm LXN5c3RlbTpzeXN0ZW0vYXV0aGVudGljYXRpb24vdXNlciIsCiAgICAgICAgICJzaWQiOiAxNzMw CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAg ICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2F1dGhlbnRpY2F0aW9uLwogICAg ICAgICAgICAgICAgICAgICAgICB1c2VyLWF1dGhlbnRpY2F0aW9uLW9yZGVyIiwKICAgICAgICAg InNpZCI6IDE3MzEKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0 YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vYXV0aGVudGlj YXRpb24vdXNlci8KICAgICAgICAgICAgICAgICAgICAgICAgYXV0aG9yaXplZC1rZXkiLAogICAg ICAgICAic2lkIjogMTczMgogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6 ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9hdXRo ZW50aWNhdGlvbi91c2VyLwogICAgICAgICAgICAgICAgICAgICAgICBhdXRob3JpemVkLWtleS9h bGdvcml0aG0iLAogICAgICAgICAic2lkIjogMTczMwogICAgICAgfSwKICAgICAgIHsKICAgICAg ICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lz dGVtOnN5c3RlbS9hdXRoZW50aWNhdGlvbi91c2VyLwogICAgICAgICAgICAgICAgICAgICAgICBh dXRob3JpemVkLWtleS9rZXktZGF0YSIsCiAgICAgICAgICJzaWQiOiAxNzM0CiAgICAgICB9LAog ICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmll ciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2F1dGhlbnRpY2F0aW9uL3VzZXIvCiAgICAgICAgICAg ICAgICAgICAgICAgIGF1dGhvcml6ZWQta2V5L25hbWUiLAogICAgICAgICAic2lkIjogMTczNQog ICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAg ImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9hdXRoZW50aWNhdGlvbi91c2VyLwog ICAgICAgICAgICAgICAgICAgICAgICBuYW1lIiwKICAgICAgICAgInNpZCI6IDE3MzYKICAgICAg IH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVu dGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vYXV0aGVudGljYXRpb24vdXNlci8KICAgICAg ICAgICAgICAgICAgICAgICAgcGFzc3dvcmQiLAoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAg IEV4cGlyZXMgSnVseSAxOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAyMl0KDApJbnRlcm5l dC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgICBKYW51 YXJ5IDIwMjAKCgogICAgICAgICAic2lkIjogMTczNwogICAgICAgfSwKICAgICAgIHsKICAgICAg ICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lz dGVtOnN5c3RlbS9jbG9jayIsCiAgICAgICAgICJzaWQiOiAxNzM4CiAgICAgICB9LAogICAgICAg ewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIv aWV0Zi1zeXN0ZW06c3lzdGVtL2Nsb2NrL3RpbWV6b25lLW5hbWUiLAogICAgICAgICAic2lkIjog MTczOQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAg ICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9jbG9jay90aW1lem9uZS11 dGMtb2Zmc2V0IiwKICAgICAgICAgInNpZCI6IDE3NDAKICAgICAgIH0sCiAgICAgICB7CiAgICAg ICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5 c3RlbTpzeXN0ZW0vY29udGFjdCIsCiAgICAgICAgICJzaWQiOiAxNzQxCiAgICAgICB9LAogICAg ICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6 ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2Rucy1yZXNvbHZlciIsCiAgICAgICAgICJzaWQiOiAxNzQy CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAg ICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2Rucy1yZXNvbHZlci9vcHRpb25z IiwKICAgICAgICAgInNpZCI6IDE3NDMKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1l c3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0 ZW0vZG5zLXJlc29sdmVyL29wdGlvbnMvCiAgICAgICAgICAgICAgICAgICAgICAgIGF0dGVtcHRz IiwKICAgICAgICAgInNpZCI6IDE3NDQKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1l c3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0 ZW0vZG5zLXJlc29sdmVyL29wdGlvbnMvCiAgICAgICAgICAgICAgICAgICAgICAgIHRpbWVvdXQi LAogICAgICAgICAic2lkIjogMTc0NQogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVz cGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3Rl bS9kbnMtcmVzb2x2ZXIvc2VhcmNoIiwKICAgICAgICAgInNpZCI6IDE3NDYKCgoKVmVpbGxldHRl LCBldCBhbC4gICAgICAgICBFeHBpcmVzIEp1bHkgMTgsIDIwMjAgICAgICAgICAgICAgICAgW1Bh Z2UgMjNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIg KFNJRCkgICAgICAgSmFudWFyeSAyMDIwCgoKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJu YW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpz eXN0ZW0vZG5zLXJlc29sdmVyL3NlcnZlciIsCiAgICAgICAgICJzaWQiOiAxNzQ3CiAgICAgICB9 LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRp ZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2Rucy1yZXNvbHZlci9zZXJ2ZXIvbmFtZSIsCiAg ICAgICAgICJzaWQiOiAxNzQ4CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNl IjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2Ru cy1yZXNvbHZlci9zZXJ2ZXIvCiAgICAgICAgICAgICAgICAgICAgICAgIHVkcC1hbmQtdGNwIiwK ICAgICAgICAgInNpZCI6IDE3NDkKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3Bh Y2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0v ZG5zLXJlc29sdmVyL3NlcnZlci8KICAgICAgICAgICAgICAgICAgICAgICAgdWRwLWFuZC10Y3Av YWRkcmVzcyIsCiAgICAgICAgICJzaWQiOiAxNzUwCiAgICAgICB9LAogICAgICAgewogICAgICAg ICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0 ZW06c3lzdGVtL2Rucy1yZXNvbHZlci9zZXJ2ZXIvCiAgICAgICAgICAgICAgICAgICAgICAgIHVk cC1hbmQtdGNwL3BvcnQiLAogICAgICAgICAic2lkIjogMTc1MQogICAgICAgfSwKICAgICAgIHsK ICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2ll dGYtc3lzdGVtOnN5c3RlbS9ob3N0bmFtZSIsCiAgICAgICAgICJzaWQiOiAxNzUyCiAgICAgICB9 LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRp ZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL2xvY2F0aW9uIiwKICAgICAgICAgInNpZCI6IDE3 NTMKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAg ICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vbnRwIiwKICAgICAgICAgInNp ZCI6IDE3NTQKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIs CiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vbnRwL2VuYWJsZWQi LAogICAgICAgICAic2lkIjogMTc1NQoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgIEV4cGly ZXMgSnVseSAxOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAyNF0KDApJbnRlcm5ldC1EcmFm dCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgICBKYW51YXJ5IDIw MjAKCgogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAg ICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9udHAvc2VydmVyIiwKICAg ICAgICAgInNpZCI6IDE3NTYKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2Ui OiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vbnRw L3NlcnZlci8KICAgICAgICAgICAgICAgICAgICAgICAgYXNzb2NpYXRpb24tdHlwZSIsCiAgICAg ICAgICJzaWQiOiAxNzU3CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjog ImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL250cC9z ZXJ2ZXIvaWJ1cnN0IiwKICAgICAgICAgInNpZCI6IDE3NTgKICAgICAgIH0sCiAgICAgICB7CiAg ICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRm LXN5c3RlbTpzeXN0ZW0vbnRwL3NlcnZlci9uYW1lIiwKICAgICAgICAgInNpZCI6IDE3NTkKICAg ICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJp ZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vbnRwL3NlcnZlci9wcmVmZXIiLAogICAg ICAgICAic2lkIjogMTc2MAogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6 ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9udHAv c2VydmVyL3VkcCIsCiAgICAgICAgICJzaWQiOiAxNzYxCiAgICAgICB9LAogICAgICAgewogICAg ICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1z eXN0ZW06c3lzdGVtL250cC9zZXJ2ZXIvdWRwL2FkZHJlc3MiLAogICAgICAgICAic2lkIjogMTc2 MgogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAg ICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5c3RlbS9udHAvc2VydmVyL3VkcC9wb3J0 IiwKICAgICAgICAgInNpZCI6IDE3NjMKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAgICJuYW1l c3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0 ZW0vcmFkaXVzIiwKICAgICAgICAgInNpZCI6IDE3NjQKICAgICAgIH0sCiAgICAgICB7CgoKClZl aWxsZXR0ZSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBKdWx5IDE4LCAyMDIwICAgICAgICAgICAg ICAgIFtQYWdlIDI1XQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVu dGlmaWVyIChTSUQpICAgICAgIEphbnVhcnkgMjAyMAoKCiAgICAgICAgICJuYW1lc3BhY2UiOiAi ZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vcmFkaXVz L29wdGlvbnMiLAogICAgICAgICAic2lkIjogMTc2NQogICAgICAgfSwKICAgICAgIHsKICAgICAg ICAgIm5hbWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lz dGVtOnN5c3RlbS9yYWRpdXMvb3B0aW9ucy9hdHRlbXB0cyIsCiAgICAgICAgICJzaWQiOiAxNzY2 CiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAg ICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL3JhZGl1cy9vcHRpb25zL3RpbWVv dXQiLAogICAgICAgICAic2lkIjogMTc2NwogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5h bWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5 c3RlbS9yYWRpdXMvc2VydmVyIiwKICAgICAgICAgInNpZCI6IDE3NjgKICAgICAgIH0sCiAgICAg ICB7CiAgICAgICAgICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjog Ii9pZXRmLXN5c3RlbTpzeXN0ZW0vcmFkaXVzL3NlcnZlci8KICAgICAgICAgICAgICAgICAgICAg ICAgYXV0aGVudGljYXRpb24tdHlwZSIsCiAgICAgICAgICJzaWQiOiAxNzY5CiAgICAgICB9LAog ICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLAogICAgICAgICAiaWRlbnRpZmll ciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL3JhZGl1cy9zZXJ2ZXIvbmFtZSIsCiAgICAgICAgICJz aWQiOiAxNzcwCiAgICAgICB9LAogICAgICAgewogICAgICAgICAibmFtZXNwYWNlIjogImRhdGEi LAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL3JhZGl1cy9zZXJ2 ZXIvdWRwIiwKICAgICAgICAgInNpZCI6IDE3NzEKICAgICAgIH0sCiAgICAgICB7CiAgICAgICAg ICJuYW1lc3BhY2UiOiAiZGF0YSIsCiAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3Rl bTpzeXN0ZW0vcmFkaXVzL3NlcnZlci91ZHAvCiAgICAgICAgICAgICAgICAgICAgICAgIGFkZHJl c3MiLAogICAgICAgICAic2lkIjogMTc3MgogICAgICAgfSwKICAgICAgIHsKICAgICAgICAgIm5h bWVzcGFjZSI6ICJkYXRhIiwKICAgICAgICAgImlkZW50aWZpZXIiOiAiL2lldGYtc3lzdGVtOnN5 c3RlbS9yYWRpdXMvc2VydmVyL3VkcC8KICAgICAgICAgICAgICAgICAgICAgICAgYXV0aGVudGlj YXRpb24tcG9ydCIsCiAgICAgICAgICJzaWQiOiAxNzczCiAgICAgICB9LAogICAgICAgewoKCgpW ZWlsbGV0dGUsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSnVseSAxOCwgMjAyMCAgICAgICAgICAg ICAgICBbUGFnZSAyNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURl bnRpZmllciAoU0lEKSAgICAgICBKYW51YXJ5IDIwMjAKCgogICAgICAgICAibmFtZXNwYWNlIjog ImRhdGEiLAogICAgICAgICAiaWRlbnRpZmllciI6ICIvaWV0Zi1zeXN0ZW06c3lzdGVtL3JhZGl1 cy9zZXJ2ZXIvdWRwLwogICAgICAgICAgICAgICAgICAgICAgICBzaGFyZWQtc2VjcmV0IiwKICAg ICAgICAgInNpZCI6IDE3NzQKICAgICAgIH0KICAgICBdCiAgIH0KCkFwcGVuZGl4IEIuICBTSUQg YXV0byBnZW5lcmF0aW9uCgogICBBc3NpZ25tZW50IG9mIFNJRHMgdG8gWUFORyBpdGVtcyBjYW4g YmUgYXV0b21hdGVkLCB0aGUgcmVjb21tZW5kZWQKICAgcHJvY2VzcyB0byBhc3NpZ24gU0lEcyBp cyBhcyBmb2xsb3dzOgoKICAgMS4gIEEgdG9vbCBleHRyYWN0cyB0aGUgZGlmZmVyZW50IGl0ZW1z IGRlZmluZWQgZm9yIGEgc3BlY2lmaWMgWUFORwogICAgICAgbW9kdWxlLgoKICAgMi4gIFRoZSBs aXN0IG9mIGl0ZW1zIGlzIHNvcnRlZCBpbiBhbHBoYWJldGljYWwgb3JkZXIsICduYW1lc3BhY2Un IGluCiAgICAgICBkZXNjZW5kaW5nIG9yZGVyLCAnaWRlbnRpZmllcicgaW4gYXNjZW5kaW5nIG9y ZGVyLiAgVGhlCiAgICAgICAnbmFtZXNwYWNlJyBhbmQgJ2lkZW50aWZpZXInIGZvcm1hdHMgYXJl IGRlc2NyaWJlZCBpbiB0aGUgWUFORwogICAgICAgbW9kdWxlICdpZXRmLXNpZC1maWxlJyBkZWZp bmVkIGluIFNlY3Rpb24gNC4KCiAgIDMuICBTSURzIGFyZSBhc3NpZ25lZCBzZXF1ZW50aWFsbHkg ZnJvbSB0aGUgZW50cnkgcG9pbnQgdXAgdG8gdGhlCiAgICAgICBzaXplIG9mIHRoZSByZWdpc3Rl cmVkIFNJRCByYW5nZS4gIFRoaXMgYXBwcm9hY2ggaXMgcmVjb21tZW5kZWQKICAgICAgIHRvIG1p bmltaXplIHRoZSBzZXJpYWxpemF0aW9uIG92ZXJoZWFkLCBlc3BlY2lhbGx5IHdoZW4gZGVsdGEK ICAgICAgIGJldHdlZW4gYSByZWZlcmVuY2UgU0lEIGFuZCB0aGUgY3VycmVudCBTSUQgaXMgdXNl ZCBieSBwcm90b2NvbHMKICAgICAgIGFpbWluZyB0byByZWR1Y2UgbWVzc2FnZSBzaXplLgoKICAg NC4gIElmIHRoZSBudW1iZXIgb2YgaXRlbXMgZXhjZWVkcyB0aGUgU0lEIHJhbmdlKHMpIGFsbG9j YXRlZCB0byBhCiAgICAgICBZQU5HIG1vZHVsZSwgYW4gZXh0cmEgcmFuZ2UgaXMgYWRkZWQgZm9y IHN1YnNlcXVlbnQgYXNzaWdubWVudHMuCgogICBDaGFuZ2VzIG9mIFNJRCBmaWxlcyBjYW4gYWxz byBiZSBhdXRvbWF0ZWQgdXNpbmcgdGhlIHNhbWUgbWV0aG9kCiAgIGRlc2NyaWJlZCBhYm92ZSwg b25seSB1bmFzc2lnbmVkIFlBTkcgaXRlbXMgYXJlIHByb2Nlc3NlZCBhdCBzdGVwICMzLgogICBB bHJlYWR5IGV4aXN0aW5nIGl0ZW1zIGluIHRoZSBTSUQgZmlsZSBzaG91bGQgbm90IGJlIGdpdmVu IG5ldyBTSURzLgoKQXBwZW5kaXggQy4gICIuc2lkIiBmaWxlIGxpZmVjeWNsZQoKICAgQmVmb3Jl IGFzc2lnbmluZyBTSURzIHRvIHRoZWlyIFlBTkcgbW9kdWxlcywgWUFORyBtb2R1bGUgYXV0aG9y cyBtdXN0CiAgIGFjcXVpcmUgYSBTSUQgcmFuZ2UgZnJvbSBhICJTSUQgUmFuZ2UgUmVnaXN0cnki LiAgSWYgdGhlIFlBTkcgbW9kdWxlCiAgIGlzIHBhcnQgb2YgYW4gSUVURiBkcmFmdCBvciBSRkMs IHRoZSBTSUQgcmFuZ2UgbmVlZCB0byBiZSBhY3F1aXJlZAogICBmcm9tIHRoZSAiSUVURiBTSUQg UmFuZ2UgUmVnaXN0cnkiIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA2LjMuICBGb3IKICAgdGhlIG90 aGVyIFlBTkcgbW9kdWxlcywgdGhlIGF1dGhvcnMgY2FuIGFjcXVpcmUgYSBTSUQgcmFuZ2UgZnJv bSBhbnkKICAgIlNJRCBSYW5nZSBSZWdpc3RyeSIgb2YgdGhlaXIgY2hvaWNlLgoKICAgT25jZSB0 aGUgU0lEIHJhbmdlIGlzIGFjcXVpcmVkLCB0aGUgb3duZXIgY2FuIHVzZSBpdCB0byBnZW5lcmF0 ZQogICAiLnNpZCIgZmlsZS9zIGZvciBoaXMgWUFORyBtb2R1bGUvcy4gIEl0IGlzIHJlY29tbWVu ZGVkIHRvIGxlYXZlIHNvbWUKICAgdW5hbGxvY2F0ZWQgU0lEcyBmb2xsb3dpbmcgdGhlIGFsbG9j YXRlZCByYW5nZSBpbiBlYWNoICIuc2lkIiBmaWxlIGluCiAgIG9yZGVyIHRvIGFsbG93IGJldHRl ciBldm9sdXRpb24gb2YgdGhlIFlBTkcgbW9kdWxlIGluIHRoZSBmdXR1cmUuCiAgIEdlbmVyYXRp b24gb2YgIi5zaWQiIGZpbGVzIHNob3VsZCBiZSBwZXJmb3JtZWQgdXNpbmcgYW4gYXV0b21hdGVk CgoKClZlaWxsZXR0ZSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBKdWx5IDE4LCAyMDIwICAgICAg ICAgICAgICAgIFtQYWdlIDI3XQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRl bSBpRGVudGlmaWVyIChTSUQpICAgICAgIEphbnVhcnkgMjAyMAoKCiAgIHRvb2wuICBOb3RlIHRo YXQgIi5zaWQiIGZpbGVzIGNhbiBvbmx5IGJlIGdlbmVyYXRlZCBmb3IgWUFORyBtb2R1bGVzCiAg IGFuZCBub3QgZm9yIHN1Ym1vZHVsZXMuCgpDLjEuICBTSUQgRmlsZSBDcmVhdGlvbgoKICAgVGhl IGZvbGxvd2luZyBhY3Rpdml0eSBkaWFncmFtIHN1bW1hcml6ZXMgdGhlIGNyZWF0aW9uIG9mIGEg WUFORwogICBtb2R1bGUgYW5kIGl0cyBhc3NvY2lhdGVkIC5zaWQgZmlsZS4KCiAgICAgICArLS0t LS0tLS0tLS0tLS0tKwogIE8gICAgfCBDcmVhdGlvbiBvZiBhIHwKIC18LSAtPnwgWUFORyBtb2R1 bGUgICB8CiAvIFwgICArLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICB8CiAgICAgICAg ICAgICAgIFYKICAgICAgICAvLS0tLS0tLS0tLS0tLVwKICAgICAgIC8gU3RhbmRhcmRpemVkICBc ICAgICB5ZXMKICAgICAgIFwgWUFORyBtb2R1bGUgPyAvLS0tLS0tLS0tLS0tLSsKICAgICAgICBc LS0tLS0tLS0tLS0tLS8gICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgfCBubyAgICAgICAg ICAgICAgICAgIHwKICAgICAgICAgICAgICAgViAgICAgICAgICAgICAgICAgICAgIFYKICAgICAg ICAvLS0tLS0tLS0tLS0tLVwgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAgICAgLyBDb25zdHJh aW5lZCAgIFwgeWVzIHwgU0lEIHJhbmdlICAgICB8CiAgICstLT5cIGFwcGxpY2F0aW9uID8gLy0t LS0+fCByZWdpc3RyYXRpb24gIHw8LS0tLS0tLS0tLSsKICAgfCAgICBcLS0tLS0tLS0tLS0tLS8g ICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgfAogICB8ICAgICAgICAgICB8IG5vICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgIFYgICAg ICAgICAgICAgICAgICAgICBWICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICstLS0tLS0tLS0t LS0tLS0rICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgfAogICArLS0tfCBZQU5HIG1v ZHVsZSAgIHwgICAgIHwgU0lEIHN1Yi1yYW5nZSB8ICAgICAgICAgICB8CiAgICAgICB8IHVwZGF0 ZSAgICAgICAgfCAgICAgfCBhc3NpZ25tZW50ICAgIHw8LS0tLS0tLS0tLSsKICAgICAgICstLS0t LS0tLS0tLS0tLS0rICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgfAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWICAgICAgICAgICAgICAgICAgIHwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICArLS0tLS0tLS0tLS0t LSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IC5zaWQgZmlsZSAgICAgfCAgICB8IFJl d29yayBZQU5HIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IGdlbmVyYXRpb24gICAg fCAgICB8ICAgIG1vZGVsICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tKyAgICArLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgXgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgViAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLy0tLS0tLS0tLS1cICB5ZXMgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC8gIFdvcmsgaW4gICBcIC0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgXCAgcHJvZ3Jlc3MgIC8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBcLS0tLS0tLS0tLS8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgbm8K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFYKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC8tLS0tLS0tLS0tLS0tXCAgICAgICAvLS0tLS0tLS0tLS0tLVwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLyAgICAgIFJGQyAgICAgIFwgbm8gIC8gICAgIE9wZW4g ICAgICBcIG5vCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwgIHB1YmxpY2F0aW9uPyAv LS0tLT5cIHNwZWNpZmljYXRpb24/Ly0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFwtLS0tLS0tLS0tLS0tLyAgICAgICBcLS0tLS0tLS0tLS0tLS8gICAgfAoKCgpWZWlsbGV0dGUs IGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSnVseSAxOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFn ZSAyOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAo U0lEKSAgICAgICBKYW51YXJ5IDIwMjAKCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgeWVzICAgICAgICAgICAgICAgICB8IHllcyAgICAgICB8CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgKy0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWICAgICBWICAgICAgICAg ICAgICAgICAgICAgICAgICAgVgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgSUFOQSAgICAgIHwgICAgICAgICAgICAgICAgIHwgVGhp cmQgcGFydHkgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgcmVnaXN0cmF0aW9u ICB8ICAgICAgICAgICAgICAgICB8IHJlZ2lzdHJhdGlvbiAgfAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLSstLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0tLS0rLS0t LS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbRE9ORV0KCiAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IFNJRCBMaWZlY3lj bGUKCkMuMi4gIFNJRCBGaWxlIFVwZGF0ZQoKICAgVGhlIGZvbGxvd2luZyBBY3Rpdml0eSBkaWFn cmFtIHN1bW1hcml6ZXMgdGhlIHVwZGF0ZSBvZiBhIFlBTkcgbW9kdWxlCiAgIGFuZCBpdHMgYXNz b2NpYXRlZCAuc2lkIGZpbGUuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClZlaWxs ZXR0ZSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBKdWx5IDE4LCAyMDIwICAgICAgICAgICAgICAg IFtQYWdlIDI5XQoMCkludGVybmV0LURyYWZ0ICAgICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlm aWVyIChTSUQpICAgICAgIEphbnVhcnkgMjAyMAoKCiAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t KwogICAgIE8gICAgfCBVcGRhdGUgb2YgdGhlIHwKICAgIC18LSAtPnwgWUFORyBtb2R1bGUgICB8 CiAgICAvIFwgICB8IG9yIGluY2x1ZGUocykgfAogICAgICAgICAgfCBvciBpbXBvcnQocykgIHwK ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgIHwKICAgICAgICAg ICAgICAgICAgVgogICAgICAgICAgICAgIC8tLS0tLS0tLS0tLS0tXAogICAgICAgICAgICAgLyAg TmV3IGl0ZW1zICAgIFwgeWVzCiAgICAgICAgICAgICBcICBjcmVhdGVkICA/ICAgLy0tLS0tLSsK ICAgICAgICAgICAgICBcLS0tLS0tLS0tLS0tLS8gICAgICAgfAogICAgICAgICAgICAgICAgICAg ICB8IG5vICAgICAgICAgICBWCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgLy0tLS0tLS0t LS0tLS1cICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAvICBTSUQgcmFuZ2UgICAgXCB5ZXMgfCBFeHRyYSBzdWItcmFuZ2V8CiAgICAgICAgICAgICAg ICAgICAgIHwgICAgICBcICBleGhhdXN0ZWQgPyAgLy0tLS0+fCBhc3NpZ25tZW50ICAgICB8CiAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgXC0tLS0tLS0tLS0tLS0vICAgICAgKy0tLS0tLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgbm8gICAgICAg ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgVgogICAgICAgICAgICAgICAgICAgICB8 ICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwgLnNp ZCBmaWxlICAgICB8CiAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8IHVwZGF0ZSBiYXNlZCAg fAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCBvbiBwcmV2aW91cyAgIHwKICAgICAgICAg ICAgICAgICAgICAgfCAgICAgIHwgLnNpZCBmaWxlICAgICB8CiAgICAgICAgICAgICAgICAgICAg IHwgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICB8CiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIFYKICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAvLS0tLS0tLS0tLS0tLVwgICAgICArLS0tLS0tLS0tLS0tLS0tKwog ICAgICAgICAgICAgICAgICAgICB8ICAgICAgLyAgUHVibGljbHkgICAgIFwgeWVzIHwgWUFORyBt b2R1bGUgICB8CiAgICAgICAgICAgICAgICAgICAgIHwgICAgICBcICBhdmFpbGFibGUgPyAgLy0t LS0+fCByZWdpc3RyYXRpb24gIHwKICAgICAgICAgICAgICAgICAgICAgfCAgICAgICBcLS0tLS0t LS0tLS0tLS8gICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICB8IG5vICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbRE9O RV0KCgogICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBZQU5HIGFuZCBTSUQgZmlsZSB1cGRh dGUKCkF1dGhvcnMnIEFkZHJlc3NlcwoKCgoKCgoKCgpWZWlsbGV0dGUsIGV0IGFsLiAgICAgICAg IEV4cGlyZXMgSnVseSAxOCwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAzMF0KDApJbnRlcm5l dC1EcmFmdCAgICAgIFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKSAgICAgICBKYW51 YXJ5IDIwMjAKCgogICBNaWNoZWwgVmVpbGxldHRlIChlZGl0b3IpCiAgIFRyaWxsaWFudCBOZXR3 b3JrcyBJbmMuCiAgIDYxMCBSdWUgZHUgTHV4ZW1ib3VyZwogICBHcmFuYnksIFF1ZWJlYyAgSjJK IDJWMgogICBDYW5hZGEKCiAgIFBob25lOiArMTQ1MDM3NTA1NTYKICAgRW1haWw6IG1pY2hlbC52 ZWlsbGV0dGVAdHJpbGxpYW50LmNvbQoKCiAgIEFsZXhhbmRlciBQZWxvdiAoZWRpdG9yKQogICBB Y2tsaW8KICAgMTEzN0EgYXZlbnVlIGRlcyBDaGFtcHMgQmxhbmNzCiAgIENlc3Nvbi1TZXZpZ25l LCBCcmV0YWduZSAgMzU1MTAKICAgRnJhbmNlCgogICBFbWFpbDogYUBhY2tsLmlvCgoKICAgSXZh eWxvIFBldHJvdiAoZWRpdG9yKQogICBBY2tsaW8KICAgMTEzN0EgYXZlbnVlIGRlcyBDaGFtcHMg QmxhbmNzCiAgIENlc3Nvbi1TZXZpZ25lLCBCcmV0YWduZSAgMzU1MTAKICAgRnJhbmNlCgogICBF bWFpbDogaXZheWxvQGFja2wuaW8KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClZlaWxsZXR0ZSwg ZXQgYWwuICAgICAgICAgRXhwaXJlcyBKdWx5IDE4LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdl IDMxXQo= --000000000000294898059c2d3d93-- From nobody Wed Jan 15 05:51: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 A380D12004A for ; Wed, 15 Jan 2020 05:51:27 -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 Db2D66ExYyVJ for ; Wed, 15 Jan 2020 05:51: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 1B001120025 for ; Wed, 15 Jan 2020 05:51:22 -0800 (PST) Received: from [192.168.217.119] (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 47ySx12mXzz161k; Wed, 15 Jan 2020 14:34:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: <6025.1578939111@localhost> Date: Wed, 15 Jan 2020 14:34:44 +0100 Cc: core@ietf.org, Ivaylo Petrov X-Mao-Original-Outgoing-Id: 600788084.258963-e336369d855f4ed1c111d3b8c5894d93 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.40.2.2.4) 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, 15 Jan 2020 13:51:28 -0000 (No chair hat.) On 2020-01-13, at 19:11, Michael Richardson = wrote: >=20 > The use of 63-bit unsigned integers allows SIDs to be manipulated = more easily > on architectures that might otherwise lack native 64-bit unsigned = arithmetic. > The loss a single bit of precision is not significant given the size = of the > space. s/use of/limitation to/ (we have been using them before) s/architectures/platforms/ (Java is our main problem here, no?) s/precision/range/ s/space/remaining space/ Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 15 05:51: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 A34E1120077 for ; Wed, 15 Jan 2020 05:51:30 -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 Fwsyiq2Y1Fhv for ; Wed, 15 Jan 2020 05:51:25 -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 39FA912003E for ; Wed, 15 Jan 2020 05:51:25 -0800 (PST) Received: from [192.168.217.119] (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 47yStb2w8Kz160c; Wed, 15 Jan 2020 14:32:39 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Jan 2020 14:32:38 +0100 Cc: Michael Richardson , core X-Mao-Original-Outgoing-Id: 600787958.048686-07e638dee1caf01d6aa96cae19b883a9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> To: Ivaylo Petrov X-Mailer: Apple Mail (2.3608.40.2.2.4) 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, 15 Jan 2020 13:51:32 -0000 Hi Ivaylo, Sorry for being slow to reply. > On 2020-01-13, at 11:35, Ivaylo Petrov wrote: >=20 > Do you see any issues adding such a text and do you want me to add it > before you > can start a WGLC or how do you want this to happen? If the text doesn=E2=80=99t come out of the blue but reflects discussion = here on the WG list, that is exactly what we do when making documents = ready for WGLC. So please do go ahead. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 15 06:21:48 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 78F0A120025 for ; Wed, 15 Jan 2020 06:21:27 -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 63VqdHFTqpIc for ; Wed, 15 Jan 2020 06:21: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 E53EB12003E for ; Wed, 15 Jan 2020 06:21:21 -0800 (PST) Received: from [192.168.217.119] (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 47ySzh6mJ4z161C; Wed, 15 Jan 2020 14:37:04 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: <6025.1578939111@localhost> Date: Wed, 15 Jan 2020 14:37:04 +0100 Cc: core@ietf.org, Ivaylo Petrov X-Mao-Original-Outgoing-Id: 600788224.410859-81f8c28c6ff07ca8d26cb5f76cd7d7a2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.40.2.2.4) 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, 15 Jan 2020 14:21:28 -0000 On 2020-01-13, at 19:11, Michael Richardson = wrote: >=20 > o SIDs never change. That may require a little bit of expansion. SIDs do change while I=E2=80=99= m editing the document on my laptop and not telling anyone else what = I=E2=80=99m doing. But at some time, they freeze. What is the specific event that makes a SID allocation immutable, even = if the underlying identifier goes away (and maybe comes back later)? What is the way we keep this memory? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 15 07:01:51 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 C40C6120071 for ; Wed, 15 Jan 2020 07:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JGjYJXIQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HXERvoZF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfBycO2FXJIc for ; Wed, 15 Jan 2020 07:01:08 -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 BEF2012004A for ; Wed, 15 Jan 2020 07:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1926; q=dns/txt; s=iport; t=1579100468; x=1580310068; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kuhUxRkFwBqFjHkwxptAc70OMA23jp/zwIh2choBaPU=; b=JGjYJXIQ0CsrZmBXZIz6zbbdsq4Bo2xWvj/6zBZKeWnRxKZtel8YFT44 qO0hGGFxSlzc2Dsai0GFLi7P2YhWQk3V9CckmvuyOAa0DVMUMXWigiZ/T +Y0CFgivQloNbrgzEXo5LoB+U7urPoz/UkFRrBrGua+c936ojv6Tvd6Ro o=; IronPort-PHdr: =?us-ascii?q?9a23=3AGMrEPhKp/Itkye5nMtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFfkLfr2aCoSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAABVKB9e/5FdJa1kGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gVRQBWxYIAQLKgqEBYNGA4p0gl+YDoJSA1Q?= =?us-ascii?q?JAQEBDAEBGAsKAgEBhEACF4FoJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQE?= =?us-ascii?q?CAQEBEBERDAEBLAsBBAcEAgEGAg4DBAEBAQICJgICAiULFQgIAgQBDQUIGoM?= =?us-ascii?q?FgkoDDiABAgyKJZBkAoE4iGF1gTKCfwEBBYUfGIINAwaBDiiMGBqBQT+BWIJ?= =?us-ascii?q?MPoJkAQGBZYMOMoIsjVeCeZ54CoI4lkuabo5cmwACBAIEBQIOAQEFgWkigVh?= =?us-ascii?q?wFTuCbFAYDYgBDBeDUIUUhT90gSmLJwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,322,1574121600"; d="scan'208";a="405484144" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jan 2020 15:01:04 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 00FF142w028075 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jan 2020 15:01:04 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 09:01:03 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 10:01:02 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 15 Jan 2020 09:01:01 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SHi0BPtJeTaZIkCxEVsYFGCbRY2gy0xNnH5HTSuO0G/2nJj9HYakKBG/rhQcW74xgOnLGM2DBpAwL2tgkJi7BVdogXxdYTPMs9NIbXGGXDCFqbuSg/asQy6qc9u954/TbzR2hxA4kJa+C2QDxMLvY2HWufhRvt9KyGXG1UlUTCtc0OLz0fv5yy93P3wLXDV6jiLvLi6mwJKnFTri+pf/IIHc0XV3ekDS4mbzXZsRGrpWu//d/+CdjGLTAh5fHDM/bwL1/jTDOq856B1pfgXckjCx+y8wT8JFQhQ/ZP8OmlZ/Tyn/rxlSJnBoIkBb0a2eUTYhWf9saRbbWf/lmNBr9Q== 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=kuhUxRkFwBqFjHkwxptAc70OMA23jp/zwIh2choBaPU=; b=W7rR9d+0lewHQwdeR5PSU3OHwLJPjvvtwOEjFsfM5yTQkl9UjvCuqUXyoCTLVJOhMyZenrqMxZa3rJzfib5FPdInU1FVCFHbeCfuaozLPI5x0L7mzC6nlEy1h7zRd9j58ifepBI13m+A6lSinmRMSqwYfUblMjFmQZNGbBtAWdLeC9pSCXTjDJ7WPh+v/6aQYMR9yOwJhmkA8v6YUUSm4aslumsklJO8BMnZg2O/VyUVZ/Al2fXlRwdIMdWAL5SOTArCxLYZx7CjKASwZC/APRsksbEdavZzJfGTUJRv1g0teeddIqMvrNgLZ2HOeGyVWtqcj5ufNwPMzkQL5ESuCw== 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=kuhUxRkFwBqFjHkwxptAc70OMA23jp/zwIh2choBaPU=; b=HXERvoZF8YcgQ48AQBPjK/DpEWYMO4vMpx0PsK+LyAwsXwLjtWl5lwOg4cc+0DHIyHMrL4yWyiabQEiLZMq+mn8q0CpXknI0p0yzApOQ6kQKxvAJoduwyHFtdB9W4N7ywVtR0lYPARzIT+9dOZRP2tu+7TDmpwcwZmZ76/N2HDw= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4205.namprd11.prod.outlook.com (52.135.39.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Wed, 15 Jan 2020 15:01:01 +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.2623.018; Wed, 15 Jan 2020 15:01:01 +0000 From: "Rob Wilton (rwilton)" To: Carsten Bormann , Michael Richardson CC: "core@ietf.org" Thread-Topic: [core] progressing ietf-core-yang-cbor and ietf-core-sid Thread-Index: AQHVurUJXZhJjcMJe0u46wy442FB/KfheU0AgAHZe4CAAM9xgIACJ0WAgAI7cgCAAH+BgIAC1zwAgAASRXA= Date: Wed, 15 Jan 2020 15:01:00 +0000 Message-ID: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> In-Reply-To: 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: 69f0bc55-83c4-4fb3-84c2-08d799cbbc23 x-ms-traffictypediagnostic: MN2PR11MB4205: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(346002)(396003)(366004)(189003)(199004)(6506007)(53546011)(8936002)(478600001)(5660300002)(9686003)(71200400001)(55016002)(52536014)(186003)(7696005)(86362001)(76116006)(33656002)(4326008)(66476007)(110136005)(316002)(66446008)(64756008)(66946007)(66556008)(26005)(966005)(81166006)(81156014)(2906002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4205; 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: 3LAmVO9UA7hjvFxwiWlKSyJXkDH7FbH2IGECUfurw4sOGLJp2O41lyA6eUJ/wl1svzr/uwLH+VbXPWv34p06y8qHurNWGb1eVQMi5UDnYolaQzkUQKpQliR71etJcRx77v+l+oviOYWEK+1dfP3mb47LxUNK6GlDTjRp5JU7bhjzLSrr2DoAtSP9VD7EA4D9V4+zzPvEGkSsDYbhYOtJuqFU0ooxAmgfgWBw8SEYgKypeB1pbSoojzm6nFKoZAy15izzhxUEBtPU3kyRVqchUUlhaqDoVpoSLFmEH6r+n0IivEEcRUANu8xRJB9KfGEc9B9DPJmQk4unMSxKfGGCvNzHFzmSUGKuhWPjSbHqQNKYuAc5A/QLObdp/uFqwe8sVBp8RcItJD7/1zC2RKRxvcsxyyf0BkbXLA1iduvAZt9Yqswhb1XxLyjLtOOeRGL9+zy+DNk0JAyoXzrQpL1MgcS8hERgdwOxbKl6o4UDDVwp1Vc7wwQMHY/Exijfr6osEgYA0zkw0brdIla5QpXptw== 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: 69f0bc55-83c4-4fb3-84c2-08d799cbbc23 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 15:01:00.7920 (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: SRvGjRdSrIJ76M9mq1nYkM4phFmMn5tLvCz7blGToOw08UicMHwz/s8gj1OuZc6GPpdmHItch8J/wMYr/YtlKw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4205 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com 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, 15 Jan 2020 15:01:14 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY29yZSA8Y29yZS1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQo+IFNlbnQ6IDE1IEph bnVhcnkgMjAyMCAxMzozNQ0KPiBUbzogTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5k ZWxtYW4uY2E+DQo+IENjOiBjb3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gcHJv Z3Jlc3NpbmcgaWV0Zi1jb3JlLXlhbmctY2JvciBhbmQgaWV0Zi1jb3JlLXNpZA0KPiANCj4gKE5v IGNoYWlyIGhhdC4pDQo+IA0KPiBPbiAyMDIwLTAxLTEzLCBhdCAxOToxMSwgTWljaGFlbCBSaWNo YXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiA+DQo+ID4gIFRoZSB1c2Ug b2YgNjMtYml0IHVuc2lnbmVkIGludGVnZXJzIGFsbG93cyBTSURzIHRvIGJlIG1hbmlwdWxhdGVk DQo+ID4gbW9yZSBlYXNpbHkgIG9uIGFyY2hpdGVjdHVyZXMgdGhhdCBtaWdodCBvdGhlcndpc2Ug bGFjayBuYXRpdmUgNjQtYml0DQo+IHVuc2lnbmVkIGFyaXRobWV0aWMuDQo+ID4gIFRoZSBsb3Nz IGEgc2luZ2xlIGJpdCBvZiBwcmVjaXNpb24gaXMgbm90IHNpZ25pZmljYW50IGdpdmVuIHRoZSBz aXplDQo+ID4gb2YgdGhlICBzcGFjZS4NCj4gDQo+IHMvdXNlIG9mL2xpbWl0YXRpb24gdG8vICAg ICAod2UgaGF2ZSBiZWVuIHVzaW5nIHRoZW0gYmVmb3JlKQ0KPiBzL2FyY2hpdGVjdHVyZXMvcGxh dGZvcm1zLyAgKEphdmEgaXMgb3VyIG1haW4gcHJvYmxlbSBoZXJlLCBubz8pDQpbUlddIA0KSSB0 aGluayB0aGF0IGl0IHdvdWxkIGJlIGF3a3dhcmQgZm9yIG1vc3QgbGFuZ3VhZ2VzL0NQVSBhcmNo aXRlY3R1cmVzLCBhbnl3aGVyZSB3aGVyZSB5b3UgY291bGQgZW5kIHVwIHdpdGggYSBuZWdhdGl2 ZSBudW1iZXIgdGhhdCBpcyBsZXNzIHRoYW4gMl42My4NCg0KWWVzLCBpdCBpcyBwb3NzaWJsZSB0 byB3cml0ZSBjb2RlIGluIEMgb3IgSmF2YSB0byBoYW5kbGUgdGhpcywgYnV0IG15IGh1bmNoIGlz IHRoYXQgaW1wbGVtZW50YXRpb25zIGNvdWxkIGVhc2lseSBnZXQgdGhpcyB3cm9uZyAoZS5nLiBi eSBqdXN0IHVzaW5nIHNpZ25lZCBpbnQ2NCBhcyB0aGUgdHlwZSB0byBob2xkIHRoZSBkaWZmZXJl bmNlIGJldHdlZW4gcGFyZW50IGFuZCBjaGlsZCBTSURzLikNCg0KVGhhbmtzLA0KUm9iDQoNCg0K PiBzL3ByZWNpc2lvbi9yYW5nZS8gcy9zcGFjZS9yZW1haW5pbmcgc3BhY2UvDQo+IA0KPiBHcsO8 w59lLCBDYXJzdGVuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From nobody Wed Jan 15 07:46: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 B2BAE1200B4 for ; Wed, 15 Jan 2020 07:45: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 my5Sd462CnAc for ; Wed, 15 Jan 2020 07:45:02 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D11120025 for ; Wed, 15 Jan 2020 07:45:01 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 199793897B; Wed, 15 Jan 2020 10:44:33 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BC88DE96; Wed, 15 Jan 2020 10:44:59 -0500 (EST) From: Michael Richardson To: Ivaylo Petrov , core In-Reply-To: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6950.1578939331@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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, 15 Jan 2020 15:45:08 -0000 --=-=-= Content-Type: text/plain Ivaylo Petrov wrote: > Thank you very much for the proposed text! I have applied the changes > that you proposed with slight modifications where I felt the need. You > can find the proposed version in attachment and the changes here [1]. > We are using markdown to build the draft, therefore there is no XML Markdown even better than XML :-) > Please notice that the change you proposed for sec 6.4.2. seemed out of > place there and I modified slightly sec 6.4.1 to address what I believe > was your concern. Please let me know if further changes are required. okay. But, what about: > Ivaylo, In section 6.3.3, you have no allocation for > constrained-voucher. You had given us 2500:2550 --- > constrained-voucher-request. And 2400 -- 2440:2500 --- > constrained-voucher. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4fM3sACgkQgItw+93Q 3WWpewgAj63DI0BGYCxodR04hjriK/2pVbQ6HG8TkxRLfruKwykUFRuenvkD53El tt+eWSvldglnh3c/jKSzJt/Z/3Sl+9OhgjGzfXeMfXBsMcWX5UCqxvQ+/pV6N+QV Kv3cw9utx7eH5AmZeTTbww5djbBFCHq+LUynqq27XtSIp/C8FSlG4t7TAA5jcxQc 6Hlp1t6Ep/DCD66Dl1DoANXbTSuCGwVVZcUZa9bcToMzLy8qpK5L0tLgMi/XIh9u E+rO88OQb93TKNO3/9vWvhyudPRybKzqz0LZKm1G+p8BXbODl5HsD+LdlcX/oKXO iDkM/7Nh+J+RU16O1yonOV6NlgIkzw== =Sahu -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 15 07:48:37 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 E00351200F6 for ; Wed, 15 Jan 2020 07:47:36 -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 tX9-siuZkUZ6 for ; Wed, 15 Jan 2020 07:47:28 -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 A4997120845 for ; Wed, 15 Jan 2020 07:46:30 -0800 (PST) Received: from [192.168.217.119] (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 47yWs10lG3z16Dv; Wed, 15 Jan 2020 16:46:29 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Jan 2020 16:46:28 +0100 Cc: Michael Richardson , "core@ietf.org" X-Mao-Original-Outgoing-Id: 600795988.598043-e9c41456fd41b0b364510afa007335d0 Content-Transfer-Encoding: quoted-printable Message-Id: <46BA6719-5319-40FC-B218-5832F32C85BC@tzi.org> References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> To: "Rob Wilton (rwilton)" X-Mailer: Apple Mail (2.3608.40.2.2.4) 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, 15 Jan 2020 15:47:37 -0000 Yeah, but here the problem is in the head of the implementor and not in = the CPU architecture :-) I was not suggesting the text behind the substitutes to be included, = this was just explanation why I=E2=80=99d like to have the change. Gr=C3=BC=C3=9Fe, Carsten > On 2020-01-15, at 16:01, Rob Wilton (rwilton) = wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: core On Behalf Of Carsten Bormann >> Sent: 15 January 2020 13:35 >> To: Michael Richardson >> Cc: core@ietf.org >> Subject: Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid >>=20 >> (No chair hat.) >>=20 >> On 2020-01-13, at 19:11, Michael Richardson = wrote: >>>=20 >>> The use of 63-bit unsigned integers allows SIDs to be manipulated >>> more easily on architectures that might otherwise lack native = 64-bit >> unsigned arithmetic. >>> The loss a single bit of precision is not significant given the size >>> of the space. >>=20 >> s/use of/limitation to/ (we have been using them before) >> s/architectures/platforms/ (Java is our main problem here, no?) > [RW]=20 > I think that it would be awkward for most languages/CPU architectures, = anywhere where you could end up with a negative number that is less than = 2^63. >=20 > Yes, it is possible to write code in C or Java to handle this, but my = hunch is that implementations could easily get this wrong (e.g. by just = using signed int64 as the type to hold the difference between parent and = child SIDs.) >=20 > Thanks, > Rob >=20 >=20 >> s/precision/range/ s/space/remaining space/ >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Wed Jan 15 08:41:48 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 A7AA012087B for ; Wed, 15 Jan 2020 08:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=EpSdFhHq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Xm+RpM4g Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WSaLU4mP5vr for ; Wed, 15 Jan 2020 08:40:52 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27FE212085B for ; Wed, 15 Jan 2020 08:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19316; q=dns/txt; s=iport; t=1579106452; x=1580316052; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+1s0+dV+S3CXOX6iQf8IWh7I44g2tBHvEUI4YGoCxME=; b=EpSdFhHqCXhFpaw0bzKzEvpaLpkVMrErui2nhb4NkrY15BPHqXK1A2Lx qlAUngrxek9drN2tspIdc8yACCJjVuEUA6jK4V6Cni1BpAEU06mBshEwY mp7of3fIRXxgOZB4tinv1wgeKL0tFkLs5ClNBf5cVytIN8/xRU7soil0p g=; IronPort-PHdr: =?us-ascii?q?9a23=3A+DBi6xeIjFPxy/BoIsb2fpHwlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTM7GNhFUndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BECAAePx9e/49dJa1kHQEBAQkBEQU?= =?us-ascii?q?FAYF7gSUvUAVsWCAECyoKhAWDRgOKdIJfkyyEYoJSA1QJAQEBDAEBGAEKCgI?= =?us-ascii?q?BAYRAAheBaCQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAgEBARARChMBASw?= =?us-ascii?q?LAQQHBAIBBgIOAwEDAQEoAwICAiULFAMGCAIEDgUIGoMFgX1NAw4gAQIMily?= =?us-ascii?q?QZAKBOIhhdYEygn8BAQWFGRiCDQMGgTaMGBqBQT+BEUeCTD6CZAEBAYFkK4J?= =?us-ascii?q?jMoIsjVeCeYVZmR8KgjiHPY8Omm6XOZIjAgQCBAUCDgEBBYFpIoFYcBU7gmw?= =?us-ascii?q?fMRgNiAEMF4NQgmSCMIU/dIEpiycBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,323,1574121600"; d="scan'208,217";a="413093650" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jan 2020 16:40:51 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 00FGepV5023078 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jan 2020 16:40:51 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 10:40:50 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 11:40:47 -0500 Received: from NAM10-BN7-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; Wed, 15 Jan 2020 11:40:47 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i0ZEeBqtYXHxQCMJNOBYu/gpZ5o4OYfsmxiQs5b2qYvSW5wTkZ0tyM+6O78aAwcKoWAZh++GvGsgmszdf7Zu3VU21n4R4PYkgBGmxt+dkdnpYVEhxDcyOiaSESpbwHQOBYWnOhRLaNgcu1dQY/v/AfU6fGf0+i5l9OUHxs6be1rZsvQyMOMpOUgt5IKz+o01sUKoy6ti6sWNnDSMxEDiP2B/NTmRsAwJa8IfdaubcuHgHpPRQrjzc+Y6xJm9QlWqgGmTMEamerxtjqkmysfLt0Y+n048T1mUmyQxZ0ZWa9H07KfserKeNR6bSurhEbhjU9k4Fg7Ir3ZmqydLms5d5Q== 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=+1s0+dV+S3CXOX6iQf8IWh7I44g2tBHvEUI4YGoCxME=; b=cJjB5gdqSGKDLtRVLy+M6Ouze6poHL17TkOlAgX/2xGUbqExs8fgdE+J7v9DqPDlfkjZFiB8MzR6qpqZbd3qlq7clf4cuhaDCSlidbG7nUxIHZZA/cPu6aZK4bzaNx16HMAUW4k5kZr1TI8H25GDIDzGKkfywaXAohLtHTr+Jxk22tYi+zOidETnksv8hVTXg4oZlRUQ7TsVkWWXt3G5NI37HpGe2ZXx5f5lPW/e9cypaGnnTIWPO53/A8t//xncmg+LYdNy9VQs46G7/pnLWopdcwTvIOqMtzGc6A5Zx4jv7Um8ITx2WHgH15e0bDyqglHTQbJpBmSqYMHkpP9BcQ== 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=+1s0+dV+S3CXOX6iQf8IWh7I44g2tBHvEUI4YGoCxME=; b=Xm+RpM4gI7x14j/W5+k08/YUgcVDpSqPB+j77GPFgPYJ9kO8Q6GmwyRAKeSTsy78b9V/seujMjcTswJrUlLP9itkdAxmInkyRCh0V6q2RyeZ4ZjqM0OLB8IJcFobnjvENKnHCAQPw5VoYrRlj80AzAAFML6EOCqz6yZuM6JFqlg= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4416.namprd11.prod.outlook.com (52.135.36.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 15 Jan 2020 16:40:46 +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.2623.018; Wed, 15 Jan 2020 16:40:46 +0000 From: "Rob Wilton (rwilton)" To: Carsten Bormann CC: Michael Richardson , "core@ietf.org" Thread-Topic: [core] progressing ietf-core-yang-cbor and ietf-core-sid Thread-Index: AQHVurUJXZhJjcMJe0u46wy442FB/KfheU0AgAHZe4CAAM9xgIACJ0WAgAI7cgCAAH+BgIAC1zwAgAASRXCAABKKAIAAANaQ Date: Wed, 15 Jan 2020 16:40:46 +0000 Message-ID: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> <46BA6719-5319-40FC-B218-5832F32C85BC@tzi.org> In-Reply-To: <46BA6719-5319-40FC-B218-5832F32C85BC@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: 6b2469f0-5d77-4889-b94b-08d799d9abf3 x-ms-traffictypediagnostic: MN2PR11MB4416: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(4636009)(366004)(39860400002)(346002)(376002)(136003)(396003)(199004)(189003)(81166006)(8676002)(966005)(54906003)(71200400001)(53546011)(2906002)(6506007)(86362001)(52536014)(6916009)(33656002)(66446008)(81156014)(478600001)(8936002)(5660300002)(55016002)(21615005)(316002)(26005)(7696005)(186003)(66946007)(64756008)(66476007)(76116006)(4326008)(66556008)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4416; 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: FJ4S4oPYsW9yeiRQ36YMhw81+Gxso5LFVDIhUs5duwo2RI8L4S0InMdyNvvtW2yTElfWQaBi2Ejp5DGL4XOfPspjhZcNbRcrWvy5coV5PRooXn4nnWGTUZ6nejRcaqD3KcqgtYJ34Y9SRmfht9+C7JRahjA8p2aZMuIeY5/gA218a1LdcfFrORtOrV2y5XIpXpucHsPS5H5sCs7Bv0nsajiRd6aOIyiccRsIsQ4tb+CACSqlbUnlfA26gPRFqPwRmwD108Yn08pvFULSrTlIBFL1OSbI27kQOFL/tWNVJSmPsGLud7+VTgtH94aDFXOKYlJtwcK1wECD9XLNR9DHMd/iwgY9zLgR6ETEy5Y3epPh4MfhOS8L8QuzbdVraDZy5+uKmtQ/oBejzkFgI2IIdoaGeE/J4KPWni46ri4MyyGEr/CHYnLM0BwBTh7gBFDsCqaWZfmaEZ3QvN7wCzdET3ic1aST/L78VXr6n2Hf5mTaSE6SuH8vI1OMTi3qW7fGB6bYdacIoJ+gmvHJnfZ/wr2YmsBlP3dctbHabyG1zedmmWPS7RzgoVTQK+aeMjCiCXvlrw6dPh/O4kyc1xASJw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43663281BBACA171BEBFAB2BB5370MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6b2469f0-5d77-4889-b94b-08d799d9abf3 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 16:40:46.2127 (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: y9I1yLLXpwaUpDMmyLepCu8HhS2c31e4aDQHMoM4KsBBgxPRIP9JTA7DD/dy/TS/gfyJFM0O3GeBT/OlYNlrqQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4416 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com 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, 15 Jan 2020 16:40:57 -0000 --_000_MN2PR11MB43663281BBACA171BEBFAB2BB5370MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogQ2Fyc3RlbiBC b3JtYW5uIDxjYWJvQHR6aS5vcmc+DQoNCj4gU2VudDogMTUgSmFudWFyeSAyMDIwIDE1OjQ2DQoN Cj4gVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT4NCg0KPiBDYzog TWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBjb3JlQGlldGYub3Jn DQoNCj4gU3ViamVjdDogUmU6IFtjb3JlXSBwcm9ncmVzc2luZyBpZXRmLWNvcmUteWFuZy1jYm9y IGFuZCBpZXRmLWNvcmUtc2lkDQoNCj4NCg0KPiBZZWFoLCBidXQgaGVyZSB0aGUgcHJvYmxlbSBp cyBpbiB0aGUgaGVhZCBvZiB0aGUgaW1wbGVtZW50b3IgYW5kIG5vdCBpbg0KDQo+IHRoZSBDUFUg YXJjaGl0ZWN0dXJlIDotKQ0KDQoNCg0KSSdtIG5vdCBzdXJlIHRoYXQgSSBhZ3JlZSwg8J+YiQ0K DQoNCg0KSSBtaWdodCBiZSB3cm9uZywgYnV0IG1vc3QgQ1BVIGFyY2hpdGVjdHVyZXMgZG9uJ3Qg c3VwcG9ydCA2NCBiaXQgbmVnYXRpdmUgdmFsdWVzICh1bmxlc3MgeW91IG1vdmUgdG8gMTI4IGJp dCBzaWduZWQgbnVtYmVycyB3aXRoIHRoZSBjb3JyZXNwb25kaW5nIHBlcmZvcm1hbmNlIG92ZXJo ZWFkKS4gIE9mIGNvdXJzZSwgaW1wbGVtZW50b3JzIGNhbiB3b3JrIGFyb3VuZCB0aGUgYXJjaGl0 ZWN0dXJlIGxpbWl0YXRpb25zIGJ5IGVtdWxhdGluZyA2NCBiaXQgbmVnYXRpdmUgbnVtYmVycyB1 c2luZyB1bnNpZ25lZCA2NCBiaXQgbnVtYmVycyAuLi4NCg0KDQoNCg0KDQpJbiBmYWN0LCBJIHdh cyB3b25kZXJpbmcgd2hldGhlciBpdCBpcyByZWFsbHkgYSBnb29kIHRoaW5nIHRoYXQgQ0JPUiBh bGxvd3MgYSA2NCBiaXQgbmVnYXRpdmUgaW50ZWdlciB0byBiZSBleHByZXNzZWQuICBJdCBtZWFu cyB0aGF0IHRoZSBDQk9SIGVuY29kaW5nIGNhbiBlYXNpbHkgY2FycnkgdmFsdWVzIHRoYXQgbW9z dCBpbXBsZW1lbnRhdGlvbnMgY2Fubm90IGVhc2lseSBnZW5lcmF0ZSBvciByZXByZXNlbnQuDQoN Cg0KDQpTbywgSSBsb29rZWQgYXQgdGhlIGZpcnN0IGF2YWlsYWJsZSBDIGltcGxlbWVudGF0aW9u IGV4YW1wbGUgYXQgaHR0cHM6Ly9jYm9yLmlvL2ltcGxzLmh0bWwsIGFuZCBpdCBjYW4ndCBoYW5k bGUgbmVnYXRpdmUgNjQgYml0IG51bWJlcnMsIG92ZXJmbG93aW5nIHRoZW0gaW50byBhIGxvbmcg dmFyaWFibGUuICBJIHdvbmRlciB3aGF0IHByb3BvcnRpb24gb2YgQ0JPUiBpbXBsZW1lbnRhdGlv bnMgZG8gaGFuZGxlIHRoZXNlIGNvcnJlY3RseSAuLi4gIE9mIGNvdXJzZSwgSSdtIG5vdCBzdWdn ZXN0aW5nIGNoYW5naW5nIHRoZSBzcGVjLCBqdXN0IGEgcmV0cm9zcGVjdGl2ZSBvYnNlcnZhdGlv bi4NCg0KDQoNCj4gSSB3YXMgbm90IHN1Z2dlc3RpbmcgdGhlIHRleHQgYmVoaW5kIHRoZQ0KDQo+ IHN1YnN0aXR1dGVzIHRvIGJlIGluY2x1ZGVkLCB0aGlzIHdhcyBqdXN0IGV4cGxhbmF0aW9uIHdo eSBJ4oCZZCBsaWtlIHRvIGhhdmUNCg0KPiB0aGUgY2hhbmdlLg0KDQpbUlddDQoNClllcywgYnV0 IEkgdGhpbmsgdGhhdCAiYXJjaGl0ZWN0dXJlcyIgaXMgcHJvYmFibHkgdGhlIGNvcnJlY3QgdGVy bSBoZXJlLCBhdCBsZWFzdCB1bnRpbCB3ZSBlbmQgdXAgd2l0aCBDUFVzIHdpdGggYSA2NSBiaXQg c2lnbmVkIGRhdGFwYXRoLCBhbHRob3VnaCBJIGhhdmUgdG8gY29uZmVzcyB0aGF0IEkgZG91YnQg dGhhdCB0aGUgY2hvaWNlIG9mIHdvcmQgcmVhbGx5IG1hdHRlcnMuIPCfmIoNCg0KDQoNClRoYW5r cywNClJvYg0KDQoNCg0KDQoNCg0KDQo+DQoNCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KDQo+DQoNCj4N Cg0KPiA+IE9uIDIwMjAtMDEtMTUsIGF0IDE2OjAxLCBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndp bHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4gd3JvdGU6DQoNCj4gPg0K DQo+ID4NCg0KPiA+DQoNCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiA+PiBG cm9tOiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRm Lm9yZz4+IE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NCg0KPiA+PiBTZW50OiAxNSBKYW51 YXJ5IDIwMjAgMTM6MzUNCg0KPiA+PiBUbzogTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBz YW5kZWxtYW4uY2E8bWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5jYT4+DQoNCj4gPj4gQ2M6IGNv cmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQoNCj4gPj4gU3ViamVjdDogUmU6IFtj b3JlXSBwcm9ncmVzc2luZyBpZXRmLWNvcmUteWFuZy1jYm9yIGFuZCBpZXRmLWNvcmUtc2lkDQoN Cj4gPj4NCg0KPiA+PiAoTm8gY2hhaXIgaGF0LikNCg0KPiA+Pg0KDQo+ID4+IE9uIDIwMjAtMDEt MTMsIGF0IDE5OjExLCBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYTxt YWlsdG86bWNyK2lldGZAc2FuZGVsbWFuLmNhPj4NCg0KPiB3cm90ZToNCg0KPiA+Pj4NCg0KPiA+ Pj4gVGhlIHVzZSBvZiA2My1iaXQgdW5zaWduZWQgaW50ZWdlcnMgYWxsb3dzIFNJRHMgdG8gYmUg bWFuaXB1bGF0ZWQNCg0KPiA+Pj4gbW9yZSBlYXNpbHkgIG9uIGFyY2hpdGVjdHVyZXMgdGhhdCBt aWdodCBvdGhlcndpc2UgbGFjayBuYXRpdmUNCg0KPiA+Pj4gNjQtYml0DQoNCj4gPj4gdW5zaWdu ZWQgYXJpdGhtZXRpYy4NCg0KPiA+Pj4gVGhlIGxvc3MgYSBzaW5nbGUgYml0IG9mIHByZWNpc2lv biBpcyBub3Qgc2lnbmlmaWNhbnQgZ2l2ZW4gdGhlIHNpemUNCg0KPiA+Pj4gb2YgdGhlICBzcGFj ZS4NCg0KPiA+Pg0KDQo+ID4+IHMvdXNlIG9mL2xpbWl0YXRpb24gdG8vICAgICAod2UgaGF2ZSBi ZWVuIHVzaW5nIHRoZW0gYmVmb3JlKQ0KDQo+ID4+IHMvYXJjaGl0ZWN0dXJlcy9wbGF0Zm9ybXMv ICAoSmF2YSBpcyBvdXIgbWFpbiBwcm9ibGVtIGhlcmUsIG5vPykNCg0KPiA+IFtSV10NCg0KPiA+ IEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBhd2t3YXJkIGZvciBtb3N0IGxhbmd1YWdlcy9DUFUg YXJjaGl0ZWN0dXJlcywNCg0KPiBhbnl3aGVyZSB3aGVyZSB5b3UgY291bGQgZW5kIHVwIHdpdGgg YSBuZWdhdGl2ZSBudW1iZXIgdGhhdCBpcyBsZXNzIHRoYW4NCg0KPiAyXjYzLg0KDQo+ID4NCg0K PiA+IFllcywgaXQgaXMgcG9zc2libGUgdG8gd3JpdGUgY29kZSBpbiBDIG9yIEphdmEgdG8gaGFu ZGxlIHRoaXMsIGJ1dCBteQ0KDQo+ID4gaHVuY2ggaXMgdGhhdCBpbXBsZW1lbnRhdGlvbnMgY291 bGQgZWFzaWx5IGdldCB0aGlzIHdyb25nIChlLmcuIGJ5DQoNCj4gPiBqdXN0IHVzaW5nIHNpZ25l ZCBpbnQ2NCBhcyB0aGUgdHlwZSB0byBob2xkIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4NCg0KPiA+ IHBhcmVudCBhbmQgY2hpbGQgU0lEcy4pDQoNCj4gPg0KDQo+ID4gVGhhbmtzLA0KDQo+ID4gUm9i DQoNCj4gPg0KDQo+ID4NCg0KPiA+PiBzL3ByZWNpc2lvbi9yYW5nZS8gcy9zcGFjZS9yZW1haW5p bmcgc3BhY2UvDQoNCj4gPj4NCg0KPiA+PiBHcsO8w59lLCBDYXJzdGVuDQoNCj4gPj4NCg0KPiA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+ID4+ IGNvcmUgbWFpbGluZyBsaXN0DQoNCj4gPj4gY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRm Lm9yZz4NCg0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUN Cg0KDQo= --_000_MN2PR11MB43663281BBACA171BEBFAB2BB5370MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0 LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDEwMi41 NXB0IDcyLjBwdCAxMDIuNTVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyA8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5G cm9tOiBDYXJzdGVuIEJvcm1hbm4gJmx0O2NhYm9AdHppLm9yZyZndDs8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5TZW50OiAxNSBKYW51YXJ5IDIwMjAgMTU6NDY8L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5UbzogUm9iIFdpbHRvbiAocndpbHRvbikg Jmx0O3J3aWx0b25AY2lzY28uY29tJmd0Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IDxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tR0IiPkNjOiBNaWNoYWVsIFJpY2hhcmRzb24gJmx0O21jciYjNDM7aWV0ZkBzYW5kZWxtYW4u Y2EmZ3Q7OyBjb3JlQGlldGYub3JnPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H QiI+U3ViamVjdDogUmU6IFtjb3JlXSBwcm9ncmVzc2luZyBpZXRmLWNvcmUteWFuZy1jYm9yIGFu ZCBpZXRmLWNvcmUtc2lkPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBZZWFoLCBidXQgaGVyZSB0aGUgcHJv YmxlbSBpcyBpbiB0aGUgaGVhZCBvZiB0aGUgaW1wbGVtZW50b3IgYW5kIG5vdCBpbjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhlIENQVSBhcmNoaXRlY3R1cmUgOi0pPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkknbSBub3Qgc3VyZSB0aGF0IEkgYWdyZWUsIDxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlm Ij4NCiYjMTI4NTIxOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBtaWdo dCBiZSB3cm9uZywgYnV0IG1vc3QgQ1BVIGFyY2hpdGVjdHVyZXMgZG9uJ3Qgc3VwcG9ydCA2NCBi aXQgbmVnYXRpdmUgdmFsdWVzICh1bmxlc3MgeW91IG1vdmUgdG8gMTI4IGJpdCBzaWduZWQgbnVt YmVycyB3aXRoIHRoZSBjb3JyZXNwb25kaW5nIHBlcmZvcm1hbmNlIG92ZXJoZWFkKS4mbmJzcDsg T2YgY291cnNlLCBpbXBsZW1lbnRvcnMgY2FuIHdvcmsgYXJvdW5kIHRoZSBhcmNoaXRlY3R1cmUg bGltaXRhdGlvbnMNCiBieSBlbXVsYXRpbmcgNjQgYml0IG5lZ2F0aXZlIG51bWJlcnMgdXNpbmcg dW5zaWduZWQgNjQgYml0IG51bWJlcnMgLi4uIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluIGZhY3Qs IEkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIGl0IGlzIHJlYWxseSBhIGdvb2QgdGhpbmcgdGhhdCBD Qk9SIGFsbG93cyBhIDY0IGJpdCBuZWdhdGl2ZSBpbnRlZ2VyIHRvIGJlIGV4cHJlc3NlZC4mbmJz cDsgSXQgbWVhbnMgdGhhdCB0aGUgQ0JPUiBlbmNvZGluZyBjYW4gZWFzaWx5IGNhcnJ5IHZhbHVl cyB0aGF0IG1vc3QgaW1wbGVtZW50YXRpb25zIGNhbm5vdCBlYXNpbHkgZ2VuZXJhdGUgb3IgcmVw cmVzZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TbywgSSBsb29rZWQgYXQgdGhl IGZpcnN0IGF2YWlsYWJsZSBDIGltcGxlbWVudGF0aW9uIGV4YW1wbGUgYXQNCjxhIGhyZWY9Imh0 dHBzOi8vY2Jvci5pby9pbXBscy5odG1sIj5odHRwczovL2Nib3IuaW8vaW1wbHMuaHRtbDwvYT4s IGFuZCBpdCBjYW4ndCBoYW5kbGUgbmVnYXRpdmUgNjQgYml0IG51bWJlcnMsIG92ZXJmbG93aW5n IHRoZW0gaW50byBhIGxvbmcgdmFyaWFibGUuJm5ic3A7IEkgd29uZGVyIHdoYXQgcHJvcG9ydGlv biBvZiBDQk9SIGltcGxlbWVudGF0aW9ucyBkbyBoYW5kbGUgdGhlc2UgY29ycmVjdGx5IC4uLiZu YnNwOyBPZiBjb3Vyc2UsIEknbSBub3Qgc3VnZ2VzdGluZw0KIGNoYW5naW5nIHRoZSBzcGVjLCBq dXN0IGEgcmV0cm9zcGVjdGl2ZSBvYnNlcnZhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBJIHdhcyBub3Qgc3VnZ2VzdGluZyB0aGUgdGV4dCBiZWhpbmQgdGhlPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzdWJzdGl0dXRlcyB0byBiZSBpbmNsdWRlZCwg dGhpcyB3YXMganVzdCBleHBsYW5hdGlvbiB3aHkgSeKAmWQgbGlrZSB0byBoYXZlPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGUgY2hhbmdlLjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W1JXXSA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlllcywgYnV0IEkgdGhpbmsgdGhhdCAmcXVvdDthcmNoaXRlY3R1cmVzJnF1b3Q7IGlzIHByb2Jh Ymx5IHRoZSBjb3JyZWN0IHRlcm0gaGVyZSwgYXQgbGVhc3QgdW50aWwgd2UgZW5kIHVwIHdpdGgg Q1BVcyB3aXRoIGEgNjUgYml0IHNpZ25lZCBkYXRhcGF0aCwgYWx0aG91Z2ggSSBoYXZlIHRvIGNv bmZlc3MgdGhhdCBJIGRvdWJ0IHRoYXQgdGhlIGNob2ljZSBvZiB3b3JkIHJlYWxseQ0KIG1hdHRl cnMuIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+JiMxMjg1MjI7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRo YW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg R3LDvMOfZSwgQ2Fyc3RlbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgT24gMjAyMC0wMS0xNSwgYXQgMTY6MDEsIFJvYiBXaWx0b24gKHJ3aWx0b24p ICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5yd2lsdG9uQGNpc2NvLmNvbTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBjb3JlICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZS1i b3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y YXRpb246bm9uZSI+Y29yZS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7IE9uIEJlaGFs ZiBPZiBDYXJzdGVuIEJvcm1hbm48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7IFNlbnQ6IDE1IEphbnVhcnkgMjAyMCAxMzozNTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsgVG86IE1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5tY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhPC9z cGFuPjwvYT4mZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBD YzogPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5jb3JlQGlldGYub3JnPC9zcGFuPjwvYT48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbY29y ZV0gcHJvZ3Jlc3NpbmcgaWV0Zi1jb3JlLXlhbmctY2JvciBhbmQgaWV0Zi1jb3JlLXNpZDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IChObyBjaGFpciBoYXQuKTwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7IE9uIDIwMjAtMDEtMTMsIGF0IDE5OjExLCBNaWNoYWVsIFJpY2hhcmRzb24g Jmx0OzxhIGhyZWY9Im1haWx0bzptY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWNyJiM0MztpZXRmQHNh bmRlbG1hbi5jYTwvc3Bhbj48L2E+Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgd3JvdGU6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGUgdXNlIG9m IDYzLWJpdCB1bnNpZ25lZCBpbnRlZ2VycyBhbGxvd3MgU0lEcyB0byBiZSBtYW5pcHVsYXRlZDwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IG1vcmUgZWFzaWx5 Jm5ic3A7IG9uIGFyY2hpdGVjdHVyZXMgdGhhdCBtaWdodCBvdGhlcndpc2UgbGFjayBuYXRpdmU8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyA2NC1iaXQ8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHVuc2lnbmVkIGFyaXRobWV0 aWMuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgVGhlIGxv c3MgYSBzaW5nbGUgYml0IG9mIHByZWNpc2lvbiBpcyBub3Qgc2lnbmlmaWNhbnQgZ2l2ZW4gdGhl IHNpemU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBvZiB0 aGUmbmJzcDsgc3BhY2UuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgcy91c2Ugb2YvbGlt aXRhdGlvbiB0by8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKHdlIGhhdmUgYmVlbiB1c2luZyB0 aGVtIGJlZm9yZSk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHMv YXJjaGl0ZWN0dXJlcy9wbGF0Zm9ybXMvJm5ic3A7IChKYXZhIGlzIG91ciBtYWluIHByb2JsZW0g aGVyZSwgbm8/KTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBbUlddPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdCBpdCB3b3Vs ZCBiZSBhd2t3YXJkIGZvciBtb3N0IGxhbmd1YWdlcy9DUFUgYXJjaGl0ZWN0dXJlcyw8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFueXdoZXJlIHdoZXJlIHlvdSBjb3VsZCBlbmQg dXAgd2l0aCBhIG5lZ2F0aXZlIG51bWJlciB0aGF0IGlzIGxlc3MgdGhhbjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgMl42My48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgWWVzLCBpdCBp cyBwb3NzaWJsZSB0byB3cml0ZSBjb2RlIGluIEMgb3IgSmF2YSB0byBoYW5kbGUgdGhpcywgYnV0 IG15PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGh1bmNoIGlzIHRoYXQg aW1wbGVtZW50YXRpb25zIGNvdWxkIGVhc2lseSBnZXQgdGhpcyB3cm9uZyAoZS5nLiBieTwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBqdXN0IHVzaW5nIHNpZ25lZCBpbnQ2 NCBhcyB0aGUgdHlwZSB0byBob2xkIHRoZSBkaWZmZXJlbmNlIGJldHdlZW48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgcGFyZW50IGFuZCBjaGlsZCBTSURzLik8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsgVGhhbmtzLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyBSb2I8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7IHMvcHJlY2lzaW9uL3JhbmdlLyBzL3NwYWNlL3JlbWFpbmluZyBzcGFj ZS88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBHcsO8w59lLCBDYXJzdGVuPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGNv cmUgbWFpbGluZyBsaXN0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyA8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvcmU8L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB43663281BBACA171BEBFAB2BB5370MN2PR11MB4366namp_-- From nobody Wed Jan 15 09:08:10 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 98075120892 for ; Wed, 15 Jan 2020 09:07:27 -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 0YdfA3Ji_8ws for ; Wed, 15 Jan 2020 09:07: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 02BF6120886 for ; Wed, 15 Jan 2020 09:07:23 -0800 (PST) Received: from [192.168.217.119] (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 47yYfK1d2Dz160Y; Wed, 15 Jan 2020 18:07:21 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Jan 2020 18:07:20 +0100 Cc: Michael Richardson , "core@ietf.org" X-Mao-Original-Outgoing-Id: 600800839.819038-4f318758cdb42ffd7197019f411ea784 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> <46BA6719-5319-40FC-B218-5832F32C85BC@tzi.org> To: "Rob Wilton (rwilton)" X-Mailer: Apple Mail (2.3608.40.2.2.4) 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, 15 Jan 2020 17:07:27 -0000 OK, let=E2=80=99s get pedantic then. The operation that would be needed here without the 63-bit restriction = is adding a 65-bit signed (delta) to a 64-bit unsigned (context SID), = with the constraint that the result (actual SID) fits into a 64-bit = unsigned. Unless you want to do error checking (which probably is a = good idea), this can be done entirely with 64-bit unsigned numbers, = simply ignoring the modulo wraparounds. Error checking then just = requires a few magnitude checks, which do require some scribbling on the = back of an envelope to get right. All CPU architectures of the last 40 = years (OK, maybe since the iAPX 432, which was 1981) that I know of make = it not hard to do these things. Platforms like the JVM do. CBOR=E2=80=99s "65-bit signed" (64-bit unsigned + sign bit in mt) = integer coverage is indeed surprising initially (it is until you start = to embrace bignums). =46rom the C language, implementers should be used = to the fact that as soon as you go to "signed 64-bit" (63-bit unsigned + = sign bit expressed as two=E2=80=99s complement), there are all kinds of = problems. Of course, not all C courses teach this=E2=80=A6 (The main = problem being that 64-bit is big enough that many implementers never = reach the boundaries of this space.) So the problem here really is in the platform or BKAC (between keyboard = and chair), not in the architecture... Gr=C3=BC=C3=9Fe, Carsten > On 2020-01-15, at 17:40, Rob Wilton (rwilton) = wrote: >=20 > =20 > =20 > > -----Original Message----- > > From: Carsten Bormann > > Sent: 15 January 2020 15:46 > > To: Rob Wilton (rwilton) > > Cc: Michael Richardson ; core@ietf.org > > Subject: Re: [core] progressing ietf-core-yang-cbor and = ietf-core-sid > > > > Yeah, but here the problem is in the head of the implementor and not = in > > the CPU architecture :-) > =20 > I'm not sure that I agree, =F0=9F=98=89 > =20 > I might be wrong, but most CPU architectures don't support 64 bit = negative values (unless you move to 128 bit signed numbers with the = corresponding performance overhead). Of course, implementors can work = around the architecture limitations by emulating 64 bit negative numbers = using unsigned 64 bit numbers ...=20 > =20 > =20 > In fact, I was wondering whether it is really a good thing that CBOR = allows a 64 bit negative integer to be expressed. It means that the = CBOR encoding can easily carry values that most implementations cannot = easily generate or represent. > =20 > So, I looked at the first available C implementation example at = https://cbor.io/impls.html, and it can't handle negative 64 bit numbers, = overflowing them into a long variable. I wonder what proportion of CBOR = implementations do handle these correctly ... Of course, I'm not = suggesting changing the spec, just a retrospective observation. > =20 > > I was not suggesting the text behind the > > substitutes to be included, this was just explanation why I=E2=80=99d = like to have > > the change. > [RW]=20 > Yes, but I think that "architectures" is probably the correct term = here, at least until we end up with CPUs with a 65 bit signed datapath, = although I have to confess that I doubt that the choice of word really = matters. =F0=9F=98=8A > =20 > Thanks, > Rob > =20 > =20 > =20 > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > On 2020-01-15, at 16:01, Rob Wilton (rwilton) = wrote: > > > > > > > > > > > >> -----Original Message----- > > >> From: core On Behalf Of Carsten Bormann > > >> Sent: 15 January 2020 13:35 > > >> To: Michael Richardson > > >> Cc: core@ietf.org > > >> Subject: Re: [core] progressing ietf-core-yang-cbor and = ietf-core-sid > > >> > > >> (No chair hat.) > > >> > > >> On 2020-01-13, at 19:11, Michael Richardson = > > wrote: > > >>> > > >>> The use of 63-bit unsigned integers allows SIDs to be = manipulated > > >>> more easily on architectures that might otherwise lack native > > >>> 64-bit > > >> unsigned arithmetic. > > >>> The loss a single bit of precision is not significant given the = size > > >>> of the space. > > >> > > >> s/use of/limitation to/ (we have been using them before) > > >> s/architectures/platforms/ (Java is our main problem here, no?) > > > [RW] > > > I think that it would be awkward for most languages/CPU = architectures, > > anywhere where you could end up with a negative number that is less = than > > 2^63. > > > > > > Yes, it is possible to write code in C or Java to handle this, but = my > > > hunch is that implementations could easily get this wrong (e.g. by > > > just using signed int64 as the type to hold the difference between > > > parent and child SIDs.) > > > > > > Thanks, > > > Rob > > > > > > > > >> s/precision/range/ s/space/remaining space/ > > >> > > >> Gr=C3=BC=C3=9Fe, Carsten > > >> > > >> _______________________________________________ > > >> core mailing list > > >> core@ietf.org > > >> https://www.ietf.org/mailman/listinfo/core From nobody Wed Jan 15 10:01: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 EA0AB1208C6 for ; Wed, 15 Jan 2020 10:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=k8GI/K/j; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SNnUfdZL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5plVqT_2Zub for ; Wed, 15 Jan 2020 10:00:58 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAAE21208BF for ; Wed, 15 Jan 2020 10:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36074; q=dns/txt; s=iport; t=1579111257; x=1580320857; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KirATHSNVqmonFe4LW3tRAhCnK35Gk7q/lrXBbUuFNQ=; b=k8GI/K/jla8oZdDU9oq+eUr93QHeYXaFh/Bw8X1ANO2KC3If/zbjd4wz O1jgKBlIdE5GbFNtiQbthkXv6xO1ZglmnPtcj3dtSQCu4PqiQsR2z4NbJ 4SRSKaia3Wa+xUbxqiDOIel3wUfUgdxSQpe7QC+oDmQR9Tl7ROudB6nvK k=; IronPort-PHdr: =?us-ascii?q?9a23=3Ay5YHWRW9EMIbvh2B2r3znst1jNjV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankgA8VGSFhj13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxCQDoUh9e/5NdJa1kHgELHIMgLyQ?= =?us-ascii?q?sBWxYIAQLKgqEBYNGA4p3gl+YDoJSA1QJAQEBDAEBGAEKCgIBAYFMgnQCF4F?= =?us-ascii?q?oJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECAQEBEBEKEwEBLAsBBAcEAgE?= =?us-ascii?q?GAg4DAQMBASEHAwICAiULFAMGCAIEDgUIGoMFgX1NAw4gAQIMi2WQZAKBOIh?= =?us-ascii?q?hdYEygn8BAQWFJhiCDQMGgTaMGBqBQT+BEUeCTD6CZAEBAYFkK4JjMoIsjTc?= =?us-ascii?q?ggnmFWYlwjy8KgjiHPYV6iRSabpc5kiMCBAIEBQIOAQEFgWkigVhwFTuCbB8?= =?us-ascii?q?xGA2IAQwXg1CCZIIwhT90gSmLJwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,323,1574121600"; d="scan'208,217";a="698006843" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jan 2020 18:00:43 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 00FI0h8M023375 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jan 2020 18:00:43 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, 15 Jan 2020 12:00:42 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 13:00:40 -0500 Received: from NAM11-CO1-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; Wed, 15 Jan 2020 13:00:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EORJ0KZ++JKbtdgtxrxFFFxm/Dzfj+N1ujATlNm6Kxwo5ZCAqEIc7UQTiBsthn9AXxPw2WrrPEURv6owgCS3e9fzzFAFbB26zVanAqMPknRFGjgB118lpFUx1CgkuYPSRlpWD0ivyGbIqL1aiQREbKSzmnJDEw6a4mSOzmYtKdU9cNkcNZ+wFQNFDkjl6lyukTo5lJuEng3jD7m+KhlO0DZmuPlnu1NNbBsvrkYS3zAbU/0/uskS9GsvC96m3Wt68N43eeDcC6xAP3uTobcIXtkzPslDoBt9R2Sw5hTXriuSAKvz0npSKjmdYajnOzue1RJ/Uq8iLuc/P7afm3QCkg== 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=KirATHSNVqmonFe4LW3tRAhCnK35Gk7q/lrXBbUuFNQ=; b=lDAE8Ju89sCeMyDqHrRPPKoRtgQeVmayXBgSZb1bdpweikZBfo2Yqe0nrv0SOydmxI6WFUKwoiGrU9OWJs4vLRp7fZp5xfsasdjwZHjZkRGCoeHRDAl2LlaJzc7/CiYPhV4g9zqGEkaxo8aPMMiTYhy9Sr7C8KnHP6mwcq92a8CHUZRj1yA1z01c3zOVnwu+XSMqJmpYvJEnlutEua2nDAGtBRRtbi2Zu7agtKkaofiBMN6zB3Ozk/Yuktf2Zl+7Yux6Or9v5Rws4hswnMJyplP86UjS1/Z/FjdL2WlsT3TiP4mmeKsASoJdxuR6lMOFGJKv9Vzypw+MXDsdjw3MQQ== 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=KirATHSNVqmonFe4LW3tRAhCnK35Gk7q/lrXBbUuFNQ=; b=SNnUfdZLN56IyUTAHwU6ezRH8jFnzGtnOMrxnnyNTv+m8VOKSwk1WjFdwZqnMyv8aH7E2I5GSwhR1Jlv3TP1VZ6XtuJ+K+90hHjk/WuNsHRNqtJMfpPuPR5beAvJjrWvqhscAoaxy9OpUYh02+jSZNrhQNgx5ReojX9ZcVzJHiA= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3568.namprd11.prod.outlook.com (20.178.251.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18; Wed, 15 Jan 2020 18:00:38 +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.2623.018; Wed, 15 Jan 2020 18:00:38 +0000 From: "Rob Wilton (rwilton)" To: Carsten Bormann CC: Michael Richardson , "core@ietf.org" Thread-Topic: [core] progressing ietf-core-yang-cbor and ietf-core-sid Thread-Index: AQHVurUJXZhJjcMJe0u46wy442FB/KfheU0AgAHZe4CAAM9xgIACJ0WAgAI7cgCAAH+BgIAC1zwAgAASRXCAABKKAIAAANaQgAAVwgCAAAE30A== Date: Wed, 15 Jan 2020 18:00:38 +0000 Message-ID: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> <46BA6719-5319-40FC-B218-5832F32C85BC@tzi.org> In-Reply-To: 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: b309ba25-12e5-4195-29d1-08d799e4d3de x-ms-traffictypediagnostic: MN2PR11MB3568: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(4636009)(396003)(39860400002)(376002)(136003)(366004)(346002)(189003)(199004)(71200400001)(8676002)(54906003)(478600001)(26005)(64756008)(81166006)(2906002)(5660300002)(53546011)(966005)(81156014)(6506007)(66446008)(66556008)(76116006)(66476007)(66946007)(21615005)(33656002)(6916009)(316002)(9686003)(7696005)(52536014)(4326008)(186003)(55016002)(86362001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3568; 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: 2CqvFKi0urcaqCkQBJR8asLUqsB0J4Ok+tfEgIdUfWdkvv9u2dHsZy1iyYZlv39fR++Pli+NMRBClJBVTivM7DM1qkOiV376uniROoeFlvIvdfa7cACqLFF3EyNqc0jY79UV2Er4ys8BspEG+BrwZWLcqdjh8TdIpKF1d3npvlW3bsPlNSl2KhfcGfWuRlI/tIXYkI5jxMlJqaic+B/Bs2lsKzcgerNOL6vncY8w3qowj+MzI0a5ISzmz702S2MnIOubkiiIN9VSY1pY3GTOVioN/BhwpA8AKEyFZ3NbF+Q54tQyuiIML/VY4Gxh5IR7JYDo+ag5Y95c/q6+zSOJL/dkHOK2ekPI7mcrly5x4sAY+wTPJw/i60e+7DPMD71inmmeAJFGTrxAG6d+llNLBjCRD5zCPFN+UqnkHSl6W5Yed89tY7VpsPYgelnTALYgU3NAUMxH7KLkmI7VlVUrPzbhVPSyXFSVjYZiFF5yFyTzbe0m6ful4p+SjDsZrylOt0hLa6P9ycf1ki457lfO3l8qSgXZlodDi9XA9PrREug= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43663AFE1492793F34DAA113B5370MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b309ba25-12e5-4195-29d1-08d799e4d3de X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 18:00:38.1330 (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: obhuVcCaxrW/NXnv8TeryrACuD7pxAKB+V/IJOrVLuPAqAeCQUUlpmgk62oa48aaMR33ELArFV+PdVlmEg67Cw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3568 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com 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, 15 Jan 2020 18:01:03 -0000 --_000_MN2PR11MB43663AFE1492793F34DAA113B5370MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogQ2Fyc3RlbiBC b3JtYW5uIDxjYWJvQHR6aS5vcmc+DQoNCj4gU2VudDogMTUgSmFudWFyeSAyMDIwIDE3OjA3DQoN Cj4gVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT4NCg0KPiBDYzog TWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBjb3JlQGlldGYub3Jn DQoNCj4gU3ViamVjdDogUmU6IFtjb3JlXSBwcm9ncmVzc2luZyBpZXRmLWNvcmUteWFuZy1jYm9y IGFuZCBpZXRmLWNvcmUtc2lkDQoNCj4NCg0KPiBPSywgbGV04oCZcyBnZXQgcGVkYW50aWMgdGhl bi4NCg0KW1JXXQ0KDQpJIGFtIG5vdCBiZWluZyBwZWRhbnRpYy4g8J+YiQ0KDQoNCg0KQ1BVIGFy Y2hpdGVjdHVyZXMgcmVhbGx5IGRvIG5vdCBuYXRpdmVseSBzdXBwb3J0IG5lZ2F0aXZlIDY0IGJp dCBpbnRlZ2VycywgYW5kIHlvdSBjYW4ndCBwcmV0ZW5kIHRoYXQgdGhleSBkbywgc28gbGV0J3Mg anVzdCBhdm9pZCB0aGVtLCBiZWNhdXNlIHdlIGRvbid0IG5lZWQgdGhlbSBhbmQgdGhleSB3aWxs IG9ubHkgY2F1c2UgYnVncy9taXN0YWtlcy4NCg0KDQoNCg0KDQo+DQoNCj4gVGhlIG9wZXJhdGlv biB0aGF0IHdvdWxkIGJlIG5lZWRlZCBoZXJlIHdpdGhvdXQgdGhlIDYzLWJpdCByZXN0cmljdGlv biBpcw0KDQo+IGFkZGluZyBhIDY1LWJpdCBzaWduZWQgKGRlbHRhKSB0byBhIDY0LWJpdCB1bnNp Z25lZCAoY29udGV4dCBTSUQpLCB3aXRoDQoNCj4gdGhlIGNvbnN0cmFpbnQgdGhhdCB0aGUgcmVz dWx0IChhY3R1YWwgU0lEKSBmaXRzIGludG8gYSA2NC1iaXQgdW5zaWduZWQuDQoNCj4gVW5sZXNz IHlvdSB3YW50IHRvIGRvIGVycm9yIGNoZWNraW5nICh3aGljaCBwcm9iYWJseSBpcyBhIGdvb2Qg aWRlYSksIHRoaXMNCg0KPiBjYW4gYmUgZG9uZSBlbnRpcmVseSB3aXRoIDY0LWJpdCB1bnNpZ25l ZCBudW1iZXJzLCBzaW1wbHkgaWdub3JpbmcgdGhlDQoNCj4gbW9kdWxvIHdyYXBhcm91bmRzLiAg RXJyb3IgY2hlY2tpbmcgdGhlbiBqdXN0IHJlcXVpcmVzIGEgZmV3IG1hZ25pdHVkZQ0KDQo+IGNo ZWNrcywgd2hpY2ggZG8gcmVxdWlyZSBzb21lIHNjcmliYmxpbmcgb24gdGhlIGJhY2sgb2YgYW4g ZW52ZWxvcGUgdG8gZ2V0DQoNCj4gcmlnaHQuDQoNCltSV10NCg0KDQoNCkkndmUgbm90IHNhaWQg dGhhdCBvbmUgY2FuJ3QgZW5jb2RlIHRoaXMsIGp1c3QgdGhhdCBpdCBiZWNvbWVzIG1vcmUgdHJp Y2t5IGFuZCBJIHByZWRpY3QgdGhhdCBwZW9wbGUgd2lsbCBnZXQgaXQgd3JvbmcsIG9yIGxpa2Vs eSBhc3N1bWUgdGhhdCBTSURzIGFyZSBvbmx5IDYzIGJpdHMuDQoNCg0KDQpFLmcuIHdoZW4gY29u c3RydWN0aW5nIHRoZSBTSUQgZGVsdGEgKGluIEMpIHlvdSBjYW4ndCBqdXN0IHN1YnRyYWN0IHRo ZSBjaGlsZCBTSUQgZnJvbSB0aGUgcGFyZW50IFNJRCBhbmQgY29udmVydCB0byBhIGNib3Igc2ln bmVkL3Vuc2lnbmVkIHZhbHVlLCBhbmQgZXhwZWN0IHRoZSByaWdodCB0aGluZyB0byBoYXBwZW4u ICBZb3UgaGF2ZSBmdXJ0aGVyIGFubm95YW5jZXMgaWYgeW91IHdhbnQgdG8gc3RvcmUgdGhlIFNJ RCBkZWx0YXMgaW4gaGVhcCBkYXRhIHN0cnVjdHVyZXMgZm9yIGFueSByZWFzb24uICBQZXJoYXBz IG5vYm9keSB3aWxsIGV2ZW4gd2FudC9uZWVkIHRvIGRvIHRoaXMsIGJ1dCBpdCBzZWVtcyBwbGF1 c2libGUgdGhhdCB0aGV5IG1pZ2h0Lg0KDQoNCg0KDQoNCj4gQWxsIENQVSBhcmNoaXRlY3R1cmVz IG9mIHRoZSBsYXN0IDQwIHllYXJzIChPSywgbWF5YmUgc2luY2UgdGhlDQoNCj4gaUFQWCA0MzIs IHdoaWNoIHdhcyAxOTgxKSB0aGF0IEkga25vdyBvZiBtYWtlIGl0IG5vdCBoYXJkIHRvIGRvIHRo ZXNlDQoNCj4gdGhpbmdzLg0KDQpbUlddDQoNCkkgcmVzcGVjdGl2ZWx5IGRpc2FncmVlLg0KDQoN Cg0KSGF2aW5nIHNlZW4gdGhlIGhhcmQgdG8gZGVidWcgYnVncyB3aGVuIHNtYXJ0IGV4cGVyaWVu Y2VkIHNvZnR3YXJlIGVuZ2luZWVycyB3ZXJlIG5vdCBjYXJlZnVsIGVub3VnaCB3aXRoIEMncyBo YW5kbGluZyBvZiBzaWduZWQgYW5kIHVuc2lnbmVkIGludGVnZXJzIGRlZmluaXRlbHkgcHV0cyBt ZSBpbnRvIHRoZSBjYW1wIHRoYXQgSmF2YSBnb3QgdGhpcyByaWdodCwgYW5kIHRoYXQgaXQgaXMg dW5zaWduZWQgYXJpdGhtZXRpYyB0aGF0IGZvbGtzIHN0cnVnZ2xlIHRvIGNvbnNpc3RlbnRseSBn ZXQgcmlnaHQuDQoNCg0KDQo+IFBsYXRmb3JtcyBsaWtlIHRoZSBKVk0gZG8uDQoNCj4NCg0KPiBD Qk9S4oCZcyAiNjUtYml0IHNpZ25lZCIgKDY0LWJpdCB1bnNpZ25lZCArIHNpZ24gYml0IGluIG10 KSBpbnRlZ2VyIGNvdmVyYWdlDQoNCj4gaXMgaW5kZWVkIHN1cnByaXNpbmcgaW5pdGlhbGx5IChp dCBpcyB1bnRpbCB5b3Ugc3RhcnQgdG8gZW1icmFjZSBiaWdudW1zKS4NCg0KPiBGcm9tIHRoZSBD IGxhbmd1YWdlLCBpbXBsZW1lbnRlcnMgc2hvdWxkIGJlIHVzZWQgdG8gdGhlIGZhY3QgdGhhdCBh cyBzb29uDQoNCj4gYXMgeW91IGdvIHRvICJzaWduZWQgNjQtYml0IiAoNjMtYml0IHVuc2lnbmVk ICsgc2lnbiBiaXQgZXhwcmVzc2VkIGFzDQoNCj4gdHdv4oCZcyBjb21wbGVtZW50KSwgdGhlcmUg YXJlIGFsbCBraW5kcyBvZiBwcm9ibGVtcy4gIE9mIGNvdXJzZSwgbm90IGFsbCBDDQoNCj4gY291 cnNlcyB0ZWFjaCB0aGlz4oCmICAoVGhlIG1haW4gcHJvYmxlbSBiZWluZyB0aGF0IDY0LWJpdCBp cyBiaWcgZW5vdWdoDQoNCj4gdGhhdCBtYW55IGltcGxlbWVudGVycyBuZXZlciByZWFjaCB0aGUg Ym91bmRhcmllcyBvZiB0aGlzIHNwYWNlLikNCg0KW1JXXQ0KDQpPa2F5LCBidXQgSSdtIG9mIHRo ZSBvcGluaW9uIHRoYXQgc2lnbmVkIHR5cGVzIGFyZSB0aGUgc2FuZSBvbmVzLCBhbmQgaXQgaXMg dW5zaWduZWQgdHlwZXMgdGhhdCBkbyBzdXJwcmlzaW5nIHRoaW5ncyAobm9ybWFsbHkgd2l0aCB1 bmFudGljaXBhdGVkIHVuZGVyZmxvdyBkdWUgdG8gc3VidHJhY3Rpb24gYW5kIG1vZHVsbyBhcml0 aG1ldGljKS4NCg0KDQoNCg0KDQo+DQoNCj4gU28gdGhlIHByb2JsZW0gaGVyZSByZWFsbHkgaXMg aW4gdGhlIHBsYXRmb3JtIG9yIEJLQUMgKGJldHdlZW4ga2V5Ym9hcmQNCg0KPiBhbmQgY2hhaXIp LCBub3QgaW4gdGhlIGFyY2hpdGVjdHVyZS4uLg0KDQpbUlddDQoNCkFzIHBlciBhYm92ZSwgSSB0 aGluayB0aGF0IHdlIGRpc2FncmVlIG9uIHRoaXMgcG9pbnQuICBCdXQgcmVhbGx5IG5vdCBzdXJl IGl0IGlzIHdvcnRoIHNwZW5kaW5nIG1vcmUgdGltZSBvbiAuLi4NCg0KDQoNCktpbmQgcmVnYXJk cywNClJvYg0KDQoNCg0KDQoNCg0KDQo+DQoNCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KDQo+DQoNCj4N Cg0KPiA+IE9uIDIwMjAtMDEtMTUsIGF0IDE3OjQwLCBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndp bHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4gd3JvdGU6DQoNCj4gPg0K DQo+ID4NCg0KPiA+DQoNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gPiA+ IEZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPG1haWx0bzpjYWJvQHR6aS5vcmc+ Pg0KDQo+ID4gPiBTZW50OiAxNSBKYW51YXJ5IDIwMjAgMTU6NDYNCg0KPiA+ID4gVG86IFJvYiBX aWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5j b20+Pg0KDQo+ID4gPiBDYzogTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4u Y2E8bWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5jYT4+OyBjb3JlQGlldGYub3JnPG1haWx0bzpj b3JlQGlldGYub3JnPg0KDQo+ID4gPiBTdWJqZWN0OiBSZTogW2NvcmVdIHByb2dyZXNzaW5nIGll dGYtY29yZS15YW5nLWNib3IgYW5kDQoNCj4gPiA+IGlldGYtY29yZS1zaWQNCg0KPiA+ID4NCg0K PiA+ID4gWWVhaCwgYnV0IGhlcmUgdGhlIHByb2JsZW0gaXMgaW4gdGhlIGhlYWQgb2YgdGhlIGlt cGxlbWVudG9yIGFuZCBub3QNCg0KPiA+ID4gaW4gdGhlIENQVSBhcmNoaXRlY3R1cmUgOi0pDQoN Cj4gPg0KDQo+ID4gSSdtIG5vdCBzdXJlIHRoYXQgSSBhZ3JlZSwg8J+YiQ0KDQo+ID4NCg0KPiA+ IEkgbWlnaHQgYmUgd3JvbmcsIGJ1dCBtb3N0IENQVSBhcmNoaXRlY3R1cmVzIGRvbid0IHN1cHBv cnQgNjQgYml0DQoNCj4gbmVnYXRpdmUgdmFsdWVzICh1bmxlc3MgeW91IG1vdmUgdG8gMTI4IGJp dCBzaWduZWQgbnVtYmVycyB3aXRoIHRoZQ0KDQo+IGNvcnJlc3BvbmRpbmcgcGVyZm9ybWFuY2Ug b3ZlcmhlYWQpLiAgT2YgY291cnNlLCBpbXBsZW1lbnRvcnMgY2FuIHdvcmsNCg0KPiBhcm91bmQg dGhlIGFyY2hpdGVjdHVyZSBsaW1pdGF0aW9ucyBieSBlbXVsYXRpbmcgNjQgYml0IG5lZ2F0aXZl IG51bWJlcnMNCg0KPiB1c2luZyB1bnNpZ25lZCA2NCBiaXQgbnVtYmVycyAuLi4NCg0KPiA+DQoN Cj4gPg0KDQo+ID4gSW4gZmFjdCwgSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgaXQgaXMgcmVhbGx5 IGEgZ29vZCB0aGluZyB0aGF0IENCT1INCg0KPiBhbGxvd3MgYSA2NCBiaXQgbmVnYXRpdmUgaW50 ZWdlciB0byBiZSBleHByZXNzZWQuICBJdCBtZWFucyB0aGF0IHRoZSBDQk9SDQoNCj4gZW5jb2Rp bmcgY2FuIGVhc2lseSBjYXJyeSB2YWx1ZXMgdGhhdCBtb3N0IGltcGxlbWVudGF0aW9ucyBjYW5u b3QgZWFzaWx5DQoNCj4gZ2VuZXJhdGUgb3IgcmVwcmVzZW50Lg0KDQo+ID4NCg0KPiA+IFNvLCBJ IGxvb2tlZCBhdCB0aGUgZmlyc3QgYXZhaWxhYmxlIEMgaW1wbGVtZW50YXRpb24gZXhhbXBsZSBh dA0KDQo+IGh0dHBzOi8vY2Jvci5pby9pbXBscy5odG1sLCBhbmQgaXQgY2FuJ3QgaGFuZGxlIG5l Z2F0aXZlIDY0IGJpdCBudW1iZXJzLA0KDQo+IG92ZXJmbG93aW5nIHRoZW0gaW50byBhIGxvbmcg dmFyaWFibGUuICBJIHdvbmRlciB3aGF0IHByb3BvcnRpb24gb2YgQ0JPUg0KDQo+IGltcGxlbWVu dGF0aW9ucyBkbyBoYW5kbGUgdGhlc2UgY29ycmVjdGx5IC4uLiAgT2YgY291cnNlLCBJJ20gbm90 DQoNCj4gc3VnZ2VzdGluZyBjaGFuZ2luZyB0aGUgc3BlYywganVzdCBhIHJldHJvc3BlY3RpdmUg b2JzZXJ2YXRpb24uDQoNCj4gPg0KDQo+ID4gPiBJIHdhcyBub3Qgc3VnZ2VzdGluZyB0aGUgdGV4 dCBiZWhpbmQgdGhlIHN1YnN0aXR1dGVzIHRvIGJlIGluY2x1ZGVkLA0KDQo+ID4gPiB0aGlzIHdh cyBqdXN0IGV4cGxhbmF0aW9uIHdoeSBJ4oCZZCBsaWtlIHRvIGhhdmUgdGhlIGNoYW5nZS4NCg0K PiA+IFtSV10NCg0KPiA+IFllcywgYnV0IEkgdGhpbmsgdGhhdCAiYXJjaGl0ZWN0dXJlcyIgaXMg cHJvYmFibHkgdGhlIGNvcnJlY3QgdGVybQ0KDQo+ID4gaGVyZSwgYXQgbGVhc3QgdW50aWwgd2Ug ZW5kIHVwIHdpdGggQ1BVcyB3aXRoIGEgNjUgYml0IHNpZ25lZA0KDQo+ID4gZGF0YXBhdGgsIGFs dGhvdWdoIEkgaGF2ZSB0byBjb25mZXNzIHRoYXQgSSBkb3VidCB0aGF0IHRoZSBjaG9pY2Ugb2YN Cg0KPiA+IHdvcmQgcmVhbGx5IG1hdHRlcnMuIPCfmIoNCg0KPiA+DQoNCj4gPiBUaGFua3MsDQoN Cj4gPiBSb2INCg0KPiA+DQoNCj4gPg0KDQo+ID4NCg0KPiA+ID4NCg0KPiA+ID4gR3LDvMOfZSwg Q2Fyc3Rlbg0KDQo+ID4gPg0KDQo+ID4gPg0KDQo+ID4gPiA+IE9uIDIwMjAtMDEtMTUsIGF0IDE2 OjAxLCBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0 b25AY2lzY28uY29tPj4NCg0KPiB3cm90ZToNCg0KPiA+ID4gPg0KDQo+ID4gPiA+DQoNCj4gPiA+ ID4NCg0KPiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiA+ID4gPj4gRnJv bTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5v cmc+PiBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQoNCj4gPiA+ID4+IFNlbnQ6IDE1IEph bnVhcnkgMjAyMCAxMzozNQ0KDQo+ID4gPiA+PiBUbzogTWljaGFlbCBSaWNoYXJkc29uIDxtY3Ir aWV0ZkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5jYT4+DQoNCj4gPiA+ ID4+IENjOiBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KDQo+ID4gPiA+PiBT dWJqZWN0OiBSZTogW2NvcmVdIHByb2dyZXNzaW5nIGlldGYtY29yZS15YW5nLWNib3IgYW5kDQoN Cj4gPiA+ID4+IGlldGYtY29yZS1zaWQNCg0KPiA+ID4gPj4NCg0KPiA+ID4gPj4gKE5vIGNoYWly IGhhdC4pDQoNCj4gPiA+ID4+DQoNCj4gPiA+ID4+IE9uIDIwMjAtMDEtMTMsIGF0IDE5OjExLCBN aWNoYWVsIFJpY2hhcmRzb24NCg0KPiA+ID4gPj4gPG1jcitpZXRmQHNhbmRlbG1hbi5jYTxtYWls dG86bWNyK2lldGZAc2FuZGVsbWFuLmNhPj4NCg0KPiA+ID4gd3JvdGU6DQoNCj4gPiA+ID4+Pg0K DQo+ID4gPiA+Pj4gVGhlIHVzZSBvZiA2My1iaXQgdW5zaWduZWQgaW50ZWdlcnMgYWxsb3dzIFNJ RHMgdG8gYmUNCg0KPiA+ID4gPj4+IG1hbmlwdWxhdGVkIG1vcmUgZWFzaWx5ICBvbiBhcmNoaXRl Y3R1cmVzIHRoYXQgbWlnaHQgb3RoZXJ3aXNlDQoNCj4gPiA+ID4+PiBsYWNrIG5hdGl2ZSA2NC1i aXQNCg0KPiA+ID4gPj4gdW5zaWduZWQgYXJpdGhtZXRpYy4NCg0KPiA+ID4gPj4+IFRoZSBsb3Nz IGEgc2luZ2xlIGJpdCBvZiBwcmVjaXNpb24gaXMgbm90IHNpZ25pZmljYW50IGdpdmVuIHRoZQ0K DQo+ID4gPiA+Pj4gc2l6ZSBvZiB0aGUgIHNwYWNlLg0KDQo+ID4gPiA+Pg0KDQo+ID4gPiA+PiBz L3VzZSBvZi9saW1pdGF0aW9uIHRvLyAgICAgKHdlIGhhdmUgYmVlbiB1c2luZyB0aGVtIGJlZm9y ZSkNCg0KPiA+ID4gPj4gcy9hcmNoaXRlY3R1cmVzL3BsYXRmb3Jtcy8gIChKYXZhIGlzIG91ciBt YWluIHByb2JsZW0gaGVyZSwgbm8/KQ0KDQo+ID4gPiA+IFtSV10NCg0KPiA+ID4gPiBJIHRoaW5r IHRoYXQgaXQgd291bGQgYmUgYXdrd2FyZCBmb3IgbW9zdCBsYW5ndWFnZXMvQ1BVDQoNCj4gPiA+ ID4gYXJjaGl0ZWN0dXJlcywNCg0KPiA+ID4gYW55d2hlcmUgd2hlcmUgeW91IGNvdWxkIGVuZCB1 cCB3aXRoIGEgbmVnYXRpdmUgbnVtYmVyIHRoYXQgaXMgbGVzcw0KDQo+ID4gPiB0aGFuIDJeNjMu DQoNCj4gPiA+ID4NCg0KPiA+ID4gPiBZZXMsIGl0IGlzIHBvc3NpYmxlIHRvIHdyaXRlIGNvZGUg aW4gQyBvciBKYXZhIHRvIGhhbmRsZSB0aGlzLCBidXQNCg0KPiA+ID4gPiBteSBodW5jaCBpcyB0 aGF0IGltcGxlbWVudGF0aW9ucyBjb3VsZCBlYXNpbHkgZ2V0IHRoaXMgd3JvbmcgKGUuZy4NCg0K PiA+ID4gPiBieSBqdXN0IHVzaW5nIHNpZ25lZCBpbnQ2NCBhcyB0aGUgdHlwZSB0byBob2xkIHRo ZSBkaWZmZXJlbmNlDQoNCj4gPiA+ID4gYmV0d2VlbiBwYXJlbnQgYW5kIGNoaWxkIFNJRHMuKQ0K DQo+ID4gPiA+DQoNCj4gPiA+ID4gVGhhbmtzLA0KDQo+ID4gPiA+IFJvYg0KDQo+ID4gPiA+DQoN Cj4gPiA+ID4NCg0KPiA+ID4gPj4gcy9wcmVjaXNpb24vcmFuZ2UvIHMvc3BhY2UvcmVtYWluaW5n IHNwYWNlLw0KDQo+ID4gPiA+Pg0KDQo+ID4gPiA+PiBHcsO8w59lLCBDYXJzdGVuDQoNCj4gPiA+ ID4+DQoNCj4gPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCj4gPiA+ID4+IGNvcmUgbWFpbGluZyBsaXN0DQoNCj4gPiA+ID4+IGNvcmVAaWV0 Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQoNCj4gPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQoNCg== --_000_MN2PR11MB43663AFE1492793F34DAA113B5370MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9z ZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29u c29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFp blRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCAxMDIuNTVwdCA3Mi4wcHQgMTAyLjU1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1H QiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tR0IiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1HQiI+RnJvbTogQ2Fyc3RlbiBCb3JtYW5uICZsdDtjYWJvQHR6aS5v cmcmZ3Q7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+U2VudDogMTUgSmFu dWFyeSAyMDIwIDE3OjA3PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+VG86 IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZndDs8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5DYzogTWljaGFlbCBSaWNoYXJkc29uICZsdDtt Y3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhJmd0OzsgY29yZUBpZXRmLm9yZzwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPlN1YmplY3Q6IFJlOiBbY29yZV0gcHJvZ3Jlc3Npbmcg aWV0Zi1jb3JlLXlhbmctY2JvciBhbmQgaWV0Zi1jb3JlLXNpZDwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg T0ssIGxldOKAmXMgZ2V0IHBlZGFudGljIHRoZW4uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5bUlddIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBhbSBu b3QgYmVpbmcgcGVkYW50aWMuIDwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mIzEyODUyMTs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5DUFUgYXJjaGl0ZWN0dXJlcyByZWFsbHkgZG8gbm90IG5h dGl2ZWx5IHN1cHBvcnQgbmVnYXRpdmUgNjQgYml0IGludGVnZXJzLCBhbmQgeW91IGNhbid0IHBy ZXRlbmQgdGhhdCB0aGV5IGRvLCBzbyBsZXQncyBqdXN0IGF2b2lkIHRoZW0sIGJlY2F1c2Ugd2Ug ZG9uJ3QgbmVlZCB0aGVtIGFuZCB0aGV5IHdpbGwgb25seSBjYXVzZSBidWdzL21pc3Rha2VzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgVGhlIG9wZXJhdGlvbiB0aGF0IHdvdWxkIGJlIG5lZWRlZCBoZXJl IHdpdGhvdXQgdGhlIDYzLWJpdCByZXN0cmljdGlvbiBpczwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgYWRkaW5nIGEgNjUtYml0IHNpZ25lZCAoZGVsdGEpIHRvIGEgNjQtYml0IHVu c2lnbmVkIChjb250ZXh0IFNJRCksIHdpdGg8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IHRoZSBjb25zdHJhaW50IHRoYXQgdGhlIHJlc3VsdCAoYWN0dWFsIFNJRCkgZml0cyBpbnRv IGEgNjQtYml0IHVuc2lnbmVkLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVW5s ZXNzIHlvdSB3YW50IHRvIGRvIGVycm9yIGNoZWNraW5nICh3aGljaCBwcm9iYWJseSBpcyBhIGdv b2QgaWRlYSksIHRoaXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGNhbiBiZSBk b25lIGVudGlyZWx5IHdpdGggNjQtYml0IHVuc2lnbmVkIG51bWJlcnMsIHNpbXBseSBpZ25vcmlu ZyB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG1vZHVsbyB3cmFwYXJvdW5k cy4mbmJzcDsgRXJyb3IgY2hlY2tpbmcgdGhlbiBqdXN0IHJlcXVpcmVzIGEgZmV3IG1hZ25pdHVk ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgY2hlY2tzLCB3aGljaCBkbyByZXF1 aXJlIHNvbWUgc2NyaWJibGluZyBvbiB0aGUgYmFjayBvZiBhbiBlbnZlbG9wZSB0byBnZXQ8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHJpZ2h0LiZuYnNwOyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPltSV10gPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkkndmUgbm90IHNhaWQgdGhhdCBvbmUgY2FuJ3QgZW5jb2RlIHRoaXMsIGp1c3QgdGhh dCBpdCBiZWNvbWVzIG1vcmUgdHJpY2t5IGFuZCBJIHByZWRpY3QgdGhhdCBwZW9wbGUgd2lsbCBn ZXQgaXQgd3JvbmcsIG9yIGxpa2VseSBhc3N1bWUgdGhhdCBTSURzIGFyZSBvbmx5IDYzIGJpdHMu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkUuZy4gd2hlbiBjb25zdHJ1Y3RpbmcgdGhl IFNJRCBkZWx0YSAoaW4gQykgeW91IGNhbid0IGp1c3Qgc3VidHJhY3QgdGhlIGNoaWxkIFNJRCBm cm9tIHRoZSBwYXJlbnQgU0lEIGFuZCBjb252ZXJ0IHRvIGEgY2JvciBzaWduZWQvdW5zaWduZWQg dmFsdWUsIGFuZCBleHBlY3QgdGhlIHJpZ2h0IHRoaW5nIHRvIGhhcHBlbi4mbmJzcDsgWW91IGhh dmUgZnVydGhlciBhbm5veWFuY2VzIGlmIHlvdSB3YW50IHRvIHN0b3JlDQogdGhlIFNJRCBkZWx0 YXMgaW4gaGVhcCBkYXRhIHN0cnVjdHVyZXMgZm9yIGFueSByZWFzb24uJm5ic3A7IFBlcmhhcHMg bm9ib2R5IHdpbGwgZXZlbiB3YW50L25lZWQgdG8gZG8gdGhpcywgYnV0IGl0IHNlZW1zIHBsYXVz aWJsZSB0aGF0IHRoZXkgbWlnaHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBBbGwgQ1BVIGFy Y2hpdGVjdHVyZXMgb2YgdGhlIGxhc3QgNDAgeWVhcnMgKE9LLCBtYXliZSBzaW5jZSB0aGU8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGlBUFggNDMyLCB3aGljaCB3YXMgMTk4MSkg dGhhdCBJIGtub3cgb2YgbWFrZSBpdCBub3QgaGFyZCB0byBkbyB0aGVzZTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgdGhpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+W1JXXSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkkgcmVzcGVjdGl2ZWx5IGRpc2FncmVlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5I YXZpbmcgc2VlbiB0aGUgaGFyZCB0byBkZWJ1ZyBidWdzIHdoZW4gc21hcnQgZXhwZXJpZW5jZWQg c29mdHdhcmUgZW5naW5lZXJzIHdlcmUgbm90IGNhcmVmdWwgZW5vdWdoIHdpdGggQydzIGhhbmRs aW5nIG9mIHNpZ25lZCBhbmQgdW5zaWduZWQgaW50ZWdlcnMgZGVmaW5pdGVseSBwdXRzIG1lIGlu dG8gdGhlIGNhbXAgdGhhdCBKYXZhIGdvdCB0aGlzIHJpZ2h0LCBhbmQgdGhhdCBpdCBpcyB1bnNp Z25lZA0KIGFyaXRobWV0aWMgdGhhdCBmb2xrcyBzdHJ1Z2dsZSB0byBjb25zaXN0ZW50bHkgZ2V0 IHJpZ2h0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFBsYXRmb3JtcyBsaWtl IHRoZSBKVk0gZG8uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ0JPUuKAmXMgJnF1b3Q7NjUtYml0 IHNpZ25lZCZxdW90OyAoNjQtYml0IHVuc2lnbmVkICYjNDM7IHNpZ24gYml0IGluIG10KSBpbnRl Z2VyIGNvdmVyYWdlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBpcyBpbmRlZWQg c3VycHJpc2luZyBpbml0aWFsbHkgKGl0IGlzIHVudGlsIHlvdSBzdGFydCB0byBlbWJyYWNlIGJp Z251bXMpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBGcm9t IHRoZSBDIGxhbmd1YWdlLCBpbXBsZW1lbnRlcnMgc2hvdWxkIGJlIHVzZWQgdG8gdGhlIGZhY3Qg dGhhdCBhcyBzb29uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhcyB5b3UgZ28g dG8gJnF1b3Q7c2lnbmVkIDY0LWJpdCZxdW90OyAoNjMtYml0IHVuc2lnbmVkICYjNDM7IHNpZ24g Yml0IGV4cHJlc3NlZCBhczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdHdv4oCZ cyBjb21wbGVtZW50KSwgdGhlcmUgYXJlIGFsbCBraW5kcyBvZiBwcm9ibGVtcy4mbmJzcDsgT2Yg Y291cnNlLCBub3QgYWxsIEM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGNvdXJz ZXMgdGVhY2ggdGhpc+KApiZuYnNwOyAoVGhlIG1haW4gcHJvYmxlbSBiZWluZyB0aGF0IDY0LWJp dCBpcyBiaWcgZW5vdWdoPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGF0IG1h bnkgaW1wbGVtZW50ZXJzIG5ldmVyIHJlYWNoIHRoZSBib3VuZGFyaWVzIG9mIHRoaXMgc3BhY2Uu KTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ W1JXXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+T2theSwgYnV0IEknbSBvZiB0aGUgb3BpbmlvbiB0aGF0IHNp Z25lZCB0eXBlcyBhcmUgdGhlIHNhbmUgb25lcywgYW5kIGl0IGlzIHVuc2lnbmVkIHR5cGVzIHRo YXQgZG8gc3VycHJpc2luZyB0aGluZ3MgKG5vcm1hbGx5IHdpdGggdW5hbnRpY2lwYXRlZCB1bmRl cmZsb3cgZHVlIHRvIHN1YnRyYWN0aW9uIGFuZCBtb2R1bG8gYXJpdGhtZXRpYykuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBTbyB0aGUgcHJvYmxlbSBoZXJlIHJlYWxseSBpcyBpbiB0aGUgcGxhdGZvcm0g b3IgQktBQyAoYmV0d2VlbiBrZXlib2FyZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgYW5kIGNoYWlyKSwgbm90IGluIHRoZSBhcmNoaXRlY3R1cmUuLi48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPltSV10gPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5BcyBwZXIgYWJvdmUsIEkgdGhpbmsgdGhhdCB3ZSBkaXNhZ3JlZSBvbiB0aGlzIHBvaW50 LiZuYnNwOyBCdXQgcmVhbGx5IG5vdCBzdXJlIGl0IGlzIHdvcnRoIHNwZW5kaW5nIG1vcmUgdGlt ZSBvbiAuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+S2luZCByZWdh cmRzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBH csO8w59lLCBDYXJzdGVuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyBPbiAyMDIwLTAxLTE1LCBhdCAxNzo0MCwgUm9iIFdpbHRvbiAocndpbHRvbikg Jmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnJ3aWx0b25AY2lzY28uY29tPC9zcGFu PjwvYT4mZ3Q7IHdyb3RlOjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0Ozwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7ICZndDsgRnJvbTogQ2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJt YWlsdG86Y2Fib0B0emkub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+Y2Fib0B0emkub3JnPC9zcGFuPjwvYT4mZ3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgU2VudDogMTUgSmFudWFyeSAyMDIwIDE1OjQ2 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgVG86IFJvYiBXaWx0 b24gKHJ3aWx0b24pICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5yd2lsdG9uQGNp c2NvLmNvbTwvc3Bhbj48L2E+Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmZ3Q7IENjOiBNaWNoYWVsIFJpY2hhcmRzb24gJmx0OzxhIGhyZWY9Im1haWx0bzptY3Im IzQzO2lldGZAc2FuZGVsbWFuLmNhIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYTwvc3Bhbj48L2E+Jmd0 OzsNCjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Y29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtj b3JlXSBwcm9ncmVzc2luZyBpZXRmLWNvcmUteWFuZy1jYm9yIGFuZDwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IGlldGYtY29yZS1zaWQ8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAmZ3Q7IFllYWgsIGJ1dCBoZXJlIHRoZSBwcm9ibGVtIGlzIGluIHRoZSBoZWFk IG9mIHRoZSBpbXBsZW1lbnRvciBhbmQgbm90PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7ICZndDsgaW4gdGhlIENQVSBhcmNoaXRlY3R1cmUgOi0pPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7IEknbSBub3Qgc3VyZSB0aGF0IEkgYWdyZWUsIDxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4NCiYjMTI4NTIxOzwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgSSBtaWdodCBiZSB3cm9uZywgYnV0IG1vc3QgQ1BVIGFy Y2hpdGVjdHVyZXMgZG9uJ3Qgc3VwcG9ydCA2NCBiaXQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IG5lZ2F0aXZlIHZhbHVlcyAodW5sZXNzIHlvdSBtb3ZlIHRvIDEyOCBiaXQgc2ln bmVkIG51bWJlcnMgd2l0aCB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGNv cnJlc3BvbmRpbmcgcGVyZm9ybWFuY2Ugb3ZlcmhlYWQpLiZuYnNwOyBPZiBjb3Vyc2UsIGltcGxl bWVudG9ycyBjYW4gd29yazwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYXJvdW5k IHRoZSBhcmNoaXRlY3R1cmUgbGltaXRhdGlvbnMgYnkgZW11bGF0aW5nIDY0IGJpdCBuZWdhdGl2 ZSBudW1iZXJzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB1c2luZyB1bnNpZ25l ZCA2NCBiaXQgbnVtYmVycyAuLi48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgSW4gZmFjdCwgSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIg aXQgaXMgcmVhbGx5IGEgZ29vZCB0aGluZyB0aGF0IENCT1I8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IGFsbG93cyBhIDY0IGJpdCBuZWdhdGl2ZSBpbnRlZ2VyIHRvIGJlIGV4cHJl c3NlZC4mbmJzcDsgSXQgbWVhbnMgdGhhdCB0aGUgQ0JPUjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgZW5jb2RpbmcgY2FuIGVhc2lseSBjYXJyeSB2YWx1ZXMgdGhhdCBtb3N0IGlt cGxlbWVudGF0aW9ucyBjYW5ub3QgZWFzaWx5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBnZW5lcmF0ZSBvciByZXByZXNlbnQuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IFNvLCBJIGxv b2tlZCBhdCB0aGUgZmlyc3QgYXZhaWxhYmxlIEMgaW1wbGVtZW50YXRpb24gZXhhbXBsZSBhdDwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9jYm9yLmlv L2ltcGxzLmh0bWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5odHRwczovL2Nib3IuaW8vaW1wbHMuaHRtbDwvc3Bhbj48L2E+LCBhbmQgaXQgY2Fu J3QgaGFuZGxlIG5lZ2F0aXZlIDY0IGJpdCBudW1iZXJzLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgb3ZlcmZsb3dpbmcgdGhlbSBpbnRvIGEgbG9uZyB2YXJpYWJsZS4mbmJzcDsg SSB3b25kZXIgd2hhdCBwcm9wb3J0aW9uIG9mIENCT1I8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IGltcGxlbWVudGF0aW9ucyBkbyBoYW5kbGUgdGhlc2UgY29ycmVjdGx5IC4uLiZu YnNwOyBPZiBjb3Vyc2UsIEknbSBub3Q8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IHN1Z2dlc3RpbmcgY2hhbmdpbmcgdGhlIHNwZWMsIGp1c3QgYSByZXRyb3NwZWN0aXZlIG9ic2Vy dmF0aW9uLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IEkgd2FzIG5vdCBzdWdnZXN0aW5nIHRo ZSB0ZXh0IGJlaGluZCB0aGUgc3Vic3RpdHV0ZXMgdG8gYmUgaW5jbHVkZWQsPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgdGhpcyB3YXMganVzdCBleHBsYW5hdGlv biB3aHkgSeKAmWQgbGlrZSB0byBoYXZlIHRoZSBjaGFuZ2UuPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7IFtSV108L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgWWVzLCBidXQgSSB0aGluayB0aGF0ICZxdW90O2FyY2hpdGVjdHVyZXMmcXVvdDsgaXMg cHJvYmFibHkgdGhlIGNvcnJlY3QgdGVybTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyBoZXJlLCBhdCBsZWFzdCB1bnRpbCB3ZSBlbmQgdXAgd2l0aCBDUFVzIHdpdGggYSA2 NSBiaXQgc2lnbmVkPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGRhdGFw YXRoLCBhbHRob3VnaCBJIGhhdmUgdG8gY29uZmVzcyB0aGF0IEkgZG91YnQgdGhhdCB0aGUgY2hv aWNlIG9mPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IHdvcmQgcmVhbGx5 IG1hdHRlcnMuIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZx dW90OyxzYW5zLXNlcmlmIj4NCiYjMTI4NTIyOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg VGhhbmtzLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBSb2I8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IEdyw7zDn2UsIENhcnN0ZW48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyBPbiAyMDIwLTAxLTE1LCBhdCAxNjowMSwgUm9iIFdpbHRvbiAocndpbHRvbikg Jmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnJ3aWx0b25AY2lzY28uY29tPC9zcGFu PjwvYT4mZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB3cm90ZTo8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IEZyb206IGNvcmUg Jmx0OzxhIGhyZWY9Im1haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5jb3JlLWJvdW5jZXNAaWV0Zi5v cmc8L3NwYW4+PC9hPiZndDsgT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IDE1IEphbnVh cnkgMjAyMCAxMzozNTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7 ICZndDsmZ3Q7IFRvOiBNaWNoYWVsIFJpY2hhcmRzb24gJmx0OzxhIGhyZWY9Im1haWx0bzptY3Im IzQzO2lldGZAc2FuZGVsbWFuLmNhIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYTwvc3Bhbj48L2E+Jmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IENj OiA8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6 IFJlOiBbY29yZV0gcHJvZ3Jlc3NpbmcgaWV0Zi1jb3JlLXlhbmctY2JvciBhbmQ8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBpZXRmLWNvcmUtc2lk PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAoTm8gY2hh aXIgaGF0Lik8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7 IE9uIDIwMjAtMDEtMTMsIGF0IDE5OjExLCBNaWNoYWVsIFJpY2hhcmRzb248L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5tY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhPC9zcGFu PjwvYT4mZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgd3Jv dGU6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7IFRoZSB1c2Ugb2YgNjMtYml0IHVuc2lnbmVkIGludGVnZXJzIGFsbG93cyBTSURzIHRvIGJl PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7 IG1hbmlwdWxhdGVkIG1vcmUgZWFzaWx5Jm5ic3A7IG9uIGFyY2hpdGVjdHVyZXMgdGhhdCBtaWdo dCBvdGhlcndpc2U8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAm Z3Q7Jmd0OyZndDsgbGFjayBuYXRpdmUgNjQtYml0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgdW5zaWduZWQgYXJpdGhtZXRpYy48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgVGhlIGxvc3Mg YSBzaW5nbGUgYml0IG9mIHByZWNpc2lvbiBpcyBub3Qgc2lnbmlmaWNhbnQgZ2l2ZW4gdGhlPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHNp emUgb2YgdGhlJm5ic3A7IHNwYWNlLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyZndDsgcy91c2Ugb2YvbGltaXRhdGlvbiB0by8mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgKHdlIGhhdmUgYmVlbiB1c2luZyB0aGVtIGJlZm9yZSk8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBzL2FyY2hpdGVjdHVyZXMvcGxhdGZv cm1zLyZuYnNwOyAoSmF2YSBpcyBvdXIgbWFpbiBwcm9ibGVtIGhlcmUsIG5vPyk8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFtSV108L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdCBpdCB3b3Vs ZCBiZSBhd2t3YXJkIGZvciBtb3N0IGxhbmd1YWdlcy9DUFU8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGFyY2hpdGVjdHVyZXMsPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgYW55d2hlcmUgd2hlcmUgeW91IGNvdWxkIGVu ZCB1cCB3aXRoIGEgbmVnYXRpdmUgbnVtYmVyIHRoYXQgaXMgbGVzczwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IHRoYW4gMl42My48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBZZXMsIGl0IGlzIHBvc3NpYmxlIHRvIHdyaXRlIGNvZGUg aW4gQyBvciBKYXZhIHRvIGhhbmRsZSB0aGlzLCBidXQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG15IGh1bmNoIGlzIHRoYXQgaW1wbGVtZW50YXRpb25z IGNvdWxkIGVhc2lseSBnZXQgdGhpcyB3cm9uZyAoZS5nLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgYnkganVzdCB1c2luZyBzaWduZWQgaW50NjQgYXMg dGhlIHR5cGUgdG8gaG9sZCB0aGUgZGlmZmVyZW5jZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgYmV0d2VlbiBwYXJlbnQgYW5kIGNoaWxkIFNJRHMuKTwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoYW5rcyw8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJvYjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgcy9wcmVjaXNpb24vcmFuZ2UvIHMvc3BhY2UvcmVtYWlu aW5nIHNwYWNlLzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7ICZn dDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZn dDsgR3LDvMOfZSwgQ2Fyc3RlbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyAmZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBj b3JlIG1haWxpbmcgbGlzdDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAm Z3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Y29yZUBpZXRmLm9yZzwvc3Bh bj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZn dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L3NwYW4+PC9hPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB43663AFE1492793F34DAA113B5370MN2PR11MB4366namp_-- From nobody Wed Jan 15 10:38:21 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 543B11208FB for ; Wed, 15 Jan 2020 10:38:19 -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 MVa5UBzrnjHC for ; Wed, 15 Jan 2020 10:38:17 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFCD1208D4 for ; Wed, 15 Jan 2020 10:38:16 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F5633897D for ; Wed, 15 Jan 2020 13:27:37 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2EB4412A1 for ; Wed, 15 Jan 2020 13:28:04 -0500 (EST) From: Michael Richardson To: core@ietf.org In-Reply-To: References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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, 15 Jan 2020 18:38:19 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2020-01-13, at 19:11, Michael Richardson > wrote: >> >> o SIDs never change. > That may require a little bit of expansion. SIDs do change while I= =E2=80=99m > editing the document on my laptop and not telling anyone else what I= =E2=80=99m > doing. But at some time, they freeze. Actually, if things go well on your laptop, they don't. You might add/delete leafs and so you might roll through the SIDs quickly, and then, because you haven't published anything, decided to reset, but that's your business :-) > What is the specific event that makes a SID allocation immutable, even > if the underlying identifier goes away (and maybe comes back later)? > What is the way we keep this memory? There is the .sid file which records the allocations. You use --generate-sid-file (giving your allocation) to initialize the process, which creates a .sid file. You do this only once. You use --update-sid-file normally to allocate SID values from a YANG file. It keeps track not to re-use elements after the leaf is deleted, and makes sure to re-use numbers when the leaf has not changed. Deleting and then adding a leaf with the *same name* should wind up with the SID being reused. The SID file is some JSON. Here is an example: https://github.com/anima-wg/constrained-voucher/blob/master/ietf-constrai= ned-voucher-request%402019-09-01.sid =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4fWbMACgkQgItw+93Q 3WX+/Af9FwXWGFb33rQFele7Lq1aSkWRIOsJw+/hg2fLB2GxJp1f7oP3qLKlSaNB a6EbNHbacv5wPhtET2Q0rSCDidAs/dk+SBOyGN1XjtApsl3AavzfrPAAuKqf7pXw XtgfCyYu+VKlEI5Z0e51fJVrSl6JQTqlxH5LMMkIa2UtSfnZV9LpsTj84o2VgGa7 wkFKszgcpa3RECC99K5qw4GBpfPujRYUegB16qu1WCfAM48pZ9hVQZ8E8WORxarT Xw9aInMjZLTSx4OCv0QKQjnQG+1k2XailpXoe5p4cek8bFdG2FokoK9kz895rxGL N3BG568VxH7RsFUSP6PZdkS9QJqvPA== =ePh/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 15 13:32:14 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 337B9120984 for ; Wed, 15 Jan 2020 13:32:12 -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 Ewr6kt1554Dv for ; Wed, 15 Jan 2020 13:32: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 178D3120992 for ; Wed, 15 Jan 2020 13:32:07 -0800 (PST) Received: from [192.168.217.119] (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 47ygWn54Slz16GL; Wed, 15 Jan 2020 22:32:05 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: <26398.1579112884@localhost> Date: Wed, 15 Jan 2020 22:32:05 +0100 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 600816725.184234-cdfd2e110e574a12cbce636aa2047c5c Content-Transfer-Encoding: quoted-printable Message-Id: <0805B57C-3DCB-4601-976C-2D51CE812312@tzi.org> References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> <22612.1578626081@localhost> <15754.1578789013@localhost> <6025.1578939111@localhost> <26398.1579112884@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.40.2.2.4) 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, 15 Jan 2020 21:32:12 -0000 On 2020-01-15, at 19:28, Michael Richardson = wrote: >=20 >=20 > Carsten Bormann wrote: >> On 2020-01-13, at 19:11, Michael Richardson >> wrote: >>>=20 >>> o SIDs never change. >=20 >> That may require a little bit of expansion. SIDs do change while = I=E2=80=99m >> editing the document on my laptop and not telling anyone else what = I=E2=80=99m >> doing. But at some time, they freeze. >=20 > Actually, if things go well on your laptop, they don't. > You might add/delete leafs and so you might roll through the SIDs = quickly, > and then, because you haven't published anything, decided to reset, = but > that's your business :-) Exactly. My question really was if we can state unambiguously when it stops being = my business. >> What is the specific event that makes a SID allocation immutable, = even >> if the underlying identifier goes away (and maybe comes back later)? >=20 >> What is the way we keep this memory? >=20 > There is the .sid file which records the allocations. > You use --generate-sid-file (giving your allocation) to initialize the > process, which creates a .sid file. You do this only once. >=20 > You use --update-sid-file normally to allocate SID values from a YANG = file. > It keeps track not to re-use elements after the leaf is deleted, and = makes > sure to re-use numbers when the leaf has not changed. Deleting and = then > adding a leaf with the *same name* should wind up with the SID being = reused. So when the development of a standard is completed, we hand IANA a SID = file with dead SIDs in it? Or how do we maintain the memory of those = dead SIDs? Are there boundaries through which a SID file can go that = does remove dead SIDs? > The SID file is some JSON. > Here is an example: > = https://github.com/anima-wg/constrained-voucher/blob/master/ietf-constrain= ed-voucher-request%402019-09-01.sid Yes. The file format is fine, the question is whether we give enough = guidance on how to handle the evolution of =E2=80=9Cthe=E2=80=9D SID = file for a YANG module. I think Andy Bierman has reminded us often enough that this is hard to = get right. Sorry for playing a bad copy of Andy today. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 15 13:56: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 18B3D1209CB for ; Wed, 15 Jan 2020 13:56:43 -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 zdkcx0R6YD5z for ; Wed, 15 Jan 2020 13:56:41 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FEDC1209C9 for ; Wed, 15 Jan 2020 13:56:40 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E21D3897D; Wed, 15 Jan 2020 16:56:09 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 79134124A; Wed, 15 Jan 2020 16:56:36 -0500 (EST) From: Michael Richardson To: Carsten Bormann cc: core@ietf.org In-Reply-To: <0805B57C-3DCB-4601-976C-2D51CE812312@tzi.org> 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> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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, 15 Jan 2020 21:56:43 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> You use --update-sid-file normally to allocate SID values from a YANG >> file. It keeps track not to re-use elements after the leaf is >> deleted, and makes sure to re-use numbers when the leaf has not >> changed. Deleting and then adding a leaf with the *same name* should >> wind up with the SID being reused. > So when the development of a standard is completed, we hand IANA a SID > file with dead SIDs in it? Or how do we maintain the memory of those > dead SIDs? Are there boundaries through which a SID file can go that > does remove dead SIDs? Yes, if we evolved the design during WG processing, then we could well have dead SIDs. We could, at WGLC or IESG approval, edit the SID file and mark them as useable again. (If there were no running code, we could reset the SID file entirely at tha= t point) The SID file maintains the memory of the dead values for only as long as we want it to. >> The SID file is some JSON. Here is an example: >> https://github.com/anima-wg/constrained-voucher/blob/master/ietf-con= strained-voucher-request%402019-09-01.sid > Yes. The file format is fine, the question is whether we give enough > guidance on how to handle the evolution of =E2=80=9Cthe=E2=80=9D SID = file for a YANG > module. Thus, I think, a need to get early IANA review of the details. > I think Andy Bierman has reminded us often enough that this is hard to > get right. Sorry for playing a bad copy of Andy today. > Gr=C3=BC=C3=9Fe, Carsten =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4fipQACgkQgItw+93Q 3WWS4gf/S4lj9WNEL+3p7aS7tL5iC32ZMqAczKGCxwWYABeYG+6OWYMN/1Oey9lA 6fY2A27B5O235DrtEGRrACo5KPv8RqYIRzzp0NKG4sP30QdcKYS7vaXnBzqf3EyP tfgSDEr1NuhSwT6QBn+g1jjHcEdv6RkXq4HdMzCbGpNX3TPjxnyTX8KHGxJ0tUxo prs0GXBcZcxl/ZAk9GWMQm93EBlq92EixTfFOy97PQyOVsXoaTfR2PIJjc9ndqOy 8CQ9x0vlAVh39Wsb56cmEBrcJSHfUAihhvlOfH/dHK69S+Fz14qxH/Kv7kgRhrTB sIXx70nKGBBswq4YaTekNia25FcK9g== =1JHr -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 15 15:04: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 7EA72120639 for ; Wed, 15 Jan 2020 15:04:42 -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 IJjkoe4B2Xex for ; Wed, 15 Jan 2020 15:04:40 -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 6ABE7120110 for ; Wed, 15 Jan 2020 15:04:40 -0800 (PST) Received: from [192.168.217.119] (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 47yjZZ6QQkz16H8; Thu, 16 Jan 2020 00:04:38 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: <14603.1579125396@localhost> Date: Thu, 16 Jan 2020 00:04:38 +0100 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 600822278.361071-5c5beb9024d8c4a37a9f3e0918d6dd74 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Michael Richardson X-Mailer: Apple Mail (2.3608.40.2.2.4) 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, 15 Jan 2020 23:04:42 -0000 On 2020-01-15, at 22:56, Michael Richardson = wrote: >=20 > Yes, if we evolved the design during WG processing, then we could well = have > dead SIDs. We could, at WGLC or IESG approval, edit the SID file and = mark > them as useable again. > (If there were no running code, we could reset the SID file entirely = at that point) > The SID file maintains the memory of the dead values for only as long = as we > want it to. This paragraph is exactly reflecting my nightmares about this. We could do a lot of things, if we wanted to. What are our unambiguous, not-to-be-missed instructions that make this = fool-proof? I would expect that we get rid of dead SIDs about as often as we revoke = TCP port number assignments, i.e., essentially never. But this requires = getting around the cognitive dissonance of just having =E2=80=9Cwasted=E2=80= =9D a SID value (*): With very strongly worded instructions, I=E2=80=99d assume. Gr=C3=BC=C3=9Fe, Carsten (*) (Note that there are way more SIDs than there are TCP ports.) From nobody Wed Jan 15 15:14:29 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 BDADD120044 for ; Wed, 15 Jan 2020 15:14:27 -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, 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] 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 URfm0Tvi89Fx for ; Wed, 15 Jan 2020 15:14:25 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 5B15D120113 for ; Wed, 15 Jan 2020 15:14:25 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id b15so14058557lfc.4 for ; Wed, 15 Jan 2020 15:14:25 -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=DR1G/81JUbVKMoAgaDW66NRWwjjZNFm9xg5bjqMzRq4=; b=TFiAahoySf7JfNMB3sKyq36f6oXXOM0comQlO4e0lf8wi6aqnq9Y3JJYBL+/KtM0TO RRR+YFsu2oz9pbufBFq/gjLaXci/XCdxxItzP2uSbMsSxl10Mj3MvMU369fHp/+w92d1 n8ZGENInjnCk6/0nUmCTuGzjdd1NlWTybdnfcnMAQ09Wq68493B697g8iM3AGSj4j9uq 3Y1pCdwFNTn0Uhkh42FTkADf1UpWW7dZGTRRRpgQYsS0E43bdxwVTMC64VqfPQntqpxp dMfGT2OLblMbNtJgLDWIaJ2fvuPuxRteB105FldjUKt7nN32A9hTCL8/DK+LUw2Ot1ob 72sA== 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=DR1G/81JUbVKMoAgaDW66NRWwjjZNFm9xg5bjqMzRq4=; b=jLl2NygCkI3R5psaetcm+3glrsbPcPQrH1UBpVM5CQB4/MBDOUWnZpBgXFWdOEzTMA A1/agQyNuURSBNENFCJ/82O5I36GJhV4UIYgsuBEPp32tJSAtWbrTtBBq7ou6Y9s6Z6i nUlx1b0e4SrDyePo5U7+bwCIHksbYmiKcvgahSLXLwkgGjw+RZLynZM6sHeIfyTNIM+U WZTKtWIaWLfU9v/oKE7R/iivYRDDxDT9i4FWZMT134m5CluURusV9stpxpVX0NzDuwMu KJYpREyZmCqr6SFrBXQYfOPv6QPzOCRUxPzCS5AapKlCmXcoYespw34oPHXvajaROkO8 EhZQ== X-Gm-Message-State: APjAAAXSSeK9vIB4JsFm7JZwdm/jbGOcDK90Awf01hM8p2c4X525YYMz rZhMsCdM+CajVK10x+EtsDoKpKWnhaQYl0iTvjEBqQF0 X-Google-Smtp-Source: APXvYqx5h20j3X55SEgP4w/zLP+VULB905Fb++b0nxDdTS0OIToksH1PiLh37g3M1+JZltvm0gixpdUYwTX3maeCv58= X-Received: by 2002:a19:2389:: with SMTP id j131mr647428lfj.86.1579130063384; Wed, 15 Jan 2020 15:14:23 -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> In-Reply-To: <0805B57C-3DCB-4601-976C-2D51CE812312@tzi.org> From: Andy Bierman Date: Wed, 15 Jan 2020 15:14:12 -0800 Message-ID: To: Carsten Bormann Cc: Michael Richardson , Core Content-Type: multipart/alternative; boundary="0000000000007b8e10059c35de3a" 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, 15 Jan 2020 23:14:28 -0000 --0000000000007b8e10059c35de3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 15, 2020 at 1:32 PM Carsten Bormann wrote: > On 2020-01-15, at 19:28, Michael Richardson wrote= : > > > > > > Carsten Bormann wrote: > >> On 2020-01-13, at 19:11, Michael Richardson > >> wrote: > >>> > >>> o SIDs never change. > > > >> That may require a little bit of expansion. SIDs do change while I=E2= =80=99m > >> editing the document on my laptop and not telling anyone else what I= =E2=80=99m > >> doing. But at some time, they freeze. > > > > Actually, if things go well on your laptop, they don't. > > You might add/delete leafs and so you might roll through the SIDs > quickly, > > and then, because you haven't published anything, decided to reset, but > > that's your business :-) > > Exactly. > > My question really was if we can state unambiguously when it stops being > my business. > > >> What is the specific event that makes a SID allocation immutable, even > >> if the underlying identifier goes away (and maybe comes back later)? > > > >> What is the way we keep this memory? > > > > There is the .sid file which records the allocations. > > You use --generate-sid-file (giving your allocation) to initialize the > > process, which creates a .sid file. You do this only once. > > > > You use --update-sid-file normally to allocate SID values from a YANG > file. > > It keeps track not to re-use elements after the leaf is deleted, and > makes > > sure to re-use numbers when the leaf has not changed. Deleting and the= n > > adding a leaf with the *same name* should wind up with the SID being > reused. > > So when the development of a standard is completed, we hand IANA a SID > file with dead SIDs in it? Or how do we maintain the memory of those dea= d > SIDs? Are there boundaries through which a SID file can go that does > remove dead SIDs? > > > The SID file is some JSON. > > Here is an example: > > > https://github.com/anima-wg/constrained-voucher/blob/master/ietf-constrai= ned-voucher-request%402019-09-01.sid > > Yes. The file format is fine, the question is whether we give enough > guidance on how to handle the evolution of =E2=80=9Cthe=E2=80=9D SID file= for a YANG module. > > I think Andy Bierman has reminded us often enough that this is hard to ge= t > right. > Sorry for playing a bad copy of Andy today. > > :-) There are so many ways to mess up things with SIDs... I hope the pyang regression tests for SIDs are ready for the task. There are multiple YANG lint programs and they don't all agree or get everything right. There are no such programs for SID (e.g. to verify everything that is supposed to have a SID assigned actually got an assignment). As a hypothetical, let's assume there are undetected bugs in a SID file or across the entire set of SID files. How do they get corrected? The SID file itself contains no metadata indicating it is a corrected revision of a previous SID file. This has already proven to be a problem for YANG, and it has the deviation-stmt which can be used in some cases to correct broken YANG in another YANG file= . A SID file is just a JSON instance file. There are no defined mechanisms to correct a SID file from IANA or anywhere else. Perhaps a "sid-file-revision" field in the SID file would help. Gr=C3=BC=C3=9Fe, Carsten > > Andy > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000007b8e10059c35de3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 15, 2020 at 1:32 PM Carst= en Bormann <cabo@tzi.o= rg> wrote:
mcr+ietf@sandelman.ca> wrote: >
>
> Carsten Bormann <= cabo@tzi.org> wrote:
>> On 2020-01-13, at 19:11, Michael Richardson <mcr+ietf@sandelman.ca> >> wrote:
>>>
>>> o SIDs never change.
>
>> That may require a little bit of expansion.=C2=A0 SIDs do change w= hile I=E2=80=99m
>> editing the document on my laptop and not telling anyone else what= I=E2=80=99m
>> doing.=C2=A0 But at some time, they freeze.
>
> Actually, if things go well on your laptop, they don't.
> You might add/delete leafs and so you might roll through the SIDs quic= kly,
> and then, because you haven't published anything, decided to reset= , but
> that's your business :-)

Exactly.

My question really was if we can state unambiguously when it stops being my= business.

>> What is the specific event that makes a SID allocation immutable, = even
>> if the underlying identifier goes away (and maybe comes back later= )?
>
>> What is the way we keep this memory?
>
> There is the .sid file which records the allocations.
> You use --generate-sid-file (giving your allocation) to initialize the=
> process, which creates a .sid file.=C2=A0 You do this only once.
>
> You use --update-sid-file normally to allocate SID values from a YANG = file.
> It keeps track not to re-use elements after the leaf is deleted, and m= akes
> sure to re-use numbers when the leaf has not changed.=C2=A0 Deleting a= nd then
> adding a leaf with the *same name* should wind up with the SID being r= eused.

So when the development of a standard is completed, we hand IANA a SID file= with dead SIDs in it?=C2=A0 Or how do we maintain the memory of those dead= SIDs?=C2=A0 Are there boundaries through which a SID file can go that does= remove dead SIDs?

> The SID file is some JSON.
> Here is an example:
>=C2=A0 https://github.com/anima-wg/constrained-voucher/blob/ma= ster/ietf-constrained-voucher-request%402019-09-01.sid

Yes.=C2=A0 The file format is fine, the question is whether we give enough = guidance on how to handle the evolution of =E2=80=9Cthe=E2=80=9D SID file f= or a YANG module.

I think Andy Bierman has reminded us often enough that this is hard to get = right.
Sorry for playing a bad copy of Andy today.


:-)

There are= so many ways to mess up things with SIDs...
I hope the pyang reg= ression tests for=C2=A0 SIDs are ready for the task.
There are mu= ltiple YANG lint programs and they don't all agree or get everything ri= ght.
There are no such programs for SID (e.g. to verify everythin= g that is supposed to
have a SID assigned actually got an assignm= ent).

As a hypothetical, let's assume there ar= e undetected bugs in a SID file
or across the entire set of SID f= iles. How do they get corrected?
The SID file itself contains no = metadata indicating it is a corrected revision of a previous SID file.

This has already proven to be a problem for YANG, and = it has the deviation-stmt
which can be used in some cases to corr= ect broken YANG in another YANG file.

A SID file i= s just a JSON instance file.
There are no defined mechanisms to c= orrect a SID file from IANA or anywhere else.
Perhaps a "sid= -file-revision" field in the SID file would help.

=

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


Andy
=C2=A0
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--0000000000007b8e10059c35de3a-- From nobody Wed Jan 15 16:08:49 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 58997120639 for ; Wed, 15 Jan 2020 16:08:47 -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 UenYpw79DM4n for ; Wed, 15 Jan 2020 16:08:45 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C09120113 for ; Wed, 15 Jan 2020 16:08:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 090713897D; Wed, 15 Jan 2020 19:08:16 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EB755124A; Wed, 15 Jan 2020 19:08:42 -0500 (EST) From: Michael Richardson To: Carsten Bormann cc: core@ietf.org In-Reply-To: <0805B57C-3DCB-4601-976C-2D51CE812312@tzi.org> 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> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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: Thu, 16 Jan 2020 00:08:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> Carsten Bormann wrote: >>> On 2020-01-13, at 19:11, Michael Richardson >>> wrote: >>>> >>>> o SIDs never change. >> >>> That may require a little bit of expansion. SIDs do change while I= =E2=80=99m >>> editing the document on my laptop and not telling anyone else what >>> I=E2=80=99m doing. But at some time, they freeze. >> >> Actually, if things go well on your laptop, they don't. You might >> add/delete leafs and so you might roll through the SIDs quickly, and >> then, because you haven't published anything, decided to reset, but >> that's your business :-) > Exactly. > My question really was if we can state unambiguously when it stops > being my business. Unfortunately, "my" in ambiguous here :-) {/me considers demonstrating my abilities with German dative pronouns...} I think that you mean "the document authors", but it could be that you mean the WG's problem, or the CORE WG's problem. I would like to suggest that WGs doing things with SID should ask for an allocation at document adoption time. This is the earlist that it can beco= me anyone's problem. I think that a WGLC consideration would be whether to: 1) reset the SID allocations for the document in question 2) mark any deleted leafs as available There is potentially recursive implication of this. In an ideal world, documents will be proposed in a bottom-up order, but if that does not occur, then this could cause this decision to cycle. > Yes. The file format is fine, the question is whether we give enough > guidance on how to handle the evolution of =E2=80=9Cthe=E2=80=9D SID = file for a YANG > module. I think we shouldn't try to make up all the rules ahead of time. We just need to some running code first. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4fqYoACgkQgItw+93Q 3WWviggAg0TGNoGbhjJiKT1NqzOHXYXjfhJ3FbfihPFiIX5Z2khg4KmK4KC/f6qc Tl3qoqM6am5eVVOBRCZHIHinqRzo4fpS0fFg3odfwbglKla0UghihhrbZV8W8LDb 3C2Twr6T3BI38hM9dqiJ8HeESP89GSY1KfE+vP5Y1wTJdm3bu9LFEK8NVXtQ/gI1 6rnpz1vn90EFeLrrSEDQ1QMdIXrAEUSK8blt6h+OhtmWpYmPMhMsSzRQ80XlIz8N QlT8gKxzFl5B3J3Y7qMPvlFEWN3q6oRPY6rtPDQ982uDDHnJAJULdskEgFa8JOaL 4do+mKqep4XQqmmxsiOgSyofkF8pXQ== =ZO6G -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 15 16:12: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 88E93120113 for ; Wed, 15 Jan 2020 16:12:44 -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 UHwLZdRV0w0C for ; Wed, 15 Jan 2020 16:12:43 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD0A12008F for ; Wed, 15 Jan 2020 16:12:43 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 18C7E3897D; Wed, 15 Jan 2020 19:11:37 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 04AD5124A; Wed, 15 Jan 2020 19:12:04 -0500 (EST) From: Michael Richardson To: Andy Bierman cc: Carsten Bormann , Core 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> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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: Thu, 16 Jan 2020 00:12:45 -0000 --=-=-= Content-Type: text/plain Andy Bierman wrote: > As a hypothetical, let's assume there are undetected bugs in a SID file > or across the entire set of SID files. How do they get corrected? The > SID file itself contains no metadata indicating it is a corrected > revision of a previous SID file. I guess revising the YANG date is too big a hammer. > This has already proven to be a problem for YANG, and it has the > deviation-stmt which can be used in some cases to correct broken YANG > in another YANG file. > A SID file is just a JSON instance file. There are no defined > mechanisms to correct a SID file from IANA or anywhere else. Perhaps a > "sid-file-revision" field in the SID file would help. I agree, that would be worthwhile. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4fqlMACgkQgItw+93Q 3WUH7AgAtRWNdL81Pi92nlP4y/x+sITQLjj2Uu93bHroh62xsqcXiFe97P+ZIFIB 7wU6qaMeNgLAYyCvNDmamwTgasMjtM3l1eNJInZHIsk0yzxOVEliujp6R8ZHbgFr UtZAvgDeG0DLVDCCFyaOkepLyYMH9xyeAmulAQ+kczM7qc9ol1vz5Fuc5q8fEWp0 Z0nx8fKJ00lkSZafpDURGYAJnouBRRXUVrGy86lcEdSwhaU15otKCqNCKp88ftpQ 51PiiWE1TNhFgKMS5ghNIlHnORddI0NAvh3gtWMsuqigSUuKzXzYQOvK6StX43pg aaT9WNHmn6oH8v+lYeMyWxhRcP+sfA== =vZoZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 15 16:17:24 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 63F87120891 for ; Wed, 15 Jan 2020 16:17:23 -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 BkTnszgTnlp1 for ; Wed, 15 Jan 2020 16:17:21 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EDC12008F for ; Wed, 15 Jan 2020 16:17:20 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0EC813897D; Wed, 15 Jan 2020 19:16:53 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 00EC9124A; Wed, 15 Jan 2020 19:17:19 -0500 (EST) From: Michael Richardson To: Carsten Bormann cc: core@ietf.org 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> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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: Thu, 16 Jan 2020 00:17:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> Yes, if we evolved the design during WG processing, then we could we= ll >> have dead SIDs. We could, at WGLC or IESG approval, edit the SID fi= le >> and mark them as useable again. (If there were no running code, we >> could reset the SID file entirely at that point) The SID file >> maintains the memory of the dead values for only as long as we want = it >> to. > This paragraph is exactly reflecting my nightmares about this. We > could do a lot of things, if we wanted to. What are our unambiguous, > not-to-be-missed instructions that make this fool-proof? We will screw up, but the fools are often brilliant in their ability to get around fool-proofing :-) > I would expect that we get rid of dead SIDs about as often as we revo= ke > TCP port number assignments, i.e., essentially never. But this > requires getting around the cognitive dissonance of just having > =E2=80=9Cwasted=E2=80=9D a SID value (*): With very strongly worded i= nstructions, I=E2=80=99d > assume. > Gr=C3=BC=C3=9Fe, Carsten > (*) (Note that there are way more SIDs than there are TCP ports.) The time when we are most likely to create dead SID values is during the development of running code between WG Adoption and WGLC. I think it is reasonable thing to decide, with some communication among implementers to reset/re-allocate. Revisions to the YANG which deprecate leafs and therefore create deprecated SID values are different: deployed code might still be using them. (If we are revising published YANG, then certainly can never reset the SID = process!) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4fq48ACgkQgItw+93Q 3WWPXQf/VgCDz2Mj/pwWLxQZJJ7oDwfZhJ3RoKCibM6y/7kS9e1VrW+S3xN7N9qL VBuaUgXmnwUC19+3MUySPYdyNkj0wqoGhcw+JhWYYUedfJTDXT4C6jqe2orWV0Yw nkSEI7rc6yHjGm1IxtqNeflN2lW/vn4bMBgLJrh6bM4am16JGIcrbDFTdZGUjCj4 FXFJrVj9F4LtNDgIjvA3XYlkH3LEADCGlmGNKqT7vfpCW5yV9YJmNGS6IpvMyymP LDi9fYiI9XVlL7tDV/78OU5EGCQABjw/aSQ7PuLajpU6+Dnz5Q94JimjRPErqGzu gpCKco8m9A0r521fNPzDL0XaXDFcYw== =msMt -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 15 16:28:14 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 CE0F612008F for ; Wed, 15 Jan 2020 16:28:12 -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=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 iVY1E5mD9_bG for ; Wed, 15 Jan 2020 16:28:09 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F76B120113 for ; Wed, 15 Jan 2020 16:28:09 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id u1so20604599ljk.7 for ; Wed, 15 Jan 2020 16:28:09 -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=yLrlPDHoq9H2m+o9QNtDEgocoPtM4tPZ8ekORX2wE2E=; b=YnXUzkEHYVjl4yC4ltk9hEtEuayn5xkF3ElH4x/8YKW6t5dwSvtSf+eL0WFjexFy9f 5D3FRCEHTK7l3TF1mROSe8LiZJMAk4Z1lNQ7Y+TqC8Y4H/O8RDjXd/eyMcHQuu1+uQLj wjEbtW3uzwn9Zsc8VCHOpvwPsCeWNqZalgaJIzSNCgcuH2FaBHVW1D+YHsx/k2PJpjyz Xfs4Cn18b9TD82ABpixYSCDz8Z9bTUVx7gMhBd6OE5u8DmRpxl/mNgPI70DpBuJrzH+8 2wnRzPeutsp0OoxjuJM0/ZCflj/xuSGqREf7HoeJd8taDdpLSQDOnd2Nym+fcuFD3CTc jQcw== 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=yLrlPDHoq9H2m+o9QNtDEgocoPtM4tPZ8ekORX2wE2E=; b=ctHeALY1aSL3UTBV48ejvNep/HQIjas+82IKwN71HizhickAgXxW8xMpHOPyb48n0j 1noFXyJyWmCiXnO1q5bq0cXln/20xFXIjitjOyKUybOA21hQQ2KEKnFxI4OL1AP7+/cn MRsTcAliUkzYC4xNPtYEmGGNH4g2J3pQv+WLm8O9DtdKxhCHzZHtIsm2cGYJN4XDWxd4 PaH9Rh4ygRyJWPadshmbJEOooifxZI1iytanCzHFcV67hl8Ts9866LbKJ02+LBAvrRLG UACu4u99+HsdJdm/QF4mR4/TWg9H/+SMUrj0au7MWrrxhys3snimaE+nTM3K6y7+yaPf 3HDg== X-Gm-Message-State: APjAAAWzfgCIx1hAXgvfaYMEhoG4iuhNPuqA3R5t68+Z/2QG+aoMFDV3 y2kzAiUm5IWFOHiDeDSOQWbGfI0PPgEQ4VD+bYCpIg== X-Google-Smtp-Source: APXvYqzoWXRtELAuFFjkTA3Vr3w8Xc6jkGU96fPLpr9vDMN1XqFJ70oXvRjM2PujwyKkGmMp/PWReE8QfNtY9gJhcx4= X-Received: by 2002:a2e:9596:: with SMTP id w22mr505178ljh.21.1579134487449; Wed, 15 Jan 2020 16:28:07 -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> <17100.1579133523@localhost> In-Reply-To: <17100.1579133523@localhost> From: Andy Bierman Date: Wed, 15 Jan 2020 16:27:56 -0800 Message-ID: To: Michael Richardson Cc: Carsten Bormann , Core Content-Type: multipart/alternative; boundary="0000000000002d69d3059c36e69a" 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: Thu, 16 Jan 2020 00:28:13 -0000 --0000000000002d69d3059c36e69a Content-Type: text/plain; charset="UTF-8" On Wed, Jan 15, 2020 at 4:12 PM Michael Richardson wrote: > > Andy Bierman wrote: > > As a hypothetical, let's assume there are undetected bugs in a SID > file > > or across the entire set of SID files. How do they get corrected? > The > > SID file itself contains no metadata indicating it is a corrected > > revision of a previous SID file. > > I guess revising the YANG date is too big a hammer. > That needs to stay the same, because the YANG module is not changing and this field needs to match the YANG file. > > > This has already proven to be a problem for YANG, and it has the > > deviation-stmt which can be used in some cases to correct broken YANG > > in another YANG file. > > > A SID file is just a JSON instance file. There are no defined > > mechanisms to correct a SID file from IANA or anywhere else. > Perhaps a > > "sid-file-revision" field in the SID file would help. > > I agree, that would be worthwhile. > This would make it possible to correct a SID file and still support the broken version(s) that might be deployed already. IANA would only need to maintain the latest sid-file-revision. I suggest a simple integer, not a datestamp. > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > Andy --0000000000002d69d3059c36e69a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 15, 2020 at 4:12 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Andy Bierman <an= dy@yumaworks.com> wrote:
=C2=A0 =C2=A0 > As a hypothetical, let's assume there are undetected= bugs in a SID file
=C2=A0 =C2=A0 > or across the entire set of SID files. How do they get c= orrected?=C2=A0 The
=C2=A0 =C2=A0 > SID file itself contains no metadata indicating it is a = corrected
=C2=A0 =C2=A0 > revision of a previous SID file.

I guess revising the YANG date is too big a hammer.
That needs to stay the same, because the YANG module is not ch= anging and this field needs to
match the YANG file.
=C2= =A0

=C2=A0 =C2=A0 > This has already proven to be a problem for YANG, and it= has the
=C2=A0 =C2=A0 > deviation-stmt which can be used in some cases to correc= t broken YANG
=C2=A0 =C2=A0 > in another YANG file.

=C2=A0 =C2=A0 > A SID file is just a JSON instance file.=C2=A0 There are= no defined
=C2=A0 =C2=A0 > mechanisms to correct a SID file from IANA or anywhere e= lse.=C2=A0 Perhaps a
=C2=A0 =C2=A0 > "sid-file-revision" field in the SID file woul= d help.

I agree, that would be worthwhile.

This= would make it possible to correct a SID file and still support the broken = version(s)
that might be deployed already. IANA would only need t= o maintain the latest sid-file-revision.
I suggest a simple integ= er, not a datestamp.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




Andy
=C2=A0
--0000000000002d69d3059c36e69a-- From nobody Wed Jan 15 16:54:09 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 5A89B120807 for ; Wed, 15 Jan 2020 16:54:07 -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=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 SmHfwWH3IiFu for ; Wed, 15 Jan 2020 16:54:05 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915AA1207FB for ; Wed, 15 Jan 2020 16:54:04 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id y6so20699379lji.0 for ; Wed, 15 Jan 2020 16:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u7EGxUcmwNCN+7s3zNJR29IHFpL8TNCtepLn+Rgg31Q=; b=g0Hrims27/xsbtzm/obYZxklyMfECpOjj7BOcMOs46y/gykI/+GHJxIt+3rGSykXQK akmj349G17IE2Z+mRt+FrDKfvU4wf1KXyNTGxz7uA7okqunBEMHJjmrzPOnTWguZB3Fj 8xOafJnzUt/OAhNN1qqZqj0LL6MUxARbHaiDTPe36rDvBF7t/EzdMte7Qu3fNe1fYN6+ 87pSuyrgqW/tpKNByHbie915IYu/zGTewXiSnzmFERP++iSfMoVxwHKBK0B0868Ti4MI /ZDa0AKkkcJiZjCYOE9Ya61Jjga4ALjklCmV50PM2P/hxoRA/rD4TG+1J1tym3c9AvZf L7rQ== 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=u7EGxUcmwNCN+7s3zNJR29IHFpL8TNCtepLn+Rgg31Q=; b=ZaLCfYR0d3jMve1VQoO40tnlkEtZlDLgDZkaay9sTLefcHEGzZtKoI0GI3zARzKNIN kxZ1+08AKfaD19Jv5oBiLesa9jgzLbSNP+COZb9J7ap4NYtC/nbO55EJqDLBzMO/oydc cr+ltj3JsRjyyFGG6gzYqVOLxDmL3nqRXGCavAhvcuN8FmXoOOWemFyzMRJSpWIq9Lgs Q6fYoNcgNeB3LZF4lWTJlaBCDg6QbagIFSiGv4ITDwep6RID7oTWgRQhY5V+Rdp0UJ+D QmhbCi6nE1uNagFZzr56ZN5K4S790CpJNmbKV6LhojQWvTIP6D+X7Nv/lWf0KFS3sSah x3zw== X-Gm-Message-State: APjAAAUy+KGjoDfLLAb+R42e4sr/ezNyOmDiQG7wiYOwCF8PY4h66Jty DwatwZObDMCKJcLF1L+zxHR8s9FLSwC28fFeLB992A== X-Google-Smtp-Source: APXvYqzbsvoAveKGbEvIXGvahW25WUScJLPDhOIIDfBmsmmsjifltTNyIDX/vpcaZx8PlNgxCw60Cf8U4s/3nV9du5o= X-Received: by 2002:a2e:9143:: with SMTP id q3mr602748ljg.199.1579136042815; Wed, 15 Jan 2020 16:54:02 -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> In-Reply-To: <18568.1579133839@localhost> From: Andy Bierman Date: Wed, 15 Jan 2020 16:53:51 -0800 Message-ID: To: Michael Richardson Cc: Carsten Bormann , Core Content-Type: multipart/alternative; boundary="000000000000e263a5059c3742cf" 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: Thu, 16 Jan 2020 00:54:07 -0000 --000000000000e263a5059c3742cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 15, 2020 at 4:17 PM Michael Richardson wrote: > > Carsten Bormann wrote: > >> Yes, if we evolved the design during WG processing, then we could > well > >> have dead SIDs. We could, at WGLC or IESG approval, edit the SID > file > >> and mark them as useable again. (If there were no running code, w= e > >> could reset the SID file entirely at that point) The SID file > >> maintains the memory of the dead values for only as long as we wan= t > it > >> to. > > > This paragraph is exactly reflecting my nightmares about this. We > > could do a lot of things, if we wanted to. What are our unambiguou= s, > > not-to-be-missed instructions that make this fool-proof? > > We will screw up, but the fools are often brilliant in their ability to g= et > around fool-proofing :-) > > > I would expect that we get rid of dead SIDs about as often as we > revoke > > TCP port number assignments, i.e., essentially never. But this > > requires getting around the cognitive dissonance of just having > > =E2=80=9Cwasted=E2=80=9D a SID value (*): With very strongly worded= instructions, I=E2=80=99d > > assume. > > > Gr=C3=BC=C3=9Fe, Carsten > > > (*) (Note that there are way more SIDs than there are TCP ports.) > > The time when we are most likely to create dead SID values is during the > development of running code between WG Adoption and WGLC. > I think it is reasonable thing to decide, with some communication among > implementers to reset/re-allocate. > > Revisions to the YANG which deprecate leafs and therefore create deprecat= ed > SID values are different: deployed code might still be using them. > (If we are revising published YANG, then certainly can never reset the SI= D > process!) > IMO there should be no concept of conformance status for a SID file. It would be unwise to recover SIDs of obsolete YANG definitions. It is safer to just burn the wasted range and keep range assignments small. Do SID files need to be identified by a 3-tuple {module-name, module-revision, sid-file-revision } foo@2020-01-15.1 -> { foo, 2020-01-15, 1 } If the sid-file-revision is missing then it defaults to '1'. Hopefully SID files will be correct and updated revisions will not be needed. I think a robust CORECONF client needs to know the 3-tuples of all the SID files used by a server. It is not enough just to know module@revision-date. We want to be able to rely on centralized (common) SID files and not have to retrieve each one from each server (because they doctored the real SID file or replaced it with their own). Andy > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000e263a5059c3742cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 15, 2020 at 4:17 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Carsten Bormann <cabo@= tzi.org> wrote:
=C2=A0 =C2=A0 >> Yes, if we evolved the design during WG processing, = then we could well
=C2=A0 =C2=A0 >> have dead SIDs.=C2=A0 We could, at WGLC or IESG appr= oval, edit the SID file
=C2=A0 =C2=A0 >> and mark them as useable again.=C2=A0 (If there were= no running code, we
=C2=A0 =C2=A0 >> could reset the SID file entirely at that point) The= SID file
=C2=A0 =C2=A0 >> maintains the memory of the dead values for only as = long as we want it
=C2=A0 =C2=A0 >> to.

=C2=A0 =C2=A0 > This paragraph is exactly reflecting my nightmares about= this.=C2=A0 We
=C2=A0 =C2=A0 > could do a lot of things, if we wanted to.=C2=A0 What ar= e our unambiguous,
=C2=A0 =C2=A0 > not-to-be-missed instructions that make this fool-proof?=

We will screw up, but the fools are often brilliant in their ability to get=
around fool-proofing :-)

=C2=A0 =C2=A0 > I would expect that we get rid of dead SIDs about as oft= en as we revoke
=C2=A0 =C2=A0 > TCP port number assignments, i.e., essentially never.=C2= =A0 But this
=C2=A0 =C2=A0 > requires getting around the cognitive dissonance of just= having
=C2=A0 =C2=A0 > =E2=80=9Cwasted=E2=80=9D a SID value (*): With very stro= ngly worded instructions, I=E2=80=99d
=C2=A0 =C2=A0 > assume.

=C2=A0 =C2=A0 > Gr=C3=BC=C3=9Fe, Carsten

=C2=A0 =C2=A0 > (*) (Note that there are way more SIDs than there are TC= P ports.)

The time when we are most likely to create dead SID values is during the development of running code between WG Adoption and WGLC.
I think it is reasonable thing to decide, with some communication among
implementers to reset/re-allocate.

Revisions to the YANG which deprecate leafs and therefore create deprecated=
SID values are different: deployed code might still be using them.
(If we are revising published YANG, then certainly can never reset the SID = process!)


IMO there shou= ld be no concept of conformance status for a SID file.
It would b= e unwise to recover SIDs of obsolete YANG definitions.
It is safe= r to just burn the wasted range and keep range assignments small.

Do SID files need to be identified by a 3-tuple {module-nam= e, module-revision, sid-file-revision }

=C2=A0 =C2= =A0foo@2020-01-15.1=C2=A0 -> { foo, 2020-01-15, 1 }

=
If the sid-file-revision is missing then it defaults to '1'.
Hopefully SID files will be correct and updated revisions will not= be needed.

I think a robust CORECONF client needs= to know the 3-tuples of all the SID files used by a=C2=A0server.
It is not enough just to know module@revision-date.=C2=A0 We want to be ab= le to
rely on centralized (common) SID files and not have to retr= ieve each one
from each server (because they doctored the real SI= D file or replaced it with their own).


<= div>Andy




--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000e263a5059c3742cf-- From nobody Thu Jan 16 02:28: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 8628412001B for ; Thu, 16 Jan 2020 02:28:57 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 23G7YbOEhdZJ for ; Thu, 16 Jan 2020 02:28:52 -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 9B43A12001E for ; Thu, 16 Jan 2020 02:28:52 -0800 (PST) Received: by mail-wm1-x32b.google.com with SMTP id f129so3192871wmf.2 for ; Thu, 16 Jan 2020 02:28:52 -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:content-transfer-encoding; bh=Ixie+8pizSsvoyYjGQjEdL7MDFQR1vfu7KACYUcnQzw=; b=ywrtMJNGySMjBk03aZspZeDrrquNNbqQUho/VUrp69jjMhv8jYRevBb3UE23pz54PU jI9BhFSlj4wN5nulOwBhluWxJEC+vFOgpz2msQ1SsutQe6+92XNqsORSe8s8k4kAVm4i Ka/SQ6/YXQzAVdQVdwWNJvotP9bg3b92HAu0/vNXTemSvLodsTb/PwBfP+POLptSEYbv hzO9D2CrWjpaFvpVavx232A0qjRUNyu9zcNWOf7UjTDoTZsN1fLa+yd4nYbFlBL+dyPv l0dJLfaIdaR2KOqFXc+WmuEL87AZK6CPUDaFF+PHwzlQl+/ZNgoBEiBdoi23nskQ2lC3 D34Q== 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:content-transfer-encoding; bh=Ixie+8pizSsvoyYjGQjEdL7MDFQR1vfu7KACYUcnQzw=; b=BSP5wGOr4sNjLd/82fDpQjA73GSWKiSun0aohzqX36nGFv4d8kUQCRi6hT41CJ3y43 m5nyHCXaQnR6sCP8qznkrOjUrc2DLpylW/21C5NNPKjzAGgCyW0FsQNfvtMhZPOnK7Xx 62ijxKAE6ciB+oFsolEDvQHBSXyDVs+sX4I2c5XR7FuZCWw8YJU6oqCj3++HzWr8sQtI /sk9zKhYPBQkHbqdTjDFxJPHooMSP1zO+fgw15azMSPdb4Ik9RglZgwtqQJHMexclWLQ 0X8KzodbtbT1kMqvynKNC37gwU6x6SpWHCgHXhbnJyyR+CR0zugUJHs5ng81MtiD7j53 qbLA== X-Gm-Message-State: APjAAAWO/vdbVjAfe6SPjZCXqfO6NhKgV4kZ1i873VFfc84jDA/CjqHD CIHt3HeQuanzfJMaLFFdOQF7KTPo/+t9TKiZF+jinQ== X-Google-Smtp-Source: APXvYqwNT1SjYrvhowMAw7DZvB7k/Q1jV7iKguBbB7uwExCFELeFNpMb3KW44APsPg1j/pqLxpuMsUfhC2xQR8bsF4o= X-Received: by 2002:a7b:c1c7:: with SMTP id a7mr5105574wmj.168.1579170530982; Thu, 16 Jan 2020 02:28:50 -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> In-Reply-To: From: Ivaylo Petrov Date: Thu, 16 Jan 2020 11:28:24 +0100 Message-ID: To: Andy Bierman , Alexander Pelov , Michel Veillette Cc: Michael Richardson , Core Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Thu, 16 Jan 2020 10:28:57 -0000 Hello, Thank you very much for the discussion. It brings a lot of interesting perspectives on the problem how to make sure SIDs are most usable for people and make it difficult to make mistakes. I believe there are a few important points that need to be agreed upon before we accept how to fix anything. Here are my assumptions: 1. we don't want to waste too much SIDs while creating SID modules 2. we want SIDs to be as stable as possible 3. we don't want to unpleasantly surprise people with the way SIDs need to be used as compared to only using YANG modules. My question is what happens currently with an implementation that uses a version of YANG module that has been present inside a draft, but have differences with the version in the final RFC that is published from the draft? I could not see multiple revisions of YANG modules associated with the same RFC in the IANA page. I also don't see update of the revision information for a module that has been changed in different versions of a draft. Therefore my impression is that people that start using YANG modules that are not fully finished either are ready to update their implementation later when the modules are finalized or they control both ends and can handle the fact that they use YANG module version that could be incompatible with other implementations. Coming from assumption 3 then is my question - do we need to make anything different? I don't think the SID file needs to be published as available on IANA's web page before the publication of an RFC. Doing so would open a huge potential for problems a number of which have already been mentioned in this thread. For me this does not contradict assumption 2 as people should be aware of the possible stability issues before publication of the RFC and that should the expected behaviour from their point of view considering it is already the case with YANG modules. Then going back to early allocation, what is done during early allocation is simply assigning ranges, not registration of the SIDs themselves. Those ranges are used to generate the .sid files in the draft and people can use the values from the draft at their own risk if they so decide, but they should be aware that those values can change. I suspect that I am missing something here, but if I am not, then SID files do not need to include dead SIDs. There might be SIDs that are present in one published version of a module and not in the next one, but we can not delete them as the older revision of the YANG module might still be in use by some implementations. Note that this is not a waste in this case, so we are not violating assumption 1. I am not sure I see how a version of the .sid file will help here. My concern is that it will make finding the SID file that one wants more difficult - one needs to know both the yang version and a sid file version + the sid in order to be able to understand it. Currently one can find the sid file that covers a range and from inside it figure out which revision of which module is used and that is straight-forward. Having multiple .sid files also means that verification of SIDs will be that much more difficult as it will be spread possibly over a number of files. Andy, you have an interesting point about what will happen if there is a problem with our .sid file generation tool. Could you give examples of the types of errors that would cause significant issues? My general answer is - if we have published the .sid file, some SIDs might be lost. This is better than the alternative of modifying the meaning of a SID leading to possible ambiguity. Fixing such errors might require updating some .sid files and doing firmware update, which would not be a pleasant thing. However for me one vital part of the role of the Experts is to check that the output of the tool makes sense and to guard against big allocation issues. A possibly interesting thing to do would be to create another version of the SID allocation tool. That way having two independent implementations would greatly reduce the risk of issues if they produce the same output. Another safeguard here is the fact that SID ranges are independent, therefore if the tool messes up something, it should not be possible to do so in a way that affects other ranges. I currently don't see how a problem - big, but subtle, in the generation software can create a situation that would make me want to change the SID architecture. Best regards, Ivaylo On Thu, Jan 16, 2020 at 1:54 AM Andy Bierman wrote: > > > > On Wed, Jan 15, 2020 at 4:17 PM Michael Richardson wrote: >> >> >> Carsten Bormann wrote: >> >> Yes, if we evolved the design during WG processing, then we could= well >> >> have dead SIDs. We could, at WGLC or IESG approval, edit the SID= file >> >> and mark them as useable again. (If there were no running code, = we >> >> could reset the SID file entirely at that point) The SID file >> >> maintains the memory of the dead values for only as long as we wa= nt it >> >> to. >> >> > This paragraph is exactly reflecting my nightmares about this. We >> > could do a lot of things, if we wanted to. What are our unambiguo= us, >> > not-to-be-missed instructions that make this fool-proof? >> >> We will screw up, but the fools are often brilliant in their ability to = get >> around fool-proofing :-) >> >> > I would expect that we get rid of dead SIDs about as often as we r= evoke >> > TCP port number assignments, i.e., essentially never. But this >> > requires getting around the cognitive dissonance of just having >> > =E2=80=9Cwasted=E2=80=9D a SID value (*): With very strongly worde= d instructions, I=E2=80=99d >> > assume. >> >> > Gr=C3=BC=C3=9Fe, Carsten >> >> > (*) (Note that there are way more SIDs than there are TCP ports.) >> >> The time when we are most likely to create dead SID values is during the >> development of running code between WG Adoption and WGLC. >> I think it is reasonable thing to decide, with some communication among >> implementers to reset/re-allocate. >> >> Revisions to the YANG which deprecate leafs and therefore create depreca= ted >> SID values are different: deployed code might still be using them. >> (If we are revising published YANG, then certainly can never reset the S= ID process!) > > > > IMO there should be no concept of conformance status for a SID file. > It would be unwise to recover SIDs of obsolete YANG definitions. > It is safer to just burn the wasted range and keep range assignments smal= l. > > Do SID files need to be identified by a 3-tuple {module-name, module-revi= sion, sid-file-revision } > > foo@2020-01-15.1 -> { foo, 2020-01-15, 1 } > > If the sid-file-revision is missing then it defaults to '1'. > Hopefully SID files will be correct and updated revisions will not be nee= ded. > > I think a robust CORECONF client needs to know the 3-tuples of all the SI= D files used by a server. > It is not enough just to know module@revision-date. We want to be able t= o > rely on centralized (common) SID files and not have to retrieve each one > from each server (because they doctored the real SID file or replaced it = with their own). > > > Andy > > > >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Jan 16 03:36:13 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 7FD5212002E for ; Thu, 16 Jan 2020 03:36:12 -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=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 YvqlYvtwFbmG for ; Thu, 16 Jan 2020 03:36:07 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1EF0120019 for ; Thu, 16 Jan 2020 03:36:06 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id o13so22219858ljg.4 for ; Thu, 16 Jan 2020 03:36:06 -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=PuerqDxW2ctl2u7Q5OjJbiQ2z+g26D7/x1SwW+7Tl0Q=; b=ZJbbIuEciAFryXPXz0+g+4Ap4Q26mO3H0h+4RsJWSo0Biibh+7s3m5hfL+pnwP4D/n LV2zE+YKph8sDorAzJTLJI7kxBJSKA3bMqELwaAlhC1IKRi/T0jzhwJd/sTw+jTXDUA8 tKtFlyORlL5Ch0p01VkwroGyR0HrB0YAnJlTuhOULnJXAclpUn5wUY/j2Pbem6w7/5mD Att/ZQs5qvFN7NTRXjI3gyOHBrn5SGKCbH8ofRG5siA/YdJWs5qd8ZncR4t06d5Jdloz mvOLtDnVPJ+Ba9l0nuiVmD20o+ULLqemLmG/brG9hxFRmu19Pgpb/uaYlv08Uq4YbZ67 juqA== 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=PuerqDxW2ctl2u7Q5OjJbiQ2z+g26D7/x1SwW+7Tl0Q=; b=gEymrdbYyKDjf3W+h+dr8BZto3pue34WEKIKMHE0roiKeZPP/CFGt5+wxh5Z2V2V1I YTsvie1diLftRcscZ829i0A71iCvZ7W/w2k6NTTniUzLd6ZnUlGzDXLgmIrf+UWNBV0g ydycXLsSqPRRcqR4BtACLorqvjMqfxzKHndOJXhAa4NZGNx+4sF8RKgsUPSC5RU5ttrl ResLyOShT/fy+dJ2W6HfUR+BXlYD1mwM3+muYqhcvhqmDopbacFykbZsK3IRDve2RHp2 mOSeYIGkB/KRLzTUWPB0WD7rZQJiIy/V9y2zfP6xgXMFN/nB5ElOdvH3cpMm8LSYtxrC SJ0w== X-Gm-Message-State: APjAAAVYG9+FfYHzkdNTJLbu1i6eSDG0e6/HjimLi8gttpdRoD/V8V5D qE5OnHaeEE91w6jLDehBGNvg83Z9GyrnYIB7zs4foA== X-Google-Smtp-Source: APXvYqzN/D4UyafEX/41xAplxABTMQ/PRs1jJPtPhxvkIBuBNTZMzn17VELtc19BWj7p3LTMY3CAemPCEJ99tO8dDuo= X-Received: by 2002:a2e:9143:: with SMTP id q3mr1988943ljg.199.1579174565185; Thu, 16 Jan 2020 03:36:05 -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> In-Reply-To: From: Andy Bierman Date: Thu, 16 Jan 2020 03:35:53 -0800 Message-ID: To: Ivaylo Petrov Cc: Alexander Pelov , Michel Veillette , Michael Richardson , Core Content-Type: multipart/alternative; boundary="000000000000ff20e5059c403aa8" 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: Thu, 16 Jan 2020 11:36:13 -0000 --000000000000ff20e5059c403aa8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 16, 2020 at 2:28 AM Ivaylo Petrov wrote: > Hello, > > Thank you very much for the discussion. It brings a lot of interesting > perspectives on the problem how to make sure SIDs are most usable for > people and make it difficult to make mistakes. > > I believe there are a few important points that need to be agreed upon > before we accept how to fix anything. Here are my assumptions: > 1. we don't want to waste too much SIDs while creating SID modules > 2. we want SIDs to be as stable as possible > 3. we don't want to unpleasantly surprise people with the way SIDs > need to be used as compared to only using YANG modules. > > YANG module development has proven to be a messy process. It is the exception, not the rule, that a module stays stable from draft-00 to RFC. > My question is what happens currently with an implementation that uses > a version of YANG module that has been present inside a draft, but > have differences with the version in the final RFC that is published > from the draft? The implementor is on their own, just like now for YANG, and just like MIB modules for 30+ years. Vendors know that implementing a work-in-progress is dangerous. WGs should know that publishing an RFC with zero implementation experience for the technology in the draft is going to produce an inferior result. Only the RFC versions of MIB or YANG modules is ever recorded by IANA. The work-in-progress versions are extracted from drafts. The YangModels github repo stores these modules. > I could not see multiple revisions of YANG modules > associated with the same RFC in the IANA page. I also don't see update > of the revision information for a module that has been changed in > different versions of a draft. Therefore my impression is that people > that start using YANG modules that are not fully finished either are > ready to update their implementation later when the modules are > finalized or they control both ends and can handle the fact that they > use YANG module version that could be incompatible with other > implementations. Coming from assumption 3 then is my question - do we > need to make anything different? I don't think the SID file needs to > be published as available on IANA's web page before the publication of > an RFC. Doing so would open a huge potential for problems a number of > which have already been mentioned in this thread. For me this does not > contradict assumption 2 as people should be aware of the possible > stability issues before publication of the RFC and that should the > expected behaviour from their point of view considering it is already > the case with YANG modules. Then going back to early allocation, what > is done during early allocation is simply assigning ranges, not > registration of the SIDs themselves. Those ranges are used to generate > the .sid files in the draft and people can use the values from the > draft at their own risk if they so decide, but they should be aware > that those values can change. I suspect that I am missing something > here, but if I am not, then SID files do not need to include dead > SIDs. There might be SIDs that are present in one published version of > a module and not in the next one, but we can not delete them as the > older revision of the YANG module might still be in use by some > implementations. Note that this is not a waste in this case, so we are > not violating assumption 1. > > I am not sure I see how a version of the .sid file will help here. My > concern is that it will make finding the SID file that one wants more > difficult - one needs to know both the yang version and a sid file > version + the sid in order to be able to understand it. Currently one > can find the sid file that covers a range and from inside it figure > out which revision of which module is used and that is > straight-forward. Having multiple .sid files also means that > verification of SIDs will be that much more difficult as it will be > spread possibly over a number of files. > > Relying on the YANG to SID algorithm to generate the SID file assumes that every tool will generate the SID file correctly and every tool is perfect and never has a new bug or a regression bug. It is more realistic that SID interoperability will be achieved using actual SID files downloaded from a common repo. A SID file version allows for corrections to the YANG to SID translation. The YANG module revision is not changing. It is not at fault. Multiple SID files for the same YANG revision should be distinguishable. > Andy, you have an interesting point about what will happen if there is > a problem with our .sid file generation tool. Could you give examples > of the types of errors that would cause significant issues? My general > answer is - if we have published the .sid file, some SIDs might be > lost. This is better than the alternative of modifying the meaning of > a SID leading to possible ambiguity. Fixing such errors might require > updating some .sid files and doing firmware update, which would not be > a pleasant thing. However for me one vital part of the role of the > Experts is to check that the output of the tool makes sense and to > guard against big allocation issues. A possibly interesting thing to > do would be to create another version of the SID allocation tool. That > way having two independent implementations would greatly reduce the > risk of issues if they produce the same output. Another safeguard here > is the fact that SID ranges are independent, therefore if the tool > messes up something, it should not be possible to do so in a way that > affects other ranges. I currently don't see how a problem - big, but > subtle, in the generation software can create a situation that would > make me want to change the SID architecture. > > It would be naive to think that pyang cannot possibly have a bug in it, or that YANG complexity in real modules is low enough to simply inspect the file output like your constrained voucher example. How does the output look for ietf-bgp.yang (or any of the recent routing modules). When a YANG module has a bug in it, a new revision with a new revision date is published to fix it. IMO it would be wise to provide a mechanism to fix a bug in a SID file. Multiple independent implementations are always good for finding bugs in the tools. There are so many ways to change a YANG module, I suspect that the code that updates a SID file (as opposed to resetting the SID translation each time) has the most opportunity for bugs. Best regards, > Ivaylo > Andy > > On Thu, Jan 16, 2020 at 1:54 AM Andy Bierman wrote: > > > > > > > > On Wed, Jan 15, 2020 at 4:17 PM Michael Richardson < > mcr+ietf@sandelman.ca> wrote: > >> > >> > >> Carsten Bormann wrote: > >> >> Yes, if we evolved the design during WG processing, then we > could well > >> >> have dead SIDs. We could, at WGLC or IESG approval, edit the > SID file > >> >> and mark them as useable again. (If there were no running code= , > we > >> >> could reset the SID file entirely at that point) The SID file > >> >> maintains the memory of the dead values for only as long as we > want it > >> >> to. > >> > >> > This paragraph is exactly reflecting my nightmares about this. = We > >> > could do a lot of things, if we wanted to. What are our > unambiguous, > >> > not-to-be-missed instructions that make this fool-proof? > >> > >> We will screw up, but the fools are often brilliant in their ability t= o > get > >> around fool-proofing :-) > >> > >> > I would expect that we get rid of dead SIDs about as often as we > revoke > >> > TCP port number assignments, i.e., essentially never. But this > >> > requires getting around the cognitive dissonance of just having > >> > =E2=80=9Cwasted=E2=80=9D a SID value (*): With very strongly wor= ded instructions, > I=E2=80=99d > >> > assume. > >> > >> > Gr=C3=BC=C3=9Fe, Carsten > >> > >> > (*) (Note that there are way more SIDs than there are TCP ports.= ) > >> > >> The time when we are most likely to create dead SID values is during t= he > >> development of running code between WG Adoption and WGLC. > >> I think it is reasonable thing to decide, with some communication amon= g > >> implementers to reset/re-allocate. > >> > >> Revisions to the YANG which deprecate leafs and therefore create > deprecated > >> SID values are different: deployed code might still be using them. > >> (If we are revising published YANG, then certainly can never reset the > SID process!) > > > > > > > > IMO there should be no concept of conformance status for a SID file. > > It would be unwise to recover SIDs of obsolete YANG definitions. > > It is safer to just burn the wasted range and keep range assignments > small. > > > > Do SID files need to be identified by a 3-tuple {module-name, > module-revision, sid-file-revision } > > > > foo@2020-01-15.1 -> { foo, 2020-01-15, 1 } > > > > If the sid-file-revision is missing then it defaults to '1'. > > Hopefully SID files will be correct and updated revisions will not be > needed. > > > > I think a robust CORECONF client needs to know the 3-tuples of all the > SID files used by a server. > > It is not enough just to know module@revision-date. We want to be able > to > > rely on centralized (common) SID files and not have to retrieve each on= e > > from each server (because they doctored the real SID file or replaced i= t > with their own). > > > > > > Andy > > > > > > > >> > >> -- > >> Michael Richardson , Sandelman Software Works > >> -=3D IPv6 IoT consulting =3D- > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > --000000000000ff20e5059c403aa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 16, 2020 at 2:28 AM Ivayl= o Petrov <ivaylo@ackl.io> wrote= :
Hello,

Thank you very much for the discussion. It brings a lot of interesting
perspectives on the problem how to make sure SIDs are most usable for
people and make it difficult to make mistakes.

I believe there are a few important points that need to be agreed upon
before we accept how to fix anything. Here are my assumptions:
1. we don't want to waste too much SIDs while creating SID modules
2. we want SIDs to be as stable as possible
3. we don't want to unpleasantly surprise people with the way SIDs
need to be used as compared to only using YANG modules.


YANG module development has proven to = be a messy process.
It is the exception, not the rule, that a mod= ule stays stable from draft-00 to RFC.
=C2=A0
My question is what happens currently with an implementation that uses
a version of YANG module that has been present inside a draft, but
have differences with the version in the final RFC that is published
from the draft?


The impleme= ntor is on their own, just like now for YANG,
and just like MIB m= odules for 30+ years.=C2=A0 Vendors know that
implementing a work= -in-progress is dangerous.=C2=A0 WGs should know
that publishing = an RFC with zero implementation experience for the
technology in = the draft is going to produce an inferior result.

= Only the RFC versions of MIB or YANG modules is ever recorded by IANA.
The work-in-progress versions are extracted from drafts.
Th= e YangModels github repo stores these modules.

=C2=A0
I= could not see multiple revisions of YANG modules
associated with the same RFC in the IANA page. I also don't see update<= br> of the revision information for a module that has been changed in
different versions of a draft. Therefore my impression is that people
that start using YANG modules that are not fully finished either are
ready to update their implementation later when the modules are
finalized or they control both ends and can handle the fact that they
use YANG module version that could be incompatible with other
implementations. Coming from assumption 3 then is my question - do we
need to make anything different? I don't think the SID file needs to be published as available on IANA's web page before the publication of<= br> an RFC. Doing so would open a huge potential for problems a number of
which have already been mentioned in this thread. For me this does not
contradict assumption 2 as people should be aware of the possible
stability issues before publication of the RFC and that should the
expected behaviour from their point of view considering it is already
the case with YANG modules. Then going back to early allocation, what
is done during early allocation is simply assigning ranges, not
registration of the SIDs themselves. Those ranges are used to generate
the .sid files in the draft and people can use the values from the
draft at their own risk if they so decide, but they should be aware
that those values can change. I suspect that I am missing something
here, but if I am not, then SID files do not need to include dead
SIDs. There might be SIDs that are present in one published version of
a module and not in the next one, but we can not delete them as the
older revision of the YANG module might still be in use by some
implementations. Note that this is not a waste in this case, so we are
not violating assumption 1.

I am not sure I see how a version of the .sid file will help here. My
concern is that it will make finding the SID file that one wants more
difficult - one needs to know both the yang version and a sid file
version + the sid in order to be able to understand it. Currently one
can find the sid file that covers a range and from inside it figure
out which revision of which module is used and that is
straight-forward. Having multiple .sid files also means that
verification of SIDs will be that much more difficult as it will be
spread possibly over a number of files.


Relying on the YANG to SID algorithm t= o generate the SID file
assumes that every tool will generate the= SID file correctly and
every tool is perfect and never has a new= bug or a regression bug.
It is more realistic that SID interoper= ability will be achieved using actual SID files
downloaded from a= common repo.=C2=A0 A SID file version allows for
corrections to = the YANG to SID translation.=C2=A0 The YANG module revision
is no= t changing.=C2=A0 It is not at fault.=C2=A0 Multiple SID files for the same= YANG revision
should be distinguishable.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Andy, you have an interesting point about what will happen if there is
a problem with our .sid file generation tool. Could you give examples
of the types of errors that would cause significant issues? My general
answer is - if we have published the .sid file, some SIDs might be
lost. This is better than the alternative of modifying the meaning of
a SID leading to possible ambiguity. Fixing such errors might require
updating some .sid files and doing firmware update, which would not be
a pleasant thing. However for me one vital part of the role of the
Experts is to check that the output of the tool makes sense and to
guard against big allocation issues. A possibly interesting thing to
do would be to create another version of the SID allocation tool. That
way having two independent implementations would greatly reduce the
risk of issues if they produce the same output. Another safeguard here
is the fact that SID ranges are independent, therefore if the tool
messes up something, it should not be possible to do so in a way that
affects other ranges. I currently don't see how a problem - big, but subtle, in the generation software can create a situation that would
make me want to change the SID architecture.


It would be naive to think that pyang = cannot possibly have a bug in it,
or that YANG complexity in real= modules is low enough to simply inspect
the file output like you= r constrained voucher example. How does the output look
for ietf-= bgp.yang (or any of the recent routing modules).=C2=A0

=
When a YANG module has a bug in it, a new revision with a new revision= date is
published to fix it. IMO it would be wise to provide a m= echanism to fix a bug in
a SID file.=C2=A0

Multiple independent implementations are always good for finding bugs in= the tools.
There are so many ways to change a YANG module, I sus= pect that the code
that updates a SID file (as opposed to resetti= ng the SID translation each time)
has the most opportunity for bu= gs.


Best regards,
Ivaylo


Andy
= =C2=A0

On Thu, Jan 16, 2020 at 1:54 AM Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Wed, Jan 15, 2020 at 4:17 PM Michael Richardson <mcr+ietf@sandelman.ca>= wrote:
>>
>>
>> Carsten Bormann <cabo@tzi.org> wrote:
>>=C2=A0 =C2=A0 =C2=A0>> Yes, if we evolved the design during W= G processing, then we could well
>>=C2=A0 =C2=A0 =C2=A0>> have dead SIDs.=C2=A0 We could, at WGL= C or IESG approval, edit the SID file
>>=C2=A0 =C2=A0 =C2=A0>> and mark them as useable again.=C2=A0 = (If there were no running code, we
>>=C2=A0 =C2=A0 =C2=A0>> could reset the SID file entirely at t= hat point) The SID file
>>=C2=A0 =C2=A0 =C2=A0>> maintains the memory of the dead value= s for only as long as we want it
>>=C2=A0 =C2=A0 =C2=A0>> to.
>>
>>=C2=A0 =C2=A0 =C2=A0> This paragraph is exactly reflecting my ni= ghtmares about this.=C2=A0 We
>>=C2=A0 =C2=A0 =C2=A0> could do a lot of things, if we wanted to.= =C2=A0 What are our unambiguous,
>>=C2=A0 =C2=A0 =C2=A0> not-to-be-missed instructions that make th= is fool-proof?
>>
>> We will screw up, but the fools are often brilliant in their abili= ty to get
>> around fool-proofing :-)
>>
>>=C2=A0 =C2=A0 =C2=A0> I would expect that we get rid of dead SID= s about as often as we revoke
>>=C2=A0 =C2=A0 =C2=A0> TCP port number assignments, i.e., essenti= ally never.=C2=A0 But this
>>=C2=A0 =C2=A0 =C2=A0> requires getting around the cognitive diss= onance of just having
>>=C2=A0 =C2=A0 =C2=A0> =E2=80=9Cwasted=E2=80=9D a SID value (*): = With very strongly worded instructions, I=E2=80=99d
>>=C2=A0 =C2=A0 =C2=A0> assume.
>>
>>=C2=A0 =C2=A0 =C2=A0> Gr=C3=BC=C3=9Fe, Carsten
>>
>>=C2=A0 =C2=A0 =C2=A0> (*) (Note that there are way more SIDs tha= n there are TCP ports.)
>>
>> The time when we are most likely to create dead SID values is duri= ng the
>> development of running code between WG Adoption and WGLC.
>> I think it is reasonable thing to decide, with some communication = among
>> implementers to reset/re-allocate.
>>
>> Revisions to the YANG which deprecate leafs and therefore create d= eprecated
>> SID values are different: deployed code might still be using them.=
>> (If we are revising published YANG, then certainly can never reset= the SID process!)
>
>
>
> IMO there should be no concept of conformance status for a SID file. > It would be unwise to recover SIDs of obsolete YANG definitions.
> It is safer to just burn the wasted range and keep range assignments s= mall.
>
> Do SID files need to be identified by a 3-tuple {module-name, module-r= evision, sid-file-revision }
>
>=C2=A0 =C2=A0 foo@2020-01-15.1=C2=A0 -> { foo, 2020-01-15, 1 }
>
> If the sid-file-revision is missing then it defaults to '1'. > Hopefully SID files will be correct and updated revisions will not be = needed.
>
> I think a robust CORECONF client needs to know the 3-tuples of all the= SID files used by a server.
> It is not enough just to know module@revision-date.=C2=A0 We want to b= e able to
> rely on centralized (common) SID files and not have to retrieve each o= ne
> from each server (because they doctored the real SID file or replaced = it with their own).
>
>
> Andy
>
>
>
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works >>=C2=A0 -=3D IPv6 IoT consulting =3D-
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core >
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core
--000000000000ff20e5059c403aa8-- From nobody Thu Jan 16 04:50:23 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 2383112002E for ; Thu, 16 Jan 2020 04:50:23 -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=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 3kWXo_VSUQ91 for ; Thu, 16 Jan 2020 04:50:18 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 11FA612004C for ; Thu, 16 Jan 2020 04:50:18 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id b15so15472285lfc.4 for ; Thu, 16 Jan 2020 04:50:17 -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=X8/9bPmjzPNKkLxce/A/z1Ov1JmOEi8eENwcgCB9lLo=; b=KY1js9zoJqen0hoWL81FsE5b9+wjiKRWTCznoPGbBCRPiWLWd81006/Ougp5VwrdNP QAj3yCVClG7+l9uvV9ndSanEhH22fRNdNkt9d4d24cn11SWUWdsJy0kRpASJzB3Wc6+O Yx7/3ZsFh7Wkw9UoOWhHaHdG2sb7j2890Emt63HuPp7zBnGrbe0M9DTti5cj7Znjw/Up OkB5/pCkIWcr1AGTHCpHliO0LISGa9OTLh/mlJwvo9t+Y4Zpo/gNfl/OH5hS5Gs6danN v3gtYYHsXwu9wzichRvPvZQPW06F159rMQh2LDSUxcVPSrrvQRQx9ClmVyXMLgvOPyJG HJnQ== 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=X8/9bPmjzPNKkLxce/A/z1Ov1JmOEi8eENwcgCB9lLo=; b=qQa4sVAyfHgOPiLEdMMX5LgXAWxjCw/1jLL9fY0yQnG3H+2UKEcSZZ1JVOmwMLnP3Z iPm0PWUOZvY59MGhX4ozqf1THpWEirrbUv1oxhfMKy8O4YLMykmTJIf7iZeCQ/I7hmhG jzaDtGZvnAxuUxboh/3/xirp/urAp9LOnMLu8b8iaU4hZITilJAhs+Da77/MqZsYYQVe bYIrYcAj0eIpAgiOK7ajHPbuFHkTN4zdO7dFYp951u0htuXVMDRTos8wyMyMpsvnRBcd 3REFg2LMMQSjte335w6ttWDdpm5/XXxbrUDSwtIGFHMIXf+XQm+HIszbEK1vkEkRyauy 8VEw== X-Gm-Message-State: APjAAAVJEUM0mnqDopk3Y9AUOma1G2JASJh6p6UwikFwoGT5AzEWB9g4 Liy2XhIH0DKUc0S+9N48nmaVexokTx8vottMJEnSyRMj X-Google-Smtp-Source: APXvYqx6hqZj96aICT+px1Pw0w6kNRC4fbtLFE9Dlj42NeOovpPHASxHZUpmC8cvHIk4oHD4G8SJJgGuu5AgyH9WxDk= X-Received: by 2002:a19:2389:: with SMTP id j131mr2157140lfj.86.1579179016147; Thu, 16 Jan 2020 04:50:16 -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> In-Reply-To: From: Andy Bierman Date: Thu, 16 Jan 2020 04:50:04 -0800 Message-ID: To: Ivaylo Petrov Cc: Alexander Pelov , Michel Veillette , Michael Richardson , Core Content-Type: multipart/alternative; boundary="0000000000004b6ef1059c414463" 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: Thu, 16 Jan 2020 12:50:23 -0000 --0000000000004b6ef1059c414463 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 16, 2020 at 2:28 AM Ivaylo Petrov wrote: > Hello, > > Thank you very much for the discussion. It brings a lot of interesting > perspectives on the problem how to make sure SIDs are most usable for > people and make it difficult to make mistakes. > > I believe there are a few important points that need to be agreed upon > before we accept how to fix anything. Here are my assumptions: > 1. we don't want to waste too much SIDs while creating SID modules > 2. we want SIDs to be as stable as possible > 3. we don't want to unpleasantly surprise people with the way SIDs > need to be used as compared to only using YANG modules. > > These goals are not going to be easy to achieve. The biggest challenge is maintaining existing SIDs from draft to draft. There is a significant amount of metadata needed to generate a SID file, starting with all the previous YANG revisions or SID files, and when/if the SID files have been reset vs. updated with preserved numbers. SID assignments depend on statement order. YANG identifiers do not depend on statement order at all. Most definitions are actually conceptual, and only the conceptual expansion of submodules, groupings, augments, and uses can be numbered. This leads to all sorts of opportunities for bugs. Some changes are difficult to detect (like 2 augments that get combined) which have zero impact on YANG identifiers but a huge impact on SIDs. My biggest concern about SID generation is that it depends on all the revisions of all the imported modules. The SID file for module X is dependent on the groupings expanded from module Y and Z (and Z imports A, which imports B, etc.) If any of these imported modules change at all, then the SID file for the target module can change, even though that module did not change at all. The date that the SID file is generated can change the outcome (!) How does the SID tool make sure the exact same set of imported modules is used? How are these dependencies documented in the SID file so generation of version N =3D 1 ca= n detect object changes correctly? Andy My question is what happens currently with an implementation that uses > a version of YANG module that has been present inside a draft, but > have differences with the version in the final RFC that is published > from the draft? I could not see multiple revisions of YANG modules > associated with the same RFC in the IANA page. I also don't see update > of the revision information for a module that has been changed in > different versions of a draft. Therefore my impression is that people > that start using YANG modules that are not fully finished either are > ready to update their implementation later when the modules are > finalized or they control both ends and can handle the fact that they > use YANG module version that could be incompatible with other > implementations. Coming from assumption 3 then is my question - do we > need to make anything different? I don't think the SID file needs to > be published as available on IANA's web page before the publication of > an RFC. Doing so would open a huge potential for problems a number of > which have already been mentioned in this thread. For me this does not > contradict assumption 2 as people should be aware of the possible > stability issues before publication of the RFC and that should the > expected behaviour from their point of view considering it is already > the case with YANG modules. Then going back to early allocation, what > is done during early allocation is simply assigning ranges, not > registration of the SIDs themselves. Those ranges are used to generate > the .sid files in the draft and people can use the values from the > draft at their own risk if they so decide, but they should be aware > that those values can change. I suspect that I am missing something > here, but if I am not, then SID files do not need to include dead > SIDs. There might be SIDs that are present in one published version of > a module and not in the next one, but we can not delete them as the > older revision of the YANG module might still be in use by some > implementations. Note that this is not a waste in this case, so we are > not violating assumption 1. > > I am not sure I see how a version of the .sid file will help here. My > concern is that it will make finding the SID file that one wants more > difficult - one needs to know both the yang version and a sid file > version + the sid in order to be able to understand it. Currently one > can find the sid file that covers a range and from inside it figure > out which revision of which module is used and that is > straight-forward. Having multiple .sid files also means that > verification of SIDs will be that much more difficult as it will be > spread possibly over a number of files. > > Andy, you have an interesting point about what will happen if there is > a problem with our .sid file generation tool. Could you give examples > of the types of errors that would cause significant issues? My general > answer is - if we have published the .sid file, some SIDs might be > lost. This is better than the alternative of modifying the meaning of > a SID leading to possible ambiguity. Fixing such errors might require > updating some .sid files and doing firmware update, which would not be > a pleasant thing. However for me one vital part of the role of the > Experts is to check that the output of the tool makes sense and to > guard against big allocation issues. A possibly interesting thing to > do would be to create another version of the SID allocation tool. That > way having two independent implementations would greatly reduce the > risk of issues if they produce the same output. Another safeguard here > is the fact that SID ranges are independent, therefore if the tool > messes up something, it should not be possible to do so in a way that > affects other ranges. I currently don't see how a problem - big, but > subtle, in the generation software can create a situation that would > make me want to change the SID architecture. > > Best regards, > Ivaylo > > On Thu, Jan 16, 2020 at 1:54 AM Andy Bierman wrote: > > > > > > > > On Wed, Jan 15, 2020 at 4:17 PM Michael Richardson < > mcr+ietf@sandelman.ca> wrote: > >> > >> > >> Carsten Bormann wrote: > >> >> Yes, if we evolved the design during WG processing, then we > could well > >> >> have dead SIDs. We could, at WGLC or IESG approval, edit the > SID file > >> >> and mark them as useable again. (If there were no running code= , > we > >> >> could reset the SID file entirely at that point) The SID file > >> >> maintains the memory of the dead values for only as long as we > want it > >> >> to. > >> > >> > This paragraph is exactly reflecting my nightmares about this. = We > >> > could do a lot of things, if we wanted to. What are our > unambiguous, > >> > not-to-be-missed instructions that make this fool-proof? > >> > >> We will screw up, but the fools are often brilliant in their ability t= o > get > >> around fool-proofing :-) > >> > >> > I would expect that we get rid of dead SIDs about as often as we > revoke > >> > TCP port number assignments, i.e., essentially never. But this > >> > requires getting around the cognitive dissonance of just having > >> > =E2=80=9Cwasted=E2=80=9D a SID value (*): With very strongly wor= ded instructions, > I=E2=80=99d > >> > assume. > >> > >> > Gr=C3=BC=C3=9Fe, Carsten > >> > >> > (*) (Note that there are way more SIDs than there are TCP ports.= ) > >> > >> The time when we are most likely to create dead SID values is during t= he > >> development of running code between WG Adoption and WGLC. > >> I think it is reasonable thing to decide, with some communication amon= g > >> implementers to reset/re-allocate. > >> > >> Revisions to the YANG which deprecate leafs and therefore create > deprecated > >> SID values are different: deployed code might still be using them. > >> (If we are revising published YANG, then certainly can never reset the > SID process!) > > > > > > > > IMO there should be no concept of conformance status for a SID file. > > It would be unwise to recover SIDs of obsolete YANG definitions. > > It is safer to just burn the wasted range and keep range assignments > small. > > > > Do SID files need to be identified by a 3-tuple {module-name, > module-revision, sid-file-revision } > > > > foo@2020-01-15.1 -> { foo, 2020-01-15, 1 } > > > > If the sid-file-revision is missing then it defaults to '1'. > > Hopefully SID files will be correct and updated revisions will not be > needed. > > > > I think a robust CORECONF client needs to know the 3-tuples of all the > SID files used by a server. > > It is not enough just to know module@revision-date. We want to be able > to > > rely on centralized (common) SID files and not have to retrieve each on= e > > from each server (because they doctored the real SID file or replaced i= t > with their own). > > > > > > Andy > > > > > > > >> > >> -- > >> Michael Richardson , Sandelman Software Works > >> -=3D IPv6 IoT consulting =3D- > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > --0000000000004b6ef1059c414463 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 16, 2020 at 2:28 AM Ivayl= o Petrov <ivaylo@ackl.io> wrote= :
Hello,

Thank you very much for the discussion. It brings a lot of interesting
perspectives on the problem how to make sure SIDs are most usable for
people and make it difficult to make mistakes.

I believe there are a few important points that need to be agreed upon
before we accept how to fix anything. Here are my assumptions:
1. we don't want to waste too much SIDs while creating SID modules
2. we want SIDs to be as stable as possible
3. we don't want to unpleasantly surprise people with the way SIDs
need to be used as compared to only using YANG modules.



These goals are not goi= ng to be easy to achieve.
The biggest challenge is maintaining ex= isting SIDs from draft to draft.

There is a signif= icant amount of metadata needed to generate a SID file,
starting = with all the previous YANG revisions or SID files, and when/if
th= e SID files have been reset vs. updated with preserved numbers.
<= br>
SID assignments depend on statement order.
YANG ide= ntifiers do not depend on statement order at all.
Most defini= tions are actually conceptual, and only the
conceptual expansion = of submodules, groupings, augments, and uses
can be numbered. Thi= s leads to all sorts of opportunities for bugs.
Some changes are = difficult to detect (like 2=C2=A0augments that get combined)
whic= h have zero impact on YANG identifiers but a huge impact on SIDs.

My biggest concern about SID generation is that it depends = on all
the revisions of all the imported modules.=C2=A0 The SID f= ile for module X
is dependent on the groupings expanded from modu= le Y and Z
(and Z imports A, which imports B, etc.)
If any of these imported modules change at all, then the SID fi= le for the target module
can change, even though that module did = not change at all. The date that
the SID file is generated can ch= ange the outcome (!)=C2=A0 How does the SID tool
make sure the ex= act same set of imported modules is used?=C2=A0 How are these
dep= endencies documented in the SID file so generation of version N =3D 1 can d= etect
object changes correctly?


Andy




My question is what happens currently with an implementation that uses
a version of YANG module that has been present inside a draft, but
have differences with the version in the final RFC that is published
from the draft? I could not see multiple revisions of YANG modules
associated with the same RFC in the IANA page. I also don't see update<= br> of the revision information for a module that has been changed in
different versions of a draft. Therefore my impression is that people
that start using YANG modules that are not fully finished either are
ready to update their implementation later when the modules are
finalized or they control both ends and can handle the fact that they
use YANG module version that could be incompatible with other
implementations. Coming from assumption 3 then is my question - do we
need to make anything different? I don't think the SID file needs to be published as available on IANA's web page before the publication of<= br> an RFC. Doing so would open a huge potential for problems a number of
which have already been mentioned in this thread. For me this does not
contradict assumption 2 as people should be aware of the possible
stability issues before publication of the RFC and that should the
expected behaviour from their point of view considering it is already
the case with YANG modules. Then going back to early allocation, what
is done during early allocation is simply assigning ranges, not
registration of the SIDs themselves. Those ranges are used to generate
the .sid files in the draft and people can use the values from the
draft at their own risk if they so decide, but they should be aware
that those values can change. I suspect that I am missing something
here, but if I am not, then SID files do not need to include dead
SIDs. There might be SIDs that are present in one published version of
a module and not in the next one, but we can not delete them as the
older revision of the YANG module might still be in use by some
implementations. Note that this is not a waste in this case, so we are
not violating assumption 1.

I am not sure I see how a version of the .sid file will help here. My
concern is that it will make finding the SID file that one wants more
difficult - one needs to know both the yang version and a sid file
version + the sid in order to be able to understand it. Currently one
can find the sid file that covers a range and from inside it figure
out which revision of which module is used and that is
straight-forward. Having multiple .sid files also means that
verification of SIDs will be that much more difficult as it will be
spread possibly over a number of files.

Andy, you have an interesting point about what will happen if there is
a problem with our .sid file generation tool. Could you give examples
of the types of errors that would cause significant issues? My general
answer is - if we have published the .sid file, some SIDs might be
lost. This is better than the alternative of modifying the meaning of
a SID leading to possible ambiguity. Fixing such errors might require
updating some .sid files and doing firmware update, which would not be
a pleasant thing. However for me one vital part of the role of the
Experts is to check that the output of the tool makes sense and to
guard against big allocation issues. A possibly interesting thing to
do would be to create another version of the SID allocation tool. That
way having two independent implementations would greatly reduce the
risk of issues if they produce the same output. Another safeguard here
is the fact that SID ranges are independent, therefore if the tool
messes up something, it should not be possible to do so in a way that
affects other ranges. I currently don't see how a problem - big, but subtle, in the generation software can create a situation that would
make me want to change the SID architecture.

Best regards,
Ivaylo

On Thu, Jan 16, 2020 at 1:54 AM Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Wed, Jan 15, 2020 at 4:17 PM Michael Richardson <mcr+ietf@sandelman.ca>= wrote:
>>
>>
>> Carsten Bormann <cabo@tzi.org> wrote:
>>=C2=A0 =C2=A0 =C2=A0>> Yes, if we evolved the design during W= G processing, then we could well
>>=C2=A0 =C2=A0 =C2=A0>> have dead SIDs.=C2=A0 We could, at WGL= C or IESG approval, edit the SID file
>>=C2=A0 =C2=A0 =C2=A0>> and mark them as useable again.=C2=A0 = (If there were no running code, we
>>=C2=A0 =C2=A0 =C2=A0>> could reset the SID file entirely at t= hat point) The SID file
>>=C2=A0 =C2=A0 =C2=A0>> maintains the memory of the dead value= s for only as long as we want it
>>=C2=A0 =C2=A0 =C2=A0>> to.
>>
>>=C2=A0 =C2=A0 =C2=A0> This paragraph is exactly reflecting my ni= ghtmares about this.=C2=A0 We
>>=C2=A0 =C2=A0 =C2=A0> could do a lot of things, if we wanted to.= =C2=A0 What are our unambiguous,
>>=C2=A0 =C2=A0 =C2=A0> not-to-be-missed instructions that make th= is fool-proof?
>>
>> We will screw up, but the fools are often brilliant in their abili= ty to get
>> around fool-proofing :-)
>>
>>=C2=A0 =C2=A0 =C2=A0> I would expect that we get rid of dead SID= s about as often as we revoke
>>=C2=A0 =C2=A0 =C2=A0> TCP port number assignments, i.e., essenti= ally never.=C2=A0 But this
>>=C2=A0 =C2=A0 =C2=A0> requires getting around the cognitive diss= onance of just having
>>=C2=A0 =C2=A0 =C2=A0> =E2=80=9Cwasted=E2=80=9D a SID value (*): = With very strongly worded instructions, I=E2=80=99d
>>=C2=A0 =C2=A0 =C2=A0> assume.
>>
>>=C2=A0 =C2=A0 =C2=A0> Gr=C3=BC=C3=9Fe, Carsten
>>
>>=C2=A0 =C2=A0 =C2=A0> (*) (Note that there are way more SIDs tha= n there are TCP ports.)
>>
>> The time when we are most likely to create dead SID values is duri= ng the
>> development of running code between WG Adoption and WGLC.
>> I think it is reasonable thing to decide, with some communication = among
>> implementers to reset/re-allocate.
>>
>> Revisions to the YANG which deprecate leafs and therefore create d= eprecated
>> SID values are different: deployed code might still be using them.=
>> (If we are revising published YANG, then certainly can never reset= the SID process!)
>
>
>
> IMO there should be no concept of conformance status for a SID file. > It would be unwise to recover SIDs of obsolete YANG definitions.
> It is safer to just burn the wasted range and keep range assignments s= mall.
>
> Do SID files need to be identified by a 3-tuple {module-name, module-r= evision, sid-file-revision }
>
>=C2=A0 =C2=A0 foo@2020-01-15.1=C2=A0 -> { foo, 2020-01-15, 1 }
>
> If the sid-file-revision is missing then it defaults to '1'. > Hopefully SID files will be correct and updated revisions will not be = needed.
>
> I think a robust CORECONF client needs to know the 3-tuples of all the= SID files used by a server.
> It is not enough just to know module@revision-date.=C2=A0 We want to b= e able to
> rely on centralized (common) SID files and not have to retrieve each o= ne
> from each server (because they doctored the real SID file or replaced = it with their own).
>
>
> Andy
>
>
>
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works >>=C2=A0 -=3D IPv6 IoT consulting =3D-
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core >
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core
--0000000000004b6ef1059c414463-- From nobody Thu Jan 16 09:47:30 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 3D837120861 for ; Thu, 16 Jan 2020 09:47:28 -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 StbG8f01tUSj for ; Thu, 16 Jan 2020 09:47: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 3AA49120071 for ; Thu, 16 Jan 2020 09:47:22 -0800 (PST) Received: from client-0160.vpn.uni-bremen.de (client-0160.vpn.uni-bremen.de [134.102.107.160]) (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 47zBV027x6zyRy; Thu, 16 Jan 2020 18:47:20 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Carsten Bormann In-Reply-To: Date: Thu, 16 Jan 2020 18:47:19 +0100 Cc: Ivaylo Petrov , Core , Alexander Pelov X-Mao-Original-Outgoing-Id: 600889639.290224-5cae1b8d232acb504856dbdf0d76dbd8 Content-Transfer-Encoding: quoted-printable Message-Id: <5C3B4919-5513-4342-888D-998A11366D36@tzi.org> 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> To: Andy Bierman X-Mailer: Apple Mail (2.3608.40.2.2.4) 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: Thu, 16 Jan 2020 17:47:28 -0000 On 2020-01-16, at 13:50, Andy Bierman wrote: >=20 > There is a significant amount of metadata needed to generate a SID = file, > starting with all the previous YANG revisions or SID files, and = when/if > the SID files have been reset vs. updated with preserved numbers. Well, specifically, the current YANG module and the previous SID 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 calls 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 this role. But we need to define the process leading up to this. (Yes, that process will evolve, and we probably also need to allow = exceptions. But there must be strong guide rails that work for the vast majority 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 with = concurrent lineages; thinking that version numbers will fix any fallout. 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. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jan 16 15:17:14 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 3702A1200D7 for ; Thu, 16 Jan 2020 15:17:13 -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 kcMpaeTtWJiQ for ; Thu, 16 Jan 2020 15:17:11 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8DB1200D6 for ; Thu, 16 Jan 2020 15:17:11 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EC03B3897D; Thu, 16 Jan 2020 18:16:42 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id ABF3CD98; Thu, 16 Jan 2020 18:17:10 -0500 (EST) From: Michael Richardson To: Andy Bierman cc: Carsten Bormann , Core 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> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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: Thu, 16 Jan 2020 23:17:13 -0000 --=-=-= Content-Type: text/plain mcr> Revisions to the YANG which deprecate leafs and therefore create mcr> deprecated mcr> SID values are different: deployed code might still be using them. mcr> (If we are revising published YANG, then certainly can never reset mcr> the SID process!) Andy Bierman wrote: andy> IMO there should be no concept of conformance status for a SID file. andy> It would be unwise to recover SIDs of obsolete YANG definitions. andy> It is safer to just burn the wasted range and keep range assignments andy> small. I think that we are in agreement here. andy> Do SID files need to be identified by a 3-tuple {module-name, andy> module-revision, sid-file-revision } andy> foo@2020-01-15.1 -> { foo, 2020-01-15, 1 } seems right to me. andy> I think a robust CORECONF client needs to know the 3-tuples of all the andy> SID files used by a server. andy> It is not enough just to know module@revision-date. We want to be able andy> to andy> rely on centralized (common) SID files and not have to retrieve each andy> one andy> from each server (because they doctored the real SID file or replaced andy> it with their own). I think that you are saying that SID requires changes to the YANG module meta data which I think is available in some YANG (meta-)module? If we all agree that SID values can be deprecated, but never reused (And I do not hear anyone saying otherwise), then the highest sid-file-revision is always the correct one. If we revise the module, and we get a new module-revision, I do not think that we reset the sid file, nor do we reset the sid-file-revision. Do you concur? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4g7vYACgkQgItw+93Q 3WUrkQf+MrREw5N3KzdFZS5i6FkJNP+ycaA6WChM2QNBoa8k655x+n69DMScaNiX UiKQ76bkwZpL+eILX2WUcIxZrONoBjib5kto0EfdZyUe4HvKNJiGh++f+hAT819T egbcQGil82+D8GQglwQNFSP95o634P60Ys5/TXbGKEX74M1XdSRYbAxr9EpQ7mvO CJVtSfxqJuw4/6EXKXU7Wd+DEy9zjxyZ9wNUVFCxXZTsLoVm29JYx/S4POjMgQb+ Z33mKeeGdtLIQaRc1EjShPRkfbtoks76OQnxJhW3DqbANHFuDidHYT0dFw2Dw9DI 1sWcA+oC9FvQJPxBiMTWrDXRjt0ymw== =1a4a -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 16 15:34:49 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 DA71F1200D6 for ; Thu, 16 Jan 2020 15:34:46 -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 Jeq2iteYkhqb for ; Thu, 16 Jan 2020 15:34:43 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1371200BA for ; Thu, 16 Jan 2020 15:34:43 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BBD4C3897D for ; Thu, 16 Jan 2020 18:34:14 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7E307D98 for ; Thu, 16 Jan 2020 18:34:42 -0500 (EST) From: Michael Richardson To: Core 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> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [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: Thu, 16 Jan 2020 23:34:47 -0000 --=-=-= Content-Type: text/plain {Trying to answer several emails in this thread at once.} Ivaylo wrote: >> Thank you very much for the discussion. It brings a lot of interesting >> perspectives on the problem how to make sure SIDs are most usable for >> people and make it difficult to make mistakes. >> >> I believe there are a few important points that need to be agreed upon >> before we accept how to fix anything. Here are my assumptions: "Petrov's Three Laws of SID allocation": [in the spirit of: https://en.wikipedia.org/wiki/Three_Laws_of_Robotics] >> 1. we don't want to waste too much SIDs while creating SID modules I would have preferred if you hadn't made this the first point. >> 2. we want SIDs to be as stable as possible >> 3. we don't want to unpleasantly surprise people with the way SIDs >> need to be used as compared to only using YANG modules. andy> YANG module development has proven to be a messy process. andy> It is the exception, not the rule, that a module stays stable from draft-00 andy> to RFC. So, again, I advocate that at WGLC, that the WG consider if they wish to remove and/or renumber any SID values that have been allocated since WG Adoption. (Of course, we might being doing a BIS document, so there is history before) I see Carsten's point about the sid-file-revision could lead to people being attached to particular lineages. I don't think that is as likely; but I'm not going to die on this hill. It's JSON, we could add it later if we needed it, but it would be better to specify what it is. I am happy with an integer that increments. I think that the SID writer should probably insert it's name, revision, the date it ran, who ran it, the phase of the moon, and the current cost of a .org domain, into the file if it changes anything. >> My question is what happens currently with an implementation that uses >> a version of YANG module that has been present inside a draft, but >> have differences with the version in the final RFC that is published >> from the draft? andy> The implementor is on their own, just like now for YANG, andy> and just like MIB modules for 30+ years. Vendors know that andy> implementing a work-in-progress is dangerous. WGs should know andy> that publishing an RFC with zero implementation experience for the andy> technology in the draft is going to produce an inferior result. I think that you intended to identify a tussle here, but maybe it was rather subtle? On the one hand: work-in-progress can be dangerous to implement. On the other hand: having no implementation feedback produces inferior results. The discussion we are having here is how to enhance the stability of the spec in order to reduce cost/risk of early implementations, while at the same time allowing the WG to regret (and reverse) early decisions. I think that the flow I have suggested works: allocate at adoption time, remove dead-wood at WGLC, and make renumbering a WGLC consideration. andy> Only the RFC versions of MIB or YANG modules is ever recorded by IANA. andy> The work-in-progress versions are extracted from drafts. andy> The YangModels github repo stores these modules. Andy, should sid files be included in then along with YANG modules? We don't say anything about that, I think. I hadn't thought about this. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4g8xIACgkQgItw+93Q 3WUKOAf/bAQpo+fqyClpEz3Xl3rzoUalbkaoI61E7ZTns1Ny2e/a5UHF6OkbekGY 3VT6EbSb1pNvrrVpcDGvk1+uGa0cjTm456/Tvcv94L77ZtCKA+J1+u49iUfL1Asp BYr1iZ6xZpm/P48PR7qmPxJ/k33TS4QvW4oXiCauEkX07jReRoXl4dSvINsOKisu +f21u3YWDzIig5kzospjpwXSk5oMvDw8zgcU1MByenuPpWaSVMq+ark9xs0WDziv Br4U7dh3s7aP/pRJLFB+yQp20eYdYOMMMA8gSib1Q48x3YygmOJHHDOzcKsotSlN L75rMFOXDtm9YS1rkWlHbU7XGSYq6A== =cZBd -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 16 16:41: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 8D732120099 for ; Thu, 16 Jan 2020 16:41:02 -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, 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] 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 NjX6ccF40qkS for ; Thu, 16 Jan 2020 16:41:00 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F43512008C for ; Thu, 16 Jan 2020 16:41:00 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id y4so24617026ljj.9 for ; Thu, 16 Jan 2020 16:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v3EPDUkP1/YqeRaH3X2Mm+PEDpHD4WabdXiQ5CKZ1JI=; b=PkfTCd8qvhjR220ru1/H4y9eikDkOU+vw0+0l66VfiTKXg6b5D1TnOOlZgmIOGylV2 txb6s14feseOehtH/493870MuNgP1I9ZJgnqF+xMP1+x/2ZXDabv0S0sb+EXBOnc+BQq zOqqtSJHnZ922TadhJjPtS99xsVgftepbTtvHJIUF18FZPQUbCsdf5omqSbT9pr+T8Gs MiZ7nMdtA1TvJocKYfrwWCkXLkSHPkWKB/KQRhN+ZRaNiOm1KwmXJ4dVQ7bKlf7VnY3L FXWsdQyCpKgRWyXp6chmjKpXw9cS5/OT2qYh1iUG+1O3coVZpflPC4M7pzAyBa20rxki 6crQ== 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=v3EPDUkP1/YqeRaH3X2Mm+PEDpHD4WabdXiQ5CKZ1JI=; b=Pqx4Gdwnt2fOqjFMeghBmKf50QtGaJT1jgmOiAtetIXMV0yTJD9zX7Y4Y2E182LzAu LXRMYyqxrjrk1Le3x1A2ku1bo08ApFuYwxTcvL+jAYYR03/Tys/CkybsE6fuMGvQzCEd 1iU13XS/jeU+//bcp+TxQbryljkEleMfilrxHq3x1wo7iyM2CG7rCBuqKjDwfgWwu1yw fTf5y4UciGFpCLXAo638Mddv+amPnUeRRXRG6Luo8tJbQrwNUYBB459wH1V1u8mqhg/h x5BzY9gnSYxzklUsBUq+n79xfuPZJJWxnqejjm5nu65dNdgMPAm4cEVhFBF9M7xLTAvC O0IQ== X-Gm-Message-State: APjAAAUJY1SCq1ZHbcjW9UmvyZ1Vuy7Ep6nLSZuCN/qAnQEhZwoSIphb edNL03QUL/Dj+UAPnX1ivucuHOJd1UZl8EWKCXU1jg== X-Google-Smtp-Source: APXvYqxnk/p3CrCvWrvwQYmD/+q3o02+wGHoZScj0zYQ0+ACQ6epevnEQtBUFBpUJoa2tb0yHcgwNX1rQA2GC9g6D7g= X-Received: by 2002:a2e:9596:: with SMTP id w22mr3468711ljh.21.1579221658245; Thu, 16 Jan 2020 16:40:58 -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> <12736.1579216630@localhost> In-Reply-To: <12736.1579216630@localhost> From: Andy Bierman Date: Thu, 16 Jan 2020 16:40:45 -0800 Message-ID: To: Michael Richardson Cc: Carsten Bormann , Core Content-Type: multipart/alternative; boundary="000000000000f63968059c4b314a" 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: Fri, 17 Jan 2020 00:41:03 -0000 --000000000000f63968059c4b314a Content-Type: text/plain; charset="UTF-8" On Thu, Jan 16, 2020, 3:17 PM Michael Richardson wrote: > > mcr> Revisions to the YANG which deprecate leafs and therefore create > mcr> deprecated > mcr> SID values are different: deployed code might still be using them. > mcr> (If we are revising published YANG, then certainly can never reset > mcr> the SID process!) > > Andy Bierman wrote: > andy> IMO there should be no concept of conformance status for a SID > file. > andy> It would be unwise to recover SIDs of obsolete YANG definitions. > andy> It is safer to just burn the wasted range and keep range > assignments > andy> small. > > I think that we are in agreement here. > > andy> Do SID files need to be identified by a 3-tuple {module-name, > andy> module-revision, sid-file-revision } > > andy> foo@2020-01-15.1 -> { foo, 2020-01-15, 1 } > > seems right to me. > > andy> I think a robust CORECONF client needs to know the 3-tuples of > all the > andy> SID files used by a server. > andy> It is not enough just to know module@revision-date. We want to > be able > andy> to > andy> rely on centralized (common) SID files and not have to retrieve > each > andy> one > andy> from each server (because they doctored the real SID file or > replaced > andy> it with their own). > > I think that you are saying that SID requires changes to the YANG module > meta > data which I think is available in some YANG (meta-)module? > If we all agree that SID values can be deprecated, but never reused (And I > do > not hear anyone saying otherwise), then the highest sid-file-revision is > always the correct one. > > If we revise the module, and we get a new module-revision, I do not think > that we reset the sid file, nor do we reset the sid-file-revision. Do you > concur? > > > I think only the last sid file and the new module revision are needed, > like Carsten said. > The sid revision would start at 1 for each module, revision date. I still think it is useful to be able to correct a sid file with errors. All code has bugs and there will be bugs found that will require edits to the sid file. Andy -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > --000000000000f63968059c4b314a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 16, 2020, 3:17 PM Michael Richardson <<= a href=3D"mailto:mcr%2Bietf@sandelman.ca" target=3D"_blank" rel=3D"noreferr= er">mcr+ietf@sandelman.ca> wrote:

=C2=A0 =C2=A0 mcr> Revisions to the YANG which deprecate leafs and there= fore create
=C2=A0 =C2=A0 mcr> deprecated
=C2=A0 =C2=A0 mcr> SID values are different: deployed code might still b= e using them.
=C2=A0 =C2=A0 mcr> (If we are revising published YANG, then certainly ca= n never reset
=C2=A0 =C2=A0 mcr> the SID process!)

Andy Bierman <andy@yumaworks.com> wrote:
=C2=A0 =C2=A0 andy> IMO there should be no concept of conformance status= for a SID file.
=C2=A0 =C2=A0 andy> It would be unwise to recover SIDs of obsolete YANG = definitions.
=C2=A0 =C2=A0 andy> It is safer to just burn the wasted range and keep r= ange assignments
=C2=A0 =C2=A0 andy> small.

I think that we are in agreement here.

=C2=A0 =C2=A0 andy> Do SID files need to be identified by a 3-tuple {mod= ule-name,
=C2=A0 =C2=A0 andy> module-revision, sid-file-revision }

=C2=A0 =C2=A0 andy> foo@2020-01-15.1 -> { foo, 2020-01-15, 1 }

seems right to me.

=C2=A0 =C2=A0 andy> I think a robust CORECONF client needs to know the 3= -tuples of all the
=C2=A0 =C2=A0 andy> SID files used by a server.
=C2=A0 =C2=A0 andy> It is not enough just to know module@revision-date. = We want to be able
=C2=A0 =C2=A0 andy> to
=C2=A0 =C2=A0 andy> rely on centralized (common) SID files and not have = to retrieve each
=C2=A0 =C2=A0 andy> one
=C2=A0 =C2=A0 andy> from each server (because they doctored the real SID= file or replaced
=C2=A0 =C2=A0 andy> it with their own).

I think that you are saying that SID requires changes to the YANG module me= ta
data which I think is available in some YANG (meta-)module?
If we all agree that SID values can be deprecated, but never reused (And I = do
not hear anyone saying otherwise), then the highest sid-file-revision is always the correct one.

If we revise the module, and we get a new module-revision, I do not think that we reset the sid file, nor do we reset the sid-file-revision.=C2=A0 Do= you
concur?


I think only the last sid file and the new module revision are need= ed, like Carsten said.

The sid revision would start at 1 for each module, re= vision date.
I still think it is useful to be able t= o correct a sid file with errors.=C2=A0 All code has bugs and there will be= bugs found that will require edits to the sid file.=C2=A0

Andy


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sande= lman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-
--000000000000f63968059c4b314a-- From nobody Thu Jan 16 16:47: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 3A34412008C for ; Thu, 16 Jan 2020 16:47:51 -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=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 melrJ5AwtXyN for ; Thu, 16 Jan 2020 16:47:49 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 D4AE0120059 for ; Thu, 16 Jan 2020 16:47:48 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id f15so16992372lfl.13 for ; Thu, 16 Jan 2020 16:47:48 -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=XMb5XK/TyrIX1+JKjD0wnBJNz42w9IiTBXLRKS9FRRk=; b=nDzh3x9oqWJtGny2CNMpWDivU0v+QyLZr4PWC/6J8VFtRrZ5LYhJ17t8u8WkYVdz0N hvZd/wI7B+17d3aI0BY2M1cjcrasi7SomXqPgKVcjF+4OVYaPQaFqIxjF227+6/zYcWi ouk30UnuYegbjK0ttLQXY3aL6uxA0kaZl+0i0OLU/Ee2Y/tx/e8YrrvtldxuvCopEokX 2O9iFJidGRZo5dJbKg1UnlL5wbfIQfMjKeWGLXTOoJt98eAG8CMm6w+rbYrUZrgbetJ9 dL3quAGNxJyZ68R+FG/OIbpvEGAjz6UPBkQCcML8542igpPiSQSndkky11zJxJ28g5iP +XJA== 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=XMb5XK/TyrIX1+JKjD0wnBJNz42w9IiTBXLRKS9FRRk=; b=YmKgZDhY17g23ydt+bv80YUP56w8Q8dRAtlhrUlFJ/hL6z+5VjoAtyn+ORgKXCkX0c PBYPb3nojCOMDm7jz2TqDEPOyx5nrp8kGzvHyH9dBrpQ8FGopT2haTeos6VF0NtBfwXG kDR8kXMkx2b2DAp6QhTsGXxWoh6+J2+Hr5MBut+H9aLOIdYjeihO6icQdCW5BfVYSmPd rvc/f4fFttE6S4yc23e1p+HhzOKBvKo1rZe7ALs3LXbnWnG3LMZESoJ8l1uUcbemsj98 W6JrisqwO513mo28pt/1sLhcbV/zxRWmTPveSN/Ln0EkCJ9qIP0FY+TEuNNbtZP1XwxJ L80g== X-Gm-Message-State: APjAAAUHh9qguD54ryRdrpph8dmdSAs8iTa8vrK5sAwkrTK7GZTbgnAb MiJO5q/8Cd2xaIaMm/L3jYEUIZYWLypafYltCG9QBwjb X-Google-Smtp-Source: APXvYqwvNHhhF0Hb3HmrBmEDsFTqxOMpZK0PauhC9v1ZpAVt0COrWWZpe/F1hjuYHAFs9IhjQVRh48e6VwYGnoiWVjA= X-Received: by 2002:a19:48c5:: with SMTP id v188mr4071563lfa.100.1579222066932; Thu, 16 Jan 2020 16:47:46 -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> <16867.1579217682@localhost> In-Reply-To: <16867.1579217682@localhost> From: Andy Bierman Date: Thu, 16 Jan 2020 16:47:34 -0800 Message-ID: To: Michael Richardson Cc: Core Content-Type: multipart/alternative; boundary="00000000000052446e059c4b4a4b" 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: Fri, 17 Jan 2020 00:47:51 -0000 --00000000000052446e059c4b4a4b Content-Type: text/plain; charset="UTF-8" On Thu, Jan 16, 2020, 3:34 PM Michael Richardson wrote: > > {Trying to answer several emails in this thread at once.} > > Ivaylo wrote: > >> Thank you very much for the discussion. It brings a lot of > interesting > >> perspectives on the problem how to make sure SIDs are most usable > for > >> people and make it difficult to make mistakes. > >> > >> I believe there are a few important points that need to be agreed > upon > >> before we accept how to fix anything. Here are my assumptions: > > "Petrov's Three Laws of SID allocation": > [in the spirit of: https://en.wikipedia.org/wiki/Three_Laws_of_Robotics] > > >> 1. we don't want to waste too much SIDs while creating SID modules > > I would have preferred if you hadn't made this the first point. > > >> 2. we want SIDs to be as stable as possible > >> 3. we don't want to unpleasantly surprise people with the way SIDs > >> need to be used as compared to only using YANG modules. > > andy> YANG module development has proven to be a messy process. > andy> It is the exception, not the rule, that a module stays stable > from draft-00 > andy> to RFC. > > So, again, I advocate that at WGLC, that the WG consider if they wish to > remove and/or renumber any SID values that have been allocated since WG > Adoption. > (Of course, we might being doing a BIS document, so there is history before I agree with this plan. > I see Carsten's point about the sid-file-revision could lead to people > being > attached to particular lineages. I don't think that is as likely; but I'm > not going to die on this hill. It's JSON, we could add it later if we > needed > it, but it would be better to specify what it is. I am happy with an > integer > that increments. I think that the SID writer should probably insert it's > name, revision, the date it ran, who ran it, the phase of the moon, and the > current cost of a .org domain, into the file if it changes anything. > > >> My question is what happens currently with an implementation that > uses > >> a version of YANG module that has been present inside a draft, but > >> have differences with the version in the final RFC that is published > >> from the draft? > > andy> The implementor is on their own, just like now for YANG, > andy> and just like MIB modules for 30+ years. Vendors know that > andy> implementing a work-in-progress is dangerous. WGs should know > andy> that publishing an RFC with zero implementation experience for > the > andy> technology in the draft is going to produce an inferior result. > > I think that you intended to identify a tussle here, but maybe it was > rather subtle? > It is a delicate balance. Vendors are not supposed to complain when the draft changes and running code has to be rewritten. . > > On the one hand: work-in-progress can be dangerous to implement. > On the other hand: having no implementation feedback produces inferior > results. > > The discussion we are having here is how to enhance the stability of the > spec > in order to reduce cost/risk of early implementations, while at the same > time > allowing the WG to regret (and reverse) early decisions. > > I think that the flow I have suggested works: allocate at adoption time, > remove dead-wood at WGLC, and make renumbering a WGLC consideration. > > andy> Only the RFC versions of MIB or YANG modules is ever recorded by > IANA. > andy> The work-in-progress versions are extracted from drafts. > andy> The YangModels github repo stores these modules. > > Andy, should sid files be included in then along with YANG > modules? We don't say anything about that, I think. I hadn't thought > about this. > > > > Yes. They are code components Andy > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000052446e059c4b4a4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 16, 2020, 3:34 PM Michael Richardson <<= a href=3D"mailto:mcr%2Bietf@sandelman.ca">mcr+ietf@sandelman.ca> wro= te:

{Trying to answer several emails in this thread at once.}

Ivaylo wrote:
=C2=A0 =C2=A0 >> Thank you very much for the discussion. It brings a = lot of interesting
=C2=A0 =C2=A0 >> perspectives on the problem how to make sure SIDs ar= e most usable for
=C2=A0 =C2=A0 >> people and make it difficult to make mistakes.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I believe there are a few important points that need= to be agreed upon
=C2=A0 =C2=A0 >> before we accept how to fix anything. Here are my as= sumptions:

"Petrov's Three Laws of SID allocation":
[in the spirit of: https://en.wikiped= ia.org/wiki/Three_Laws_of_Robotics]

=C2=A0 =C2=A0 >> 1. we don't want to waste too much SIDs while cr= eating SID modules

I would have preferred if you hadn't made this the first point.

=C2=A0 =C2=A0 >> 2. we want SIDs to be as stable as possible
=C2=A0 =C2=A0 >> 3. we don't want to unpleasantly surprise people= with the way SIDs
=C2=A0 =C2=A0 >> need to be used as compared to only using YANG modul= es.

=C2=A0 =C2=A0 andy> YANG module development has proven to be a messy pro= cess.
=C2=A0 =C2=A0 andy> It is the exception, not the rule, that a module sta= ys stable from draft-00
=C2=A0 =C2=A0 andy> to RFC.

So, again, I advocate that at WGLC, that the WG consider if they wish to remove and/or renumber any SID values that have been allocated since WG Ado= ption.
(Of course, we might being doing a BIS document, so there is history before=


=
I agree with this plan.=C2=A0


I see Carsten's point about the sid-file-revision could lead to people = being
attached to particular lineages.=C2=A0 I don't think that is as likely;= but I'm
not going to die on this hill.=C2=A0 It's JSON, we could add it later i= f we needed
it, but it would be better to specify what it is.=C2=A0 I am happy with an = integer
that increments.=C2=A0 I think that the SID writer should probably insert i= t's
name, revision, the date it ran, who ran it, the phase of the moon, and the=
current cost of a .org domain, into the file if it changes anything.

=C2=A0 =C2=A0 >> My question is what happens currently with an implem= entation that uses
=C2=A0 =C2=A0 >> a version of YANG module that has been present insid= e a draft, but
=C2=A0 =C2=A0 >> have differences with the version in the final RFC t= hat is published
=C2=A0 =C2=A0 >> from the draft?

=C2=A0 =C2=A0 andy> The implementor is on their own, just like now for Y= ANG,
=C2=A0 =C2=A0 andy> and just like MIB modules for 30+ years.=C2=A0 Vendo= rs know that
=C2=A0 =C2=A0 andy> implementing a work-in-progress is dangerous.=C2=A0 = WGs should know
=C2=A0 =C2=A0 andy> that publishing an RFC with zero implementation expe= rience for the
=C2=A0 =C2=A0 andy> technology in the draft is going to produce an infer= ior result.

I think that you intended to identify a tussle here, but maybe it was rathe= r subtle?

It is a delicate balance.=C2=A0
Vendors ar= e not supposed to complain when the draft changes and running code has to b= e rewritten.=C2=A0=C2=A0
.

On the one hand: work-in-progress can be dangerous to implement.
On the other hand: having no implementation feedback produces inferior
=C2=A0 =C2=A0 =C2=A0 =C2=A0results.

The discussion we are having here is how to enhance the stability of the sp= ec
in order to reduce cost/risk of early implementations, while at the same ti= me
allowing the WG to regret (and reverse) early decisions.

I think that the flow I have suggested works: allocate at adoption time, remove dead-wood at WGLC, and make renumbering a WGLC consideration.

=C2=A0 =C2=A0 andy> Only the RFC versions of MIB or YANG modules is ever= recorded by IANA.
=C2=A0 =C2=A0 andy> The work-in-progress versions are extracted from dra= fts.
=C2=A0 =C2=A0 andy> The YangModels github repo stores these modules.

Andy, should sid files be included in <CODE BEGINS> then along with Y= ANG
modules?=C2=A0 We don't say anything about that, I think.=C2=A0 I hadn&= #39;t thought about this.


=C2=A0
Yes. They are code components=C2=A0

Andy


--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0mcr@sandelman.ca=C2=A0 http://www.sandelma= n.ca/=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2= =A0 [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Softwa= re Works
=C2=A0-=3D IPv6 IoT consulting =3D-



_______________________________________________
core mailing list
core@= ietf.org
https://www.ietf.org/mailman/listinfo/core<= br>
--00000000000052446e059c4b4a4b-- From nobody Sat Jan 18 21:37:10 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 4F594120059 for ; Sat, 18 Jan 2020 21:37:08 -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=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 Ig6O6Tj2VyWs for ; Sat, 18 Jan 2020 21:37:03 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 816F012004C for ; Sat, 18 Jan 2020 21:37:02 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id l18so21433148lfc.1 for ; Sat, 18 Jan 2020 21:37:02 -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=IaUXtPe34MDzoAdRkwo6oKv1w2aouieF+XgLrBhAc0g=; b=wPsLPMdVFxDP8bitTlhTgqwm14mtRtHS1Cnf3Q5oarGKl4AbNOuveQeaG+iIuKghjw mQAwhhn+OUaBJqnZI5wOyfNCKtut4xEZhmrEfAhteNfdQCAlaLsn0Y8l2YRQRbjsFNlw dpkrjZEUFXZ/5meBVyx9WpAyKEYDMN5y3QNI08O+1yBImhFhlA50DoaWDNarZ4kroYVc gYGqCmiysBloaCk3K2njM4MkgmpC5JWjNJhQWSpfcGzC1v0NYli4dHl6IH+vSfsc1m5g u/n/f7PsPsVUGxapuoc7z5ScQvyRyz1M8lO8budqqGOsvZ7GP9E8PO0tw2CL7ks/DgFG ygUg== 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=IaUXtPe34MDzoAdRkwo6oKv1w2aouieF+XgLrBhAc0g=; b=AToMn9UzkQfF1DXDa4+q2WgxdyXFs1wSW7sz2ONBl9a6QrHkViWleHaat4N53Rk255 RZuOiXjpaAUnfDbzMYAjqfydRddnRKZ95F4uwN3VRyZA3jOXC2r7lFbUsgstgnsHoaSD HR9583UTG8IjOwFdPFgubNJxwqgIdf5faiAHnuqqLgh63nmDA6kQkIDOK2UZW9vPhYBK 7kkcfbppGadFB4B9rPxx0H1oN3oodfOgrI4Ou37v/LSbuw/FqXAZLPUm7+pnVNNzIg3C f5VkoYhmWsWeNGc3PpTWqgTR+dnTFVg70Q7o4u2KUHcGT91H1vPTY+bfF7VQgbFVMIlH YH5g== X-Gm-Message-State: APjAAAXCk8DMaEfSTC0tz8MiXPWLxDn9tNql9xpyTBMkJlaeH1tvGEOB YufgYcXVts9U0tuKOlktlO9rAN6THXixbK0UXBTTwwvdajM= X-Google-Smtp-Source: APXvYqxQhgxYcKr6rgMXiZymHbEPEpBlUpydA6ncTj3o9V7cTjQuAVtIxOLRKzOWza7N0NPPKopTySulTi4+GfBXuGk= X-Received: by 2002:a19:48c5:: with SMTP id v188mr10059741lfa.100.1579412220638; Sat, 18 Jan 2020 21:37:00 -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: <5C3B4919-5513-4342-888D-998A11366D36@tzi.org> From: Andy Bierman Date: Sat, 18 Jan 2020 21:36:49 -0800 Message-ID: To: Carsten Bormann Cc: Ivaylo Petrov , Core , Alexander Pelov Content-Type: multipart/alternative; boundary="0000000000005d8c6f059c779058" 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: Sun, 19 Jan 2020 05:37:08 -0000 --0000000000005d8c6f059c779058 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 16, 2020 at 9:47 AM Carsten Bormann wrote: > On 2020-01-16, at 13:50, Andy Bierman wrote: > > > > There is a significant amount of metadata needed to generate a SID file= , > > starting with all the previous YANG revisions or SID files, and when/if > > the SID files have been reset vs. updated with preserved numbers. > > Well, specifically, the current YANG module and the previous SID file; no= t > 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 calls 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 this role. > But we need to define the process leading up to this. > (Yes, that process will evolve, and we probably also need to allow > exceptions. > But there must be strong guide rails that work for the vast majority 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 with > concurrent lineages; thinking that version numbers will fix any fallout. > 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 than 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 harder on the tool maker, such as no order dependencies, but is has some guardrails. No matter 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. 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 reasons: - no way to apply changes to an incorrect SID file (without a sid-file-identifier) - no way for vendors to apply deviations on any YANG modules, e,.g deviation { not-supported; } - the SID file generation depends on the specific revisions of all modules imported and submodules included by the target YANG module - vendors are already failing to deploy YANG modules from a central source model. The NETCONF and RESTCONF protocols have robust mechanisms to discover and retrieve the actual YANG files used by the server, and vendors 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) CORECONF (and SID in general) needs a SID file retrieval mechanism. Perhaps based on YANG Data Instance Files https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-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 point, or maybe use it unchanged - The SID files need support and probably some tool changes in the ID-submission process - IANA will only archive the RFC version, just like YANG modules. Gr=C3=BC=C3=9Fe, Carsten > Andy --0000000000005d8c6f059c779058 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 16, 2020 at 9:47 AM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
On 2020-01-16, a= t 13:50, Andy Bierman <andy@yumaworks.com> wrote:
>
> There is a significant amount of metadata needed to generate a SID fil= e,
> starting with all the previous YANG revisions or SID files, and when/i= f
> the SID files have been reset vs. updated with preserved numbers.

Well, specifically, the current YANG module and the previous SID file; not = the entire history of the universe.

The need for the previous SID file means that there needs to be a single li= neage; SID files cannot be independently progressed.=C2=A0 This calls for c= entral 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 this role.
But we need to define the process leading up to this.
(Yes, that process will evolve, and we probably also need to allow exceptio= ns.
But there must be strong guide rails that work for the vast majority of cas= es.)

Adding a version number to the SID file could indeed help with accidents/di= sasters.
But it could also lead to people thinking they can get away with concurrent= lineages; thinking that version numbers will fix any fallout.
That would be a disaster on its own, most likely leading to permanent unive= rse splits.
So I=E2=80=99m not so sure we want to open that Pandora=E2=80=99s box.



We already opened Pando= ra's box by attempting to create a 1-flat-number globally unique, multi= -module,
multi-owner object identifier. I think YANG is quite dif= ferent than the MAC address example of success
in this endeavour = because YANG modules need the numbers assigned in the development phase,
not the manufacturing=C2=A0phase.

YANG has= =C2=A0many features that make it easier on the writer and harder on the too= l maker,
such as no order dependencies, but is has some guardrail= s. No matter how the writer may
possibly alter or refactor a YANG= module, nothing unintentional can change the YANG identifier for
any defined data node.=C2=A0 SID has no such guardrails.

I think there is a practical solution for deployment, which does no= t require the use of the
centrally maintained SID files, which is= not realistic for 4 reasons:
=C2=A0 - no way to apply changes to= an incorrect SID file (without a sid-file-identifier)
=C2=A0= - no way for vendors to apply deviations on any YANG modules, e,.g deviati= on { not-supported; }
=C2=A0 - the SID file generation depen= ds on the specific revisions of all modules imported
=C2=A0 =C2= =A0 and submodules included by the target YANG module
=C2= =A0 - vendors are already failing to deploy YANG modules from a central sou= rce model.
=C2=A0 =C2=A0 The NETCONF and RESTCONF protocols have = robust mechanisms to discover and
=C2=A0 =C2=A0 retrieve the actu= al YANG files used by the server, and vendors rely on this feature.
=C2=A0 =C2=A0 Some vendors need model branching and other complexity tha= t make SID assignment even harder
=C2=A0 =C2=A0 (see=C2=A0= https://tools.ietf.org/html/draft-ietf-netmod-yang-versioning-reqs-02)<= /div>

CORECONF (and SID in general) needs a SID file ret= rieval mechanism.
A server will make the URI of this resource known= somehow, which can be used if needed,
before a client starts usi= ng SIDs.

In addition, or instead of listing YANG m= odules, 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 file= s 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:=
=C2=A0 - The WG or vendor can maintain an informal public archiv= e of SID files.
=C2=A0 - The YangModels repo update process shoul= d include SID files.=C2=A0=C2=A0https://github.com/YangModels/yang
=C2=A0 - Vendors still= need the public SID file for the starting point, or maybe use it unchanged=
=C2=A0 - The SID files need <CODE BEGINS> support and prob= ably=C2=A0some tool changes in the ID-submission process
=C2=A0 -= IANA will only archive the RFC version, just like YANG modules.
=


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


Andy
=C2=A0
--0000000000005d8c6f059c779058-- From nobody Mon Jan 20 01:37:07 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 9DEF2120091 for ; Mon, 20 Jan 2020 01:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=4yAx79k7; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=YLDrwYzV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFOuOyETt4a1 for ; Mon, 20 Jan 2020 01:36:59 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80057.outbound.protection.outlook.com [40.107.8.57]) (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 E2E21120077 for ; Mon, 20 Jan 2020 01:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YdeVI2RY8UI0qWjGsfW8iTNu0d9BplafvB+lg9+MBm8=; b=4yAx79k7txbb+zhbwAn+QXH13k7FzGiY2ZbV6YSdNy3UXgr3qNp/6ocuc5SlS1R8vmZ/oFLepbxTsNWmE1HACPEqxpcPad5/QaxsjtSIBH5SJwn0rXAKEWDeIDkyHRTOMpEKSGm5spCLgSihdbY/YE3dutve9ZwzvoJzQiYdt1c= Received: from AM6PR08CA0010.eurprd08.prod.outlook.com (2603:10a6:20b:b2::22) by VI1PR0801MB1679.eurprd08.prod.outlook.com (2603:10a6:800:59::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Mon, 20 Jan 2020 09:36:55 +0000 Received: from AM5EUR03FT030.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::204) by AM6PR08CA0010.outlook.office365.com (2603:10a6:20b:b2::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18 via Frontend Transport; Mon, 20 Jan 2020 09:36:54 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT030.mail.protection.outlook.com (10.152.16.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.23 via Frontend Transport; Mon, 20 Jan 2020 09:36:54 +0000 Received: ("Tessian outbound ca1df68f3668:v40"); Mon, 20 Jan 2020 09:36:54 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 629f392cf52d06e2 X-CR-MTA-TID: 64aa7808 Received: from 6aa6b8a58a90.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 73BD6D22-932D-45DF-9A25-8A5A77F67770.1; Mon, 20 Jan 2020 09:36:48 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 6aa6b8a58a90.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 20 Jan 2020 09:36:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a5ySKpcRbD2Yb85bewYbGIOTrkyKvbhUSb2ga769dRy+2WNqZVuBtc67WJM03U+QS5cAUlGCFoOKyf82AbJHQ8L2iY8u4dYyrUF91eOfEsXRlF8VGZRbithuws0dCIxpR01MXFEaZ3k+eWrQn2p+7ypmyuKPfz+1ILXlnVtni9ZbhXl82xhSdpNMAZb5iwQwlPCF4ZEZlSrdnZA/yHiPRl9slNHkpLWbPAIHRGYBeYcKbdn6nA9HKJ/DLUbPAUC9pbgpE90I5ZGXsr07Q8QcjceV6TsnO/+EyaqSmA6jFI4QfmQx3wrmGVL60RHYqeKqwWDZQ33OUZGt4+Qbl0Pxzw== 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=PP3Ong5WjL1XXfQj2FSQRgYR4MoXGsm/K50llkRHmgA=; b=g1NBDkW1jAvx0R40XUft89e8goZsv9WvlvkSYmfXyfo21fQgLbreJ/k3zTUcyyvl9K/i/eBK2uYxoc8W5XKY6q495AOmZTm4tYrC13h7sbUdNPjzK9Mnj3yq7e0lE5yzw8UD7+ZU0/gbjquAxD/qgZCxNsu9mUdM2X7lsYg9nVgjRag3ax2e0VzmegpRbacDXsT38/mhBXWiU4oL5CGavfQ7HueapajB0W32jZBBsLdUXyCW0uelBKOHX6jghyXr88NtehVjyttj4Q2u8ZYWQ+qG4knL8BgO4xT+BurEgNlYH0oIaV3YBxY7QQrcZuMQiqs1QKIQ9dJ3LPbK7UC0yA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PP3Ong5WjL1XXfQj2FSQRgYR4MoXGsm/K50llkRHmgA=; b=YLDrwYzVuGvDb+hq9pV5lxmM2ytp5JQinjaPf7gKA8x8n5Rl73aRDbrBKStSQcyiyHusrWXoF7nKGXLwkOyUy29XvEvjxPV3XloSeC7qKi5m+R0GxNXMTM5YgIZoSEFiKoz/wZ8rKn+YqlmSz0wN5Bzt8DfgyMFBcyDw/kb+w2k= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.18.151) by AM6PR08MB4325.eurprd08.prod.outlook.com (20.179.18.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.24; Mon, 20 Jan 2020 09:36:46 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9989:84d6:c203:2c63]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9989:84d6:c203:2c63%7]) with mapi id 15.20.2644.026; Mon, 20 Jan 2020 09:36:46 +0000 From: Thomas Fossati To: "core@ietf.org" Thread-Topic: Porting QUIC to constrained devices Thread-Index: AQHVz3UhzejS/hx4mkmYCkjL+0RCig== Date: Mon, 20 Jan 2020 09:36:46 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 37db608a-c8e6-4c45-3e9b-08d79d8c4910 X-MS-TrafficTypeDiagnostic: AM6PR08MB4325:|AM6PR08MB4325:|VI1PR0801MB1679: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:4502;OLM:9508; x-forefront-prvs: 0288CD37D9 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(396003)(376002)(346002)(199004)(189003)(26005)(186003)(86362001)(6506007)(36756003)(66446008)(66556008)(478600001)(64756008)(66476007)(76116006)(5660300002)(66946007)(91956017)(6916009)(71200400001)(2906002)(6486002)(4326008)(2616005)(8676002)(6512007)(33656002)(81166006)(316002)(4744005)(8936002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4325; H:AM6PR08MB4231.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: Gh4R2BRCLFqY/Xfnov1e/+SbXqjjqB/F/kq1W0CcIMcxaZt4/66zjpyQNMngRQ17zymhMcdiZIe0/eGR+suk0DoO0+eGXySF3GQp/3Mv2wuEr/icr3tYO227B1ZqY5zUitaAAU7FarVDgxZy7T044+lrOGMfn44ZIK8yvLfgFSfYgVgLKqxHubZYj8pj4j8qtd3A1u4gfmndao1jVRrWSfKLJVFE6Oal0ql4skFrIAYQOZx40OZKsxImh+3u0PH5grSJcXPcE37BlHKuCYX1BngFzuWePdbSV2Oeq49SfoBIv+ip1xv3YsL87S3A7wsUxwY6KT5y3hOgg9UwM3A8IXCgRtxxsdpkdra8jUAxKUViBQPYn/QHRdT+34AhAjP5mQQbTq+1UCckkSIwmt8SmlLR8A9TBqEtJEsu6vtcpZIkWVgzUd9Bmg+fD7ZoI5KEwvobPo0aeZL09C1M7wJwkzZvf6KjOsRo6e8Or9IMlAY9eFV4dkFrCMT2B1lVZQcVufF1uEUOAk96bTAV/zN3ww== Content-Type: text/plain; charset="utf-8" Content-ID: <78A296EF24BE164CAC8C41903E59D01E@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4325 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT030.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(376002)(39860400002)(199004)(189003)(8676002)(6916009)(316002)(81156014)(36906005)(186003)(336012)(70206006)(70586007)(4744005)(6506007)(356004)(6486002)(36756003)(5660300002)(26005)(8936002)(6512007)(4326008)(478600001)(26826003)(2616005)(2906002)(86362001)(33656002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1679; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: d4a83f4e-93f7-43c0-2525-08d79d8c4457 X-Forefront-PRVS: 0288CD37D9 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DXi1uZ13JFYi6ibmYlS1D1uCaA5VrgJZuDVMwE80IMkexvHs9v1da1JRo5w3Ye0LLEyiEMtX7fNdN2G1sRxewDGjwDslTnZxrSlbisPCV2cxaSIeaLZBSw4F9fGX0YQWVkTBujGCLhyQmYfAq/f7x6Qa5sApQ6hHnSpGZUQBLoDmiVOo7dJRt3HvLa1TeldNHHgTDxFk8r28oSkUgkqmDr6MMi2TlCLUGJbnO9Ro9xfObhNOh7jtQotqK+N3uIp+9ZkmXyp+os7uq+LdPsJKKxzpRcwJWi0cc21aFBLKrlSnuB//vQTAcWA0NCSy6xi4RX5LZsEVB7Db4Ky4vi2hQyr+dcX4k1BuSOR4l9t/68ADxqZBgEy/JfUxZhwg1PUU2a1uy6Nv2OuXfE1VnUj4JQnokSjwzISOyI6A5VP/PCIohX9ErRfeC+lg1JNH7sTZVZDRBfjgx4JgDyEXsFOJMlkWtjdPxSy32YzaHv4TUMsnbu+c0ZHFb40mckKA23Ym8E7+9FTstMH7C5utn++OmA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2020 09:36:54.2437 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 37db608a-c8e6-4c45-3e9b-08d79d8c4910 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1679 Archived-At: Subject: [core] Porting QUIC to constrained devices 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, 20 Jan 2020 09:37:05 -0000 RllJOiDvu79odHRwczovL2VnZ2VydC5vcmcvcGFwZXJzLzIwMjAtbmRzcy1xdWljLWlvdC5wZGYN Cg0KKFdvdWxkIGJlIGludGVyZXN0aW5nIHRvIHJlcGVhdCB0aGUgc2FtZSBleHBlcmltZW50cyB3 aXRoIENvQVAvRFRMUy4pDQoNCkNoZWVycyENCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRl bnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBk aXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkg cHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4g VGhhbmsgeW91Lg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2 aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUg b3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Tue Jan 21 01:36:15 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 D0F57120074 for ; Tue, 21 Jan 2020 01:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbuiPksT6ymC for ; Tue, 21 Jan 2020 01:36:08 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945D1120043 for ; Tue, 21 Jan 2020 01:36:08 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CCD9622027 for ; Tue, 21 Jan 2020 04:36:07 -0500 (EST) Received: from imap3 ([10.202.2.53]) by compute6.internal (MEProxy); Tue, 21 Jan 2020 04:36:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm1; bh=woR07LDE+pPgqgUA/FLZkA5+vrGLPzlQmFta6Hc6V ic=; b=kiyvvk2BfQjIGIYr3yPj+FWsccb3g7B0NYmS/eylxawvXKlhU6xbDxoG7 5jocpy4AquePZbBN7Qxyz3N1pBF+Cx4HoIj74cLxOvKv9lj8+KmnmfwVhRgyPPR9 jl7ALm1UFNiFTaheUVPEi6caQ2OQt9m3x8q+PnapBvxrveXYyGpkSrZ05EILRWED iQzW1VsjSx41Sn6mO2oM5A2M0M68uEcWqf6Ncm8VX/Y0CoFORFjcnUlutiDsxkWZ iMfnEYCUEmER1dVhlDfX8hBTlwVmUQZNep47ARmLftwaaRj/wKl+50ncoJplEzsT m46vCjyYMA3FVc/lGzG+KVK01WsZw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudekgddthecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedflfgrihhmvgculfhimhgvnhgviidfuceojhgrihhmvges ihhkihdrfhhiqeenucffohhmrghinhepfihikhhiphgvughirgdrohhrghdpihgvthhfrd horhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep jhgrihhmvgesihhkihdrfhhi X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3DC754E009F; Tue, 21 Jan 2020 04:36:07 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1 Mime-Version: 1.0 Message-Id: <5e82c3f0-aa71-460c-a646-9a86427d7f40@www.fastmail.com> In-Reply-To: <20200120161000.jxfsyeiffrvih62x@EMB-918HFH01> References: <20200120161000.jxfsyeiffrvih62x@EMB-918HFH01> Date: Tue, 21 Jan 2020 11:35:47 +0200 From: "Jaime Jimenez" To: core@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 21 Jan 2020 09:36:14 -0000 Sending it to the core thread.=20 --=20 Jaime Jim=C3=A9nez 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 o= ut > > > whether a unit encountered was actually of interest to it. > > > Discussion in the first session resulted in the tentative proposa= l > > > to mark secondary units with an asterisk (as in "*km/h", as oppos= ed > > > to unmarked "m/s"). Further discussion in the second session mad= e > > > 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, whic= h > > > 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 t= he > > > asterisks, but to include more explanatory text about implementat= ion > > > 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 w= ithout some backwards compatibility consideration that help theses deplo= yed 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 sid= e 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 abou= t > 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 unnecessaril= y,=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 th= e > wire in a senml record.=20 >=20 > >=20 >=20 > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > From nobody Tue Jan 21 02:48:08 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 4E6821200FE for ; Tue, 21 Jan 2020 02:48:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 L4889RdrCmAF for ; Tue, 21 Jan 2020 02:48:01 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 105AE120091 for ; Tue, 21 Jan 2020 02:48:00 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id t2so2640981wrr.1 for ; Tue, 21 Jan 2020 02:48:00 -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=qHLHuE77cUDEhC0hh4dGxD58uk5uqS13J5X4RlL5fGo=; b=uLZFfyytCU909tq86L5tyeaZQd/ZAabBQRLvuTo8mWYBR7nXNX3OmBqnzz+My2F2jG XxsspLcygqpJVLHEx9G0TVdoPTzsHQVaV8ky9aDXhPIWSnolgjpyVcoOl7s+hlDbGism rHSZXHpkWg0XNHwmJVMBYiyV2s9U9qyyQ1Taq59HJWYdI5YGK11+FoKP/Ih3RcOqukoI gj+0GxzsIwnmbFDETx9SbPSOQCdW98wWGow1NMld8tY5B6itQKTuUSwQhEFOJqAq8eN3 12Ge5IPyhgtOzPzs3srrbkVyU/7N71RvIvMs1Haegh0lyhIUDoBHIxN31pnDpd/C9s/Z xUWw== 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=qHLHuE77cUDEhC0hh4dGxD58uk5uqS13J5X4RlL5fGo=; b=C+z501k12O5vttsd3QWOPnFpSPjVN1j3wUDxrrqlI2uf7QVqUOkPFWAdUE0AnEXYL/ 7K5CJiunlhQ0O7OscAaUBGJgFhmF1ktSm5D7wYV5tEYwvwn1BXeolEMByJ4S5p+SUziT buWlv/qaCBhXBXUfAulhFcLzA94Ts/G0qC6JVNzuER9/vr+NIPhoAAgthbk/lTT3ID7D jTDhFXDL//k2ld6Epm1p3CHyCP3N1KA1IENG+9MkstVnbsMHpOlw6GrdhVuQoceqfONr QGehwpdP8fAXvkggq7H6W1KT6yU+mq44awRf9U9FCLyf6VBstWF9ME920kLllPgSGFUK 8o2A== X-Gm-Message-State: APjAAAUOOHGVRDJaY/qzJR4zF4/3JOavGILirgllS5+6ShNePKzNWDKL CdnYgeg3rS3eG3S7dSX1yVGC/Bg+JCf5oLYHwfJEOvnHHL/x7A== X-Google-Smtp-Source: APXvYqzDBjXpBnR2giImK8awBCqeGBPCG24lwyHZEiWSFcYIGLUXt76Wwt49pvpV/8clOcnEhFXBvLfiJnOyamlPBAE= X-Received: by 2002:adf:fe43:: with SMTP id m3mr4696762wrs.213.1579603679149; Tue, 21 Jan 2020 02:47:59 -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> <16867.1579217682@localhost> In-Reply-To: <16867.1579217682@localhost> From: Ivaylo Petrov Date: Tue, 21 Jan 2020 11:47:32 +0100 Message-ID: To: Michael Richardson Cc: Core Content-Type: text/plain; charset="UTF-8" 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: Tue, 21 Jan 2020 10:48:06 -0000 Hello Michael, See my answers below On Fri, Jan 17, 2020 at 12:34 AM Michael Richardson wrote: > > > {Trying to answer several emails in this thread at once.} > > Ivaylo wrote: > >> Thank you very much for the discussion. It brings a lot of interesting > >> perspectives on the problem how to make sure SIDs are most usable for > >> people and make it difficult to make mistakes. > >> > >> I believe there are a few important points that need to be agreed upon > >> before we accept how to fix anything. Here are my assumptions: > > "Petrov's Three Laws of SID allocation": > [in the spirit of: https://en.wikipedia.org/wiki/Three_Laws_of_Robotics] > > >> 1. we don't want to waste too much SIDs while creating SID modules > > I would have preferred if you hadn't made this the first point. It was unordered list, I just wanted to be able to refer to the different points. I should have made that clear. > > > >> 2. we want SIDs to be as stable as possible > >> 3. we don't want to unpleasantly surprise people with the way SIDs > >> need to be used as compared to only using YANG modules. > > andy> YANG module development has proven to be a messy process. > andy> It is the exception, not the rule, that a module stays stable from draft-00 > andy> to RFC. > > So, again, I advocate that at WGLC, that the WG consider if they wish to > remove and/or renumber any SID values that have been allocated since WG Adoption. > (Of course, we might being doing a BIS document, so there is history before) Sounds good to me. > > I see Carsten's point about the sid-file-revision could lead to people being > attached to particular lineages. I don't think that is as likely; but I'm > not going to die on this hill. It's JSON, we could add it later if we needed > it, but it would be better to specify what it is. I am happy with an integer > that increments. I think that the SID writer should probably insert it's > name, revision, the date it ran, who ran it, the phase of the moon, and the > current cost of a .org domain, into the file if it changes anything. The cost of .org domain could indeed be useful :) While I can surely agree that we should allow name, tool version and date to be inserted, I don't think this information should be mandatory. For some YANG modules it might be fine for people to write by hand the .sid files (although I don't think this is ever a good idea). > > >> My question is what happens currently with an implementation that uses > >> a version of YANG module that has been present inside a draft, but > >> have differences with the version in the final RFC that is published > >> from the draft? > > andy> The implementor is on their own, just like now for YANG, > andy> and just like MIB modules for 30+ years. Vendors know that > andy> implementing a work-in-progress is dangerous. WGs should know > andy> that publishing an RFC with zero implementation experience for the > andy> technology in the draft is going to produce an inferior result. > > I think that you intended to identify a tussle here, but maybe it was rather subtle? > > On the one hand: work-in-progress can be dangerous to implement. > On the other hand: having no implementation feedback produces inferior > results. > > The discussion we are having here is how to enhance the stability of the spec > in order to reduce cost/risk of early implementations, while at the same time > allowing the WG to regret (and reverse) early decisions. > > I think that the flow I have suggested works: allocate at adoption time, > remove dead-wood at WGLC, and make renumbering a WGLC consideration. > > andy> Only the RFC versions of MIB or YANG modules is ever recorded by IANA. > andy> The work-in-progress versions are extracted from drafts. > andy> The YangModels github repo stores these modules. > > Andy, should sid files be included in then along with YANG > modules? We don't say anything about that, I think. I hadn't thought about this. I agree with that. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Best regards, Ivaylo From nobody Tue Jan 21 02:56:03 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 2AE1212009C for ; Tue, 21 Jan 2020 02:56:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 3MKGDzbIeABH for ; Tue, 21 Jan 2020 02:55:55 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 6D146120091 for ; Tue, 21 Jan 2020 02:55:55 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id d16so2604579wre.10 for ; Tue, 21 Jan 2020 02:55:55 -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:content-transfer-encoding; bh=+drO+atttVsda9FLYzYUSo0iJzUZPk3eR/LOS1idOBY=; b=PUPBMDxxKCzX1WK14tJ/cwYuOaTzDzXntZ/e5j8FRgvHLkCB94y+zdWzOLtoxx7BiA 1IuX6XZTPr+ydbEenD6odFeQ5cJeP4oIxqU/i1/nM6XjpUcF6SGkP53T1ZE9TERzqhY/ KxQDrMDm4ko2U77WhS9ObZfHkF4fnVzVMYboz+65F79VWQSvWQ9dUzl/lnLleQC3E/bE CObeRTd5W2WAlZROFH0pnihtPo2TAvqRG/4voRZTxlQoFRdU9C6m1R5avBMVka7ntA7e GflYfqTPFk0VOE0J3uQzbfQqNH9aKOY8Idjg/S+8mUe1CqC/zj+Zt1cbD6tqxHk+d02M glGA== 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:content-transfer-encoding; bh=+drO+atttVsda9FLYzYUSo0iJzUZPk3eR/LOS1idOBY=; b=ej79MuEavM9Ojx1Q9MyXfzlJeVlghQjQwy9ELC5JlTTkiRSMx4/hqBfT9p47qzf0FD pDWDkcCi1peFo7XKHUZGGHiVCAJwP/pRqvr26kAzhGa3we7lK4N3slQXrwwcA6BY2eKb WsBbG7ip0qiOGUCsyQ9zBWV2A4pjHtZd6yOn7Vq2TRSt302kdeWgDiqBAuj07HETQETp kKIXQ74syX/n2nzjArs9XZO0QJkrrueuL0UjrATC/YtQr3+5yc8oFt9sCjvEAvUVIVOF Esvw2Y20C/zh0W6ZfNp8F7SeEmnWRoYH+XWRSSiifRwXL510xZiN69hXpOYjC+H0DLyV SVBg== X-Gm-Message-State: APjAAAXIazCFptNDky6nc/ePzg1MNTvjaFpI5aGfgXB7+QCPJt91mOvm FGAqIlORmMtAbS2yRMUeWc1vyPFBQ+KWLJJj7TetUw/Phh6C9A== X-Google-Smtp-Source: APXvYqyRWNZXRxwB8I500u3tXVd/R1RMIEDGopYOd4CsDWDHQVYsMrKrct1TieHmEOInRlDu746dO0YclHe1LNbPuw0= X-Received: by 2002:adf:fe43:: with SMTP id m3mr4730612wrs.213.1579604153779; Tue, 21 Jan 2020 02:55:53 -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: Tue, 21 Jan 2020 11:55:27 +0100 Message-ID: To: Andy Bierman Cc: Carsten Bormann , Core , Alexander Pelov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Tue, 21 Jan 2020 10:56:01 -0000 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 wrote: >> >> On 2020-01-16, at 13:50, Andy Bierman wrote: >> > >> > There is a significant amount of metadata needed to generate a SID fil= e, >> > starting with all the previous YANG revisions or SID files, and when/i= f >> > the SID files have been reset vs. updated with preserved numbers. >> >> Well, specifically, the current YANG module and the previous SID file; n= ot 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 calls for cen= tral 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 this role. >> But we need to define the process leading up to this. >> (Yes, that process will evolve, and we probably also need to allow excep= tions. >> But there must be strong guide rails that work for the vast majority 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 with concurr= ent lineages; thinking that version numbers will fix any fallout. >> That would be a disaster on its own, most likely leading to permanent un= iverse 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 g= lobally unique, multi-module, > multi-owner object identifier. I think YANG is quite different than the M= AC address example of success > in this endeavour because YANG modules need the numbers assigned in the d= evelopment phase, > not the manufacturing phase. > > YANG has many features that make it easier on the writer and harder on th= e tool maker, > such as no order dependencies, but is has some guardrails. No matter how = the writer may > possibly alter or refactor a YANG module, nothing unintentional can chang= e 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 changing the YANG identifiers and the paths will cause changes to the .sid file. Could y= ou 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 otherwise I believe the NETCONF representation will also change, so CORECONF will be no different. > > I think there is a practical solution for deployment, which does not requ= ire the use of the > centrally maintained SID files, which is not realistic for 4 reasons: > - 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 version 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 Michael 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 versions for= one version of a YANG module, errors could be corrected. Does this sound good to you? > - no way for vendors to apply deviations on any YANG modules, e,.g devi= ation { 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 modu= les 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 RFC60= 20 ` modules need to be imported using specific revisions`. Could you provide more details of the issue you see? > - vendors are already failing to deploy YANG modules from a central sou= rce model. > The NETCONF and RESTCONF protocols have robust mechanisms to discover= and > retrieve the actual YANG files used by the server, and vendors rely o= n 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-re= qs-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 to obtain further details. Presently we believed as there are not going to be too many mega range 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 them. Specifying such a protocol might be something we do if this is a really big concern for peopl= e. Would that retrieval mechanism cover the cases that you were thinking of? Are there other cases that you believe it should cover? > CORECONF (and SID in general) needs a SID file retrieval mechanism. > Perhaps based on YANG Data Instance Files https://tools.ietf.org/html/dra= ft-ietf-netmod-yang-instance-file-format-06 > A server will make the URI of this resource known somehow, which can be u= sed if needed, > before a client starts using SIDs. > > In addition, or instead of listing YANG modules, the data is SID files, m= aybe 1 super-SID-file JSON object. > It is not realistic that a client will be able to use all global SID file= s 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 point, or may= be use it unchanged > - The SID files need support and probably some tool chang= es in the ID-submission process > - IANA will only archive the RFC version, just like YANG modules. > > > >> Gr=C3=BC=C3=9Fe, Carsten > > > > Andy > -- Best regards, Ivaylo From nobody Tue Jan 21 11:29:19 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 4619312003F for ; Tue, 21 Jan 2020 11:29:18 -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=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 rixiTsgqKhdU for ; Tue, 21 Jan 2020 11:29:14 -0800 (PST) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 779E912001B for ; Tue, 21 Jan 2020 11:29:14 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id i16so4203150edr.5 for ; Tue, 21 Jan 2020 11:29:14 -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=2MSmYs6ircSubKcj3JmKWmbJmWL9qpvMcYQiSakBt0c=; b=1LfE5XYvu12D8orfB1LfPA2b4YqrAjCMsDYrESLB+pD5QgESIWal2284YYvy1Y8XVv i9/PSSzvCXfoNLABG5aNmvfWlGN57V+aw0p60ubU2g6YKkNIjcmyWkxL/K4pTagBf5tk EmPIgJhSh3NsbvO4ATxPVhhFEnhTP/2K/4m7JPSM/n6p1q2d3E/iAxJ/WiqPMAik0aUT MoGP4TD3ZkfcDNZAIwckqpwiK0GMSFk9RuCMMLCVCJ/GPQ63WAkBROL/GpXj98Ekn2x0 0ZDE71/7jKCH6/0X2/eGmGwxIdmNHv0saBMdGYRmykvSol/yrFf2T326+v1pwK88EOD2 Y5UQ== 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=2MSmYs6ircSubKcj3JmKWmbJmWL9qpvMcYQiSakBt0c=; b=D5BovdzRY4PBZSR8hv0V4VM2GzT7Mlgjc85uSQmEhqkbGY3ofzSsoRW1zTVSe6Qo/A TI3u9hKVzLy+EC8YYMZ2crNhlDKUx5x6FpDIcdKHW/WFC1S6w39pgsURuqokrM6nQSpg oAWiCzBrhbbCOeVnEWedtbSSfsCkg7HiAB3Ep/lVSEpIezbkaHQDEjSxHdahLC/RMK/D ZsqRJa35+vlmZ6evbhtLRiGAjo1iqAgaFUV5kTU/3GppbpRul/uTcjs/7RxwM6A1wCNd 7GztbpgJoANAWq/koMXoiDF+JXogLebQ1lPrJjtgCydrR4AqVg5GUTIFj53jbhTtUTc/ D8Aw== X-Gm-Message-State: APjAAAUSINs7ok7DiBJBBuYk59i4M4eSByNqh2oG3RCj1Rz+/HXV7aLq V8v+NSawe9yahM9SiTBDWsbpOIa3XsdY/WAz5hp+rA8A X-Google-Smtp-Source: APXvYqwjCuyZPSbs8ofXukieL3Tt7acMpQeklvlCokC2MIdGUwzx5NsJSAWAXWnQfpqDh1EOHT+VbBxj+32D9yK43DE= X-Received: by 2002:a05:6512:15d:: with SMTP id m29mr3666962lfo.51.1579634952270; Tue, 21 Jan 2020 11:29:12 -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: Andy Bierman Date: Tue, 21 Jan 2020 11:29:00 -0800 Message-ID: To: Ivaylo Petrov Cc: Carsten Bormann , Core , Alexander Pelov Content-Type: multipart/alternative; boundary="000000000000348d80059cab6cb4" 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: Tue, 21 Jan 2020 19:29:18 -0000 --000000000000348d80059cab6cb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 21, 2020 at 2:55 AM Ivaylo Petrov wrote: > 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 wrote: > >> > >> On 2020-01-16, at 13:50, Andy Bierman wrote: > >> > > >> > There is a significant amount of metadata needed to generate a SID > file, > >> > starting with all the previous YANG revisions or SID files, and > when/if > >> > the SID files have been reset vs. updated with preserved numbers. > >> > >> Well, specifically, the current YANG module and the previous SID 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 calls > 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 this role. > >> But we need to define the process leading up to this. > >> (Yes, that process will evolve, and we probably also need to allow > exceptions. > >> But there must be strong guide rails that work for the vast majority o= f > 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 with > concurrent lineages; thinking that version numbers will fix any fallout. > >> 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 than 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 harder on > the tool maker, > > such as no order dependencies, but is has some guardrails. No matter ho= w > 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 changing t= he > 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 otherwise 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 update" 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, especially since YANG tools have no existing reason to be careful in these areas. > > > > 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 reasons: > > - 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 version > 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 Michael > 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 versions > for one > version of a YANG module, errors could be corrected. Does this sound > 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 in 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 after 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 change. All of the unspecified revisions imported by module foo determine the 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. > > > - 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`. > 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 central > source model. > > The NETCONF and RESTCONF protocols have robust mechanisms to > discover and > > retrieve the actual YANG files used by the server, and vendors rely > on this feature. > > Some vendors need model branching and other complexity that make SI= D > 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 to > obtain further details. > > No. I am interested in loading the SID data from each individual server, as needed. I understand some people want to hard-wire SIDs into their client or server and they will not have the YANG identifiers. I am not interested in 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. > Presently we believed as there are not going to be too many mega range > 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 them. > 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 thinking > 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 deployment scenarios. This could be considered a protocol issue and can be ignored for SID 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. > > > CORECONF (and SID in general) needs a SID file retrieval mechanism. > > Perhaps based on YANG Data Instance Files > https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-0= 6 > > 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 point, or > maybe use it unchanged > > - The SID files need support and probably some tool > changes in the ID-submission process > > - IANA will only archive the RFC version, just like YANG modules. > > > > > > > >> Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > Andy > > > > -- > Best regards, > Ivaylo > Andy --000000000000348d80059cab6cb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 21, 2020 at 2:55 AM Ivayl= o Petrov <ivaylo@ackl.io> wrote= :
Hello Andy,
Find my answers below

On Sun, Jan 19, 2020 at 6:37 AM Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Thu, Jan 16, 2020 at 9:47 AM Carsten Bormann <cabo@tzi.org> wrote:
>>
>> On 2020-01-16, at 13:50, Andy Bierman <andy@yumaworks.com> wrote:
>> >
>> > 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 SID f= ile; 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.=C2=A0 This ca= lls 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 this r= ole.
>> But we need to define the process leading up to this.
>> (Yes, that process will evolve, and we probably also need to allow= exceptions.
>> But there must be strong guide rails that work for the vast majori= ty of cases.)
>>
>> Adding a version number to the SID file could indeed help with acc= idents/disasters.
>> But it could also lead to people thinking they can get away with c= oncurrent lineages; thinking that version numbers will fix any fallout.
>> That would be a disaster on its own, most likely leading to perman= ent 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-n= umber globally unique, multi-module,
> multi-owner object identifier. I think YANG is quite different than th= e MAC address example of success
> in this endeavour because YANG modules need the numbers assigned in th= e development phase,
> not the manufacturing phase.
>
> YANG has many features that make it easier on the writer and harder on= the tool maker,
> such as no order dependencies, but is has some guardrails. No matter h= ow the writer may
> possibly alter or refactor a YANG module, nothing unintentional can ch= ange the YANG identifier for
> any defined data node.=C2=A0 SID has no such guardrails.

[ivaylo]:
It seems that you are implying that refactoring a YANG without changing the=
YANG identifiers and the paths will cause changes to the .sid file. Could y= ou
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 otherwise I
believe the
NETCONF representation will also change, so CORECONF will be no different.<= br>


YANG modules under deve= lopment do not follow any of the "module update" 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, espe= cially
since YANG tools have no existing reason to be careful in = these areas.

=C2=A0
>
> I think there is a practical solution for deployment, which does not r= equire the use of the
> centrally maintained SID files, which is not realistic for 4 reasons:<= br> >=C2=A0 =C2=A0- no way to apply changes to an incorrect SID file (withou= t a sid-file-identifier)

[ivaylo]:
I believe currently the way to achieve this is to have a new version
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 Michael
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 versions for= one
version of a YANG module, errors could be corrected. Does this sound
good to you?


This will n= ot 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 in 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 after releas= e 1

=C2=A0 =C2=A0module foo {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 import A { pref= ix a; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 revision 2019-01-01;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 container top {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses a:grouping1;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0}
=C2=A0 }

The SID f= ile contents for /top are not determined by module foo.
Over time= , module A will keep changing and module foo will never change.
A= ll of the unspecified revisions imported by module foo determine the expans= ion of 'grouping1.
This approach only works within a server i= mplementation because all the module revisions
are known to the c= lient via the YANG library.


=C2=A0<= br>

>=C2=A0 =C2=A0- no way for vendors to apply deviations on any YANG modul= es, 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.

>=C2=A0 =C2=A0- the SID file generation depends on the specific revision= s of all modules imported
>=C2=A0 =C2=A0 =C2=A0and submodules included by the target YANG module
[ivaylo]:
I agree, but I believe this is a good thing.=C2=A0 As is said sec 5.1.1 of = RFC6020

` modules need to be imported using specific revisions`.


This is not how YANG is used 95% of the ti= me.
Even if I import-by-revision, it is very common for that modu= le to
have its own imports, and I have no control over the revisi= ons used there.

=C2=A0

Could you provide more details of the issue you see?

>=C2=A0 =C2=A0- vendors are already failing to deploy YANG modules from = a central source model.
>=C2=A0 =C2=A0 =C2=A0The NETCONF and RESTCONF protocols have robust mech= anisms to discover and
>=C2=A0 =C2=A0 =C2=A0retrieve the actual YANG files used by the server, = and vendors rely on this feature.
>=C2=A0 =C2=A0 =C2=A0Some vendors need model branching and other complex= ity that make SID assignment even harder
>=C2=A0 =C2=A0 =C2=A0(see ht= tps://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 to
obtain further details.



No. I am interested in = loading the SID data from each individual server, as needed.

=
I understand some people want to hard-wire SIDs into their clien= t or server
and they will not have the YANG identifiers.=C2=A0 I = am not interested in 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 module= s.

=C2=A0
Presently we believed as there are not going to be too many mega range
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 them.
Specifying such a
protocol might be something we do if this is a really big concern for peopl= e.
Would that retrieval mechanism cover the cases that you were thinking
of? Are there other
cases that you believe it should cover?


I think vendors will continue to fill in the gaps with prop= rietary mechanisms.
The SID file format will get augmented, etc. = to support real deployment scenarios.
This could be considered a = protocol issue and can be ignored for SID files in general.

<= /div>
How the client gets the YANG and SID files could be considered an= implementation detail.
The IANA repo is there but there is no re= quirement to use it.

=C2=A0

> CORECONF (and SID in general) needs a SID file retrieval mechanism. > Perhaps based on YANG Data Instance Files https://tools.ietf.org/html/draft-ietf-netmod-yang-ins= tance-file-format-06
> A server will make the URI of this resource known somehow, which can b= e 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 f= iles based on the YANG module name
> and revision date, especially in the development phase. The IANA SID f= ile may be useful after the YANG
> module is very stable.
>
> More solution details:
>=C2=A0 =C2=A0- The WG or vendor can maintain an informal public archive= of SID files.
>=C2=A0 =C2=A0- The YangModels repo update process should include SID fi= les.=C2=A0 https://github.com/YangModels/yang
>=C2=A0 =C2=A0- Vendors still need the public SID file for the starting = point, or maybe use it unchanged
>=C2=A0 =C2=A0- The SID files need <CODE BEGINS> support and proba= bly some tool changes in the ID-submission process
>=C2=A0 =C2=A0- IANA will only archive the RFC version, just like YANG m= odules.
>
>
>
>> Gr=C3=BC=C3=9Fe, Carsten
>
>
>
> Andy
>

--
Best regards,
Ivaylo


Andy
= =C2=A0
--000000000000348d80059cab6cb4-- From nobody Wed Jan 22 03:44: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 49E8412009C for ; Wed, 22 Jan 2020 03:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 XvmkRBsn2-Uj for ; Wed, 22 Jan 2020 03:44:47 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 E4A54120089 for ; Wed, 22 Jan 2020 03:44:46 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id g17so6941280wro.2 for ; Wed, 22 Jan 2020 03:44:46 -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:content-transfer-encoding; bh=OK4ASVK1CFzEct4kotQ2HI+H1DM/6dOAHz1TM8xzq6c=; b=y+/c8Rt1gWUQPskDysOThKXO3SdtZZ9Ovo2bZWzs+6CVFL84Gh/O9/0Z+hA7ooK6Wk ZUeKZ4vvgeLiYnVaWVU4UUQ29CT36LyZgGgC/RoWvuqxqEfPQsTsTn+hJrYIslvrDfr7 Urxp8xs9Zmo69rDUPm7loipKsldZ3QK5nuT2EVQrnHN8fyb+AQyvwdWWgy3seRo7U09Z srLPg0BfKFC9bMuEcMoYheBPiI+lqMMDtGHVU/PD2QuwWH/K1dWMhWz7qtnXuaqf3D/f Ro0tmwNymtEZKL8mhu02E7gehmutdXnNsisCGJ64B+MNwSwWMVZjcEGfVfkDzQ+PGAFi ocuw== 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:content-transfer-encoding; bh=OK4ASVK1CFzEct4kotQ2HI+H1DM/6dOAHz1TM8xzq6c=; b=eyItDDGdjPVLTgvyf4pL+s/X8MHghDXjcMqyRGJjkvXFJXYxo3EsPXZYZgyznropN4 CwaUIP5bUHKzHdHk4CONXOIZ1Hpt+0gmVNOlt3QdgRKCX9zOK9Lv4UJaih16+AA+krM/ AVjy6qiD2MnkOuXAN7mfcYr3tQ2xw9zO+XxEcZjgNPZXrZHwMTEF1Hc7mOFeSqJe7sj+ EoAY4397/KYbyyrmAjUHEOm3/0TJG7IHgEiVvp8wGY+iH6kQvXy8WM3AugMNZ9a54g5K dZuLLTT3yzl/Tgcropb4UVlPDxno19gAmCLXN3Ou9Wr6cgD8AGlwxNwQHdO/QnPP+z/I FotQ== X-Gm-Message-State: APjAAAWZTZzpcz5Kgs7+Hy6W7kRiXkw/zX/YxFkMr3p5uZoL5Kspddp1 CrqE+lCC9tOB87pEWIcEjzPRZIRBoSMkK1nEwsDXyw== X-Google-Smtp-Source: APXvYqyEJsFaVKx73cnJeU61zvvP1a6oxFjyHbQ2mC3TIZusVirk9zCg/o7NUQ3bM/jd3Ds8PLb5myALA8R8txFWCJM= X-Received: by 2002:adf:f88c:: with SMTP id u12mr10179593wrp.323.1579693485127; Wed, 22 Jan 2020 03:44:45 -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, 22 Jan 2020 12:44:18 +0100 Message-ID: To: Andy Bierman Cc: Carsten Bormann , Core , Alexander Pelov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 22 Jan 2020 11:44:50 -0000 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 wrote: > > > > On Tue, Jan 21, 2020 at 2:55 AM Ivaylo Petrov wrote: >> >> 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 wrote: >> >> >> >> On 2020-01-16, at 13:50, Andy Bierman wrote: >> >> > >> >> > There is a significant amount of metadata needed to generate a SID = file, >> >> > starting with all the previous YANG revisions or SID files, and whe= n/if >> >> > the SID files have been reset vs. updated with preserved numbers. >> >> >> >> Well, specifically, the current YANG module and the previous SID file= ; not the entire history of the universe. >> >> >> >> The need for the previous SID file means that there needs to be a sin= gle lineage; SID files cannot be independently progressed. This calls 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 this role= . >> >> But we need to define the process leading up to this. >> >> (Yes, that process will evolve, and we probably also need to allow ex= ceptions. >> >> But there must be strong guide rails that work for the vast majority = of cases.) >> >> >> >> Adding a version number to the SID file could indeed help with accide= nts/disasters. >> >> But it could also lead to people thinking they can get away with conc= urrent lineages; thinking that version numbers will fix any fallout. >> >> 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-numbe= r globally unique, multi-module, >> > multi-owner object identifier. I think YANG is quite different than th= e MAC address example of success >> > in this endeavour because YANG modules need the numbers assigned in th= e development phase, >> > not the manufacturing phase. >> > >> > YANG has many features that make it easier on the writer and harder on= the tool maker, >> > such as no order dependencies, but is has some guardrails. No matter h= ow the writer may >> > possibly alter or refactor a YANG module, nothing unintentional can ch= ange 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 changing = the >> YANG identifiers and the paths will cause changes to the .sid file. Coul= d 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 otherwise I >> believe the >> NETCONF representation will also change, so CORECONF will be no differen= t. >> > > > YANG modules under development do not follow any of the "module update" r= ules > so there are no restrictions that can be relied on in real YANG developme= nt. > This requires the tools and developers to be more careful, especially > since YANG tools have no existing reason to be careful in these areas. > [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 and I don't see how we can provide anything better. > >> >> > >> > I think there is a practical solution for deployment, which does not r= equire the use of the >> > centrally maintained SID files, which is not realistic for 4 reasons: >> > - no way to apply changes to an incorrect SID file (without a sid-fi= le-identifier) >> >> [ivaylo]: >> I believe currently the way to achieve this is to have a new version >> 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 Michael >> 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 versions = for one >> version of a YANG module, errors could be corrected. Does this sound >> 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 in 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 after re= lease 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 change. > All of the unspecified revisions imported by module foo determine the exp= ansion of 'grouping1. > This approach only works within a server implementation because all the m= odule revisions > are known to the client via the YANG library. > [ivaylo] I think the difference of viewpoints here came from my assumption that 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 we might need to add information in the SID file about what version of each 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 appears 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 problem 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 the constrained device. It seems that your preference, Andy, is to go with the first one and have SIDs be more contextually dependent. > > >> >> >> > - no way for vendors to apply deviations on any YANG modules, e,.g d= eviation { 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 m= odules 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 RF= C6020 >> >> ` modules need to be imported using specific revisions`. > > > > 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 central = source model. >> > The NETCONF and RESTCONF protocols have robust mechanisms to disco= ver and >> > retrieve the actual YANG files used by the server, and vendors rel= y on this feature. >> > Some vendors need model branching and other complexity that make S= ID 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 to >> obtain further details. >> > > > No. I am interested in loading the SID data from each individual server, = as needed. > > I understand some people want to hard-wire SIDs into their client or serv= er > and they will not have the YANG identifiers. I am not interested in this > deployment option for YANG-Push so the SID values will get added at runti= me. > The client will consume or use cached the SID files at session-startup-ti= me, 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 file is present for each server, wouldn't the mechanism from draft-ietf-core-yang-library solve that? Or maybe you would like to have a more compact reply that gives only the YANG module name, version and version the SID file that can be found on a server - be it internal or external one. If that is the need you have, we can see which is the best approach to resolve it. > > >> >> Presently we believed as there are not going to be too many mega range >> 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 them. >> Specifying such a >> protocol might be something we do if this is a really big concern for pe= ople. >> Would that retrieval mechanism cover the cases that you were thinking >> of? Are there other >> cases that you believe it should cover? > > > > I think vendors will continue to fill in the gaps with proprietary mechan= isms. > The SID file format will get augmented, etc. to support real deployment s= cenarios. > This could be considered a protocol issue and can be ignored for SID file= s in general. > > How the client gets the YANG and SID files could be considered an impleme= ntation 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 the 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 assume that the server or a proxy in between will be able to understand their 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, which 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 will still be able to use the same introspection protocol as before and find the YANG modules looking at the SID file. > >> >> >> > CORECONF (and SID in general) needs a SID file retrieval mechanism. >> > Perhaps based on YANG Data Instance Files https://tools.ietf.org/html/= draft-ietf-netmod-yang-instance-file-format-06 >> > A server will make the URI of this resource known somehow, which can b= e 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 f= iles based on the YANG module name >> > and revision date, especially in the development phase. The IANA SID f= ile 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 fi= les. >> > - The YangModels repo update process should include SID files. http= s://github.com/YangModels/yang >> > - Vendors still need the public SID file for the starting point, or = maybe use it unchanged >> > - The SID files need support and probably some tool ch= anges in the ID-submission process >> > - IANA will only archive the RFC version, just like YANG modules. >> > >> > >> > >> >> Gr=C3=BC=C3=9Fe, Carsten >> > >> > >> > >> > Andy >> > >> >> -- >> Best regards, >> Ivaylo > > > > Andy > -- Best regards, Ivaylo From nobody Wed Jan 22 09:53:09 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 75C4412087B for ; Wed, 22 Jan 2020 09:53:04 -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, 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] 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 GCo3G3--hUtb for ; Wed, 22 Jan 2020 09:53:00 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92AB4120846 for ; Wed, 22 Jan 2020 09:52:57 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id y4so7827805ljj.9 for ; Wed, 22 Jan 2020 09:52:57 -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=VhRWC7q26mjZhFQZl56igTvukg5Jlo6931RhD317O7E=; b=h9EmpPnhbo+c2ol0cBzl+kz024OSi09CBRnWmiIED8WnWo9Wr1p37akc8/jukzSfTq bmbIBaJyNX5iJOt1Nax5aRyscJ2zqBkMZc1VF7MjI9Dfn9HXJBLo7tlo72SqS9NBT4Y9 ZqgZ8gXSlB9iUOjP/j1OEgDRaOGzD+eUWg99WTjrm+7uzA6BdX20jmCmGEv9H7CySl+T MEW4a9epDoM9BR+Bi8IZQgooqL/jb4chCnU84ybdwlx+4daOFbEtK+IEGaFu0llM+jqu k+tGoCAttNUX1sV/rg9D7roV11xLZRWDG+4Q7AOVV5TTHg03nWRTMFcMT8Q/XiRIcvLv uHtw== 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=VhRWC7q26mjZhFQZl56igTvukg5Jlo6931RhD317O7E=; b=mahboLU0xG1YakGjYyADSpmFNcdNHbBcXfKBoaDg2W/6OAq5mG1R7neoAdJrd5PhQ0 1Mf1xKQw+iND/O96gsUMduXgR5xQrxNp3XJnaJ+XNPXVnw9UJU7yBeO+/X3xQ5Zqr5NY n9NlpxAppJM12kVU0zHzABpCLCn8XkolG/HiqL5S8tWxIdMzO0CUeajVCiNNrVNQ/Xiq YavWnhqdv8gCwcPWIsfdSNdy6TWCUFrWRa7UhC8ZP3HuqFFemFOe7RMwbMmSIIArtCjM TLQ4L9VEHv2qxMS0QxbsmdgDNeHS6X1KPOy/QrM/EdCj//LdwG2Hf8JlBnVeszKTQD1V 8IRA== X-Gm-Message-State: APjAAAWF7SugsRLOniLctnNIOV6hIH6PbmvaGaumO/Exsj7HG9wkSu22 9rC0482rBvSNb+jeBzIPKTOCSFbSmppp3PrBC6hxSQRJ X-Google-Smtp-Source: APXvYqxnvbvo7uAXudPjmWCspNdTVyOIh7i6KbyTmjmmzwpT8rOcEydWsm4W+SUM1EybDbj1eGvMfy16zZFGvcvxM5g= X-Received: by 2002:a2e:844e:: with SMTP id u14mr20284462ljh.183.1579715575734; Wed, 22 Jan 2020 09:52:55 -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: Andy Bierman Date: Wed, 22 Jan 2020 09:52:43 -0800 Message-ID: To: Ivaylo Petrov Cc: Carsten Bormann , Core , Alexander Pelov Content-Type: multipart/alternative; boundary="000000000000bcf106059cbe31e6" 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, 22 Jan 2020 17:53:08 -0000 --000000000000bcf106059cbe31e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > > > > > > > > On Tue, Jan 21, 2020 at 2:55 AM Ivaylo Petrov wrote: > >> > >> 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 wrote= : > >> >> > >> >> On 2020-01-16, at 13:50, Andy Bierman wrote: > >> >> > > >> >> > There is a significant amount of metadata needed to generate a SI= D > file, > >> >> > starting with all the previous YANG revisions or SID files, and > when/if > >> >> > the SID files have been reset vs. updated with preserved numbers. > >> >> > >> >> Well, specifically, the current YANG module and the previous SID > 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 calls > 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 this > role. > >> >> But we need to define the process leading up to this. > >> >> (Yes, that process will evolve, and we probably also need to allow > exceptions. > >> >> But there must be strong guide rails that work for the vast majorit= y > 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 with > concurrent lineages; thinking that version numbers will fix any fallout. > >> >> 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 b= ox. > >> >> > >> > > >> > > >> > 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 than > 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 harder > on the tool maker, > >> > such as no order dependencies, but is has some guardrails. No matter > 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 changin= g > 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 cas= e. > >> Note that I added the restriction of not changing paths as otherwise 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 update" > 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, especially > > since YANG tools have no existing reason to be careful in these areas. > > > > [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 and > 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 get 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 they 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. > > > >> > >> > > >> > 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 reasons= : > >> > - 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 version > >> 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 Michael > >> 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 version= s > for one > >> version of a YANG module, errors could be corrected. Does this sound > >> 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 in 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 after > 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 change= . > > All of the unspecified revisions imported by module foo determine the > 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 that > 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 we > might need to add information in the SID file about what version of each > 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 appears > 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 problem > 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 the > constrained device. It seems that your preference, Andy, is to go with > 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 point 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. > > > > > >> > >> > >> > - 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 mostly 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. > > > > > > 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 centra= l > source model. > >> > The NETCONF and RESTCONF protocols have robust mechanisms to > discover and > >> > retrieve the actual YANG files used by the server, and vendors > 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 to > >> obtain further details. > >> > > > > > > No. I am interested in loading the SID data from each individual server= , > as needed. > > > > I understand some people want to hard-wire SIDs into their client or > server > > and they will not have the YANG identifiers. I am not interested in th= is > > 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 file > is present for each server, wouldn't the mechanism from > draft-ietf-core-yang-library solve that? Or maybe you would like to have > a more compact reply that gives only the YANG module name, version and > version the SID file that can be found on a server - be it internal or > external one. If that is the need you have, we can see which is the best > 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 entire set of imported modules depends on the SID file generation date and modules available to the tools used by by authors submitting files to IANA > > > > > >> > >> Presently we believed as there are not going to be too many mega range > >> 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 them. > >> 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 thinking > >> 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 deployment > scenarios. > > This could be considered a protocol issue and can be ignored for SID > 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 the > 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 assume > that the server or a proxy in between will be able to understand their > 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, which > 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 will > still be able to use the same introspection protocol as before and find > the YANG modules looking at the SID file. > > > > >> > >> > >> > CORECONF (and SID in general) needs a SID file retrieval mechanism. > >> > Perhaps based on YANG Data Instance Files > https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-0= 6 > >> > 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 point, o= r > maybe use it unchanged > >> > - The SID files need support and probably some tool > changes in the ID-submission process > >> > - IANA will only archive the RFC version, just like YANG modules. > >> > > >> > > >> > > >> >> Gr=C3=BC=C3=9Fe, Carsten > >> > > >> > > >> > > >> > Andy > >> > > >> > >> -- > >> Best regards, > >> Ivaylo > > > > > > > > Andy > > > > -- > Best regards, > Ivaylo > Andy --000000000000bcf106059cbe31e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 22, 2020 at 3:44 AM Ivayl= o Petrov <ivaylo@ackl.io> 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 <andy@yumaworks.com> wrote:
>
>
>
> On Tue, Jan 21, 2020 at 2:55 AM Ivaylo Petrov <ivaylo@ackl.io> wrote:
>>
>> Hello Andy,
>>
>> Find my answers below
>>
>> On Sun, Jan 19, 2020 at 6:37 AM Andy Bierman <andy@yumaworks.com> wrote: >> >
>> >
>> >
>> > On Thu, Jan 16, 2020 at 9:47 AM Carsten Bormann <cabo@tzi.org> wrote:
>> >>
>> >> On 2020-01-16, at 13:50, Andy Bierman <andy@yumaworks.com> wrote:<= br> >> >> >
>> >> > There is a significant amount of metadata needed to = generate a SID file,
>> >> > starting with all the previous YANG revisions or SID= files, and when/if
>> >> > the SID files have been reset vs. updated with prese= rved numbers.
>> >>
>> >> Well, specifically, the current YANG module and the previ= ous SID 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.=C2= =A0 This calls for central entity (or a blockchain :-).
>> >> What we need to define unambiguously is who that entity i= s.
>> >> One we are at the IANA, the Designated Expert (DE) can pl= ay this role.
>> >> But we need to define the process leading up to this.
>> >> (Yes, that process will evolve, and we probably also need= to allow exceptions.
>> >> But there must be strong guide rails that work for the va= st majority 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 aw= ay with concurrent lineages; thinking that version numbers will fix any fal= lout.
>> >> 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 differen= t than the MAC address example of success
>> > in this endeavour because YANG modules need the numbers assig= ned in the development phase,
>> > not the manufacturing phase.
>> >
>> > YANG has many features that make it easier on the writer and = harder on the tool maker,
>> > such as no order dependencies, but is has some guardrails. No= matter how the writer may
>> > possibly alter or refactor a YANG module, nothing unintention= al can change the YANG identifier for
>> > any defined data node.=C2=A0 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 di= fferent.
>>
>
>
> YANG modules under development do not follow any of the "module u= pdate" rules
> so there are no restrictions that can be relied on in real YANG develo= pment.
> This requires the tools and developers to be more careful, especially<= br> > since YANG tools have no existing reason to be careful in these areas.=
>

[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 and
I don't see how we can provide anything better.



I think that WGs will w= ant to regenerate the files during development, even though
it of= ten takes the IETF 2 - 5 years to complete a YANG module.=C2=A0 Nodes get r= enamed a lot
and every time that is done it creates new SIDs and = leaves behind irrelevant SIDs.
It might takes 5x - 10x the requir= ed range by the time the WG is done.

It is not eve= n clear that I-Ds (or RFCs) can include SID files, since they rely on
=
the imports used to generate the file.=C2=A0 I agree that there is not= much that can (or should)
be done to pretend that work-in-progre= ss has any stability.


=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> >
>>
>> >
>> > I think there is a practical solution for deployment, which d= oes not require the use of the
>> > centrally maintained SID files, which is not realistic for 4 = reasons:
>> >=C2=A0 =C2=A0- no way to apply changes to an incorrect SID fil= e (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 in i= t,
> 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 after= release 1
>
>=C2=A0 =C2=A0 module foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0import A { prefix a; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0revision 2019-01-01;
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container top {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uses a:grouping1;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0}
>
> The SID file contents for /top are not determined by module foo.
> Over time, module A will keep changing and module foo will never chang= e.
> All of the unspecified revisions imported by module foo determine the = expansion of 'grouping1.
> This approach only works within a server implementation because all th= e module revisions
> are known to the client via the YANG library.
>

[ivaylo]
I think the difference of viewpoints here came from my assumption that
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 we
might need to add information in the SID file about what version of each 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.=C2=A0 In both cases it appea= rs
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 problem
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 the
constrained device. It seems that your preference, Andy, is to go with
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 point in= an "official" SID file
at all. Only the mappings for a= specific server implementation can be used.=C2=A0 Even products
= from the same vendor will use different revisions of the same imported modu= le.

It is quite possible that common SID files wil= l be practical after development is done
for a module and it is q= uite stable. There will probably be a mix of deployment strategies
depending on module maturity and implementation details.



=C2=A0
>
>
>>
>>
>> >=C2=A0 =C2=A0- no way for vendors to apply deviations on any Y= ANG 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.
>>
>> >=C2=A0 =C2=A0- the SID file generation depends on the specific= revisions of all modules imported
>> >=C2=A0 =C2=A0 =C2=A0and submodules included by the target YANG= module
>>
>> [ivaylo]:
>> I agree, but I believe this is a good thing.=C2=A0 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 mostly wor= thless
since Day One.=C2=A0 Perhaps this will be fixed someday bu= t until then, most designers do
not specify the exact revision th= at must be used.

=C2=A0
>
>
> 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 th= ere.
>
>
>>
>>
>> Could you provide more details of the issue you see?
>>
>> >=C2=A0 =C2=A0- vendors are already failing to deploy YANG modu= les from a central source model.
>> >=C2=A0 =C2=A0 =C2=A0The NETCONF and RESTCONF protocols have ro= bust mechanisms to discover and
>> >=C2=A0 =C2=A0 =C2=A0retrieve the actual YANG files used by the= server, and vendors rely on this feature.
>> >=C2=A0 =C2=A0 =C2=A0Some vendors need model branching and othe= r complexity that make SID assignment even harder
>> >=C2=A0 =C2=A0 =C2=A0(see https://tools.ietf.org/html/draft-ietf-netmod-yang-versioning-reqs-0= 2)
>> >
>>
>> [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 serve= r, as needed.
>
> I understand some people want to hard-wire SIDs into their client or s= erver
> and they will not have the YANG identifiers.=C2=A0 I am not interested= in this
> deployment option for YANG-Push so the SID values will get added at ru= ntime.
> 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 file
is present for each server, wouldn't the mechanism from
draft-ietf-core-yang-library solve that? Or maybe you would like to have a more compact reply that gives only the YANG module name, version and
version the SID file that can be found on a server - be it internal or
external one. If that is the need you have, we can see which is the best approach to resolve it.


=
You can hardwire SIDs based on proprietary vendor informatio= n or IANA information.
I don't see how IANA can maintain any = SID files though, since the entire set of imported modules
depend= s on the SID file generation date and modules available to the tools used b= y by
authors submitting files to IANA


>
>
>>
>> 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 mec= hanisms.
> The SID file format will get augmented, etc. to support real deploymen= t scenarios.
> This could be considered a protocol issue and can be ignored for SID f= iles in general.
>
> How the client gets the YANG and SID files could be considered an impl= ementation 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 the
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 assume
that the server or a proxy in between will be able to understand their
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, which 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 will
still be able to use the same introspection protocol as before and find
the YANG modules looking at the SID file.

>
>>
>>
>> > CORECONF (and SID in general) needs a SID file retrieval mech= anism.
>> > Perhaps based on YANG Data Instance Files https://tools.ietf.org/html/draft-ietf-netmod= -yang-instance-file-format-06
>> > A server will make the URI of this resource known somehow, wh= ich 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 glo= bal SID files based on the YANG module name
>> > and revision date, especially in the development phase. The I= ANA SID file may be useful after the YANG
>> > module is very stable.
>> >
>> > More solution details:
>> >=C2=A0 =C2=A0- The WG or vendor can maintain an informal publi= c archive of SID files.
>> >=C2=A0 =C2=A0- The YangModels repo update process should inclu= de SID files.=C2=A0 https://github.com/YangModels/yang
>> >=C2=A0 =C2=A0- Vendors still need the public SID file for the = starting point, or maybe use it unchanged
>> >=C2=A0 =C2=A0- The SID files need <CODE BEGINS> support = and probably some tool changes in the ID-submission process
>> >=C2=A0 =C2=A0- IANA will only archive the RFC version, just li= ke YANG modules.
>> >
>> >
>> >
>> >> Gr=C3=BC=C3=9Fe, Carsten
>> >
>> >
>> >
>> > Andy
>> >
>>
>> --
>> Best regards,
>> Ivaylo
>
>
>
> Andy
>

--
Best regards,
Ivaylo


Andy
= =C2=A0
--000000000000bcf106059cbe31e6-- From nobody Thu Jan 23 02:14:37 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 27489120255 for ; Thu, 23 Jan 2020 02:14:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 9vu7SOMHm-MA for ; Thu, 23 Jan 2020 02:14:33 -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 7AC8C120178 for ; Thu, 23 Jan 2020 02:14:33 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id b19so1915719wmj.4 for ; Thu, 23 Jan 2020 02:14:33 -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:content-transfer-encoding; bh=7wC77KvctUUvYz/G2DxT186kEOkVpZuuJ37n6ZaGMY4=; b=ZFriPkPwndUoTx+51umC/cydr93BO7rOb5HrCojn80kxweunhjpJ+xppgmCNSce7Ti Gs4/39IRKc1szXnNCk6pbrR5YgAbzXmDgijsJQPKdbR5M1CNqe8NVTQGvYAIKNt8ouv9 7nJD54zTp56/q0A0ThC0N3AbQY1jAmNPx93jvTyUByoUvDF5GxB4TqXDTfIqLKKIYY2u UvsIhsO3xuC8nUneUdugHB5+9BQb1Ipk3is33R3w13T7FYT7Gqo3UrLFwOON9lknQwp8 iu5tR1RyWrhBT6bNONiNkz2VhsF0q5sKHEQoWLCJkScVi5npSl5BA6Uu6wjrhz7SgZeP 6AjQ== 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:content-transfer-encoding; bh=7wC77KvctUUvYz/G2DxT186kEOkVpZuuJ37n6ZaGMY4=; b=QL3YWhL2SvqdvFuWb0OugaC22cfY8FgEkAeGH5OLij/Fi+6hzaRfRoqB74USEWnmJI fX3rmdJTIEbJu7H2tDKYcGz8iLYmuINnsP6lzC0zIuKi0vSW/WomiC5Fv2ur0AZZYJMg UHJPzuojqMIrXB4mjP7rDw2sCEsXsmVX4BfCeP+xQQSGDPH9Z5qauELRPJ03NukNpwaQ hd9qHclKlPEcid/+TTnQvQ4MnOFfXFGgHLHP5iduIP1mLoDZWETXqAbUFQqIsy8OsTzp jERoX3YCPgsQwWzTJ754itkrzQ6btNhjAQAOzJvZnQO59+p13eGlU2AdU9vA09tXEjU4 uTPg== X-Gm-Message-State: APjAAAXZWZ1XBaZUUhgqcSa93mSrlbUEuRFNa8YnHuQpWhTrKY1GeafR p/1ApauvZLEDkIAuFsQoXFhVURjEl01Zj/zHwyIEEg== X-Google-Smtp-Source: APXvYqwUfseBaR2jXNdC6/i8vAzuN0CznUy/2MerMeKTa8VKLzRepNTI9XRiySx3wPdtHtbGSGYQFFTf4GBCBnYT9ig= X-Received: by 2002:a7b:c416:: with SMTP id k22mr3535533wmi.10.1579774471675; Thu, 23 Jan 2020 02:14:31 -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: Thu, 23 Jan 2020 11:14:05 +0100 Message-ID: To: Andy Bierman Cc: Carsten Bormann , Core , Alexander Pelov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Thu, 23 Jan 2020 10:14:36 -0000 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 wrote= : > > > > > > > > > > > > On Tue, Jan 21, 2020 at 2:55 AM Ivaylo Petrov wrote: > > >> > > >> 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 wro= te: > > >> >> > > >> >> On 2020-01-16, at 13:50, Andy Bierman wrote: > > >> >> > > > >> >> > There is a significant amount of metadata needed to generate a = SID > > file, > > >> >> > starting with all the previous YANG revisions or SID files, and > > when/if > > >> >> > the SID files have been reset vs. updated with preserved number= s. > > >> >> > > >> >> Well, specifically, the current YANG module and the previous SID > > 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 cal= ls > > 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 this > > role. > > >> >> But we need to define the process leading up to this. > > >> >> (Yes, that process will evolve, and we probably also need to allo= w > > exceptions. > > >> >> But there must be strong guide rails that work for the vast major= ity > > 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 with > > concurrent lineages; thinking that version numbers will fix any fallout= . > > >> >> 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 tha= n > > the MAC address example of success > > >> > in this endeavour because YANG modules need the numbers assigned i= n > > the development phase, > > >> > not the manufacturing phase. > > >> > > > >> > YANG has many features that make it easier on the writer and harde= r > > on the tool maker, > > >> > such as no order dependencies, but is has some guardrails. No matt= er > > how the writer may > > >> > possibly alter or refactor a YANG module, nothing unintentional ca= n > > 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 chang= ing > > 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 c= ase. > > >> Note that I added the restriction of not changing paths as otherwise= 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 updat= e" > > 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, especially > > > since YANG tools have no existing reason to be careful in these areas= . > > > > > > > [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 and > > I don't see how we can provide anything better. > > > > > > I think that WGs will want to regenerate the files during development, ev= en > though > it often takes the IETF 2 - 5 years to complete a YANG module. Nodes get > 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 the= y > rely on > the imports used to generate the file. I agree that there is not much th= at > 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 n= ot > > require the use of the > > >> > centrally maintained SID files, which is not realistic for 4 reaso= ns: > > >> > - 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 version > > >> 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 Michael > > >> said, the latest > > >> version of the .sid file should be able to handle both all clients o= f > > >> previous versions of > > >> the YANG module and the latest one. As there could be multiple versi= ons > > for one > > >> version of a YANG module, errors could be corrected. Does this sound > > >> 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 in = 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 afte= r > > 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 chan= ge. > > > All of the unspecified revisions imported by module foo determine the > > expansion of 'grouping1. > > > This approach only works within a server implementation because all t= he > > module revisions > > > are known to the client via the YANG library. > > > > > > > [ivaylo] > > I think the difference of viewpoints here came from my assumption that > > 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 we > > might need to add information in the SID file about what version of eac= h > > 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 al= l > > the YANG modules and the revision information. In both cases it appear= s > > 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 problem > > 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 the > > constrained device. It seems that your preference, Andy, is to go with > > 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 point = 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 file 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 a= ll > > 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 o= f > > RFC6020 > > >> > > >> ` modules need to be imported using specific revisions`. > > > > > > > > > The YANG import-by-revision mechanism is fatally flawed and has been most= ly > 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 cent= ral > > source model. > > >> > The NETCONF and RESTCONF protocols have robust mechanisms to > > discover and > > >> > retrieve the actual YANG files used by the server, and vendors > > rely on this feature. > > >> > Some vendors need model branching and other complexity that ma= ke > > 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 th= at > > >> mega range in > > >> the IANA registry. > > >> 3. You contact that mega range operator through a given protocol to > > >> obtain further details. > > >> > > > > > > > > > No. I am interested in loading the SID data from each individual serv= er, > > as needed. > > > > > > I understand some people want to hard-wire SIDs into their client or > > server > > > and they will not have the YANG identifiers. I am not interested in = 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 file > > is present for each server, wouldn't the mechanism from > > draft-ietf-core-yang-library solve that? Or maybe you would like to hav= e > > a more compact reply that gives only the YANG module name, version and > > version the SID file that can be found on a server - be it internal or > > external one. If that is the need you have, we can see which is the bes= t > > 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 entire > set of imported modules > depends on the SID file generation date and modules available to the tool= s > 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 ran= ge > > >> registries and > > >> we have no experience operating them it might be unwise to specify t= he > > >> protocol that > > >> they need to implement in order for clients to be able to query them= . > > >> Specifying such a > > >> protocol might be something we do if this is a really big concern fo= r > > people. > > >> Would that retrieval mechanism cover the cases that you were thinkin= g > > >> 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 deployme= nt > > scenarios. > > > This could be considered a protocol issue and can be ignored for SID > > 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 the > > 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 assume > > that the server or a proxy in between will be able to understand their > > 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, whic= h > > 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 th= e > > endpoints is really constrained. In that case I believe the client will > > still be able to use the same introspection protocol as before and find > > the YANG modules looking at the SID file. > > > > > > > >> > > >> > > >> > CORECONF (and SID in general) needs a SID file retrieval mechanism= . > > >> > Perhaps based on YANG Data Instance Files > > https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format= -06 > > >> > A server will make the URI of this resource known somehow, which c= an > > 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 S= ID > > files based on the YANG module name > > >> > and revision date, especially in the development phase. The IANA S= ID > > 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 SI= D > > 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 point,= or > > maybe use it unchanged > > >> > - The SID files need support and probably some too= l > > changes in the ID-submission process > > >> > - IANA will only archive the RFC version, just like YANG modules= . > > >> > > > >> > > > >> > > > >> >> Gr=C3=BC=C3=9Fe, Carsten > > >> > > > >> > > > >> > > > >> > Andy > > >> > > > >> > > >> -- > > >> Best regards, > > >> Ivaylo > > > > > > > > > > > > Andy > > > > > > > -- > > Best regards, > > Ivaylo > > > > > Andy -- Best regards, Ivaylo From nobody Thu Jan 23 05:04: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 4D54A1207FC; Thu, 23 Jan 2020 05:04:05 -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.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <157978464523.22613.16017465022251621477@ietfa.amsl.com> Date: Thu, 23 Jan 2020 05:04:05 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-09.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: Thu, 23 Jan 2020 13:04:05 -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-09.txt Pages : 31 Date : 2020-01-23 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-09 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 Thu Jan 23 05:13:12 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 6219E120819; Thu, 23 Jan 2020 05:13:11 -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.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <157978519135.22790.5431015597755855232@ietfa.amsl.com> Date: Thu, 23 Jan 2020 05:13:11 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-library-01.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: Thu, 23 Jan 2020 13:13:11 -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 : Constrained YANG Module Library Authors : Michel Veillette Ivaylo Petrov Filename : draft-ietf-core-yang-library-01.txt Pages : 15 Date : 2020-01-23 Abstract: This document describes a constrained version of the YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a constrained network management server (e.g., a CORECONF server). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-library/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-yang-library-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-library-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-library-01 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/