From nobody Fri Mar 1 04:05:26 2019 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 310C2130E6B for ; Fri, 1 Mar 2019 04:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=CIQaFFfi; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=h+ZiJIYX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Raa9_7oyZ6BZ for ; Fri, 1 Mar 2019 04:05:15 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E77C130E2F for ; Fri, 1 Mar 2019 04:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551441911; x=1554033911; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=J7ueN4d2J28suCfCFcRX51GEmNtzcLIjLkTggD4edWQ=; b=CIQaFFfiZdF3l9vRAzQFUxaE2MOTEG0CfaunUcB7G4Qkpfk4RSKET7r/LItQ6Els VHQQ7gEItunCBzvZdSGHhu/l0/eD+PqHFKHiuhWQdW6nhuTXJbPcK8cM9G0MkORy AIBHGHYyLJPjqmWTtQjo9+uWJBlMon1Rk/aFeE81Y38=; X-AuditID: c1b4fb30-41b3a9e00000355c-7e-5c791ff7ec7a Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 07.B3.13660.7FF197C5; Fri, 1 Mar 2019 13:05:11 +0100 (CET) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Mar 2019 13:05:09 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 1 Mar 2019 13:05:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MdvBJBONiFXQQsFPFH2hipDjref8h6lsfHviqrmNQ/w=; b=h+ZiJIYXTFO+pfNOfeagCieGcMaflmrU4OeOj1QOaSMqzeYyAAZAY+uJA6TWh/BmBfNnY7rv+kTGBLFNSKmRFIKkXsMUUTRUENSH70v7kI4hySUbML7J8HWjsDrMtUPOHd0uKzIhm8brcy28o2L6AI/CKcgmRw5XebQcLAs0S8s= Received: from AM5PR0701MB2307.eurprd07.prod.outlook.com (10.169.152.18) by AM5PR0701MB2324.eurprd07.prod.outlook.com (10.169.152.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.5; Fri, 1 Mar 2019 12:05:08 +0000 Received: from AM5PR0701MB2307.eurprd07.prod.outlook.com ([fe80::60c7:8b7:f1b1:b641]) by AM5PR0701MB2307.eurprd07.prod.outlook.com ([fe80::60c7:8b7:f1b1:b641%11]) with mapi id 15.20.1686.009; Fri, 1 Mar 2019 12:05:08 +0000 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: =?utf-8?B?Q2hyaXN0aWFuIE0uIEFtc8O8c3M=?= CC: core , Carsten Bormann , "draft-ietf-core-resource-directory@ietf.org" Thread-Topic: [core] Chair's review of draft-ietf-core-resource-directory-19 Thread-Index: AdTKqThILqREaxH5RIWEnORALxAYaQFAMI8AAB9B7AA= Date: Fri, 1 Mar 2019 12:05:07 +0000 Message-ID: References: <20190228211005.GD15212@hephaistos.amsuess.com> In-Reply-To: <20190228211005.GD15212@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 82280e05-6679-45a8-e0fe-08d69e3e25ea x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM5PR0701MB2324; x-ms-traffictypediagnostic: AM5PR0701MB2324: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjIzMjQ7MjM6NHA2M0FBU0dBT0VyMlZrTTlvd1IwcW5a?= =?utf-8?B?YTBURkk0RG5zODhZYjhIZWNVbElOS1VtT1k0RXhmU2RHWmtTemkxa0FFNTNh?= =?utf-8?B?ejNJa2VFV2ExR0RsVlFvUFZ3SVB2Z0Z6VmlHTVJpcUorTkVpQyt0MWNtd2dj?= =?utf-8?B?QzlZMHlzbElTTmlkSkZ3YnFubHBxQzhiYUExVkNvbGF1U1gwbEFhV0FIWGV6?= =?utf-8?B?RXQyZFFjR211K3V4YUlIYVFlbm9LMWd4elY5cDVPZzhabzZaM0N0dDNWU3Jh?= =?utf-8?B?NXBkTzMwSFgvbWVDbjR0empmSm5nWE0zTHhJUkxrTzJYMWhMcGZ0bURhWUpZ?= =?utf-8?B?bkJXQlhLbmpqd0RUODdZRXpYZW5tci84NWRRZmxmYzREd2Z1WW80djhLTjBs?= =?utf-8?B?ZGZGekYzZUFPZmVNZjhPZGJHWHpYMzNTdHBXbk4ydDBjWW9yRlBWRVU4ZWRL?= =?utf-8?B?eHcvVEJuZGhGd1FNMGVoSExZZkpQVFBENzVXTmUxb0pUTTA4emtVL05MYkxs?= =?utf-8?B?SXVDbzVkZytjcE42UER4ZGhMMjFJRitzUVpEck9tR0kwSFZ5MmZ5c2RHZWph?= =?utf-8?B?ak1YNGNmMUxuVWFqQUphNk5nbTlVdjlkeUUwTDJZS0JvdDdKbWpTeXVtWWZz?= =?utf-8?B?T1ppMVF6Zm5wUHNOSHlZT1ZXVTIrYTdnOGtkWllid1hwZkFjVytieTVrdGRj?= =?utf-8?B?UVQrT0dCeDRyYklCeW1wWjFmMExKbUVady8wVG85cTI4RmEzZnhvQzl6Q0N3?= =?utf-8?B?OUtjTk9TT085Y0w3dllLWmtkQUpLQTZZWGFrTFNXRFJIRUUxYnlHdDhiNTZ0?= =?utf-8?B?RG92Wm5qNmVEL2VxOG1McCt3WkM0a2NGZ0R1VEEyVm8xRk9jdjRPcXpCUm10?= =?utf-8?B?QThPT3BKY2FQaHRJVUVmYjdCcitGWi9nWi9mak5vNGJuRE9lVW5mbTc5c3RE?= =?utf-8?B?RFNZZDAyRmZqN0c3VFhTNVBhMDZyOGswMUpHbzVzNE9LR3EwUGNRcTlIdjBh?= =?utf-8?B?d2RXaURiTzlKQkk4QzhiVGRJSmZtdFZsakdFSXIvTHFiRElibjJhSE5zTi96?= =?utf-8?B?dWM1N0diK29UcVNVOWRVZFRGbUpkM1hBd2ozLzJVbTIyM1lFNlNNRXNoM0dL?= =?utf-8?B?U1ZndVZFQ2p5cUVOdUR5ZWRESW1FMno2Wm4rRW54L05renJDZUVqTGZuc0Z0?= =?utf-8?B?QU9PaVhJZlIzeVJld0k0TzdNMCtxNU04NTEzbUViK005ZWEvZ05WSVJkaHlj?= =?utf-8?B?WndzN3JMOXRueUx0NDFpNS9mQmF5ckVCSy9wOVYzWnVzMEhiVTFBcFBTUVkr?= =?utf-8?B?eXdNR0hDeVlaOVZjUW5CemowdHBvSlAvRGJBenE3L1RUZU5Ra29NdlNKTWNN?= =?utf-8?B?S1h6YXVNS2tZTWxYMzVHd0tQM2FOTFFBTFNvb0UxQWlhaGdoQVo0RkJLcmhr?= =?utf-8?B?NXFuTElyMWc4QjNtODJKanZCUGtselNGa3RJQmwwQWF4cnhDZTBpQkhIb01Y?= =?utf-8?B?bkIxQk1RTzhQRFZlbUp2dnFQMjVzTWdtOTdxYnZ1Y3N3SisyUEhUTkNXNUlt?= =?utf-8?B?U0crUmJGalYxazVvZXJnNktSZzRTTGRCSE5MclVhMWpFTU54M3YrM2tFMFp0?= =?utf-8?B?cFR3S3Rjdk5jQkJoOXh1L3Y3WDhDaklyeHkwZHIrbFBib2pMZXY3cHVma0Ny?= =?utf-8?B?UjVUa0o0Wk9jQWpSdC9MU2lsekh2RlFEUy82STYxNlc5RFU3T0VlNDNwMGU0?= =?utf-8?B?Y01ETkxocE1aeWRtRGNIS2lEUDFqS01CWUZrTHZOeElVNDBibk9kdmdFcWhW?= =?utf-8?B?eVRZYTUvczQ1NDRzdm1DY0N5dkxuZ0FYVVh5SWRlT2o5RDhvZC9Nd0ZjcVlX?= =?utf-8?B?TWE4OFBvV0xFbmtpL3ozc3RiVHZTbm1WQUp0L0paeTZ3NlJmdU5nUjZ1amRk?= =?utf-8?Q?H1MFo5scQbTZzr+AfRqCflP+UTGUAEk8=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09634B1196 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(376002)(39860400002)(346002)(189003)(199004)(51914003)(102836004)(6512007)(6306002)(54896002)(14444005)(256004)(68736007)(36756003)(53936002)(236005)(25786009)(6486002)(6436002)(6246003)(66066001)(66574012)(71200400001)(7736002)(6346003)(6506007)(26005)(4326008)(71190400001)(8676002)(76176011)(83716004)(81166006)(486006)(2906002)(81156014)(186003)(476003)(85182001)(478600001)(105586002)(14454004)(2616005)(33656002)(6916009)(11346002)(97736004)(54906003)(8936002)(106356001)(316002)(85202003)(229853002)(99286004)(606006)(86362001)(5660300002)(446003)(966005)(3846002)(6116002)(99936001)(82746002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2324; H:AM5PR0701MB2307.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jaime.jimenez@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YK6/VEd2NyYSZ3+iRbXrrbI5ouIZicEB19vSgy6n57F1WvBrCOBqwQEKAUR879sn8jMMWohg+joSQd2+4CTvuD3f+HxUnEbbVI+KPYFLLW8CWZ0I3InaheL9D98f0Wp9cVsAGK4GeeqqaRZug+OHdHePmncNOLW38DKcyp/oOa0M3DlugRF/F0t0g5xky1y/4N5jMWfaYkrVucGFPvExIvNT8EZGsDm+9MtUH3dp4mL+hV96QApPF9As2RM7fhbEXPh5sQYw61sm1PcUGshL8JWZ+icT3ssbzGXZGu+iMEuhP9LgYrgn73U0GyjROeQMLe4zf/rn+BXfQXfNGzH7kFYJmN3WWDVxn3aSi1vN117XdfIQMjw3tkpRX+zhpP6KFjopQajx2llQL3hXKQJ7VeWGcYCCgMgRBgAyHhvwgvc= Content-Type: multipart/signed; boundary="Apple-Mail=_5353BA3A-BAD9-4EAB-AFD5-5A450CD04835"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 82280e05-6679-45a8-e0fe-08d69e3e25ea X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2019 12:05:07.9984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2324 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSbSyVYRjHu5/nOS/o1O14u6gmZz5EkqRRSSpiqelDH6oxHXq8FIedR0bW pkVEIZMhVp1IqZDyMuWUQyWlyJYxzGsYx5K8N+ucc2tr69vvuv7/+/5f97VbSItneBbCMFk0 K5dJwyV8fSbvZA23bd4yzs+hc9TCpSm7l+eirE1nXJTqctrlzbyzO+Od2rDE8y4qWqS8cxRh x+nT+q5n2fCwGFa+3e2Mfmjb9QZB1KM0KrY4Y5ZOQB1jKBUJhYCdoOalSSrSF4pxE4Jvr3qo VKSnKWYRvJuMJ8J9Cr6k91PagsGZNHQpu/lEuUXB08o6ihTDCNT1VXzteT4+BD+/XxZo2Rh7 QFJfI9IyjfMQ9P7SZRhhH2jsSFz1HIXk6ue0diZjvAcSC9y1bQZbww/1iM4iwvuhb2WZJllZ CMp6pnWCHnaFpewKWssIm8J8yxOKZJlB9/AdHQM2hoH2j3zCJjA+tMIjbAWtUwOrnk3w9U4a InwMSj9XIm0Y4BEErTO3aCLYgWJYzSfCMyNoUVxdFSJhrHOSIVvdCA/LLpF2OR8aF0zJUlko eZqkWzzC/tByj81Edvn/jJqvuZXGOQgU47lUvu7RhvAhb5ghpkCYqernE94KD+5N0IRt4HVa CfN/fwtcm7vJI7wLJt5OI8J7YbFgcJWtIDttQHAXGZQiE47lAiNCHB3tWXlYEMdFyuxlbHQl 0ny/hhfLDrVofPSACmEhkqwV7RPE+Yl50hguLkKFrDX3DFY8bkMWjCxSxkqMRevWaGTRWWnc RVYeGSC/EM5yKrRByEjMRL/Fhn5iHCKNZs+zbBQr/6tSQj2LBOQZfLhbGWAOljn23PZu50T/ GV9bmV6ISmXg464YL1kxd5osEMXWxAgijiR7BRU3N5V0TZd9YrJOtftF9I09z7/d8ba5vzCH Fn10G7KudlzwOF2+u/6+jfXmwvfnUk4Ytq6/6xB/xTDXwzdjZ8qUQetBWZ36uNcNXlE4NVfR Hqz0lDBcqHSHLS3npH8AO0zuk4YDAAA= Archived-At: Subject: Re: [core] Chair's review of draft-ietf-core-resource-directory-19 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, 01 Mar 2019 12:05:24 -0000 --Apple-Mail=_5353BA3A-BAD9-4EAB-AFD5-5A450CD04835 Content-Type: multipart/alternative; boundary="Apple-Mail=_A1F3E7C4-2412-45F6-9E13-509BE59207EB" --Apple-Mail=_A1F3E7C4-2412-45F6-9E13-509BE59207EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christian, thanks for the reply, comments inline. > Asking back > ----------- >=20 >> p20 p28 p31 p38 and others - There does not seem to be a common way = to >> present REST interactions in the examples of the document. Please use >> always the same form. For example similar to: >>=20 >> : -> >> : >> >> : >> >>=20 >> Which in markdown would look like: >> ~~~~ >> Int: EP -> IPv6 Multicast Address (FF0X::FE) or [MCD1] >> Req: GET coap://[MCD1]/.well-known/core?rt=3Dcore.rd* >> Res: 2.05 Content >> ;rt=3D"core.rd";ct=3D40, >> ;rt=3D"core.rd-lookup-ep";ct=3D40, >> ;rt=3D"core.rd-lookup-res";ct=3D40, >> ~~~~ >>=20 >=20 >=20 >> p23 - Sorry for asking, but why is base URI only mandatory when = filled >> by the Commissioning Tool? Wouldn't it be better to make it always >> mandatory to avoid the differentiation? >=20 > That'd require the registrant to find out its currently preferred IP > address, keep track of it and serialize it -- something it may often = not > need to do for any other purpose. >=20 > For example, non-TCP CoAP devices in a 6LoWPAN deployment can be sure = to > never need base URIs, and don't even need to consider at runtime when = to > update their base address as long as their registration lifetime is = not > "long-living" in RFC6879 terms (hours or days). >=20 > Applications that talk to the device exclusively through the RD (such = as > LwM2M, or the extension at [1]) need the base URI to be absent, so not > requiring the base URI also helps not conflicting with existing > deployments. >=20 > [1]: = https://tools.ietf.org/html/draft-amsuess-core-resource-directory-extensio= ns-00#section-2 OK, that makes a lot of sense now. >=20 >> p26 - Section 5.3.1 seems like could use a bit of reordering, I can >> explain this in another email or call with the authors. >=20 > Looking forward to any suggestion. Sure, I will ping you in a bit. >=20 >> p22 - Endpoint Name "mostly mandatory" is ambiguous. If the ep name = is >> not needed to register to an RD then it is optional. If, on the other >> hand the RD needs an ep name and assigns one then it is mandatory ( >> btw if the RD assigns the ep name, shouldn't it return that >> information to the ep, together with the location within the rd, once >> the registration is successful? ) >=20 > The endpoint name is mandatory in the information model, but not = always > mandatory in the registration URI. As for the "mostly mandatory" = phrase, > I'll try to phrase that better (together with the base URI which is = also > mandatory or optional depending on some criteria). OK, thanks. >=20 > As for the device learning the endpoint name, my expectation is that > that is bound to the security context (eg. for certificates, it can be > the certificate identifier), so registrant and RD would already agree = on > it. OK, I thought that epname was needed by the device (for example when = doing a registration update). Now I see that it is not really needed for further operations.=20 >=20 > A registrant can use the endpoint lookup interface to retrieve the ep > name of its registration, but admittedly that's a bit intricate -- are > there applications for a registrant learning its endpoint name that'd > warrant adding mechanism to learn it more easily? As before, I see now that the epname is not really necessary to do = update operations on the RD. If there is no real need by the use case then let=E2=80=99s not change = that.=20 >=20 >> p41 p42 - Just to clarify, is then the tuple [endpoint,sector] the = way >> RD identifies endpoints? Or is it derived from the device's >> credentials? >>=20 >> - "A given endpoint that registers itself, needs to proof its >> possession of its unique (endpoint name, sector) value pair." - "An >> Endpoint (name, sector) pair is unique within the et of endpoints >> registered by the RD. An Endpoint MUST NOT be identified by its >> protocol, port or IP address as these may change over the lifetime of >> an Endpoint." >=20 > The tuple (endpoint name, sector) is how the RD identifies endpoints. = It > may learn the registrant's endpoint name and sector from explicit > registration argumemts or from the the credentials. OK >=20 >> p15 - I wonder why there is no DHCP/DHCP6 option to discover RD >> defined, is there no interest by those deploying RD? If the authors >> find it relevant, it could be added as a new draft or as part of this >> one in a similar way as the RDAO option on a new section 4.2 >=20 > AFAICT it just has not come up so there was no need to (given that in > 6LoWPAN deployments TTBOMK the ND configuration is more prevalent). Do > you know of any interested parties or setups? At this point of time I don=E2=80=99t know any. I just assumed that = it=E2=80=99d be common in LAN/WLAN settings. > Otherwise the answer is > probably still "no such option is defined at the time of writing" (but > can be added easily by anyone later). >=20 >=20 > Easy editorial fixes > -------------------- >=20 >> p1 - "Web interfaces" is often used interchangeably with "REST = interfaces" it'd be better to use one only, maybe the latter. >> p6 - RDAO is under-defined in the terminology section, expanding the = acronym is too short for a definition. >> p6 - "Only information SHOULD be stored in the resource directory = that can be obtained by querying ..." could be "Information SHOULD be = stored in the resource directory only if it can that can be obtained by = querying ..." >> p8 - The Commissioning Tool (CT) should be added to the architecture = on the Registration Interface. >> p6 - the last paragraph of Section 2 "For several operations.... = circumstances" could probably go before the enumeration of the = terminology. >> p10 =E2=80=93 change content-type (ct)/content-format (ct) >> p44 - typo address/Address >=20 > Thanks, will be fixed by the next version. [193] Cool. >=20 > Being discussed among authors > ------------------------------- >=20 > The questions I don't feel comfortable answering have been put into = the > authors' issue tracker. >=20 >> p3 p12 - I think we could move on and update the term = "machine-to-machine" to "Internet of Things" throughout the document, = unless there is a specific need to keep M2M still there. >=20 > [194] with suggestion for change Great, I am seeing that maybe next time I can do a pull-request on the = repo directly to save you some work. >=20 >> p33 - As per the document structure, there are two interfaces: = registration and lookup. Shouldn't they be at the same level in the = document? Registration is 5.3, shouldn't lookup be 5.5 instead of 6? >=20 > [195] with suggestion for change >=20 your suggestion looks good to me, also for consistency we could change = =E2=80=9CRegistration" to =E2=80=9CRD Registration=E2=80=9D. Sorry for = nitpicking. >> p30 - lt, base and extra-attrs were already explained in 5.3 you = might >> want to keep it as it is or change it by adding a reference to 5.3 = and >> comment on the changes that the Registration Update has over the >> Registration. >=20 > [196], though I don't really see yet what to do about it; I'll try for > some text. No problem, it=E2=80=99s just a suggestion. >=20 >> "The entries for "Failure" are quite repetitive for 4.00 and 5.03. = Can we factor these out a bit? >> The entry "HTTP support" is surprising; maybe this item should be = explained beforehand. (It seems all it is saying is that HTTP does not = do multicast or /.well-known/core?)" >=20 > [191] as you mentioned; waiting for feedback from the authors. ACK >=20 >> Github Issue 190 (below) raises the need to define a bit better what = the ep name is supposed to contain. To me, we could keep it mandatory = and add some guidelines for its creation, in OMA for example they are = defined as an URN = http://www.openmobilealliance.org/release/LightweightM2M/V1_1-20180710-A/H= TML-Version/OMA-TS-LightweightM2M_Core-V1_1-20180710-A.html#7-3-1-0-731-En= dpoint-Client-Name >> "All we know from the draft is that it is =E2=89=A4 63 bytes. But we = need to say that it is a UTF-8 string. Not entirely sure we want = =F0=9F=98=88=F0=9F=91=84=F0=9F=91=BD as an endpoint name either. Same = for sector." >=20 > [190] as you mentioned; there's some things we'll definitely need to = do > (state it's UTF-8 or ASCII); outlawing Unicode by properties is = tricky, > and I wouldn't even know which ASCII characters to permit. I'm leaning > towards allowing daemon-kissing aliens, but waiting for authors' > opinions. Yeah, about this one; we could provide some MAY guidelines as to the use = of UUIDs and URNs? So that we can have both = "urn:uuid:########-####-####-####-############=E2=80=9D and = =E2=80=9D=F0=9F=A4=94=F0=9F=92=A1=F0=9F=A4=98=E2=80=9D Were can I get the emoji license plates again? :D=20 >=20 >> p3 - "with limited RAM and ROM" Adding a reference to the expected = RAM >> and ROM would be good. https://ieeexplore.ieee.org/document/6970748/ >> provides an estimation of <2kB of minimum RAM and <30kB of minimum = ROM >> for common IoT OSs. >=20 > [197], hoping anyone has more reliable numbers than I do. ACK >=20 >=20 > Thanks again; I'll follow up as the referenced issues bear fruit > Christian >=20 > [190]: https://github.com/core-wg/resource-directory/issues/190 > [191]: https://github.com/core-wg/resource-directory/issues/191 > [193]: https://github.com/core-wg/resource-directory/issues/193 > [194]: https://github.com/core-wg/resource-directory/issues/194 > [195]: https://github.com/core-wg/resource-directory/issues/195 > [196]: https://github.com/core-wg/resource-directory/issues/196 > [197]: https://github.com/core-wg/resource-directory/issues/197 >=20 Thanks a lot to you for the quick reply and for the great work! > --=20 > To use raw power is to make yourself infinitely vulnerable to greater = powers. > -- Bene Gesserit axiom --Apple-Mail=_A1F3E7C4-2412-45F6-9E13-509BE59207EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Christian,

thanks = for the reply, comments inline.

Asking back
-----------

p20 p28 p31 p38 and = others - There does not seem to be a common way to
present = REST interactions in the examples of the document. Please use
always the same form. For example similar to:
<Interaction>: <Origin EP> -> <Destination = EP>
<Request>:  <Method> = <URI/PATH>
=            <PAYL= OAD>
<Response>: <Code>
=            <PAYL= OAD>

Which in markdown would look = like:
~~~~
 Int: EP -> IPv6 = Multicast Address (FF0X::FE) or [MCD1]
 Req: GET coap://[MCD1]/.well-known/core?rt=3Dcore.rd*
=  Res: 2.05 Content
=       </rd>;rt=3D"core.rd";ct=3D40, =       </rd-lookup/ep>;rt=3D"core.rd-lo= okup-ep";ct=3D40,
=       </rd-lookup/res>;rt=3D"core.rd-l= ookup-res";ct=3D40,
~~~~



p23 - Sorry for asking, but why is base URI = only mandatory when filled
by the Commissioning Tool? = Wouldn't it be better to make it always
mandatory to avoid = the differentiation?

That'd = require the registrant to find out its currently preferred IP
address, keep track of it and serialize it -- something it = may often not
need to do for any other purpose.

For example, non-TCP CoAP devices in a 6LoWPAN = deployment can be sure to
never need base URIs, and don't = even need to consider at runtime when to
update their base = address as long as their registration lifetime is not
"long-living" in RFC6879 terms (hours or days).

Applications that talk to the device = exclusively through the RD (such as
LwM2M, or the = extension at [1]) need the base URI to be absent, so not
requiring the base URI also helps not conflicting with = existing
deployments.

[1]: https://tools.ietf.org/html/draft-amsuess-core-resource-directo= ry-extensions-00#section-2

OK, = that makes a lot of sense now.

p26 - Section 5.3.1 seems like could use a bit = of reordering, I can
explain this in another email or call = with the authors.

Looking = forward to any suggestion.
Sure, I will ping you in a bit.


p22 - = Endpoint Name "mostly mandatory" is ambiguous. If the ep name is
not needed to register to an RD then it is optional. If, on = the other
hand the RD needs an ep name and assigns one = then it is mandatory (
btw if the RD assigns the ep name, = shouldn't it return that
information to the ep, together = with the location within the rd, once
the registration is = successful? )

The endpoint = name is mandatory in the information model, but not always
mandatory in the registration URI. As for the "mostly = mandatory" phrase,
I'll try to phrase that better = (together with the base URI which is also
mandatory or = optional depending on some criteria).

OK, = thanks.


As for the device learning the = endpoint name, my expectation is that
that is bound to the = security context (eg. for certificates, it can be
the = certificate identifier), so registrant and RD would already agree on
it.

OK, I thought that epname was needed by the device = (for example when doing a registration update).
Now I see that = it is not really needed for further operations. 


A registrant can use the endpoint lookup = interface to retrieve the ep
name of its registration, but = admittedly that's a bit intricate -- are
there = applications for a registrant learning its endpoint name that'd
warrant adding mechanism to learn it more easily?

As = before, I see now that the epname is not really necessary to do update = operations on the RD.
If there is no real need by the use case = then let=E2=80=99s not change that. 


p41 p42 - Just to = clarify, is then the tuple [endpoint,sector] the way
RD = identifies endpoints? Or is it derived from the device's
credentials?

- "A given endpoint = that registers itself, needs to proof its
possession of = its unique (endpoint name, sector) value pair." - "An
Endpoint (name, sector) pair is unique within the et of = endpoints
registered by the RD.  An Endpoint MUST NOT = be identified by its
protocol, port or IP address as these = may change over the lifetime of
an Endpoint."

The tuple (endpoint name, sector) = is how the RD identifies endpoints. It
may learn the = registrant's endpoint name and sector from explicit
registration argumemts or from the the credentials.

OK


p15 - I wonder why there is no DHCP/DHCP6 = option to discover RD
defined, is there no interest by = those deploying RD? If the authors
find it relevant, it = could be added as a new draft or as part of this
one in a = similar way as the RDAO option on a new section 4.2

AFAICT it just has not come up so = there was no need to (given that in
6LoWPAN deployments = TTBOMK the ND configuration is more prevalent). Do
you = know of any interested parties or setups? =

At this point of = time I don=E2=80=99t know any. I just assumed that it=E2=80=99d be = common in LAN/WLAN settings.

Otherwise the answer = is
probably still "no such option is defined at = the time of writing" (but
can be added easily by anyone = later).


Easy editorial = fixes
--------------------

p1 - "Web interfaces" is = often used interchangeably with "REST interfaces" it'd be better to use = one only, maybe the latter.
p6 - RDAO is under-defined in = the terminology section, expanding the acronym is too short for a = definition.
p6 - "Only information SHOULD be stored in the = resource directory that can be obtained by querying ..." could be = "Information SHOULD be stored in the resource directory only if it can = that can be obtained by querying ..."
p8 - The = Commissioning Tool (CT) should be added to the architecture on the = Registration Interface.
p6 - the last paragraph of Section = 2 "For several operations.... circumstances" could probably go before = the enumeration of the terminology.
p10 =E2=80=93 change = content-type (ct)/content-format (ct)
p44 - typo = address/Address

Thanks, will = be fixed by the next version. [193]

Cool.


Being = discussed among authors
-------------------------------

The questions I don't feel comfortable = answering have been put into the
authors' issue = tracker.

p3 p12 - I think we could move on and update the term = "machine-to-machine" to "Internet of Things" throughout the document, = unless there is a specific need to keep M2M still there.

[194] with suggestion for = change

Great, I am seeing that maybe next time I can do a = pull-request on the repo directly to save you some work.


p33 - As = per the document structure, there are two interfaces: registration and = lookup. Shouldn't they be at the same level in the document? = Registration is 5.3, shouldn't lookup be 5.5 instead of 6?

[195] with suggestion for = change


your suggestion looks good to me, also for = consistency we could change =E2=80=9CRegistration" to =E2=80=9CRD = Registration=E2=80=9D. Sorry for nitpicking.

p30 - lt, base and = extra-attrs were already explained in 5.3 you might
want = to keep it as it is or change it by adding a reference to 5.3 and
comment on the changes that the Registration Update has over = the
Registration.

[196], though I don't really see yet what to do about it; = I'll try for
some text.

No = problem, it=E2=80=99s just a suggestion.


"The entries for = "Failure" are quite repetitive for 4.00 and 5.03. Can we factor these = out a bit?
The entry "HTTP support" is surprising; maybe = this item should be explained beforehand. (It seems all it is saying is = that HTTP does not do multicast or /.well-known/core?)"

[191] as you mentioned; waiting = for feedback from the authors.

ACK


Github Issue 190 (below) raises the need to = define a bit better what the ep name is supposed to contain. To me, we = could keep it mandatory and add some guidelines for its creation, in OMA = for example they are defined as an URN http://www.openmobilealliance.org/release/LightweightM2M/V1_1-2= 0180710-A/HTML-Version/OMA-TS-LightweightM2M_Core-V1_1-20180710-A.html#7-3= -1-0-731-Endpoint-Client-Name
"All we know from the = draft is that it is =E2=89=A4 63 bytes. But we need to say that it is a = UTF-8 string. Not entirely sure we want =F0=9F=98=88=F0=9F=91=84=F0=9F=91=BD= as an endpoint name either. Same for sector."

[190] as you mentioned; there's = some things we'll definitely need to do
(state it's UTF-8 = or ASCII); outlawing Unicode by properties is tricky,
and = I wouldn't even know which ASCII characters to permit. I'm leaning
towards allowing daemon-kissing aliens, but waiting for = authors'
opinions.

Yeah, = about this one; we could provide some MAY guidelines as to the use of = UUIDs and URNs?
So that we can have both "urn:uuid:########-####-####-####-############=E2=80=9D and= =E2=80=9D=F0=9F=A4=94=F0=9F=92=A1=F0=9F=A4=98=E2=80=9D
Were can I get = the emoji license plates again? :D 


p3 - = "with limited RAM and ROM" Adding a reference to the expected RAM
and ROM would be good. https://ieeexplore.ieee.org/document/6970748/
provides an estimation of <2kB of minimum RAM and <30kB = of minimum ROM
for common IoT OSs.

[197], hoping anyone has more = reliable numbers than I do.

ACK



Thanks again; I'll follow up as the referenced issues bear = fruit
Christian

[190]: https://github.com/core-wg/resource-directory/issues/190[191]: https://github.com/core-wg/resource-directory/issues/191[193]: https://github.com/core-wg/resource-directory/issues/193[194]: https://github.com/core-wg/resource-directory/issues/194[195]: https://github.com/core-wg/resource-directory/issues/195[196]: https://github.com/core-wg/resource-directory/issues/196[197]: https://github.com/core-wg/resource-directory/issues/197


Thanks a lot to you for = the quick reply and for the great work!

--
To use raw power is to make yourself = infinitely vulnerable to greater powers.
 -- Bene = Gesserit axiom

= --Apple-Mail=_A1F3E7C4-2412-45F6-9E13-509BE59207EB-- --Apple-Mail=_5353BA3A-BAD9-4EAB-AFD5-5A450CD04835 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE5MDMwMTEyMDUwNlowIwYJKoZIhvcNAQkEMRYEFMFTanQmYrNktYb7PRTM290+KuC+ MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEASYammwuDooUtox8bFo6UXZin7EwDqAdsTLO4b5iCgi/nQqzY2BrLLUuLA8n3qANa wTA6AmzLQ1xYTFpXOArg4Vuv7tgYKhCdWSzAKmE5VsNIgZw9e4gy06188Poy2MT6FeKdAacUHbBx DtmBJaypkSyPPRL5eN8tCq0RreIn0v9zN0736rUXwAJrXrAeaw6KnPwPcrMtvQABD9f/uLdwtmZL ByRMxTDKJa3RN+R43zwH/j78suzsRj7QNnTq6QyAoAMmJk+4g/FwP/6eKOTUwhvv5Na3TMVwYjly Haj7UsdwjVcZ1F2mUwfsTOXKesQ1t+0GIbK8SnKctVOzJ437owAAAAAAAA== --Apple-Mail=_5353BA3A-BAD9-4EAB-AFD5-5A450CD04835-- From nobody Fri Mar 1 07:37:08 2019 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 8824B130E7F; Fri, 1 Mar 2019 07:37:00 -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.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155145462049.6195.1822279980793702684@ietfa.amsl.com> Date: Fri, 01 Mar 2019 07:37:00 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-stateless-00.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: Fri, 01 Mar 2019 15:37:01 -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 : Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) Author : Klaus Hartke Filename : draft-ietf-core-stateless-00.txt Pages : 16 Date : 2019-03-01 Abstract: This document provides considerations for alleviating CoAP clients and intermediaries of maintaining per-request state. Additionally, it introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-stateless/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-stateless-00 https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 1 13:15:49 2019 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 1AEFD13122F; Fri, 1 Mar 2019 13:10:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: core@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147461010.6101.731730006888968824.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:10 -0800 Archived-At: Subject: [core] core - Requested sessions have been scheduled for IETF 104 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:10:24 -0000 Dear Carsten Bormann, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. core Session 1 (1:30 requested) Tuesday, 26 March 2019, Afternoon Session I 1350-1550 Room Name: Berlin/Brussels size: 100 --------------------------------------------- core Session 2 (1:30 requested) Friday, 29 March 2019, Morning Session I 0900-1030 Room Name: Congress Hall 3 size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/core.ics Request Information: --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: cose cbor ace suit httpbis artarea t2trg lpwan rats Second Priority: saag secdispatch sacm teep irtfopen 6tisch 6lo roll Third Priority: lwig detnet quic v6ops opsarea cfrg icnrg dnssd netconf netmod emu People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Special Requests: Plse lso avd any potntlly IoT reltd BOFs&PRGs (e.g., coin) tht mght cme up. Prefer some time between the two meetings (48 h or more). Responsible AD *might* change to Barry Leiba before the meeting. --------------------------------------------------------- From nobody Fri Mar 1 18:16:13 2019 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 A7403126D00; Fri, 1 Mar 2019 18:15:56 -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, 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 X7BDtjqO8uTP; Fri, 1 Mar 2019 18:15:53 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13EF129284; Fri, 1 Mar 2019 18:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x222FeOa008142; Sat, 2 Mar 2019 03:15:46 +0100 (CET) Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44B8yh472nz1Bp8; Sat, 2 Mar 2019 03:15:40 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 2 Mar 2019 03:15:37 +0100 Message-Id: <932D3C6C-E9F7-4B9D-B335-4B43ADA0936C@tzi.org> To: ace , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF104: FINAL AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 02:15:57 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF104. Remember that, even though this will now go to the printers, there is still some potential for changes. The somewhat annoying coflicts cose/teep and lpwan/t2trg remain. I also don't like that I'll have to miss the cacao BOF (vs. core), dinrg/suit, coinrg/git. rats has been swapped against the paw/saag conflict. All times are CET (Central European Time) =3D=3D UTC +1 hours. Note = that there is no daylight saving time in effect at the time in Europe (this starts on the Sunday *after* IETF). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, March 22, 2019 -- Fri 0930=E2=80=931830 T2TRG Work Meeting -- Istanbul room SATURDAY/SUNDAY, March 23/24. 2019 -- Hackathon (including various interops) (Grand Hilton Ballroom) -- Sun 1700-1900 Welcome Reception - Congress Hall 1/2 -- Sun 1800-2000 Hot RFC Lightning Talks - Congress Hall 3 MONDAY, March 25, 2019 0900-1100 Morning Session I Congress H 3 ART dispatch Dispatch WG - Joint with ARTAREA Congress H 2 INT 6man IPv6 Maintenance WG Congress H 1 IRTF pearg Privacy Enhancements and Assessments = Proposed Research Group Karlin 3 RTG bier Bit Indexed Explicit Replication WG 1120-1220 Morning Session II Congress H 3 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Karlin 3 RTG bier Bit Indexed Explicit Replication WG Congress H 2 SEC tls Transport Layer Security WG Karlin 1/2 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1350-1550 Afternoon Session I Karlin 1/2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Congress H 2 IRTF irtfopen IRTF Open Meeting Congress H 3 SEC secdispatch Security Dispatch WG 1610-1810 Afternoon Session II Congress H 2 ART httpbis Hypertext Transfer Protocol WG Congress H 3 IAB smart Stopping Malware and Researching Threats Berlin/Brussels INT dnssd Extensions for Scalable DNS Service = Discovery WG Grand BR IRTF qirg Quantum Internet Proposed Research Group Karlin 3 RTG *** roll Routing Over Low power and Lossy = networks WG Athens/Barcel. SEC oauth Web Authorization Protocol WG Congress H 1 TSV tsvwg Transport Area Working Group WG TUESDAY, March 26, 2019 0900-1100 Morning Session I Karlin 3 ART uta Using TLS in Applications WG - 1000 - = 1100 Grand BR INT homenet Home Networking WG Berlin/Brussels SEC *** cose CBOR Object Signing and Encryption WG Karlin 1/2 SEC *** teep Trusted Execution Environment = Provisioning WG Congress H 2 TSV quic QUIC WG 1120-1220 Morning Session II Athens/Barcel. INT *** lwig Light-Weight Implementation Guidance WG Congress H 1 IRTF qirg Quantum Internet Proposed Research Group Congress H 3 TSV tsvwg Transport Area Working Group WG 1350-1550 Afternoon Session I Berlin/Brussels ART *** core Constrained RESTful Environments WG Karlin 1/2 OPS anima Autonomic Networking Integrated Model = and Approach WG Congress H 1 SEC mls Messaging Layer Security WG Congress H 3 TSV tsvarea Transport Area Open Meeting 1610-1810 Afternoon Session II Grand BR INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Congress H 1 IRTF*** t2trg Thing-to-Thing Congress H 2 SEC tls Transport Layer Security WG WEDNESDAY, March 27, 2019 0900-1100 Morning Session I Karlin 1/2 IRTF*** dinrg Decentralized Internet Infrastructure Congress H 1 RTG detnet Deterministic Networking WG Grand BR RTG rift Routing In Fat Trees WG Congress H 3 SEC *** suit Software Updates for Internet of Things = WG Congress H 2 TSV quic QUIC WG 1120-1320 Morning Session II Grand BR IRTF cfrg Crypto Forum - 12:20 - 13:20 Grand BR SEC acme Automated Certificate Management = Environment WG - 11:20 - 12:20 1500-1700 Afternoon Session I Grand BR OPS wgtlgo Technology Deep Dive - Modern Router = Architecture BOF THURSDAY, March 28, 2019 0900-1030 Morning Session I Karlin 3 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Congress H 3 IRTF panrg Path Aware Networking RG Athens/Barcel. RTG babel Babel routing protocol WG Congress H 1 SEC mls Messaging Layer Security WG Berlin/Brussels SEC oauth Web Authorization Protocol WG 1050-1220 Morning Session II Congress H 3 GEN git GitHub Integration and Tooling WG Congress H 1 IRTF coinrg Computing in the Network Congress H 2 IRTF maprg Measurement and Analysis for Protocols 1350-1550 Afternoon Session I Congress H 3 ART httpbis Hypertext Transfer Protocol WG Grand BR INT *** paw Predictable and Available Wireless BOF Athens/Barcel. OPS v6ops IPv6 Operations WG Congress H 1 SEC saag Security Area Open Meeting 1610-1810 Afternoon Session II Athens/Barcel. INT intarea Internet Area Working Group WG Grand BR SEC *** rats Remote ATtestation ProcedureS BOF FRIDAY, March 29, 2019 0900-1030 Morning Session I Grand BR ART *** core Constrained RESTful Environments WG Congress H 1 INT 6man IPv6 Maintenance WG Berlin/Brussels SEC cacao Collaborative Automated Course of Action = Operations for Cyber Security BOF 1050-1250 Morning Session II Berlin/Brussels INT ipwave IP Wireless Access in Vehicular = Environments WG Karlin 1/2 IRTF icnrg Information-Centric Networking Congress H 1 SEC *** ace Authentication and Authorization for = Constrained Environments WG Athens/Barcel. TSV taps Transport Services WG From nobody Sat Mar 2 14:05:44 2019 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 373A8128B33; Sat, 2 Mar 2019 14:05:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am9r_lic-MH8; Sat, 2 Mar 2019 14:05:40 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0: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 3568B130DFA; Sat, 2 Mar 2019 14:05:40 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id u9so683098pgo.7; Sat, 02 Mar 2019 14:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tnICRt0xnn+k/hyQUoWWF840r7Y39K8pMZMjT0pHI6g=; b=W877yNZBlhsyvKyksxUQJlP/aByvU3H5jw5PGRDD/esCVWEmVyOiuLCAnsSLrWkJ37 Z8/VIdbSRlVAgOdOcHTZXvU8SqpnzXEjCTifTEY/f63WwW2GX7SmL5+nWyQms8Xvj0n+ 8u0QfofnCK05L6367HgYZ+5Vtr326ftbYi2qVDvcgVoC7yrz7wWtjcYDdvuBN1BohYj5 RyyaNlku9BgeyAgsEjpcxNPCOPli+bXCTp9tsOQ5ZrQG/d65TA6M1q+3QN9rxGXJLgjC Qc8lhsk7T2riARwp5nRqC0NoJOz8hsvHPSEenw0nPAaKoCahGo7XGPPtbo2vwQMK/Dxc 5AGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tnICRt0xnn+k/hyQUoWWF840r7Y39K8pMZMjT0pHI6g=; b=ALMI//jf11Eu+bTXwOVb2iv75coXGIkLfzUSI0+cG/g584vU2zJ4s5lypALSieDUX2 yEBZY6RYVMtPUMcw9/WDVGaokTrk13UTe1s5NkiV1K5UKnoR27zSWZKv2D4ErkpLiN0t ahreBRzTKJ4byOiN44SwBgfAtUFBGzH5RUl3SagQ9dAa8Yafvnrbbi2ZZxyOkt9sMvse IX09yw6Uzqp946HM1SHLzMAgIkT/Rc8dFJxA7owS5HyQrkqnfJRpVdlsdiqXClP/JY4l NMWKdCho0gAj6eHdtS6u95XzKUYRL1hc79Mq9ZhYGbi+7Vf+uoUbJ65PtO+MteJZjqJf psYQ== X-Gm-Message-State: AHQUAubVNONQOF6r3Xud5B/uLrOhwd9iymWYz8uLWqzvsS8CUZQ2XhKv mB4KUzRrAI1s5aHB+t122e0= X-Google-Smtp-Source: AHgI3IaGBxFoU1K/yd1+fX/bKCc2IJUZaqQfwzaQficwtptgvsYknAqM6lur0ob1T/HxrUK5ButLwA== X-Received: by 2002:a62:b508:: with SMTP id y8mr12655172pfe.140.1551564339196; Sat, 02 Mar 2019 14:05:39 -0800 (PST) Received: from [172.16.0.3] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id u28sm3017677pgn.32.2019.03.02.14.05.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Mar 2019 14:05:38 -0800 (PST) From: Michael Koster Message-Id: <1D9AA506-85CB-452E-B0DC-4BC099E04F58@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E62B8033-2E77-4119-9149-BA967D2CD9C9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 2 Mar 2019 14:05:35 -0800 In-Reply-To: <026901d4c8df$e2251410$a66f3c30$@augustcellars.com> Cc: Thomas Fossati , draft-ietf-core-multipart-ct@ietf.org, "core@ietf.org WG" , Klaus Hartke , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , =?utf-8?Q?Ari_Ker=C3=A4nen?= To: Jim Schaad References: <000901d4c2f8$4b69a640$e23cf2c0$@augustcellars.com> <00f901d4c624$f313cb30$d93b6190$@augustcellars.com> <026901d4c8df$e2251410$a66f3c30$@augustcellars.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-multipart-ct 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, 02 Mar 2019 22:05:43 -0000 --Apple-Mail=_E62B8033-2E77-4119-9149-BA967D2CD9C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I am integrating multipart into pub/sub as a way to signal empty = payloads that might result from a subscribe operation where their aren't = any stored data (stale or non-retaining topic) or a retrieve in the same = case. We have decided initially not to support multiple content formats on a = topic in pub/sub,where the proker would have to convert, but now it = might be a little easier with multipart, if we build in a subtyping = system as per Jim's email.=20 IMO the subtype target attribute at least will be necessary for the kind = of discovery we want to support in pub/sub. I guess subtype accept = header option is going to be needed also, so a pub/sub client can = indicate it accepts emty payload format and e.g. senml. In general I think this can work for the pub/sub use case and will write = it in if it makes sense. Best regards, Michael > On Feb 19, 2019, at 9:48 PM, Jim Schaad = wrote: >=20 > I did think about some of this when I put up the proposal. > =20 > For case (A), unless it is going to have options while doing a rigidly = structured response, there is no need to have a value different than = Accept 62. In fact if there is really only one structured response, = then there is not a need to have any accept option in the request at = all. > =20 > For case (B), I thought about the recursive case and that is why I put = the SHOULD and talked about options between multiple things while = building the response. I don=E2=80=99t think that there are going to be = enough cases of a tree structure being returned that anything needs to = be said about it one way or the other. If that type of detail is really = needed then I would expect that a GET would be replaced by a POST with = the details of the response needed in the content of the POST. > =20 > In the semantics, I wanted to provide a minimal amount of information. = Thus the language about using it to provide guidance for specific pairs = of content types that can go into a specific location. The other place = that I was thinking it might be useful would be in the case of a PUB-SUB = server returning multiple content types where the set of equivalents = might be restricted to the requested values rather than returning all = possibilities. > =20 > Jim > =20 > =20 > From: Thomas Fossati =20 > Sent: Tuesday, February 19, 2019 1:58 AM > To: Jim Schaad > Cc: Klaus Hartke ; = draft-ietf-core-multipart-ct@ietf.org; core@ietf.org > Subject: Re: [core] draft-ietf-core-multipart-ct > =20 > It has surfaced in the mailing list as well as in private exchanges = that there are two ways of looking at multipart-ct: > (A) as a mechanism to wrap multiple related things in a rigidly = structured way; > (B) as a mechanism to aggregate related thingsin flexible ways (e.g., = the EST-coaps credentials). >=20 > One approach to content negotiation for multiparts of kind (A) is to = assign the aggregate a separate type altogether (overriding C-F 62 with = something allocated on purpose from the FCFS portion of the codepoint = space). This fits Accept=E2=80=99s semantics well. >=20 > Content negotiation with multiparts of kind (B) needs something like = Jim=E2=80=99s proposal. The slight complication that potentially breaks = Jim=E2=80=99s approach is recursion. >=20 > To support this, I think the draft could say: > - multiparts of kind (A) SHOULD override the multipart C-F with their = own; and > - multiparts of kind (B) MUST not include other multiparts of the same = =E2=80=9Ckind=E2=80=9D. >=20 > The above would make a recursive multipart (i.e., a 62 embedded in = another 62) illegal and give Jim=E2=80=99s new content negotiation a = well-defined semantics. >=20 > Cheers >=20 > On Sat, Feb 16, 2019 at 6:25 PM Jim Schaad > wrote: > > > > Looking at this, it does seem to be a strange way to deal with = things. Of course the problem is made even more of a pain if you think = about the possibility of having nested multipart contents. > > > > While the following does may not be the greatest solution, I think = that it might be a better answer: > > > > 1. Define a new target attribute: "mt-subtypes" which contains the = list of any content type which can be returned in a multipart content. = This could be at the top level or anyplace in a tree. > > > > 2. Define a new option: "mt-accept" which contains the list of = sub-content types that the client can deal with. This option would be = defined as advisory on the part of the server, that is it can return = content types which are not in the list, but where options exist in the = possible returned content tree the requested types, in order, SHOULD be = the ones chosen by the server. I would propose the option be = "Non-Critical, Safe, CacheKey, Repeatable". > > > > I am not sure if I believe that the new option is part of the cache = key or not. I can see arguments on both sides, but I think I come down = to yes. > > > > Carsten, I think that this issue (but maybe not this solution) = needs to be put onto the agenda for the interim meeting next Wed. > > > > Jim > > > > > > > -----Original Message----- > > > From: Klaus Hartke > > > > Sent: Tuesday, February 12, 2019 9:50 AM > > > To: Jim Schaad > > > > Cc: draft-ietf-core-multipart-ct@ietf.org = ; core@ietf.org = WG > > > > Subject: Re: [core] draft-ietf-core-multipart-ct > > > > > > For context: [1] [2] > > > > > > Jim Schaad wrote: > > > > If you say ACCEPT 62, do you accept any combination of nested = content > > > types? > > > > > > Yes. A CoAP request can include at most one Accept option and any = response > > > must exactly that value as Content-Format or be an error response. = CoAP > > > doesn't have a mechanism for negotiating the content formats of > > > representations embedded in other representations. I stumbled upon = the > > > same problem with CoRAL. > > > > > > > Should something about this be placed into the draft? > > > > > > Yes. Proposed text: "CoAP doesn't have a mechanism for negotiating = the > > > content formats of representations embedded in = application/multipart-core > > > representations." > > > > > > > Also I note that this draft is currently expired and needs to be = reposted. > > > > > > Yes. Soon=E2=84=A2. > > > > > > Klaus > > > > > > [1] > > > = https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFDu6dcm = > > > I > > > [2] = https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui3Gkllk = > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core = >=20 > --=20 > Thomas > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_E62B8033-2E77-4119-9149-BA967D2CD9C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I am = integrating multipart into pub/sub as a way to signal empty payloads = that might result from a subscribe operation where their aren't any = stored data (stale or non-retaining topic) or a retrieve in the same = case.

We have = decided initially not to support multiple content formats on a topic in = pub/sub,where the proker would have to convert, but now it might be a = little easier with multipart, if we build in a subtyping system as per = Jim's email. 

IMO the subtype target attribute at least will be necessary = for the kind of discovery we want to support in pub/sub. I guess subtype = accept header option is going to be needed also, so a pub/sub client can = indicate it accepts emty payload format and e.g. senml.

In general I think this = can work for the pub/sub use case and will write it in if it makes = sense.

Best = regards,

Michael


On Feb 19, 2019, at 9:48 PM, = Jim Schaad <ietf@augustcellars.com> wrote:

I did think about some of this when I put up the = proposal.
 
For case (A), unless it is going to have options while doing = a rigidly structured response, there is no need to have a value = different than Accept 62.  In fact if there is really only one = structured response, then there is not a need to have any accept option = in the request at all.
 
For case (B), I thought about the recursive case and that is = why I put the SHOULD and talked about options between multiple things = while building the response.  I don=E2=80=99t think that there are = going to be enough cases of a tree structure being returned that = anything needs to be said about it one way or the other.  If that = type of detail is really needed then I would expect that a GET would be = replaced by a POST with the details of the response needed in the = content of the POST.
 
In the semantics, I wanted to provide a minimal amount of = information.  Thus the language about using it to provide guidance = for specific pairs of content types that can go into a specific = location.  The other place that I was thinking it might be useful = would be in the case of a PUB-SUB server returning multiple content = types where the set of equivalents might be restricted to the requested = values rather than returning all possibilities.
 
Jim
 
 
From: Thomas Fossati <tho.ietf@gmail.com> 
Sent: Tuesday, February 19, 2019 = 1:58 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Klaus= Hartke <hartke@projectcool.de>; draft-ietf-core-multipart-ct@ietf.org; core@ietf.org
Subject: Re: [core] = draft-ietf-core-multipart-ct
 
It has surfaced in the = mailing list as well as in private exchanges that there are two ways of = looking at multipart-ct:
(A) as a mechanism to wrap = multiple related things in a rigidly structured way;
(B) = as a mechanism to aggregate related thingsin flexible ways (e.g., the = EST-coaps credentials).

One approach to = content negotiation for multiparts of kind (A) is to assign the = aggregate a separate type altogether (overriding C-F 62 with something = allocated on purpose from the FCFS portion of the codepoint = space).  This fits Accept=E2=80=99s semantics well.
Content negotiation with multiparts of kind (B) needs = something like Jim=E2=80=99s proposal.  The slight complication = that potentially breaks Jim=E2=80=99s approach is recursion.

To support this, I think the draft could = say:
- multiparts of kind (A) SHOULD override the = multipart C-F with their own; and
- multiparts of kind (B) = MUST not include other multiparts of the same =E2=80=9Ckind=E2=80=9D.

The above would make a recursive multipart = (i.e., a 62 embedded in another 62) illegal and give Jim=E2=80=99s new = content negotiation a well-defined semantics.

Cheers

On Sat, Feb 16, 2019 at = 6:25 PM Jim Schaad <ietf@augustcellars.com> wrote:
>
> Looking at this, it does seem to be a strange way to = deal with things.  Of course the problem is made even more of a = pain if you think about the possibility of having nested multipart = contents.
>
> While the following does = may not be the greatest solution, I think that it might be a better = answer:
>
> 1.  Define a new = target attribute:  "mt-subtypes" which contains the list of any = content type which can be returned in a multipart content.  This = could be at the top level or anyplace in a tree.
>
> 2.  Define a new option: "mt-accept" which contains = the list of sub-content types that the client can deal with.  This = option would be defined as advisory on the part of the server, that is = it can return content types which are not in the list, but where options = exist in the possible returned content tree the requested types, in = order, SHOULD be the ones chosen by the server.   I would propose = the option be "Non-Critical, Safe, CacheKey, Repeatable".
>
> I am not sure if I believe that the = new option is part of the cache key or not.  I can see arguments on = both sides, but I think I come down to yes.
>
> Carsten,   I think that this issue (but maybe not = this solution) needs to be put onto the agenda for the interim meeting = next Wed.
>
> Jim
>
>
> > -----Original Message-----
> > From: Klaus Hartke <hartke@projectcool.de>
> > Sent: Tuesday, February 12, 2019 9:50 AM
> > To: Jim Schaad <ietf@augustcellars.com>
> > Cc: draft-ietf-core-multipart-ct@ietf.org; core@ietf.org WG <core@ietf.org>
> > = Subject: Re: [core] draft-ietf-core-multipart-ct
> = >
> > For context: [1] [2]
> = >
> > Jim Schaad wrote:
> > = > If you say ACCEPT 62, do you accept any combination of nested = content
> > types?
> >
> > Yes. A CoAP request can include at most one Accept = option and any response
> > must exactly that value = as Content-Format or be an error response. CoAP
> > = doesn't have a mechanism for negotiating the content formats of
> > representations embedded in other representations. = I stumbled upon the
> > same problem with CoRAL.
> >
> > > Should something about = this be placed into the draft?
> >
> = > Yes. Proposed text: "CoAP doesn't have a mechanism for negotiating = the
> > content formats of representations embedded = in application/multipart-core
> > = representations."
> >
> > > = Also I note that this draft is currently expired and needs to be = reposted.
> >
> > Yes. = Soon=E2=84=A2.
> >
> > Klaus
> >
> > [1]
> = > https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFD= u6dcm
> > I
> > [2] https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui= 3Gkllk
>
> = _______________________________________________
> core = mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

-- 
Thomas
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_E62B8033-2E77-4119-9149-BA967D2CD9C9-- From nobody Sat Mar 2 14:14:33 2019 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 10E32130DFA; Sat, 2 Mar 2019 14:14:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffXoxT21T596; Sat, 2 Mar 2019 14:14:28 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 E99B1128B33; Sat, 2 Mar 2019 14:14:27 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id v11so671046plg.9; Sat, 02 Mar 2019 14:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FPeTZqnQ3kzOktoCFtnY7f+KgWETUiPx3FzB7kAIxm4=; b=jDoFFClWS+WRy+S/HuX4YehfnB1zak+EHVR8/2m3d8hOtjlCMXQJCMX6AkomUGyHmn ZUjomc6doRVY0XXbjcUR8gsPLwjm4d0NKy/jB+E4sNQdBtTMDEdLIug99SL/o74HpZJX EuYyuXjFQJn5fSs14X3Bs8K0RZAf6MuSngtvrZvzN6d0ntanojtM81NrRKEaWJT9++Jk MqHwNIw0617XR3qbRRqNYrhvUakWLQAGEnAweVxVFCP7e8sTzw0v3n6D1FHQGekLjJ29 nzj6Mjlh8ptQ0pGCvN7Bij2ofmROm9vXSx2p350k9+j5b8fAEPd8s+WTumDLUZls/DVu fCXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FPeTZqnQ3kzOktoCFtnY7f+KgWETUiPx3FzB7kAIxm4=; b=omXKNVqVf6VdcuKXp875qrxRPSlMaD3OUmWMg6jt8E1LR9XhIYPNwaZg3omnuXsmK8 OgkHu0GqU2jheZQCwwnirepH59tC+dTJMl9Qqs29VuTlQ8UdCKM6bfyECDOUUY6TBqup eGwpE/RJmRer9Y8IKOpFCLgHFGVlnaEE5dQakTYnsVdRJWLY7Z1q01Ka/ud0KcckDuJM h3MnQThdZN2A2f1DRduYyer4KLpthDT+t6SZXXutGtn9aEH3CuKbmz+sZqkCZNq50XX3 PQ0ixqeT/lkkIWoKEhIo2k3PeRW+Qm6OEoEAYG2TxHiKBv9cNLtVcNDLftcHJwRSpXqO cctw== X-Gm-Message-State: APjAAAUGYaNYNLnh3kLeTH6GEbHUYtyGC2/YgkYjp9xVyhT1npl0toqa 0aAbnF01iyy8rl8sc9wmEEo= X-Google-Smtp-Source: APXvYqxL5kqdqTtvYw4Pdc0D15llbUcRUCRNtyGhXgwMTjEh9yJvoe2IntFhV2j/t/PkQzvgbn75bg== X-Received: by 2002:a17:902:7b85:: with SMTP id w5mr12742284pll.288.1551564867004; Sat, 02 Mar 2019 14:14:27 -0800 (PST) Received: from [172.16.0.3] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id j20sm2469974pfh.141.2019.03.02.14.14.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Mar 2019 14:14:26 -0800 (PST) From: Michael Koster Message-Id: <47DAEE52-702A-40C0-9F7C-589CBD0D1C73@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AC0E1FBE-6610-4CE2-B4DB-F9CE08954977" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 2 Mar 2019 14:14:24 -0800 In-Reply-To: <1D9AA506-85CB-452E-B0DC-4BC099E04F58@gmail.com> Cc: Thomas Fossati , draft-ietf-core-multipart-ct@ietf.org, "core@ietf.org WG" , Klaus Hartke , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , =?utf-8?Q?Ari_Ker=C3=A4nen?= To: Jim Schaad References: <000901d4c2f8$4b69a640$e23cf2c0$@augustcellars.com> <00f901d4c624$f313cb30$d93b6190$@augustcellars.com> <026901d4c8df$e2251410$a66f3c30$@augustcellars.com> <1D9AA506-85CB-452E-B0DC-4BC099E04F58@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-multipart-ct 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, 02 Mar 2019 22:14:31 -0000 --Apple-Mail=_AC0E1FBE-6610-4CE2-B4DB-F9CE08954977 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To follow on a little, the pub/sub use case is for a variable format = response (case C?) that is a better alternative than adding a new result = code (2.xx) for "no data". There is another use case (like case B) which is for a generalized = hypermedia format that can return links, data, or both depending on the = client workflow. This would eliminate the need for a new content format = like HSML, and would allow arbitrary data formats to be associated with = core-link-format in batch-access collections as per CoRE Interfaces. Best regards, Michael > On Mar 2, 2019, at 2:05 PM, Michael Koster = wrote: >=20 > Hi, >=20 > I am integrating multipart into pub/sub as a way to signal empty = payloads that might result from a subscribe operation where their aren't = any stored data (stale or non-retaining topic) or a retrieve in the same = case. >=20 > We have decided initially not to support multiple content formats on a = topic in pub/sub,where the proker would have to convert, but now it = might be a little easier with multipart, if we build in a subtyping = system as per Jim's email.=20 >=20 > IMO the subtype target attribute at least will be necessary for the = kind of discovery we want to support in pub/sub. I guess subtype accept = header option is going to be needed also, so a pub/sub client can = indicate it accepts emty payload format and e.g. senml. >=20 > In general I think this can work for the pub/sub use case and will = write it in if it makes sense. >=20 > Best regards, >=20 > Michael >=20 >=20 >> On Feb 19, 2019, at 9:48 PM, Jim Schaad > wrote: >>=20 >> I did think about some of this when I put up the proposal. >> =20 >> For case (A), unless it is going to have options while doing a = rigidly structured response, there is no need to have a value different = than Accept 62. In fact if there is really only one structured = response, then there is not a need to have any accept option in the = request at all. >> =20 >> For case (B), I thought about the recursive case and that is why I = put the SHOULD and talked about options between multiple things while = building the response. I don=E2=80=99t think that there are going to be = enough cases of a tree structure being returned that anything needs to = be said about it one way or the other. If that type of detail is really = needed then I would expect that a GET would be replaced by a POST with = the details of the response needed in the content of the POST. >> =20 >> In the semantics, I wanted to provide a minimal amount of = information. Thus the language about using it to provide guidance for = specific pairs of content types that can go into a specific location. = The other place that I was thinking it might be useful would be in the = case of a PUB-SUB server returning multiple content types where the set = of equivalents might be restricted to the requested values rather than = returning all possibilities. >> =20 >> Jim >> =20 >> =20 >> From: Thomas Fossati >=20= >> Sent: Tuesday, February 19, 2019 1:58 AM >> To: Jim Schaad > >> Cc: Klaus Hartke >; draft-ietf-core-multipart-ct@ietf.org = ; core@ietf.org = >> Subject: Re: [core] draft-ietf-core-multipart-ct >> =20 >> It has surfaced in the mailing list as well as in private exchanges = that there are two ways of looking at multipart-ct: >> (A) as a mechanism to wrap multiple related things in a rigidly = structured way; >> (B) as a mechanism to aggregate related thingsin flexible ways (e.g., = the EST-coaps credentials). >>=20 >> One approach to content negotiation for multiparts of kind (A) is to = assign the aggregate a separate type altogether (overriding C-F 62 with = something allocated on purpose from the FCFS portion of the codepoint = space). This fits Accept=E2=80=99s semantics well. >>=20 >> Content negotiation with multiparts of kind (B) needs something like = Jim=E2=80=99s proposal. The slight complication that potentially breaks = Jim=E2=80=99s approach is recursion. >>=20 >> To support this, I think the draft could say: >> - multiparts of kind (A) SHOULD override the multipart C-F with their = own; and >> - multiparts of kind (B) MUST not include other multiparts of the = same =E2=80=9Ckind=E2=80=9D. >>=20 >> The above would make a recursive multipart (i.e., a 62 embedded in = another 62) illegal and give Jim=E2=80=99s new content negotiation a = well-defined semantics. >>=20 >> Cheers >>=20 >> On Sat, Feb 16, 2019 at 6:25 PM Jim Schaad > wrote: >> > >> > Looking at this, it does seem to be a strange way to deal with = things. Of course the problem is made even more of a pain if you think = about the possibility of having nested multipart contents. >> > >> > While the following does may not be the greatest solution, I think = that it might be a better answer: >> > >> > 1. Define a new target attribute: "mt-subtypes" which contains = the list of any content type which can be returned in a multipart = content. This could be at the top level or anyplace in a tree. >> > >> > 2. Define a new option: "mt-accept" which contains the list of = sub-content types that the client can deal with. This option would be = defined as advisory on the part of the server, that is it can return = content types which are not in the list, but where options exist in the = possible returned content tree the requested types, in order, SHOULD be = the ones chosen by the server. I would propose the option be = "Non-Critical, Safe, CacheKey, Repeatable". >> > >> > I am not sure if I believe that the new option is part of the cache = key or not. I can see arguments on both sides, but I think I come down = to yes. >> > >> > Carsten, I think that this issue (but maybe not this solution) = needs to be put onto the agenda for the interim meeting next Wed. >> > >> > Jim >> > >> > >> > > -----Original Message----- >> > > From: Klaus Hartke > >> > > Sent: Tuesday, February 12, 2019 9:50 AM >> > > To: Jim Schaad > >> > > Cc: draft-ietf-core-multipart-ct@ietf.org = ; core@ietf.org = WG > >> > > Subject: Re: [core] draft-ietf-core-multipart-ct >> > > >> > > For context: [1] [2] >> > > >> > > Jim Schaad wrote: >> > > > If you say ACCEPT 62, do you accept any combination of nested = content >> > > types? >> > > >> > > Yes. A CoAP request can include at most one Accept option and any = response >> > > must exactly that value as Content-Format or be an error = response. CoAP >> > > doesn't have a mechanism for negotiating the content formats of >> > > representations embedded in other representations. I stumbled = upon the >> > > same problem with CoRAL. >> > > >> > > > Should something about this be placed into the draft? >> > > >> > > Yes. Proposed text: "CoAP doesn't have a mechanism for = negotiating the >> > > content formats of representations embedded in = application/multipart-core >> > > representations." >> > > >> > > > Also I note that this draft is currently expired and needs to = be reposted. >> > > >> > > Yes. Soon=E2=84=A2. >> > > >> > > Klaus >> > > >> > > [1] >> > > = https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFDu6dcm = >> > > I >> > > [2] = https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui3Gkllk = >> > >> > _______________________________________________ >> > core mailing list >> > core@ietf.org >> > https://www.ietf.org/mailman/listinfo/core = >>=20 >> --=20 >> Thomas >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_AC0E1FBE-6610-4CE2-B4DB-F9CE08954977 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To follow on a little, the pub/sub use case is for a variable = format response (case C?) that is a better alternative than adding a new = result code (2.xx) for "no data".

There is another use case (like case B) which is for a = generalized hypermedia format that can return links, data, or both = depending on the client workflow. This would eliminate the need for a = new content format like HSML, and would allow arbitrary data formats to = be associated with core-link-format in batch-access collections as per = CoRE Interfaces.

Best regards,

Michael

On Mar 2, 2019, at 2:05 PM, = Michael Koster <michaeljohnkoster@gmail.com> wrote:

Hi,

I am integrating = multipart into pub/sub as a way to signal empty payloads that might = result from a subscribe operation where their aren't any stored data = (stale or non-retaining topic) or a retrieve in the same case.

We have decided = initially not to support multiple content formats on a topic in = pub/sub,where the proker would have to convert, but now it might be a = little easier with multipart, if we build in a subtyping system as per = Jim's email. 

IMO the subtype target attribute at least will be necessary = for the kind of discovery we want to support in pub/sub. I guess subtype = accept header option is going to be needed also, so a pub/sub client can = indicate it accepts emty payload format and e.g. senml.

In general I think this = can work for the pub/sub use case and will write it in if it makes = sense.

Best = regards,

Michael


On Feb = 19, 2019, at 9:48 PM, Jim Schaad <ietf@augustcellars.com> wrote:

I did think about some of this when I put up the = proposal.
 
For case (A), unless it is going to have options while doing = a rigidly structured response, there is no need to have a value = different than Accept 62.  In fact if there is really only one = structured response, then there is not a need to have any accept option = in the request at all.
 
For case (B), I thought about the recursive case and that is = why I put the SHOULD and talked about options between multiple things = while building the response.  I don=E2=80=99t think that there are = going to be enough cases of a tree structure being returned that = anything needs to be said about it one way or the other.  If that = type of detail is really needed then I would expect that a GET would be = replaced by a POST with the details of the response needed in the = content of the POST.
 
In the semantics, I wanted to provide a minimal amount of = information.  Thus the language about using it to provide guidance = for specific pairs of content types that can go into a specific = location.  The other place that I was thinking it might be useful = would be in the case of a PUB-SUB server returning multiple content = types where the set of equivalents might be restricted to the requested = values rather than returning all possibilities.
 
Jim
 
 
From: Thomas Fossati <tho.ietf@gmail.com> 
Sent: Tuesday, February 19, 2019 = 1:58 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Klaus= Hartke <hartke@projectcool.de>; draft-ietf-core-multipart-ct@ietf.org; core@ietf.org
Subject: Re: [core] = draft-ietf-core-multipart-ct
 
It has surfaced in the = mailing list as well as in private exchanges that there are two ways of = looking at multipart-ct:
(A) as a mechanism to wrap = multiple related things in a rigidly structured way;
(B) = as a mechanism to aggregate related thingsin flexible ways (e.g., the = EST-coaps credentials).

One approach to = content negotiation for multiparts of kind (A) is to assign the = aggregate a separate type altogether (overriding C-F 62 with something = allocated on purpose from the FCFS portion of the codepoint = space).  This fits Accept=E2=80=99s semantics well.
Content negotiation with multiparts of kind (B) needs = something like Jim=E2=80=99s proposal.  The slight complication = that potentially breaks Jim=E2=80=99s approach is recursion.

To support this, I think the draft could = say:
- multiparts of kind (A) SHOULD override the = multipart C-F with their own; and
- multiparts of kind (B) = MUST not include other multiparts of the same =E2=80=9Ckind=E2=80=9D.

The above would make a recursive multipart = (i.e., a 62 embedded in another 62) illegal and give Jim=E2=80=99s new = content negotiation a well-defined semantics.

Cheers

On Sat, Feb 16, 2019 at = 6:25 PM Jim Schaad <ietf@augustcellars.com> wrote:
>
> Looking at this, it does seem to be a strange way to = deal with things.  Of course the problem is made even more of a = pain if you think about the possibility of having nested multipart = contents.
>
> While the following does = may not be the greatest solution, I think that it might be a better = answer:
>
> 1.  Define a new = target attribute:  "mt-subtypes" which contains the list of any = content type which can be returned in a multipart content.  This = could be at the top level or anyplace in a tree.
>
> 2.  Define a new option: "mt-accept" which contains = the list of sub-content types that the client can deal with.  This = option would be defined as advisory on the part of the server, that is = it can return content types which are not in the list, but where options = exist in the possible returned content tree the requested types, in = order, SHOULD be the ones chosen by the server.   I would propose = the option be "Non-Critical, Safe, CacheKey, Repeatable".
>
> I am not sure if I believe that the = new option is part of the cache key or not.  I can see arguments on = both sides, but I think I come down to yes.
>
> Carsten,   I think that this issue (but maybe not = this solution) needs to be put onto the agenda for the interim meeting = next Wed.
>
> Jim
>
>
> > -----Original Message-----
> > From: Klaus Hartke <hartke@projectcool.de>
> > Sent: Tuesday, February 12, 2019 9:50 AM
> > To: Jim Schaad <ietf@augustcellars.com>
> > Cc: draft-ietf-core-multipart-ct@ietf.org; core@ietf.org WG <core@ietf.org>
> > = Subject: Re: [core] draft-ietf-core-multipart-ct
> = >
> > For context: [1] [2]
> = >
> > Jim Schaad wrote:
> > = > If you say ACCEPT 62, do you accept any combination of nested = content
> > types?
> >
> > Yes. A CoAP request can include at most one Accept = option and any response
> > must exactly that value = as Content-Format or be an error response. CoAP
> > = doesn't have a mechanism for negotiating the content formats of
> > representations embedded in other representations. = I stumbled upon the
> > same problem with CoRAL.
> >
> > > Should something about = this be placed into the draft?
> >
> = > Yes. Proposed text: "CoAP doesn't have a mechanism for negotiating = the
> > content formats of representations embedded = in application/multipart-core
> > = representations."
> >
> > > = Also I note that this draft is currently expired and needs to be = reposted.
> >
> > Yes. = Soon=E2=84=A2.
> >
> > Klaus
> >
> > [1]
> = > https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFD= u6dcm
> > I
> > [2] https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui= 3Gkllk
>
> = _______________________________________________
> core = mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

-- 
Thomas
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


= --Apple-Mail=_AC0E1FBE-6610-4CE2-B4DB-F9CE08954977-- From nobody Sat Mar 2 15:13:09 2019 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 8E2CC127133; Sat, 2 Mar 2019 15:13:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRoEHc07iVgO; Sat, 2 Mar 2019 15:13:03 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 815ED128D52; Sat, 2 Mar 2019 15:13:03 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id a3so661849pff.11; Sat, 02 Mar 2019 15:13:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jSuZdPhrKBMMCSlhRWzeY+mBLonAt7/KlXbYUjp92go=; b=CCvBHUwAer3W2wcMYf/cZHoQtagRtW9AcsGsWRJU7u8aRjs5fOXrM/BT8OBqUiqMnc /aBLzJD/lnb2++bH2xND8uZ4pO3v6Ta2hCzsG90YLIRZj5JPekOiYb57L763KKcxyr/z HQ54FLzeeO4/+Nnf2TSJKFwEixd9x/jUi9EDUy78trXTUsZ0MXiAyJ2OkBM/OCYzZtOU lUCT0TJSfvKg5UA2EFpuiZNnC8+SHirQP6VTwjPxMD4q/D4JpiIW/Y0xqcXCiDLChJNu zAcI8apCVFeLZT/l4nfQTAYMPLlBr3pKCkIP/ozMuNXrsSPvcDNvo+u7CALmlJz75wfZ ILZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jSuZdPhrKBMMCSlhRWzeY+mBLonAt7/KlXbYUjp92go=; b=OPywHDSkXAv7IcORjJtnzCBOZCjIrD1Y8X8paZQly/8njAKJ7Ij60DwO4oPQUKJbl6 tH0VESOm/AZSwWIMCniRRXqB7V0ADN4H+KAyqXpaahdxITVo5lw4e3QXQXQDGoKfb6bk Kg3vJw9pY2AmOs1XGpcZifxmLV1H4VmjO1Mh91mxyY9d7uh9ZfiHuylIt+krMNVnc55I NsEBmq/rHcn+Sdh3nmuxB2Pti0coIvfkqTKX7y37N5BSCxa1vqkfYRQ3fqDzbiMoCjud 16e+ph+Ezyy01tOPfCrPj5Eehn8aJw6YeHZt91AVTwNnb/5O6GxwWjqvkIxrRkPbXrOm a6mQ== X-Gm-Message-State: APjAAAU0J87KLUfMIkbETNk8bLdXspN6ZMoGdFql8U90nwchHRZeAfpf eSRax3+HpyhGSS9EQtyZAJo= X-Google-Smtp-Source: APXvYqzqyE9JpB36R3l3lKwqa6DMSOFMfkXYyFby2uXH8nmdFtFcMg4cEpfFeoaDCpnjhA3SHV1aPw== X-Received: by 2002:a63:f544:: with SMTP id e4mr11675085pgk.145.1551568382344; Sat, 02 Mar 2019 15:13:02 -0800 (PST) Received: from [172.16.0.3] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id k9sm2747353pfc.57.2019.03.02.15.13.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Mar 2019 15:13:01 -0800 (PST) From: Michael Koster Message-Id: <39D848BF-9B8F-4062-9FF0-B8E7D694F849@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6D30D972-2076-4961-A751-D2D65CB4E152" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 2 Mar 2019 15:12:58 -0800 In-Reply-To: <47DAEE52-702A-40C0-9F7C-589CBD0D1C73@gmail.com> Cc: Thomas Fossati , draft-ietf-core-multipart-ct@ietf.org, "core@ietf.org WG" , Klaus Hartke , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , =?utf-8?Q?Ari_Ker=C3=A4nen?= To: Jim Schaad References: <000901d4c2f8$4b69a640$e23cf2c0$@augustcellars.com> <00f901d4c624$f313cb30$d93b6190$@augustcellars.com> <026901d4c8df$e2251410$a66f3c30$@augustcellars.com> <1D9AA506-85CB-452E-B0DC-4BC099E04F58@gmail.com> <47DAEE52-702A-40C0-9F7C-589CBD0D1C73@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-multipart-ct 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, 02 Mar 2019 23:13:08 -0000 --Apple-Mail=_6D30D972-2076-4961-A751-D2D65CB4E152 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK so if there's no data I send an empty multipart - (cbor x80) Sorry, I'm just getting up to speed. Is the latest draft version -02?=20 Michael > On Mar 2, 2019, at 2:14 PM, Michael Koster = wrote: >=20 > To follow on a little, the pub/sub use case is for a variable format = response (case C?) that is a better alternative than adding a new result = code (2.xx) for "no data". >=20 > There is another use case (like case B) which is for a generalized = hypermedia format that can return links, data, or both depending on the = client workflow. This would eliminate the need for a new content format = like HSML, and would allow arbitrary data formats to be associated with = core-link-format in batch-access collections as per CoRE Interfaces. >=20 > Best regards, >=20 > Michael >=20 >> On Mar 2, 2019, at 2:05 PM, Michael Koster = > = wrote: >>=20 >> Hi, >>=20 >> I am integrating multipart into pub/sub as a way to signal empty = payloads that might result from a subscribe operation where their aren't = any stored data (stale or non-retaining topic) or a retrieve in the same = case. >>=20 >> We have decided initially not to support multiple content formats on = a topic in pub/sub,where the proker would have to convert, but now it = might be a little easier with multipart, if we build in a subtyping = system as per Jim's email.=20 >>=20 >> IMO the subtype target attribute at least will be necessary for the = kind of discovery we want to support in pub/sub. I guess subtype accept = header option is going to be needed also, so a pub/sub client can = indicate it accepts emty payload format and e.g. senml. >>=20 >> In general I think this can work for the pub/sub use case and will = write it in if it makes sense. >>=20 >> Best regards, >>=20 >> Michael >>=20 >>=20 >>> On Feb 19, 2019, at 9:48 PM, Jim Schaad > wrote: >>>=20 >>> I did think about some of this when I put up the proposal. >>> =20 >>> For case (A), unless it is going to have options while doing a = rigidly structured response, there is no need to have a value different = than Accept 62. In fact if there is really only one structured = response, then there is not a need to have any accept option in the = request at all. >>> =20 >>> For case (B), I thought about the recursive case and that is why I = put the SHOULD and talked about options between multiple things while = building the response. I don=E2=80=99t think that there are going to be = enough cases of a tree structure being returned that anything needs to = be said about it one way or the other. If that type of detail is really = needed then I would expect that a GET would be replaced by a POST with = the details of the response needed in the content of the POST. >>> =20 >>> In the semantics, I wanted to provide a minimal amount of = information. Thus the language about using it to provide guidance for = specific pairs of content types that can go into a specific location. = The other place that I was thinking it might be useful would be in the = case of a PUB-SUB server returning multiple content types where the set = of equivalents might be restricted to the requested values rather than = returning all possibilities. >>> =20 >>> Jim >>> =20 >>> =20 >>> From: Thomas Fossati >=20 >>> Sent: Tuesday, February 19, 2019 1:58 AM >>> To: Jim Schaad > >>> Cc: Klaus Hartke >; draft-ietf-core-multipart-ct@ietf.org = ; core@ietf.org = >>> Subject: Re: [core] draft-ietf-core-multipart-ct >>> =20 >>> It has surfaced in the mailing list as well as in private exchanges = that there are two ways of looking at multipart-ct: >>> (A) as a mechanism to wrap multiple related things in a rigidly = structured way; >>> (B) as a mechanism to aggregate related thingsin flexible ways = (e.g., the EST-coaps credentials). >>>=20 >>> One approach to content negotiation for multiparts of kind (A) is to = assign the aggregate a separate type altogether (overriding C-F 62 with = something allocated on purpose from the FCFS portion of the codepoint = space). This fits Accept=E2=80=99s semantics well. >>>=20 >>> Content negotiation with multiparts of kind (B) needs something like = Jim=E2=80=99s proposal. The slight complication that potentially breaks = Jim=E2=80=99s approach is recursion. >>>=20 >>> To support this, I think the draft could say: >>> - multiparts of kind (A) SHOULD override the multipart C-F with = their own; and >>> - multiparts of kind (B) MUST not include other multiparts of the = same =E2=80=9Ckind=E2=80=9D. >>>=20 >>> The above would make a recursive multipart (i.e., a 62 embedded in = another 62) illegal and give Jim=E2=80=99s new content negotiation a = well-defined semantics. >>>=20 >>> Cheers >>>=20 >>> On Sat, Feb 16, 2019 at 6:25 PM Jim Schaad > wrote: >>> > >>> > Looking at this, it does seem to be a strange way to deal with = things. Of course the problem is made even more of a pain if you think = about the possibility of having nested multipart contents. >>> > >>> > While the following does may not be the greatest solution, I think = that it might be a better answer: >>> > >>> > 1. Define a new target attribute: "mt-subtypes" which contains = the list of any content type which can be returned in a multipart = content. This could be at the top level or anyplace in a tree. >>> > >>> > 2. Define a new option: "mt-accept" which contains the list of = sub-content types that the client can deal with. This option would be = defined as advisory on the part of the server, that is it can return = content types which are not in the list, but where options exist in the = possible returned content tree the requested types, in order, SHOULD be = the ones chosen by the server. I would propose the option be = "Non-Critical, Safe, CacheKey, Repeatable". >>> > >>> > I am not sure if I believe that the new option is part of the = cache key or not. I can see arguments on both sides, but I think I come = down to yes. >>> > >>> > Carsten, I think that this issue (but maybe not this solution) = needs to be put onto the agenda for the interim meeting next Wed. >>> > >>> > Jim >>> > >>> > >>> > > -----Original Message----- >>> > > From: Klaus Hartke > >>> > > Sent: Tuesday, February 12, 2019 9:50 AM >>> > > To: Jim Schaad > >>> > > Cc: draft-ietf-core-multipart-ct@ietf.org = ; core@ietf.org = WG > >>> > > Subject: Re: [core] draft-ietf-core-multipart-ct >>> > > >>> > > For context: [1] [2] >>> > > >>> > > Jim Schaad wrote: >>> > > > If you say ACCEPT 62, do you accept any combination of nested = content >>> > > types? >>> > > >>> > > Yes. A CoAP request can include at most one Accept option and = any response >>> > > must exactly that value as Content-Format or be an error = response. CoAP >>> > > doesn't have a mechanism for negotiating the content formats of >>> > > representations embedded in other representations. I stumbled = upon the >>> > > same problem with CoRAL. >>> > > >>> > > > Should something about this be placed into the draft? >>> > > >>> > > Yes. Proposed text: "CoAP doesn't have a mechanism for = negotiating the >>> > > content formats of representations embedded in = application/multipart-core >>> > > representations." >>> > > >>> > > > Also I note that this draft is currently expired and needs to = be reposted. >>> > > >>> > > Yes. Soon=E2=84=A2. >>> > > >>> > > Klaus >>> > > >>> > > [1] >>> > > = https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFDu6dcm = >>> > > I >>> > > [2] = https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui3Gkllk = >>> > >>> > _______________________________________________ >>> > core mailing list >>> > core@ietf.org >>> > https://www.ietf.org/mailman/listinfo/core = >>>=20 >>> --=20 >>> Thomas >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core = >=20 --Apple-Mail=_6D30D972-2076-4961-A751-D2D65CB4E152 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK so if there's no data I send an empty multipart - (cbor = x80)

Sorry, I'm just = getting up to speed. Is the latest draft version -02? 

Michael

On Mar 2, 2019, at 2:14 PM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

To follow on a = little, the pub/sub use case is for a variable format response (case C?) = that is a better alternative than adding a new result code (2.xx) for = "no data".

There is = another use case (like case B) which is for a generalized hypermedia = format that can return links, data, or both depending on the client = workflow. This would eliminate the need for a new content format like = HSML, and would allow arbitrary data formats to be associated with = core-link-format in batch-access collections as per CoRE = Interfaces.

Best= regards,

Michael

On Mar = 2, 2019, at 2:05 PM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

Hi,

I am integrating = multipart into pub/sub as a way to signal empty payloads that might = result from a subscribe operation where their aren't any stored data = (stale or non-retaining topic) or a retrieve in the same case.

We have decided = initially not to support multiple content formats on a topic in = pub/sub,where the proker would have to convert, but now it might be a = little easier with multipart, if we build in a subtyping system as per = Jim's email. 

IMO the subtype target attribute at least will be necessary = for the kind of discovery we want to support in pub/sub. I guess subtype = accept header option is going to be needed also, so a pub/sub client can = indicate it accepts emty payload format and e.g. senml.

In general I think this = can work for the pub/sub use case and will write it in if it makes = sense.

Best = regards,

Michael


On Feb = 19, 2019, at 9:48 PM, Jim Schaad <ietf@augustcellars.com> wrote:

I did think about some of this when I put up the = proposal.
 
For case (A), unless it is going to have options while doing = a rigidly structured response, there is no need to have a value = different than Accept 62.  In fact if there is really only one = structured response, then there is not a need to have any accept option = in the request at all.
 
For case (B), I thought about the recursive case and that is = why I put the SHOULD and talked about options between multiple things = while building the response.  I don=E2=80=99t think that there are = going to be enough cases of a tree structure being returned that = anything needs to be said about it one way or the other.  If that = type of detail is really needed then I would expect that a GET would be = replaced by a POST with the details of the response needed in the = content of the POST.
 
In the semantics, I wanted to provide a minimal amount of = information.  Thus the language about using it to provide guidance = for specific pairs of content types that can go into a specific = location.  The other place that I was thinking it might be useful = would be in the case of a PUB-SUB server returning multiple content = types where the set of equivalents might be restricted to the requested = values rather than returning all possibilities.
 
Jim
 
 
From: Thomas Fossati <tho.ietf@gmail.com> 
Sent: Tuesday, February 19, 2019 = 1:58 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Klaus= Hartke <hartke@projectcool.de>; draft-ietf-core-multipart-ct@ietf.org; core@ietf.org
Subject: Re: [core] = draft-ietf-core-multipart-ct
 
It has surfaced in the = mailing list as well as in private exchanges that there are two ways of = looking at multipart-ct:
(A) as a mechanism to wrap = multiple related things in a rigidly structured way;
(B) = as a mechanism to aggregate related thingsin flexible ways (e.g., the = EST-coaps credentials).

One approach to = content negotiation for multiparts of kind (A) is to assign the = aggregate a separate type altogether (overriding C-F 62 with something = allocated on purpose from the FCFS portion of the codepoint = space).  This fits Accept=E2=80=99s semantics well.
Content negotiation with multiparts of kind (B) needs = something like Jim=E2=80=99s proposal.  The slight complication = that potentially breaks Jim=E2=80=99s approach is recursion.

To support this, I think the draft could = say:
- multiparts of kind (A) SHOULD override the = multipart C-F with their own; and
- multiparts of kind (B) = MUST not include other multiparts of the same =E2=80=9Ckind=E2=80=9D.

The above would make a recursive multipart = (i.e., a 62 embedded in another 62) illegal and give Jim=E2=80=99s new = content negotiation a well-defined semantics.

Cheers

On Sat, Feb 16, 2019 at = 6:25 PM Jim Schaad <ietf@augustcellars.com> wrote:
>
> Looking at this, it does seem to be a strange way to = deal with things.  Of course the problem is made even more of a = pain if you think about the possibility of having nested multipart = contents.
>
> While the following does = may not be the greatest solution, I think that it might be a better = answer:
>
> 1.  Define a new = target attribute:  "mt-subtypes" which contains the list of any = content type which can be returned in a multipart content.  This = could be at the top level or anyplace in a tree.
>
> 2.  Define a new option: "mt-accept" which contains = the list of sub-content types that the client can deal with.  This = option would be defined as advisory on the part of the server, that is = it can return content types which are not in the list, but where options = exist in the possible returned content tree the requested types, in = order, SHOULD be the ones chosen by the server.   I would propose = the option be "Non-Critical, Safe, CacheKey, Repeatable".
>
> I am not sure if I believe that the = new option is part of the cache key or not.  I can see arguments on = both sides, but I think I come down to yes.
>
> Carsten,   I think that this issue (but maybe not = this solution) needs to be put onto the agenda for the interim meeting = next Wed.
>
> Jim
>
>
> > -----Original Message-----
> > From: Klaus Hartke <hartke@projectcool.de>
> > Sent: Tuesday, February 12, 2019 9:50 AM
> > To: Jim Schaad <ietf@augustcellars.com>
> > Cc: draft-ietf-core-multipart-ct@ietf.org; core@ietf.org WG <core@ietf.org>
> > = Subject: Re: [core] draft-ietf-core-multipart-ct
> = >
> > For context: [1] [2]
> = >
> > Jim Schaad wrote:
> > = > If you say ACCEPT 62, do you accept any combination of nested = content
> > types?
> >
> > Yes. A CoAP request can include at most one Accept = option and any response
> > must exactly that value = as Content-Format or be an error response. CoAP
> > = doesn't have a mechanism for negotiating the content formats of
> > representations embedded in other representations. = I stumbled upon the
> > same problem with CoRAL.
> >
> > > Should something about = this be placed into the draft?
> >
> = > Yes. Proposed text: "CoAP doesn't have a mechanism for negotiating = the
> > content formats of representations embedded = in application/multipart-core
> > = representations."
> >
> > > = Also I note that this draft is currently expired and needs to be = reposted.
> >
> > Yes. = Soon=E2=84=A2.
> >
> > Klaus
> >
> > [1]
> = > https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFD= u6dcm
> > I
> > [2] https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui= 3Gkllk
>
> = _______________________________________________
> core = mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

-- 
Thomas
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core



= --Apple-Mail=_6D30D972-2076-4961-A751-D2D65CB4E152-- From nobody Sat Mar 2 15:23:57 2019 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 CCEEF128D52; Sat, 2 Mar 2019 15:23:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbcFN2z_mSxz; Sat, 2 Mar 2019 15:23:52 -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 88646127133; Sat, 2 Mar 2019 15:23:51 -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, 2 Mar 2019 15:23:43 -0800 From: Jim Schaad To: 'Michael Koster' CC: 'Thomas Fossati' , , , 'Klaus Hartke' , =?utf-8?Q?'Jaime_Jim=C3=A9nez'?= , =?utf-8?Q?'Ari_Ker=C3=A4nen'?= References: <000901d4c2f8$4b69a640$e23cf2c0$@augustcellars.com> <00f901d4c624$f313cb30$d93b6190$@augustcellars.com> <026901d4c8df$e2251410$a66f3c30$@augustcellars.com> <1D9AA506-85CB-452E-B0DC-4BC099E04F58@gmail.com> <47DAEE52-702A-40C0-9F7C-589CBD0D1C73@gmail.com> <39D848BF-9B8F-4062-9FF0-B8E7D694F849@gmail.com> In-Reply-To: <39D848BF-9B8F-4062-9FF0-B8E7D694F849@gmail.com> Date: Sat, 2 Mar 2019 15:23:41 -0800 Message-ID: <004701d4d14e$fb3e10b0$f1ba3210$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01D4D10B.ED1C7E60" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHZeLzgd60hRSXGqZKN3jc6SJcBfgFxWGrPAht6VX8BZPQLtgJmNS+rAxweFbkBoq42gwJObeyypXyClMA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] draft-ietf-core-multipart-ct 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, 02 Mar 2019 23:23:56 -0000 ------=_NextPart_000_0048_01D4D10B.ED1C7E60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That would not work if one put in an ACCEPT XX which was not multipart. = Although in that case you could return a content request not available. =20 Jim =20 =20 From: Michael Koster =20 Sent: Saturday, March 2, 2019 3:13 PM To: Jim Schaad Cc: Thomas Fossati ; = draft-ietf-core-multipart-ct@ietf.org; core@ietf.org WG ; = Klaus Hartke ; Jaime Jim=C3=A9nez = ; Ari Ker=C3=A4nen Subject: Re: [core] draft-ietf-core-multipart-ct =20 OK so if there's no data I send an empty multipart - (cbor x80) =20 Sorry, I'm just getting up to speed. Is the latest draft version -02?=20 =20 Michael =20 On Mar 2, 2019, at 2:14 PM, Michael Koster > wrote: =20 To follow on a little, the pub/sub use case is for a variable format = response (case C?) that is a better alternative than adding a new result = code (2.xx) for "no data". =20 There is another use case (like case B) which is for a generalized = hypermedia format that can return links, data, or both depending on the = client workflow. This would eliminate the need for a new content format = like HSML, and would allow arbitrary data formats to be associated with = core-link-format in batch-access collections as per CoRE Interfaces. =20 Best regards, =20 Michael =20 On Mar 2, 2019, at 2:05 PM, Michael Koster > wrote: =20 Hi, =20 I am integrating multipart into pub/sub as a way to signal empty = payloads that might result from a subscribe operation where their aren't = any stored data (stale or non-retaining topic) or a retrieve in the same = case. =20 We have decided initially not to support multiple content formats on a = topic in pub/sub,where the proker would have to convert, but now it = might be a little easier with multipart, if we build in a subtyping = system as per Jim's email.=20 =20 IMO the subtype target attribute at least will be necessary for the kind = of discovery we want to support in pub/sub. I guess subtype accept = header option is going to be needed also, so a pub/sub client can = indicate it accepts emty payload format and e.g. senml. =20 In general I think this can work for the pub/sub use case and will write = it in if it makes sense. =20 Best regards, =20 Michael =20 =20 On Feb 19, 2019, at 9:48 PM, Jim Schaad > wrote: =20 I did think about some of this when I put up the proposal. =20 For case (A), unless it is going to have options while doing a rigidly = structured response, there is no need to have a value different than = Accept 62. In fact if there is really only one structured response, = then there is not a need to have any accept option in the request at = all. =20 For case (B), I thought about the recursive case and that is why I put = the SHOULD and talked about options between multiple things while = building the response. I don=E2=80=99t think that there are going to be = enough cases of a tree structure being returned that anything needs to = be said about it one way or the other. If that type of detail is really = needed then I would expect that a GET would be replaced by a POST with = the details of the response needed in the content of the POST. =20 In the semantics, I wanted to provide a minimal amount of information. = Thus the language about using it to provide guidance for specific pairs = of content types that can go into a specific location. The other place = that I was thinking it might be useful would be in the case of a PUB-SUB = server returning multiple content types where the set of equivalents = might be restricted to the requested values rather than returning all = possibilities. =20 Jim =20 =20 From: Thomas Fossati >=20 Sent: Tuesday, February 19, 2019 1:58 AM To: Jim Schaad > Cc: Klaus Hartke = >; draft-ietf-core-multipart-ct@ietf.org = ; core@ietf.org = =20 Subject: Re: [core] draft-ietf-core-multipart-ct =20 It has surfaced in the mailing list as well as in private exchanges that = there are two ways of looking at multipart-ct: (A) as a mechanism to wrap multiple related things in a rigidly = structured way; (B) as a mechanism to aggregate related thingsin flexible ways (e.g., = the EST-coaps credentials). One approach to content negotiation for multiparts of kind (A) is to = assign the aggregate a separate type altogether (overriding C-F 62 with = something allocated on purpose from the FCFS portion of the codepoint = space). This fits Accept=E2=80=99s semantics well. Content negotiation with multiparts of kind (B) needs something like = Jim=E2=80=99s proposal. The slight complication that potentially breaks = Jim=E2=80=99s approach is recursion. To support this, I think the draft could say: - multiparts of kind (A) SHOULD override the multipart C-F with their = own; and - multiparts of kind (B) MUST not include other multiparts of the same = =E2=80=9Ckind=E2=80=9D. The above would make a recursive multipart (i.e., a 62 embedded in = another 62) illegal and give Jim=E2=80=99s new content negotiation a = well-defined semantics. Cheers On Sat, Feb 16, 2019 at 6:25 PM Jim Schaad < = ietf@augustcellars.com> wrote: > > Looking at this, it does seem to be a strange way to deal with things. = Of course the problem is made even more of a pain if you think about = the possibility of having nested multipart contents. > > While the following does may not be the greatest solution, I think = that it might be a better answer: > > 1. Define a new target attribute: "mt-subtypes" which contains the = list of any content type which can be returned in a multipart content. = This could be at the top level or anyplace in a tree. > > 2. Define a new option: "mt-accept" which contains the list of = sub-content types that the client can deal with. This option would be = defined as advisory on the part of the server, that is it can return = content types which are not in the list, but where options exist in the = possible returned content tree the requested types, in order, SHOULD be = the ones chosen by the server. I would propose the option be = "Non-Critical, Safe, CacheKey, Repeatable". > > I am not sure if I believe that the new option is part of the cache = key or not. I can see arguments on both sides, but I think I come down = to yes. > > Carsten, I think that this issue (but maybe not this solution) needs = to be put onto the agenda for the interim meeting next Wed. > > Jim > > > > -----Original Message----- > > From: Klaus Hartke < = hartke@projectcool.de> > > Sent: Tuesday, February 12, 2019 9:50 AM > > To: Jim Schaad < = ietf@augustcellars.com> > > Cc: = draft-ietf-core-multipart-ct@ietf.org; = core@ietf.org WG < core@ietf.org> > > Subject: Re: [core] draft-ietf-core-multipart-ct > > > > For context: [1] [2] > > > > Jim Schaad wrote: > > > If you say ACCEPT 62, do you accept any combination of nested = content > > types? > > > > Yes. A CoAP request can include at most one Accept option and any = response > > must exactly that value as Content-Format or be an error response. = CoAP > > doesn't have a mechanism for negotiating the content formats of > > representations embedded in other representations. I stumbled upon = the > > same problem with CoRAL. > > > > > Should something about this be placed into the draft? > > > > Yes. Proposed text: "CoAP doesn't have a mechanism for negotiating = the > > content formats of representations embedded in = application/multipart-core > > representations." > > > > > Also I note that this draft is currently expired and needs to be = reposted. > > > > Yes. Soon=E2=84=A2. > > > > Klaus > > > > [1] > > = = https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFDu6dcm > > I > > [2] = = https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui3Gkllk > > _______________________________________________ > core mailing list > core@ietf.org > = https://www.ietf.org/mailman/listinfo/core --=20 Thomas _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core =20 =20 =20 ------=_NextPart_000_0048_01D4D10B.ED1C7E60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

That would = not work if one put in an ACCEPT XX which was not multipart.=C2=A0 = Although in that case you could return a content request not = available.

 

Jim

 

 

From: = Michael Koster <michaeljohnkoster@gmail.com>
Sent: = Saturday, March 2, 2019 3:13 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Thomas Fossati = <tho.ietf@gmail.com>; draft-ietf-core-multipart-ct@ietf.org; = core@ietf.org WG <core@ietf.org>; Klaus Hartke = <hartke@projectcool.de>; Jaime Jim=C3=A9nez = <jaimejim@gmail.com>; Ari Ker=C3=A4nen = <ari.keranen@ericsson.com>
Subject: Re: [core] = draft-ietf-core-multipart-ct

 

OK so if = there's no data I send an empty multipart - (cbor = x80)

 

Sorry, I'm just getting up to speed. Is the latest = draft version -02? 

 

Michael

 

On Mar 2, 2019, at 2:14 PM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

 

To = follow on a little, the pub/sub use case is for a variable format = response (case C?) that is a better alternative than adding a new result = code (2.xx) for "no data".

Michael

 

 

Hi,

I = am integrating multipart into pub/sub as a way to signal empty payloads = that might result from a subscribe operation where their aren't any = stored data (stale or non-retaining topic) or a retrieve in the same = case.

 

I = did think about some of this when I put up the = proposal.

 

For case (A), unless it is going to have options while = doing a rigidly structured response, there is no need to have a value = different than Accept 62.  In fact if there is really only one = structured response, then there is not a need to have any accept option = in the request at all.

 

For case (B), I thought about the recursive case and = that is why I put the SHOULD and talked about options between multiple = things while building the response.  I don=E2=80=99t think that = there are going to be enough cases of a tree structure being returned = that anything needs to be said about it one way or the other.  If = that type of detail is really needed then I would expect that a GET = would be replaced by a POST with the details of the response needed in = the content of the POST.

 

In the semantics, I wanted to provide a minimal amount = of information.  Thus the language about using it to provide = guidance for specific pairs of content types that can go into a specific = location.  The other place that I was thinking it might be useful = would be in the case of a PUB-SUB server returning multiple content = types where the set of equivalents might be restricted to the requested = values rather than returning all = possibilities.

 

Jim

 

 

From: Thomas Fossati <tho.ietf@gmail.com> 
Sent: Tuesday, February 19, 2019 = 1:58 AM
To: Jim Schaad <ietf@augustcellars.com>
= Cc: Klaus Hartke = <hartke@projectcool.de>; draft-ietf-core-mul= tipart-ct@ietf.org; core@ietf.org
Subject: Re: [core] = draft-ietf-core-multipart-ct

 

It has surfaced in the mailing list as well as in = private exchanges that there are two ways of looking at = multipart-ct:
(A) as a mechanism to wrap multiple related things in a = rigidly structured way;
(B) as a mechanism to aggregate related = thingsin flexible ways (e.g., the EST-coaps credentials).

One = approach to content negotiation for multiparts of kind (A) is to assign = the aggregate a separate type altogether (overriding C-F 62 with = something allocated on purpose from the FCFS portion of the codepoint = space).  This fits Accept=E2=80=99s semantics well.

Content = negotiation with multiparts of kind (B) needs something like = Jim=E2=80=99s proposal.  The slight complication that potentially = breaks Jim=E2=80=99s approach is recursion.

To support this, I = think the draft could say:
- multiparts of kind (A) SHOULD override = the multipart C-F with their own; and
- multiparts of kind (B) MUST = not include other multiparts of the same = =E2=80=9Ckind=E2=80=9D.

The above would make a recursive = multipart (i.e., a 62 embedded in another 62) illegal and give = Jim=E2=80=99s new content negotiation a well-defined = semantics.

Cheers

On Sat, Feb 16, 2019 at 6:25 PM Jim = Schaad <ietf@augustcellars.com> = wrote:
>
> Looking at this, it does seem to be a strange way = to deal with things.  Of course the problem is made even more of a = pain if you think about the possibility of having nested multipart = contents.
>
> While the following does may not be the = greatest solution, I think that it might be a better = answer:
>
> 1.  Define a new target attribute: =  "mt-subtypes" which contains the list of any content = type which can be returned in a multipart content.  This could be = at the top level or anyplace in a tree.
>
> 2.  Define = a new option: "mt-accept" which contains the list of = sub-content types that the client can deal with.  This option would = be defined as advisory on the part of the server, that is it can return = content types which are not in the list, but where options exist in the = possible returned content tree the requested types, in order, SHOULD be = the ones chosen by the server.   I would propose the option be = "Non-Critical, Safe, CacheKey, Repeatable".
>
> I = am not sure if I believe that the new option is part of the cache key or = not.  I can see arguments on both sides, but I think I come down to = yes.
>
> Carsten,   I think that this issue (but maybe = not this solution) needs to be put onto the agenda for the interim = meeting next Wed.
>
> Jim
>
>
> > = -----Original Message-----
> > From: Klaus Hartke <hartke@projectcool.de>
> > = Sent: Tuesday, February 12, 2019 9:50 AM
> > To: Jim Schaad = <ietf@augustcellars.com>
> = > Cc: draft-ietf-core-multipart-ct@ietf.org;<= span class=3Dapple-converted-space> core@ietf.org WG <core@ietf.org>
> > = Subject: Re: [core] draft-ietf-core-multipart-ct
> >
> = > For context: [1] [2]
> >
> > Jim Schaad = wrote:
> > > If you say ACCEPT 62, do you accept any = combination of nested content
> > types?
> >
> = > Yes. A CoAP request can include at most one Accept option and any = response
> > must exactly that value as Content-Format or be an = error response. CoAP
> > doesn't have a mechanism for = negotiating the content formats of
> > representations embedded = in other representations. I stumbled upon the
> > same problem = with CoRAL.
> >
> > > Should something about this = be placed into the draft?
> >
> > Yes. Proposed text: = "CoAP doesn't have a mechanism for negotiating the
> > = content formats of representations embedded in = application/multipart-core
> > representations."
> = >
> > > Also I note that this draft is currently expired = and needs to be reposted.
> >
> > Yes. = Soon=E2=84=A2.
> >
> > Klaus
> >
> > = [1]
> > https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zH= Aj15nsKMe8AFDu6dcm
> > I
> > [2] https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8e= Rrra5yph2Z9ui3Gkllk
>
> = _______________________________________________
> core mailing = list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core<= /a>

-- 
Thomas

____________= ___________________________________
core mailing list
core@ietf.org
https://www.ietf.org/= mailman/listinfo/core

<= p = class=3DMsoNormal> 

 

 

------=_NextPart_000_0048_01D4D10B.ED1C7E60-- From nobody Sat Mar 2 15:24:07 2019 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 3D6BA130F2F for ; Sat, 2 Mar 2019 15:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lJXSoYbo4LN for ; Sat, 2 Mar 2019 15:23:57 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 21330128D52 for ; Sat, 2 Mar 2019 15:23:57 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id b2so728438pgl.9 for ; Sat, 02 Mar 2019 15:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=daLeJ6O8ozv8puqf8bQSfKfptiDZyHnLeYZZpoRsFKI=; b=otkrj+JToq9N7IDtyNrbethtNAEPk7xENRrEQVi420jbrdcayB/j1yZkBzSWunjOI7 66QB8GXCjR6kD+zQ3bS4AHTcrsCjNzs0yxDYhltaAwg1p8FXYOU7FT7e48t2zj8x+6Ih Rv3pveUkown12jLoIf/GqkysxK6Pv9YspN3eZySyiZihmOTKpfUGhZJxRPrj354/vskI 5FIZqBq00HI6A354L8RbqkqsCD7qQGyTGxcLzUxl5vM1THWrm5urg1yO+5rkIOcaug4L StuW5oXCY+A35XsJtK0QCPTHPtTCIZpfFSY33muRWwEwI6cPe0iLHRZfTT5NKoe4/f+v GE/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=daLeJ6O8ozv8puqf8bQSfKfptiDZyHnLeYZZpoRsFKI=; b=NS36YD2vdgVczIEZ59zaOxdMN7ARry57qJ8qBS6GirTU4PWaYpxNOOyh3zf4UWksU/ WXu9Xpcy4+b1ERSblfdbbpSbKjNcl2HNC7ZZcp1r+bAe8V+57LuQTcS3q7u66q0cm249 AQleLd03zUgcBZhKYRI8M9y+KsSLPf1434WUelSUxXTHYOFG3ofaQqfPqnhvCGcscfP6 Gb7h/VVK6f8zySlIN+28djit8fRg5PomWP30EFVXjEBiBMEmhen98RfnB2CCXfH8Ksl6 FjKRBqUd4IpMBeMT8zypkBDWHTdDJI7mtkIil9sbzs0oF08Eolj5OIJQvjOIzXT7fuy+ vXkg== X-Gm-Message-State: APjAAAV61H6XXjPhBRomQTDTDt99yeAEVIB0aPTDjJSg8JmLAIWY98RQ 3HQc0GwMsMgFms/NbN2Cn9s= X-Google-Smtp-Source: APXvYqxiR7SZL7k0VKvB63jOltq5gMuqJFSO4XABMTN5OFM+2r4OB3soS2jDmdwCHmAQKnuEBUdn0w== X-Received: by 2002:a63:6b03:: with SMTP id g3mr11674357pgc.239.1551569036217; Sat, 02 Mar 2019 15:23:56 -0800 (PST) Received: from [172.16.0.3] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id v22sm4974245pfa.49.2019.03.02.15.23.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Mar 2019 15:23:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: Date: Sat, 2 Mar 2019 15:23:53 -0800 Cc: Carsten Bormann , "core@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <904CFCA3-F10A-4018-88AB-E859743B3E70@gmail.com> References: To: =?utf-8?Q?Ari_Ker=C3=A4nen?= , =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Pub/Sub update to use the core multipart content format 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, 02 Mar 2019 23:24:04 -0000 OK, I read the multipart draft (expired?) For the no data case we will = just send an empty multipart payload (cbor x80). It seems like every implementation of pub/sub will be required to = support only link-format and multipart. The subtype support will be on a = topic basis and maybe a broker should have some way to list a set of = supported subtopics that it can handle. To remind people, a coap pub/sub = broker doesn't have any notion of "resource state" other than a stored = representation. Best regards, Michael > On Mar 2, 2019, at 5:27 AM, Michael Koster = wrote: >=20 > Hi, >=20 > I am editing the pub/sub draft today and thinking about the multipart = content format as a way to provide a subscribe or retrieve response for = the no data case. >=20 > It seems to require that the pub/sub client always support the = multipart format, with no content being one of the format options = signaled by something like "maybe". >=20 > Does this seem right to you also? Do we need to invent a new empty = format code instead of a response code?=20 >=20 > Best regards, >=20 > Michael >=20 >=20 >=20 >=20 From nobody Sat Mar 2 15:26:22 2019 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 B4E05130EA3; Sat, 2 Mar 2019 15:26:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ek0xpInC_tQ5; Sat, 2 Mar 2019 15:26:17 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 6C4D3127133; Sat, 2 Mar 2019 15:26:17 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id g6so667143pfh.13; Sat, 02 Mar 2019 15:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=03oto26Um8V4xVqexq6Uyw6HFQFwNAdhn3rMRhnHcbg=; b=PigELo8uEEUzuirfkggghC9CaQvx3qaf2dXixIOvuVj/slZxP4saqVCsEk/rd73edz 9MYkcPsWnl5O2xWnNkPNDndWHg/QeWxV1YbTGb3+MUUaOhAqFFWw2yB/shYwGXbc8/zU 195w+bUAcLWonF1WapOQoU/gPihx40dKXtoM9Co68taB5SoJgb4GLHPrUth3etVyb31J D0B+/7yDAWwsINTM+9mP4NcrDRB93mraQhDoVrIp83CBc1o7bsICTq8bXi4twOKUlWet 3R1EffDfZI/W13PVPicd2PuMMGa3L61JEp5qmPsocgVfExo0yt0tnt9TRTb/TDOR4EvQ aWfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=03oto26Um8V4xVqexq6Uyw6HFQFwNAdhn3rMRhnHcbg=; b=SWcDffu6wMPbazdaUrIra0DI1+XhgOzFM5syCTqL7S9qS75ADY5mSRplaIhj+T9AOI seUq18SL6ZrMeM2YyqrGuKB049vxMqpX0WB/7dwq8GQZPN8nnj5+V8KrwOletQB+LHcj 5rlThiWvgSsatgzawKq4KOEPvwnn9OcUgIvojCxnpTozPM0X3HwQLrWEeMX7CSPG3bpG MMMLqZOI5nUbRrZ2p22yIxiTayNhfIRHdkUyIkHqG3anKKCnSGrANoZNwZodq0nfMocI 6YcO/YpUDMPHsK3ZSD57uoQMREXL5eSlRqA3FpfcOlaOJwbvgXfpgOoU5cxK5HvZf+R5 rTng== X-Gm-Message-State: AHQUAubwUlIt7A+bzeEN1JV7Nc3dnDy++RLFj9unJAgBfdygB9wWuPIX A9eJr3slRqdT1/usGl5vISE= X-Google-Smtp-Source: AHgI3IZESI73HWvm0cGNoFWDWFhNeme2PhFQjmXnEgFZjMvUl9SNI6FSapSc4KZBVDEq76W09j1pnA== X-Received: by 2002:a62:d281:: with SMTP id c123mr12673677pfg.210.1551569176699; Sat, 02 Mar 2019 15:26:16 -0800 (PST) Received: from [172.16.0.3] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id h184sm8435725pfc.78.2019.03.02.15.26.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Mar 2019 15:26:15 -0800 (PST) From: Michael Koster Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_53D8A2D1-C936-482A-BE5D-DDC18DF69CC8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 2 Mar 2019 15:26:13 -0800 In-Reply-To: <004701d4d14e$fb3e10b0$f1ba3210$@augustcellars.com> Cc: Thomas Fossati , draft-ietf-core-multipart-ct@ietf.org, "core@ietf.org WG" , Klaus Hartke , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , =?utf-8?Q?Ari_Ker=C3=A4nen?= To: Jim Schaad References: <000901d4c2f8$4b69a640$e23cf2c0$@augustcellars.com> <00f901d4c624$f313cb30$d93b6190$@augustcellars.com> <026901d4c8df$e2251410$a66f3c30$@augustcellars.com> <1D9AA506-85CB-452E-B0DC-4BC099E04F58@gmail.com> <47DAEE52-702A-40C0-9F7C-589CBD0D1C73@gmail.com> <39D848BF-9B8F-4062-9FF0-B8E7D694F849@gmail.com> <004701d4d14e$fb3e10b0$f1ba3210$@augustcellars.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-multipart-ct 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, 02 Mar 2019 23:26:21 -0000 --Apple-Mail=_53D8A2D1-C936-482A-BE5D-DDC18DF69CC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agree, the accept option would be for multipart, which illustrates why = we would need a new option for accept subtype. It follows the use case example in 3.1 of the draft. Michael > On Mar 2, 2019, at 3:23 PM, Jim Schaad wrote: >=20 > That would not work if one put in an ACCEPT XX which was not = multipart. Although in that case you could return a content request not = available. > =20 > Jim > =20 > =20 > From: Michael Koster =20 > Sent: Saturday, March 2, 2019 3:13 PM > To: Jim Schaad > Cc: Thomas Fossati ; = draft-ietf-core-multipart-ct@ietf.org; core@ietf.org WG ; = Klaus Hartke ; Jaime Jim=C3=A9nez = ; Ari Ker=C3=A4nen > Subject: Re: [core] draft-ietf-core-multipart-ct > =20 > OK so if there's no data I send an empty multipart - (cbor x80) > =20 > Sorry, I'm just getting up to speed. Is the latest draft version -02?=20= > =20 > Michael > =20 >> On Mar 2, 2019, at 2:14 PM, Michael Koster = > = wrote: >> =20 >> To follow on a little, the pub/sub use case is for a variable format = response (case C?) that is a better alternative than adding a new result = code (2.xx) for "no data". >> =20 >> There is another use case (like case B) which is for a generalized = hypermedia format that can return links, data, or both depending on the = client workflow. This would eliminate the need for a new content format = like HSML, and would allow arbitrary data formats to be associated with = core-link-format in batch-access collections as per CoRE Interfaces. >> =20 >> Best regards, >> =20 >> Michael >> =20 >>> On Mar 2, 2019, at 2:05 PM, Michael Koster = > = wrote: >>> =20 >>> Hi, >>> =20 >>> I am integrating multipart into pub/sub as a way to signal empty = payloads that might result from a subscribe operation where their aren't = any stored data (stale or non-retaining topic) or a retrieve in the same = case. >>> =20 >>> We have decided initially not to support multiple content formats on = a topic in pub/sub,where the proker would have to convert, but now it = might be a little easier with multipart, if we build in a subtyping = system as per Jim's email.=20 >>> =20 >>> IMO the subtype target attribute at least will be necessary for the = kind of discovery we want to support in pub/sub. I guess subtype accept = header option is going to be needed also, so a pub/sub client can = indicate it accepts emty payload format and e.g. senml. >>> =20 >>> In general I think this can work for the pub/sub use case and will = write it in if it makes sense. >>> =20 >>> Best regards, >>> =20 >>> Michael >>> =20 >>> =20 >>>> On Feb 19, 2019, at 9:48 PM, Jim Schaad > wrote: >>>> =20 >>>> I did think about some of this when I put up the proposal. >>>> =20 >>>> For case (A), unless it is going to have options while doing a = rigidly structured response, there is no need to have a value different = than Accept 62. In fact if there is really only one structured = response, then there is not a need to have any accept option in the = request at all. >>>> =20 >>>> For case (B), I thought about the recursive case and that is why I = put the SHOULD and talked about options between multiple things while = building the response. I don=E2=80=99t think that there are going to be = enough cases of a tree structure being returned that anything needs to = be said about it one way or the other. If that type of detail is really = needed then I would expect that a GET would be replaced by a POST with = the details of the response needed in the content of the POST. >>>> =20 >>>> In the semantics, I wanted to provide a minimal amount of = information. Thus the language about using it to provide guidance for = specific pairs of content types that can go into a specific location. = The other place that I was thinking it might be useful would be in the = case of a PUB-SUB server returning multiple content types where the set = of equivalents might be restricted to the requested values rather than = returning all possibilities. >>>> =20 >>>> Jim >>>> =20 >>>> =20 >>>> From: Thomas Fossati >=20 >>>> Sent: Tuesday, February 19, 2019 1:58 AM >>>> To: Jim Schaad > >>>> Cc: Klaus Hartke >; draft-ietf-core-multipart-ct@ietf.org = ; core@ietf.org = >>>> Subject: Re: [core] draft-ietf-core-multipart-ct >>>> =20 >>>> It has surfaced in the mailing list as well as in private exchanges = that there are two ways of looking at multipart-ct: >>>> (A) as a mechanism to wrap multiple related things in a rigidly = structured way; >>>> (B) as a mechanism to aggregate related thingsin flexible ways = (e.g., the EST-coaps credentials). >>>>=20 >>>> One approach to content negotiation for multiparts of kind (A) is = to assign the aggregate a separate type altogether (overriding C-F 62 = with something allocated on purpose from the FCFS portion of the = codepoint space). This fits Accept=E2=80=99s semantics well. >>>>=20 >>>> Content negotiation with multiparts of kind (B) needs something = like Jim=E2=80=99s proposal. The slight complication that potentially = breaks Jim=E2=80=99s approach is recursion. >>>>=20 >>>> To support this, I think the draft could say: >>>> - multiparts of kind (A) SHOULD override the multipart C-F with = their own; and >>>> - multiparts of kind (B) MUST not include other multiparts of the = same =E2=80=9Ckind=E2=80=9D. >>>>=20 >>>> The above would make a recursive multipart (i.e., a 62 embedded in = another 62) illegal and give Jim=E2=80=99s new content negotiation a = well-defined semantics. >>>>=20 >>>> Cheers >>>>=20 >>>> On Sat, Feb 16, 2019 at 6:25 PM Jim Schaad > wrote: >>>> > >>>> > Looking at this, it does seem to be a strange way to deal with = things. Of course the problem is made even more of a pain if you think = about the possibility of having nested multipart contents. >>>> > >>>> > While the following does may not be the greatest solution, I = think that it might be a better answer: >>>> > >>>> > 1. Define a new target attribute: "mt-subtypes" which contains = the list of any content type which can be returned in a multipart = content. This could be at the top level or anyplace in a tree. >>>> > >>>> > 2. Define a new option: "mt-accept" which contains the list of = sub-content types that the client can deal with. This option would be = defined as advisory on the part of the server, that is it can return = content types which are not in the list, but where options exist in the = possible returned content tree the requested types, in order, SHOULD be = the ones chosen by the server. I would propose the option be = "Non-Critical, Safe, CacheKey, Repeatable". >>>> > >>>> > I am not sure if I believe that the new option is part of the = cache key or not. I can see arguments on both sides, but I think I come = down to yes. >>>> > >>>> > Carsten, I think that this issue (but maybe not this solution) = needs to be put onto the agenda for the interim meeting next Wed. >>>> > >>>> > Jim >>>> > >>>> > >>>> > > -----Original Message----- >>>> > > From: Klaus Hartke > >>>> > > Sent: Tuesday, February 12, 2019 9:50 AM >>>> > > To: Jim Schaad > >>>> > > Cc: draft-ietf-core-multipart-ct@ietf.org = ; core@ietf.org = WG > >>>> > > Subject: Re: [core] draft-ietf-core-multipart-ct >>>> > > >>>> > > For context: [1] [2] >>>> > > >>>> > > Jim Schaad wrote: >>>> > > > If you say ACCEPT 62, do you accept any combination of nested = content >>>> > > types? >>>> > > >>>> > > Yes. A CoAP request can include at most one Accept option and = any response >>>> > > must exactly that value as Content-Format or be an error = response. CoAP >>>> > > doesn't have a mechanism for negotiating the content formats of >>>> > > representations embedded in other representations. I stumbled = upon the >>>> > > same problem with CoRAL. >>>> > > >>>> > > > Should something about this be placed into the draft? >>>> > > >>>> > > Yes. Proposed text: "CoAP doesn't have a mechanism for = negotiating the >>>> > > content formats of representations embedded in = application/multipart-core >>>> > > representations." >>>> > > >>>> > > > Also I note that this draft is currently expired and needs to = be reposted. >>>> > > >>>> > > Yes. Soon=E2=84=A2. >>>> > > >>>> > > Klaus >>>> > > >>>> > > [1] >>>> > > = https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFDu6dcm = >>>> > > I >>>> > > [2] = https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui3Gkllk = >>>> > >>>> > _______________________________________________ >>>> > core mailing list >>>> > core@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/core = >>>>=20 >>>> --=20 >>>> Thomas >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_53D8A2D1-C936-482A-BE5D-DDC18DF69CC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agree, the accept option would be for multipart, which = illustrates why we would need a new option for accept subtype.

It follows the use case = example in 3.1 of the draft.

Michael

On = Mar 2, 2019, at 3:23 PM, Jim Schaad <ietf@augustcellars.com> wrote:

That would not work if one put in an ACCEPT XX which was not = multipart.  Although in that case you could return a content = request not available.
 
Jim
 
 
From: Michael Koster <michaeljohnkoster@gmail.com> 
Sent: Saturday, March 2, 2019 = 3:13 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Thomas Fossati <tho.ietf@gmail.com>; = draft-ietf-core-multipart-ct@ietf.org; core@ietf.org WG <core@ietf.org>; Klaus = Hartke <hartke@projectcool.de>; Jaime Jim=C3=A9nez <jaimejim@gmail.com>; = Ari Ker=C3=A4nen <ari.keranen@ericsson.com>
Subject: Re: [core] = draft-ietf-core-multipart-ct
 
OK so if there's no data I send an = empty multipart - (cbor x80)
 
Sorry, I'm just getting up to speed. Is the latest draft = version -02? 
 
Michael
 
On Mar 2, 2019, at 2:14 PM, Michael Koster <michaeljohnkoster@gmail.com> wrote:
 
To follow on a little, the pub/sub use = case is for a variable format response (case C?) that is a better = alternative than adding a new result code (2.xx) for "no data".
 
There is another use case (like case B) = which is for a generalized hypermedia format that can return links, = data, or both depending on the client workflow. This would eliminate the = need for a new content format like HSML, and would allow arbitrary data = formats to be associated with core-link-format in batch-access = collections as per CoRE Interfaces.
 
Best regards,
 
Michael
 
On Mar 2, 2019, at 2:05 PM, Michael Koster <michaeljohnkoster@gmail.com> wrote:
 
Hi,
 
I am integrating multipart into pub/sub as a way to signal = empty payloads that might result from a subscribe operation where their = aren't any stored data (stale or non-retaining topic) or a retrieve in = the same case.
 
We have decided initially not to support multiple content = formats on a topic in pub/sub,where the proker would have to convert, = but now it might be a little easier with multipart, if we build in a = subtyping system as per Jim's email. 
 
IMO the subtype target attribute at = least will be necessary for the kind of discovery we want to support in = pub/sub. I guess subtype accept header option is going to be needed = also, so a pub/sub client can indicate it accepts emty payload format = and e.g. senml.
 
In general I think this can work for the pub/sub use case and = will write it in if it makes sense.
 
Best regards,
 
Michael
 
 
On Feb 19, 2019, at 9:48 PM, Jim Schaad <ietf@augustcellars.com> = wrote:
 
I did think about some of = this when I put up the proposal.
 
For case (A), unless it is going to have options while doing = a rigidly structured response, there is no need to have a value = different than Accept 62.  In fact if there is really only one = structured response, then there is not a need to have any accept option = in the request at all.
 
For case (B), I thought about the recursive case and that is = why I put the SHOULD and talked about options between multiple things = while building the response.  I don=E2=80=99t think that there are = going to be enough cases of a tree structure being returned that = anything needs to be said about it one way or the other.  If that = type of detail is really needed then I would expect that a GET would be = replaced by a POST with the details of the response needed in the = content of the POST.
 
In the semantics, I wanted to provide a minimal amount of = information.  Thus the language about using it to provide guidance = for specific pairs of content types that can go into a specific = location.  The other place that I was thinking it might be useful = would be in the case of a PUB-SUB server returning multiple content = types where the set of equivalents might be restricted to the requested = values rather than returning all possibilities.
 
Jim
 
 
From: Thomas Fossati <tho.ietf@gmail.com> 
Sent: Tuesday, February 19, 2019 = 1:58 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Klaus Hartke <hartke@projectcool.de>; draft-ietf-core-multipart-ct@ietf.org; core@ietf.org
Subject: Re: [core] = draft-ietf-core-multipart-ct
 
It has surfaced in the mailing list as = well as in private exchanges that there are two ways of looking at = multipart-ct:
(A) as a mechanism to wrap multiple related = things in a rigidly structured way;
(B) as a mechanism to = aggregate related thingsin flexible ways (e.g., the EST-coaps = credentials).

One approach to content = negotiation for multiparts of kind (A) is to assign the aggregate a = separate type altogether (overriding C-F 62 with something allocated on = purpose from the FCFS portion of the codepoint space).  This fits = Accept=E2=80=99s semantics well.

Content = negotiation with multiparts of kind (B) needs something like Jim=E2=80=99s= proposal.  The slight complication that potentially breaks Jim=E2=80= =99s approach is recursion.

To support = this, I think the draft could say:
- multiparts of kind = (A) SHOULD override the multipart C-F with their own; and
- = multiparts of kind (B) MUST not include other multiparts of the same = =E2=80=9Ckind=E2=80=9D.

The above would = make a recursive multipart (i.e., a 62 embedded in another 62) illegal = and give Jim=E2=80=99s new content negotiation a well-defined = semantics.

Cheers

On Sat, Feb 16, 2019 at 6:25 PM Jim Schaad <ietf@augustcellars.com> wrote:
>
> Looking at this, it does seem to be a = strange way to deal with things.  Of course the problem is made = even more of a pain if you think about the possibility of having nested = multipart contents.
>
> While the = following does may not be the greatest solution, I think that it might = be a better answer:
>
> 1.  = Define a new target attribute:  "mt-subtypes" which contains the = list of any content type which can be returned in a multipart = content.  This could be at the top level or anyplace in a tree.
>
> 2.  Define a new option: = "mt-accept" which contains the list of sub-content types that the client = can deal with.  This option would be defined as advisory on the = part of the server, that is it can return content types which are not in = the list, but where options exist in the possible returned content tree = the requested types, in order, SHOULD be the ones chosen by the server. =   I would propose the option be "Non-Critical, Safe, CacheKey, = Repeatable".
>
> I am not sure if I = believe that the new option is part of the cache key or not.  I can = see arguments on both sides, but I think I come down to yes.
>
> Carsten,   I think that this = issue (but maybe not this solution) needs to be put onto the agenda for = the interim meeting next Wed.
>
> = Jim
>
>
> > = -----Original Message-----
> > From: Klaus Hartke = <hartke@projectcool.de>
> > = Sent: Tuesday, February 12, 2019 9:50 AM
> > To: Jim = Schaad <ietf@augustcellars.com>
> > Cc: draft-ietf-core-multipart-ct@ietf.org; core@ietf.org WG <core@ietf.org>
> > Subject: = Re: [core] draft-ietf-core-multipart-ct
> >
> > For context: [1] [2]
> >
> > Jim Schaad wrote:
> > > If = you say ACCEPT 62, do you accept any combination of nested content
> > types?
> >
> = > Yes. A CoAP request can include at most one Accept option and any = response
> > must exactly that value as = Content-Format or be an error response. CoAP
> > = doesn't have a mechanism for negotiating the content formats of
> > representations embedded in other representations. = I stumbled upon the
> > same problem with CoRAL.
> >
> > > Should something about = this be placed into the draft?
> >
> = > Yes. Proposed text: "CoAP doesn't have a mechanism for negotiating = the
> > content formats of representations embedded = in application/multipart-core
> > = representations."
> >
> > > = Also I note that this draft is currently expired and needs to be = reposted.
> >
> > Yes. = Soon=E2=84=A2.
> >
> > Klaus
> >
> > [1]
> = > https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFD= u6dcm
> > I
> > = [2] https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui= 3Gkllk
>
> = _______________________________________________
> core = mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

-- 
Thomas
_______________________________________________core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_53D8A2D1-C936-482A-BE5D-DDC18DF69CC8-- From nobody Sat Mar 2 17:24:41 2019 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 053FA130F7F; Sat, 2 Mar 2019 17:24: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] 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 9xk8LV2QF6-I; Sat, 2 Mar 2019 17:24:33 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA0B124B0C; Sat, 2 Mar 2019 17:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x231OHvB019896; Sun, 3 Mar 2019 02:24:22 +0100 (CET) Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44Blmw6SRrz1Bp8; Sun, 3 Mar 2019 02:24:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Sun, 3 Mar 2019 02:24:15 +0100 Cc: Jim Schaad , Thomas Fossati , draft-ietf-core-multipart-ct@ietf.org, "core@ietf.org WG" , Klaus Hartke , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , =?utf-8?Q?Ari_Ker=C3=A4nen?= X-Mao-Original-Outgoing-Id: 573269053.093425-b20d4197eb6201bad0347812d3db9b50 Content-Transfer-Encoding: quoted-printable Message-Id: <9DEF2381-E0A0-4465-8751-8C29C4F91E31@tzi.org> References: <000901d4c2f8$4b69a640$e23cf2c0$@augustcellars.com> <00f901d4c624$f313cb30$d93b6190$@augustcellars.com> <026901d4c8df$e2251410$a66f3c30$@augustcellars.com> <1D9AA506-85CB-452E-B0DC-4BC099E04F58@gmail.com> <47DAEE52-702A-40C0-9F7C-589CBD0D1C73@gmail.com> <39D848BF-9B8F-4062-9FF0-B8E7D694F849@gmail.com> <004701d4d14e$fb3e10b0$f1ba3210$@augustcellars.com> To: Michael Koster X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] draft-ietf-core-multipart-ct 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, 03 Mar 2019 01:24:40 -0000 On Mar 3, 2019, at 00:26, Michael Koster = wrote: >=20 > Agree, the accept option would be for multipart, Right. > which illustrates why we would need a new option for accept subtype. So that we know what we are talking about, I made a proposal in the = slides for the last interim (2019-02-20): Accept-Embedded Option. But I=E2=80=99m not yet convinced that we actually need that=E2=80=A6 > It follows the use case example in 3.1 of the draft. Right. But I don=E2=80=99t understand why you want an accept for embedded media = types here. Why would I subscribe to a topic and then not take the data? Obviously, the kinds of data sent on a topic need to be part of the = (metadata) definition of the topic=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten >=20 > Michael >=20 >> On Mar 2, 2019, at 3:23 PM, Jim Schaad = wrote: >>=20 >> That would not work if one put in an ACCEPT XX which was not = multipart. Although in that case you could return a content request not = available. >> =20 >> Jim >> =20 >> =20 >> From: Michael Koster =20 >> Sent: Saturday, March 2, 2019 3:13 PM >> To: Jim Schaad >> Cc: Thomas Fossati ; = draft-ietf-core-multipart-ct@ietf.org; core@ietf.org WG ; = Klaus Hartke ; Jaime Jim=C3=A9nez = ; Ari Ker=C3=A4nen >> Subject: Re: [core] draft-ietf-core-multipart-ct >> =20 >> OK so if there's no data I send an empty multipart - (cbor x80) >> =20 >> Sorry, I'm just getting up to speed. Is the latest draft version -02?=20= >> =20 >> Michael >> =20 >>> On Mar 2, 2019, at 2:14 PM, Michael Koster = wrote: >>> =20 >>> To follow on a little, the pub/sub use case is for a variable format = response (case C?) that is a better alternative than adding a new result = code (2.xx) for "no data". >>> =20 >>> There is another use case (like case B) which is for a generalized = hypermedia format that can return links, data, or both depending on the = client workflow. This would eliminate the need for a new content format = like HSML, and would allow arbitrary data formats to be associated with = core-link-format in batch-access collections as per CoRE Interfaces. >>> =20 >>> Best regards, >>> =20 >>> Michael >>> =20 >>>> On Mar 2, 2019, at 2:05 PM, Michael Koster = wrote: >>>> =20 >>>> Hi, >>>> =20 >>>> I am integrating multipart into pub/sub as a way to signal empty = payloads that might result from a subscribe operation where their aren't = any stored data (stale or non-retaining topic) or a retrieve in the same = case. >>>> =20 >>>> We have decided initially not to support multiple content formats = on a topic in pub/sub,where the proker would have to convert, but now it = might be a little easier with multipart, if we build in a subtyping = system as per Jim's email.=20 >>>> =20 >>>> IMO the subtype target attribute at least will be necessary for the = kind of discovery we want to support in pub/sub. I guess subtype accept = header option is going to be needed also, so a pub/sub client can = indicate it accepts emty payload format and e.g. senml. >>>> =20 >>>> In general I think this can work for the pub/sub use case and will = write it in if it makes sense. >>>> =20 >>>> Best regards, >>>> =20 >>>> Michael >>>> =20 >>>> =20 >>>>> On Feb 19, 2019, at 9:48 PM, Jim Schaad = wrote: >>>>> =20 >>>>> I did think about some of this when I put up the proposal. >>>>> =20 >>>>> For case (A), unless it is going to have options while doing a = rigidly structured response, there is no need to have a value different = than Accept 62. In fact if there is really only one structured = response, then there is not a need to have any accept option in the = request at all. >>>>> =20 >>>>> For case (B), I thought about the recursive case and that is why I = put the SHOULD and talked about options between multiple things while = building the response. I don=E2=80=99t think that there are going to be = enough cases of a tree structure being returned that anything needs to = be said about it one way or the other. If that type of detail is really = needed then I would expect that a GET would be replaced by a POST with = the details of the response needed in the content of the POST. >>>>> =20 >>>>> In the semantics, I wanted to provide a minimal amount of = information. Thus the language about using it to provide guidance for = specific pairs of content types that can go into a specific location. = The other place that I was thinking it might be useful would be in the = case of a PUB-SUB server returning multiple content types where the set = of equivalents might be restricted to the requested values rather than = returning all possibilities. >>>>> =20 >>>>> Jim >>>>> =20 >>>>> =20 >>>>> From: Thomas Fossati =20 >>>>> Sent: Tuesday, February 19, 2019 1:58 AM >>>>> To: Jim Schaad >>>>> Cc: Klaus Hartke ; = draft-ietf-core-multipart-ct@ietf.org; core@ietf.org >>>>> Subject: Re: [core] draft-ietf-core-multipart-ct >>>>> =20 >>>>> It has surfaced in the mailing list as well as in private = exchanges that there are two ways of looking at multipart-ct: >>>>> (A) as a mechanism to wrap multiple related things in a rigidly = structured way; >>>>> (B) as a mechanism to aggregate related thingsin flexible ways = (e.g., the EST-coaps credentials). >>>>>=20 >>>>> One approach to content negotiation for multiparts of kind (A) is = to assign the aggregate a separate type altogether (overriding C-F 62 = with something allocated on purpose from the FCFS portion of the = codepoint space). This fits Accept=E2=80=99s semantics well. >>>>>=20 >>>>> Content negotiation with multiparts of kind (B) needs something = like Jim=E2=80=99s proposal. The slight complication that potentially = breaks Jim=E2=80=99s approach is recursion. >>>>>=20 >>>>> To support this, I think the draft could say: >>>>> - multiparts of kind (A) SHOULD override the multipart C-F with = their own; and >>>>> - multiparts of kind (B) MUST not include other multiparts of the = same =E2=80=9Ckind=E2=80=9D. >>>>>=20 >>>>> The above would make a recursive multipart (i.e., a 62 embedded in = another 62) illegal and give Jim=E2=80=99s new content negotiation a = well-defined semantics. >>>>>=20 >>>>> Cheers >>>>>=20 >>>>> On Sat, Feb 16, 2019 at 6:25 PM Jim Schaad = wrote: >>>>> > >>>>> > Looking at this, it does seem to be a strange way to deal with = things. Of course the problem is made even more of a pain if you think = about the possibility of having nested multipart contents. >>>>> > >>>>> > While the following does may not be the greatest solution, I = think that it might be a better answer: >>>>> > >>>>> > 1. Define a new target attribute: "mt-subtypes" which contains = the list of any content type which can be returned in a multipart = content. This could be at the top level or anyplace in a tree. >>>>> > >>>>> > 2. Define a new option: "mt-accept" which contains the list of = sub-content types that the client can deal with. This option would be = defined as advisory on the part of the server, that is it can return = content types which are not in the list, but where options exist in the = possible returned content tree the requested types, in order, SHOULD be = the ones chosen by the server. I would propose the option be = "Non-Critical, Safe, CacheKey, Repeatable". >>>>> > >>>>> > I am not sure if I believe that the new option is part of the = cache key or not. I can see arguments on both sides, but I think I come = down to yes. >>>>> > >>>>> > Carsten, I think that this issue (but maybe not this solution) = needs to be put onto the agenda for the interim meeting next Wed. >>>>> > >>>>> > Jim >>>>> > >>>>> > >>>>> > > -----Original Message----- >>>>> > > From: Klaus Hartke >>>>> > > Sent: Tuesday, February 12, 2019 9:50 AM >>>>> > > To: Jim Schaad >>>>> > > Cc: draft-ietf-core-multipart-ct@ietf.org; core@ietf.org WG = >>>>> > > Subject: Re: [core] draft-ietf-core-multipart-ct >>>>> > > >>>>> > > For context: [1] [2] >>>>> > > >>>>> > > Jim Schaad wrote: >>>>> > > > If you say ACCEPT 62, do you accept any combination of = nested content >>>>> > > types? >>>>> > > >>>>> > > Yes. A CoAP request can include at most one Accept option and = any response >>>>> > > must exactly that value as Content-Format or be an error = response. CoAP >>>>> > > doesn't have a mechanism for negotiating the content formats = of >>>>> > > representations embedded in other representations. I stumbled = upon the >>>>> > > same problem with CoRAL. >>>>> > > >>>>> > > > Should something about this be placed into the draft? >>>>> > > >>>>> > > Yes. Proposed text: "CoAP doesn't have a mechanism for = negotiating the >>>>> > > content formats of representations embedded in = application/multipart-core >>>>> > > representations." >>>>> > > >>>>> > > > Also I note that this draft is currently expired and needs = to be reposted. >>>>> > > >>>>> > > Yes. Soon=E2=84=A2. >>>>> > > >>>>> > > Klaus >>>>> > > >>>>> > > [1] >>>>> > > = https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFDu6dcm >>>>> > > I >>>>> > > [2] = https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui3Gkllk >>>>> > >>>>> > _______________________________________________ >>>>> > core mailing list >>>>> > core@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/core >>>>>=20 >>>>> --=20 >>>>> Thomas >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >=20 From nobody Sat Mar 2 17:44:52 2019 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 20CAB12785F; Sat, 2 Mar 2019 17:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZyteU-6TWEp7; Sat, 2 Mar 2019 17:44:47 -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 5AFDB1200D8; Sat, 2 Mar 2019 17:44:47 -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, 2 Mar 2019 17:44:19 -0800 From: Jim Schaad To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , CC: References: <029e01d46a3e$72bad330$58307990$@augustcellars.com> <87a7mnv7ls.fsf@tzi.org> <990DB036-3144-4729-8FB1-8E25E704E2DA@ericsson.com> In-Reply-To: <990DB036-3144-4729-8FB1-8E25E704E2DA@ericsson.com> Date: Sat, 2 Mar 2019 17:44:17 -0800 Message-ID: <005401d4d162$9f0c9870$dd25c950$@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: AQIik/ezO5bFsiApuf4eflzXupOiVQKk4pXaAjCSqwylNubhYA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] [Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize 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, 03 Mar 2019 01:44:50 -0000 I am responding to the review below in regards to the most recent = version -06. > -----Original Message----- > From: G=C3=B6ran Selander > Sent: Thursday, December 20, 2018 7:14 AM > To: draft-ietf-ace-dtls-authorize@ietf.org; Jim Schaad > ; Roman Danyliw > Subject: Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize >=20 > Hello co-chairs and co-authors, >=20 > Here is a status update on the ACE DTLS profile. >=20 > I committed us to make an update in December. It seems my co-authors > have had a hard time to even discuss the continued work. Some of us = have > been busy with other ACE drafts. >=20 > One contribution from my side: I have gone through the latest review > answer from Olaf to Jim and made some updates to the draft, and some > annotations in the mail below. This includes three out of four issues > discussed at the ACE WG meeting in Bangkok. The first issue - which I = didn't > address - the use of reference tokens, could have an impact on = different > parts of the draft and wanted to discuss with my co-authors first. >=20 > The current version on the ACE Github is thus not complete but still = possible > to review and we have hopefully cut down the number of remaining = issues. I > will not be able to work more on the draft before the week starting = Jan 7. > Perhaps my co-authors can also share when they are available pick up = the > work. >=20 > Happy holidays to all! >=20 > Best regards > G=C3=B6ran >=20 >=20 >=20 > =EF=BB=BFOn 2018-11-05, 16:59, "Ace on behalf of Olaf Bergmann" bounces@ietf.org on behalf of bergmann@tzi.org> wrote: >=20 > Jim, >=20 > Thank you for this very useful review. Please find our comments = inline: >=20 > Jim Schaad writes: >=20 > > Section 3.3 - Figure 4 - Where is the 'alg' parameter defined at = that level? >=20 > See next comment. >=20 > [GS] alg parameter included >=20 > > Section 3.3 - I am always bothered by the fact that PSK should = really be > PSS > > at this point. The secret value is no longer a key and thus = does not > > necessarily have a length. There is also a problem of trying to = decide > what > > the length of this value would be based on the algorithm. If = the client > > offers TLS_PSK_WITH_AES_128_CCM_8 and > TLS_PSK_WITH_AES_256_CCM_8 (I may > > have gotten these wrong but the intent should be understandable) = then > what > > length is the PSK supposed to be? >=20 > I think what you are saying is that for the shared secret (k) in = the > COSE_Key structure in Fig. 4, the AS needs to tell C what to do = with > that shared secret? This was the intention of the alg parameter = (which > has a not-so-useful value in this example). Some of what is done here makes sense and some of it makes no sense at = all. Happy with the removal of the "alg" parameter in the root map. =20 Happy with the addition of the kid parameter in the COSE_Key object = since this is required for doing DTLS w/o sending the token as the = identifier. I have no idea what the algorithm is doing here? This is not currently = a COSE algorithm, it is a TLS algorithm and thus would not make a great = deal of sense. The terms of what the PSK length should be would be = better covered by a statement along the lines of "When offering and/or = accepting a TLS cryptographic suite, the length of the PSK should be at = least as long as the symmetric encryption algorithms that are offered." = This may already be pointed to in the TLS documents and thus can be = referenced to rather than stated explicitly. When looking at the KDF option that you are providing. I don't = understand why you don't just make the KDF function and the length of = the secret to be derived as pre-configured properties. There is = absolutely nothing that prevents this from being a 141 byte value. =20 I am not seeing anything in the security considerations about protecting = this secret and what all will be available to an attacker in the event = that this secret is leaked. Specifically, it allows for any previously = recorded session to be decrypted if the KID is leaked, such as using the = KID as the key identifier in the handshake protocol rather than sending = across the CWT (assuming that it is encrypted). =20 It will allow for an impersonation attack to occur in the event that the = KID for a client in the event that the KID is leaked as the attacker = would be able to create the same token that is passed to the client. >=20 > > Section 3.3 - Figure 5 - Is this defining a new set of entries = for cnf or is > > there a missing layer someplace? >=20 > This is indeed a new set of entries. An internal discussion = between the > draft authors led to the opinion that we cannot use a COSE_Key = structure > in the cnf structure as this would have different semantics as = intended > here. We came to the conclusion that for key derivation, listing = the > required fields directly in the cnf structure is the cleanest = solution. >=20 > [GS] new layer added, called ACE_Salt. This does not seem to be what was implemented in the current draft. > > Section 4 - The requirement that the "kid" be in a previously = issued token > > would have problems with this if you were to use the "kid" of an = RPK > which > > can be constant rather than being changed on each newly created = token. >=20 > To solve this we could require that the COSE_Key structure for = RS's RPK > in the AS-to-Client response must also have a kid. Section 4 does = not > prevent the kid to be constant. >=20 > > Section 5 - this seems to be a very strange place to define the = new > > parameter. >=20 > True. How about moving this parameter to Section 4? >=20 > [GS] Change already done. This seems to have just vanished - is that want is desired? Jim >=20 > > Section 8 - you need to put your kid in the IANA considerations = as well >=20 > Fixed. >=20 =20 > Gr=C3=BC=C3=9Fe > Olaf >=20 >=20 >=20 From nobody Sat Mar 2 19:41:55 2019 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 C31D5129A87 for ; Sat, 2 Mar 2019 19:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ogau0K5oEV6d for ; Sat, 2 Mar 2019 19:41:52 -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 DFAAA1200D8 for ; Sat, 2 Mar 2019 19:41:51 -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, 2 Mar 2019 19:41:39 -0800 From: Jim Schaad To: 'Michael Koster' , =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , =?iso-8859-1?Q?'Jaime_Jim=E9nez'?= CC: References: <904CFCA3-F10A-4018-88AB-E859743B3E70@gmail.com> In-Reply-To: <904CFCA3-F10A-4018-88AB-E859743B3E70@gmail.com> Date: Sat, 2 Mar 2019 19:41:37 -0800 Message-ID: <006101d4d173$036f3150$0a4d93f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL/ukJMv7OBeAhozsYlCRblR68qjAJlYhGfo5BEoDA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Pub/Sub update to use the core multipart content format 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, 03 Mar 2019 03:41:54 -0000 Michael, When I was suggesting using multipart I was thinking more in term of publishing rather than retrieval. It would allow for multiple formats = to be sent to the pub/sub server which the server would not need to think = about doing format conversion on but could still return only a single format. I don't think that one wants to do a multipart retrieval as a general = rule unless the content really a multipart thing. I guess that the server = would need to be told which way to treat things, but that seems to be a = reasonable query parameter for topic creation. Jim > -----Original Message----- > From: core On Behalf Of Michael Koster > Sent: Saturday, March 2, 2019 3:24 PM > To: Ari Ker=E4nen ; Jaime Jim=E9nez > > Cc: core@ietf.org WG > Subject: Re: [core] Pub/Sub update to use the core multipart content format >=20 > OK, I read the multipart draft (expired?) For the no data case we will just > send an empty multipart payload (cbor x80). >=20 > It seems like every implementation of pub/sub will be required to = support > only link-format and multipart. The subtype support will be on a topic basis > and maybe a broker should have some way to list a set of supported > subtopics that it can handle. To remind people, a coap pub/sub broker > doesn't have any notion of "resource state" other than a stored > representation. >=20 > Best regards, >=20 > Michael >=20 > > On Mar 2, 2019, at 5:27 AM, Michael Koster > wrote: > > > > Hi, > > > > I am editing the pub/sub draft today and thinking about the = multipart > content format as a way to provide a subscribe or retrieve response = for the > no data case. > > > > It seems to require that the pub/sub client always support the = multipart > format, with no content being one of the format options signaled by > something like "maybe". > > > > Does this seem right to you also? Do we need to invent a new empty > format code instead of a response code? > > > > Best regards, > > > > Michael > > > > > > > > >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Mar 3 04:54:07 2019 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 3030C12D4EC for ; Sun, 3 Mar 2019 04:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-NJSazgcXXQ for ; Sun, 3 Mar 2019 04:54:02 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 A659D1295D8 for ; Sun, 3 Mar 2019 04:54:02 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id c17so1189772plz.13 for ; Sun, 03 Mar 2019 04:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/mfyR3+xGlD/hXR2C/cevEaYtuXy+F1OnAsdZChghcg=; b=YpsR8dpE/aFw5W2P/k/hQek3gZDn277CPsjWLFWictPhdqbWCA2Emwh5RwHDUY5IUb Z419uXtvYB5jFnBvbZePxcQ+ynbRmz2elfs6zVixi7VUAb2MPEIcZ1rFXsAehbv5C3uE B20MKzN0Viqf2ALJD4cpg52sG95xFpTIT+rFGDzEdBsXAUbYgMsakqL24o0cqcLw2b+3 iecrJQkPqY0NjwI/A7Kb9+2xQ9YzbLWN8zs7X7LiWQ9LRVjsFqrNtdSzoARUv/kKSKu2 ONLOA/ifmwRk1DNDsnvLhg9OecPKL5K0W1HxGqUxjrXgBbgVfCHmCSPbfuvYnndD9mfR qiQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/mfyR3+xGlD/hXR2C/cevEaYtuXy+F1OnAsdZChghcg=; b=CtGcJ9W3JTC9YKwAx6k9NrrTmXGRBq2k2axHoWMu6e3ZkcHWnM2SWeEV9n7eYXGJjl l5Kf5lshvx7CXAecL6DC7FJfFJGrrl2AL2FICVjo8HalZvFaGthMT4UuSpin/fRFieYM Thvq7KlcWKykAS1fpX8lK/MbcozCSwTB9FNzQFcNDYfDkxncvlkpX1Z9Y3u+IYGiH0Yk 6C+dKd/FKb5EbMoOsQDXU6RDm5vu7wgCWrlD1lroFJbah1ugqsdcVMbYnEfQikz3TTT7 dYGNg/uVTTThTiy/VWchNLIqDU4JAf1L2mkhv+mfS8CAD94plkcwF4CY7JtuW7RI+OXb GmgQ== X-Gm-Message-State: APjAAAW32sNHy65oBxhVvkiXCezu5SnPtLAFlit6vPwqJywao9cwP0jY rRsKHSRphMQQ5ghZrET8f0c= X-Google-Smtp-Source: APXvYqwegO70YJ1e0CvS3p6okIt2mSYrFHPpgXW13jDv2MXObFg3K45g5qeAJHghhvZlH4zNmhM9Vg== X-Received: by 2002:a17:902:34a:: with SMTP id 68mr14622064pld.327.1551617641492; Sun, 03 Mar 2019 04:54:01 -0800 (PST) Received: from [172.16.0.3] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id g12sm4400318pgr.76.2019.03.03.04.54.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Mar 2019 04:54:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: <006101d4d173$036f3150$0a4d93f0$@augustcellars.com> Date: Sun, 3 Mar 2019 04:53:59 -0800 Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <27BF3A10-B9D8-435D-BA4E-64C244E516B2@gmail.com> References: <904CFCA3-F10A-4018-88AB-E859743B3E70@gmail.com> <006101d4d173$036f3150$0a4d93f0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Pub/Sub update to use the core multipart content format 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, 03 Mar 2019 12:54:05 -0000 Hi Jim, I am proposing to use the multipart response to indicate that there = aren't data to be returned on a subscribe operation. We were proposing a new response code, but there was a lot of pushback = on doing this, so we want to try the multipart format with an empty = array (cbor x08). It does require that a pub/sub client learn a little cbor and be able to = unpack the intended payload from the embedded string. Would the new response code be a better option after all? It it easier = to teach clients about a new 2.xx response than a new format? Best regards, MIchael > On Mar 2, 2019, at 7:41 PM, Jim Schaad wrote: >=20 > Michael, >=20 > When I was suggesting using multipart I was thinking more in term of > publishing rather than retrieval. It would allow for multiple formats = to be > sent to the pub/sub server which the server would not need to think = about > doing format conversion on but could still return only a single = format. >=20 > I don't think that one wants to do a multipart retrieval as a general = rule > unless the content really a multipart thing. I guess that the server = would > need to be told which way to treat things, but that seems to be a = reasonable > query parameter for topic creation. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: core On Behalf Of Michael Koster >> Sent: Saturday, March 2, 2019 3:24 PM >> To: Ari Ker=C3=A4nen ; Jaime Jim=C3=A9nez >> >> Cc: core@ietf.org WG >> Subject: Re: [core] Pub/Sub update to use the core multipart content > format >>=20 >> OK, I read the multipart draft (expired?) For the no data case we = will > just >> send an empty multipart payload (cbor x80). >>=20 >> It seems like every implementation of pub/sub will be required to = support >> only link-format and multipart. The subtype support will be on a = topic > basis >> and maybe a broker should have some way to list a set of supported >> subtopics that it can handle. To remind people, a coap pub/sub broker >> doesn't have any notion of "resource state" other than a stored >> representation. >>=20 >> Best regards, >>=20 >> Michael >>=20 >>> On Mar 2, 2019, at 5:27 AM, Michael Koster >> wrote: >>>=20 >>> Hi, >>>=20 >>> I am editing the pub/sub draft today and thinking about the = multipart >> content format as a way to provide a subscribe or retrieve response = for > the >> no data case. >>>=20 >>> It seems to require that the pub/sub client always support the = multipart >> format, with no content being one of the format options signaled by >> something like "maybe". >>>=20 >>> Does this seem right to you also? Do we need to invent a new empty >> format code instead of a response code? >>>=20 >>> Best regards, >>>=20 >>> Michael >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 From nobody Sun Mar 3 11:39:16 2019 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 2277D12E04D for ; Sun, 3 Mar 2019 11:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 8m0n_6hYoo4Z for ; Sun, 3 Mar 2019 11:39:11 -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 14AEB124D68 for ; Sun, 3 Mar 2019 11:39:10 -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, 3 Mar 2019 11:39:03 -0800 From: Jim Schaad To: 'Michael Koster' CC: =?utf-8?Q?'Ari_Ker=C3=A4nen'?= , =?utf-8?Q?'Jaime_Jim=C3=A9nez'?= , References: <904CFCA3-F10A-4018-88AB-E859743B3E70@gmail.com> <006101d4d173$036f3150$0a4d93f0$@augustcellars.com> <27BF3A10-B9D8-435D-BA4E-64C244E516B2@gmail.com> In-Reply-To: <27BF3A10-B9D8-435D-BA4E-64C244E516B2@gmail.com> Date: Sun, 3 Mar 2019 11:39:02 -0800 Message-ID: <006e01d4d1f8$c30ed210$492c7630$@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: AQL/ukJMv7OBeAhozsYlCRblR68qjAJlYhGfAZ8INPoB4zUm9aN1PPVQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Pub/Sub update to use the core multipart content format 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, 03 Mar 2019 19:39:14 -0000 If I am being honest, I would really rather it be returned as "204 (No = Content)". That is, the server successfully processed the request and = there is no content to be returned as this time. I realize that this is = not the precise definition of this code, but I think that the problem = with using the multipart response is that there are other places where a = similar response may be required. Consider asking a sensor for a = reading, but the sensor does not have a current value. What is the = response code that it should return for that? In some ways it would = seem that a better answer might be 5.03 with a suggested retry. Jim > -----Original Message----- > From: Michael Koster > Sent: Sunday, March 3, 2019 4:54 AM > To: Jim Schaad > Cc: Ari Ker=C3=A4nen ; Jaime Jim=C3=A9nez > ; core@ietf.org > Subject: Re: [core] Pub/Sub update to use the core multipart content = format >=20 > Hi Jim, >=20 > I am proposing to use the multipart response to indicate that there = aren't > data to be returned on a subscribe operation. >=20 > We were proposing a new response code, but there was a lot of pushback = on > doing this, so we want to try the multipart format with an empty array = (cbor > x08). >=20 > It does require that a pub/sub client learn a little cbor and be able = to unpack > the intended payload from the embedded string. >=20 > Would the new response code be a better option after all? It it easier = to > teach clients about a new 2.xx response than a new format? >=20 > Best regards, >=20 > MIchael >=20 > > On Mar 2, 2019, at 7:41 PM, Jim Schaad = wrote: > > > > Michael, > > > > When I was suggesting using multipart I was thinking more in term of > > publishing rather than retrieval. It would allow for multiple = formats > > to be sent to the pub/sub server which the server would not need to > > think about doing format conversion on but could still return only a = single > format. > > > > I don't think that one wants to do a multipart retrieval as a = general > > rule unless the content really a multipart thing. I guess that the > > server would need to be told which way to treat things, but that = seems > > to be a reasonable query parameter for topic creation. > > > > Jim > > > > > >> -----Original Message----- > >> From: core On Behalf Of Michael Koster > >> Sent: Saturday, March 2, 2019 3:24 PM > >> To: Ari Ker=C3=A4nen ; Jaime Jim=C3=A9nez > >> > >> Cc: core@ietf.org WG > >> Subject: Re: [core] Pub/Sub update to use the core multipart = content > > format > >> > >> OK, I read the multipart draft (expired?) For the no data case we > >> will > > just > >> send an empty multipart payload (cbor x80). > >> > >> It seems like every implementation of pub/sub will be required to > >> support only link-format and multipart. The subtype support will be > >> on a topic > > basis > >> and maybe a broker should have some way to list a set of supported > >> subtopics that it can handle. To remind people, a coap pub/sub = broker > >> doesn't have any notion of "resource state" other than a stored > >> representation. > >> > >> Best regards, > >> > >> Michael > >> > >>> On Mar 2, 2019, at 5:27 AM, Michael Koster > >> wrote: > >>> > >>> Hi, > >>> > >>> I am editing the pub/sub draft today and thinking about the > >>> multipart > >> content format as a way to provide a subscribe or retrieve response > >> for > > the > >> no data case. > >>> > >>> It seems to require that the pub/sub client always support the > >>> multipart > >> format, with no content being one of the format options signaled by > >> something like "maybe". > >>> > >>> Does this seem right to you also? Do we need to invent a new empty > >> format code instead of a response code? > >>> > >>> Best regards, > >>> > >>> Michael > >>> > >>> > >>> > >>> > >> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > From nobody Sun Mar 3 13:50:28 2019 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 CD22D1200ED for ; Sun, 3 Mar 2019 13:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E98zPPjMkEgR for ; Sun, 3 Mar 2019 13:50:25 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0: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 E5B1212E04D for ; Sun, 3 Mar 2019 13:50:24 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id j5so1513562pfa.2 for ; Sun, 03 Mar 2019 13:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DE9u9C5/HNmvGEGQdeNG7d2ZNZDCK9MWhItsEEZ2LbU=; b=UJ7CoQbbR/viqvnqzvYhdKgXRNooKrLhlldInDdug4RHqwKoH2c5DOt0IfRUs7DLyo xXbKC6PgS1e75JZ8RhCNTiYIRtqeZ0/uXhYMfdpgLRHvIjREKb6bt8fEvCaUu/yQhxLS WYDQzemFwLtRkfcoTWdb+shVAUACUcxGwAbKowaHWhWOvGRiu5VCox/lHoapL5GYyltf SVwxjKd2w/1v4kpdxFbYeMQDoMSTFnQPrHoA4U4oCQYBWubCxQLj5zWf8OZykUkFkId3 kuFrY/qKzZ18ZpzajQgXnIzaMzjBr4jEFs1KuRqlvH5GSIpV00+I8rPuJA8UI/Eb4IZ3 cRNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DE9u9C5/HNmvGEGQdeNG7d2ZNZDCK9MWhItsEEZ2LbU=; b=F5d64QyQRqBXAWXmWyhpXFoSgGvVpTStifXkTdklkCmTOC1rn/5s1+t1nJyygUusOd PUe++XfUeBmjmgdt4o7v/TIiVGaPAnDe3KALRh5luV+LmIALk3Rrh4H975y66HWOPW0C WDj9A+MseImocjaaJeMDw3VsGVUrs7Um01b86ZCWxoUwnGHsuhRlkzkMMXrV5meL37a4 S21zmMMgtHo9+v3sZA0f6x+9bG+hofypNtQ5VGZaj6tgUQU4vARYDCjViiPDj3MiEk+4 yiSY9GpNan+CR0zTtufzNxPko8uUHZpsK19Cegtuk0MlMCsHAIWmIVdHYBMnxMpe2Y53 luBg== X-Gm-Message-State: APjAAAUa1dnPDh1eBJ+rjS9XZDdcxSc0YB+WiDvoymqcAPrKkq910uk7 /+VyyTKlRKmB72+p/xIAUjU= X-Google-Smtp-Source: APXvYqxhkgo/KoqYzsWqSzfFWeEEXJkcXetoBlBOoS69vgOxG7At1/fGMGo1F1Eg1wa+TAZ8YTnF0A== X-Received: by 2002:a17:902:8b82:: with SMTP id ay2mr16864305plb.64.1551649824129; Sun, 03 Mar 2019 13:50:24 -0800 (PST) Received: from [172.16.0.3] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id b70sm6871507pfm.6.2019.03.03.13.50.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Mar 2019 13:50:23 -0800 (PST) From: Michael Koster Message-Id: <392C345A-13FA-452A-9370-ED6B98CD58E9@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_651AAE21-3DB7-4B01-9809-678D6E779E9E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 3 Mar 2019 13:50:21 -0800 In-Reply-To: <006e01d4d1f8$c30ed210$492c7630$@augustcellars.com> Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , core@ietf.org To: Jim Schaad References: <904CFCA3-F10A-4018-88AB-E859743B3E70@gmail.com> <006101d4d173$036f3150$0a4d93f0$@augustcellars.com> <27BF3A10-B9D8-435D-BA4E-64C244E516B2@gmail.com> <006e01d4d1f8$c30ed210$492c7630$@augustcellars.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Pub/Sub update to use the core multipart content format 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, 03 Mar 2019 21:50:27 -0000 --Apple-Mail=_651AAE21-3DB7-4B01-9809-678D6E779E9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The http semantics for 202 Accepted might be another option. It defers = processing until later. We currently propose 2.07 to be added to signal the no-data subscription = response. It could be semantically aligned with HTTP or we could have it = mean exactly what we want it to mean. A broker can always offer the multipart format as an alternate way to = interact if we want to allow both. If the client sends multipart in the = accept header the server could signal no data through the content = format. Could we allow the client to choose content-centric signaling through = content negotiation? Best regards, Michael PS Sending an empty payload might work for some formats, and in some = libraries, e.g. with senml+json [] or cbor x80, but it doesn't seem = reliable for all possible formats.=20 > On Mar 3, 2019, at 11:39 AM, Jim Schaad = wrote: >=20 > If I am being honest, I would really rather it be returned as "204 (No = Content)". That is, the server successfully processed the request and = there is no content to be returned as this time. --Apple-Mail=_651AAE21-3DB7-4B01-9809-678D6E779E9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The http semantics for 202 Accepted might be another option. = It defers processing until later.

We currently propose 2.07 to be added to signal the no-data = subscription response. It could be semantically aligned with HTTP or we = could have it mean exactly what we want it to mean.

A broker can always = offer the multipart format as an alternate way to interact if we want to = allow both. If the client sends multipart in the accept header the = server could signal no data through the content format.

Could we allow the = client to choose content-centric signaling through content = negotiation?

Best regards,

Michael

PS Sending an empty payload might work for some formats, and = in some libraries, e.g. with senml+json [] or cbor x80, but it doesn't = seem reliable for all possible formats. 

On Mar 3, 2019, at 11:39 AM, Jim Schaad <ietf@augustcellars.com> wrote:

If I am being honest, I would = really rather it be returned as "204 (No Content)".  That is, the = server successfully processed the request and there is no content to be = returned as this time.

= --Apple-Mail=_651AAE21-3DB7-4B01-9809-678D6E779E9E-- From nobody Sun Mar 3 17:17:05 2019 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 30B59130E6F; Sun, 3 Mar 2019 17:16:59 -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_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 dn8u3q7Yviya; Sun, 3 Mar 2019 17:16:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DB71271FF; Sun, 3 Mar 2019 17:16:56 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8758638263; Sun, 3 Mar 2019 20:16:50 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 01AD0230F; Sun, 3 Mar 2019 20:16:53 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0047BC09; Sun, 3 Mar 2019 20:16:53 -0500 (EST) From: Michael Richardson To: cbor@ietf.org, core@ietf.org X-Attribution: mcr 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: [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 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, 04 Mar 2019 01:16:59 -0000 --=-=-= Content-Type: text/plain I wonder if these two drafts wouldn't be better off in CBOR WG? draft-ietf-core-sid-05 YANG Schema Item iDentifier (SID) draft-ietf-core-yang-cbor-07 CBOR Encoding of Data Modeled with YANG Well, anything that would allow the SID to progress enough for the registries to be created so that they can be used. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlx8fIUACgkQgItw+93Q 3WUXJgf8D37wFwkWoPOTHw25FtIEGr/xd+/82MWq/at8Sc90RQ1Bs49zalaxSexD UmnXm7Ua1eXA1RkbJj3CtoBEkuMaYCTF1NnxGjoBqkPlPjFxxQnipZhfeac87+7N RrV4npcz8FaUjTjlvXiWFKa/q2qSfSATvVRl4Wn+ujQTkvmsAfDmgwDGbrEIDjgO lGTDJOHYXxw6g+SEPjDqSe7JS2iZfdp2Xpbe9FCwLnM//JYCB6fUhj72a+oWymGJ WPRMGTbv+8CxJ12x0+728t2au90bm4chz1I3JiquTbfAp2ksS08xNDDvya4aVJjD Q6ZcO7brh9HslS7HhR7pqO3HCuu6hQ== =KonB -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 4 08:38:43 2019 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 77FCE12D84C for ; Mon, 4 Mar 2019 08:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 DbU_8xMB1YQZ for ; Mon, 4 Mar 2019 08:38:39 -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 DD5B31228B7 for ; Mon, 4 Mar 2019 08:38:38 -0800 (PST) Received: from mail-qt1-f175.google.com ([209.85.160.175]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1h0qbs-0003kl-Ve; Mon, 04 Mar 2019 17:38:37 +0100 Received: by mail-qt1-f175.google.com with SMTP id u7so5782041qtg.9 for ; Mon, 04 Mar 2019 08:38:36 -0800 (PST) X-Gm-Message-State: APjAAAXaIWu9zKwGfZ4zWSDWZV/5zEiK/vqwGhEq5yhutvjAQ1S08gge VwCIBbMlO39NlW7SwLOWA9klXDenPN3BMIHJkOk= X-Google-Smtp-Source: APXvYqw1YwBsjKSylHyWCyUp+8NVxSMUrT3smlEk5ftphY+CQqhePIIHPHZWh8NPD1NfdSgLHBjMTSldhTa4STiENew= X-Received: by 2002:ac8:2562:: with SMTP id 31mr15496973qtn.253.1551717515922; Mon, 04 Mar 2019 08:38:35 -0800 (PST) MIME-Version: 1.0 References: <095ADBC4-3F53-46D1-9114-71344EB76B4B@tzi.org> In-Reply-To: From: Klaus Hartke Date: Mon, 4 Mar 2019 17:38:00 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "core@ietf.org" , "t2trg@irtf.org" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1551717518; c139a1bb; X-HE-SMSGID: 1h0qbs-0003kl-Ve Archived-At: Subject: Re: [core] CoRAL @ IETF104 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, 04 Mar 2019 16:38:41 -0000 Matthias Kovatsch wrote: > Carsten Bormann wrote: > > Klaus Hartke wrote: > > > tentatively on Thursday in the first afternoon session. > > > > Rats! [sic] > > I would also prefer a different slot... Since I got more comments like this off-list, I propose to have the CoRAL side-meeting on Wednesday in the 15:00-17:00 slot. It's a bit unpredictable right now what else might be in that slot, but this has the least conflicts right now. Room reserved. If you are interested in hypermedia in constrained RESTful environments (Link Format, CoRAL, ...) but haven't filled out the form yet, please do: https://goo.gl/forms/Qu3CH8VyXC5Aslv23 Klaus From nobody Tue Mar 5 03:13:50 2019 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 3209C13103F; Tue, 5 Mar 2019 03:13:49 -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_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 OSKGvEmFKw42; Tue, 5 Mar 2019 03:13:47 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 54E2D12941A; Tue, 5 Mar 2019 03:13:47 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7EE4071795A50F28F7A5; Tue, 5 Mar 2019 11:13:45 +0000 (GMT) Received: from LHREML505-MBX.china.huawei.com ([169.254.10.40]) by lhreml704-cah.china.huawei.com ([10.201.108.45]) with mapi id 14.03.0415.000; Tue, 5 Mar 2019 11:13:43 +0000 From: Frank MATTHIAS KOVATSCH To: Klaus Hartke , "draft-hartke-t2trg-coral@ietf.org" , "T2TRG@irtf.org" , "core@ietf.org WG" Thread-Topic: [core] [T2TRG] Review of CoRAL Thread-Index: AQHUuYYTkemzU7gmakSHR2RZsbCVjaXJmq8AgDNtJUA= Date: Tue, 5 Mar 2019 11:13:42 +0000 Message-ID: References: <20181031164534.GA4995@hephaistos.amsuess.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.62.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [core] [T2TRG] Review of CoRAL 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, 05 Mar 2019 11:13:49 -0000 RGVhciBsaXN0cywNCmRlYXIgS2xhdXMNCg0KSGVyZSBhcmUgc29tZSB0aG91Z2h0cyBvbiBoeXBl cm1lZGlhLCBpbiBwYXJ0aWN1bGFyIHRoZSBmb3JtIGNvbmNlcHQsIGZyb20gYW4gb3JpZ2luYWxs eSBpbnRlcm5hbCBkaXNjdXNzaW9uIHdpdGggS2xhdXMgdG8gYWxpZ24gQ29SQUwgYW5kIFdvVCBU RC4NCg0KU28gZmFyLCB3ZSBhZ3JlZSB0aGF0IGZvcm1zIHNob3VsZCBiZSBjb21wcmlzZWQgb2Y6 DQoqIGZvcm0gY29udGV4dCAob24gd2hhdCBpcyB0aGUgb3BlcmF0aW9uIHBlcmZvcm1lZCkNCiog b3BlcmF0aW9uIHR5cGUgKGlkZW50aWZpZXIgZm9yIHRoZSBvcGVyYXRpb24gYW5hbG9nb3VzIHRv IHJlbCBvZiBsaW5rcykNCiogc3VibWlzc2lvbiBUYXJnZXQgKHRhcmdldCBVUkkgZm9yIHRoZSBy ZXF1ZXN0KQ0KKiBvcHRpb25hbGx5LCBmb3JtIGZpZWxkcyAoYWRkaXRpb25hbCBwYXJ0cyBvZiB0 aGUgcmVxdWVzdCBwcmUtc2V0IGJ5IHRoZSBzZXJ2ZXIpDQoNCkl0IHNob3VsZCBiZSBwb2ludGVk IG91dCB0aGF0IHRoZSBmb3JtIGZpZWxkcyBhcmUgbm90IGxpa2UgdGhlIGlucHV0cyBvZiBIVE1M IGZvcm1zIHRvIGRlZmluZSB0aGUgcGF5bG9hZCwgYnV0IG1heSBhcHBseSB0byBhbnkgcGFydCBv ZiB0aGUgcmVxdWVzdC4gQSB1c2UgY2FzZSBmb3IgVEQgZm9ybXMgaXMgQ29BUCBvcHRpb25zIHRo YXQgaGF2ZSB0byBiZSBzZXQgZm9yIGNlcnRhaW4gc2VydmVycyAoZS5nLiwgT0NGIGRldmljZXMp LiBJbiBnZW5lcmFsLCBmb3JtcyBhcmUgcmVhbGx5IGxpa2UgcHJpbnRlZCBmb3JtcyBhdCBzb21l IGFnZW5jeTogdGhlIGNyZWF0b3IgKHNlcnZlcikgcHJlZmlsbHMgc29tZSBwYXJ0cyBhY2NvcmRp bmcgdG8gaXRzIHByb2Nlc3MgYW5kIGxlYXZlcyBzb21lIHBhcnRzIG9wZW4gdG8gYmUgZmlsbGVk IGJ5IHRoZSBjbGllbnQuIEdvaW5nIGJhY2sgdG8gcHJvdG9jb2wgbWVzc2FnZXMsIGZvcm1zIGFy ZSBiYXNpY2FsbHkgcmVxdWVzdCB0ZW1wbGF0ZXMsIGFuZCB3ZSBoYXZlIHRvIGRlY2lkZSB3aGlj aCBmaWVsZHMgbXVzdCBhbHdheXMgYmUgdGhlcmUgdG8gbWFrZSBhIHZhbGlkIHJlcXVlc3QuDQoN CkkgdGhpbmsgdGhlIF9yZXF1ZXN0IG1ldGhvZF8gc2hvdWxkIGFsc28gYmUgbWFuZGF0b3J5LiBG b3IgbWUsIGl0IGlzIHRoZSBjZW50cmFsIHJlYXNvbiB0byBpbnRyb2R1Y2UgZm9ybXMsIGJlY2F1 c2Ugc28gZmFyIHNlcnZlcnMgaGF2ZSBub3QgYmVlbiBhYmxlIHRvIGRpcmVjdGx5IHRlbGwgY2xp ZW50cyB3aGF0IG1ldGhvZCBpcyBleHBlY3RlZDsgaXQgaGFzIGFsd2F5cyBiZWVuIGRlZmluZWQg b3V0LW9mLWJhbmQsIGUuZy4sIGFzIHBhcnQgb2YgbWVkaWEgdHlwZSBkZWZpbml0aW9ucyBvciB1 c2luZyB0aGUgT1BUSU9OUyBtZXRob2QgKGhvd2V2ZXIgd2l0aG91dCBhIG1hcHBpbmcgdG8gd2hh dCB0aGV5IGRvKS4NCkhvd2V2ZXIsIHRoZSBhdmFpbGFibGUgc2V0IG9mIG1ldGhvZHMgZGVwZW5k cyBvbiB0aGUgcHJvdG9jb2wuIFRodXMsIHRoZSByZXF1ZXN0IG1ldGhvZCBmaWVsZCBpcyBhY3R1 YWxseSBwcm90b2NvbC1kZXBlbmRlbnQsIHdoaWNoIGlzIHdoeSBURCBtYWtlcyB0aGUgZmllbGQg bmFtZSBhbHNvIHByb3RvY29sLWRlcGVuZGVudCAoImh0dHA6bWV0aG9kIiwgImNvYXA6bWV0aG9k IiwgLi4uKSAtLSB0cnVlIHRoZXJlIGlzIGFuIG92ZXJsYXAgYmV0d2VlbiBIVFRQIGFuZCBDb0FQ LCBidXQgdGhlIHZhbHVlcyBjb21lIGZyb20gYSBkaWZmZXJlbnQgZG9tYWluLiBUaGlzIHdvdWxk IGJlIGFuIGFyZ3VtZW50IHRvIHB1dCB0aGVzZSBmaWVsZHMgdW5kZXIgdGhlIG9wZW4tZW5kZWQg Zm9ybSBmaWVsZHMuDQoNClRoZSBfc3VibWlzc2lvbiB0eXBlXyB0byBkZWZpbmUgdGhlIHBheWxv YWQgZm9ybWF0IGlzIGRlZmluaXRlbHkgaW1wb3J0YW50LCBidXQgbm90IHJlcXVpcmVkIHdoZW4g dGhlcmUgaXMgbm8gcGF5bG9hZC4gVGhpcyBtYWtlcyBpdCBoYXJkIHRvIGRlY2lkZSB3aGV0aGVy IGl0IHNob3VsZCBiZSBhbiBleHBsaWNpdCBmaWVsZCBvciBqdXN0IGJlIHBhcnQgb2YgdGhlIG9w ZW4tZW5kZWQgZm9ybSBmaWVsZHMuIEkgdGVuZCBtb3JlIHRvIGNvbmRpdGlvbmFsbHkgbWFuZGF0 b3J5IGZpZWxkLg0KDQpNYW5kYXRvcnkgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbiB0aGUgZmll bGRzIG11c3QgYWx3YXlzIGJlIHNlcmlhbGl6ZWQuIFNpbmNlIHRoZSBvcGVyYXRpb24gdHlwZSBt dXN0IGJlIHVuZGVyc3Rvb2QgYnkgY2xpZW50cywgSSBjb3VsZCBpbWFnaW5lIHRoYXQgaXRzIGRl ZmluaXRpb24gbWF5IGluY2x1ZGUgZGVmYXVsdCB2YWx1ZXMgZm9yIGZpZWxkcyB0aGF0IGFyZSBu b3Qgc2VyaWFsaXplZC4gT3ZlcmFsbCwgdGhpcyBpcyBqdXN0IGFuIG9wdGltaXphdGlvbiB0byB0 cmFuc21pdCBsZXNzIC0tIHRoZSBpbmZvcm1hdGlvbiBtdXN0IHN0aWxsIGdvIGludG8gdGhlIHJl cXVlc3QuDQoNCg0KTG9va2luZyBhIGxvdCBhdCBSRkMgODI4OCBmb3IgdGhlIGRlZmluaXRpb24g b2YgZm9ybXMsIEkgbm90aWNlZCBxdWl0ZSBhIG1lc3MgYXJvdW5kIFVSSSB2cyBJUkkuIENvbnRl eHQgYW5kIHRhcmdldCBhcmUgZGVmaW5lZCBhcyBJUkkgdGhhdCBpbiBtb3N0IGNhc2VzIGFyZSBh bHNvIFVSSXMsIGJlY2F1c2UgcHJvdG9jb2wgbGltaXRhdGlvbnMuIEJ1dCB0aGVuIGZvciB0aGUg RXh0ZW5zaW9uIFJlbGF0aW9uIFR5cGVzLCBSRkMgODI4OCBvbmx5IHRhbGtzIGFib3V0IFVSSXMg KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4Mjg4I3NlY3Rpb24tMi4xLjIpLCBhbHRo b3VnaCB0aGlzIGlzIHRoZSBwbGFjZSB3aGVyZSB3ZSBhY3R1YWxseSBvbmx5IG5lZWQgYSB1bmlx dWUgc3RyaW5nLiBNYXliZSB0aGlzIGlzIGEgbG9zdCBiYXR0bGUgYW55d2F5LCBzaW5jZSBlbHNl d2hlcmUgdGhleSBhcmUgVVJMcy4uLg0KDQpDb1JBTCB0cmllcyB0byBtaW5pbWl6ZSB0aGUgcHJv Y2Vzc2luZyBvZiBJUkkvVVJJcyBieSBjbGllbnRzLiBJZGVhbGx5LCB0aGV5IGFyZSBqdXN0IHNv bWUgYnl0ZXMgdGhhdCBhcmUgZGVmaW5lZCBieSB0aGUgc2VydmVyIGFuZCB0aGUgY2xpZW50IGhh cyB0byBlY2hvIHRoZW0sIHNvIHRoYXQgdGhlIChzdGF0ZWxlc3MpIHNlcnZlciBjYW4gZG8gdGhl IHJpZ2h0IHRoaW5nLiBTbyB0aGUgZW5jb2Rpbmcgb2YgVVJJcyBpbiBDb1JBTCBpcyBjbG9zZSB0 byBpdHMgcmVwcmVzZW50YXRpb24gaW4gQ29BUCBvcHRpb25zLiBZZXQgdGhlIGNsaWVudCBzdGls bCBoYXMgdG8gc29tZWhvdyBwdXQgaXQgaW50byB0aGUgcmVxdWVzdC4gVXN1YWxseSB0aGF0IHBh cnQgb2YgdGhlIGNsaWVudCBsb2dpYyBpcyBmb3JjZWQgdG8gdXNlIHRoZSBBUEkgb2YgdGhlIENv QVAgbGlicmFyeSB1c2VkLiBJbiBteSBpbXBsZW1lbnRhdGlvbnMsIEkgdGhvdWdodCBpdCB3b3Vs ZCBiZSBnb29kIGZvciB0aGUgZGV2ZWxvcGVyIHRvIG1ha2UgaXQgYXMgY2xvc2UgdG8gSFRUUCBs aWJyYXJpZXMgYXMgcG9zc2libGUsIHdoaWNoIG1lYW5zIHRoYXQgdGhleSBiYXNpY2FsbHkgaGFu ZGxlIHN0cmluZ3Mgd2l0aCBhbGwgdGhlIHdlaXJkIFVSSSBtYWdpYywgZGlzYWxsb3dpbmcgYSBj bGVhbiBjb3B5IGZyb20gaHlwZXJtZWRpYSBjb250cm9sIHRvIHJlcXVlc3QuDQoNCktsYXVzLCBw bGVhc2UgZnJlZSB0byBhZGQgcG9pbnRzIHRoYXQgSSBtaWdodCBoYXZlIGZvcmdvdHRlbiBpbiBt eSBzdW1tYXJ5IQ0KDQpLaW5kIHJlZ2FyZHMsDQpNYXR0aGlhcw0KDQo= From nobody Tue Mar 5 04:48:21 2019 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 A36A513106C for ; Tue, 5 Mar 2019 04:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEZmEZ0hq8mj for ; Tue, 5 Mar 2019 04:48:16 -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 406511310BE for ; Tue, 5 Mar 2019 04:48:16 -0800 (PST) Received: from mail-qk1-f179.google.com ([209.85.222.179]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1h19UT-00046d-7d; Tue, 05 Mar 2019 13:48:13 +0100 Received: by mail-qk1-f179.google.com with SMTP id i5so4664393qkd.13 for ; Tue, 05 Mar 2019 04:48:13 -0800 (PST) X-Gm-Message-State: APjAAAV+2Ofap7zZpy+vezgZ4P7aLLgRDiml8cY7SFUMmshBeCGdpCOS bbsoUM7WOdHWZTfCxaB5U8Y12Q//C7c7AI/O5eA= X-Google-Smtp-Source: APXvYqwyYmmnmEa2cXhBOCcPLyPQf7lNGH7LdlLjJBFzcHSp41Ca1Yta6bYa+9VAHG+1QdhtB3QA2NGYbXqMc3qraIE= X-Received: by 2002:a05:620a:12a5:: with SMTP id x5mr1535133qki.291.1551790092200; Tue, 05 Mar 2019 04:48:12 -0800 (PST) MIME-Version: 1.0 From: Klaus Hartke Date: Tue, 5 Mar 2019 13:47:36 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1551790096; 3de70091; X-HE-SMSGID: 1h19UT-00046d-7d Archived-At: Subject: [core] Trusting links in .well-known/core 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, 05 Mar 2019 12:48:20 -0000 RFC 6690 defines "CoRE Resource Discovery" as "discovery of resources hosted by a constrained web server" [1]. The RFC then proceeds to specify that "resource discovery in CoRE is accomplished through the use of a well-known resource URI that returns a list of links about resources hosted by that server" [2]. Let's say a client requests a representation of .well-known/core from server 'kadse.example' and gets a link to a resource on 'kefer.example': => GET coap://kadse.example/.well-known/core <= 2.05 Content Content-Format: application/link-format Because of Section 2.1 of RFC 6690 [3], the context of this link is . So it's a link from to with link relation type "hosts". In other words, the client says it wants to discover the resources hosted by (coap, kadse.example, 5683) and (coap, kadse.example, 5683) says that there is a resource hosted by (coap, kefer.example, 5683) named . That doesn't seen to make a lot of sense. Are such links currently allowed? If yes, should they be forbidden? Furthermore: RFC 8288, on which RFC 6690 is based, notes that there are "attack vectors opened by automatically following, trusting, or otherwise using links" [4] that need to be mitigated. In particular, links that "associate a link's context with another resource cannot be trusted since they are effectively assertions by a third party that could be incorrect or malicious." Because of Section 2.1 of RFC 6690 [3], essentially *every* link in a Link Format representation associates the link's context with another resource. What's the security model of Link Format? That is, what are the rules that client should follow for trusting links in .well-known/core representations in Link Format? Klaus [1] https://tools.ietf.org/html/rfc6690#section-1 [2] https://tools.ietf.org/html/rfc6690#section-4 [3] https://tools.ietf.org/html/rfc6690#section-2.1 [4] https://tools.ietf.org/html/rfc8288#section-5 From nobody Tue Mar 5 07:09:40 2019 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 C83621311B9 for ; Tue, 5 Mar 2019 07:09: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, 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 kkjjPU2Shv8Q for ; Tue, 5 Mar 2019 07:09:24 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353751295D8 for ; Tue, 5 Mar 2019 07:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x25F9EVA008818; Tue, 5 Mar 2019 16:09:19 +0100 (CET) Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44DKzt3Bspz1Bp8; Tue, 5 Mar 2019 16:09:14 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 5 Mar 2019 16:09:13 +0100 Cc: "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 573491352.048673-3d2a9ad7c6ad00fbf3e8b3a0321f8bf6 Content-Transfer-Encoding: quoted-printable Message-Id: <76EA5546-A02C-41B6-81D9-A31B4EE1F630@tzi.org> References: To: Klaus Hartke X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Trusting links in .well-known/core 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, 05 Mar 2019 15:09:33 -0000 On Mar 5, 2019, at 13:47, Klaus Hartke wrote: >=20 > RFC 6690 defines "CoRE Resource Discovery" as "discovery of resources > hosted by a constrained web server" [1]. The RFC then proceeds to > specify that "resource discovery in CoRE is accomplished through the > use of a well-known resource URI that returns a list of links about > resources hosted by that server" [2]. >=20 > Let's say a client requests a representation of .well-known/core from > server 'kadse.example' and gets a link to a resource on > 'kefer.example': >=20 > =3D> > GET coap://kadse.example/.well-known/core >=20 > <=3D > 2.05 Content > Content-Format: application/link-format >=20 > >=20 > Because of Section 2.1 of RFC 6690 [3], the context of this link is > . So it's a link from > to with link relation type =E2=80=9Chosts". Right. > In other words, the client says it wants to discover the resources > hosted by (coap, kadse.example, 5683) and (coap, kadse.example, 5683) > says that there is a resource hosted by (coap, kefer.example, 5683) > named . That doesn't seen to make a lot of > sense. Sense-making is a complex function. In most environment, we can=E2=80=99t forbid everything that doesn=E2=80=99= t make sense. > Are such links currently allowed? If yes, should they be forbidden? Well, there is a statement in there: =E2=80=9CIf you want to discover = information about kadse, it may be of interest that kefer hosts that = resource over there.=E2=80=9D Without additional context, that may be = nonsensical, but with an RT, it might point to any kind of resource that = is of interest in conjunction with knowing about the current server. E.g., a CoAP server could point to a data backup server (and, probably, = hope that that one over there indeed backs up this server, but it = doesn=E2=80=99t know!). > Furthermore: RFC 8288, on which RFC 6690 is based, notes that there > are "attack vectors opened by automatically following, trusting, or > otherwise using links=E2=80=9D [4] Then don=E2=80=99t do that. > that need to be mitigated. In particular, > links that =E2=80=9Cassociate a link=E2=80=99s context with another = resource cannot be > trusted This is a nice example of a misuse of the word =E2=80=9Ctrust=E2=80=9D. = How do you =E2=80=9Ctrust a link=E2=80=9D? It is obvious that the device exhibiting this link wants you to know it, = and (assuming some form of integrity, which is missing in the example), = you can =E2=80=9Ctrust that=E2=80=9D, but that=E2=80=99s all you can = trust. Whether that has influence on what you do next depends on your = authorization policies. > since they are effectively assertions by a third party that > could be incorrect or malicious.=E2=80=9D Right. In CoAP we have much less of =E2=80=9Cautomatically following=E2=80= =9D (we don=E2=80=99t even have redirects!). > Because of Section 2.1 of RFC 6690 [3], essentially *every* link in a > Link Format representation associates the link's context with another > resource. I can=E2=80=99t parse this sentence. Links associate =E2=80=9Ccontexts=E2= =80=9D (bad name for the source of a link) to target resources. Section = 2.1 only helps you find out what the =E2=80=9Ccontext=E2=80=9D is (and I = agree, it exhibits some weirdness). > What=E2=80=99s the security model of Link Format? 6690 pretty much punts to 5988 here. And that already has above=E2=80=99s =E2=80=9Cthen don=E2=80=99t do = it=E2=80=9D. (And reminds people that you need integrity protection/authentication if = you want to do something grave based on the information.) > That is, what are the rules > that client should follow for trusting links Don=E2=80=99t =E2=80=9Ctrust=E2=80=9D, except in the sense of =E2=80=9Cthi= s device wanted to give you that information=E2=80=9D. We don=E2=80=99t treat discovery information as signed claims, right? But claims they are. > in .well-known/core > representations in Link Format? >=20 > Klaus >=20 > [1] https://tools.ietf.org/html/rfc6690#section-1 > [2] https://tools.ietf.org/html/rfc6690#section-4 > [3] https://tools.ietf.org/html/rfc6690#section-2.1 > [4] https://tools.ietf.org/html/rfc8288#section-5 I think an even more interesting problem is that a link-format can = contain coaps:// links without any indication on the kind of security = that goes with that. That is a discovery problem we haven=E2=80=99t = solved very well yet. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 5 08:58:28 2019 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 3362D13111D for ; Tue, 5 Mar 2019 08:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 L-YKCeOQnl58 for ; Tue, 5 Mar 2019 08:58:24 -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 B81C412D4F0 for ; Tue, 5 Mar 2019 08:58:13 -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 1h1DON-00046D-UO; Tue, 05 Mar 2019 17:58:12 +0100 Received: by mail-qk1-f180.google.com with SMTP id i5so5128324qkd.13 for ; Tue, 05 Mar 2019 08:58:11 -0800 (PST) X-Gm-Message-State: APjAAAXkzYEJWmiH9WTFJVsEylM1T9SsZtqgF6rSIhuoRW4uy+dxZQ3Y xK/UTdEDdWXX/RmOOdLmIpmW+DO7uSY9T2A7pUg= X-Google-Smtp-Source: APXvYqzYvBbhE1K9F2wcAMrNVFSYfweF/StBV+2mdXIOxuy66zN5himDAib4pRXgvj0Ew3ApE3bqQekde1FWsIEKmos= X-Received: by 2002:a37:628a:: with SMTP id w132mr2447189qkb.60.1551805090831; Tue, 05 Mar 2019 08:58:10 -0800 (PST) MIME-Version: 1.0 References: <76EA5546-A02C-41B6-81D9-A31B4EE1F630@tzi.org> In-Reply-To: <76EA5546-A02C-41B6-81D9-A31B4EE1F630@tzi.org> From: Klaus Hartke Date: Tue, 5 Mar 2019 17:57:35 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1551805094; 2b16c3e8; X-HE-SMSGID: 1h1DON-00046D-UO Archived-At: Subject: Re: [core] Trusting links in .well-known/core 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, 05 Mar 2019 16:58:27 -0000 Carsten Bormann wrote: > Well, there is a statement in there: =E2=80=9CIf you want to discover inf= ormation about kadse, it may be of interest that kefer hosts that resource = over there.=E2=80=9D Without additional context, that may be nonsensical, = but with an RT, it might point to any kind of resource that is of interest = in conjunction with knowing about the current server. There is a difference between kadse.example saying e.g. "my billing server is located at " and "kefer.example hosts a billing server at ". > This is a nice example of a misuse of the word =E2=80=9Ctrust=E2=80=9D. = How do you =E2=80=9Ctrust a link=E2=80=9D? [...] > Whether that has influence on what you do next depends on your authorizat= ion policies. That sounds like a very good definition for "trust". You trust a link if your authorization policies allow you to do something next. > I can=E2=80=99t parse this sentence. Links associate =E2=80=9Ccontexts= =E2=80=9D (bad name for the source of a link) to target resources. Section= 2.1 only helps you find out what the =E2=80=9Ccontext=E2=80=9D is (and I a= gree, it exhibits some weirdness). RFC 8288 suggests that a client discards any link where the actual link context is overridden. This is the case for every link in Link Format. (Because if there is no anchor attribute that overrides it, Section 2.1 overrides it with the "origin" of the link target.) Klaus From nobody Tue Mar 5 15:40:58 2019 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 6ED6512F1A5 for ; Tue, 5 Mar 2019 15:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.322 X-Spam-Level: X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.com header.b=KMg2pM3k; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Cgj4qyzi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQF9fMUwK5PP for ; Tue, 5 Mar 2019 15:40:54 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C053F1200D8 for ; Tue, 5 Mar 2019 15:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551829251; x=1554421251; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=isCi5/n50rSf2f64igsrkvgGDNBvZWeW2B2pNMxVz4Q=; b=KMg2pM3kt0S/pIYIPn6MC+XBrKdvrQAsV5pEzJ0owAWNZwvydiHOH0OT2PgXDIBT oZ6bMx5TH7Szjew8l0Dcna7wkaXy6xwLv9FRMh4DcERgs8cIoGfFkcH5t24r89SG UsXKUQk3Tjf1z2LA4BvEvwwYo+MQqPVvZMfrwM0S0JM=; X-AuditID: c1b4fb25-209009e000005ff7-20-5c7f09035e04 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 65.FF.24567.3090F7C5; Wed, 6 Mar 2019 00:40:51 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 00:40:42 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 6 Mar 2019 00:40:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=isCi5/n50rSf2f64igsrkvgGDNBvZWeW2B2pNMxVz4Q=; b=Cgj4qyzirooYOYl1TezHJ0Q9qnuJAbeQlW7y9EeYbGB9Mdc8fy1lTCqOTyKdd8uFJ9+eZ5pAS7EOhAPNF8tCMxZ19L9TCeSHnwHM4OlvWY8uMfUBXL8dIMX2QMwCZIX7k9JOq9PYltJUrrgQNt1CsSigI8jFYXCGOd/qeQNny84= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB4188.eurprd07.prod.outlook.com (20.176.166.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.15; Tue, 5 Mar 2019 23:40:41 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::d9da:b6e5:313:a24a]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::d9da:b6e5:313:a24a%6]) with mapi id 15.20.1686.016; Tue, 5 Mar 2019 23:40:41 +0000 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Carsten Bormann CC: core Thread-Topic: [core] Chair's review of draft-ietf-core-senml-etch-02.txt Thread-Index: AQHUySz80ljO8HDITE2Guzp0VgDmEKX9x1CA Date: Tue, 5 Mar 2019 23:40:40 +0000 Message-ID: References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> In-Reply-To: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 x-originating-ip: [89.166.49.243] x-clientproxiedby: HE1PR05CA0137.eurprd05.prod.outlook.com (2603:10a6:7:28::24) To HE1PR07MB4236.eurprd07.prod.outlook.com (2603:10a6:7:9f::17) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6238d3bc-9b24-457e-23a2-08d6a1c3fa27 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4188; x-ms-traffictypediagnostic: HE1PR07MB4188: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUI0MTg4OzIzOlI5SHlObUpld1g4Z2EwdDRMRm1pYVZSSE90?= =?utf-8?B?SUd4d20weFpucXQ0Znd1dVBOQjZtVjdOczBrOFZJV3FTQ2dKL1lGaElVSmR4?= =?utf-8?B?aGVRV2Q3cFF1cm1iRzF5TWdzOCt3TWF1aUdkeFpCN2xkcTUxUVRMZjY4YmRm?= =?utf-8?B?aEtPeGprSlN5VlRHOEVZL2xhRVh1MHIweGUvbXR3WDY2YVZOYktHOHVDd0VU?= =?utf-8?B?WHgwMHgvTlBIR0xyZHloNllLNVdOL1RQdk1SVnhlMVZIb1Q4L3N1M3JUdlVG?= =?utf-8?B?RzJZclI1bDVJejBkM1lCWFZuNVduVXpBRUp2cHVqZlIxTlVidE4yRDVzRXZt?= =?utf-8?B?Z0hjeUVOVXFGczNiUmhoK1pwMm9NSE9uTnpia25OQUVsRURWa1JGb2p5Q1R0?= =?utf-8?B?eHU5K1lxRlNxWjBXM0xuUm8wcC9WbTNLdytWdG52c20wSGJWaGFHVlhQRi9r?= =?utf-8?B?SFNKdUNmVU01THFIVk9TK0IxRkhOMjNFcVd5elZLME5uM1NUVFZIT0xrcjZs?= =?utf-8?B?YURFOXRIbHo2NXAvYUN5N2tKeXZyVEEvNnlndVhMckowZGc2bWNrWklBOEJn?= =?utf-8?B?Uk9veU9rVGgrK3U0VHFDVWVzVjhINmE5d2REYmx4VGlFcXE0NWVuOGQ1VXd2?= =?utf-8?B?eWJPVUZ6MGp1TlJCOTJ1S2lzeC9qTkgrbWxCMXBHaS9ZM0RjTERsM3Ztblpv?= =?utf-8?B?cDhYQVBrMHhvTTMrL1NXUGtFTXJOZlJ4RGlOalpqUDM5SWFsZVo3Z0F2cmF4?= =?utf-8?B?UXYyRVBSOHdJVUtYVmNxZnF5RjM0MnVvMUlOaHNJRjZvbXFwNXBOcmxwV0FI?= =?utf-8?B?UVdXTFVVM3V5NW5SeEIwVG9HQ2FiNnVBWjBuRHV0eE9ZcWZDN2wvRjBoWFJp?= =?utf-8?B?SlZXR0EyMkpVM0pMTmJGb3VrNXkwOXBmN3IzdVRLTHFVYUM0NXBsWjErbGZU?= =?utf-8?B?eURnV1JZSkpCM2lhSVo2V2JRN2lWc3VrK0lKbHBSRWtLRHYwL3FZRXZTRHFR?= =?utf-8?B?RTUzRGVqNHRBVmJ1T1A1bytjSFZNVDFNQVFzS3BHM1lXcGZzb3dmZm5TL0p1?= =?utf-8?B?SmlHR2F1RGc1L1U1ZWFmZWJ4enhYbG9iZmI2L3dyWGNxUDBkNmZlYkUrTzc0?= =?utf-8?B?T2VjQWxpQThaYVQySktpdGJpTTNoRXVESmpjdWdBdlhNdGtXbHp1Nnh6MTZK?= =?utf-8?B?L2RxdzkwamJzNTVhTXRKS2VVVk9VRTVxUmU4OUtRTHdWRlJ5clJXV2o3amsy?= =?utf-8?B?cVY4MEJmRU5HOFIwZlZIaG1ZYjd1TzJlaDJmS2JRTGZWMURxNTQ5elJFQzFz?= =?utf-8?B?WU9vYTJHbFNsQTJiWkVYcytvYkhRRlVsSG1MZmgwNmFYUkgxVVNLZ1ZocnNv?= =?utf-8?B?VFJlWGxSTmVXdFJnWXBFT3lkWGFlaU1rSFJON3VEYTRFayszcHg3ejZsM2JC?= =?utf-8?B?TW5ZQWlSSWNoU3JHbnpaZEordkhBK0JFTlBuWUpOUTE3L0IwL0UrOWRhZkZJ?= =?utf-8?B?TTFoM2ZKcmQ0dDd2YS80VHBtMXg3L3J3RE9CMnFPTUZPTThSY2duU1d0Wll2?= =?utf-8?B?d2RqVXNKeHhKN1dmSWlnWXFvMFNPMkVsU1llLzBuRkpLK1RDbk9pVnhvUjh4?= =?utf-8?B?cDNEN1FaVVBObDFFR1NSWDRFTzgwSjkxeGF5T0xXRlNKcGIrTDBXMDcrYnlL?= =?utf-8?B?RzBtUXFJazgwVGxCWnhYSUVkdzFWOFNwWlZRQ3prZEY2NUpFd1p2RmMvbXM2?= =?utf-8?B?NnRMUHB0eDVYTHVDN1laN3dLYXZoQ0FhaVRtY3ZSTDNpT25MaW5wOGt4WUwx?= =?utf-8?B?RmgzSysyNE8wSk1KaE9HZFNnNVAvOWQyQTYwYUpTZmF3ZExZWFRhSEQzUEx4?= =?utf-8?B?L2FlU2pTQ29ldTNBR0plRlRGbHlrM2wwVThTTWRZOHFoUWxJQjFBeEN0TDAx?= =?utf-8?B?d3gyNVh5OExRPT0=?= x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(396003)(136003)(39860400002)(189003)(199004)(65956001)(66066001)(65806001)(446003)(8676002)(486006)(476003)(7736002)(25786009)(305945005)(2616005)(966005)(11346002)(8936002)(58126008)(3846002)(85182001)(6246003)(14454004)(68736007)(256004)(64126003)(81156014)(31686004)(316002)(81166006)(106356001)(85202003)(6116002)(105586002)(186003)(31696002)(65826007)(86362001)(76176011)(71200400001)(6506007)(2906002)(71190400001)(52116002)(386003)(6916009)(99286004)(478600001)(97736004)(5660300002)(6436002)(26005)(6512007)(6306002)(36756003)(6486002)(53936002)(4326008)(102836004)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4188; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rHIbAq2sRXEhz1/q6k39ic0rjDQ7UipEmzISgX0Bz4G1JqdQu+NTBW5KhQIG+S1PVhUgNaDNLpticg4n5tQYZZVp6563fF0b29/H4lDTEMmXw3tPwlzkiwkcdWT+A1YhnzwRPO6LxMSZYpR9ubc3f9Gc+ldKwrw+9f1UfIXXlC7jXI4SM7hJcrl2gXFLRxXTmjmye/c34Rn6oFLPCiTfWH2ve6oxOX8f3dIYA/3hGieJ7I9HntqOnlze7uEcaMXHUvhyATmbTuHzEMCILtcanx4hGFhWz6WyvNfS/6Ai9Pi5lAmjWgz1TgSADdPsXgFF87fWzkIu2O7YsaZTwP8D3x7ao1pLHJDkAtTgEBbFQfB5ASfu2Ii0lfOE3+XzW6fKUhEoyWKg8F1HvpdbHjM1DzYoKfhr2Ov7Zl0oD9Exqvw= Content-Type: text/plain; charset="utf-8" Content-ID: <1F4C5B93BC1A664AAEED71B6DECA61FE@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6238d3bc-9b24-457e-23a2-08d6a1c3fa27 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 23:40:41.0319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4188 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHed53l3fL0eN0ejDSHF1MauYlkMpK+tD6YNqXTJvkylcd6ZS9 Zl4ozZK8FBgTcyrOW6GiKGYYJlZmyCTJphQqmbJFmM7Lh9LKNLdnQd9+///5n3OeAw9DS8v4 XoxGm8HqtOoUuUDMM1zo4Q7SojzVIfPtw6GD5Z/4of22DvokpWxq+kkpKxo0UVSs+FgCm6LJ ZHUBx+PFyV97PNIfu2RZxlb5+Wh9WwkSMYBDYNzaxCtBYkaKBxHMb7Y7xXcEFXXLiIhGCu70 3xLaBQ+X0VBcu0iTip6CkukPAiI+IygwNfDtkwU4DKyF/Q52x3IYfd8msDONAUZaXjt8N3wa DG/yEcko4eVUtZBwEKxN9NF25uHdMLXZ6MhL8AlY2mjb8pmtZUeg68FZuy3CR2Gy/K0jjrAH rA63UWSVJ0xajRQ5FENT3zuasAzmLBuOkTKcCG33Z5wZXxhZnKXstwDWI2j+8RyRoRfh27BJ SEIHYOSjFRHeCWZjqZMjQF9TKCDNEwg663sFpOAPv8Y7nc1esGpZEZJQrRsYjMWoDAVV/ffa qq3jaLwfOnoDiK2ExYW7QsK+UF4662AJdgWTwcqrQ/xWJONY7nJqUlCwgtVprnBcmlahZTO6 0NY/edX9e88zNLYQPoAwg+Qukua1myopX53JZacOIGBoubvETOWppJIEdXYOq0u7pLuWwnID aAfDk3tK1qWuKilOUmewV1k2ndX9q1KMyCsfBf6xmEtccurpoT72fPNTHxnTGOme1Z2rjws+ NxcZFe3zSD/1ZEi41FLUN+odIwnLfHgv2ndv7PVlQSpXrWhVjvsZ6HAPfqItvbDStKsnNyyt Jq8iNqJ7RlJg3ld55pTfvNH0ZSVEPt36wttQFL/d2mBrj1uKsZVn3FCklo42ynlcsjrQn9Zx 6r9Y7CL2IwMAAA== Archived-At: Subject: Re: [core] Chair's review of draft-ietf-core-senml-etch-02.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: Tue, 05 Mar 2019 23:40:57 -0000 VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IENhcnN0ZW4hIEkgcHJldHR5IG11Y2ggYWdyZWVkIHdp dGggYWxsIHRoZSANCmNvbW1lbnRzIGFuZCBtYWRlIGEgUFIgdG8gYWRkcmVzcyB0aGVtOg0KaHR0 cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvc2VubWwtZXRjaC9wdWxsLzINCg0KSWYgdGhlcmUgYXJl IG5vIGZ1cnRoZXIgY29tbWVudHMgb24gdGhlc2UsIEkgY291bGQgbWVyZ2UgdGhlIFBSIGFuZCAN CnN1Ym1pdCBhIG5ldyB2ZXJzaW9uLg0KDQoNCkNoZWVycywNCkFyaQ0KDQpPbiAyMC8wMi8yMDE5 IDE3LjAwLCBDYXJzdGVuIEJvcm1hbm4gd3JvdGU6DQo+IEluIHByZXBhcmF0aW9uIGZvciB0aGUg aW1wZW5kaW5nIHdvcmtpbmctZ3JvdXAgbGFzdCBjYWxsLCBJIGhhdmUNCj4gcmV2aWV3ZWQgZHJh ZnQtaWV0Zi1jb3JlLXNlbm1sLWV0Y2gtMDIudHh0LiAgU3Vic3RhbnRpdmUgY29tbWVudHMgYXJl DQo+IGJlbG93OyBhIHNldCBvZiBzbWFsbCBlZGl0b3JpYWwgY29tbWVudHMgaXMgZ29pbmcgdG8g dGhlIGF1dGhvcnMgaW4NCj4gcGFyYWxsZWwuDQo+IA0KPiAjIE1pbm9yDQo+IA0KPiAxLiBUaGUg dGV4dCBvZiB0aGUgZHJhZnQgZG9lcyBub3QgY29udGFpbiBhbiBhcmd1bWVudCB0aGF0IHRoZQ0K PiAgICAgYXBwbGljYXRpb24gb2YgUGF0Y2ggUGFja3MgaXMgaWRlbXBvdGVudC4gIEl0IHByb2Jh Ymx5IHNob3VsZC4NCj4gDQo+IDIuIFRoZSB0ZXh0IHNvbWV0aW1lcyBzYXlzICJpUEFUQ0giIHdo ZXJlIGl0IHByb2JhYmx5IHNob3VsZCBiZSBzYXlpbmcNCj4gICAgICJQQVRDSCBhbmQgaVBBVENI Ii4gIFRoaXMgc2hvdWxkIGJlIGNoZWNrZWQgdGhyb3VnaG91dC4NCj4gDQo+IDMuIFRoZSB0ZXJt ICJyZXNvdXJjZSIgaXMgc29tZXRpbWVzIHVzZWQgaW4gbGlldSBvZiAic3Vic2V0IG9mIFNlbk1M DQo+ICAgICByZWNvcmRzIHRoYXQsIHdoZW4gcmVzb2x2ZWQsIG1hdGNoIGEgZ2l2ZW4gbmFtZSIu DQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNv cmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl DQo+IA0KDQo= From nobody Tue Mar 5 15:52:12 2019 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 D391E13105F; Tue, 5 Mar 2019 15:51:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: core@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155182989485.27720.1339030368731985224.idtracker@ietfa.amsl.com> Date: Tue, 05 Mar 2019 15:51:34 -0800 Archived-At: Subject: [core] core - Requested sessions have been scheduled for IETF 104 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 23:51:36 -0000 Dear Carsten Bormann, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. core Session 1 (1:30 requested) Tuesday, 26 March 2019, Afternoon Session I 1350-1550 Room Name: Berlin/Brussels size: 100 --------------------------------------------- core Session 2 (1:30 requested) Friday, 29 March 2019, Morning Session I 0900-1030 Room Name: Grand Ballroom size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/core.ics Request Information: --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: cose cbor ace suit httpbis artarea t2trg lpwan rats Second Priority: saag secdispatch sacm teep irtfopen 6tisch 6lo roll Third Priority: lwig detnet quic v6ops opsarea cfrg icnrg dnssd netconf netmod emu People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Special Requests: Plse lso avd any potntlly IoT reltd BOFs&PRGs (e.g., coin) tht mght cme up. Prefer some time between the two meetings (48 h or more). Responsible AD *might* change to Barry Leiba before the meeting. --------------------------------------------------------- From nobody Wed Mar 6 05:20:27 2019 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 EBF38124184; Wed, 6 Mar 2019 05:20:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155187842590.24578.9474115578546563587@ietfa.amsl.com> Date: Wed, 06 Mar 2019 05:20:25 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-object-security-16.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, 06 Mar 2019 13:20:26 -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 : Object Security for Constrained RESTful Environments (OSCORE) Authors : Göran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-16.txt Pages : 90 Date : 2019-03-06 Abstract: This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although being an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates [RFC7252]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-object-security-16 https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-16 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 Mar 6 07:00:10 2019 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 619C4124BA8 for ; Wed, 6 Mar 2019 07:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 evQ6qFiohP8l for ; Wed, 6 Mar 2019 07:00:06 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA92127287 for ; Wed, 6 Mar 2019 07:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x26ExvCc027091 for ; Wed, 6 Mar 2019 16:00:02 +0100 (CET) Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44Dxkj3BqGz1Bp8; Wed, 6 Mar 2019 15:59:57 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_FFEF2F62-8DCA-4AA9-86F0-959AFD99AA26" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann X-Priority: 3 X-Mail-Calendar-Part: Yes Date: Wed, 6 Mar 2019 15:59:56 +0100 X-Mao-Original-Outgoing-Id: 573577194.692144-d0f1d98418edb819e8865bbba68145a1 Message-Id: <74895874-55F8-4246-8A96-DBF22200EB3B@tzi.org> References: <83E7C5E4-CA4B-477E-96ED-0EB840F589AE@tzi.org> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] Fwd: Webex meeting details: CoRE Interim Meeting today 2019-03-06 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, 06 Mar 2019 15:00:08 -0000 --Apple-Mail=_FFEF2F62-8DCA-4AA9-86F0-959AFD99AA26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 60 minutes till today=E2=80=99s meeting. Webex details for this full interim are the same as usual; copied below. Proposed agenda: * Document status * OSCORE, RD, dynlink * hop-limit, stateless, ERT, multipart-core * what else? * SenML: units, data-ct, fetch/patch * Pubsub empty Bash now or at the start of the meeting. Gr=C3=BC=C3=9Fe, Carsten >> Begin forwarded message: >>=20 >> From: Carsten Bormann > >> Subject: [core] Webex meeting details: CoRE Hallway and Interim = Meetings before IETF104 >> Date: January 9, 2019 at 16:01:15 GMT+1 >> To: "core@ietf.org WG" > >> Archived-At: = > >>=20 >>> CORE Working Group invites you to join this Webex meeting. >>> =20 >>> CoRE Hallway and Interim Meetings >>> Every 2 weeks on Wednesday, from Wednesday, January 9, 2019, to = Wednesday, March 20, 2019 >>> 4:00 pm | Greenwich Time (Reykjavik, GMT) | 1 hr >>> Meeting number (access code): 649 598 697 >>> Meeting password: constrained >>>=20 >>>=20 >>> =20 >>> Add to Calendar = =09 >>> When it's time, join the meeting = . >>> =20 >>> Join by phone >>> 1-650-479-3208 = Call-in toll number (US/Canada) >>> =20 >>> Can't join the meeting? = >>> =20 >>> IMPORTANT NOTICE: Please note that this Webex service allows audio = and other information sent during the session to be recorded, which may = be discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. >=20 > _______________________________________________ > 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 = --Apple-Mail=_FFEF2F62-8DCA-4AA9-86F0-959AFD99AA26 Content-Type: multipart/mixed; boundary="Apple-Mail=_9B2660FC-C970-4FAF-9D90-BD7127823431" --Apple-Mail=_9B2660FC-C970-4FAF-9D90-BD7127823431 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
60 minutes till today=E2=80=99s = meeting.
Webex details for this full interim are = the same as usual; copied below.

Proposed agenda:
* Document = status
  * OSCORE, RD, dynlink
  * hop-limit, stateless, ERT, multipart-core
  * what else?
* SenML: units, = data-ct, fetch/patch
* Pubsub empty

Bash now or at the = start of the meeting.

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

Begin forwarded message:

From: Carsten Bormann <cabo@tzi.org>
Subject: = [core] Webex = meeting details: CoRE Hallway and Interim Meetings before IETF104
Date: January 9, 2019 at 16:01:15 GMT+1
To: "core@ietf.org WG" <core@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/rjM1BQj5T-LWzH-y5Y2V= oW-7obE>

CORE Working Group invites you to join this = Webex meeting.
 
CoRE Hallway and = Interim Meetings
Every 2 weeks on Wednesday, from Wednesday, January 9, = 2019, to Wednesday, March 20, 2019
4:00 = pm  |  Greenwich Time (Reykjavik, = GMT)  |  1 hr
Meeting number (access code): 649 598 = 697
Meeting = password: constrained


 
Add to = Calendar
When it's time, join the = meeting.
 
Join by phone
1-650-479-3208 Call-in toll number = (US/Canada)
 
Can't join the = meeting?
 
IMPORTANT NOTICE: Please note that this Webex service = allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the = session.
=
= --Apple-Mail=_9B2660FC-C970-4FAF-9D90-BD7127823431 Content-Disposition: attachment; filename=Webex_Meeting.ics Content-Type: text/calendar; x-unix-mode=0666; name="Webex_Meeting.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2010.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0ABEGIN:VTIMEZONE=0A= TZID:Greenwich=20Time=0ABEGIN:STANDARD=0ADTSTART:20170101T000000=0A= TZOFFSETFROM:+0000=0ATZOFFSETTO:+0000=0ATZNAME:Standard=20Time=0A= END:STANDARD=0AEND:VTIMEZONE=0ABEGIN:VEVENT=0ACLASS:PUBLIC=0A= DESCRIPTION:\n\n\n\nJOIN=20WEBEX=20= MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm01e0c6fecb1b951b749450d= ee33a432c\nMeeting=20number=20(access=20code):=20649=20598=20= 697\nMeeting=20password:=20constrained\n\n\n\nJOIN=20BY=20= PHONE\n1-650-479-3208=20Call-in=20toll=20number=20(US/Canada)=20\nTap=20= here=20to=20call=20(mobile=20phones=20only,=20hosts=20not=20supported):=20= tel:%2B1-650-479-3208,,*01*649598697%23%23*01*\n\n\n\nCan't=20join=20the=20= meeting?\nhttps://collaborationhelp.cisco.com/article/WBX000029055\n\n\nIM= PORTANT=20NOTICE:=20Please=20note=20that=20this=20Webex=20service=20= allows=20audio=20and=20other=20information=20sent=20during=20the=20= session=20to=20be=20recorded,=20which=20may=20be=20discoverable=20in=20a=20= legal=20matter.=20By=20joining=20this=20session,=20you=20automatically=20= consent=20to=20such=20recordings.=20If=20you=20do=20not=20consent=20to=20= being=20recorded,=20discuss=20your=20concerns=20with=20the=20host=20or=20= do=20not=20join=20the=20session.\n=0AX-ALT-DESC;FMTTYPE=3Dtext/html:=09=  
 
 
=09=09Join=20= Webex=20meeting=09=09=09=09=09=09=09=09=09=09=09=09= =09=09=09=09=09=09=09
=09=09=09=09=09=09Meeting=20number=20(access=20code):=20649=20598=20= 697=09=09=09=09=09
=09=09=09= =09=09=09
Meeting=20password:constrained
=09= =09

 
 
Join=20by=20phone =20
1-650-479-3208 Call-in=20toll=20= number=20(US/Canada) =20


=09 
=09= =09= Can't=20join=20= the=20meeting?=09 
 
IMPORTANT=20NOTICE:=20Please=20note=20that=20= this=20Webex=20service=20allows=20audio=20and=20other=20information=20= sent=20during=20the=20session=20to=20be=20recorded,=20which=20may=20be=20= discoverable=20in=20a=20legal=20matter.=20By=20joining=20this=20session,=20= you=20automatically=20consent=20to=20such=20recordings.=20If=20you=20do=20= not=20consent=20to=20being=20recorded,=20discuss=20your=20concerns=20= with=20the=20host=20or=20do=20not=20join=20the=20session.=0A= ATTENDEE;CN=3D"CORE=20Working=20= Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:core-chairs@ietf.org=0A= DTSTAMP:20190109T160000Z=0AUID:87eada8c-d7f0-4692-98c1-7d481cc9637e=0A= PRIORITY:5=0ADTSTART;TZID=3D"Greenwich=20Time":20190109T160000=0A= DTEND;TZID=3D"Greenwich=20Time":20190109T170000=0A= RRULE:FREQ=3DWEEKLY;INTERVAL=3D2;BYDAY=3DWE;UNTIL=3D20190320T170000Z=0A= SEQUENCE:1547045524=0ASUMMARY:CoRE=20Hallway=20and=20Interim=20Meetings=0A= TRANSP:OPAQUE=0AORGANIZER;CN=3D"CORE=20Working=20= Group":MAILTO:core-chairs@ietf.org=0A= LOCATION:https://ietf.webex.com/ietf=0ABEGIN:VALARM=0ATRIGGER:-PT5M=0A= ACTION:DISPLAY=0ADESCRIPTION:Reminder=0AEND:VALARM=0AEND:VEVENT=0A= END:VCALENDAR=0A= --Apple-Mail=_9B2660FC-C970-4FAF-9D90-BD7127823431 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

_______________________________________________
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

= --Apple-Mail=_9B2660FC-C970-4FAF-9D90-BD7127823431-- --Apple-Mail=_FFEF2F62-8DCA-4AA9-86F0-959AFD99AA26-- From nobody Wed Mar 6 07:03:19 2019 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 499FC127287 for ; Wed, 6 Mar 2019 07:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.105, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.com header.b=G1lfCDct; dkim=pass (1024-bit key) header.d=ericsson.com header.b=F6czs+Ax Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ5en_XWs9sB for ; Wed, 6 Mar 2019 07:03:15 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0261277E0 for ; Wed, 6 Mar 2019 07:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551884592; x=1554476592; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fM2Ct7stfHAiBXzzS9kn01UcmJmE8JnMNkIEzlA8JDA=; b=G1lfCDct/RJxETbsIb6KUGlr+7D0F+EoOuI7ZdHtnhUTYAuzP3nd9YEbJflQzWD3 XupxIerXPtBRnpFCVB76uvfKDhVb+1QWbZCnVYelcB3U7u56k5MinZ7n9VLbgQ8r nHGvZ6o+bt1ZNxi0/M3oVDGZLSGLqNc1bCT8E6g0gRc=; X-AuditID: c1b4fb3a-167ff7000000672c-33-5c7fe12fdacb Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.B3.26412.F21EF7C5; Wed, 6 Mar 2019 16:03:12 +0100 (CET) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 16:03:11 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 6 Mar 2019 16:03:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fM2Ct7stfHAiBXzzS9kn01UcmJmE8JnMNkIEzlA8JDA=; b=F6czs+AxaZ6dtVqfjj4tGyaLiJY2PFMY7yuyKet+H1V31pkJLoO9bJhiKClYmhX2tf4S/3rU/ium7Fk7P8KS5+XGFGeoCvwMROcAgIjdUtvC9LceMW614VNWP6zlvptmkzasS7uQZNJjUfkuWFJDU7eL7uWicAyp3grLL+XP4x8= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB3307.eurprd07.prod.outlook.com (10.170.246.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.15; Wed, 6 Mar 2019 15:03:06 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::d9da:b6e5:313:a24a]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::d9da:b6e5:313:a24a%6]) with mapi id 15.20.1686.016; Wed, 6 Mar 2019 15:03:06 +0000 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: core WG Thread-Topic: SenML FETCH/PATCH without globally unique names Thread-Index: AQHU1C20LmdMIEtTqU2ewKGY5oAvwQ== Date: Wed, 6 Mar 2019 15:03:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 x-originating-ip: [89.166.49.243] x-clientproxiedby: HE1PR0301CA0015.eurprd03.prod.outlook.com (2603:10a6:3:76::25) To HE1PR07MB4236.eurprd07.prod.outlook.com (2603:10a6:7:9f::17) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0ae9eb7a-f988-40ab-2c82-08d6a244d6aa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3307; x-ms-traffictypediagnostic: HE1PR07MB3307: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzMzA3OzIzOitYOWdTUkRPQlZxdUI3em1vRzI5NGNaT0sz?= =?utf-8?B?K1Bla3VmU3U0UVR3Wjh5aWRubnFtdldOcEpnM2cydUMyU1pFdWJVenEyb2tL?= =?utf-8?B?c25ybjlxVTRQUi9IRGc0ZDRNR3pmemZVTWZlWU45ZWU2RTJQMS9BWTZEV1Ra?= =?utf-8?B?YS9aVk43Mmo0a0U2cWMxUEN5SUJhalVxTSsvRjNrYTk3MldGcm5lN2xyeHRM?= =?utf-8?B?SG5ZVFloUjhDZUdlRSsyUEpLSFI4WHRBWmNPdHVqcms1ZmNESlBSR3ZqbEIv?= =?utf-8?B?UmlDRHVpM3VHNGkwU0hBRlp3dG4wNUtNRXlXZ1JENjBHVXhGQnlqMTl1OElV?= =?utf-8?B?OHhSVXZVRVl3VG9OT3JpVkQrODQyOUhuanVZZ2VnSnI4WTBSNDhNSkFWZWpI?= =?utf-8?B?QjNxY3pGalVoanBDN3RGNGlXUk5jMXZqZ3JUdU1Rbzg4RXNvWUppMFk1RHoz?= =?utf-8?B?aTdwSTVXQkd6MEk0eWp1Wlk2YzF5MTNxUEJZVVpCM042ZEhKY2RJclhGZnhU?= =?utf-8?B?KzRLdkxZVUEvSnV6ZmF6YnBlQmMrbWFmS1BiT1BMRXh1YkRsZXVUcG55SmRM?= =?utf-8?B?c1dSRy9UeGFxamR2WFVJeUp0VEJReHZmdGIxamxSOHFNekdLcmNMenBRSDRN?= =?utf-8?B?SU9Qa1VocXZvalNjK014bVhKT3JITkczVFhVSGt1UEg1T0E4OXpuVndKUlNW?= =?utf-8?B?RC8ycDV5Qk5EQjJtcWRnUlJhUE5mY3Iyb0YyZTE1R3pYR3kzM2lOekg4Yzcy?= =?utf-8?B?QUdmTzNwMEc2YUdBNXY2Q3FIeldxNmdZM051TXNPd0JncGpXR1F2ZjRkMzBQ?= =?utf-8?B?RUtIa3E0MUlqZmo4OFdqTDA3NXozczBVT2M1R1dOL1E5UGVrV0RBSHplMzdK?= =?utf-8?B?ei9iaTA5dkN6bzhIdTJTVk1XWngwZlROQ1JXdU51cDVndk5GbVlJZlN4RHZN?= =?utf-8?B?QmFUUFBRb1V4QjlseEZyUE1wdDh0YTdhSXY5bFlmUmczTW1CTnVrQ0Q4b2NI?= =?utf-8?B?TEpYSW1ZWGdzaS8xc0xURlRYeEUwVkYvOU9jQzJuUDArVFo0OVdyaFMzNmFC?= =?utf-8?B?NVlrWUduS1JtQ0lnMFNXTGp5TFJPUGZLeVcvaHl3SmNDZlBORk1XdUlDOXBp?= =?utf-8?B?UXNhQ3JtYTVyOG92eHo3b2NiT1dLK2xKSzNLdnRqZTVGQkdHbFVxWlJ1RkFs?= =?utf-8?B?cjM5U0ZFeUhsc04vcFd4WEp0SkRPSjlubTIyaWxwMXhzWDlwdlNINDBpWHVY?= =?utf-8?B?anNpTUUyTmhncG1HRnRQUHJKUkdVc1RUY2FJbmx5NkhvWm96VXM0NUEvZWJ6?= =?utf-8?B?Vm4wbmxiaTBMMW0zQ2QyNVpDUTBwa1pyOVM3WUZBZFo5bDhtRTVHVW9GbnBr?= =?utf-8?B?QWgvc0svYmI3ajE2L01vK05mRTBFMFRhVkxiOE9tZHBtNnlTS0YzbnEwcWZ0?= =?utf-8?B?NTZhMUVaYkxFd1NEMGpPeHVOamxKc2xqV3hVbTBKN244MjZwVjhrYmM4NG55?= =?utf-8?B?UFd6QVA4Yld3L1JDdEJ1ekRmeENFd0FTQ1JpWjlrR3FjdnRkRVNxL0tZbVhF?= =?utf-8?B?eDVhamRucXN1ZU9qVzNscFRWZnBsMEJyR1pvN0pLSHZycXZJR1N3VXYrT3ZE?= =?utf-8?B?elk3NFhIKzZoSWNpTEJhRHpJWHZKL282YUlLbDhDUHUzTEorNlR0MW9lUDNu?= =?utf-8?B?WkFRQUpBNFFlQytCN00yNUZtMkY4WS9ZRlovcmNEU1pZTE5zYmJPYi9sNitF?= =?utf-8?B?di90TGRPbzhGa1FmYVRXdz09?= x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(376002)(136003)(366004)(199004)(189003)(71200400001)(58126008)(71190400001)(25786009)(6306002)(966005)(6512007)(476003)(6436002)(2616005)(53936002)(5660300002)(31696002)(478600001)(486006)(256004)(14454004)(99286004)(316002)(85182001)(64126003)(305945005)(97736004)(8676002)(8936002)(26005)(2906002)(81156014)(65806001)(6916009)(65956001)(68736007)(186003)(7736002)(86362001)(52116002)(102836004)(36756003)(81166006)(6506007)(386003)(106356001)(105586002)(3846002)(6116002)(66066001)(6486002)(31686004)(85202003)(65826007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3307; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: M2v1QEiVg3YpgKdvGuqUOMEjgfgo6SZ19tgyinUFAIaCw4MXJU6kORMd186Xhl8gJB2ofztupsY6h3WUMndNpTUB1s+mTAHWw5e9iJIPKuFGn4FSpAqw6WplHBv8VejgYd7bZK/D3VwIaKgSywW9GgVOtMTQ3lT2y+NPEoaMh1NsBN7n5xmc/kasJClJOuPsyTvjZSk9CCjlvqWtR/yedyRsdhwR3u6Gkj+gefz/GBmZXZCn3TNYijCKPV8ap3QEyUaE/l0NwvLlvt2SMP1a5TkzZNb3GuVZi+wGFkTFVMmg5A1VG24X3QWS1wHZd6fkJ7BuJ+KwzdOll7UOjLVV0mY9t996+X2yy6NmntcUUdQ6ueL17nfZn6yN3ZKgT3p5RXcnxtSrogxaKZcfcyAt6nFl7QVnE1aUOQXxOzIJzcg= Content-Type: text/plain; charset="utf-8" Content-ID: <0824208E741B2643B65EBB7FE162CEAF@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0ae9eb7a-f988-40ab-2c82-08d6a244d6aa X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 15:03:06.5238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3307 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42KZGbG9WtfgYX2MwfvDjBb73q5ndmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrTvP5gKzglVNNx2a2CcINTFyMkhIWAiMfHeJvYuRi4OIYEj jBL7965kgnC+Mkp833CPEcJZzCRxp2E+K0gLi8AEZonp6+ogElOYJPqmfoaqus8o8XjPdWaQ KjYBW4knrfvAOkQEpCV2bloEZgsLWEi0PN/ICBG3lXj49DMThK0ncfzEFRaIDSoSTTsbwebw CthLPP94AKyeUUBM4vupNWD1zALiEreezGeCeEJAYsme88wQtqjEy8f/wHaJCqRJrOl9AFWj KHH23UOw3yQEpjJKvLs0lxliaLTEq1Mn2SGKdCTOXn/CCGHLSlya3w1l+0r8XLiBDaL5JqPE ntmbWSESWhLbHlxng7ClJE5cPMoKUXRUUGLy55tQU7MlPt2fA7SaA8iWkVjbZAlR84hV4tXl 3+wTGPVnIfloFlAZs4CmxPpdUGEPiQ+zb7BD2IoSU7ofgtm8AoISJ2c+YVnAyLqKUbQ4tbg4 N93ISC+1KDO5uDg/Ty8vtWQTIzB5HNzy22oH48HnjocYBTgYlXh4+3fXxwixJpYVV+YeYpTg YFYS4XVfAxTiTUmsrEotyo8vKs1JLT7EKM3BoiTO+0dIMEZIID2xJDU7NbUgtQgmy8TBKdXA OJ+1PDxo8b6UlRdjm2bLf+Lnjpv4KPe6tN9qHvUfn0rfFyie3rjEoo151za/z20KKg1zW9Y4 zr/NY+zJWBNa2XWbc5r67Zd/zaI3ezPE7130tdjphp2CVaWY4R69qkSZ+2HvXqyQX9mlWrrm Rd2DmTzb7TKYr0TnHlcLCou3yGLWE+dO8lJUYinOSDTUYi4qTgQAaitFhRoDAAA= Archived-At: Subject: [core] SenML FETCH/PATCH without globally unique names 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, 06 Mar 2019 15:03:17 -0000 Q29SRSBXRywNCg0KT25lIGlzc3VlIG9uIFNlbk1MIEZFVENIL1BBVENIIHRoYXQgY2FtZSB1cCBk dXJpbmcgdGhlIGpvaW50IElFVEYgLyBPTUEgDQptZWV0aW5nIHdhcyB0aGF0IGl0IHdvdWxkIGJl IHVzZWZ1bCB0byBiZSBhYmxlIHRvIHVzZSBQQVRDSCBwYXlsb2FkIA0KbmFtZXMgd2l0aG91dCB0 aGUgImdsb2JhbGx5IHVuaXF1ZSBwcmVmaXgiLg0KDQpTZW5NTCBSRkMgaGFzIGEgcmVxdWlyZW1l bnQgdGhhdCBhbGwgU2VuTUwgbmFtZXMgYXJlIGdsb2JhbGx5IHVuaXF1ZSANClsxXS4gVGhpcyBl bmFibGVzIHRoZSBTZW5NTCBQYWNrcyB0byBiZSBlYXNpbHkgbW92ZWQgYmV0d2VlbiBzeXN0ZW1z IA0Kd2l0aG91dCBrbm93aW5nIHRoZSBjb250ZXh0IHRoZXkgd2VyZSBvcmlnaW5hbGx5IHJldHJp ZXZlZCBhdC4NCg0KSG93ZXZlciwgd2hlbiBTZW5NTCAoaSlQQVRDSCBpcyBhcHBsaWVkLCB0aGUg Y29udGV4dCBpcyBhbHdheXMga25vd24gYnkgDQp0aGUgcmVjZWl2ZXIgc2luY2UgdGhlIHJlY2Vp dmVyIGlzIGhvc3RpbmcgdGhlIHJlc291cmNlcyB0aGF0IGFyZSBiZWluZyANCnBhdGNoZWQuDQoN CkZvciBleGFtcGxlIHdpdGggTHdNMk0gY29tcG9zaXRlIHdyaXRlIHVzaW5nIGlQQVRDSCwgdGhl IGNvbnRlbnQgb2YgdGhlIA0KUGF0Y2ggUGFjayBpbiBKU09OIGZvcm1hdCBjb3VsZCBiZSBhcyBm b2xsb3dzOg0KDQpbeyJibiI6Ii8zMzAzLzAvIiwgIm4iOiI1NzAwIiwidiI6MjIuNH0sDQp7Im4i OiI1NjAxIiwidiI6MTIuMn0sDQp7Im4iOiI1NjAyIiwidiI6MzQuMn0sDQp7ImJuIjoiLzMzMDMv MS8iLCAibiI6IjU3MDAiLCJ2IjoxOC4yfSwNCnsibiI6IjU2MDEiLCJ2Ijo5LjJ9LA0KeyJuIjoi NTYwMiIsInYiOjI3LjJ9XQ0KDQooSGVyZSB5b3UgaGF2ZSBhIEx3TTJNIGNsaWVudCB3aXRoIHR3 byBpbnN0YW5jZXMgb2YgYSBJUFNPIHRlbXBlcmF0dXJlIA0Kc2Vuc29yLCBPYmplY3QgSUQgMzMw Mywgc3VwcG9ydGluZyBmb2xsb3dpbmcgcmVzb3VyY2VzIDU3MDA6IFNlbnNvciANClZhbHVlLCA1 NjAxOiBNaW4gTWVhc3VyZSBWYWx1ZSwgNTYwMjogTWF4IE1lYXN1cmVkIFZhbHVlKS4NCg0KSWYg d2Uga2VlcCB0aGUgc2FtZSByZXF1aXJlbWVudCBhcyBTZW5NTCBQYWNrIG5hbWVzLCBib3RoICJi biIgZmllbGQgDQp2YWx1ZXMgd291bGQgaGF2ZSB0byBiZSBwcmVmaXhlZCB3aXRoIHRoZSBMd00y TSBlbmRwb2ludCBJRCwgZS5nLiwgDQoidXJuOmRldjptYWM6MDAyNGJlZmZmZTgwNGZmMSIuIFRo aXMgd291bGQgY29uc3VtZSBhIGZhaXIgYW1vdW50IG9mIA0KYnl0ZXMgb24gd2lyZS4NCg0KT3Vy IHN1Z2dlc3Rpb24gaXMgdGhhdCB3ZSByZWxheCB0aGUgcmVxdWlyZW1lbnQgZm9yIHRoZSBuYW1l cyBpbiBQYXRjaCANClBhY2tzIHNvIHRoYXQgdGhlIG5hbWVzIGFyZSwgZm9yIGV4YW1wbGUsICJl dmFsdWF0ZWQgaW4gdGhlIGNvbnRleHQgb2YgDQp0aGUgdGFyZ2V0IHJlc291cmNlIi4gVGhhdCBp cywgYWxsIGJhc2UgbmFtZXMgY291bGQgYmUgYXV0b21hdGljYWxseSANCnByZWZpeGVkIGJ5IHRo ZSB1bmlxdWUgZW5kcG9pbnQgbmFtZSBhbmQgdGFyZ2V0IHJlc291cmNlIHBhdGguDQoNCkNvbW1l bnRzIHdlbGNvbWUhIFRoaXMgd2lsbCBiZSBkaXNjdXNzZWQgaW4gdGhlIENvUkUgaW50ZXJpbSBp biBvbmUgaG91ci4NCg0KDQpDaGVlcnMsDQpBcmkNCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM4NDI4I3NlY3Rpb24tNC4yDQo= From nobody Wed Mar 6 08:01:27 2019 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 2A1321277CE for ; Wed, 6 Mar 2019 08:01:26 -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_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 r-vjgo_GFSfo for ; Wed, 6 Mar 2019 08:01:23 -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 021211275E9 for ; Wed, 6 Mar 2019 08:01:23 -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; Wed, 6 Mar 2019 08:01:16 -0800 From: Jim Schaad To: =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , 'core WG' References: In-Reply-To: Date: Wed, 6 Mar 2019 08:01:14 -0800 Message-ID: <01d801d4d435$d4de9860$7e9bc920$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI+VIUwQmAWLhGzjgtA6d94D3QJ9aUrwnMg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] SenML FETCH/PATCH without globally unique names 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, 06 Mar 2019 16:01:26 -0000 As long as it is defined as optional, I don't see a problem. I would = worry about possible issues if it was forbidden. Jim > -----Original Message----- > From: core On Behalf Of Ari Ker=E4nen > Sent: Wednesday, March 6, 2019 7:03 AM > To: core WG > Subject: [core] SenML FETCH/PATCH without globally unique names >=20 > CoRE WG, >=20 > One issue on SenML FETCH/PATCH that came up during the joint IETF / = OMA > meeting was that it would be useful to be able to use PATCH payload = names > without the "globally unique prefix". >=20 > SenML RFC has a requirement that all SenML names are globally unique = [1]. > This enables the SenML Packs to be easily moved between systems = without > knowing the context they were originally retrieved at. >=20 > However, when SenML (i)PATCH is applied, the context is always known = by > the receiver since the receiver is hosting the resources that are = being > patched. >=20 > For example with LwM2M composite write using iPATCH, the content of = the > Patch Pack in JSON format could be as follows: >=20 > [{"bn":"/3303/0/", "n":"5700","v":22.4}, {"n":"5601","v":12.2}, > {"n":"5602","v":34.2}, {"bn":"/3303/1/", "n":"5700","v":18.2}, > {"n":"5601","v":9.2}, {"n":"5602","v":27.2}] >=20 > (Here you have a LwM2M client with two instances of a IPSO temperature > sensor, Object ID 3303, supporting following resources 5700: Sensor = Value, > 5601: Min Measure Value, 5602: Max Measured Value). >=20 > If we keep the same requirement as SenML Pack names, both "bn" field > values would have to be prefixed with the LwM2M endpoint ID, e.g., > "urn:dev:mac:0024befffe804ff1". This would consume a fair amount of = bytes > on wire. >=20 > Our suggestion is that we relax the requirement for the names in Patch Packs > so that the names are, for example, "evaluated in the context of the target > resource". That is, all base names could be automatically prefixed by = the > unique endpoint name and target resource path. >=20 > Comments welcome! This will be discussed in the CoRE interim in one = hour. >=20 >=20 > Cheers, > Ari >=20 > [1] https://tools.ietf.org/html/rfc8428#section-4.2 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 6 09:08:54 2019 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 BA33913115F for ; Wed, 6 Mar 2019 09:08:53 -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, 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 C2TQP6NuxjyK for ; Wed, 6 Mar 2019 09:08:50 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78AD313119C for ; Wed, 6 Mar 2019 09:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x26H8Ldf008369; Wed, 6 Mar 2019 18:08:27 +0100 (CET) Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44F0Zs3tMzz1Br6; Wed, 6 Mar 2019 18:08:21 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <01d801d4d435$d4de9860$7e9bc920$@augustcellars.com> Date: Wed, 6 Mar 2019 18:08:20 +0100 Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , core WG X-Mao-Original-Outgoing-Id: 573584898.92785-ae66965aba809ee4223ed1b4876e4781 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01d801d4d435$d4de9860$7e9bc920$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] SenML FETCH/PATCH without globally unique names 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, 06 Mar 2019 17:08:54 -0000 On Mar 6, 2019, at 17:01, Jim Schaad wrote: >=20 > As long as it is defined as optional, I don't see a problem. I would = worry > about possible issues if it was forbidden. The problem with the state of the proposal so far is that it is not = clear when it is invoked and when not. I can=E2=80=99t look at a Patch = document and say =E2=80=9Coh that is using non-global names=E2=80=9D. = So we need to work a bit on making it truly optional (as in both ends = know whether it is in effect or not). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 6 09:16:56 2019 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 AD96113119D for ; Wed, 6 Mar 2019 09:16:55 -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, 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 6hUcKpj0JhY6 for ; Wed, 6 Mar 2019 09:16:54 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23201311EC for ; Wed, 6 Mar 2019 09:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x26HEjJD014024 for ; Wed, 6 Mar 2019 18:14:50 +0100 (CET) Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44F0kF0rf5z1Bp8; Wed, 6 Mar 2019 18:14:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann X-Priority: 3 In-Reply-To: <74895874-55F8-4246-8A96-DBF22200EB3B@tzi.org> Date: Wed, 6 Mar 2019 18:14:44 +0100 X-Mao-Original-Outgoing-Id: 573585282.5773081-a348645f12661ab429732658ceed18c2 Content-Transfer-Encoding: quoted-printable Message-Id: <01426359-FA91-4238-8A2B-E077FB9A36D2@tzi.org> References: <83E7C5E4-CA4B-477E-96ED-0EB840F589AE@tzi.org> <74895874-55F8-4246-8A96-DBF22200EB3B@tzi.org> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Fwd: Webex meeting details: CoRE Interim Meeting today 2019-03-06 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, 06 Mar 2019 17:16:56 -0000 Updated slides for today=E2=80=99s interim are at: = https://datatracker.ietf.org/meeting/interim-2019-core-04/materials/slides= -interim-2019-core-04-sessa-chairs-dynamic-slides Thanks all for a productive discussion! Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 6 09:47:20 2019 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 5F08913122C for ; Wed, 6 Mar 2019 09:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.com header.b=a3Vxz4bH; dkim=pass (1024-bit key) header.d=ericsson.com header.b=dKgahpLR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuejmSnwph41 for ; Wed, 6 Mar 2019 09:47:17 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191CE131227 for ; Wed, 6 Mar 2019 09:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551894435; x=1554486435; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XGSGPa7uKHFuZ1Zb5gHnS/Drr1FLfkOpjcRAeeH1W3o=; b=a3Vxz4bHZ92GZlBceyVUb7lgh7PZm9dUcu0odAosjHqxZQV76qkT3jJzl81F8hc3 Wszz/DOhXLv07biz8E6R5iMjaiXHT5p7LbQ/OfqdYOu9eS9W5DoPgQLHQJbjPMEc dusDye1nRBWpbOmhvWnwjOLqH7dEr8IxxCqYOEQHV3c=; X-AuditID: c1b4fb2d-d9dff7000000062f-83-5c8007a39aef Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4A.C6.01583.3A7008C5; Wed, 6 Mar 2019 18:47:15 +0100 (CET) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 18:47:14 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 6 Mar 2019 18:47:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XGSGPa7uKHFuZ1Zb5gHnS/Drr1FLfkOpjcRAeeH1W3o=; b=dKgahpLRRWyiYj0g5k1i8tPcGkvDJGCKvVqQG8JMzzxAMW6ed1oblYAdKWcurZ7wZQZJNUrP8bjshn3vVGOzFwZOm6Ai43OVhI/R49TVBO6788U1Wt/ELwc38HcCV2DQ9r7s7V97VL9tufdU4sOckgVfib7ohrunb8P6IZby2sg= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3083.eurprd07.prod.outlook.com (10.170.244.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.11; Wed, 6 Mar 2019 17:47:12 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8%3]) with mapi id 15.20.1686.016; Wed, 6 Mar 2019 17:47:12 +0000 From: John Mattsson To: Carsten Bormann , core Thread-Topic: [core] New units for SenML Thread-Index: AQHU0AEvsXxLQOdm3kaFJvoEF2CPr6X++gGA Date: Wed, 6 Mar 2019 17:47:12 +0000 Message-ID: <1D6E287E-2FD8-4CF3-9370-7700179D690B@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cdb49507-6873-4d87-3ab9-08d6a25bc353 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3083; x-ms-traffictypediagnostic: HE1PR07MB3083: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzMDgzOzIzOnNwN29COTl2NmpRbGhkMndtVU5hM3Z4N2M4?= =?utf-8?B?cDdNUUdQcy80NWFqd2M1WFdXWTBvQzJVc1lKYitRZTZiMStRR1owMEJKeVFy?= =?utf-8?B?cVJnUG1tb1l3dFBmbmsxM01NU1ppRFNyL0F3dEhFK3hOZmRaeW55Sm1QNVYw?= =?utf-8?B?dmx2SG4rWG9vNzBESjkxL2ExQTAwQTk1K2taWklXa0NnM3gyWUJyTW9QRFRo?= =?utf-8?B?Qy9RWVZsWFVIRVM0Rk52NzJvUkwxWWVqMmdkb0hDK3o2QWZZZjhyVUZ4dUJL?= =?utf-8?B?SXE1LzY2OTQrWk85aXh0bDBIVjlMUmZ6ZnB4dXQ4OVVYdUdsV3Rjdm5XdGw2?= =?utf-8?B?d2hHMFJvblE3SWtjVHlIMmFGaWZTbjVmVzAxbUk0WE1GTk51eGZwd29uV05T?= =?utf-8?B?MExjSTZ0c2VSeXZVaEJsSnFzcUkyeEIrL1dhYTdUUzZoSEJyd1V4YjJXRnRM?= =?utf-8?B?c2ExRy9vWENsVCtYUzZ1MERtVXg3NUpGM1dHSysrQy80cExNR1FpWVdFSmk5?= =?utf-8?B?NHFTU2tlZys3eG12QjIyQUJjN1c5OUhzdktBb3hmYnVnWTN4Vm4zdy9PSFlu?= =?utf-8?B?STlVY2tSWFNaYWhxd0ZBOFZpVjlzYk5NVDVCM0U3aWVkSU0xNEROTXlQc2hv?= =?utf-8?B?U0d6RFpyenlLS1NEWVIrRXhWNStGMkNpeXJlNm9XNnUranF0eGdSV01yeTJ0?= =?utf-8?B?ZkZpVlc4NWhGSjc2Zk1SZlpZVXJrNk9TTm94TmNCLzRuYUkvTWJVVHRKbWpu?= =?utf-8?B?aklrNUFKNXY1U1ZyWU81WVEwcUFsQlYvS1lKWkhXVWVSeWx6SE91WWxWUURS?= =?utf-8?B?dlYvSjY5RkxhQmZPWnJXc1U5TExoTXBCZ3QxOXBhRlVqTFE2OGRxRnVBcVVI?= =?utf-8?B?c2NPNmZ0VEhjMkx6V2I4SU9HQ0d6NUVCTEp1ZmV4eTAxNXhXOU9RcEQ2UW5I?= =?utf-8?B?cHRnanNUQThENTJveWZDMmdKWlBFQmhPZ1Q4ZGNWdC92VFhTcW02RkxBekhW?= =?utf-8?B?Z05JcURjVmJZMEFKcUZKQk85NDFDMHMvY0ZPZnZKc0w4QkRjanNMTHJFMFBn?= =?utf-8?B?ZjRDM0IrU3hmdWN6Z1B5NmR3WmxRWS9ZOFdoS1I1UG9Yc2VOUEhCREYwTXdT?= =?utf-8?B?TklHYSs3ZDZBVG1rZ0Q4OWM2ZkU2SFdPWXk5ZWZJZVd6NktwQWhZK2twTUYx?= =?utf-8?B?QS82VjFGMTBPVFA4SElleVJzR25Vb2toUk9rWHprTVlzb2FzcTB1YUJZVFZv?= =?utf-8?B?c2tGdklaK1ZkM0hGZGZpbFEyd1pNTmtIdm1MQml5RHhPR20wMUVnSFk0d21U?= =?utf-8?B?REhtZCtSSWUvdURZcVJtS2s1SXI3eE5rUzJtNnJmbGJsNGpDQmNvRmVxQ1hk?= =?utf-8?B?KzdobVpubzRhYnF5YlZReFYrWUw4QjN6QXZMLytUUE1FSGphc0U4WnYzblRx?= =?utf-8?B?eGFOcmd2ZzNUdDRSMkI1R3Z5elZHZ2hwR1BrbzY4VFJyRlFnbTlOZXYzZmo5?= =?utf-8?B?WWNOQUE3eWhwSGRnV05wVXVSOXZhSDRJQk9YY3N5aU9JQUpTUXNiL0dZa2wy?= =?utf-8?B?TG1SZDhFVlpTRC9uNHAwaVhqRXplVzhaZmhFVHpVU1J1TWJnN0F5WmJyQ1hX?= =?utf-8?B?ZVE3dWtBcmVFY1JnQ2w2YndRU2pzamszOFYrQ2ZUYktLcFR4QndQOHE5WHdF?= =?utf-8?B?NnhKaytHeHZXU2NDOVZOc28zMU1LTlc4TEJQUzBGcnRIZHFIY0sxczZSVDRF?= =?utf-8?B?eldsd1haWFpXUmxhQnRpRGUzbTAyS0tHRU9nZ0FtMFEydmtIQnd6VW12MytY?= =?utf-8?Q?acoP1LysmjGmB?= x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(346002)(376002)(366004)(39860400002)(13464003)(189003)(199004)(14454004)(478600001)(2906002)(53546011)(8936002)(36756003)(11346002)(6506007)(76176011)(229853002)(106356001)(102836004)(86362001)(33656002)(44832011)(486006)(26005)(446003)(186003)(5660300002)(966005)(7736002)(2616005)(476003)(3846002)(105586002)(6116002)(99286004)(305945005)(14444005)(97736004)(25786009)(81166006)(81156014)(8676002)(256004)(58126008)(6306002)(71200400001)(68736007)(82746002)(83716004)(71190400001)(316002)(66066001)(6436002)(6246003)(6486002)(53936002)(110136005)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3083; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MLFxnNHqnxEjnPU/VGMhzrZa39eHq9JQ/fcY13jJxbWfOQo9P95wTpcDfxNqdRwJBpf6vkFpWU02aXvBG4GAkpUOdIT1nZHnzCRW6vb1kFGRtDzZMXut2pHkyOcsPPMF53GxM3tf94XdvnEbNuPA0MIFNSQmzWQN3VkupKmCILGKxXabKOj8PYP9CnbgvNdKZwBIqeqlTHkPR29kDx6k25dRmotjjktcWx95GRQL+QMIXvkgHzLAcxxDiH7KE/KxR2+Z7SiDwNn0zBZRNlj9afOozdYg94d35hxlbr3az5E2gQYBpWS7nOmRNkVLka5hKHMiw+c/yiFa0xDS1f8uBI2rBEeF8ept2Wv5nlINWp1s0+3C/RDfYZiMfOO64Hx+Z32nCLZj2JeR1KJuH1hPo+8Zdq5CRoQWqmPHsL93bB4= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cdb49507-6873-4d87-3ab9-08d6a25bc353 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 17:47:12.1268 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3083 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGee/dddfR6t1N82CFtoJS0mkZaEpaEMzAiKiQmrihF13qlF0n WUTDHOVXLB1+helSIvtaiJqJZq6pqaUlYSSGEyU/ogjJlmbatmvQf79znufhfTi8NMmUUL60 WpPNajWqdKmHSFAV//RSUL1Qrwh5bSHDbaZPVPjzrxYyhpA3NCwR8vI76hPEWVFUMpuuzmG1 skNKUap56kjWsv+FIsci0qNi/0LkSQMOg+7SVqoQiWgG2xB8vtpDugQGLyJ4VaLjhXoCmvJM hGsQYCMJXbfNBK+UEdBoahXywwQCfcFP5Mp74BCo6dB7uNgLh8P4YLubN+PdMOjgPV54Dxja VoQ874PvtW8IFwvwLhiaGXN7xDgaFsY/OJl2PnAQWsrcdk8cCcbOWrcd4S3gGHjoZhL7wNg0 vweMoaFjmOTZG+amVikXe2MZNN+wC/hsAhgMFRTv8Yf5Ir4y4O0wUluEeI6Dwm77+v4jAnPN cZ4DYebF8nrWF8zDP9x3AGxgYNhWuh5Ig6p7k5SrP+Bt8Cgvgvf8osDeMYaMSFb9X+9qp43E AWBpX1/LYWjiG8nzDjAVTQqr3VeRQH/VtKAOUfeRN8dyXEbKvv3BrFadxHGZmmANm92EnJ+k u/l3UBt68OWwFWEaSTeII1auKBhKlcPlZlgR0KTUSxxN6RWMOFmVe5HVZiZqdeksZ0VbaYHU R7zCSBQMTlFls2ksm8Vq/6kE7emrRzs7Yx3SvuVR+TGJzdofQ86ffBaX2Cut7rcPnF6ajU3w ORBacHNQe+t8krJd12qJfx+1sNZjKwuw+FVOnTlnPFUZ3N+kzkncWJ7fIomP2tQXOJffWDHL jLx8XLfYpcy9O/zkqE5Z/3bt3fSofq9Q1uy32h55rfNy7x+L6fpESVixVMClqkIDSS2n+gvs WvmIIAMAAA== Archived-At: Subject: Re: [core] New units for SenML 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, 06 Mar 2019 17:47:19 -0000 SGksDQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgQ2VsIGFuZCBLIGFyZSB0aGUgb25seSBleGNlcHRp b25zIGluIHRoZSBjdXJyZW50IFNlbk1MIElBTkEgcmVnaXN0cnkuIEZvcm1hbGx5LCBJIHRoaW5r IHRoZSBmb2xsb3dpbmcgYXJlIGFsc28gdGhlIHNhbWUgdW5pdHMgKGJ1dCB3aXRoIGRpZmZlcmVu dCB1c2VzIGNhc2VzKToNCg0KMSBHeSA9IDEgU3YNCjEgQnEgPSAxIEh6ID0gMS9zDQoNClNpbWls YXIsIHRoZSBuZXcgdW5pdHMgd291bGQgZm9ybWFsbHkgYmU6IA0KDQoxIEIgPSA4IGJpdA0KMSBW QSA9IDEgdmFyID0gMSBXIA0KMSBKL20gPSAxIE4NCg0KU28gSSB0aGluayB0aGUgbmV3IGRyYWZ0 IGp1c3QgY29udGludWVzIHRoZSBwcmFjdGljZXMgZXN0YWJsaXNoZWQgZm9yIHRoZSBlYXJsaWVy IHJlZ2lzdHJhdGlvbnMsIHRoZSBpbXBvcnRhbnQgdGhpbmcgZm9yIFNlbk1MIGlzIHRvIGJlIHVz ZWQgYnkgb3RoZXIgU0RPIGFuZCBpbmR1c3RyaWVzIHJhdGhlciB0aGF0IGZvbGxvd2luZyBzb21l IHN0cmljdCBtYXRoZW1hdGljYWwgcHJpbmNpcGxlIGZvciByZWdpc3RyYXRpb24uIEkgZGVmaW5p dGVseSB0aGluayBDT1JFIHNob3VsZCBnbyBhaGVhZCBhbmQgcmVnaXN0ZXIgdGhlc2UgaWYgdGhl eSBhcmUgcmVxdWVzdGVkLiANCg0KVGhlIGRyYWZ0IHNlZW1zIHZlcnkgd2VsbC13cml0dGVuLCBt eSBvbmx5IGNvbW1lbnQgaXMgdGhhdCB0aGUgZHJhZnQgY291bGQgbWF5YmUgbWVudGlvbiB0aGF0 IDEgQiA9IDggYml0LiANCg0KKFRoZSB0ZXh0IGluIGJ1bGxldCA4IG9mIFNlY3Rpb24gMTIuMSBv ZiBSRkMgODQyOCBzYXlzIHRoYXQgcEggc2hvdWxkIG5vdCBiZSB1c2VkLi4uIGlzIHRoYXQgYSB0 eXBvPyBwSCBpcyBpbiBUYWJsZSA2IG9mIHRoZSBzYW1lIFJGQykNCg0KQ2hlZXJzLA0KSm9obg0K DQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSA8Y29yZS1ib3VuY2Vz QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQpE YXRlOiBGcmlkYXksIDEgTWFyY2ggMjAxOSBhdCAwODozNA0KVG86IGNvcmUgPGNvcmVAaWV0Zi5v cmc+DQpTdWJqZWN0OiBbY29yZV0gTmV3IHVuaXRzIGZvciBTZW5NTA0KDQpTZW5NTCAoUkZDIDg0 MjgpIGhhcyBiZWVuIGEgYml0IG9mIGEgc3VjY2VzcyBzdG9yeSBmb3IgdGhpcyBXRywgYXQgbGVh c3QgKGJ1dCBub3Qgb25seSkgd2l0aCByZXNwZWN0IHRvIHBpY2t1cCBieSBvdGhlciBTRE8uICBX aGlsZSB3ZSBhcmUgZmlsbGluZyBnYXBzIGluIHRoZSBzcGVjaWZpY2F0aW9uIGl0c2VsZiAoZmV0 Y2gvKGkpcGF0Y2gsIGRhdGEtY3QpLCBhbm90aGVyIGl0ZW0gcmVjZWl2ZXMgYXR0ZW50aW9uOiBT ZW5NTOKAmXMgdW5pdCByZWdpc3RyeSwgd2hpY2ggY2FuIGJlIHVzZWZ1bCBmb3Igb3RoZXIgU0RP cyBldmVuIGJleW9uZCB0aGUgZGlyZWN0IHVzZSBvZiB0aGUgU2VuTUwgZGF0YSBmb3JtYXQuDQoN CkluIHRoaXMgY29udGV4dCwgYSBmZXcgdW5pdHMgcG9wcGVkIHVwIHRoYXQgYXJlIHNvbWV3aGF0 IGluIHN0eWxlIHdpdGggdGhlIENlbHNpdXMgZXhjZXB0aW9uIHRoYXQgUkZDIDg0MjggcHJvdmlk ZXMuICBJbnN0ZWFkIG9mIGp1c3QgaGF2aW5nIHRoZW0gcmVnaXN0ZXJlZCBzaWxlbnRseSwgbWF5 YmUgaXQgaXMgZ29vZCB0byBoYXZlIHNvbWUgYXR0ZW50aW9uIGZvciB0aGVtIGhlcmUgaW4gdGhl IFdHLiAgVG8gdGhhdCBlbmQsIGJhc2VkIG9uIGlucHV0IGZyb20gT01BIChidXQgYWxsIG1pc3Rh a2VzIGFyZSBtaW5lKSwgSSBoYXZlIHdyaXR0ZW4gYSBkcmFmdDoNCg0KTmFtZToJCWRyYWZ0LWJv cm1hbm4tc2VubWwtbW9yZS11bml0cw0KUmV2aXNpb246CTAwDQpUaXRsZToJCUFkZGl0aW9uYWwg VW5pdHMgZm9yIFNlbk1MDQpEb2N1bWVudCBkYXRlOgkyMDE5LTAyLTI3DQpHcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9ybWFubi1zZW5tbC1tb3JlLXVuaXRzLw0KSHRt bGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3JtYW5uLXNl bm1sLW1vcmUtdW5pdHMtMDANCg0KQWJzdHJhY3Q6DQogIFRoZSBTZW5zb3IgTWVhc3VyZW1lbnQg TGlzdHMgKFNlbk1MKSBtZWRpYSB0eXBlIHN1cHBvcnRzIHRoZQ0KICBpbmRpY2F0aW9uIG9mIHVu aXRzIGZvciBhIHF1YW50aXR5IHJlcHJlc2VudGVkLiAgVGhpcyBzaG9ydCBkb2N1bWVudA0KICBy ZWdpc3RlcnMgYSBudW1iZXIgb2YgYWRkaXRpb25hbCB1bml0IG5hbWVzIGluIHRoZSBJQU5BIHJl Z2lzdHJ5IGZvcg0KICBVbml0cyBpbiBTZW5NTC4NCg0KRGlzY3Vzc2luZyBwaHlzaWNhbCBxdWFu dGl0aWVzIGFuZCB0aGVpciB1bml0cyBtYXkgYmUgbm90IGJlIHRoZSBDb1JFIFdH4oCZcyBjZW50 ZXIgb2YgZ3Jhdml0eSwgYnV0IGlmIHlvdSBjYXJlIGFib3V0IHRoZSBpbnRlZ3JpdHkgb2YgU2Vu TUwsIHBsZWFzZSBoYXZlIGEgbG9vayBpbnRvIHRoaXMgc2hvcnQgZHJhZnQuICBUaGUgSUFOQSBw b2xpY2llcyBhbGxvdyB1cyB0byBnbyBhaGVhZCB3aXRoIHJlZ2lzdHJhdGlvbiBiZWZvcmUgdGhp cyBpcyBhbiBSRkMgKGV2ZW4gYmVmb3JlIGFueSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uISksIHdo aWNoIHdvdWxkIGZpdCB3ZWxsIHdpdGggT01BIHRpbWVsaW5lcywgc28gc29tZSBmZWVkYmFjayBm cm9tIHRoZSBXRyBub3cgd291bGQgaGVscCBnZXR0aW5nIHRoYXQgcmlnaHQuDQoNClNvcnJ5IGZv ciBmb3JnZXR0aW5nIHRoZSBXRyBuYW1lIGluIHRoZSBkcmFmdCBuYW1lIGFuZCBnb2luZyBkaXJl Y3RseSB0byB0aGUgbmFtZSBzZW5tbCDigJQgbmV3cyBvZiBhIG5ldyBTZW5NTCBXRyBhcmUgZ3Jl YXRseSBleGFnZ2VyYXRlZCA6LSkNCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNv cmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K DQo= From nobody Wed Mar 6 10:27:39 2019 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 B57DA129A87 for ; Wed, 6 Mar 2019 10:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aiS4eqXevIX for ; Wed, 6 Mar 2019 10:27:29 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E938F130FE5 for ; Wed, 6 Mar 2019 10:27:28 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5B55442ED1; Wed, 6 Mar 2019 19:27:25 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A15C036; Wed, 6 Mar 2019 19:27:23 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6EE346A; Wed, 6 Mar 2019 19:27:23 +0100 (CET) Received: (nullmailer pid 13829 invoked by uid 1000); Wed, 06 Mar 2019 18:27:23 -0000 Date: Wed, 6 Mar 2019 19:27:22 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Cc: core WG Message-ID: <20190306182721.GA12162@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] SenML FETCH/PATCH without globally unique names 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, 06 Mar 2019 18:27:32 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ari & WG, On Wed, Mar 06, 2019 at 03:03:06PM +0000, Ari Ker=E4nen wrote: > One issue on SenML FETCH/PATCH that came up during the joint IETF / OMA= =20 > meeting was that it would be useful to be able to use PATCH payload=20 > names without the "globally unique prefix". >=20 > [...] >=20 > However, when SenML (i)PATCH is applied, the context is always known by= =20 > the receiver since the receiver is hosting the resources that are being= =20 > patched. as pointed out in today's interim, I think that makes it hard for the server to tell whether the client is thinking strings (nothing to prefix) or URIs (please prefix canonical(?) URI). I'd suggest the addition of an extension that makes the desired prefixing explicit: [{"bprefix-uribase_": true, "bn":"/3303/0/", "n":"5700","v":22.4}, {"n":"5601","v":12.2}, {"n":"5602","v":34.2}, {"bn":"/3303/1/", "n":"5700","v":18.2}, {"n":"5601","v":9.2}, {"n":"5602","v":27.2}] This would set the name of all records where it's set (by virtue of having a "b", or being a document property that can only sit in the first record) to be prefixed with the Base URI according to RFC 3986 Section 5.1. (Or resolved-relative-to, I don't care any more; good choices of URIs make this moot). Applications that Know What They're Doing (like LwM2M PATCHing) can set this, and by virtue of the trailing underscore, an application that doesn't have a well-established base URI can't use that. The extension would be independent of the used method, so could be used in a PUT or even GET as well. (In a semi-related note, I'm not 100% sure that the Base URI of a PATCH payload is actually the request's URI because RFC3986 talks of the "URI used to *retrieve* the entity"; who feels qualified to answer this?) An easy alternative would be the introduction of a static prefix by the same extension mechanism ({"bprefix_": "urn:dev:..."}) that effectively builds a two-level base name. Not simple, but would achieve the same compression for large messages. BR Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyAEQMACgkQOY0REtOk veFSyBAAhc9jDotWzkWpefQg9swufyIi1FVERDHCMDYGKImenYJ9CEGJGRXWLCke a/vZ8yBqJryQK2LDfU/tF6+ZkaS9/YBfp/DN2E1OFL3q5SP5MN9rAmmV6x1IKCK+ f2+XQ2AxmyYqpWgxW9/3Gc0uuR35Ba/siCwx2uOsyvpXoWl7AY6VMIOZfJjMGYf/ ceg+IWtDybWgejsLDcQOz4L+o8c1G2WHu6H2000hxHwlHjGVFAFoGP65pFRmkYAa t0lUkHXj6qyAAEQ+GJw4Vf0IxSfNFDCFCAFAcA5xVfBvJ75W9Z/e3pDVlVBcSeLX duK1bTrdJZGu5mtFNOf6eez8qPJacFUpQRYtBDICqPtKTwe0cFQbWQXR7UCtiUWE ohnaytCk3AZ8ZE7cTGbI721/wru+AaDtQzn5k0hjfBQhbrPnGA5ayQ9POPmU5BUt H+puN7SKw+1oFvBOT4/r4uQ2EchQ4bCOIodeHikh2/eNe0Q5Iuk3OhbjsXhKblSc 3BDp+FFU51O+PvPgtz9XZavtort5L8tsQb3HCI6tBrTaqqdCAa9ve7ex/monqiGX nvy/NsFXJAO69xhJMmDumMw5zXGG73vmzEQix9X8qnev2WKUNjNV7TaMKPO+uvL0 seEVTIynQjZjTZIHJSfJqSLei23eDakGHnfennSv7H0gwpRAu9s= =A68g -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From nobody Thu Mar 7 23:51:27 2019 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 A38AA13132A; Thu, 7 Mar 2019 23:51:14 -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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155203147460.5390.6743817237636754497@ietfa.amsl.com> Date: Thu, 07 Mar 2019 23:51:14 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dynlink-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: Fri, 08 Mar 2019 07:51:23 -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 : Dynamic Resource Linking for Constrained RESTful Environments Authors : Zach Shelby Michael Koster Christian Groves Jintao Zhu Bilhanan Silverajan Filename : draft-ietf-core-dynlink-08.txt Pages : 20 Date : 2019-03-07 Abstract: This specification defines Link Bindings, which provide dynamic linking of state updates between resources, either on an endpoint or between endpoints, for systems using CoAP (RFC7252). This specification also defines Conditional Notification Attributes that work with Link Bindings or with CoAP Observe (RFC7641). Editor note The git repository for the draft is found at https://github.com/core- wg/dynlink The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dynlink/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-dynlink-08 https://datatracker.ietf.org/doc/html/draft-ietf-core-dynlink-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dynlink-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 Fri Mar 8 01:53:33 2019 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 D6ABE128B77; Fri, 8 Mar 2019 01:53:22 -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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155203880285.3244.15135224611384658659@ietfa.amsl.com> Date: Fri, 08 Mar 2019 01:53:22 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-groupcomm-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 09:53:23 -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 : Group OSCORE - Secure Group Communication for CoAP Authors : Marco Tiloca Goeran Selander Francesca Palombini Jiye Park Filename : draft-ietf-core-oscore-groupcomm-04.txt Pages : 38 Date : 2019-03-08 Abstract: This document describes a mode for protecting group communication over the Constrained Application Protocol (CoAP). The proposed mode relies on Object Security for Constrained RESTful Environments (OSCORE) and the CBOR Object Signing and Encryption (COSE) format. In particular, it defines how OSCORE is used in a group communication setting, while fulfilling the same security requirements for group requests and responses. Source authentication of all messages exchanged within the group is provided by means of digital signatures produced by the sender and embedded in the protected CoAP messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-oscore-groupcomm-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 8 02:11:58 2019 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 32DCC130F20 for ; Fri, 8 Mar 2019 02:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgO0qNd_Y2Sj for ; Fri, 8 Mar 2019 02:11:53 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61682130EE7 for ; Fri, 8 Mar 2019 02:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fC77vtPQ9Slk7dnQuFTDXTjIdY9S/jamBPjzslXMR7s=; b=QUowHC7JtoMKRx/iCyJcHdjIxM34cc4ovP2BeNnQxLb7HxVDjfKgZkxxYHERXdEV1a3rHwAdrmsFal9h35yA8QvVcOvrBqGMlSv0e1U8cR93bY9Z7rvoh+bO5NtrODN8IYxGWNyBIVDWzfuyI9TLrEF5CZtYs8hWKjgFxQd/R8s= Received: from HE1P189CA0030.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::43) by AM5P189MB0321.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:20::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Fri, 8 Mar 2019 10:11:49 +0000 Received: from HE1EUR02FT019.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::204) by HE1P189CA0030.outlook.office365.com (2603:10a6:7:53::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18 via Frontend Transport; Fri, 8 Mar 2019 10:11:49 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT019.mail.protection.outlook.com (10.152.10.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1643.21 via Frontend Transport; Fri, 8 Mar 2019 10:11:48 +0000 Received: from [10.8.8.29] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Fri, 8 Mar 2019 11:11:48 +0100 References: <155203880301.3244.4243570738064788975.idtracker@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Openpgp: preference=signencrypt Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== X-Forwarded-Message-Id: <155203880301.3244.4243570738064788975.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 8 Mar 2019 11:11:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <155203880301.3244.4243570738064788975.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="thYmRlZtBO9H2lsedOwMshwbW35yjo1sR" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(376002)(136003)(2980300002)(53754006)(189003)(199004)(106002)(33964004)(5660300002)(8936002)(84326002)(14444005)(386003)(478600001)(966005)(65826007)(7736002)(76176011)(235185007)(5024004)(606006)(77096007)(40036005)(64126003)(8676002)(106466001)(86362001)(31696002)(31686004)(68736007)(16526019)(186003)(81156014)(81166006)(69596002)(66574012)(446003)(11346002)(65956001)(2906002)(6116002)(97736004)(74482002)(65806001)(15650500001)(53936002)(71190400001)(336012)(316002)(229853002)(6916009)(16576012)(6666004)(21480400003)(104016004)(568964002)(356004)(22756006)(476003)(6306002)(54896002)(236005)(2473003)(3846002)(44832011)(126002)(36756003)(16586007)(486006)(58126008)(2616005)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P189MB0321; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 588078ee-54ea-4021-e120-08d6a3ae7a38 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060)(7193020); SRVR:AM5P189MB0321; X-MS-TrafficTypeDiagnostic: AM5P189MB0321: X-Microsoft-Exchange-Diagnostics: 1; AM5P189MB0321; 20:+fFTjCfS1SbJxOzcYz49kvOq9RuVQeqWs4r7WL4aFPoFjsviUCczQr9gF8mUxuz2nS47wn4OVmHzz9B0crEaGhpZTd9l2g/CUrUISbkL2COUgU4SXld6EeTxIyaGkhiajogIzjPeUJ2dfuroVOF0KBsTpq0BsWcqFDn1i52+aK70ZtUMsaIduvZPLG/BD0MzTOH9iTqgdK3mY1cgILtSiPBc/DoRUNm7A6tFr6TkAY0edBLkkA5w7MOt92JW6fbo X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0970508454 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM5P189MB0321; 23:P0UEF6Pz1dT66dDEhuJf5LdEogvYOP5vJLzxCaNJe?= =?us-ascii?Q?aFRvv1n2wPJelcjGk9IYToIPnMx28utb74udMnlb/DYkfcZ2q08VCDUIO9zJ?= =?us-ascii?Q?Wg661gpsmShAmR0eB7JegtYsNQ0tkAVTs/cL3nsdOXrdMJkn8vmDIk8t6j5c?= =?us-ascii?Q?0UgLPzr0J5Jwi/0goeDWiMmdfVWKBOBZsplE1+CbZj4nCZV0J+v0fj11wJxk?= =?us-ascii?Q?9QtogWNU/QZdtczhGvNQ5N7VqmYL1b7twjZg0g3RkXdgcboCmMoPTsZG4M0Q?= =?us-ascii?Q?/9D5AR7/JEQNvXtzrRP06HIQWyJSfTzhi1Jn7DVQPE1An7RTQS6ZVFos2b38?= =?us-ascii?Q?9YvK3uOzSA3jFYcVdEIEHCNZyRbjBR5VuFwbVqeE74h10z9qrKxoGBzuz1ij?= =?us-ascii?Q?75pZhANAfwfYGhNrXbvjPLiB5KVj/uaC65e+M9eWkqcMugFWew1r6kpC1hqh?= =?us-ascii?Q?Mx3m5KcG0sgDpYbeSNybMSwKx0aKISljATtyBGRjdEttfe/HejR1g1k/Gr5F?= =?us-ascii?Q?hWaPQ1A9p3GsgzdcCEo8J9YWn3l4R8yUHmN+o4Q5XjUS6LXHuVy2sVpY8cXz?= =?us-ascii?Q?ntUaEWssLi2l2rfPbubqi88dPLEkShz4CVdIfT/EpC2wUX1755zKIzYws/xT?= =?us-ascii?Q?tG4S6eFCWtpIeh2M9ybTGthcfqB0E7EuQQV03NxjF94zF1/2ofnCjH0iRIBh?= =?us-ascii?Q?XU7uyYKFjidoymKwA1mveN/3xsJHZyQb8alFe9MNbyaMzG1WLa4H2vy1Datv?= =?us-ascii?Q?d6fT4/YdI1a2LPELbAy/TWJNstbNctKk4YfusY3gxn6lcGA8bGXB9zmGdGwA?= =?us-ascii?Q?RINVtNq9aICLelQleDX+ZilDZv7KNgH/41v/foudLvr338SHLBWLf1wjl99A?= =?us-ascii?Q?pchIJgui9+BNlJbL6LmW15gs8QQKjnAww5MR8f55lq4wbL01Y33HyhvJMlQK?= =?us-ascii?Q?q2ZgVUtyqkJXk6QvrMMVeDcvCB0yzkVzz/39m+zjVrW/y3fZw+NKLkPVEGsS?= =?us-ascii?Q?FrGgkSz25m0Mf5Vt2HTKrmdeAVDaUdlnmsccaJIvuMeW+VQ4XGZcKyUMIvve?= =?us-ascii?Q?474mbWhkaVMcB4a2ukqGKXcv6AXW1DzecJ5q05or39xI4NZCMWwomnxjM0VE?= =?us-ascii?Q?1VtJ5qSBoLIY70HVqvQA32oBpFkOC1GewNqSxPZ3Edey8zFT9yN0m1Ze6BL3?= =?us-ascii?Q?x+YBD4LLJCyX1EF8KAybJvZ/gleET91uQSUk4YWowGrB6tWa5YR8MjpvOlQy?= =?us-ascii?Q?NgnH4u32VDNZ9uEjjkzDhOuBozlYmZVfVZTy3HrIeUnxETNL3lGGgPesLQq5?= =?us-ascii?Q?aeO1Cy3GGwqcIp4paSP7tcXV01LKtWUoCRXmhZi0Byl0oPa3h0Xr8C+HwhEL?= =?us-ascii?Q?bGsGrWV9WKwnTrPul+DG2XfX1m0QLueUvLhhVnmKkpuWQ5WLoedDAqmW5lnE?= =?us-ascii?Q?Jp30P6tJeD3HV/6at0/IEGriBKzlHNeTv4sfw0cesX8LM6ndSdek18EE1a8U?= =?us-ascii?Q?0on0kusYIp/mNFebJygQe20LsRmGVwqpRIDRVZprLySsBc6s2w3/srgNClPj?= =?us-ascii?Q?bj4Duz1b2mL/cNxt8LqAj6oy69MIA5zduuHseYgXvBZqXnMv0RhBBlhrYOTy?= =?us-ascii?Q?VC73mae2Fbvs0fzshUPdQsExmLngptUEzIQzGZ7S5A=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: byo7pUfz82F1J5D8AbFKFua5sUbVe3V6P4gyr2PZ35GCav6X2JnQJWHCat6vsUx0eq7etCiZKYzGIrWCB02HDsnvlYO7wmasHRPn0q7gSKmGc0iqBUJ8vEi/i/wHemuucvaxlf549Zjv/tXXMdpkXmxHPW00fPC+orht1lGfh7hAWX0P3Ojveml64kSw2kDUizHp9cBRVLBqBdoc1QFsMNM/MLWzYRjKa1wAshaM8BTDBlvP/PZ1b/cT2TUkKcfG9NclZYu7mRq+/EkCShSDKWpezLQH1S3OfIRrLF8OxDmYUsYO/H1DQQiDPEZqxw7VUBAwMsmGK07QtUw4Zq0wZQl5K2Tz3vSZc2KwMzxGNcLc7vQqZYOkLvhg6fMElbwWNLaYNZpIl2vSBR5SCNrGi+DjDnGnPwca0ZaIiAYH20I= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2019 10:11:48.8948 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 588078ee-54ea-4021-e120-08d6a3ae7a38 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P189MB0321 Archived-At: Subject: [core] Fwd: New Version Notification for draft-ietf-core-oscore-groupcomm-04.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: Fri, 08 Mar 2019 10:11:57 -0000 --thYmRlZtBO9H2lsedOwMshwbW35yjo1sR Content-Type: multipart/mixed; boundary="m4V1dKzpv2eozqkut4CQ44ubJFO3DH3B1"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: Fwd: New Version Notification for draft-ietf-core-oscore-groupcomm-04.txt References: <155203880301.3244.4243570738064788975.idtracker@ietfa.amsl.com> In-Reply-To: <155203880301.3244.4243570738064788975.idtracker@ietfa.amsl.com> --m4V1dKzpv2eozqkut4CQ44ubJFO3DH3B1 Content-Type: multipart/alternative; boundary="------------3B8AFCADA32E9DA74CE68F80" Content-Language: en-US This is a multi-part message in MIME format. --------------3B8AFCADA32E9DA74CE68F80 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Among other things, this updated version addresses especially comments from Jim (thanks a lot!) discussed in: https://mailarchive.ietf.org/arch/msg/core/BVGdqKPAl6T4mc6hW_EyAfzYYbk https://mailarchive.ietf.org/arch/msg/core/ee149hXdIg1vM_qWc-8xkDnsSG0 Best, /Marco -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-core-oscore-groupcomm-04.txt Date: Fri, 8 Mar 2019 01:53:23 -0800 From: internet-drafts@ietf.org To: Marco Tiloca , Jiye Park , Goeran Selander , Francesca Palombini A new version of I-D, draft-ietf-core-oscore-groupcomm-04.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-ietf-core-oscore-groupcomm Revision: 04 Title: Group OSCORE - Secure Group Communication for CoAP Document date: 2019-03-08 Group: core Pages: 38 URL: https://www.ietf.org/internet-drafts/draft-ietf-core-oscore-groupcomm-04.= txt Status: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm= / Htmlized: https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-04= Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-oscore-groupcom= m-04 Abstract: This document describes a mode for protecting group communication over the Constrained Application Protocol (CoAP). The proposed mode relies on Object Security for Constrained RESTful Environments (OSCORE) and the CBOR Object Signing and Encryption (COSE) format. In particular, it defines how OSCORE is used in a group communication setting, while fulfilling the same security requirements for group requests and responses. Source authentication of all messages exchanged within the group is provided by means of digital signatures produced by the sender and embedded in the protected CoAP messages. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------3B8AFCADA32E9DA74CE68F80 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all,

Among other things, this updated version addresses especially comments from Jim (thanks a lot!) discussed in:

https://mailarchive.ietf.org/ar= ch/msg/core/BVGdqKPAl6T4mc6hW_EyAfzYYbk

https://mailarchive.ietf.org/ar= ch/msg/core/ee149hXdIg1vM_qWc-8xkDnsSG0

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-ietf-core-oscore-groupcomm-04.txt
Dat= e: Fri, 8 Mar 2019 01:53:23 -0800
Fro= m: internet-drafts@ietf.org
To:= Marco Tiloca <marco.tiloca@ri.se>, Jiye Park <ji-ye.park@uni-due.de>, Goeran Selander <goran.selander@ericsson.com>, Francesca Pa= lombini <francesca.palombini@ericsson.com>



A new version of I-D, draft-ietf-core-oscore-groupcomm-04.txt
has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-ietf-core-oscore-groupcomm
Revision: 04
Title: Group OSCORE - Secure Group Communication for CoAP
Document date: 2019-03-08
Group: core
Pages: 38
URL: https://www.ietf.org/inte= rnet-drafts/draft-ietf-core-oscore-groupcomm-04.txt
Status: https://datatracker.ietf.or= g/doc/draft-ietf-core-oscore-groupcomm/
Htmlized: https://tools.ietf.org/html/draf= t-ietf-core-oscore-groupcomm-04
Htmlized: https://datatracker.iet= f.org/doc/html/draft-ietf-core-oscore-groupcomm
Diff: https://www.ietf.org/rfc= diff?url2=3Ddraft-ietf-core-oscore-groupcomm-04

Abstract:
This document describes a mode for protecting group communication over the Constrained Application Protocol (CoAP). The proposed mode
relies on Object Security for Constrained RESTful Environments
(OSCORE) and the CBOR Object Signing and Encryption (COSE) format.<= br> In particular, it defines how OSCORE is used in a group communication
setting, while fulfilling the same security requirements for group<= br> requests and responses. Source authentication of all messages
exchanged within the group is provided by means of digital signatures
produced by the sender and embedded in the protected CoAP messages.



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

--------------3B8AFCADA32E9DA74CE68F80-- --m4V1dKzpv2eozqkut4CQ44ubJFO3DH3B1-- --thYmRlZtBO9H2lsedOwMshwbW35yjo1sR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAlyCP94ACgkQ7iZktA5Y 2kMa7wf+KVDXNzfPtqPsFvqyQdKTsqVoVsc9Pa7bYTmfUWcn303LApYoJZh1BOFT nUO1ktNYhou9sPSeJAjOsCnPheIXR6Qu9/erS8Mrrq5JIY5FGZF5zJaF10I8FoI5 RhDqViK5ti67JqDRjlO4T5MeXVtQIIPTcJ4oh5YOJGpHVM7BurTsOaxbrFRh9fbn DkuGUxkpp0ZPipYT1bRbEb3or6G8g2W3IXVaondrLzMJQdC6aOEMY4rY+NJEPkTD TIb1RJO8RWtf0wsEBLTUzUBVIryITrYCTMTHNiPRwf7FrYrVDJkVihdHXNWkmu7y AesjPszQmLW749M2zZprP/H9jBUevw== =xQXn -----END PGP SIGNATURE----- --thYmRlZtBO9H2lsedOwMshwbW35yjo1sR-- From nobody Fri Mar 8 05:45:14 2019 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 4EA98127980 for ; Fri, 8 Mar 2019 05:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5_IQgxYzMLW for ; Fri, 8 Mar 2019 05:45:07 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ACB0127598 for ; Fri, 8 Mar 2019 05:45:06 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6220F42131 for ; Fri, 8 Mar 2019 14:45:04 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0592936 for ; Fri, 8 Mar 2019 14:45:03 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CEE6944 for ; Fri, 8 Mar 2019 14:45:01 +0100 (CET) Received: (nullmailer pid 22726 invoked by uid 1000); Fri, 08 Mar 2019 13:45:01 -0000 Date: Fri, 8 Mar 2019 14:45:01 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core WG Message-ID: <20190308134459.GA7720@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [core] Sketch of "Keep it simple" / "Never reified union types" 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, 08 Mar 2019 13:45:10 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (interim follow-up) Reply-To:=20 Hello CoRE, following up on the last interim, I've sketched up what I understood the keep-it-simple solution to the pubsum problem of allowing empty topics could look like. Most of the text below deals with how proxies would handle it, the actual client and server behaviors should be indeed simple and straightforward. Best regards Christian The Accept-Any-Of option =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A new option Accept-Any-Of is defined. It is critical (I don't fully see why but follow Accept here), safe-to-foward and part of the cache key. Its format is uint up to 2 long (indicating content types), it is Class E in OSCORE, usable in requests only, and repeatable (Repeatability is the only aspect in which it differs from Accept in terms of option properties). Its values indicate a list of acceptable representations in order of decreasing preference. A server MUST answer with the first format it can represent the requested state in, or 4.06 (Not Acceptable) if it could answer successfully but the response would not match any of the option values. Proxy behavior -------------- A proxy MAY serve a cached representation to a request with a different sequence of Accept-Any-Of options, provided the second request has an Accept value of the cached representation, or all the content formats that precede the available content format in the second request's Accept-Any-Of options also preceded the available representation in an earlier (fresh) request's list. When a request that carries Accept-Any-Of is answered 4.06 (or with any but the first format requested by Accept-Any-Of), a proxy SHOULD [ we can't have a MUST here w/o making it non-safe-to-forward, but I think it's sufficient ] invalidate all known representations in any of the requested formats (or the formats preceeding the returned one, respectively). Update to RFC7641 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The requirement that subsequent notifications carry the same Content-Format option as the original response is lifted. Impact ------ Changes to the returned media type can either happen when * Accept-Any-Of was sent in the request -- in which case both server and client know the updated rules, or * no Accept header was sent -- in which case the server whose representation changes to require a new content format has no clear way of indicating that under RFC7641 (ending with 4.06 Not Acceptable would be close but isn't the expected response to a repeated request); if the server changes the content format in a notification to an unaware client, the client would catch it as a bad response (probably similar to a response with a Content-Format not matching the sent Accept). The client might consider the observation over while the server does not, and will terminate the observation with a RST on the next notification (or close the connection in TCP). Impact on proxies: A proxy that enforces the previous rule on Content-Format staying constant would close observations (probably with something like 5.02 Bad Gateway), and the client would need to re-establish. No proxy implementations are known that implement that behavior. [ But I know only one so this would definitely need to be confirmed on the mailing list ]. [ I don't think that this has any actual interactions with the caching model, as the caching considerations are independent of the content format. ] Usage in pubsub =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topics that were created but do not have any publication are represented in the application/nothing-here-to-see (or application/null? either TBD) type. The PUBLISH operation would probably not need to accept nothing-here-to-see, at leat create-on-publish can't do that as there is no type to set on the topic with such an initial publication. Requests to the topic with an Accept option of the topic's type will return 4.06 Not Acceptable both in observations (subscription) and plain get requests (read). The subscribe (and possibly read) operation therefore will not use the Accept header, but Accept-Any-Of with nothing-here-to-see and the topic's designate type, in that sequence. Thus, a proxy may serve a nothing-here-to-see as long as it is fresh (as it always could), but it sees a notification carrying the actual type, that evicts the nothing-here-to-see from its cache. (Conversely, if a topic goes to nothing-here-to-see, that will not clear out any cached-but-still-fresh value from the cache. As long as publishers are not allowed to explicitly send nothing-here-to-see, this will not happen, because topics only enter nothing-here-to-see when their content expires, at which time all its caches expire as well. The broker might not even send the nothing-here-to-see in a notification [ ? ].) --=20 This may seem a bit weird, but that's okay, because it is weird. -- perldata(1) about perl variables --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyCcdgACgkQOY0REtOk veF2pg/9HaxjlECKJJ3HhIjrcAvYOMHzCsojDl9M+SdPPluHOmf8cSaGoMKuKNR7 xFU0gBUTBWG7kKbXM9qsn2syst9lD2MQFqUlcBIDMJvy+5XGL3dIIhkXpK8+3Fcs SxUz0cLw3L/CbTe9NB3LNcBZ+cQOqGs7MuWWwYL6ZgBhOEqpYr4xPRtCs7ar+I+2 oHp5NFRLgyWK8nWyTdrE+zI7mVNpVCMe2va2+An+wb801phRcht6hX9CAT+IY8A7 k/plsgRxta+FgaiseSJBMb++taQC3Ikem0xNu0nScjL63dkh5p1mj/rFvb6dC1bZ BfpmrA7kreefjTwYBjYMhh8NCx0gs1NB//zZi6AKLGwI5jYSbu4HWyC7kQMZCUlu ebyYxXcllnTaqPqOQAiLsgOYYPxz6FDHhjNoIBDw7BJTde1I+cP7wIah8PkJt0zD FPqHZbxSQYICaqZNz45cDYVWPkqJ+CU8rUe8Lj2xNIts4bixhHvWdfCkGeWEKsS0 chwAju1iJ4q9Q9UScJ9WuPYJq2/G9NL4w5WJNMABbkrOTB5DSeJdVgiT787lzN85 EzpSS+QQL9q+ZfeU/FLvjFDi3z7gEmMjiE4l9VIX2MAQ7CCtpvC0pD3WNVCflBv2 JYAIQgwjUFszWFJ5RzNuMKnpBPIAASHJUVHa1ODLcj3f9zCV4Z4= =eEJh -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From nobody Fri Mar 8 12:17:31 2019 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 723681277CD; Fri, 8 Mar 2019 12:17:23 -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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155207624342.3291.18090244257061831133@ietfa.amsl.com> Date: Fri, 08 Mar 2019 12:17:23 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-multipart-ct-03.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: Fri, 08 Mar 2019 20:17:24 -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 : Multipart Content-Format for CoAP Authors : Thomas Fossati Klaus Hartke Carsten Bormann Filename : draft-ietf-core-multipart-ct-03.txt Pages : 9 Date : 2019-03-08 Abstract: This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of zero or more different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-multipart-ct-03 https://datatracker.ietf.org/doc/html/draft-ietf-core-multipart-ct-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-multipart-ct-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 8 15:44:42 2019 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 44519127918; Fri, 8 Mar 2019 15:44:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jaime Jimenez via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Jaime Jimenez , jaime.jimenez@ericsson.com, core-chairs@ietf.org, iesg-secretary@ietf.org, core@ietf.org Message-ID: <155208868027.3232.7919301853065513198.idtracker@ietfa.amsl.com> Date: Fri, 08 Mar 2019 15:44:40 -0800 Archived-At: Subject: [core] Publication has been requested for draft-ietf-core-multipart-ct-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 23:44:40 -0000 Jaime Jimenez has requested publication of draft-ietf-core-multipart-ct-03 as Proposed Standard on behalf of the CORE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ From nobody Sat Mar 9 15:11:27 2019 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 7461A129441; Sat, 9 Mar 2019 15:11:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla via Datatracker To: "The IESG" Cc: draft-ietf-core-object-security@ietf.org, Carsten Bormann , jaime.jimenez@ericsson.com, core-chairs@ietf.org, cabo@tzi.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155217308647.28794.17453696870430692819.idtracker@ietfa.amsl.com> Date: Sat, 09 Mar 2019 15:11:26 -0800 Archived-At: Subject: [core] Eric Rescorla's No Record on draft-ietf-core-object-security-16: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 23:11:26 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-core-object-security-16: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS points. From nobody Sat Mar 9 15:13:02 2019 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 E4E12129441; Sat, 9 Mar 2019 15:13:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla via Datatracker To: "The IESG" Cc: draft-ietf-core-object-security@ietf.org, Carsten Bormann , jaime.jimenez@ericsson.com, core-chairs@ietf.org, cabo@tzi.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155217318093.28702.9713045585741617980.idtracker@ietfa.amsl.com> Date: Sat, 09 Mar 2019 15:13:00 -0800 Archived-At: Subject: [core] Eric Rescorla's No Objection on draft-ietf-core-object-security-16: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 23:13:01 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-core-object-security-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Grr. No Objection From nobody Mon Mar 11 02:37:06 2019 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 0AC7713104A; Mon, 11 Mar 2019 02:36:43 -0700 (PDT) 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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155229700298.16968.3257053096174949406@ietfa.amsl.com> Date: Mon, 11 Mar 2019 02:36:43 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-stateless-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: Mon, 11 Mar 2019 09:36:56 -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 : Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) Author : Klaus Hartke Filename : draft-ietf-core-stateless-01.txt Pages : 16 Date : 2019-03-11 Abstract: This document provides considerations for alleviating CoAP clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-stateless/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-stateless-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-stateless-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/ From nobody Mon Mar 11 04:16:41 2019 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 D7E89130FCB for ; Mon, 11 Mar 2019 04:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj4uq6DKqXyI for ; Mon, 11 Mar 2019 04:16:34 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20086.outbound.protection.outlook.com [40.107.2.86]) (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 0F21F13104D for ; Mon, 11 Mar 2019 04:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=90XnANc0NhSoiqwF/Ajd731wvdPyhKPd/cRwDGz/pD0=; b=kKw5DiRGhj9QAYqggwzwWpcVBrVDWTFaL2zlQIXfcifFwPrt9czkAQ+KUimoHVneS8t7rXiktQ96UEmeqg78ygucRtmXOw9FC0SM9CiHw0F7h5D47hTpyOOZw04Z59DInDe2oliTYS6rsUFZlF9MKhfC9FykJdwJtbg6Vz5ibbs= Received: from VI1P18901CA0023.EURP189.PROD.OUTLOOK.COM (2603:10a6:801::33) by DB6P18901MB0104.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:27::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.16; Mon, 11 Mar 2019 11:16:31 +0000 Received: from HE1EUR02FT007.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::202) by VI1P18901CA0023.outlook.office365.com (2603:10a6:801::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18 via Frontend Transport; Mon, 11 Mar 2019 11:16:30 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT007.mail.protection.outlook.com (10.152.10.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1643.21 via Frontend Transport; Mon, 11 Mar 2019 11:16:29 +0000 Received: from [10.8.0.2] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Mon, 11 Mar 2019 12:16:03 +0100 References: <155230214201.16857.15407850936286018798.idtracker@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Openpgp: preference=signencrypt Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== X-Forwarded-Message-Id: <155230214201.16857.15407850936286018798.idtracker@ietfa.amsl.com> Message-ID: <1d2f910d-ad9f-85bb-0563-f1b4f9f6d482@ri.se> Date: Mon, 11 Mar 2019 12:15:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <155230214201.16857.15407850936286018798.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dsNLDmh6ZAX20UEoYqMXHHOuHP0fMgY8S" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(136003)(396003)(39850400004)(346002)(2980300002)(189003)(199004)(53754006)(16526019)(53936002)(5024004)(15650500001)(16576012)(336012)(606006)(21480400003)(16586007)(6666004)(65806001)(14444005)(478600001)(58126008)(65956001)(68736007)(356004)(106002)(65826007)(186003)(966005)(64126003)(22756006)(104016004)(74482002)(40036005)(71190400001)(8676002)(316002)(33964004)(22746008)(229853002)(84326002)(486006)(36756003)(69596002)(31696002)(6916009)(44832011)(2906002)(8936002)(81156014)(76176011)(66574012)(97736004)(5660300002)(7736002)(54896002)(2473003)(6306002)(11346002)(31686004)(446003)(236005)(386003)(106466001)(235185007)(2616005)(86362001)(77096007)(6116002)(126002)(476003)(3846002)(568964002)(81166006)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P18901MB0104; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8e453b82-ec2a-406f-0803-08d6a613026d X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060)(7193020); SRVR:DB6P18901MB0104; X-MS-TrafficTypeDiagnostic: DB6P18901MB0104: X-Microsoft-Exchange-Diagnostics: 1; DB6P18901MB0104; 20:M0oqUXajOBIdARkc70vRsX3vTqyPbYwYevF4xM3/ZZzILw+E/fMZyhM7OZ5bWEmvzjRUpO4ihlNmIabmGtHb/ftgzQYlpfykyGW9lQvGdk0aYzGWLukh3Y4qKoWxSwmK++pqFkdyRfi+4d4ImfDXpuyrET+AvfnqpyYjpw5fPk2eSpV3OE537gDpipNlNTwkXJ7Zl0vmmXr6A2XsXDGpK/kC8jpqgx0LEaqkW5GHOvrcVJ7cizlQBpTeWpztumAw X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09730BD177 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB6P18901MB0104; 23:cTIZ8UndKuDJ9G2JG5oUUfdolXtithTqoxq6bEh?= =?us-ascii?Q?MhUeXErTQqoYlxZ6F2Z98eA6IoPv8t/aUh46rjxLFY4uwTEvhYQGDl8ZMH8Y?= =?us-ascii?Q?Ui96bw7KuNFaLp7doWuuPxEjdwL1ivON0OdxPFDEVARuIaFcvDftplBi+hti?= =?us-ascii?Q?SC0CHB1Isc1sacJlIBgpQwAXXutSuJF9KA87h5WSbLxD659lEhwJNq3XcbPM?= =?us-ascii?Q?3Gs2M7VoEFSNONe5gWUAprZLTW+RpiQcOO6gsAnE3lhh1BPCkL8MLRiBXfYx?= =?us-ascii?Q?QZeCD1GXZ1PQH4jfiMvhLH7Gp8xgj1ZaUPZP2XmYaLkhzLAia/i1osYJO/Zl?= =?us-ascii?Q?3YrEM/9CiMiybgQ6hkmrTiqCscjyw4oZEnw4PuABravPYg9AXRIXv4NSbTXi?= =?us-ascii?Q?bT6IMI3QrSNQmsfoiDRl0qMTMko1kaPNaS5V499H4xgthigE7jsLk00xuBZI?= =?us-ascii?Q?+K0Cbs50Nk7DL/5QU0awHiG66lmPmIZ90VE6CUUC1pFRj8v+GCGQyGakoxlt?= =?us-ascii?Q?B2QD3+cUU067wfWgXiBRwF5/YfBAYnsJ6qqXmaQOLzrop48DiRrnuM3GQqYN?= =?us-ascii?Q?KFnvxqJh8QfqKrpNOH+1s2Wikn2dbwjOHH/wDrE3+qDS5X2WENVYjubu0E+v?= =?us-ascii?Q?OC0lYxLy5BcGGeg7NZ5rISqR+XB2T5xHDAHt8pHcvDXAlWK2lfc0+JkaTg1/?= =?us-ascii?Q?P+UpnhJgQxlrwfmTgqSR3aI1xUfWGp8pUNh4Sqvd7eNOu68uMNLi/TITlKqm?= =?us-ascii?Q?bjcCYlwQw6rFjHPTshOVxmLra9znVobLYb4sKSpfnlV42e5i5SromsGhVyrX?= =?us-ascii?Q?sIP9vdAkgk5JXxf2ldrfJ828cKccnpJnC74Td4tvGIw9XUU2YJkA8Os0cXID?= =?us-ascii?Q?ntc6Bumk3FdmwiKJarBGUI1jsX+2JyPdWZTnfCgGXyUewxH4G/Or1AYlKUq7?= =?us-ascii?Q?IjXfGzlgsdLqB+iTfZV806zZ3eRk/M755aaD5Pepcsf6GXoGCAvCgEFZ2oKO?= =?us-ascii?Q?opZhd5wQ+PMgofxqSbuYdvzPpTMNgdfRZXb6R+/NAfTRjWYac9XUpeGcDXYE?= =?us-ascii?Q?HbR5tG/6rgAWxqM+GkAM8HnMCOC5jUA2/WafkzRLOjmInBv7WH4ZsrSvEEsH?= =?us-ascii?Q?u8x1XGTl2Dr+2fbdrD2dGanP+GIega3YHnEccJvZAFZoFgBPGn0GEuziDHSP?= =?us-ascii?Q?ff3CgQ4iiItW94RNV9m+/bUwcOmiPBPZPZFjP++H8TzBXNa1HNu5j5aPEHxZ?= =?us-ascii?Q?MQ3Nk4M00bvukpza3WeHAlRRHM0Q9AM+4eWW/DX4u0J7N6AvNppUYqhV0BmC?= =?us-ascii?Q?xBdAcJmgkrEYomM2IuqYw/BOqVBhvnhImTSjHe7mXXtkkKQmzZRqErh/fiuF?= =?us-ascii?Q?MKXhFlAolWFQC80YVuGTkjevA7dWACaehjPqq5m9gju2qzV6U43NBJnWqy9W?= =?us-ascii?Q?5yXNdWXJUYlIhTljbx+5rar08xTONVkvSkRQF2Eyu7lGuGcH4ezsSgon+T13?= =?us-ascii?Q?DB7qdKvFwCgXC2gWaiF4rtbliHHsEcrc5wZNcSaOl7D3ul53FSKHRsg2x5AN?= =?us-ascii?Q?QtUzmz98uMLyckakqqqrq6kE2E9/20CemPLz0TeaaZGfV4uxlDcEC8DsMcJ6?= =?us-ascii?Q?f2yA7qQ3bn9K0G9eap3/2eXHZFWHY6UunP/1MIH0EzY4gzbYs6uU6qyLUrgj?= =?us-ascii?Q?yayGL?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: c43DriJMt6fzxIyx03I2IwFweR/+GO3XXP+9qjngI3Rp1agyMXP8Q4rw7qkVhDPhJfYe6zg29NBtv9yCHQkJleSt8RtqyuajYhqpJ5LJgDiLaex79vzkVua3nvjDoftCz9rAsE02lR7sV6sZHsBcMiJkvwkLKH5WVtA9QF0hkb3D+uW6B5tYv+qvq74a3hQDsuBxmfvXBT2lDM8ranCEmUl+ENl8WnEG6ldKyVHJaqr0YkDpIj4aUFz7URnbIfPhJvC7NaAEKU0ihJXx0M4/UjiEGEBfm/LV5/R0ua0ovyVaoq41QTg50I3Drh+Thx2L+zo0hsWsW1Hvsvqg84cxc3Vbuj+BjK4z7J24TTs9bXAsQuH7+GIMHzsSxK7hykRQPlsP0Jy2QIgieZqcFbRw4RkCpTkNl8nxlFeAWsSenbw= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2019 11:16:29.3972 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8e453b82-ec2a-406f-0803-08d6a613026d X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0104 Archived-At: Subject: [core] Fwd: New Version Notification for draft-tiloca-core-oscore-discovery-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 11:16:39 -0000 --dsNLDmh6ZAX20UEoYqMXHHOuHP0fMgY8S Content-Type: multipart/mixed; boundary="pL5FldceMnAAKUuqCvLJbhxY8KLdMByhW"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <1d2f910d-ad9f-85bb-0563-f1b4f9f6d482@ri.se> Subject: Fwd: New Version Notification for draft-tiloca-core-oscore-discovery-02.txt References: <155230214201.16857.15407850936286018798.idtracker@ietfa.amsl.com> In-Reply-To: <155230214201.16857.15407850936286018798.idtracker@ietfa.amsl.com> --pL5FldceMnAAKUuqCvLJbhxY8KLdMByhW Content-Type: multipart/alternative; boundary="------------0C06A05810CBE4D9BA9A9E68" Content-Language: en-US This is a multi-part message in MIME format. --------------0C06A05810CBE4D9BA9A9E68 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, We have just submitted an updated version of draft-tiloca-core-oscore-discovery https://tools.ietf.org/html/draft-tiloca-core-oscore-discovery-02 The document describes how to use the CoRE Resource Directory for discovering OSCORE groups and retrieving information to join them through their Group Manager. This is the second update after IETF 103, so taking into account: 1) The new RD-Group usage pattern introduced in v -17 of draft-ietf-core-resource-directory. 2) The comments from Jim (thanks!) discussed at https://mailarchive.ietf.org/arch/msg/core/Bm2fQbeimLw5WutQZL2CXthI9fs Comments are very welcome! Best, /Marco -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-core-oscore-discovery-02.txt Date: Mon, 11 Mar 2019 04:02:22 -0700 From: internet-drafts@ietf.org To: Christian Amsuess , Marco Tiloca , Peter van der Stok A new version of I-D, draft-tiloca-core-oscore-discovery-02.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-core-oscore-discovery Revision: 02 Title: Discovery of OSCORE Groups with the CoRE Resource Directory Document date: 2019-03-11 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-tiloca-core-oscore-discovery-0= 2.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-core-oscore-discove= ry/ Htmlized: https://tools.ietf.org/html/draft-tiloca-core-oscore-discovery-= 02 Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-core-oscore-discovery Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-tiloca-core-oscore-discovery-02= Abstract: Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Object Security for Constrained RESTful Environments (OSCORE). At deployment time, devices may not know the exact OSCORE groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how CoAP endpoints can use the CoRE Resource Directory to discover OSCORE groups and acquire information to join them through their respective Group Manager. A same OSCORE group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of OSCORE groups based on the ACE framework for Authentication and Authorization in constrained environments. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------0C06A05810CBE4D9BA9A9E68 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all,

We have just submitted an updated version of draft-tiloca-core-oscore-discovery

https://tools.ietf.org/html/draf= t-tiloca-core-oscore-discovery-02

The document describes how to use the CoRE Resource Directory for discovering OSCORE groups and retrieving information to join them through their Group Manager.

This is the second update after IETF 103, so taking into account:
=
1) The new RD-Group usage pattern introduced in v -17 of draft-ietf-core-resource-directory.

2) The comments from Jim (thanks!) discussed at https://mailarchive.ietf.or= g/arch/msg/core/Bm2fQbeimLw5WutQZL2CXthI9fs

Comments are very welcome!

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-core-oscore-discovery-02.txt
Dat= e: Mon, 11 Mar 2019 04:02:22 -0700
Fro= m: internet-drafts@ietf.org
To:= Christian Amsuess <christian@amsuess.com>, Marc= o Tiloca <marco.tiloca@ri.se>, Peter van der Stok <consultancy@vanderstok.org>



A new version of I-D, draft-tiloca-core-oscore-discovery-02.txt
= has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-core-oscore-discovery
Revision: 02
Title: Discovery of OSCORE Groups with the CoRE Resource Directory<= br> Document date: 2019-03-11
Group: Individual Submission
Pages: 13
URL: https://www.ietf.org/in= ternet-drafts/draft-tiloca-core-oscore-discovery-02.txt
Status: https://datatracker.ietf.= org/doc/draft-tiloca-core-oscore-discovery/
Htmlized: https://tools.ietf.org/html/dr= aft-tiloca-core-oscore-discovery-02
Htmlized: https://datatracker.i= etf.org/doc/html/draft-tiloca-core-oscore-discovery
Diff: https://www.ietf.org/r= fcdiff?url2=3Ddraft-tiloca-core-oscore-discovery-02

Abstract:
Group communication over the Constrained Application Protocol (CoAP)
can be secured by means of Object Security for Constrained RESTful<= br> Environments (OSCORE). At deployment time, devices may not know the
exact OSCORE groups to join, the respective Group Manager, or other
information required to perform the joining process. This document<= br> describes how CoAP endpoints can use the CoRE Resource Directory to
discover OSCORE groups and acquire information to join them through
their respective Group Manager. A same OSCORE group may protect
= multiple application groups, which are separately announced in the<= br> Resource Directory as sets of endpoints sharing a pool of resources.
This approach is consistent with, but not limited to, the joining of
OSCORE groups based on the ACE framework for Authentication and
= Authorization in constrained environments.



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

--------------0C06A05810CBE4D9BA9A9E68-- --pL5FldceMnAAKUuqCvLJbhxY8KLdMByhW-- --dsNLDmh6ZAX20UEoYqMXHHOuHP0fMgY8S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAlyGQ24ACgkQ7iZktA5Y 2kNQpAf/fC0EZhdTRDfcQOYPe2UBQHq4lGgMNgX114GnPYbS124coZVrMZo97MVX fBhl5V1eKlKnxjFX53XHuddrHFz+pSl9ZCzfGP734DO/axwVfhfZeE18M9w33R+w g2Eyuajwjw96U5xf9eKTQDP/Ogvx0+1zw7EvoQcwI5ogjsY91iXC3n+/ZRkts4vw gCHiPEHD69g4HJ6Z3oJWoz8E/7bA9+1V6v1vWCd4ABmDfJxIRf449oJeCJBb+8aL e/Od+jlFeRVwdPPVOqu7s6Gd4gZEmS0FHL3zJsTt3m6vPHvkaA008AzBfNQ4CCka /QLDDMCJKQhqgNsmAsmAWtnl3spzfQ== =jgS1 -----END PGP SIGNATURE----- --dsNLDmh6ZAX20UEoYqMXHHOuHP0fMgY8S-- From nobody Mon Mar 11 08:23:54 2019 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 9FF0313114E for ; Mon, 11 Mar 2019 08:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZbPoaSlSpOU for ; Mon, 11 Mar 2019 08:23:50 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 218281310F1 for ; Mon, 11 Mar 2019 08:23:27 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id u9so3942818pfn.1 for ; Mon, 11 Mar 2019 08:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+U9T4YdEHSwjuU7ZK68Nj+or/T21B2uVsI4HJ1OZNZg=; b=nnjrpWCEgLGBhTQkpzwJKxCXboWXsEHsrAY6AX5+Qmy2mAueuugDLGS6teqhRRc8dg FK05vu8YZNEqgwaC3zYtO1sLIoPr3bK4My7I31EacwG2/eqP/HeQ1f53EkSPB/6vXdX8 /imk+5GytBpAbzmiElJLwPvGmOeHnUFK1dajZ0csZD6qiYKpTKe8B4RlZXPQNfdYz8vI pzGXwxcqGbPYlHrzPEWEfm/7zsoFjAOcndI+hdHZSo9dzBoA8vwAkjeqVi5qflyTFqw6 pp+vezDbjOutY0zWUpkQoLsTE2l1KHEYPXdFGa3lmfBQeM3PG/PoM5J4NDhzh6Fu+95e EVLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+U9T4YdEHSwjuU7ZK68Nj+or/T21B2uVsI4HJ1OZNZg=; b=EqzPslwf7q9qa5h23i/8A8j15s8/0MNQmMzZpZpu4VMfuHB5fGu6NiiyKzk89Q0X8Z 2zy5tYQxG1kHoROV8voFnHBW2/OKYePOO3h3X+cJnR+Ky3ZckBCl9f3eUJLVzY/HmnWJ led9+ugMJqeWBGCz0UUi5/tYe72bs86nB/XV5a6v1qgVD3htmZrV5L/8FElMDxE/pveo gre05ah9sw+6ob2g1WNv5/lsUblTzVH448kuyTZ+WjSc8L45Ls/4STCmGTCm0wZsF/pA y7mD44DnOIX4igB6hVDxaAQETybztrGTN1koDG5+udo7HrVW44CT6Fo644RYLa1TCepP 1kRA== X-Gm-Message-State: APjAAAWFKpQ0o+vkPeJgBrIZEeYownnQAmRDXgjkEcNZk1lvej41lLQF +K7tbzHZRmv8lN6+M8mSvn8= X-Google-Smtp-Source: APXvYqxAXsdFGvMR1tIlLP6we1cYHm1WpzoJwY3aXV8JKW/w/hiesPhqRZRb2dl9BjaWeuMOnVLuwg== X-Received: by 2002:a65:510c:: with SMTP id f12mr30996795pgq.40.1552317806389; Mon, 11 Mar 2019 08:23:26 -0700 (PDT) Received: from [172.16.0.3] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id z18sm14768445pfl.164.2019.03.11.08.23.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Mar 2019 08:23:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: <20190308134459.GA7720@hephaistos.amsuess.com> Date: Mon, 11 Mar 2019 08:23:23 -0700 Cc: core WG , =?utf-8?Q?Ari_Ker=C3=A4nen?= , =?utf-8?Q?Jaime_Jim=C3=A9nez?= Content-Transfer-Encoding: quoted-printable Message-Id: <162F3D30-6DF8-4A73-A018-94CD511EB2F1@gmail.com> References: <20190308134459.GA7720@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Sketch of "Keep it simple" / "Never reified union types" 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, 11 Mar 2019 15:23:53 -0000 Hi Christian (and CoRE), In the spirit of handling "empty topic" case in the application layer, = as we discussed, I propose to have the publisher be responsible to = publish "nothing-here-to-see" as a topic's initial value if it has no = initial value in the more meaningful content format.=20 (Keeping in mind that, as defined, CoAP pub/sub only handles = representations, and is not strictly a proxy for resource state, = therefore should not be responsible for generating default = representations in any particular content format, except the required = link-format in the case of create-on-publish). The pub-sub behavior would be to reply to READ/SUBSCRIBE only when = something has been published. The topic creator is thus responsible to = "promptly" publish nothing-here-to-see upon topic creation. Otherwise = the broker simply acks any READ/SUBSCRIBE request and waits to send a = response until something is published.=20 The broker might be allowed to ack and queue subscribe (observe) = requests that come in before something is published.=20 When a topic's max-age expires, the broker returns 4.xx; there would be = no separate data lifetime. Publish operations reset the topic lifetime = and could change the topic's lifetime by including max-age in the = PUBLISH request. This way, the Accept-Any option and the nothing-here-to-see content = formats may be defined in separate independent drafts, and the multipart = format may be used with its potential accept-subformat options. This is how I interpreted the result of the discussion on Thursday where = we decided to keep the pub/sub draft simple. WIll this work? Best regards, MIchael > On Mar 8, 2019, at 5:45 AM, Christian Ams=C3=BCss = wrote: >=20 > (interim follow-up) > Reply-To:=20 >=20 > Hello CoRE, >=20 > following up on the last interim, I've sketched up what I understood = the > keep-it-simple solution to the pubsum problem of allowing empty topics > could look like. >=20 > Most of the text below deals with how proxies would handle it, the > actual client and server behaviors should be indeed simple and > straightforward. >=20 > Best regards > Christian >=20 >=20 > The Accept-Any-Of option > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=20 > A new option Accept-Any-Of is defined. It is critical (I don't fully = see > why but follow Accept here), safe-to-foward and part of the cache key. > Its format is uint up to 2 long (indicating content types), it is = Class > E in OSCORE, usable in requests only, and repeatable >=20 > (Repeatability is the only aspect in which it differs from Accept in > terms of option properties). >=20 > Its values indicate a list of acceptable representations in order of > decreasing preference. A server MUST answer with the first format it = can > represent the requested state in, or 4.06 (Not Acceptable) if it could > answer successfully but the response would not match any of the option > values. >=20 > Proxy behavior > -------------- >=20 > A proxy MAY serve a cached representation to a request with a = different > sequence of Accept-Any-Of options, provided the second request has an > Accept value of the cached representation, or all the content formats > that precede the available content format in the second request's > Accept-Any-Of options also preceded the available representation in an > earlier (fresh) request's list. >=20 > When a request that carries Accept-Any-Of is answered 4.06 (or with = any > but the first format requested by Accept-Any-Of), a proxy SHOULD [ we > can't have a MUST here w/o making it non-safe-to-forward, but I think > it's sufficient ] invalidate all known representations in any of the > requested formats (or the formats preceeding the returned one, > respectively). >=20 >=20 > Update to RFC7641 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The requirement that subsequent notifications carry the same > Content-Format option as the original response is lifted. >=20 > Impact > ------ >=20 > Changes to the returned media type can either happen when >=20 > * Accept-Any-Of was sent in the request -- in which case both server = and > client know the updated rules, or > * no Accept header was sent -- in which case the server whose > representation changes to require a new content format has no clear > way of indicating that under RFC7641 (ending with 4.06 Not Acceptable > would be close but isn't the expected response to a repeated = request); > if the server changes the content format in a notification to an > unaware client, the client would catch it as a bad response (probably > similar to a response with a Content-Format not matching the sent > Accept). The client might consider the observation over while the > server does not, and will terminate the observation with a RST on the > next notification (or close the connection in TCP). >=20 > Impact on proxies: A proxy that enforces the previous rule on > Content-Format staying constant would close observations (probably = with > something like 5.02 Bad Gateway), and the client would need to > re-establish. No proxy implementations are known that implement that > behavior. [ But I know only one so this would definitely need to be > confirmed on the mailing list ]. >=20 > [ I don't think that this has any actual interactions with the caching > model, as the caching considerations are independent of the content > format. ] >=20 >=20 > Usage in pubsub > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Topics that were created but do not have any publication are = represented > in the application/nothing-here-to-see (or application/null? either = TBD) > type. >=20 > The PUBLISH operation would probably not need to accept > nothing-here-to-see, at leat create-on-publish can't do that as there = is > no type to set on the topic with such an initial publication. >=20 > Requests to the topic with an Accept option of the topic's type will > return 4.06 Not Acceptable both in observations (subscription) and = plain > get requests (read). The subscribe (and possibly read) operation > therefore will not use the Accept header, but Accept-Any-Of with > nothing-here-to-see and the topic's designate type, in that sequence. > Thus, a proxy may serve a nothing-here-to-see as long as it is fresh = (as > it always could), but it sees a notification carrying the actual type, > that evicts the nothing-here-to-see from its cache. (Conversely, if a > topic goes to nothing-here-to-see, that will not clear out any > cached-but-still-fresh value from the cache. As long as publishers are > not allowed to explicitly send nothing-here-to-see, this will not > happen, because topics only enter nothing-here-to-see when their = content > expires, at which time all its caches expire as well. The broker might > not even send the nothing-here-to-see in a notification [ ? ].) >=20 >=20 > --=20 > This may seem a bit weird, but that's okay, because it is weird. > -- perldata(1) about perl variables > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Mar 11 08:52:25 2019 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 A56041310ED for ; Mon, 11 Mar 2019 08:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwGErdKow9m6 for ; Mon, 11 Mar 2019 08:52:19 -0700 (PDT) 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 0E27E13110E for ; Mon, 11 Mar 2019 08:51:56 -0700 (PDT) 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; Mon, 11 Mar 2019 08:51:48 -0700 From: Jim Schaad To: 'Michael Koster' , =?utf-8?Q?'Christian_Ams=C3=BCss'?= CC: 'core WG' , =?utf-8?Q?'Jaime_Jim=C3=A9nez'?= References: <20190308134459.GA7720@hephaistos.amsuess.com> <162F3D30-6DF8-4A73-A018-94CD511EB2F1@gmail.com> In-Reply-To: <162F3D30-6DF8-4A73-A018-94CD511EB2F1@gmail.com> Date: Mon, 11 Mar 2019 08:51:46 -0700 Message-ID: <03ce01d4d822$56cb9fe0$0462dfa0$@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: AQKtCI43Gmbmyv63u6747dLwvrof5gHGbCZBpEf/oTA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Sketch of "Keep it simple" / "Never reified union types" 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, 11 Mar 2019 15:52:24 -0000 Michael, It is not clear to me below if a published data item is going to have an = age value or not. I would expect that they should but the minimum age = would be 0. At that point the age on the data item stays at 0, but the = item is not removed from the subscription. Jim > -----Original Message----- > From: core On Behalf Of Michael Koster > Sent: Monday, March 11, 2019 8:23 AM > To: Christian Ams=C3=BCss > Cc: core WG ; Jaime Jim=C3=A9nez > Subject: Re: [core] Sketch of "Keep it simple" / "Never reified union = types" >=20 > Hi Christian (and CoRE), >=20 > In the spirit of handling "empty topic" case in the application layer, = as we > discussed, I propose to have the publisher be responsible to publish > "nothing-here-to-see" as a topic's initial value if it has no initial = value in the > more meaningful content format. >=20 > (Keeping in mind that, as defined, CoAP pub/sub only handles > representations, and is not strictly a proxy for resource state, = therefore > should not be responsible for generating default representations in = any > particular content format, except the required link-format in the case = of > create-on-publish). >=20 > The pub-sub behavior would be to reply to READ/SUBSCRIBE only when > something has been published. The topic creator is thus responsible to > "promptly" publish nothing-here-to-see upon topic creation. Otherwise = the > broker simply acks any READ/SUBSCRIBE request and waits to send a > response until something is published. >=20 > The broker might be allowed to ack and queue subscribe (observe) = requests > that come in before something is published. >=20 > When a topic's max-age expires, the broker returns 4.xx; there would = be no > separate data lifetime. Publish operations reset the topic lifetime = and could > change the topic's lifetime by including max-age in the PUBLISH = request. >=20 > This way, the Accept-Any option and the nothing-here-to-see content > formats may be defined in separate independent drafts, and the = multipart > format may be used with its potential accept-subformat options. >=20 > This is how I interpreted the result of the discussion on Thursday = where we > decided to keep the pub/sub draft simple. WIll this work? >=20 > Best regards, >=20 > MIchael >=20 > > On Mar 8, 2019, at 5:45 AM, Christian Ams=C3=BCss = > wrote: > > > > (interim follow-up) > > Reply-To: > > > > Hello CoRE, > > > > following up on the last interim, I've sketched up what I understood > > the keep-it-simple solution to the pubsum problem of allowing empty > > topics could look like. > > > > Most of the text below deals with how proxies would handle it, the > > actual client and server behaviors should be indeed simple and > > straightforward. > > > > Best regards > > Christian > > > > > > The Accept-Any-Of option > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > A new option Accept-Any-Of is defined. It is critical (I don't fully > > see why but follow Accept here), safe-to-foward and part of the = cache key. > > Its format is uint up to 2 long (indicating content types), it is > > Class E in OSCORE, usable in requests only, and repeatable > > > > (Repeatability is the only aspect in which it differs from Accept in > > terms of option properties). > > > > Its values indicate a list of acceptable representations in order of > > decreasing preference. A server MUST answer with the first format it > > can represent the requested state in, or 4.06 (Not Acceptable) if it > > could answer successfully but the response would not match any of = the > > option values. > > > > Proxy behavior > > -------------- > > > > A proxy MAY serve a cached representation to a request with a > > different sequence of Accept-Any-Of options, provided the second > > request has an Accept value of the cached representation, or all the > > content formats that precede the available content format in the > > second request's Accept-Any-Of options also preceded the available > > representation in an earlier (fresh) request's list. > > > > When a request that carries Accept-Any-Of is answered 4.06 (or with > > any but the first format requested by Accept-Any-Of), a proxy SHOULD = [ > > we can't have a MUST here w/o making it non-safe-to-forward, but I > > think it's sufficient ] invalidate all known representations in any = of > > the requested formats (or the formats preceeding the returned one, > > respectively). > > > > > > Update to RFC7641 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > The requirement that subsequent notifications carry the same > > Content-Format option as the original response is lifted. > > > > Impact > > ------ > > > > Changes to the returned media type can either happen when > > > > * Accept-Any-Of was sent in the request -- in which case both server > > and client know the updated rules, or > > * no Accept header was sent -- in which case the server whose > > representation changes to require a new content format has no clear > > way of indicating that under RFC7641 (ending with 4.06 Not = Acceptable > > would be close but isn't the expected response to a repeated = request); > > if the server changes the content format in a notification to an > > unaware client, the client would catch it as a bad response = (probably > > similar to a response with a Content-Format not matching the sent > > Accept). The client might consider the observation over while the > > server does not, and will terminate the observation with a RST on = the > > next notification (or close the connection in TCP). > > > > Impact on proxies: A proxy that enforces the previous rule on > > Content-Format staying constant would close observations (probably > > with something like 5.02 Bad Gateway), and the client would need to > > re-establish. No proxy implementations are known that implement that > > behavior. [ But I know only one so this would definitely need to be > > confirmed on the mailing list ]. > > > > [ I don't think that this has any actual interactions with the = caching > > model, as the caching considerations are independent of the content > > format. ] > > > > > > Usage in pubsub > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Topics that were created but do not have any publication are > > represented in the application/nothing-here-to-see (or > > application/null? either TBD) type. > > > > The PUBLISH operation would probably not need to accept > > nothing-here-to-see, at leat create-on-publish can't do that as = there > > is no type to set on the topic with such an initial publication. > > > > Requests to the topic with an Accept option of the topic's type will > > return 4.06 Not Acceptable both in observations (subscription) and > > plain get requests (read). The subscribe (and possibly read) = operation > > therefore will not use the Accept header, but Accept-Any-Of with > > nothing-here-to-see and the topic's designate type, in that = sequence. > > Thus, a proxy may serve a nothing-here-to-see as long as it is fresh > > (as it always could), but it sees a notification carrying the actual > > type, that evicts the nothing-here-to-see from its cache. > > (Conversely, if a topic goes to nothing-here-to-see, that will not > > clear out any cached-but-still-fresh value from the cache. As long = as > > publishers are not allowed to explicitly send nothing-here-to-see, > > this will not happen, because topics only enter nothing-here-to-see > > when their content expires, at which time all its caches expire as > > well. The broker might not even send the nothing-here-to-see in a > > notification [ ? ].) > > > > > > -- > > This may seem a bit weird, but that's okay, because it is weird. > > -- perldata(1) about perl variables > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Mar 11 10:36:25 2019 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 E17441286E7 for ; Mon, 11 Mar 2019 10:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 XD_ORmPuDTRK for ; Mon, 11 Mar 2019 10:36:22 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399D3128B01 for ; Mon, 11 Mar 2019 10:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x2BHaBwx011206 for ; Mon, 11 Mar 2019 18:36:17 +0100 (CET) Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44J4yg4mYfz1Bp8; Mon, 11 Mar 2019 18:36:11 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann Date: Mon, 11 Mar 2019 18:36:10 +0100 X-Mao-Original-Outgoing-Id: 574018568.941985-8a081e2ac3aaae3bf8d7035fc460d9ab Content-Transfer-Encoding: quoted-printable Message-Id: References: <155232527016.23134.15624613562412422263.idtracker@ietfa.amsl.com> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] And now for something completely different: draft-bormann-core-media-content-type-format-00 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, 11 Mar 2019 17:36:25 -0000 If you need a break from busily making and reading Internet-Drafts: I finally could not bear it any longer and wrote it up :-) > Name: draft-bormann-core-media-content-type-format > Title: On Media-Types, Content-Types, and related = terminology > Status: = https://datatracker.ietf.org/doc/draft-bormann-core-media-content-type-for= mat/ > Htmlized: = https://tools.ietf.org/html/draft-bormann-core-media-content-type-format-0= 0 >=20 > Abstract: > There is a lot of confusion about media-types, content-types, and > related terminology. >=20 > This memo is an attempt at clearing it up. Matthias Kovatsch brought this up repeatedly at previous WISHI = hackathons; apparently the amount of committee time spent on this = confusion was already considerable by then. I=E2=80=99m sure it happens = in other SDOs, too. Maybe we can get more eyes on this document and = actually get it published so we never have to define these terms in new = RFCs again. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 11 12:35:49 2019 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 4D36813119D; Mon, 11 Mar 2019 12:35:42 -0700 (PDT) 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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155233294226.23134.1429390956350570600@ietfa.amsl.com> Date: Mon, 11 Mar 2019 12:35:42 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-interfaces-14.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: Mon, 11 Mar 2019 19:35:46 -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 : Reusable Interface Definitions for Constrained RESTful Environments Authors : Zach Shelby Michael Koster Christian Groves Jintao Zhu Bilhanan Silverajan Filename : draft-ietf-core-interfaces-14.txt Pages : 25 Date : 2019-03-11 Abstract: This document defines a set of Constrained RESTful Environments (CoRE) Link Format Interface Descriptions [RFC6690] applicable for use in constrained environments. These include the: Actuator, Parameter, Read-only parameter, Sensor, Batch, Linked Batch and Link List interfaces. The Batch, Linked Batch and Link List interfaces make use of resource collections. This document further describes how collections relate to interfaces. Many applications require a set of interface descriptions in order provide the required functionality. This document defines an Interface Description attribute value to describe resources conforming to a particular interface. Editor's notes: o The git repository for the draft is found at https://github.com/ The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-interfaces-14 https://datatracker.ietf.org/doc/html/draft-ietf-core-interfaces-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 12:51:02 2019 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 59412131122 for ; Mon, 11 Mar 2019 12:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqSiJ76zkriD for ; Mon, 11 Mar 2019 12:50:58 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 8FDA71310F8 for ; Mon, 11 Mar 2019 12:50:58 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id r124so4844419pgr.3 for ; Mon, 11 Mar 2019 12:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RT7HKhDQYcQuTOGi/PST68TTHFtDtqfctSvvdCLbgFU=; b=AAKR/cRKv6BvS9q8UlpuMl1nDUNlcD4j/bxe4eC5BXnTPT9fBQEdkGFNwai+keKHZe AKtO7SLNSkScPvXnp83uIfHc79dgNEDq5/FeOOLXM2RpvnB3nYYnN7MiXo2FsxNIlkRs ZluNCya/TmwHVeWj5I6Gl+QBzzVPUVVe31zVZ6qJZMlb5307rFsxD+SVQEKTNnkxReyU SbSD/tMzxMSb3iSTsByCgHzclPbT0XqsP1qJR36hft1l10RTaZGFTi5U/bjzG0xGgTHc go5zWfffCoTrPCYW9Ry76zPyfkcI+n7AKc+Pp8S/eaC4cPHiP7FGhNO2IfENknLhUb0e 7tDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RT7HKhDQYcQuTOGi/PST68TTHFtDtqfctSvvdCLbgFU=; b=dMWBU+O7MNGQkqYiKXxAaLNuRrfWh2StofBOcV0507tnSg/n34pdv2BrSry21lZDqB J5gNZilLWED6hYRxi8NMk87b6CiRC53G/x5/Yr8eIp2Tq8WdhQQDuxwlJpK+6lBDfsFV rHyKvqyF4ce1W4dHiaXQmyOq/WpMZF6YHpQBGFOkQlm+dXcJc1tjYY99mhXxiGdCjd30 2QUKqPSVhK/+GZOojKROnvvd/496LnmLXjSuteJFyjNW4SQy/fOOaOu3MnSQaOqh7TPY CWxxpNxyTOs1SNUSWK2RRPnGi3IUi/iasYaD7DvBkDLmfwi+WGcPfcHEG54QYkwkxLhd vhuA== X-Gm-Message-State: APjAAAWRE7UGQ/d+NLn0zpKmnvLQbcTiVSmZldc3H/XvlsxLpWbvkQbt ieGaGSktOABnotYVIirFNIk= X-Google-Smtp-Source: APXvYqyihj/qUdW6jjqMbPhLv4wU0+FoD21LTe1QEV8ErVGZTWBS3y+uyBRjL0ph+kriDWeNf+J7Fg== X-Received: by 2002:a63:ed45:: with SMTP id m5mr9859548pgk.265.1552333857958; Mon, 11 Mar 2019 12:50:57 -0700 (PDT) Received: from [172.16.0.3] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id e26sm9392695pfd.124.2019.03.11.12.50.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Mar 2019 12:50:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: <036f01d4cfd9$99b054f0$cd10fed0$@augustcellars.com> Date: Mon, 11 Mar 2019 12:50:56 -0700 Cc: core Content-Transfer-Encoding: quoted-printable Message-Id: <08A40B3A-12C9-494C-8374-9D44D5C8D234@gmail.com> References: <036f01d4cfd9$99b054f0$cd10fed0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Responses to PUB/SUB messages 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, 11 Mar 2019 19:51:00 -0000 What if one combines Dynlink with a pub/sub Broker and creates observe = bindings to topics? Likewise with Dynlinks one could create push = bindings for outgoing notifications. In this case the node that hosts = the pub/sub broker will also be a client due to the Dynlinks. Multicast = would also be possible with a push Dynlink. Best regards, Michael > On Feb 28, 2019, at 6:50 PM, Jim Schaad = wrote: >=20 > I have ended up with an odd ball question about the Pub/Sub system. = For the > purpose of security, a message that goes to the pub/sub server is = marked > with a group identifier and a key identifier. This makes complete = sense. > The question that I have is there any concept of doing a response in = some > manner to something that is on a Pub/Sub server or does that just = become a > new publish? The concept exists for a multicast and the question = exists can > one simulate doing a multicast operation via a Pub/Sub server. >=20 > Jim >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Mar 11 14:10:45 2019 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 42E7D131163; Mon, 11 Mar 2019 14:10:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155233864425.23122.7127463384196652743@ietfa.amsl.com> Date: Mon, 11 Mar 2019 14:10:44 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-resource-directory-20.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: Mon, 11 Mar 2019 21:10:44 -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 : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Christian Amsüss Filename : draft-ietf-core-resource-directory-20.txt Pages : 73 Date : 2019-03-11 Abstract: In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-20 https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 15:25:56 2019 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 8D4851311B0; Mon, 11 Mar 2019 15:25:44 -0700 (PDT) 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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155234314455.23155.18359207618774680663@ietfa.amsl.com> Date: Mon, 11 Mar 2019 15:25:44 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-etch-03.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: Mon, 11 Mar 2019 22:25:45 -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 : FETCH & PATCH with Sensor Measurement Lists (SenML) Authors : Ari Keranen Mojan Mohajer Filename : draft-ietf-core-senml-etch-03.txt Pages : 10 Date : 2019-03-11 Abstract: The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The CoAP iPATCH, PATCH, and FETCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP iPATCH, PATCH, and FETCH methods for resources represented with the SenML data model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-etch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-senml-etch-03 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-etch-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-etch-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 15:40:39 2019 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 22A991228B7 for ; Mon, 11 Mar 2019 15:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 QH4vlQtJ25ij for ; Mon, 11 Mar 2019 15:40:36 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7452124B16 for ; Mon, 11 Mar 2019 15:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x2BMeR0I017366 for ; Mon, 11 Mar 2019 23:40:32 +0100 (CET) Received: from client-0056.vpn.uni-bremen.de (client-0056.vpn.uni-bremen.de [134.102.107.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44JCjl1Qmfz1Bp8; Mon, 11 Mar 2019 23:40:27 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 11 Mar 2019 23:40:25 +0100 X-Mao-Original-Outgoing-Id: 574036824.119817-8f576a02fbedd23f7677cdb560364516 Content-Transfer-Encoding: quoted-printable Message-Id: <3E80442D-9EBF-4973-89E1-7B4A69F42754@tzi.org> References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-se?= =?utf-8?q?nml-etch-03=2Etxt?= 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, 11 Mar 2019 22:40:38 -0000 On Mar 6, 2019, at 00:40, Ari Ker=C3=A4nen = wrote: >=20 > If there are no further comments on these, I could merge the PR and=20 > submit a new version. =E2=80=A6 which the authors did (see below). This starts a working group last call for = draft-ietf-core-senml-etch-03.txt, ending on 24:00 CET on Monday, March 25, 2019. Please start a new email thread for each major issue that will need discussion and make sure the subject line includes the draft name and some sort of name for the issue. (Minor issues such as typos can also be sent to the authors.) If you read the draft and think it looks fine, please send a one line=20 email to the list or to the chairs letting us know that so we can get=20 a feel of how broad the review has been. (To reviewers and authors:) If you are aware of any patent claims that might apply to systems that implement these drafts, please review BCP 78 and BCP 79 and make any appropriate IPR declaration before the last-call ends. If you are not sure whether you need to make a declaration or not,=20= please talk to the chairs and we will help. Gr=C3=BC=C3=9Fe, Carsten >=20 > Cheers, > Ari >=20 > On 20/02/2019 17.00, Carsten Bormann wrote: >> In preparation for the impending working-group last call, I have >> reviewed draft-ietf-core-senml-etch-02.txt. Substantive comments are >> below; a set of small editorial comments is going to the authors in >> parallel. >>=20 >> # Minor >>=20 >> 1. The text of the draft does not contain an argument that the >> application of Patch Packs is idempotent. It probably should. >>=20 >> 2. The text sometimes says "iPATCH" where it probably should be = saying >> "PATCH and iPATCH". This should be checked throughout. >>=20 >> 3. The term "resource" is sometimes used in lieu of "subset of SenML >> records that, when resolved, match a given name". >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >=20 >=20 >=20 From nobody Mon Mar 11 16:39:54 2019 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 F1F70129532; Mon, 11 Mar 2019 16:39:52 -0700 (PDT) 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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155234759297.23155.9162777534268385111@ietfa.amsl.com> Date: Mon, 11 Mar 2019 16:39:52 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-rd-dns-sd-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 23:39:53 -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 : CoRE Resource Directory: DNS-SD mapping Authors : Kerry Lynn Peter van der Stok Michael Koster Christian Amsuess Filename : draft-ietf-core-rd-dns-sd-04.txt Pages : 13 Date : 2019-03-11 Abstract: Resource and service discovery are complementary. Resource discovery provides fine-grained detail about the content of a web server, while service discovery can provide a scalable method to locate servers in large networks. This document defines a method for mapping between CoRE Link Format attributes and DNS-Based Service Discovery records to facilitate the use of either method to locate RESTful service interfaces (APIs) in heterogeneous HTTP/CoAP environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-rd-dns-sd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-rd-dns-sd-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-rd-dns-sd-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-rd-dns-sd-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 16:40:43 2019 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 F17271311E3; Mon, 11 Mar 2019 16:40:37 -0700 (PDT) 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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155234763794.23146.2796855861003415645@ietfa.amsl.com> Date: Mon, 11 Mar 2019 16:40:37 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-coap-pubsub-07.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: Mon, 11 Mar 2019 23:40:42 -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 : Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Authors : Michael Koster Ari Keranen Jaime Jimenez Filename : draft-ietf-core-coap-pubsub-07.txt Pages : 24 Date : 2019-03-11 Abstract: The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe Broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-coap-pubsub-07 https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-pubsub-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 16:59:38 2019 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 52F2E13128D; Mon, 11 Mar 2019 16:59:23 -0700 (PDT) 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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155234876330.23090.13979178016571375166@ietfa.amsl.com> Date: Mon, 11 Mar 2019 16:59:23 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-coap-pubsub-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: Mon, 11 Mar 2019 23:59:29 -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 : Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Authors : Michael Koster Ari Keranen Jaime Jimenez Filename : draft-ietf-core-coap-pubsub-08.txt Pages : 24 Date : 2019-03-11 Abstract: The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe Broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-coap-pubsub-08 https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-pubsub-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 Tue Mar 12 07:30:07 2019 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 B2E57130FF3 for ; Tue, 12 Mar 2019 07:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4b1qhq2659J for ; Tue, 12 Mar 2019 07:30:02 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on070c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::70c]) (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 E3292130FCF for ; Tue, 12 Mar 2019 07:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector1-iotconsultancy-nl; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Aq/MdDgVKwUXDpfyfpLWKtSoc/+eUtZ7G0+5twHWf1o=; b=yM3c5c7S22oZ+ni2HtOhU7v5ps+FX45VAbWKUeNkEmSeAMwjYyzEj5qZiDbJOVUmF83lj6pQRU5A3or7DMJxcWNuSMHwR/g+wT9agxJV8vr4HuCozgTlTwZR6b0zomN2pmGmhVdr9NWxu9CUFjN3xfA+NWHtuRH2BA0VNo7R0/4= Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM (10.172.229.12) by DB6P190MB0039.EURP190.PROD.OUTLOOK.COM (10.172.229.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Tue, 12 Mar 2019 14:29:59 +0000 Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::d0c8:1b24:d4fa:82a1]) by DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::d0c8:1b24:d4fa:82a1%3]) with mapi id 15.20.1686.021; Tue, 12 Mar 2019 14:29:59 +0000 From: Esko Dijk To: "core@ietf.org" Thread-Topic: New Version Notification for draft-dijk-core-groupcomm-bis-00.txt Thread-Index: AQHU14KvVdyaaIrse0OFU4TabvsasaYIDmEQ Date: Tue, 12 Mar 2019 14:29:59 +0000 Message-ID: References: <155225093428.31003.16060682780482812100.idtracker@ietfa.amsl.com> In-Reply-To: <155225093428.31003.16060682780482812100.idtracker@ietfa.amsl.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [2001:1c02:3101:4800:79be:4469:ae6a:1eed] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 400c4b61-a8f5-48bd-a2c8-08d6a6f734c8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DB6P190MB0039; x-ms-traffictypediagnostic: DB6P190MB0039: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(366004)(376002)(346002)(396003)(136003)(199004)(189003)(13464003)(7696005)(476003)(53546011)(6506007)(102836004)(413944005)(966005)(86362001)(446003)(14454004)(33656002)(256004)(99286004)(11346002)(508600001)(46003)(76176011)(66574012)(105586002)(6916009)(53936002)(14444005)(2906002)(106356001)(2351001)(5660300002)(486006)(316002)(74316002)(44832011)(186003)(71200400001)(71190400001)(55016002)(81166006)(97736004)(1730700003)(15650500001)(8936002)(68736007)(25786009)(7736002)(9686003)(6436002)(2501003)(8676002)(5640700003)(6116002)(6306002)(74482002)(305945005)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P190MB0039; H:DB6P190MB0054.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtEQjZQMTkwTUIwMDM5OzIzOjRFdHh5RHZFdnlIVCtiZUh0Q0lKZGhEYWJu?= =?utf-8?B?UTdQU0tpSmpYRGMvYzNXNUovTm1iMFpqdWFHMXBZZXZIZy9LbjlldVV6Zk5z?= =?utf-8?B?SjRISlBIQmlJcUoxZ0RpK0FlK0d1T2R2Q2xGNEhyckVadjZiYjJBVkhEdVo5?= =?utf-8?B?WC9wRE5Qd01SRStPTjhmWGdNdVphamhmT3J0eW1tdDg3aG0za1BiM1l4N0Na?= =?utf-8?B?UTQyczdpeXZ5cFg1KzhJNURGeWlDeUgzWkVOR0FEd0MxSTE5YmhNR2tGVTdB?= =?utf-8?B?ZGhTMjFpZHBhNlM0V1M3cEVkUVVybGFLKzRKRjljWVdIenJNTVQ2Qm55Snc3?= =?utf-8?B?TThkN3JmamNWcWdvOWhwU0FSZXVYY3FpRHhxblUxdC9CbTlDZlFOMGtCOHpo?= =?utf-8?B?RUsrNFBxanpWUGh2M0pHYmU2M21VSi9NcC9uRVNCNVBwTEpWRjlabE5oaXZG?= =?utf-8?B?eTBWVEhtZVdGMGwybDJ6N1RVQThvVGNEdGVBbU9YOEg0cThZL0hYMFVHeEwv?= =?utf-8?B?MFM2WnRuVXZ1NlRpNXRudVdMck4vRVRyUFNOSGIyWDhWUnZ2SDZWV0I0NmU4?= =?utf-8?B?UVlKVXhPL3c4ZmJTQnc0dWJ2Y1N6bDhsWlBiYlBvdkU2MXJ0ZnJ1czRJU05W?= =?utf-8?B?NWJvdmZ6SlA3NVZDL1FnVEh3Snk2NWhCY1ZNVXF1ZTdITGxzNzJ3c0trTjZX?= =?utf-8?B?bFZsQzg4TWJ0M09qRXJPT09wN0k4OExwcVBMMmJzTkxzbnhIMXM4SjZnU3BN?= =?utf-8?B?bWhqOGtUdlY4NWN3V0tGakFkTEZhSmRmNzJ6M0dOdWkra2pMZlR4SFdEa0Fn?= =?utf-8?B?SXpJNW5nUXoxdmlESk9ieVE2ZUJybDhBdTE4OE9yQkpXT3krdWpibTYzamxn?= =?utf-8?B?QnNLVDIzQkFUNVN5MWRPSHB4VFBvUFRrN2o4clpwMms1eEF6R0dLdy9jbFZi?= =?utf-8?B?VTdHbGZ4RFlFMDA4QTk3V0l4Wmpycjk5VVN5ays4ODl0cEF1M2dXYnZUU1hM?= =?utf-8?B?V3BLemszRDFQeWEzd3VRR25qVWJKcEJqbm1tRGxkd3pOckV6cDBFdlVHendL?= =?utf-8?B?c0hZYTY0TGtOUjhZM1ljM2gxaDQrZUFCWFJmendUc2U4ampySkJxUm1UcDZr?= =?utf-8?B?Y1pmWUJpODhWRkhKRkR6WG9PVENTSTl5WExFTGpMdCtmWVN2MHpUeUZVTlNT?= =?utf-8?B?emMwNXJFOEFobzJ5UDNDM21LcENmS3QwZ1NUV0VLWlh0cTAxejBzT2NrSkJJ?= =?utf-8?B?bFdQRjI5cTBSSVU0MDhhTmU3RkVkMzBINWRUUmdFQ3BON0MwdzQvQjRwWWQr?= =?utf-8?B?dmhoZUlBZSt0T2JCeHJWdzVCWmZRUHFGZHd5SXlRSllOWUlJR09CaWxMREZu?= =?utf-8?B?UjFKdnBYeStVNjl6V094cUxlMVBvOUxuZ0Y5aTl0cks0bWR4cmJOZVRFMlpu?= =?utf-8?B?a0p3WjN5WjM1R0VXL0s5Z0V4YWdjREJZbVIrZUhwVEFWK2pzYWdJZlNTRnkr?= =?utf-8?B?L3V5elZiWVRrNlZGZ1FyMHBFK1d4cnV1SUN0OGdvR2RFRHdObGpXcmNwL3c0?= =?utf-8?B?ZC81RGJodEZkMEpxMTVRWTV0bytRTUJ0bDRTdE1YY202bFBybVVBaS96bll3?= =?utf-8?B?UlNHQUwraWc0YVkyUjhGNmdMS2R1SmZsWXlSbW1TNGN5VTVyMlBtSDJRRllx?= =?utf-8?B?aWpYSnNCQzIvSXB3blNKWmJUTCtvcW10OGFuemZ0bkVweEFzME9wbkRCNGhx?= =?utf-8?B?YlQwZ0tKamM1OTUrWnp1c2VHeTFVazAvaml3dGZ2blNvWmtEL2xKVjVNRmRJ?= =?utf-8?B?ZnpCT00zcmJvU0huWmlSQ05OQnNpbEVQaGI4cXdydWtiWUNoN1MyejBuMjFW?= =?utf-8?Q?fdNuqsn+XvI=3D?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: SY+a6r8Im08+hRGkknrWGuO0epT2IE/MJJQnVT+Dux9Kpu853QtC7eKY4B7CwH01BqvNZmpaJtPR+dV1k7Rw32sE71zzr2mgSWapIltOUSAeF7/HAQR78mwMIT6ujLWv5HiLB1cWWCSE6OYWTbzEjusmaFraKaRRVvQOCV1prmo/PJoFNuJId0IV+oqhEwxnK7llxWWbhO0gpQ1+9z3xMf4OkossK7Og7E1ogOd57e8M72uJXZqPhB7bq8E9+lBxl69lfJQaoPLcq+yMRlU8aU9b3U+IIJiIsqXvWcVBqBhxYqXyQvO4psDdK/ru2AMZUCqEmsaVaEjMesbjDmbbz2TrCduDJLcMUmsjOU/w05Oe3Xaw7anFmIs7FUfwpjFI+eAT3AB3k/iJTsbJ6VxnYUe6s1uhIoOv31RwNgl/dJY= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 400c4b61-a8f5-48bd-a2c8-08d6a6f734c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 14:29:59.0979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0039 Archived-At: Subject: [core] New Version Notification for draft-dijk-core-groupcomm-bis-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: Tue, 12 Mar 2019 14:30:06 -0000 RGVhciBDb1JFIFdHLA0KDQpGWUkgYSBuZXcgZHJhZnQgb24gQ29BUCBncm91cCBjb21tdW5pY2F0 aW9uIGhhcyBiZWVuIHN1Ym1pdHRlZCwgaW50ZW5kZWQgYXMgYSBwb3RlbnRpYWwgbm9ybWF0aXZl IHVwZGF0ZSB0byBSRkMgNzM5MC4gSnVzdCBsZXQgbWUgb3IgY28tYXV0aG9ycyBrbm93IGlmIHlv dSBoYXZlIGFueSBmZWVkYmFjayENCg0KQmVzdCByZWdhcmRzDQpFc2tvDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4gDQpTZW50OiBTdW5kYXksIE1hcmNoIDEwLCAyMDE5IDIxOjQ5DQpU bzogTWFyY28gVGlsb2NhIDxtYXJjby50aWxvY2FAcmkuc2U+OyBDaG9uZ2dhbmcgV2FuZyA8Q2hv bmdnYW5nLldhbmdASW50ZXJEaWdpdGFsLmNvbT47IEVza28gRGlqayA8ZXNrby5kaWprQGlvdGNv bnN1bHRhbmN5Lm5sPjsgQ2hvbmdnYW5nIFdhbmcgPGNob25nZ2FuZy53YW5nQGludGVyZGlnaXRh bC5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRpamst Y29yZS1ncm91cGNvbW0tYmlzLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1kaWprLWNvcmUtZ3JvdXBjb21tLWJpcy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgRXNrbyBEaWprIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cg0KTmFtZToJCWRyYWZ0LWRpamstY29yZS1ncm91cGNvbW0tYmlzDQpSZXZpc2lvbjoJMDANClRp dGxlOgkJR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9u IFByb3RvY29sIChDb0FQKQ0KRG9jdW1lbnQgZGF0ZToJMjAxOS0wMy0xMA0KR3JvdXA6CQlJbmRp dmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjANClVSTDogICAgICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZGlqay1jb3JlLWdyb3VwY29tbS1iaXMt MDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZGlqay1jb3JlLWdyb3VwY29tbS1iaXMvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRpamstY29yZS1ncm91cGNvbW0tYmlzLTAwDQpIdG1s aXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1k aWprLWNvcmUtZ3JvdXBjb21tLWJpcw0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBz cGVjaWZpZXMgdGhlIHVzZSBvZiB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24NCiAgIFByb3Rv Y29sIChDb0FQKSBmb3IgZ3JvdXAgY29tbXVuaWNhdGlvbiwgdXNpbmcgVURQL0lQIG11bHRpY2Fz dCBhcw0KICAgdGhlIHVuZGVybHlpbmcgZGF0YSB0cmFuc3BvcnQuICBCb3RoIHVuc2VjdXJlZCBh bmQgc2VjdXJlZCBDb0FQIGdyb3VwDQogICBjb21tdW5pY2F0aW9uIGFyZSBzcGVjaWZpZWQuICBT ZWN1cml0eSBpcyBhY2hpZXZlZCBieSB0aGUgR3JvdXANCiAgIE9iamVjdCBTZWN1cml0eSBmb3Ig Q29uc3RyYWluZWQgUkVTVGZ1bCBFbnZpcm9ubWVudHMgKEdyb3VwIE9TQ09SRSkNCiAgIHByb3Rv Y29sLiAgVGhlIHRhcmdldCBhcHBsaWNhdGlvbiBhcmVhIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBp cyBhbnkNCiAgIGdyb3VwIGNvbW11bmljYXRpb24gdXNlIGNhc2VzIHRoYXQgaW52b2x2ZSByZXNv dXJjZS1jb25zdHJhaW5lZA0KICAgbmV0d29yayBub2Rlcy4gIFRoZSBtb3N0IGNvbW1vbiBvZiBz dWNoIHVzZSBjYXNlcyBhcmUgbGlzdGVkIGluIHRoaXMNCiAgIGRvY3VtZW50Lg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Mar 12 07:40:15 2019 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 CD3D6129AA0 for ; Tue, 12 Mar 2019 07:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=smartthings.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROxNV3CVjTX3 for ; Tue, 12 Mar 2019 07:40:10 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 2ABFE1275F3 for ; Tue, 12 Mar 2019 07:40:10 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id y124so988042pfy.7 for ; Tue, 12 Mar 2019 07:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DqoduwgtWKYRrFr0A+k4nZGW+dkMIj9AS9P6XxSjqTQ=; b=TbJVH13GNhccVMg6GBTbeFX2Y0939QPNzJcGSOmW4PcAf9/XEnd8e+8mh2IjUxiBYw bPPwM7cEE9Hnv41LDI8UKTJX1g0WDjulSAsUQEZm3z2AqU1rioxVAWy+tP/eb+9L2RU3 IiIEMyKQn6MjcEufR9YfduLMet6Y+W7FPyC3Qwnd84jxEgoui1i33Kh3dt87YQIF7aG8 K/Z+nC/QUfRWvAvSqMAsamdIr02kLnjzykUpnrqNOn6BQUAdss2cqfZmt2PSWkWbhjgV 0GCVpMOR4dLWhEzPhahcCEvmP/r0psRPf7bN55Lb93K1Wvmc6i9r+iWUKE7Hv+O58JI0 XsMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DqoduwgtWKYRrFr0A+k4nZGW+dkMIj9AS9P6XxSjqTQ=; b=VXUXZxVDcyWH5l3LP4QemOGoQaT7PukZz5BtjvpYtlTUGGBoc+tANtxJCrLl4vFJhF qJhrqa0Z9fn3JW1WfT5+TJRc5GtMXHb8Hs2XGJ4OKBqhL4MQBhRLTEt4zck5WvFU3j6d z3Uk1XAYfjJZfcR8KFxKz6QLWJk0sQj1jlxd00Tv0D0eDg2sEwQz16tEu644JyXq7YLU orfE93tDN897q87zDj5F/jhQtqnLp+I58s1gL5cMr2GR8NK8QtL9srXPjduI5Rwvp/29 3EcsSIG02coMGgoKgYG/b1f6KH2Z+0aQt93Yj5pQFNpTPo7a66nA/Xow/o5A0549bAt8 0y/w== X-Gm-Message-State: APjAAAUlaS8ZIfwoCbjSdSlgMD8cJGztdieXDRtsskCs43cS6NqlevoZ BlbuGyeYab5QAt2NrDNm5uwYmQ== X-Google-Smtp-Source: APXvYqxf836M4dt7zJxD76tUCxR+Y8TEc93OgstNT6TH0vQSG60NyVOATPkpdCs6YJinsRZosC+P5g== X-Received: by 2002:a63:104e:: with SMTP id 14mr35168403pgq.185.1552401609264; Tue, 12 Mar 2019 07:40:09 -0700 (PDT) Received: from [172.16.0.3] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id r82sm15093555pfa.161.2019.03.12.07.40.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Mar 2019 07:40:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: <011001d4a87a$76f82f40$64e88dc0$@augustcellars.com> Date: Tue, 12 Mar 2019 07:40:04 -0700 Cc: draft-ietf-core-coap-pubsub@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <355D36D4-152C-4EFC-BA5F-41B3727FBA40@smartthings.com> References: <011001d4a87a$76f82f40$64e88dc0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Review of draft-ietf-core-coap-pubsub-06 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, 12 Mar 2019 14:40:13 -0000 Hi Jim, Thanks for the review! You hit a lot of the squishy bits=20 Sorry for the delay in processing.=20 We incorporated some items in the current draft, others we will need to = discussin the WG. > On Jan 9, 2019, at 4:21 PM, Jim Schaad wrote: >=20 > Here is a more detailed review of this document: >=20 > 1. Section 2 - You should update the keywords with text from RFC 8174 Did that >=20 > 2. Section 2 - I am not sure that I would agree that a top = corresponds to a > valid CoAP URI. I believe that this is really a CoAP URI-Path as the = same > topic could appear on different brokers or under different schemes. = The > scheme/URI-host would appear to be the broker and not the topic. This = is > re-enforced by the topic in section 3.4 >=20 Fixed > 3. Section 3.5 - I think that the brokerless in the title should be > capitalized. >=20 Did that > 4. Section 3.5 - I understand the use case for having a broker version = of > this protocol. I am not clear why the brokerless version is useful. = It > might be a good idea to include a description of where this would be = used as > opposed to normal CoAP functionality. >=20 Added some use case notes > 5. Section 4.1 - Should there be a resource type of 'core.ps.topic' = to > distinguish between resources which are supported by the server = directly and > those which are pub/sub topics. This would complete the 'core.ps', > 'core.ps.discover' set of resource types. Specifically I am trying to = map > the different operations to the different resource types. >=20 See below in the discussion on ps and discover. I think tagging all = topics with core.ps may be OK if they support topic creation, otherwise = core.ps.topic may also be needed. > 6. Section 4.1 - The definition of 'ps' implies that topics can be = rooted at > / rather than at /ps. While I don't have a problem with this I think = that > by saying that it 'ps' is optional seems to be slightly odd. It would = make > more sense to me to say that '{ps}' is not optional but can be the > equivalent of '/.' The assumption in this case is that what would be > returned by .w-k/core would be ';rt=3Dcore.ps;ct=3D40' rather than = '<>' as > the refpath. =20 >=20 Yes, that's what we want. We probably misunderstand URI template syntax. = I think we confuse "ps" as a template variable vs. "ps" as a path = segment string. Are there any specific suggestions for how we could reorganize this?=20 > 7. Section 4.1 - I am not completely clear on this. Is DISCOVERY only > supported by rt=3Dcoap.ps.discovery or is it also supported by = rt=3Dcoap.ps? =20 Support for discovery is optional, and indicated by including = rt=3Dcoap.ps.discovery in the link that describes the "ps" resource. If the link for the resource has only coap.ps then it is not expected to = support discovery.=20 The target attributes describe a service entry point. In the case of the = pub/sub service and pub/sub topic discovery, we allow the broker to = provide the functionality at every topic. More on this in the next = comment. > 8. Section 4.1 - Is discovery only permitted to find those resources = which > are subordinate to it for rt=3Dcoap.ps.discovery or can it search all = topics > published in the PS? >=20 The intention is for discovery to list all the topics that are = sub-topics of the resource pointed to by the URI of the discovery = request. We leave it open whether the server recursively descends, but = on further thought we may need to say one way or the other. Maybe just = the topics tagged with core.ps.discovery would be recursively listed = (see next) If you do discovery from the root resource ("ps" for example) you get a = link-format listing of all topics. If you do discovery at some topic, = you get a link-format listing of the subtopics of the target topic. Perhaps we should explicitly require each topic and sub-topic link to = include rt=3Dcore.ps (supports topic creation) and optionally = core.ps.discovery (if the topic supportssub- topic discovery). If a link = has neither, then it points to the content. This is also a way we could = support link-format as content. If there are topics that don't support = sub-topic creation, then we may also need something like core.ps.topic Note all topics are technically sub-topics, at least of the "ps" entry = point resource. > 9. Section 4.1 - Is there a policy of some type about what topics are = and > are not visible under .w-k/core? I was planning to hide all of them = and > only expose them via the /ps resource. This seems to be = contra-indicated by > the example in figure 5 but is similar to what happens in RD. >=20 It is intended to be entirely application-dependent which topics have = links in well-known/core. Usually it would be only the ps entry point = but we didn't want to restrict what may be included in w-k/core or how = it must be organized. > 10. Section 4.2/3 You should think about what happens if I use a = multipart > content for publishing. This would allow for publishing multiple = content > types at the same time which might be an interesting feature. This = allows > for multiple content types w/o the broker having to do the content > conversions. >=20 I think pub/sub will work with multipart content format as long as the = broker can treat the published payloads as opaque. What are some = potential issues? > 11. Section 4.3 - Am I correct in assuming that max-age defaults to 60 > seconds for a publish operation? There is a different default value > specified for CREATE but not here. Another possible default value = would > have been the topic lifetime. >=20 We thought we had a simple solution to lifetime in the last hallway = call, but there are a number of issues. Mostly, Max-Age is for responses = and we should come up with a different way to transmit data lifetime for = push operations. Currently thinking a URI parameter in the query options = would be appropriate, some version of "lt". We also think there is a good case for separate handling of topic = expiration and data expiration. Topic expiration should send 4.04 = responses to observers and readers, and data ageing should be handled = via Max-Age in notifications. We didn't get the design finished before = the draft deadline, also it seems like we should have a WG discussion on = the proposal. I will write up a github issue and we can go from there. > 12. Section 5 - I think you need to re-write the text dealing with con = as > this does not appear to be in the RD any more. >=20 Con as in CON/NON? We do have a bit where we say that a READ or = SUBSCRIBE maybe ack'ed and queued waiting for first publish.=20 From nobody Tue Mar 12 08:00:58 2019 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 8DFA9131063 for ; Tue, 12 Mar 2019 08:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.com header.b=RNTulD/I; dkim=pass (1024-bit key) header.d=ericsson.com header.b=bfMBJM8t Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5TtmaNTIDDw for ; Tue, 12 Mar 2019 08:00:52 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D339131050 for ; Tue, 12 Mar 2019 08:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552402850; x=1554994850; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Yfc3+89KERBWqUb3KzRyVOxFVPoZPxVGvGxZVdvfWqc=; b=RNTulD/IdrS82x6tr7gHfkYxpwVGAaspn3Ez0eu7GaHFDXE4OpaEsRk3PoxClAcR sKOmZM1RgytOBJI3/Hrrl0D5MlZksVmLSlHr1wcTagciVnQX9Tp2UfoWMANmqf9P GAtSk+60yoXTLoMYTskzWwB09qReXCCIL8Mb26rLBjk=; X-AuditID: c1b4fb25-da1ff70000005ff7-6f-5c87c9a21140 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A7.8F.24567.2A9C78C5; Tue, 12 Mar 2019 16:00:50 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 12 Mar 2019 16:00:50 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 12 Mar 2019 16:00:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yfc3+89KERBWqUb3KzRyVOxFVPoZPxVGvGxZVdvfWqc=; b=bfMBJM8tNUWnEZVBchSG0dBXD+IFbi012gKZ6ryUxdwZtWfgk6OSxBBtg+mIkPLXzkidsqlgqaJRQwtIj6noCTLbcyGuQ+vHu9kxlp9MzODWS8NFjg4jDTlTTSurHxu65VCZfAtsVRJaHReyy3ITxvdMjw3ABlxErdemW8IKe6w= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB4361.eurprd07.prod.outlook.com (20.176.167.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.10; Tue, 12 Mar 2019 15:00:48 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8%3]) with mapi id 15.20.1709.011; Tue, 12 Mar 2019 15:00:48 +0000 From: John Mattsson To: Carsten Bormann , core Thread-Topic: [core] And now for something completely different: draft-bormann-core-media-content-type-format-00 Thread-Index: AQHU2DEUKRict0nAM0eJYWqSXU87GqYIKSCA Date: Tue, 12 Mar 2019 15:00:48 +0000 Message-ID: References: <155232527016.23134.15624613562412422263.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0cfd9394-3947-4a5d-3370-08d6a6fb82d4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4361; x-ms-traffictypediagnostic: HE1PR07MB4361: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(39860400002)(376002)(346002)(199004)(189003)(13464003)(8676002)(81166006)(476003)(6506007)(486006)(102836004)(53546011)(82746002)(966005)(68736007)(6306002)(53936002)(6512007)(305945005)(8936002)(7736002)(97736004)(86362001)(110136005)(58126008)(81156014)(66066001)(83716004)(71200400001)(71190400001)(66574012)(6436002)(36756003)(105586002)(106356001)(6116002)(6486002)(6246003)(316002)(44832011)(33656002)(229853002)(446003)(99286004)(76176011)(256004)(25786009)(26005)(5660300002)(11346002)(186003)(2616005)(3846002)(478600001)(2906002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4361; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: StSRR8d5hFXLFNfchJ9irxbjVpZsYwVQdxHwmW7fRNf+SqIWLWHh5/2iEM9wtt/m5ktmciI3+VF3a++NT2w/eJX4ErjTJ1voFlAuVE4ij8RIrmS9FG9S3U4dY/5Z+SVQt1OtK1sEyEqkte7Cu7pOvcGCjzKbywv2pS8zo77ZWSO+PLmHk1r9vLUeutNQS4hy5DCB4PEKZmm8KPfXiokiiOE6nx3AT22SAve0U13z8GDB/YqEtEXcnLmDQm0r5QgkZaZFTkHb/dl+yg3xddtks+tlvDA26MOZ02nPQYVgy4BirVEKpp7tLuwJJ1of6u2Bf26htXTIpOFjATGCwLNkvfOvitVPjsrC2S4lBahNXV2d69PG6trI5SX2mdO4dOonhrDoeBSAomxU6OsBp8pBdei/jhqgE8iI4TGIYOarnfA= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0cfd9394-3947-4a5d-3370-08d6a6fb82d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 15:00:48.0500 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4361 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42KZGbG9UnfRyfYYg73rZSyOTLnLarHv7Xpm ByaPJUt+MnlMW5QZwBTFZZOSmpNZllqkb5fAldGz+wJbwQrhiuu/djM3ML4Q6mLk4JAQMJE4 vCeyi5GTQ0jgCKPE3+nuXYxcQPY3RolZ+3ewQThLmCSeNXeyglSxCExgljg6wQUiMZlJYs7y i1BVDxglDnefYgOpYhMwkJi7pwHMFhGwkLhzehcbyDphgUKJcy8lIcJFEh9XLWeBsI0kZh74 DLVAVeLXtMtgrbwC9hJ9mzczgbQKCdRLTD7ECBLmFLCWuHJqCVg5o4CYxPdTa5hAbGYBcYlb T+aD2RICAhJL9pxnhrBFJV4+/gdWLyqgL7Gl7wELRG+sRGvrdFaIGkWJ0/tWQNXLSlya380I CSBfibbDLCAfSgjcZJR4enYGC0SNlsSS8/PZIGwpiYXnv7BD2NkSK+cdhrpBBmjmTjaI5h+s Es0zJ7JBgjpVYvnaVsYJjHqzkNw9C2gfs4CmxPpd+hBhD4mGPQfZIGxFiSndD9lngUNFUOLk zCcsCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIEJpGDW36r7mC8/MbxEKMAB6MSD+/+ de0xQqyJZcWVuYcYJTiYlUR4LXKAQrwpiZVVqUX58UWlOanFhxilOViUxHn/CAnGCAmkJ5ak ZqemFqQWwWSZODilGhiD/VV7H/xRuWNzlH99zGWniuqMZYbiAtusrzytT90hWaWXP3emcMSq RrOZnr9EBP2lUhz0yiO9dWcdFVLMDJioxMRT/2cRj6RY8bNgdx+xiJJTW/7lOBgcLYw/tidY 7NzkpfMbZ5rqLgizOhq0gz1lu4T05m6JPzrlnZJzVvFGPXvIELD8lhJLcUaioRZzUXEiAKyk TuseAwAA Archived-At: Subject: Re: [core] And now for something completely different: draft-bormann-core-media-content-type-format-00 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, 12 Mar 2019 15:00:56 -0000 SGksDQoNCkkgdGhpbmsgdGhpcyBpcyB3ZWxsIG5lZWRlZCBmb3IgYm90aCBiZWdpbm5lcnMgYW5k IGV4cGVydHMgaW4gdGhlIHN1YmplY3QuIEZvciBub24tZXhwZXJ0cyBzb21lIGNvbmNyZXRlIGV4 YW1wbGVzIGNvdWxkIGJlIGdvb2QuDQoNCkkgc3VwcG9ydCB0aGlzIGRyYWZ0LCBhbmQgSSBwcm9t aXNlIHRvIHN1cHBvcnQgYWxsIGRyYWZ0cyB0aGF0IGFyZSBwcm9tb3RlZCB3aXRoIE1vbnR5IFB5 dGhvbiBxdW90ZXMgOikNCg0KU2hvdWxkDQoNCk1lZGlhLVR5cGUgPSB0eXBlLW5hbWUgIi8iIHN1 YnR5cGUNCg0KYmUNCg0KTWVkaWEtVHlwZSA9IHR5cGUtbmFtZSAiLyIgc3VidHlwZS1uYW1lDQoN Cm9yDQoNCk1lZGlhLVR5cGUgPSB0eXBlICIvIiBzdWJ0eXBlDQoNCj8NCg0KQ2hlZXJzLA0KSm9o bg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUgPGNvcmUtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0K RGF0ZTogTW9uZGF5LCAxMSBNYXJjaCAyMDE5IGF0IDE4OjM3DQpUbzogY29yZSA8Y29yZUBpZXRm Lm9yZz4NClN1YmplY3Q6IFtjb3JlXSBBbmQgbm93IGZvciBzb21ldGhpbmcgY29tcGxldGVseSBk aWZmZXJlbnQ6IGRyYWZ0LWJvcm1hbm4tY29yZS1tZWRpYS1jb250ZW50LXR5cGUtZm9ybWF0LTAw DQoNCklmIHlvdSBuZWVkIGEgYnJlYWsgZnJvbSBidXNpbHkgbWFraW5nIGFuZCByZWFkaW5nIElu dGVybmV0LURyYWZ0czoNCkkgZmluYWxseSBjb3VsZCBub3QgYmVhciBpdCBhbnkgbG9uZ2VyIGFu ZCB3cm90ZSBpdCB1cCA6LSkNCg0KPiBOYW1lOgkJZHJhZnQtYm9ybWFubi1jb3JlLW1lZGlhLWNv bnRlbnQtdHlwZS1mb3JtYXQNCj4gVGl0bGU6CQlPbiBNZWRpYS1UeXBlcywgQ29udGVudC1UeXBl cywgYW5kIHJlbGF0ZWQgdGVybWlub2xvZ3kNCj4gU3RhdHVzOiAgICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9ybWFubi1jb3JlLW1lZGlhLWNvbnRlbnQt dHlwZS1mb3JtYXQvDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYm9ybWFubi1jb3JlLW1lZGlhLWNvbnRlbnQtdHlwZS1mb3JtYXQtMDANCj4gDQo+ IEFic3RyYWN0Og0KPiAgIFRoZXJlIGlzIGEgbG90IG9mIGNvbmZ1c2lvbiBhYm91dCBtZWRpYS10 eXBlcywgY29udGVudC10eXBlcywgYW5kDQo+ICAgcmVsYXRlZCB0ZXJtaW5vbG9neS4NCj4gDQo+ ICAgVGhpcyBtZW1vIGlzIGFuIGF0dGVtcHQgYXQgY2xlYXJpbmcgaXQgdXAuDQoNCk1hdHRoaWFz IEtvdmF0c2NoIGJyb3VnaHQgdGhpcyB1cCByZXBlYXRlZGx5IGF0IHByZXZpb3VzIFdJU0hJIGhh Y2thdGhvbnM7IGFwcGFyZW50bHkgdGhlIGFtb3VudCBvZiBjb21taXR0ZWUgdGltZSBzcGVudCBv biB0aGlzIGNvbmZ1c2lvbiB3YXMgYWxyZWFkeSBjb25zaWRlcmFibGUgYnkgdGhlbi4gIEnigJlt IHN1cmUgaXQgaGFwcGVucyBpbiBvdGhlciBTRE9zLCB0b28uICBNYXliZSB3ZSBjYW4gZ2V0IG1v cmUgZXllcyBvbiB0aGlzIGRvY3VtZW50IGFuZCBhY3R1YWxseSBnZXQgaXQgcHVibGlzaGVkIHNv IHdlIG5ldmVyIGhhdmUgdG8gZGVmaW5lIHRoZXNlIHRlcm1zIGluIG5ldyBSRkNzIGFnYWluLg0K DQpHcsO8w59lLCBDYXJzdGVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg== From nobody Tue Mar 12 11:18:49 2019 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 1FA2A124B91; Tue, 12 Mar 2019 11:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iet8jIzqiOil; Tue, 12 Mar 2019 11:18:45 -0700 (PDT) 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 21742130E8C; Tue, 12 Mar 2019 11:18:45 -0700 (PDT) Received: from Jude (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Mar 2019 11:18:38 -0700 From: Jim Schaad To: 'Michael Koster' CC: , References: <011001d4a87a$76f82f40$64e88dc0$@augustcellars.com> <355D36D4-152C-4EFC-BA5F-41B3727FBA40@smartthings.com> In-Reply-To: <355D36D4-152C-4EFC-BA5F-41B3727FBA40@smartthings.com> Date: Tue, 12 Mar 2019 11:18:36 -0700 Message-ID: <007f01d4d900$03f19b60$0bd4d220$@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: AQI22FekPWtqdaEwE9yMmqLuc7Ht9gKJoxiepS/9/LA= Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: Re: [core] Review of draft-ietf-core-coap-pubsub-06 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, 12 Mar 2019 18:18:48 -0000 Hurrah - there is a new draft (actually apparently two since this review) I have trimmed out items that I am not responding to. That does not mean that all of the other items don't need to be responded to, just that I am not doing it now. > -----Original Message----- > From: Michael Koster > Sent: Tuesday, March 12, 2019 7:40 AM > To: Jim Schaad > Cc: draft-ietf-core-coap-pubsub@ietf.org; core@ietf.org > Subject: Re: Review of draft-ietf-core-coap-pubsub-06 > > Hi Jim, > > Thanks for the review! You hit a lot of the squishy bits > > Sorry for the delay in processing. > > We incorporated some items in the current draft, others we will need to > discussin the WG. > > > On Jan 9, 2019, at 4:21 PM, Jim Schaad wrote: > > > > Here is a more detailed review of this document: > > > > > 6. Section 4.1 - The definition of 'ps' implies that topics can be > > rooted at / rather than at /ps. While I don't have a problem with > > this I think that by saying that it 'ps' is optional seems to be > > slightly odd. It would make more sense to me to say that '{ps}' is > > not optional but can be the equivalent of '/.' The assumption in this > > case is that what would be returned by .w-k/core would be > > ';rt=core.ps;ct=40' rather than '<>' as the refpath. > > > Yes, that's what we want. We probably misunderstand URI template syntax. I > think we confuse "ps" as a template variable vs. "ps" as a path segment > string. > Are there any specific suggestions for how we could reorganize this? I think it was my understanding that was wrong at the time. This matches what is done for RD so it seems to be ok. > > 10. Section 4.2/3 You should think about what happens if I use a > > multipart content for publishing. This would allow for publishing > > multiple content types at the same time which might be an interesting > > feature. This allows for multiple content types w/o the broker having > > to do the content conversions. > > > I think pub/sub will work with multipart content format as long as the broker > can treat the published payloads as opaque. What are some potential issues? I think that this can be done in some type of extension. I was thinking in terms of the publisher using the multipart content format to say: Here are 5 different representations of the same information. The PS broker can say that any of the 5 different representations are available for retrieval. This allows for "content conversions" to be done at the publisher rather than at the broker. However, yes there are going to be cases where this breakup of the multipart must not be done by the PS server. > > 12. Section 5 - I think you need to re-write the text dealing with con > > as this does not appear to be in the RD any more. > > > Con as in CON/NON? We do have a bit where we say that a READ or > SUBSCRIBE maybe ack'ed and queued waiting for first publish. A client which registers pub/sub Topics with an RD MUST use the context relation (con) [I-D.ietf-core-resource-directory] to indicate that the context of the registered links is the pub/sub Broker. This is what I was referring to. Jim > > From nobody Tue Mar 12 13:48:14 2019 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 5DB03131287 for ; Tue, 12 Mar 2019 13:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1t4DVL9lTxZ for ; Tue, 12 Mar 2019 13:48:10 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F851311CB for ; Tue, 12 Mar 2019 13:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x2CKm0EM021075; Tue, 12 Mar 2019 21:48:05 +0100 (CET) Received: from client-0134.vpn.uni-bremen.de (client-0134.vpn.uni-bremen.de [134.102.107.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44Jn9X42lbz1Bp8; Tue, 12 Mar 2019 21:48:00 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 12 Mar 2019 21:47:59 +0100 Cc: core X-Mao-Original-Outgoing-Id: 574116477.338536-276ceaea989b31b06b71f8858d78917b Content-Transfer-Encoding: quoted-printable Message-Id: <185FC6F6-BA2B-4C65-B8AB-5946C9804043@tzi.org> References: <155232527016.23134.15624613562412422263.idtracker@ietfa.amsl.com> To: John Mattsson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] And now for something completely different: draft-bormann-core-media-content-type-format-00 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, 12 Mar 2019 20:48:12 -0000 Hi John, > I think this is well needed for both beginners and experts in the = subject. For non-experts some concrete examples could be good. >=20 > I support this draft, and I promise to support all drafts that are = promoted with Monty Python quotes :) Thank you! > Should >=20 > Media-Type =3D type-name "/" subtype >=20 > be >=20 > Media-Type =3D type-name "/" subtype-name >=20 > or >=20 > Media-Type =3D type "/" subtype >=20 > ? That is one of the many little $64000 questions here. (I wrote the first line above by mistake, but it is a nice demo of one = of the smaller confusions: For use on the web, do we use the character set that can be registered = [RFC6383] or the character set that can be specified in an HTTP header = field [RFC7231].) Because there is little use for a media-type name that cannot be = registered, I think it should be > Media-Type =3D type-name =E2=80=9C/" subtype-name taking the more limited character set of RFC 6383. RFC 7231 among = others interestingly allows =E2=80=9C*=E2=80=9D in those names, but that = is usually used as a wildcard and not as part of a media type name = itself. Gr=C3=BC=C3=9Fe, Carsten RFC 6838: reg-name-chars =3D ALPHA / DIGIT / "!" / "#" / "$" / "&" / "." / =E2=80=9C+=E2=80=9D / "-" / "^" / "_" RFC 7230 =E2=9E=94 7231: tchar =3D "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA delta: reg-name-chars\tchar =3D=20 tchar\reg-name-chars =3D "%" / "'" / "*" / "`" / "|" / "~" From nobody Wed Mar 13 00:59:09 2019 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 313E7130EB1 for ; Wed, 13 Mar 2019 00:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_STAzRQKEIF for ; Wed, 13 Mar 2019 00:59:04 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70051.outbound.protection.outlook.com [40.107.7.51]) (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 73D4212798E for ; Wed, 13 Mar 2019 00:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/78kZ7lemVWgahmThuBXyzJinglRQS7R1uIsHOGgtas=; b=kD14fd1M26aBLEgXUcKSsLXBJUI3u88ZPg/exvIInx/Z4f5bm/VH75y4YC0hPGd1+i4I3oqpisNInP779qze3AMRDmc4TJYYWfW71i4ATtUVy2P2SuruJlUNKWmN9oZWt2lssgHw2j6FaFMP0+dVsL+t+6rKMych5GSvX+wKbmQ= Received: from DB6P189CA0009.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:2e::22) by DB6P189MB0325.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:31::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Wed, 13 Mar 2019 07:59:00 +0000 Received: from HE1EUR02FT024.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::201) by DB6P189CA0009.outlook.office365.com (2603:10a6:6:2e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13 via Frontend Transport; Wed, 13 Mar 2019 07:59:00 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT024.mail.protection.outlook.com (10.152.10.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1643.21 via Frontend Transport; Wed, 13 Mar 2019 07:59:00 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 13 Mar 2019 08:58:52 +0100 To: References: <155232527016.23134.15624613562412422263.idtracker@ietfa.amsl.com> From: Ludwig Seitz Message-ID: <19f4ae72-145e-ed09-b5a7-4d65e0971012@ri.se> Date: Wed, 13 Mar 2019 08:58:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050108020206030108060409" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(39850400004)(136003)(396003)(346002)(2980300002)(189003)(199004)(5660300002)(235185007)(65956001)(186003)(84326002)(69596002)(26005)(5024004)(77096007)(14444005)(76176011)(305945005)(33964004)(53546011)(386003)(65826007)(336012)(7736002)(486006)(126002)(476003)(446003)(11346002)(86362001)(31696002)(2616005)(65806001)(81166006)(81156014)(36756003)(8676002)(16526019)(6916009)(568964002)(478600001)(68736007)(74482002)(8936002)(40036005)(22756006)(44832011)(6116002)(104016004)(3846002)(71190400001)(6246003)(16576012)(31686004)(229853002)(106002)(6666004)(2906002)(106466001)(64126003)(22746008)(356004)(2351001)(5000100001)(16586007)(58126008)(53936002)(316002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P189MB0325; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f92adf95-aad6-452c-74ed-08d6a789c076 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060)(7193020); SRVR:DB6P189MB0325; X-MS-TrafficTypeDiagnostic: DB6P189MB0325: X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09752BC779 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: IlgRAD8X9hq/mP2C7UcGecjcYuxjvs/2zdtWv8lohUuTrXo2jaj6wH7zferc3ki25uaEgtAg7b/i2QiMmMZB7TA/zSFEjH17Af2huQqxRiGTJNYYDhp7IWtKY/HLEZw1Or2Gk0pj8VYJ5xvRhahhCODKQyxgjP3DfxcxR6zUbxRm+DVXpYdb+wkofLd923KnHReEbxp51DuxFzx81KXlXwVVXaTmtgYoTuGGagsHYgK+6IYNgObVupd0XDSO6osl55j1vMvxPjSVl1nngAg1cr/gQHIDfWMcoIMBBK6wcsggHkkrSMfQO+ei/M+SaIhmeEfRDVIdo8bQqkuTw4Aosgt+boCgsmTRE1ApNXRIibBj2e5fj9fBPINN5O4+Z5X1zcqlF+TfpJ/AcKOk9aB/b+cjJoPTdP012puosPMgGtU= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2019 07:59:00.0130 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f92adf95-aad6-452c-74ed-08d6a789c076 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0325 Archived-At: Subject: Re: [core] And now for something completely different: draft-bormann-core-media-content-type-format-00 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, 13 Mar 2019 07:59:08 -0000 --------------ms050108020206030108060409 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/03/2019 16:00, John Mattsson wrote: > Hi, >=20 > I think this is well needed for both beginners and experts in the > subject. For non-experts some concrete examples could be good. > +1 on both points. > I support this draft, and I promise to support all drafts that are > promoted with Monty Python quotes :) +1 for support, but I make no promises based on MP, humor is a very=20 serious matter for us Germans. /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms050108020206030108060409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMxMzA3 NTg0M1owLwYJKoZIhvcNAQkEMSIEICkRB9waqMvrcMuav6byZI2o1mhVRC78mh/h+raAU1qF MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAEtHDTEtZDuzpuovnPuIG5xr9zM5UwI0dtns86zzbvc4K DxJ3cpjBWriR1MCe7D2a626sAN8pXTuf4gnHjSFwwPuXB/+r31LuIG4PcIhQZumVMpRXGEGE 9xr8YnTf+tcZm7G7pegjbhxkj8TEDSKKwUQOECJ6REmr52KKPKVTb2L0ERsPjV89HSZ416HT CFeNlRmG3D6NpUg9lLHqYCLBifLsI9zg6ApJN67IzLmMZn9rC88Av0Ju5HsuLKTPjjv1dUOu Bw67wmCi+dhFzmfPxESFIizquBlcn7hDoQFbNK0b8uqRwEyHMTu9yuWunu0HI7UTe3YkEcGx fr/lvN0B+gAAAAAAAA== --------------ms050108020206030108060409-- From nobody Wed Mar 13 01:14:12 2019 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 CBD61130EA3 for ; Wed, 13 Mar 2019 01:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.com header.b=HuINT2MQ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=etyZkiKh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8RrpeV3bma8 for ; Wed, 13 Mar 2019 01:14:09 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A8B12798E for ; Wed, 13 Mar 2019 01:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552464846; x=1555056846; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pMqdDOyQKUBp0CNS5jvzTnvhLWQCedIb2cIuQsIqVP0=; b=HuINT2MQ3zseu+vwcvO0TonQ5cQR4ex09bHVdyDGAwR/iksIz10x/awC5wGfx/Kt KLg7g+pTKzJVcBolEkXKfZVvblO6+QDArI0difF4ZYk8E03PkTLsKSebXpYZbvj2 iTX7u1XIp/ST9z77vpnWihHlu0bepy9Fjl68YhRSZoc=; X-AuditID: c1b4fb2d-2198b9e00000062f-a2-5c88bbce5255 Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0F.9A.01583.ECBB88C5; Wed, 13 Mar 2019 09:14:06 +0100 (CET) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 13 Mar 2019 09:14:05 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 13 Mar 2019 09:14:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pMqdDOyQKUBp0CNS5jvzTnvhLWQCedIb2cIuQsIqVP0=; b=etyZkiKhyhM7GbPNwrwxuFCJHRiRC2Bn1LLYL42uW7YdmzrrNTcQzlZc/WUvB25o83wDMu4mdIPTcl1SmkUP51a0pJglEzTzdgUGMRAh0bRyoE+6uEVWowgFU1GpQI768b4JtYsHlYUabDSwUui7ccujXvB7KQxi3nJWJvUCzdc= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2090.eurprd07.prod.outlook.com (10.168.36.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.9; Wed, 13 Mar 2019 08:14:04 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::f83b:7f0f:a7df:3c58]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::f83b:7f0f:a7df:3c58%10]) with mapi id 15.20.1730.003; Wed, 13 Mar 2019 08:14:04 +0000 From: Francesca Palombini To: "core@ietf.org" Thread-Topic: Update to external_aad in OSCORE Thread-Index: AQHUuW1b2WMCrH/cjEumiyV7ZFHczqYJh1mA Date: Wed, 13 Mar 2019 08:14:04 +0000 Message-ID: References: <45C7EBE3-E716-4E02-A5A4-075E0B9EE99B@ericsson.com> In-Reply-To: <45C7EBE3-E716-4E02-A5A4-075E0B9EE99B@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: feb25615-0124-4606-c926-08d6a78bdb9d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2090; x-ms-traffictypediagnostic: HE1PR0701MB2090: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09752BC779 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(366004)(376002)(396003)(199004)(189003)(186003)(76176011)(81166006)(68736007)(26005)(66066001)(81156014)(10710500007)(6506007)(53546011)(3846002)(256004)(8676002)(102836004)(6116002)(2906002)(6346003)(14444005)(606006)(82746002)(9326002)(6916009)(6486002)(25786009)(5640700003)(2351001)(229853002)(7110500001)(15650500001)(2420400007)(6436002)(8936002)(7736002)(99286004)(33656002)(71200400001)(71190400001)(486006)(6246003)(6306002)(316002)(54896002)(966005)(236005)(44832011)(6512007)(14454004)(478600001)(106356001)(11346002)(36756003)(105586002)(86362001)(476003)(2616005)(2501003)(53936002)(5660300002)(97736004)(66574012)(1730700003)(83716004)(561944003)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2090; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7vhaboTzo4+yh9+7pvtzIf2/5eE8dv0BukQq0yUiHf2fc9FrKuCkD2xauJm6rc49+XPp0TVoJVXJdRd38nbS1Jln8joefK6OUc5E4u3lHtSK5a/FM7bnRO9NzcYzz9zyy6VQLauFrYIqcfkugXFpUNAwvdVUcqIgL4+qMMpKmOXC9Wc3mxFc7BPa7j/kj7fa7aUxNKkMe/t5eoklxydGdlyKnV38HACA3E2DMwx7wVNkm0x8uJt91aoUphk63Aftlf7ck1tryi9XL/8xpM1barl9zXuufPPbN3dQ4nhUuMyFUmrWp6S+0qUaIHLg62wfAFLrSJY8caAU4ZTF1vw76/H5enpuB9DmiGeEzu+jrMBJ+p5/hktC2ILUJrlI+2FFkEpAa26X/lRoB5D9UXduzV5ePvsAAT1PHb+/oRcLpDw= Content-Type: multipart/alternative; boundary="_000_E90727D8956C4297B86335F98C46DFD3ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: feb25615-0124-4606-c926-08d6a78bdb9d X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2019 08:14:04.4315 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2090 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGe3e363U4ep0bnkyDJoHflkWFWdpfGmEFJURaNuZNJd101yQj aFKSzFLD1LSlJoNAc5MSFc3Kj0rLSrRFuURlS8vPhGoNZ+bdXeB/v+c5z3l5DrwUIW4U+FDp yhxarZRnyEghv+pkmzr0XWdh0vamH/57n84biRgUp9fbecfQKWFUCp2Rnkurww+cFaZ9+zKG skYr0cXm/mKeBo2UIS2iKMC74EaNrxYJKTHuQ/BKYyM48RuB5W434oSeBwUlepIVfFxKwNXn za5YOQ/6ukp5WuS+JqYRPOw9zjKJo2BoclHAsgT7w+PBWcSyFw6FJU05wflh4FioQRxHgHn4 mdPn421QP9dOsizC0eDQFbnej4belSkB29sdx8BMyWnWRtgPfuY3OlcJ7A2j1lpnHDAG/ZP3 BMdS+G75K+DYHxaH3iCO/WC4tsjF8TBYr3MeCdiMYPVFpWsQAq2r424c+4DNsuRiFdy6biM5 9gVTHduTXf5DwvLAfQFXmoYHTQWIa6qAD+Zi1/IWaLg5yS9FwdXrinOsAGtFF1ntvN8TBqqs /Oq1mwkcCMaOcC6yFW4XTbpxHAAFunsujoORrya39Zk6RDUgKUMzTGZqxM4wWp2uYBiVMkxJ 5zxCa1+ou2U5tB01zh7sQZhCMg/RkKEwSSyQ5zJ5mT0IKEImERlj1yxRijzvEq1WJasvZNBM D9pM8WXeIofYM0mMU+U59HmazqLV/6c8yt1Hg5JXxjdNnLHr7UUTkoATbQkVgy0bkmea+yM/ l5uDXrYkHp22Bl6Zs+++k5Dv6CwjswvpwstvZR31iuyPqft4gYcVIUsduu7gPfNHTF6t8VOG 3nOJ7fmV+42v0ViMIfKXIZaOkGo8WlWflAuWYrvvbIntUL62zs9kIK9tlGZ1SWR8Jk2+I4hQ M/J/2gbPlj4DAAA= Archived-At: Subject: Re: [core] Update to external_aad in OSCORE 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, 13 Mar 2019 08:14:11 -0000 --_000_E90727D8956C4297B86335F98C46DFD3ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRvIGZvbGxvdyB1cCBvbiB0aGlzOiB0aGlzIHdhcyBjb25zaWRlcmVkIGFuZCBmaW5h bGx5IHJlamVjdGVkIChpc3N1ZSBoZXJlOiBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9vc2Nv YXAvaXNzdWVzLzI1MyApLCBwcmltYXJpbHkgYmVjYXVzZSB3ZSBkbyBub3QgaGF2ZSBhIHJlYXNv biB0byBtb3RpdmF0ZSBpbmNsdWRpbmcgdGhlIElEIENvbnRleHQgaW4gdGhlIGV4dGVybmFsIGFh ZCBpbiB1bmljYXN0Lg0KDQpUaGUgZGlzY3Vzc2lvbiBpcyBzdGlsbCBnb2luZyBvbiBhYm91dCBn cm91cCBjb21tdW5pY2F0aW9uLg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0KDQpGcm9tOiBGcmFu Y2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4NCkRhdGU6 IFRodXJzZGF5LCAzMSBKYW51YXJ5IDIwMTkgYXQgMTU6MDENClRvOiAiY29yZUBpZXRmLm9yZyIg PGNvcmVAaWV0Zi5vcmc+DQpDYzogImRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkuYXV0 aG9yc0BpZXRmLm9yZyIgPGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkuYXV0aG9yc0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFVwZGF0ZSB0byBleHRlcm5hbF9hYWQgaW4gT1NDT1JFDQpSZXNl bnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86IEfDtnJhbiBTZWxh bmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPiwgSm9obiBNYXR0c3NvbiA8am9obi5t YXR0c3NvbkBlcmljc3Nvbi5jb20+LCBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFs b21iaW5pQGVyaWNzc29uLmNvbT4sIEx1ZHdpZyBTZWl0eiA8bHVkd2lnLnNlaXR6QHJpLnNlPg0K UmVzZW50LURhdGU6IFRodXJzZGF5LCAzMSBKYW51YXJ5IDIwMTkgYXQgMTU6MDANCg0KSGksDQoN CkFmdGVyIHJlY2VpdmluZyBzb21lIHJldmlldyBjb21tZW50cyBmcm9tIEppbSBhYm91dCBHcm91 cCBPU0NPUkUgKCBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2NvcmUva3gz ZVBORzNSYnh0b0ZDOXBabllLZ2djY2V3ICksIGFuZCBmb2xsb3dpbmcgb2ZmLWxpc3QgZGlzY3Vz c2lvbiwgd2UgaGF2ZSBhIHByb3Bvc2FsIHRvIHVwZGF0ZSB0aGUgZXh0ZXJuYWxfYWFkIGluIE9T Q09SRSB0byBhZGQgdGhlIElEIENvbnRleHQuDQoNCk1vcmUgcHJlY2lzZWx5LCB0aGUgZXh0ZXJu YWxfYWFkIHdvdWxkIGJlIG1vZGlmaWVkIGZyb206DQoNCmV4dGVybmFsX2FhZCA9IGJzdHIgLmNi b3IgYWFkX2FycmF5DQoNCmFhZF9hcnJheSA9IFsNCiAgb3Njb3JlX3ZlcnNpb24gOiB1aW50LA0K ICBhbGdvcml0aG1zIDogWyBhbGdfYWVhZCA6IGludCAvIHRzdHIgXSwNCiAgcmVxdWVzdF9raWQg OiBic3RyLA0KICByZXF1ZXN0X3BpdiA6IGJzdHIsDQogIG9wdGlvbnMgOiBic3RyLA0KXQ0KDQp0 bzoNCg0KDQpleHRlcm5hbF9hYWQgPSBic3RyIC5jYm9yIGFhZF9hcnJheQ0KDQoNCg0KYWFkX2Fy cmF5ID0gWw0KDQogIG9zY29yZV92ZXJzaW9uIDogdWludCwNCg0KICBhbGdvcml0aG1zIDogWyBh bGdfYWVhZCA6IGludCAvIHRzdHIgXSwNCg0KICByZXF1ZXN0X2tpZCA6IGJzdHIsDQoNCiAgcmVx dWVzdF9waXYgOiBic3RyLA0KDQogIGtpZF9jb250ZXh0IDogYnN0ciAvIG5pbCwNCg0KICBvcHRp b25zIDogYnN0ciwNCg0KXQ0Kd2hlcmUgdGhlIGtpZF9jb250ZXh0IGlzIHRoZSBJRCBDb250ZXh0 IChvciBuaWwgaWYgbm90IHByZXNlbnQpLg0KDQpXZSBoYXZlIG5vdCBpZGVudGlmaWVkIGFueSBp c3N1ZXMgd2l0aCBJRCBDb250ZXh0IG5vdCBiZWluZyBwYXJ0IG9mIHRoZSBleHRlcm5hbF9hYWQg aW4gT1NDT1JFICh1bmljYXN0KSwgYXMgaXQgaXMgbGlua2VkIHRvIHRoZSBrZXlpbmcgbWF0ZXJp YWwgdmlhIHRoZSBzZWN1cml0eSBjb250ZXh0IGtleSBkZXJpdmF0aW9uLiBIb3dldmVyLCB0aGUg c2FtZSBleHRlcm5hbF9hYWQgc3RydWN0dXJlIGlzIHVzZWQgYm90aCBpbiB1bmljYXN0IGFuZCBn cm91cCBzZXR0aW5ncywgYm90aCBmb3IgQUVBRCBhbmQgZm9yIHNpZ25pbmcuIEFzIGl0IGNvdWxk IGJlIGhlbHBmdWwgdG8gaGF2ZSBJRCBDb250ZXh0IGluIHRoZSBleHRlcm5hbF9hYWQgZm9yIHRo ZSBzaWduYXR1cmUsIHdlIHByb3Bvc2UgdG8gZG8gdGhpcyBjaGFuZ2UgaW4gdW5pY2FzdCBPU0NP UkUgdG8ga2VlcCBPU0NPUkUgYW5kIGdyb3VwIE9TQ09SRSBhbGlnbmVkLg0KDQpUaGlzIGNoYW5n ZSBtZWFucyB0aGF0IHRoZSBJRCBDb250ZXh0ICh3aGljaCBpbiBHcm91cCBPU0NPUkUgY29udGFp bnMgdGhlIGdyb3VwIGlkZW50aWZpZXIpIHdvdWxkIGJlIGludGVncml0eSBwcm90ZWN0ZWQgKGFu ZCBzaWduZWQgaW4gZ3JvdXAgT1NDT1JFKSBpbiBlYWNoIG1lc3NhZ2UsIHJhdGhlciB0aGFuIGp1 c3QgcGFydCBvZiB0aGUga2V5IGRlcml2YXRpb24uDQoNClRoaXMgY2hhbmdlIGRvZXMgbm90IGFk ZCBhbnkgb3ZlcmhlYWQgdG8gdGhlIG1lc3NhZ2UgYXMgZXh0ZXJuYWxfYWFkIGlzIG5vdCBzZW50 LCBhbmQgaXMgYSB2ZXJ5IGxpdHRsZSBtb2RpZmljYXRpb24gaW1wbGVtZW50YXRpb24td2lzZS4g VGhlIGJpZ2dlc3QgY29uc2VxdWVuY2Ugd291bGQgYmUgZHJhZnQtd2lzZSB0byByZS1jcmVhdGUg YW5kIHVwZGF0ZSB0aGUgdGVzdCB2ZWN0b3JzIGluIGFwcGVuZGl4IEMuDQoNCldlIGhhdmUgaGFk IGRpc2N1c3Npb25zIHdpdGggc29tZSBpbXBsZW1lbnRlcnMsIGFuZCB0aGV5IGRvbuKAmXQgc2Vl IGFuIGlzc3VlIHdpdGggdGhpcyBjaGFuZ2UuIElmIGFueWJvZHkgc2VlcyBhIHByb2JsZW0gd2l0 aCBpdCwgcGxlYXNlIGxldCB1cyBrbm93Lg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg== --_000_E90727D8956C4297B86335F98C46DFD3ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <5BB2A390BA31AA41BBF9DB30BE23E208@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmNvZGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRvIGZvbGxvdyB1cCBvbiB0 aGlzOiA8L3NwYW4+DQp0aGlzIHdhcyBjb25zaWRlcmVkIGFuZCBmaW5hbGx5IHJlamVjdGVkIChp c3N1ZSBoZXJlOiA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9vc2NvYXAvaXNz dWVzLzI1MyI+DQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9vc2NvYXAvaXNzdWVzLzI1Mzwv YT4gKSwgcHJpbWFyaWx5IGJlY2F1c2Ugd2UgZG8gbm90IGhhdmUgYSByZWFzb24gdG8gbW90aXZh dGUgaW5jbHVkaW5nIHRoZSBJRCBDb250ZXh0IGluIHRoZSBleHRlcm5hbCBhYWQgaW4gdW5pY2Fz dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRpc2N1c3Npb24gaXMgc3RpbGwgZ29pbmcg b24gYWJvdXQgZ3JvdXAgY29tbXVuaWNhdGlvbi4gPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPGJyPg0KRnJhbmNlc2NhPGJyPg0KPGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5GcmFuY2VzY2EgUGFsb21iaW5pICZsdDtmcmFu Y2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNk YXksIDMxIEphbnVhcnkgMjAxOSBhdCAxNTowMTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7Y29yZUBp ZXRmLm9yZyZxdW90OyAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90 O2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkuYXV0aG9yc0BpZXRmLm9yZyZxdW90OyAm bHQ7ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS5hdXRob3JzQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5VcGRhdGUgdG8gZXh0ZXJuYWxfYWFkIGluIE9TQ09SRTxicj4N CjxiPlJlc2VudC1Gcm9tOiA8L2I+Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+UmVzZW50LVRvOiA8L2I+R8O2cmFuIFNlbGFuZGVyICZsdDtnb3Jhbi5zZWxhbmRlckBlcmlj c3Nvbi5jb20mZ3Q7LCBKb2huIE1hdHRzc29uICZsdDtqb2huLm1hdHRzc29uQGVyaWNzc29uLmNv bSZndDssIEZyYW5jZXNjYSBQYWxvbWJpbmkgJmx0O2ZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nz b24uY29tJmd0OywgTHVkd2lnIFNlaXR6ICZsdDtsdWR3aWcuc2VpdHpAcmkuc2UmZ3Q7PGJyPg0K PGI+UmVzZW50LURhdGU6IDwvYj5UaHVyc2RheSwgMzEgSmFudWFyeSAyMDE5IGF0IDE1OjAwPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWZ0 ZXIgcmVjZWl2aW5nIHNvbWUgcmV2aWV3IGNvbW1lbnRzIGZyb20gSmltIGFib3V0IEdyb3VwIE9T Q09SRSAoDQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Nv cmUva3gzZVBORzNSYnh0b0ZDOXBabllLZ2djY2V3Ij4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvY29yZS9reDNlUE5HM1JieHRvRkM5cFpuWUtnZ2NjZXc8L2E+ICksIGFu ZCBmb2xsb3dpbmcgb2ZmLWxpc3QgZGlzY3Vzc2lvbiwgd2UgaGF2ZSBhIHByb3Bvc2FsIHRvIHVw ZGF0ZSB0aGUgZXh0ZXJuYWxfYWFkIGluIE9TQ09SRSB0byBhZGQgdGhlIElEIENvbnRleHQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Nb3JlIHByZWNpc2VseSwg dGhlIGV4dGVybmFsX2FhZCB3b3VsZCBiZSBtb2RpZmllZCBmcm9tOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDojRjZGOEZBIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyNDI5MkU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBw dDtwYWRkaW5nOjBjbSI+ZXh0ZXJuYWxfYWFkID0gYnN0ciAuY2JvciBhYWRfYXJyYXk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDoj RjZGOEZBIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMyNDI5MkU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6I0Y2RjhGQSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMjQyOTJFO2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowY20iPmFhZF9hcnJheSA9IFs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRjZGOEZBIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyNDI5MkU7Ym9yZGVyOm5v bmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+Jm5ic3A7IG9zY29yZV92ZXJzaW9uIDog dWludCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDojRjZGOEZBIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMyNDI5MkU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtw YWRkaW5nOjBjbSI+Jm5ic3A7IGFsZ29yaXRobXMgOiBbIGFsZ19hZWFkIDogaW50IC8gdHN0ciBd LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOiNGNkY4RkEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6IzI0MjkyRTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp bmc6MGNtIj4mbmJzcDsgcmVxdWVzdF9raWQgOiBic3RyLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNkY4RkEiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzI0MjkyRTti b3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIj4mbmJzcDsgcmVxdWVzdF9w aXYgOiBic3RyLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOiNGNkY4RkEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzI0MjkyRTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEu MHB0O3BhZGRpbmc6MGNtIj4mbmJzcDsgb3B0aW9ucyA6IGJzdHIsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y2RjhGQSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjQy OTJFO2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20iPl0NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+dG86PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6I0Y2 RjhGQSI+PGNvZGU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjojMjQyOTJFO2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzow Y20iPmV4dGVybmFsX2FhZCA9IGJzdHIgLmNib3IgYWFkX2FycmF5PC9zcGFuPjwvY29kZT48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDojRjZGOEZBIj48Y29kZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyNDI5 MkU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+Jm5ic3A7PC9zcGFu PjwvY29kZT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDojRjZGOEZB Ij48Y29kZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMyNDI5MkU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+ YWFkX2FycmF5ID0gWzwvc3Bhbj48L2NvZGU+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 ImJhY2tncm91bmQ6I0Y2RjhGQSI+PGNvZGU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjQyOTJFO2JvcmRlcjpub25lIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowY20iPiZuYnNwOyBvc2NvcmVfdmVyc2lvbiA6IHVpbnQsPC9zcGFuPjwv Y29kZT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDojRjZGOEZBIj48 Y29kZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOiMyNDI5MkU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+Jm5i c3A7IGFsZ29yaXRobXMgOiBbIGFsZ19hZWFkIDogaW50IC8gdHN0ciBdLDwvc3Bhbj48L2NvZGU+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6I0Y2RjhGQSI+PGNvZGU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MjQyOTJFO2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20iPiZuYnNwOyBy ZXF1ZXN0X2tpZCA6IGJzdHIsPC9zcGFuPjwvY29kZT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDojRjZGOEZBIj48Y29kZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyNDI5MkU7Ym9yZGVyOm5vbmUgd2luZG93 dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+Jm5ic3A7IHJlcXVlc3RfcGl2IDogYnN0ciw8L3NwYW4+ PC9jb2RlPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNkY4RkEi Pjxjb2RlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzI0MjkyRTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIj4m bmJzcDsga2lkX2NvbnRleHQgOiBic3RyIC8gbmlsLDwvc3Bhbj48L2NvZGU+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6I0Y2RjhGQSI+PGNvZGU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjQyOTJFO2JvcmRl cjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20iPiZuYnNwOyBvcHRpb25zIDogYnN0 ciw8L3NwYW4+PC9jb2RlPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OiNGNkY4RkEiPjxjb2RlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6IzI0MjkyRTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp bmc6MGNtIj5dPC9zcGFuPjwvY29kZT48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPndoZXJlIHRoZSBraWRfY29udGV4 dCBpcyB0aGUgSUQgQ29udGV4dCAob3IgbmlsIGlmIG5vdCBwcmVzZW50KS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldlIGhhdmUgbm90IGlkZW50aWZpZWQgYW55 IGlzc3VlcyB3aXRoIElEIENvbnRleHQgbm90IGJlaW5nIHBhcnQgb2YgdGhlIGV4dGVybmFsX2Fh ZCBpbiBPU0NPUkUgKHVuaWNhc3QpLCBhcyBpdCBpcyBsaW5rZWQgdG8gdGhlIGtleWluZyBtYXRl cmlhbCB2aWEgdGhlIHNlY3VyaXR5IGNvbnRleHQga2V5IGRlcml2YXRpb24uIEhvd2V2ZXIsIHRo ZSBzYW1lIGV4dGVybmFsX2FhZA0KIHN0cnVjdHVyZSBpcyB1c2VkIGJvdGggaW4gdW5pY2FzdCBh bmQgZ3JvdXAgc2V0dGluZ3MsIGJvdGggZm9yIEFFQUQgYW5kIGZvciBzaWduaW5nLiBBcyBpdCBj b3VsZCBiZSBoZWxwZnVsIHRvIGhhdmUgSUQgQ29udGV4dCBpbiB0aGUgZXh0ZXJuYWxfYWFkIGZv ciB0aGUgc2lnbmF0dXJlLCB3ZSBwcm9wb3NlIHRvIGRvIHRoaXMgY2hhbmdlIGluIHVuaWNhc3Qg T1NDT1JFIHRvIGtlZXAgT1NDT1JFIGFuZCBncm91cCBPU0NPUkUgYWxpZ25lZC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoaXMgY2hhbmdlIG1lYW5zIHRoYXQg dGhlIElEIENvbnRleHQgKHdoaWNoIGluIEdyb3VwIE9TQ09SRSBjb250YWlucyB0aGUgZ3JvdXAg aWRlbnRpZmllcikgd291bGQgYmUgaW50ZWdyaXR5IHByb3RlY3RlZCAoYW5kIHNpZ25lZCBpbiBn cm91cCBPU0NPUkUpIGluIGVhY2ggbWVzc2FnZSwgcmF0aGVyIHRoYW4ganVzdCBwYXJ0IG9mIHRo ZSBrZXkgZGVyaXZhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPlRoaXMgY2hhbmdlIGRvZXMgbm90IGFkZCBhbnkgb3ZlcmhlYWQgdG8gdGhlIG1lc3NhZ2Ug YXMgZXh0ZXJuYWxfYWFkIGlzIG5vdCBzZW50LCBhbmQgaXMgYSB2ZXJ5IGxpdHRsZSBtb2RpZmlj YXRpb24gaW1wbGVtZW50YXRpb24td2lzZS4gVGhlIGJpZ2dlc3QgY29uc2VxdWVuY2Ugd291bGQg YmUgZHJhZnQtd2lzZSB0byByZS1jcmVhdGUgYW5kIHVwZGF0ZQ0KIHRoZSB0ZXN0IHZlY3RvcnMg aW4gYXBwZW5kaXggQy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PldlIGhhdmUgaGFkIGRpc2N1c3Npb25zIHdpdGggc29tZSBpbXBsZW1lbnRlcnMsIGFuZCB0aGV5 IGRvbuKAmXQgc2VlIGFuIGlzc3VlIHdpdGggdGhpcyBjaGFuZ2UuIElmIGFueWJvZHkgc2VlcyBh IHByb2JsZW0gd2l0aCBpdCwgcGxlYXNlIGxldCB1cyBrbm93Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5GcmFuY2Vz Y2E8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E90727D8956C4297B86335F98C46DFD3ericssoncom_-- From nobody Thu Mar 14 03:05:43 2019 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 15DDE129441 for ; Thu, 14 Mar 2019 03:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTdwhq8K5F8u for ; Thu, 14 Mar 2019 03:05:38 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0224.hostedemail.com [216.40.44.224]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F7712958B for ; Thu, 14 Mar 2019 03:05:37 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id E410418224D73 for ; Thu, 14 Mar 2019 10:05:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:subject:reply-to :message-id; s=key; bh=yhcLXJqzjb1y5Qsfud4u5WKedeVFAHAv3BWd3Igef /Y=; b=VJ92Uhgb3s7ClqeuuKq2TF7dVTYCuos04I9qmRlrnI1yck0YZ2NnUpsnx YUrELkLQqgmVIP2L9Z6zMhPH+kDQd87FAMyBJ/29i9lEmucdS2zX3XpnJ3sJZ6Ur LuupLvzFs0+DLmhzVqQRT3L6RbMS6iABi4ro9Ok/JI/ZMfyACg= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :, RULES_HIT:41:72:152:355:379:582:800:960:962:967:969:973:983:988:989:1152:1189:1208:1221:1260:1263:1313:1314:1345:1381:1431:1436:1437:1516:1517:1518:1535:1542:1575:1588:1589:1592:1594:1711:1730:1776:1792:2198:2199:2525:2527:2561:2564:2682:2685:2829:2859:2910:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3352:3586:3622:3740:3742:3865:3866:3867:3868:3870:3871:3872:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4425:4557:4659:5007:6261:6298:6659:6684:7464:8603:9007:9015:9025:9177:9388:10004:10400:10482:10848:11232:11658:11914:12043:12109:12295:12555:12663:12679:12895:12986:13139:13161:13184:13199:13229:13439:13846:13972:14093:14096:14181:14721:19901:19997:21080:21324:21433:21451:21625:21691:21740:21790:30029:30034:30048:30054:30076, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF X-HE-Tag: base49_8825e46aa600a X-Filterd-Recvd-Size: 5231 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf05.hostedemail.com (Postfix) with ESMTPA for ; Thu, 14 Mar 2019 10:05:35 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_c7fe6235127b722cb20f83552fc78dfe" Date: Thu, 14 Mar 2019 03:05:35 -0700 From: Peter van der Stok To: Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: [core] review draft-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, 14 Mar 2019 10:05:41 -0000 --=_c7fe6235127b722cb20f83552fc78dfe Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Dear authors, below a restricted review of draft-ietf-core-sid. The remarks concern clarifications of the registration process. The drawings and tables have no figure numbers; providing numbers helps referencing. Drawing on page 5 and 6 does not view easily; it is wrapped around. Suggestion to break the drawing in two with as breaking point the box. section 7.2 introduce the hierachical composition of the Registries with a diagram as given in section 7.2.1 section 7.2.1 extend the diagram with "Registry name" next to "Entry point", "Size", and "IANA policy". Explain the difference between a "standardized YANG module" and a "standardized YANG module in RFC". bullit 2, range 1000 to 59,999 s/YANG modules/standardized YANG module/ Allocation within this range: . yang file MUST be registered in "Yang module registry" and "YANG module assignment registry"; associated .sid file MUST be registered in "YANG module assignment registry" bullit 4, range 100,000 to 999,999 Allocation within this range: . yang file MUST be registered in "Yang module registry" and "YANG module assignment registry"; associated .sid file MUST be registered in "YANG module assignment registry" section 7.2.2 probably both YANG module, .yang file and .sid files must be registered. Hope this helps. I am looking forward to publication of this draft, to register the sid files we use for the constrained voucher draft. Greetings, Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org --=_c7fe6235127b722cb20f83552fc78dfe Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Dear authors,

below a restricted review of draft-ietf-core-sid= =2E
The remarks concern clarifications of the registration process.
The drawings and tables have no figure numbers; providing numbers = helps referencing.
Drawing on page 5 and 6 does not view easily; it is= wrapped around. Suggestion to break the drawing in two with as breaking po= int the <work in progress> box.

section 7.2
introduce= the hierachical composition of the Registries with a diagram as given in s= ection 7.2.1

section 7.2.1
extend the diagram with "Registr= y name" next to "Entry point", "Size", and "IANA policy".
Explain the = difference between a "standardized YANG module" and a "standardized YANG mo= dule in RFC".

bullit 2, range 1000 to 59,999
s/YANG modules= /standardized YANG module/
Allocation within this range:
. yang f= ile MUST be registered in "Yang module registry" and "YANG module assignmen= t registry"; associated .sid file MUST be registered in "YANG mo= dule assignment registry"

bullit 4, range 100,000 to 999,= 999
Allocation within this range:
. yang file = MUST be registered in "Yang module registry" and "YANG module assignment re= gistry"; associated .sid file MUST be registered in "YANG= module assignment registry"

section 7.2.2

pro= bably both YANG module, .yang file and .sid files must be registered.
=
Hope this helps.

I am looking forward to publication of th= is draft, to register the sid files we use for the constrained voucher draf= t.

Greetings,

Peter
--
= Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl
www: www.vanders= tok.org
tel NL: +31(0)492474673     F: +33(0)= 966015248
--=_c7fe6235127b722cb20f83552fc78dfe-- From nobody Fri Mar 15 06:24:40 2019 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 4CBB413124B; Fri, 15 Mar 2019 06:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GByINxqkxJTm; Fri, 15 Mar 2019 06:24:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C7813124A; Fri, 15 Mar 2019 06:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1066; q=dns/txt; s=iport; t=1552656277; x=1553865877; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=x/pfRlB7shU4Fo6lrLTfZVmHCxwNHeU8fbYRNyCoAfg=; b=ARZ1PxoE6SGDzDPqC0Kco59DqLSql7jqhYCvCyQcG9nJzMlw6vAr5/6t WyKxqs3mFQZk2ha3UZDyPlvBkAAp3F3uhaOO934zN2Jcz9lMdlCE7p3gT 4+/iZJVrHqXMrn3txojwpqFRCcWbDKi+jtEFunQpgJ62tdnFVEsfCZdA1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAC8potc/5tdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGCD4FrJwqZS5gxgXsLAQGBd4J1AoRQIjUIDQE?= =?us-ascii?q?BAwEBCQEDAm0ohUoBAQEEOksEAgEIEQQBAR8QMh0IAgQBEgiFEK0sijaBLwG?= =?us-ascii?q?LMheBQD+BEYMSimIDpEoJApMZIZNQiwWSdQIRFYEoIAE2gVZwFYMnghYXjh5?= =?us-ascii?q?BMY1fgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,482,1544486400"; d="scan'208";a="532585225" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Mar 2019 13:24:36 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2FDOZbb025558 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Mar 2019 13:24:35 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 15 Mar 2019 08:24:35 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 15 Mar 2019 08:24:35 -0500 From: "Rob Wilton (rwilton)" To: Michael Richardson , "cbor@ietf.org" , "core@ietf.org" Thread-Topic: [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 Thread-Index: AQHU0if+rkpVL8iC4E+Vyl/vbXGKcaYMvJmQ Date: Fri, 15 Mar 2019 13:24:35 +0000 Message-ID: <92df97c1457947f09a2de92d740de925@XCH-RCD-007.cisco.com> References: <21467.1551662213@localhost> In-Reply-To: <21467.1551662213@localhost> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.63.23.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 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, 15 Mar 2019 13:24:39 -0000 I think that it would be good if these drafts could somehow progress to com= pletion. I've previously posted comments on the SID draft, but never received any re= sponse. In short, I think that it would be more pragmatic if SIDs are restricted to= the non-negative range of the signed 64 bit integer type. I.e. disallow v= alues from (2^63 through 2^64 - 1). Thanks, Rob=20 -----Original Message----- From: core On Behalf Of Michael Richardson Sent: 04 March 2019 01:17 To: cbor@ietf.org; core@ietf.org Subject: [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 I wonder if these two drafts wouldn't be better off in CBOR WG? draft-ietf-core-sid-05 YANG Schema Item iDentifier (SID) draft-ietf-core-yang-cbor-07 CBOR Encoding of Data Modeled with YANG Well, anything that would allow the SID to progress enough for the registri= es to be created so that they can be used. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Fri Mar 15 08:42:47 2019 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 AAFFC13126B; Fri, 15 Mar 2019 08:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 uum3ZGLBHoyV; Fri, 15 Mar 2019 08:42:40 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AD913126E; Fri, 15 Mar 2019 08:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x2FFgNCc015386; Fri, 15 Mar 2019 16:42:28 +0100 (CET) Received: from [IPv6:2001:638:708:30da:350e:7c7:5611:1727] (unknown [IPv6:2001:638:708:30da:350e:7c7:5611:1727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44LVFW09Txz1Bp8; Fri, 15 Mar 2019 16:42:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <92df97c1457947f09a2de92d740de925@XCH-RCD-007.cisco.com> Date: Fri, 15 Mar 2019 16:42:22 +0100 Cc: Michael Richardson , "cbor@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 574357340.568283-b6ec990e683caf938bd49d9f38306dc1 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21467.1551662213@localhost> <92df97c1457947f09a2de92d740de925@XCH-RCD-007.cisco.com> To: "Rob Wilton (rwilton)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 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, 15 Mar 2019 15:42:45 -0000 On Mar 15, 2019, at 14:24, Rob Wilton (rwilton) = wrote: >=20 > In short, I think that it would be more pragmatic if SIDs are = restricted to the non-negative range of the signed 64 bit integer type. = I.e. disallow values from (2^63 through 2^64 - 1). SIDs are unsigned integers. However, there are still languages that = have a hard time with those. And it helps if all SID deltas fit into a = signed 64-bit integer. So maybe limiting SIDs to the (non-negative) range of signed 64-bit = integers is a restriction that makes sense. https://github.com/core-wg/yang-cbor has three pull requests, but no = issues. (This apparently also happens to be the repo for the SID specification.) Should we put up the issues there? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 15 10:47:44 2019 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 7DCA512958B; Fri, 15 Mar 2019 10:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPk8qtgPEeyl; Fri, 15 Mar 2019 10:47:39 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7CB1277D7; Fri, 15 Mar 2019 10:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1426; q=dns/txt; s=iport; t=1552672058; x=1553881658; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3lPx2Tw2JkEIxFjXbKx22BzIVTdgbmA3dJZP9lO/i00=; b=Jeich92I9yh2amNqQY2uRyo6/f4Fytru9C3XbWzndSKeUrZEcCd+qyd9 028jubZFr6YrAWGrpmGlCOFwWg2Haqt0b0rW26jL5Eh5Rtss2FhxmkgNP h7xzzANcpDFANL/q66Aa6ndRotchrKFgmU2PAaj189CivD/dROralBLHy 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAX5Itc/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgWCBF1AzJ4QLiHuMIi2YMYF7DR+ETQK?= =?us-ascii?q?EcjYHDQEBAwEBCQEDAm0cDIVKAQEBAwEjDwEFQQULCQIOCgICJgICVwYBDAY?= =?us-ascii?q?CAQGDHgGBbQgPj3KbZoEvhDABgRWEawWBCyQBi0mBQD+BOIJrgx4ChGuCVwO?= =?us-ascii?q?kSgmHW4tCBhmLDIhEiwWFdYVfh0mBTgMugVYzGggbFYMnghYXg0uFFIU/PwM?= =?us-ascii?q?wjnsBAQ?= X-IronPort-AV: E=Sophos;i="5.58,482,1544486400"; d="scan'208";a="10709012" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Mar 2019 17:47:35 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x2FHlZKf019804; Fri, 15 Mar 2019 17:47:35 GMT To: Carsten Bormann , draft-ietf-core-sid@ietf.org Cc: Michael Richardson , "cbor@ietf.org" , "core@ietf.org" References: <21467.1551662213@localhost> <92df97c1457947f09a2de92d740de925@XCH-RCD-007.cisco.com> From: Robert Wilton Message-ID: <7809a821-7ea8-f6ff-b5ff-ea8b124f9941@cisco.com> Date: Fri, 15 Mar 2019 17:47:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.135, dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 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, 15 Mar 2019 17:47:43 -0000 On 15/03/2019 15:42, Carsten Bormann wrote: > On Mar 15, 2019, at 14:24, Rob Wilton (rwilton) wrote: >> In short, I think that it would be more pragmatic if SIDs are restricted to the non-negative range of the signed 64 bit integer type. I.e. disallow values from (2^63 through 2^64 - 1). > SIDs are unsigned integers. However, there are still languages that have a hard time with those. I imagine that you may be referring to languages like Java and Python, but in my experience, C and C++ also struggle to safely use unsigned numbers. E.g. https://blog.regehr.org/archives/268 and their similar cases. > And it helps if all SID deltas fit into a signed 64-bit integer. This is really the key one for me. Otherwise, I would guess that many implementations will probably just assume that the delta always fits into a signed 64-bit integer and potentially fail silently in the future when they hit an overflow/underflow condition. > So maybe limiting SIDs to the (non-negative) range of signed 64-bit integers is a restriction that makes sense. > > https://github.com/core-wg/yang-cbor has three pull requests, but no issues. > (This apparently also happens to be the repo for the SID specification.) > > Should we put up the issues there? I've added the author alias.  Hopefully we'll get an answer. Thanks, Rob > > Grüße, Carsten > > . > From nobody Mon Mar 18 07:22:38 2019 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 8C8FB13106C; Mon, 18 Mar 2019 07:22:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: jaime.jimenez@ericsson.com, draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core@ietf.org, alexey.melnikov@isode.com, core-chairs@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155291894956.26208.11219533779741307368.idtracker@ietfa.amsl.com> Date: Mon, 18 Mar 2019 07:22:29 -0700 Archived-At: Subject: [core] Last Call: (Multipart Content-Format for CoAP) to Proposed Standard 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: Mon, 18 Mar 2019 14:22:30 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Multipart Content-Format for CoAP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of zero or more different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Mar 18 08:05:21 2019 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 A1DDE131231; Mon, 18 Mar 2019 08:05:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155292150764.26166.17431619369045337650@ietfa.amsl.com> Date: Mon, 18 Mar 2019 08:05:07 -0700 Archived-At: Subject: [core] IPR Disclosure China Mobile Communications Corporation' s Statement about IPR related to RFC 8132 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: Mon, 18 Mar 2019 15:05:09 -0000 Dear Peter Van der Stok, Carsten Bormann, Anuj Sehgal: An IPR disclosure that pertains to your RFC entitled "PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)" (RFC8132) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3475/). The title of the IPR disclosure is "China Mobile Communications Corporation's Statement about IPR related to RFC 8132" Thank you IETF Secretariat From nobody Tue Mar 19 03:42:53 2019 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 517BF128CE4; Tue, 19 Mar 2019 03:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DB3t0ITqhGD; Tue, 19 Mar 2019 03:42:49 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E57F126C87; Tue, 19 Mar 2019 03:42:46 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id B31C441923; Tue, 19 Mar 2019 11:42:43 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 3A67D36; Tue, 19 Mar 2019 11:42:42 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:bcdd:f8a7:9b70:3719]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C4AAA7A; Tue, 19 Mar 2019 11:42:41 +0100 (CET) Received: (nullmailer pid 24749 invoked by uid 1000); Tue, 19 Mar 2019 10:42:41 -0000 Date: Tue, 19 Mar 2019 11:42:41 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: draft-silverajan-core-coap-protocol-negotiation@ietf.org Cc: core@ietf.org Message-ID: <20190319104240.GF20814@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cQXOx3fnlpmgJsTP" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [core] Status of protocol-negotiation, further development 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, 19 Mar 2019 10:42:52 -0000 --cQXOx3fnlpmgJsTP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Bill and Mert, I haven't heard any news on protocol-negotiation in some time, but think that this is a valuable document to a pending problem of the WG, as well as being relevant to upcoming applications of resource directories. Are you still actively engaged in that document, and/or can I render any assistance in getting this forward? Will you be in Prague next week? Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --cQXOx3fnlpmgJsTP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyQx50ACgkQOY0REtOk veHssg//c2ipaKOaE2mpHJGu/qcw8WDedp2tDr7kFbRln166AooW70BHv0hGyzQK cDt8wTgjsTH5XY4+OLSCOhAmKtjoRXRphpOfD3I42zBLyUcWG8U2K3O6ubfleLJ1 8SFn5Z5R/q6ulm4nvye94YpPp5yVCiqlmxDY4N3SoVIdaIIRm11ysfjytAUslWvl CgfcLq0Ez3RIRs3J73yzQij/EdlI8ucgPuPIEAG/tVgoCAbQOm33h3kslwMSUrI/ AoxWSyZakW787b0eliHMcxEbB3LrKJAx/J0yAQcm9pZyG7tAWOdp1L6kl7oWbuf4 qJM+7MtC4rQmpNJ7jxbXm3Hxcj9pLg8rWaCVbCcZamQ8NGunrCRpVT+rvfhOZNA+ Ph07REBn5o+4tswu7XZa5HAzA8NEUBwRmlrBtyrb2xPo+KOSC8ynrqaglLX1p3Nv 2gLbZlK5wh2ZPTqBOfB9ISZragFBuHPGzTAnKMbzlgovK+ThP+EbtcPbTvj4kyVp fykDP10ueCfiEmyLVt54AWHPZH0+qGNDMyB/cta/NsZY/qnk8gJcnGB+3jPtiQ4T yELSLLze2OVVha68/lCBZzcWwBgeCVUhZtA/l9hM9q6osqC3YyC3jXOXlK0D6uCQ yhYPP1zT+2kP1mSZfhLLBizirIQCeWaZ8ru+tFz/hkcSbZPwQgc= =PZEL -----END PGP SIGNATURE----- --cQXOx3fnlpmgJsTP-- From nobody Wed Mar 20 08:23:47 2019 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 4AFAC130F25; Wed, 20 Mar 2019 08:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVYiSVIpPOPS; Wed, 20 Mar 2019 08:23:36 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860D0129A4B; Wed, 20 Mar 2019 08:23:35 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0D58341923; Wed, 20 Mar 2019 16:23:33 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 55CA036; Wed, 20 Mar 2019 16:23:32 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:9568:5ff3:9971:c700]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1C59D7A; Wed, 20 Mar 2019 16:23:32 +0100 (CET) Received: (nullmailer pid 23454 invoked by uid 1000); Wed, 20 Mar 2019 15:23:31 -0000 Date: Wed, 20 Mar 2019 16:23:31 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: "core@ietf.org WG" , draft-ietf-core-echo-request-tag@ietf.org Message-ID: <20190320152331.GA21541@hephaistos.amsuess.com> References: <963CE8EA-ABAC-488A-8FA6-81431A2E5B06@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <963CE8EA-ABAC-488A-8FA6-81431A2E5B06@tzi.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Chair's review of draft-ietf-core-echo-request-tag-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 15:23:46 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten, hello CoRE WG, we've prepared a -04 version of echo-request-tag that, in the authors' opinion, addresses the concerns raised in the last review. As I've missed the cut-off before IETF104, the draft is not officially available, so any WGLC can only start when it's uploaded next weekend. However, the version that will become -04 is already tagged in our working tree and available at [1]. Best regards Christian [1]: https://core-wg.github.io/echo-request-tag/draft-ietf-core-echo-reques= t-tag-04/draft-ietf-core-echo-request-tag.html --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlySWusACgkQOY0REtOk veEE3RAAo8s7ggBpNHjefU3Hybv0BIU7a9tDSgNSET24IBHG4zMCyV3mYuK054xh g72qdX5tTa9NuE/xe1Ou1KMdicL+bkIBPob10598wECm/GsIC7EO8QRYx1NZyQuC 9rBBTX0/NeWygg5kQveomQgjtqX05DvAe/TeX8E0ja+kBV5aDZy2Juo8Kjj68CY0 rPfb0nYZiRnLJpuwdLy9RGBHWOBQQske3c4VHuF2zthgnrbOB1XFSNGkjiA6rwzC 2x8tpKZKzX4oRgL/BimzJUyEOKpu49UXthoGycdeTuhH8l8yglFF/UtQKzZkSyzk 5QkKf/tjvvlL0GUTTDi101w9F4Yer5i+JnJHu5J21o4D+QGK8w/MopFcIRnacDP/ BY8+RBul1v1QvZY5DF/m2j+NTNhQJgurI7pWTFUf4Y65uOVbYXztKWfAmnTC2nt1 bGMFed7GV3tJ3H61hbPIzKT+du/wD945MLAGsfdraho3Y87esarXmpmEqxjKeZxH UIeP1ltTNbwQTadyItTRKzQED/KwBgvT4zVf4780pvj+csOa+gxiV5jMyUHp31Gc xKCSnK+QqqG2H9FmmxlNLe0Ts9Slu795AOKJ5vBSmMYJTCvg5MEFtmy04pAaPzcS u0li7dw3bXQ33/1R+Y4uJurSPw06BbDz/3HmnvOwLH0d9QbtPZk= =tgF2 -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From nobody Wed Mar 20 08:51:37 2019 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 C4B2212AF80 for ; Wed, 20 Mar 2019 08:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPDHGl7V54Ad for ; Wed, 20 Mar 2019 08:51:15 -0700 (PDT) Received: from smtp.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 E626F12426A for ; Wed, 20 Mar 2019 08:51:14 -0700 (PDT) Received: from [192.168.217.106] (p54A6CE73.dip0.t-ipconnect.de [84.166.206.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44PZCN65NHzybH; Wed, 20 Mar 2019 16:51:12 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann X-Priority: 3 In-Reply-To: <74895874-55F8-4246-8A96-DBF22200EB3B@tzi.org> Date: Wed, 20 Mar 2019 16:51:12 +0100 X-Mao-Original-Outgoing-Id: 574789870.254163-6f7d39e02afa097b327fe33b854bc528 Content-Transfer-Encoding: quoted-printable Message-Id: <04A9EF7E-6449-4E15-9076-1CEA2C3C4D3F@tzi.org> References: <83E7C5E4-CA4B-477E-96ED-0EB840F589AE@tzi.org> <74895874-55F8-4246-8A96-DBF22200EB3B@tzi.org> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Webex meeting details: CoRE Interim Meeting today 2019-03-20 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, 20 Mar 2019 15:51:18 -0000 10 minutes till today=E2=80=99s meeting=E2=80=A6 Webex details for this full interim are the same as usual; copied below Proposed agenda: * Document status We have 27 drafts for 180 minutes of meeting time next week, may need to = do some triage. (And maybe we can dispose of some today.) > Bash now or at the start of the meeting. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >>> Begin forwarded message: >>>=20 >>> From: Carsten Bormann >>> Subject: [core] Webex meeting details: CoRE Hallway and Interim = Meetings before IETF104 >>> Date: January 9, 2019 at 16:01:15 GMT+1 >>> To: "core@ietf.org WG" >>> Archived-At: = >>>=20 >>>> CORE Working Group invites you to join this Webex meeting. >>>> =20 >>>> CoRE Hallway and Interim Meetings >>>> Every 2 weeks on Wednesday, from Wednesday, January 9, 2019, to = Wednesday, March 20, 2019 >>>> 4:00 pm | Greenwich Time (Reykjavik, GMT) | 1 hr >>>> Meeting number (access code): 649 598 697 >>>> Meeting password: constrained >>>>=20 >>>>=20 >>>> =20 >>>> Add to Calendar >>>> When it's time, join the meeting. >>>> =20 >>>> Join by phone >>>> 1-650-479-3208 Call-in toll number (US/Canada) >>>> =20 >>>> Can't join the meeting? >>>> =20 >>>> IMPORTANT NOTICE: Please note that this Webex service allows audio = and other information sent during the session to be recorded, which may = be discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. > >>=20 >> _______________________________________________ >> 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 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 20 13:52:25 2019 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 5D87C1311BF for ; Wed, 20 Mar 2019 13:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MV1hvR52_qDY for ; Wed, 20 Mar 2019 13:52:21 -0700 (PDT) Received: from smtp.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 803851311AA for ; Wed, 20 Mar 2019 13:52:21 -0700 (PDT) Received: from [192.168.217.106] (p54A6CE73.dip0.t-ipconnect.de [84.166.206.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44Phtq2d7JzyfZ; Wed, 20 Mar 2019 21:52:19 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 574807937.115888-938e4f15ddd587a9feb03c41b9669f5a Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 20 Mar 2019 21:52:18 +0100 Message-Id: <541A113C-5FA1-410F-B17F-EC2D194E5079@tzi.org> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] Should we bury draft-ietf-core-interfaces? 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, 20 Mar 2019 20:52:24 -0000 This is one of the oldest drafts still on the roster (created Jan 2012, = adopted Jun 2013.): https://tools.ietf.org/html/draft-ietf-core-interfaces-14 We split off dynlink from that a while ago and now think dynlink will be = completed quite soon (a further split of dynlink was contemplated, but a = clear separation is now done within the single document). The parts of core-interfaces that remain have been picked up e.g. by = OCF, but in a slightly different way. As far as we are aware, the = original core-interfaces version is not implemented. Nor would we = recommend to implement them exactly as specified. The most important face value, defining the if=3D link target attribute, = already is done in Section 3.2 of RFC 6690: = https://tools.ietf.org/html/rfc6690#section-3.2 That registry is in very active use by other SDOs. Core-interfaces intends to add specific values to that registry, but, = again, these are not in actual use. A description of what collections can do maybe can be transferred to the = T2TRG =E2=80=9CRESTful IoT=E2=80=9D draft, or a future, more detailed = companion document of that. At the interim call today we discussed whether core-interfaces, after = already having split out all its salient parts into different documents, = can now be buried. If you agree, please say so in a reply; speak up particularly if you = don=E2=80=99t agree. We probably will make a decision in the Friday IETF104 CoRE meeting, so = please reply till 2019-03-28. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 21 00:47:20 2019 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 5C6F1130F3E for ; Thu, 21 Mar 2019 00:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtbaufJiubuF for ; Thu, 21 Mar 2019 00:47:16 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5028130F39 for ; Thu, 21 Mar 2019 00:47:15 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 54BA941923; Thu, 21 Mar 2019 08:47:13 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1C28336; Thu, 21 Mar 2019 08:47:11 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:9568:5ff3:9971:c700]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 5207B17B; Thu, 21 Mar 2019 08:47:11 +0100 (CET) Received: (nullmailer pid 8381 invoked by uid 1000); Thu, 21 Mar 2019 07:47:10 -0000 Date: Thu, 21 Mar 2019 08:47:10 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Cc: core WG Message-ID: <20190321074710.GB28481@hephaistos.amsuess.com> References: <20190308134459.GA7720@hephaistos.amsuess.com> <162F3D30-6DF8-4A73-A018-94CD511EB2F1@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB" Content-Disposition: inline In-Reply-To: <162F3D30-6DF8-4A73-A018-94CD511EB2F1@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Sketch of "Keep it simple" / "Never reified union types" 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, 21 Mar 2019 07:47:19 -0000 --UHN/qo2QbUvPLonB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Michael and CoRE, On Mon, Mar 11, 2019 at 08:23:23AM -0700, Michael Koster wrote: > In the spirit of handling "empty topic" case in the application layer, > as we discussed, I propose to have the publisher be responsible to > publish "nothing-here-to-see" as a topic's initial value if it has no > initial value in the more meaningful content format.=20 >=20 > (Keeping in mind that, as defined, CoAP pub/sub only handles > representations, and is not strictly a proxy for resource state, > therefore should not be responsible for generating default > representations in any particular content format, except the required > link-format in the case of create-on-publish). >=20 > The pub-sub behavior would be to reply to READ/SUBSCRIBE only when > something has been published. The topic creator is thus responsible to > "promptly" publish nothing-here-to-see upon topic creation. Otherwise > the broker simply acks any READ/SUBSCRIBE request and waits to send a > response until something is published.=20 That would mean that any faulty (or malicious) topic creator could force the broker into (costly-to-maintain in terms of memory) long-poll situations, I'd prefer not to do that. (An alternative would be that the broker answers 5.03 "I'm not in a state to process this request, retry later please" with some Max-Age). My gut feeling is that the broker can be argued to be the authority on the topic (at least formally it is) and would thus be justified to say that "empty" is its current representation, but I'll need to read the latest version of pubsub to argue that well (or be taught better). > This way, the Accept-Any option and the nothing-here-to-see content > formats may be defined in separate independent drafts, and the > multipart format may be used with its potential accept-subformat > options. I agree that Accept-Any can (and probably should) be separate. Kind regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --UHN/qo2QbUvPLonB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyTQXsACgkQOY0REtOk veFLQxAApCTp4YR5EjXjtLPztj+kq/MP72ZbrZe9htN2kdIdcuI+6MKT6RnzSymm o4aktGqSBLIfBF5fzujjeWdLhJbvyrXPMJh+BCb7wW4V7Pjn7XR8UswRdidwFRGj 6Ohek1k5LrPAcy8nUOjzc4T8CV8/1xp+Y8Kdh4ithV1S8IH1RxHgN8zJXP55SECA Vk8D5/lOcsdu9neMJEYKi8Tn0JsCn6CZ7gTSV58RRBuCYWFiBkXrSeGAZW0BsPgJ cpbBNZivj9U1ISfnpMFVsQimB/4dnOZUM/LFN5tWO1h60E/VHLmb7kppq0BBfrS9 YyPoFWGg7HRDafJA115ee0hGcU6qEiV4pTnKIqCU3tBOJ/Yr8xoI1V9QCRKIJHoK ixDESazjik4Xie9iwj58PpsOtgheBiWSMpu8ddQi8tT+LngnrlGhJFtAHC+koIA/ XZJ+AcNzNKlTOtWFE0ilKpSjkavmN+9+8v1ityO+WQcrfXWUazsraiyClSjhJBEF S9z+nMs2DK6eK7yF22SwKXBss1bG+COG2cCQ3kX0PJemo/MPZqCKPwwbRnmS5fzf znciAiMg9Xzv/fkwCMOi4Wk80uML2/zHdKyY0dwI/NeMMN7NN3CNdj2IsDOV3g4W /EXCXJ+bgKKxvURNi7TANhk7UaMayUEIVJIT7HVreKTihC2eKJk= =IiFO -----END PGP SIGNATURE----- --UHN/qo2QbUvPLonB-- From nobody Thu Mar 21 01:47:26 2019 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 E30A81311AD for ; Thu, 21 Mar 2019 01:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNyWnh3cQ6n9 for ; Thu, 21 Mar 2019 01:47:13 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D17B1310E8 for ; Thu, 21 Mar 2019 01:47:13 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id DF33841923 for ; Thu, 21 Mar 2019 09:47:09 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 8788136 for ; Thu, 21 Mar 2019 09:47:08 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:9568:5ff3:9971:c700]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 474F717B for ; Thu, 21 Mar 2019 09:47:08 +0100 (CET) Received: (nullmailer pid 15352 invoked by uid 1000); Thu, 21 Mar 2019 08:47:08 -0000 Date: Thu, 21 Mar 2019 09:47:08 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core WG Message-ID: <20190321084706.GA17128@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [core] Observe updates, and call for proxy implementations (picking from 'Sketch of "Keep it simple"' thread) 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, 21 Mar 2019 08:47:25 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE, during IETF104, I'd like to discuss the possibility of small changes to obsevation, which would mean an update to RFC7641. Topics that have accumulated: * Block1 and Observe. RFC8132 introduces the FETCH method which allows both observation and having a Block1'd request payload, but does not state those's interactions. AFAIR we've worked out how they'd work in practice on this list (roughly "as long as 2.31 is returned, the server won't accept the observation, but will on the last Block1"), but that should be written down at some point. That might be an opportunity to formally allow observation for all operations, provided I assume correctly that limiting Block1 interaction was an important reason to not have POST+Observe. OSCORE worked around this by switching to FETCH for observations. * Pinning of response content formats. The restriction that notifications need to carry the same Content-Format hinders the use of the Accept-Any variety of content negotiation in pubsub. (See proposal and impact ananlys^Wthoughts in quoted part below from the other thread). To me that restriction looks pretty arbitrary (though I see why it sounded good at the outset); I'm looking forward to discussion on its backgrounds. * Pinning of all request options except ETag. This is a similar case as the pinning of response content formats. OSCORE worked its way around this by claiming that the inner options are the relevant ones, even though a proxy would have a hard time to know that. ("For OSCORE messages, this matching is to be done to the options in the decrypted message"). It was argued that a proxy can't really "be mad at" the client for doing it, for the client may simply have forgotten that the old observation was there, and is just requesting a new one with a most innocent look on its face. My impression is that this can be a light update, especially if the Block1/Observe part stays in there as "From the previous documents, it (kind of implicitly but we better spell it out here) follows that". That discussion would profit a lot from knowning which proxies are out there and how they behave with respect to the open points; I'll start: * aiocoap: The proxy implementation shipped with the library is lenient w/rt pinning. Block1+Observe is implemented as above (but not covered by the test suite yet). Best regards Christian Proposal from [1]: > Update to RFC7641 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The requirement that subsequent notifications carry the same > Content-Format option as the original response is lifted. >=20 > Impact > ------ >=20 > Changes to the returned media type can either happen when >=20 > * Accept-Any-Of was sent in the request -- in which case both server and > client know the updated rules, or > * no Accept header was sent -- in which case the server whose > representation changes to require a new content format has no clear > way of indicating that under RFC7641 (ending with 4.06 Not Acceptable > would be close but isn't the expected response to a repeated request); > if the server changes the content format in a notification to an > unaware client, the client would catch it as a bad response (probably > similar to a response with a Content-Format not matching the sent > Accept). The client might consider the observation over while the > server does not, and will terminate the observation with a RST on the > next notification (or close the connection in TCP). >=20 > Impact on proxies: A proxy that enforces the previous rule on > Content-Format staying constant would close observations (probably with > something like 5.02 Bad Gateway), and the client would need to > re-establish. No proxy implementations are known that implement that > behavior. [ But I know only one so this would definitely need to be > confirmed on the mailing list ]. >=20 > [ I don't think that this has any actual interactions with the caching > model, as the caching considerations are independent of the content > format. ] [1]: https://mailarchive.ietf.org/arch/msg/core/81SjKzfMJtSx6x8sc2P_RNq-M30 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyTT4EACgkQOY0REtOk veHLnhAAqytxV3em96UdBsN+1KKhRix4ZWIQz6TwObbCmgm6ZoUw272d/esJcTPn AH2Aj2Pfa4EqiPYBUh5+Ap+LVP5+OwaFEPBrHfFYZk/wqyvylT+ZwMIwDhfeYw8K qTaI53RhrLdK/dZzFnQGBvRa9rfnzZJk4Zp18FiOcVsoyy/4RW5IN1UYQh0AXm3u yeb4SIRUIZtk8qNVlY+bz9mrzJvOc+SLx446IvZjyC+C8hGF1uD/eekcRlL92dzQ kFtUDQi4/FG7QxNceffozxj1fMUbdhnJ8kkUbZDx/to+jckT8IEOT35WOSFHpC3b aGeRJ9fnWqflWKu9vEvYfF1y7jG5oqU9FrTyBezihuPdPtTwYQZ1MLVrKw7Pj9yw K8ZJLrSiStmsUM4z18FTrsmzu7e47AunRRuRtITsDhchmfdmEduJZNVceKdBeUbl IH+wjBoQnrxgO31Fc/JFL+qWMtrqD+xjBZndhCGx1piwn62uE8viK+pqeOcPFF2R IUI1+g1ZS6VaxNjm+QKTJCe5jWhyTCMaKHPe2gk/4pL+/TUFxexfWfUaQKBbrIy+ nYrCWHdooizSPO0RSTxtIDdAgEnmGKZO4uHfPhBwJxxmo0rvrlBBkGta2oaEyz0H Sp70mr8MlYpAgZj/CV1CdccidDJ4QHwuaMCqPYAIuS13XaNx2Ec= =pQfn -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From nobody Thu Mar 21 02:07:21 2019 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 4646E1277CE; Thu, 21 Mar 2019 02:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJtnk6-tjLM0; Thu, 21 Mar 2019 02:07:17 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE09B126C01; Thu, 21 Mar 2019 02:07:17 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 091FF41923; Thu, 21 Mar 2019 10:07:15 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5702936; Thu, 21 Mar 2019 10:07:14 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:9568:5ff3:9971:c700]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1723817B; Thu, 21 Mar 2019 10:07:14 +0100 (CET) Received: (nullmailer pid 17586 invoked by uid 1000); Thu, 21 Mar 2019 09:07:13 -0000 Date: Thu, 21 Mar 2019 10:07:13 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: core , draft-ietf-core-senml-etch@ietf.org Message-ID: <20190321090713.GC28481@hephaistos.amsuess.com> References: <541A113C-5FA1-410F-B17F-EC2D194E5079@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sHrvAb52M6C8blB9" Content-Disposition: inline In-Reply-To: <541A113C-5FA1-410F-B17F-EC2D194E5079@tzi.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Should we bury draft-ietf-core-interfaces? 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, 21 Mar 2019 09:07:20 -0000 --sHrvAb52M6C8blB9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten, hello CoRE, On Wed, Mar 20, 2019 at 09:52:18PM +0100, Carsten Bormann wrote: > At the interim call today we discussed whether core-interfaces, after alr= eady having split out all its salient parts into different documents, can n= ow be buried. >=20 > If you agree, please say so in a reply; speak up particularly if you don= =E2=80=99t agree. > We probably will make a decision in the Friday IETF104 CoRE meeting, so p= lease reply till 2019-03-28. I see some use of core-interface terminology in senml-etch. It isn't made explicit, but the use case description talks of batches of sensor data, and updates several resources at once. Without the background of core-interface batches, I think it's not immediately obvious how such a PATCH is used, and in particular at which resource it is targeted. (That can be addressed in senml-etch though, and doesn't need to keep core-interfaces around). On the procedural side, core-interfaces is part of the WG charter, so abandoning this draft may need more than just WG consensus. (Personally, I'll miss core-interfaces, as it shaped my introduction to CoAP, but let that be motivation to have a good t2trg-rest-iot document.) Best regards Christian --=20 The tortoise lays on its back, its belly baking in the hot sun, beating its legs trying to turn itself over, but it can=E2=80=99t, not without your help. But you=E2=80=99re not helping. Why is that? -- Holden, Blade Runner --sHrvAb52M6C8blB9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyTVEEACgkQOY0REtOk veHz7g/9G9xh0paV715KTZylKJDMaj8bXPGg80LU4WQIafRiolUBs3juPvC411J0 yFvvrrHFufGGifqTEtVpMmQMDGULvJjLb6T7+YDOMFua4ZqinsZTHebjyEMw997f ffmWe5spMVXo7NVlruoekHgJ29dnra7zWhg7rq0xTg/oKO6WpsstUJTKbrNPF1fU 5mJGsNqCEHqEyD72BMhCslzlrJVyip7UI1DV3JMpalGeICfYa4qQeIevi/CMNfOB kCC+MgwCVsO8+XYjALzvZA0r3cQZSyMj2HoUNqJc3Ye5faF77Ws6eSRcjyHEEw/C tCoeOBA5f4qSeNzElchlDDjsK8pGE/zbN/0kedypQnupHzIz2n8oiM0bBUrTWnM0 RWtSOjHJxkFCIh/vTAefbduLByWlqV/fAJW5MLS43e1PIkM92it4cJtZXbxas7xA IlwWcsgmJgPKOC/kdg0g/J0qm1tFE26xtETbViFgXXXFFyFySnR1+PEXYR9CmEMv 1WGPVZ0TWAN35WVDSGByDMhfEG/LFq4tk5bkX2iTiT5tZTV4Zf0PRyJ/A86kXYI7 DwQgkOwyUHlTfwhRD/p4peUdXjFYEkkRPciRD3SuJ4pCScSQOQKlhPUhKRdvv7HX qzq7HE03qtbNjYd+G/7w9Oyl+JEtYX0yE5W8LbyYV/j+oM2pCXA= =2mCO -----END PGP SIGNATURE----- --sHrvAb52M6C8blB9-- From nobody Thu Mar 21 03:22:33 2019 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 C677B130F5B; Thu, 21 Mar 2019 03:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 7eiEXBypqr7n; Thu, 21 Mar 2019 03:22:29 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A461130DE4; Thu, 21 Mar 2019 03:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x2LAMJ5G000788; Thu, 21 Mar 2019 11:22:24 +0100 (CET) Received: from [100.68.224.189] (ip-109-41-65-253.web.vodafone.de [109.41.65.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44Q2sR1lnyz1Br6; Thu, 21 Mar 2019 11:22:19 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-EB030125-EA69-47BF-BCCC-84BFBEEC5C64 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (16D57) In-Reply-To: <20190321090713.GC28481@hephaistos.amsuess.com> Date: Thu, 21 Mar 2019 11:22:18 +0100 Cc: core , draft-ietf-core-senml-etch@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <617D6214-5CB0-4BB9-899A-16F76442D33F@tzi.org> References: <541A113C-5FA1-410F-B17F-EC2D194E5079@tzi.org> <20190321090713.GC28481@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= Archived-At: Subject: Re: [core] Should we bury draft-ietf-core-interfaces? 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, 21 Mar 2019 10:22:32 -0000 --Apple-Mail-EB030125-EA69-47BF-BCCC-84BFBEEC5C64 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think we can check the procedural side (and the editorial implications on o= ther drafts) once we know what we want. Sent from mobile on the way to Prague > On 21. Mar 2019, at 10:07, Christian Ams=C3=BCss w= rote: >=20 > Hello Carsten, hello CoRE, >=20 >> On Wed, Mar 20, 2019 at 09:52:18PM +0100, Carsten Bormann wrote: >> At the interim call today we discussed whether core-interfaces, after alr= eady having split out all its salient parts into different documents, can no= w be buried. >>=20 >> If you agree, please say so in a reply; speak up particularly if you don=E2= =80=99t agree. >> We probably will make a decision in the Friday IETF104 CoRE meeting, so p= lease reply till 2019-03-28. >=20 > I see some use of core-interface terminology in senml-etch. It isn't > made explicit, but the use case description talks of batches of sensor > data, and updates several resources at once. Without the background of > core-interface batches, I think it's not immediately obvious how such a > PATCH is used, and in particular at which resource it is targeted. > (That can be addressed in senml-etch though, and doesn't need to keep > core-interfaces around). >=20 > On the procedural side, core-interfaces is part of the WG charter, so > abandoning this draft may need more than just WG consensus. >=20 > (Personally, I'll miss core-interfaces, as it shaped my introduction to > CoAP, but let that be motivation to have a good t2trg-rest-iot > document.) >=20 > Best regards > Christian >=20 > --=20 > The tortoise lays on its back, its belly baking in the hot sun, beating > its legs trying to turn itself over, but it can=E2=80=99t, not without you= r > help. But you=E2=80=99re not helping. Why is that? > -- Holden, Blade Runner --Apple-Mail-EB030125-EA69-47BF-BCCC-84BFBEEC5C64 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think we can check the procedural side (a= nd the editorial implications on other drafts) once we know what we want.
Sent from mobile= on the way to Prague

On 21. Mar 2019, at 1= 0:07, Christian Ams=C3=BCss <chr= istian@amsuess.com> wrote:

Hello Carsten, hello CoRE,

On Wed, Mar 20, 2019 at 09:52:18PM +0100, Carsten Bormann wrote:<= br>
At the interim call today we discussed wh= ether core-interfaces, after already having split out all its salient parts i= nto different documents, can now be buried.

If you agree, please say so in a reply; speak up particularly if you don=E2= =80=99t agree.
We pro= bably will make a decision in the Friday IETF104 CoRE meeting, so please rep= ly till 2019-03-28.

I see some= use of core-interface terminology in senml-etch. It isn't
m= ade explicit, but the use case description talks of batches of sensor=
data, and updates several resources at once. Without the backgroun= d of
core-interface batches, I think it's not immediately ob= vious how such a
PATCH is used, and in particular at which r= esource it is targeted.
(That can be addressed in senml-etch= though, and doesn't need to keep
core-interfaces around).

On the procedural side, core-interfaces is p= art of the WG charter, so
abandoning this draft may need mor= e than just WG consensus.

(Personally, I'll= miss core-interfaces, as it shaped my introduction to
CoAP,= but let that be motivation to have a good t2trg-rest-iot
do= cument.)

Best regards
Chris= tian

--
The tortoise lays o= n its back, its belly baking in the hot sun, beating
its leg= s trying to turn itself over, but it can=E2=80=99t, not without your<= br>help. But you=E2=80=99re not helping. Why is that?
=  -- Holden, Blade Runner
= --Apple-Mail-EB030125-EA69-47BF-BCCC-84BFBEEC5C64-- From nobody Thu Mar 21 03:25:54 2019 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 EC047130F5B for ; Thu, 21 Mar 2019 03:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmDRyLhZR1gK for ; Thu, 21 Mar 2019 03:25:50 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41932130F35 for ; Thu, 21 Mar 2019 03:25:50 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 769C341923 for ; Thu, 21 Mar 2019 11:25:47 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 89D9836 for ; Thu, 21 Mar 2019 11:25:46 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:9568:5ff3:9971:c700]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 4822317B for ; Thu, 21 Mar 2019 11:25:46 +0100 (CET) Received: (nullmailer pid 28351 invoked by uid 1000); Thu, 21 Mar 2019 10:25:45 -0000 Date: Thu, 21 Mar 2019 11:25:45 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: <20190321102544.GA17235@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [core] CoRE Resource Directory interop during IETF104 hackathon 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, 21 Mar 2019 10:25:53 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE, I'd like to use the hackathon[1] to run implementations of CoRE RD against each other based on the version currently in working group last call. Please contact me by mail or at the WISHI table during the interop. I'll only arrive on Saturday around 11:30 and be briefly absent around 1400-1500 for good reasons[3]. While I'm there, I'll run both a local and a globally reachable RD server, and keep clients (both RIOT-OS and aiocoap based) running to be registered at these and other RD servers. This interop will not follow a strict test case sequence but rather see what works to accomodate work-in-progress implementations and experimentation. Best regards Christian [1]: https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon [2]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-20 [3]: https://mailarchive.ietf.org/arch/msg/104attendees/x7Q6wJL3fTpruklzbAf= zuPqFRKI --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --/04w6evG8XlLl3ft Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyTZqQACgkQOY0REtOk veGqUBAAiypwSnLvIWFZXp/p2oAU41brCtRQoqFYZOcB+DgVQrjW+3AAgAB0A8uc s4QjiWG0RsFpG9++138HQcDdbbQOQnze6GH3ZKq7ozjpERJgUssGeq88fABt9Jp9 DE6QmiHXz2KewLvuE6Cp1VC/0/w8CHfPdiSkV9V/lYHEXTNpkPwI8HXBWMOZCXav btodkB10MwqnXS9mCAJD2SoyzdHlFMANXNahbEfBACuLun9TtMHgZC5kbktTqc9T SsFvTDMAxcZXM/9jU4hs6rfNprzT6jfw0/w+8J9CyQ/jZ686js8SFvEoAZgHVmgw 3Eufa+BAbYW+oVciTYJggYov6NLrWlt/JaGkcZH25kywwCRMDdR+52deqpjnOlSV LIXPbI1KR4N1cbhMm2yzmuzi2mRMm8/5gmhyG7r6zkPOTZC7PQnDBUmQ14HFdOCF ZVMWGOJ/AZ0ym9eKblllGruKCn8WsMD/uGDeokjgVHWctFdos5fPBNZbncGDOUhy rynvf4x9HUZOCPjWWFtXKCyiBZkfNwV70Im/Dt2Ht2ZfOPe67wr2Z3OE+5lUfRlq +A8sFCfIRGtSAQcvuSXHwyFi2mMhPj/get86BgI38OIIbclt4E90alrMn6zpZkfv pz/e7IDW6GDXPVos4+i9tfhGR/DqKUZ0ryRExy54T9cnVJQi+Z0= =Pv8F -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From nobody Thu Mar 21 08:15:21 2019 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 A03AE1310E6; Wed, 20 Mar 2019 08:49:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , jaime.jimenez@ericsson.com, core-chairs@ietf.org, Carsten Bormann , core@ietf.org, alexey.melnikov@isode.com, cabo@tzi.org, draft-ietf-core-object-security@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155309694264.14868.3339363338496295456.idtracker@ietfa.amsl.com> Date: Wed, 20 Mar 2019 08:49:02 -0700 Archived-At: X-Mailman-Approved-At: Thu, 21 Mar 2019 08:15:20 -0700 Subject: [core] Protocol Action: 'Object Security for Constrained RESTful Environments (OSCORE)' to Proposed Standard (draft-ietf-core-object-security-16.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, 20 Mar 2019 15:49:11 -0000 The IESG has approved the following document: - 'Object Security for Constrained RESTful Environments (OSCORE)' (draft-ietf-core-object-security-16.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ Technical Summary This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Working Group Summary The document has gone through multiple expert reviews and has been discussed in multiple IETF meetings. Before the last IETF the WGLC was completed. Document Quality There are 4 existing implementations of the protocol and one more is being worked on. Personnel Carsten Bormann is the document shepherd. Alexey Melnikov is the Responsible AD. From nobody Thu Mar 21 08:31:46 2019 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 30DE51312D3 for ; Thu, 21 Mar 2019 08:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=dP8PHfH8; dkim=pass (1024-bit key) header.d=ericsson.com header.b=M8rj7g3V Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljw_IQz6OmCj for ; Thu, 21 Mar 2019 08:31:37 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC771312D5 for ; Thu, 21 Mar 2019 08:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1553182293; x=1555774293; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3xFAZeJq+YO/zw+tAQIbDIDt5ERhOwQP2aL2V6nS1+w=; b=dP8PHfH8wCcSoaMMiI1113lA+eAz/Evw1edlAQ6MUuVk2b8CpAEutgvQdBJXbbX6 5mbN9uocfalZBKCnuB/8vc5ss9K70jNcXOGIYamaJPsyWF4TJlBN11l9A43bED1W +s78dHhuree9LwpVM1M6uOUIBFY8Q3U3ZTl2jYHbOE4=; X-AuditID: c1b4fb3a-491169e000001645-dc-5c93ae55f6f8 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3C.B8.05701.55EA39C5; Thu, 21 Mar 2019 16:31:33 +0100 (CET) Received: from ESESBMR506.ericsson.se (153.88.183.202) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 21 Mar 2019 16:31:21 +0100 Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMR506.ericsson.se (153.88.183.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 21 Mar 2019 16:31:21 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Thu, 21 Mar 2019 16:31:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3xFAZeJq+YO/zw+tAQIbDIDt5ERhOwQP2aL2V6nS1+w=; b=M8rj7g3VKLV/S4fem0KaglJ2828GNrQXRb2DMonis1U9q04wptx+eCcLW4/IT4VUevzGnMWFwzduTESrCW47r64aYm7jWDyfmMoQrakY4E3I/N5HWMlPJRGitEwA7C4IUoKu3weSx7n2fKMZsdrFtJkPG+fCgULNb+yu4hyAVnE= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2826.eurprd07.prod.outlook.com (10.168.92.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.13; Thu, 21 Mar 2019 15:31:20 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d%6]) with mapi id 15.20.1730.013; Thu, 21 Mar 2019 15:31:20 +0000 From: Francesca Palombini To: "core@ietf.org" CC: Ace Wg Thread-Topic: Pub Sub and multicast Thread-Index: AQHU3/siSpHHSsIZz0arCk9g1aR/4g== Date: Thu, 21 Mar 2019 15:31:20 +0000 Message-ID: <1CA68BFD-B585-4CB0-9303-7E2A6FC2B005@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 78921f4a-0157-4c89-6af3-08d6ae1244ac x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2826; x-ms-traffictypediagnostic: HE1PR0701MB2826: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0983EAD6B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(396003)(136003)(366004)(346002)(199004)(189003)(53754006)(236005)(6306002)(33656002)(4326008)(606006)(450100002)(966005)(53936002)(97736004)(54896002)(6512007)(5640700003)(316002)(36756003)(478600001)(66066001)(5660300002)(2351001)(7736002)(105586002)(106356001)(14454004)(68736007)(1730700003)(486006)(2501003)(8936002)(25786009)(6436002)(99286004)(86362001)(186003)(26005)(83716004)(6486002)(81166006)(82746002)(14444005)(6346003)(81156014)(8676002)(256004)(71190400001)(2616005)(3480700005)(476003)(102836004)(6506007)(6116002)(6916009)(3846002)(71200400001)(2906002)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2826; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: v15X7Ku8bUE53TYyBLhB0fKqp2KRwDtoyXOGsN1niARYVazP1k4Fay6psrpkUllIlOcxCjziJBqi6E9uYP15ka4iyxlgTESNfNRGiVA08VfXvcnGQgUubN7XS6cSlkdUW7Y4Ya6ORSgzWuz6u1BjkJ3eYpW7/OAT5N4fokbi36pauEDZqmIJWkkgmTRc0yFdD26V0o0hx99SGrzNNocj//omDejxH7sH0bUWBTiJooH4dCzKz44va52hA+sXmjypsZ9w0e+uaFmVZ2KXFwBG+i/ZN+NT7s7XEXRIh9x7gDz9LrefAXGbNi7pj7Rtk08fXTaJu8uN7KGhApK1TYNgopPwXjqGXx3xBwdkOmCmP4QxuXPomKWtFfOYCjX70GBrtqiQagDGHtzrrS6oMC2bQpHL1OI0WvK6vaXEsjwXlt4= Content-Type: multipart/alternative; boundary="_000_1CA68BFDB5854CB093037E2A6FC2B005ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 78921f4a-0157-4c89-6af3-08d6ae1244ac X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2019 15:31:20.2927 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2826 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRTA+Xbvtut0dZ2KJ22ik6RaTRsFIpYFEiuzggisxnLoxUdzyq6K j4SZSjC1RENzOKZlWmo+SliKJA4hNMEsNWyhLaXIFCF84CNr26fgf79zzu8czvn4KELUxvWj UrSZjE6r1kh4ArI2zpJ3/Hp7lTKsf9szfG21jAh/u9hBnOUoGhvXOVfRTUFkIqNJyWZ0oWfi BcnW7k5uhvVyTtdkJV+PWi8ZkBsF9El4aBngG5CAEtGDCJpHZvnOgoheRbBgy8YFBz/d6uLh oJEDTd9NHGdA0hUELM4YuLilmgPFzyKw9QNB20o3x1ng0ZHwwb7kkrzpYHg98hs5maAPQF/T DOlkLzoAql60ol1nvNNEYJaBvrbIxSR9CNrLB10spKNgvqXDxYgWw3JhK4Fn+sKXOTMHH0dD Y98ogdkHfs1uczEHwnypnodZDB/NpQhzLFiGC12XAW1DMNbX45AoR3AM2sYKsOMHDaPLfJxO h+JmOU4fhI6pJzutj3lw32TeeUcGml+WILxnAozbHvBxQwC0lNvJCiQ17lnb6BhLODTbeLTR daUnDNXOkTh9BDp6Q7EdBI9K7XzMh6GkzsTHigIqLRf2KvWIakE+LMOyaUlyuYzRpSSwbLpW pmUyXyHHHxro3ox4gwZ+nrMimkISD+GV6iqliKvOZnPTrAgoQuIt7L3lSAkT1bl5jC79ti5L w7BW5E+REl/hlshTKaKT1JnMHYbJYHS7VQ7l5qdHJYLKlayiYff8XlWFSrkUFyUN/DalUHF1 a/IJUPYY3W2EtaxeuuoR804aErsR8rwlemyK3JxSmIfWE+6ubJxXuBuD/HnXZMLUsIWIhslP f+o0qV7/xAao+XqxYP82Vxn3OS/m3nTXe/8b8TlissY+ka/ST6YH/y0/dXq6f5+EZJPVJ44S Olb9HxeIqds/AwAA Archived-At: Subject: [core] Pub Sub and multicast 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, 21 Mar 2019 15:31:38 -0000 --_000_1CA68BFDB5854CB093037E2A6FC2B005ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUTDtEUjogUHViL3N1YiBhbmQgbXVsdGljYXN0IGhhbGx3YXkgZGlzY3Vzc2lv biBoYXBwZW5pbmcgYXQgSUVURjEwNCAocG9zc2libHkgZHVyaW5nIHRoZSBoYWNrYXRob24/KS4g U2xpZGVzIGhlcmU6DQpodHRwczovL2dpdGh1Yi5jb20vRXJpY3Nzb25SZXNlYXJjaC9jb2FwLXB1 YnN1Yi1wcm9maWxlL2Jsb2IvbWFzdGVyL1B1YnN1Yi1tdWx0aWNhc3QucGRmICBDb250YWN0IG1l IGlmIGludGVyZXN0ZWQuDQpBcyBtZW50aW9uZWQgZHVyaW5nIHRoZSBDb1JFIGludGVyaW0sIEkg aGF2ZSBzdGFydGVkIHRvIHRoaW5rIG9uIGhvdyB0byBwcm9ncmVzcyB0aGUgc2VjdXJpdHkgZm9y IHB1Yi9zdWIgd29yay4gRm9yIHRoZSBwZW9wbGUgbm90IGZvbGxvd2luZywgdGhlcmUgaXMgY3Vy cmVudGx5IG9uZSBkcmFmdCBpbiBBY2UgdGhhdCBkZXNjcmliZXMgYSBwcm9maWxlIG9mIEFjZSBm b3IgYXV0aG9yaXphdGlvbiBhbmQga2V5IGRpc3RyaWJ1dGlvbiArIGNvbW11bmljYXRpb24gcHJv dGVjdGlvbiBmb3IgQ29BUCBwdWJzdWIgWzFdOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtcGFsb21iaW5pLWFjZS1jb2FwLXB1YnN1Yi1wcm9maWxlLTAzLg0KDQpXaGlsZSBsb29r aW5nIGF0IGhvdyB0byBtb3ZlIGZvcndhcmQgdGhhdCBkcmFmdCwgc29tZSB0aGluZ3MgY2FtZSB1 cDogZmlyc3Qgb2YgYWxsLCBpdCB3b3VsZCBiZSBuaWNlIHRvIHVzZSBtdWx0aWNhc3QgdG8gYnJv YWRjYXN0IG5vdGlmaWNhdGlvbnMgZnJvbSBicm9rZXIgdG8gc3Vic2NyaWJlcnMsIGZvciBwZXJm b3JtYW5jZSByZWFzb25zLiBTZWNvbmRseSwgdGhlIGFjZS1jb2FwLXB1YnN1YiBkb2N1bWVudCBt aXNzIGEgd2F5IHRvIHByb3RlY3QgdW5hd2FyZSBub2RlcyB0byBnZXQgdW53aWxsaW5nbHkgc3Vi c2NyaWJlZCBieSBhdHRhY2tlcnMgc3Bvb2ZpbmcgdGhlaXIgSVAgYWRkcmVzcy4gSW4gZmFjdCwg YWNlLWNvYXAtcHVic3ViIGRvZXMgcHJvdGVjdCB0aGUgcHVibGljYXRpb24sIGJ1dCBkb2VzIG5v dCBzZXQgdXAgdGhlIOKAnGF1dGhvcml6YXRpb24gZm9yIHN1YnNjcmliZXJz4oCdIG1lY2hhbmlz bSwgb3IgYW55IG90aGVyIERvUyBwcm90ZWN0aW9uIG1lY2hhbmlzbS4NCg0KVGhlc2UgdHdvIHBv aW50cyBtaWdodCBzZWVtIHBhcmFsbGVsIGFuZCBpbmRlcGVuZGVudCwgYnV0IG9uZSBpbmZsdWVu Y2UgdGhlIG90aGVyczogZGVwZW5kaW5nIG9uIGhvdyBtdWx0aWNhc3Qgbm90aWZpY2F0aW9ucyBh cmUgc2V0IHVwLCB3ZSBtaWdodCByZXVzZSBleGlzdGluZyBtZWNoYW5pc21zIHRoYXQgbWlnaHQg cHJvdGVjdCBhZ2FpbnN0IHVuYXV0aG9yaXplZCBub2RlcyBiZWluZyBzZW50IG5vdGlmaWNhdGlv bnMgZnJvbSB0aGUgYnJva2VyLg0KDQpJIHB1dCB1cCBzb21lIGlkZWFzIGluIHNsaWRlcyBhbmQg d2FzIGhvcGluZyB0byBnZXQgc29tZSBkaXNjdXNzaW9uIHN0YXJ0ZWQgZHVyaW5nIHRoZSBoYWNr YXRob24gKGlmIHBvc3NpYmxlKToNCmh0dHBzOi8vZ2l0aHViLmNvbS9Fcmljc3NvblJlc2VhcmNo L2NvYXAtcHVic3ViLXByb2ZpbGUvYmxvYi9tYXN0ZXIvUHVic3ViLW11bHRpY2FzdC5wZGYgYW5k L29yIGluIHRoZSBtYWlsaW5nIGxpc3QuIEFzIHlvdSBjYW4gc2VlLCBJIHRyeSB0byBleHBsYWlu IHRoZSBwcm9ibGVtIGFuZCBjb21lIHVwIHdpdGggcG9zc2libGUgc29sdXRpb25zIGJhc2VkIG9u IHRoZSBleGlzdGluZyBkcmFmdHMuIFRoZXNlIGFyZSBvZiBjb3Vyc2UganVzdCB2ZXJ5IGhpZ2gg bGV2ZWwgZHJhZnQgc29sdXRpb25zLCBhbmQgcmVxdWlyZSBtb3JlIGRpc2N1c3Npb24uDQoNCkFu eSBmZWVkYmFjayB3ZWxjb21lIQ0KDQpGcmFuY2VzY2ENCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29hcC1wdWJzdWItMDgNCg== --_000_1CA68BFDB5854CB093037E2A6FC2B005ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4571EC83442AFF42A19588C143C26CFD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+VEw7RFI6IFB1Yi9zdWIgYW5kIG11bHRpY2FzdCBoYWxsd2F5IGRpc2N1c3Np b24gaGFwcGVuaW5nIGF0IElFVEYxMDQgKHBvc3NpYmx5IGR1cmluZyB0aGUgaGFja2F0aG9uPyku IFNsaWRlcyBoZXJlOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9Fcmljc3NvblJlc2VhcmNoL2NvYXAtcHVic3ViLXByb2ZpbGUvYmxvYi9tYXN0ZXIvUHVi c3ViLW11bHRpY2FzdC5wZGYiPmh0dHBzOi8vZ2l0aHViLmNvbS9Fcmljc3NvblJlc2VhcmNoL2Nv YXAtcHVic3ViLXByb2ZpbGUvYmxvYi9tYXN0ZXIvUHVic3ViLW11bHRpY2FzdC5wZGY8L2E+ICZu YnNwO0NvbnRhY3QgbWUgaWYNCiBpbnRlcmVzdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+QXMgbWVudGlvbmVkIGR1cmluZyB0aGUgQ29SRSBpbnRlcmltLCBJIGhhdmUg c3RhcnRlZCB0byB0aGluayBvbiBob3cgdG8gcHJvZ3Jlc3MgdGhlIHNlY3VyaXR5IGZvciBwdWIv c3ViIHdvcmsuIEZvciB0aGUgcGVvcGxlIG5vdCBmb2xsb3dpbmcsIHRoZXJlIGlzIGN1cnJlbnRs eSBvbmUgZHJhZnQgaW4gQWNlIHRoYXQgZGVzY3JpYmVzIGEgcHJvZmlsZSBvZg0KIEFjZSBmb3Ig YXV0aG9yaXphdGlvbiBhbmQga2V5IGRpc3RyaWJ1dGlvbiAmIzQzOyBjb21tdW5pY2F0aW9uIHBy b3RlY3Rpb24gZm9yIENvQVAgcHVic3ViIFsxXToNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1wYWxvbWJpbmktYWNlLWNvYXAtcHVic3ViLXByb2ZpbGUtMDMiPg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhbG9tYmluaS1hY2UtY29hcC1wdWJz dWItcHJvZmlsZS0wMzwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5XaGlsZSBsb29raW5nIGF0IGhvdyB0byBtb3ZlIGZvcndhcmQgdGhhdCBkcmFmdCwgc29t ZSB0aGluZ3MgY2FtZSB1cDogZmlyc3Qgb2YgYWxsLCBpdCB3b3VsZCBiZSBuaWNlIHRvIHVzZSBt dWx0aWNhc3QgdG8gYnJvYWRjYXN0IG5vdGlmaWNhdGlvbnMgZnJvbSBicm9rZXIgdG8gc3Vic2Ny aWJlcnMsIGZvciBwZXJmb3JtYW5jZSByZWFzb25zLiBTZWNvbmRseSwNCiB0aGUgYWNlLWNvYXAt cHVic3ViIGRvY3VtZW50IG1pc3MgYSB3YXkgdG8gcHJvdGVjdCB1bmF3YXJlIG5vZGVzIHRvIGdl dCB1bndpbGxpbmdseSBzdWJzY3JpYmVkIGJ5IGF0dGFja2VycyBzcG9vZmluZyB0aGVpciBJUCBh ZGRyZXNzLiBJbiBmYWN0LCBhY2UtY29hcC1wdWJzdWIgZG9lcyBwcm90ZWN0IHRoZSBwdWJsaWNh dGlvbiwgYnV0IGRvZXMgbm90IHNldCB1cCB0aGUg4oCcYXV0aG9yaXphdGlvbiBmb3Igc3Vic2Ny aWJlcnPigJ0gbWVjaGFuaXNtLA0KIG9yIGFueSBvdGhlciBEb1MgcHJvdGVjdGlvbiBtZWNoYW5p c20uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGVzZSB0d28g cG9pbnRzIG1pZ2h0IHNlZW0gcGFyYWxsZWwgYW5kIGluZGVwZW5kZW50LCBidXQgb25lIGluZmx1 ZW5jZSB0aGUgb3RoZXJzOiBkZXBlbmRpbmcgb24gaG93IG11bHRpY2FzdCBub3RpZmljYXRpb25z IGFyZSBzZXQgdXAsIHdlIG1pZ2h0IHJldXNlIGV4aXN0aW5nIG1lY2hhbmlzbXMgdGhhdCBtaWdo dCBwcm90ZWN0IGFnYWluc3QgdW5hdXRob3JpemVkDQogbm9kZXMgYmVpbmcgc2VudCBub3RpZmlj YXRpb25zIGZyb20gdGhlIGJyb2tlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkkgcHV0IHVwIHNvbWUgaWRlYXMgaW4gc2xpZGVzIGFuZCB3YXMgaG9waW5nIHRv IGdldCBzb21lIGRpc2N1c3Npb24gc3RhcnRlZCBkdXJpbmcgdGhlIGhhY2thdGhvbiAoaWYgcG9z c2libGUpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vRXJp Y3Nzb25SZXNlYXJjaC9jb2FwLXB1YnN1Yi1wcm9maWxlL2Jsb2IvbWFzdGVyL1B1YnN1Yi1tdWx0 aWNhc3QucGRmIj5odHRwczovL2dpdGh1Yi5jb20vRXJpY3Nzb25SZXNlYXJjaC9jb2FwLXB1YnN1 Yi1wcm9maWxlL2Jsb2IvbWFzdGVyL1B1YnN1Yi1tdWx0aWNhc3QucGRmPC9hPiBhbmQvb3IgaW4g dGhlDQogbWFpbGluZyBsaXN0LiBBcyB5b3UgY2FuIHNlZSwgSSB0cnkgdG8gZXhwbGFpbiB0aGUg cHJvYmxlbSBhbmQgY29tZSB1cCB3aXRoIHBvc3NpYmxlIHNvbHV0aW9ucyBiYXNlZCBvbiB0aGUg ZXhpc3RpbmcgZHJhZnRzLiBUaGVzZSBhcmUgb2YgY291cnNlIGp1c3QgdmVyeSBoaWdoIGxldmVs IGRyYWZ0IHNvbHV0aW9ucywgYW5kIHJlcXVpcmUgbW9yZSBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QW55IGZlZWRiYWNrIHdlbGNvbWUhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5GcmFuY2VzY2E8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlsxXSA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvYXAtcHVic3ViLTA4Ij4NCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29hcC1wdWJzdWItMDg8 L2E+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1CA68BFDB5854CB093037E2A6FC2B005ericssoncom_-- From nobody Thu Mar 21 08:51:35 2019 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 D977D13134E for ; Thu, 21 Mar 2019 08:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Ob-_UUreHwbc for ; Thu, 21 Mar 2019 08:51:22 -0700 (PDT) Received: from smtp.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 693A0131326 for ; Thu, 21 Mar 2019 08:51:22 -0700 (PDT) Received: from [10.0.0.216] (unknown [82.202.112.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44QB934fKGzydL; Thu, 21 Mar 2019 16:51:19 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 574876276.552436-30567beba8fb6d0f0eeecb0609b0b21e Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 21 Mar 2019 16:51:18 +0100 Message-Id: <7D9023AE-28AB-4EC9-9289-A7B89869BFCA@tzi.org> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] CoRE@IETF104 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, 21 Mar 2019 15:51:25 -0000 Thanks to the helpful discussion in the interim yesterday, we now have a = 0.1 agenda: https://datatracker.ietf.org/meeting/104/materials/agenda-104-core We have 120+90 minutes, a bit more than we requested, and it=E2=80=99s = still tight. Please check if all the discussions you need are represented and have = the right amount of time. Please clarify the objectives for each = discussion slot (mail to core-chairs@ietf.org) if they aren=E2=80=99t = too clear yet. Gr=C3=BC=C3=9Fe, Carsten (Near Dresden, closing in on Praha=E2=80=A6) From nobody Thu Mar 21 09:04:26 2019 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 C01E713143A; Thu, 21 Mar 2019 09:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms13qNNbqvVE; Thu, 21 Mar 2019 09:04:18 -0700 (PDT) Received: from smtp.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 A395B131371; Thu, 21 Mar 2019 09:03:54 -0700 (PDT) Received: from [10.0.0.216] (unknown [82.202.112.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44QBRX2XCJzycr; Thu, 21 Mar 2019 17:03:52 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <1CA68BFD-B585-4CB0-9303-7E2A6FC2B005@ericsson.com> Date: Thu, 21 Mar 2019 17:03:51 +0100 Cc: "core@ietf.org" , Ace Wg X-Mao-Original-Outgoing-Id: 574877029.323092-1268c0c3c97ca6dc1872f3924fef50d4 Content-Transfer-Encoding: quoted-printable Message-Id: <2A2E572D-D00C-443B-B42D-CC6C9500474D@tzi.org> References: <1CA68BFD-B585-4CB0-9303-7E2A6FC2B005@ericsson.com> To: Francesca Palombini X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Pub Sub and multicast 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, 21 Mar 2019 16:04:25 -0000 I=E2=80=99m certainly interested. Not sure I understand =E2=80=9C =E2=80=A2 Additionally, the Subscriber = must be authorized to subscribe, otherwise an attacker could DoS = external nodes that do not want to receive the publications=E2=80=9D. = Whether the attacker is authorized to subscribe and whether the actual = notification receiver is interested is kind of orthogonal. Generally, we=E2=80=99d need a way to prove address ownership for = setting up observation interest. The Echo option can be used for = that=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 21 09:32:56 2019 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 D605B131412 for ; Thu, 21 Mar 2019 09:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=W3XYmq7s; dkim=pass (1024-bit key) header.d=ericsson.com header.b=DFbErSKj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFcVay0ImI-D for ; Thu, 21 Mar 2019 09:32:53 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01391313D0 for ; Thu, 21 Mar 2019 09:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1553185966; x=1555777966; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=z1UnY87ZgMwiqUeCnTVy4Q1CeantQXMl7TubI1W5xzc=; b=W3XYmq7s+c/6a/Zf7yb2UUrKzgS4BTSYuw88rM14mcO5AeXvSi9ZwMhtuW5n8c+4 qUO0LFGRx3fl0WQ+H9yhqRztzZkh08gK//UZAybfFoOWBn4vZOss3/WJOP7fScVq 5RJuy2Emi0l3wOgfHr2mf/x8pIzKJcOluxByb/NbuFU=; X-AuditID: c1b4fb2d-fafff70000002218-1d-5c93bcae891e Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3A.45.08728.EACB39C5; Thu, 21 Mar 2019 17:32:46 +0100 (CET) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 21 Mar 2019 17:32:45 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Thu, 21 Mar 2019 17:32:45 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z1UnY87ZgMwiqUeCnTVy4Q1CeantQXMl7TubI1W5xzc=; b=DFbErSKj+xeWZoa72TfEePlb7ZjXsrEXoplFH2EOwlvdsJvtj2pZVEYWIt7El9QhdOJ3SMMv1Xgsryd0CdfRa8ggkSEoCEIgJESPZJu0SjQMq9fTmVIFKFf4O5Nqa5bqm7MBFr7l/Tt11FblUTOAiGoHsVi1SEPUzTQkAlaor8E= Received: from AM5PR0701MB2307.eurprd07.prod.outlook.com (10.169.152.18) by AM5PR0701MB2929.eurprd07.prod.outlook.com (10.168.156.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.15; Thu, 21 Mar 2019 16:32:45 +0000 Received: from AM5PR0701MB2307.eurprd07.prod.outlook.com ([fe80::68c0:59da:7d33:7410]) by AM5PR0701MB2307.eurprd07.prod.outlook.com ([fe80::68c0:59da:7d33:7410%10]) with mapi id 15.20.1709.015; Thu, 21 Mar 2019 16:32:45 +0000 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org" CC: "draft-ietf-core-resource-directory.authors@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBmb3IgUmVzb3VyY2UgRGlyZWN0b3J5?= Thread-Index: AdTgA6ykzjVMaAxvQH6T56b4ADSYAA== Date: Thu, 21 Mar 2019 16:32:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.75] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa75adcc-54f5-43db-fba3-08d6ae1ad8e5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2929; x-ms-traffictypediagnostic: AM5PR0701MB2929: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0983EAD6B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(376002)(366004)(136003)(189003)(199004)(6346003)(71200400001)(71190400001)(3846002)(2501003)(54896002)(33656002)(4326008)(55016002)(99286004)(6116002)(7696005)(105586002)(6506007)(102836004)(7736002)(790700001)(5640700003)(74316002)(486006)(236005)(476003)(6436002)(26005)(6306002)(2906002)(66574012)(450100002)(25786009)(606006)(6916009)(5660300002)(186003)(2351001)(9686003)(85202003)(52536014)(66066001)(8936002)(316002)(1730700003)(106356001)(81156014)(68736007)(4744005)(53936002)(14454004)(97736004)(966005)(413944005)(256004)(86362001)(81166006)(478600001)(85182001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2929; H:AM5PR0701MB2307.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jaime.jimenez@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OBYpej60IBOTeWDeReBUTiS5dXl4cRnzxd1Ug1Yw5Up7/NO5JxFTcZjXcmjDbubwAAOELEURCcTt8dgRo8oNNXY7MZ1sZAAQoaPlAYHAynICflE0Hr/s8x/kNhN17YCMFB3OXy9iJn827EnS2nCJWx1qIs2S9M0wIOKB5IQjn1L5W7iA3DJF6rIMePwi9AFnlYSe3Mb2KADmvp5RwMFUAIHbvf1MTKUdJuB29oTPnAGSc+dgLmCPGVRKKYg22kJU5PVpMIg8FOFftShnR7bELFpKwjIrnU3IFj6Y4MGZp9/TWfHeiy4xvvPjGWT0UcXH0BspuOhKYWqPyQWbOIwV2PMrje+PtZSil+qEPw5NjIn950VQafy6SZBg+WoL10nV+/aGvJUlhcvX8Vzu8NijT/kTaR298deA68XMmj5/tx0= Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB230754CF5CD643B6B7DC1A7697420AM5PR0701MB2307_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fa75adcc-54f5-43db-fba3-08d6ae1ad8e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2019 16:32:44.9736 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2929 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+86Z21EafC2Xb8ukFlGJ15TaH2kXMyqwIhBCjRx6cpI63VHR EFRETaewXFSbW95GhmkztbybmuGFwEtXl5CSFeIFk5o5Ldp2Fvjf73ne5334XvgoUlDtJKLi k1JpRZI0Qcx14WiutKZ5P+lSR/lZpkHSs2gkJZ0lzcQJ4qzBsEZcQhEux2LphPh0WuEbHO0i W8obIpLNxzN+TU6jHKQKLkbOFOBAGFx9SRQjF0qABxAsqN7zWGFG0Nk7zWGFgQDLjwnSJjhY RcLvyo+O2D0CirR6Liu+I2ibXSJszVwcAivfcnk2dsX7oPn1PLIxiVPg7ecyO2/H56BI98aR uQDKgRoH+4CysZBrYw7eD5W9PaSN+TgaxjRmJxsjvANWR+oJttMNTLMVBHsRBkPXKMmyEOa+ /LXmKSvvgRdPL7P2bpioUCKWw0DfOmV/P+BPCJZXhjjswAsspj+OHhFUjf7ksT1yaC8XsLY7 GCerCXZXw4Vu3ZJ9V4BpqG3IR7Y8wldhpIpm8x5QVzrjqB8loWA8XIU8tZsuYFkOS8paO/Px NhjWzHK01iYSHwJjhy8b2Qt3lDM8lg9Cvk7P2+xXIl4dEjI0wyTGHQ7woRXxMQwjT/JJolOb kPXn9LWse7ehx/Mn+xGmkHgrX9GkjhI4SdOZzMR+BBQpduV3RFotfqw08yatkF9TpCXQTD/a RXHEbvwNwbYoAY6TptI3aDqZVvyfEpSzKAfp7q8lRlmCatVuD1+5c3fOnFpMKx3zW+BlG4NE 9QVZi3flB4TPhnOZ+a/5kpQaqeDD+YR0HI4LfcffDd8KeH5kyhR42z/muuRM34MMD1lDWXm1 drlFGyGcbDFd1LYbvXr0Qq8tG8OPSvIGI9dlIRGhwsaso6FmKnuuO0wtO50i5jAyqb8nqWCk /wDkEmV2NQMAAA== Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 21 Mar 2019 16:32:55 -0000 --_000_AM5PR0701MB230754CF5CD643B6B7DC1A7697420AM5PR0701MB2307_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDb3JlIFdHLA0KDQpUaGlzIGlzIHRoZSBXR0xDIGZvciB0aGUgUmVzb3VyY2UgRGlyZWN0 b3J5IGRyYWZ0Lg0KDQpCb3RoIGF1dGhvcnMgYW5kIGNoYWlycyBmZWVsIHRoYXQgdGhlIGRvY3Vt ZW50IGlzIHZlcnkgbWF0dXJlIGF0IHRoaXMgcG9pbnQsIGl0IGhhcyBnb25lIHRocm91Z2ggbWFu eSByZXZpZXdzLCBpbnRlcm9wcyBhbmQgaXQgaGFzIGdhdGhlcmVkIHN1ZmZpY2llbnQgZmVlZGJh Y2sgZnJvbSB0aGUgZ3JvdXAuDQoNClBsZWFzZSB0YWtlIHNvbWUgdGltZSB0byBjYXJlZnVsbHkg cmV2aWV3IHRoZSBsYXRlc3QgdmVyc2lvbiBhbmQgcHJvdmlkZSBmZWVkYmFjayBieSAyMDE5LTA0 LTE3ICwgc3BlY2lhbGx5IHRob3NlIG9mIHlvdSB0aGF0IGNvbnRyaWJ1dGUgdG8gb3RoZXIgb3Jn YW5pc2F0aW9ucyB0aGF0IG1ha2UgdXNlIG9mIHNvbWUgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQu DQoNClRoZSBkcmFmdCBpcyBhdmFpbGFibGUgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY29yZS1yZXNvdXJjZS1kaXJlY3RvcnkgYW5kIHRoZSB3b3JraW5nIGNvcHkg aXMgYXQgaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvcmVzb3VyY2UtZGlyZWN0b3J5DQoNCkR1 cmluZyBJRVRGIDEwNCBzb21lIG9mIHVzIHdpbGwgYWxzbyBtZWV0IGF0IHRoZSBoYWNrYXRob24g dG8gdGVzdCBvdXIgaW1wbGVtZW50YXRpb25zOyB5b3UgY2FuIGZpbmQgKGFuZCBqb2luISkgdXMg ZHVyaW5nIGhhY2thdGhvbiBvdXJzIGF0IGh0dHBzOi8vaml0c2kudG9vbHMuaWV0Zi5vcmcvcmQt aW50ZXJvcA0KDQpCZXN0IFJlZ2FyZHMsDQpKYWltZSBKaW3DqW5leg0K --_000_AM5PR0701MB230754CF5CD643B6B7DC1A7697420AM5PR0701MB2307_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNh Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVu Z1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RGVhciBDb3JlIFdHLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9z cGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHRoZSBXR0xDIGZvciB0aGUgUmVzb3VyY2UgRGlyZWN0b3J5 IGRyYWZ0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3Bh Y2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkJvdGggYXV0aG9ycyBhbmQgY2hhaXJzIGZlZWwg dGhhdCB0aGUgZG9jdW1lbnQgaXMgdmVyeSBtYXR1cmUgYXQgdGhpcyBwb2ludCwgaXQgaGFzIGdv bmUgdGhyb3VnaCBtYW55IHJldmlld3MsIGludGVyb3BzIGFuZCBpdCBoYXMgZ2F0aGVyZWQgc3Vm ZmljaWVudA0KIGZlZWRiYWNrIGZyb20gdGhlIGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5QbGVh c2UgdGFrZSBzb21lIHRpbWUgdG8gY2FyZWZ1bGx5IHJldmlldyB0aGUgbGF0ZXN0IHZlcnNpb24g YW5kIHByb3ZpZGUgZmVlZGJhY2sgYnkNCjxiPjIwMTktMDQtMTc8L2I+ICwgc3BlY2lhbGx5IHRo b3NlIG9mIHlvdSB0aGF0IGNvbnRyaWJ1dGUgdG8gb3RoZXIgb3JnYW5pc2F0aW9ucyB0aGF0IG1h a2UgdXNlIG9mIHNvbWUgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PlRoZSBkcmFmdCBpcyBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtcmVzb3VyY2UtZGlyZWN0b3J5Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzA5NTBEMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29y ZS1yZXNvdXJjZS1kaXJlY3Rvcnk8L3NwYW4+PC9hPiBhbmQgdGhlIHdvcmtpbmcgY29weSBpcyBh dA0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvcmVzb3VyY2UtZGlyZWN0b3J5 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzA5NTBEMCI+aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cv cmVzb3VyY2UtZGlyZWN0b3J5PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RHVyaW5nIElF VEYgMTA0IHNvbWUgb2YgdXMgd2lsbCBhbHNvIG1lZXQgYXQgdGhlIGhhY2thdGhvbiB0byB0ZXN0 IG91ciBpbXBsZW1lbnRhdGlvbnM7IHlvdSBjYW4gZmluZCAoYW5kIGpvaW4hKSB1cyBkdXJpbmcg aGFja2F0aG9uIG91cnMgYXQNCjxhIGhyZWY9Imh0dHBzOi8vaml0c2kudG9vbHMuaWV0Zi5vcmcv cmQtaW50ZXJvcCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwOTUwRDAiPmh0dHBzOi8vaml0c2kudG9v bHMuaWV0Zi5vcmcvcmQtaW50ZXJvcDwvc3Bhbj48L2E+Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5KYWltZSBKaW3DqW5lejwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM5PR0701MB230754CF5CD643B6B7DC1A7697420AM5PR0701MB2307_-- From nobody Thu Mar 21 14:08:55 2019 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 B36AC1277CC for ; Thu, 21 Mar 2019 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.com header.b=XJrzmGFe; dkim=pass (1024-bit key) header.d=ericsson.com header.b=aMGPyNhj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSbzDVUE5zyZ for ; Thu, 21 Mar 2019 14:08:51 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CF01228B7 for ; Thu, 21 Mar 2019 14:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1553202529; x=1555794529; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bKPa/0BY4WXJiglXcJ7/lMJRf45lqjq99dk9WSn1xcE=; b=XJrzmGFe91u/wKD7kmR57E2TXK4g85YMxlgKaXQOQwRqo8UdNNYDLA0ZQj8fvNR0 yqg8T5M0kHILfE4D5HLTbzJeQpFXBGwM3pEc+LvVPQxmTmunduWhaoPCUlE2HvTa 5a2tI7GUILqbsgh3N3sI7gBvMuvL4rdvU0l3OT8LeBk=; X-AuditID: c1b4fb25-259ff7000000438b-af-5c93fd61ee5e Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 07.B9.17291.16DF39C5; Thu, 21 Mar 2019 22:08:49 +0100 (CET) Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESBMB505.ericsson.se (153.88.183.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 21 Mar 2019 22:08:49 +0100 Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 21 Mar 2019 22:08:49 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Thu, 21 Mar 2019 22:08:48 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bKPa/0BY4WXJiglXcJ7/lMJRf45lqjq99dk9WSn1xcE=; b=aMGPyNhjq7Go2k9+rotu8Y4Utkjw7+cXgyX+99xm+9l5zUWWFiliLfbzmoIwWlcg29owknzK9Nuh+QWkid7PDxg3nmpEsRJ3tbjmufz5QL4yENyb4AAhp9QsujaIduORnWAI2W7knPa+EMaxDy0bIRGBsmAdR64JHkS8Kg0d/ns= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3308.eurprd07.prod.outlook.com (10.170.246.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.8; Thu, 21 Mar 2019 21:08:47 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8%3]) with mapi id 15.20.1730.013; Thu, 21 Mar 2019 21:08:47 +0000 From: John Mattsson To: core Thread-Topic: Choice of signature Algorithm(s) in Group OSCORE Thread-Index: AQHU4CpGywafXrMZ/UarZfJVbQoXNA== Date: Thu, 21 Mar 2019 21:08:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cbd245f6-d078-484b-0b51-08d6ae416918 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3308; x-ms-traffictypediagnostic: HE1PR07MB3308: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0983EAD6B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(396003)(39860400002)(136003)(189003)(199004)(106356001)(105586002)(6436002)(6486002)(316002)(68736007)(58126008)(3846002)(6116002)(2906002)(6916009)(33656002)(82746002)(36756003)(66066001)(97736004)(186003)(102836004)(81166006)(81156014)(86362001)(6506007)(53936002)(8676002)(26005)(478600001)(305945005)(7736002)(83716004)(2616005)(71190400001)(71200400001)(476003)(486006)(6512007)(6306002)(5660300002)(25786009)(14454004)(256004)(99286004)(8936002)(966005)(14444005)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3308; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: bHNMje5IerrlrCntfeOHBZDk7oYA5xCQkH/oN8b6iRZ0F2BLPBV9A2tEoOquiesN6Wi+n5KU+DDC/TkGgU957nMDJXrMdx6eh5yJyL1yi428BXr6Ewt4qXMW3c1OCsi70OFygFgQbae9B4hkRGTU4ph+hxxY570yWDp4J8ud+m4EYPM+nRhRHiXFpa8DQXaGQ2Q4yuRwTRkoiZUfcVnXLf1O7roQayCK5K/U8ANjQzCbnT6cJ9NN1zby5an/xDa4cVJXlcAnMusnL4J0G8j43pcnGHn6B38K6b3f8yRE6no+XzkicyXjf49sFLh3SSqez/12NIFTx1kZlMWjbFQbRtHeRMl8bQiMGQBCc8/0rTSJ0babWth8Z6Xr22+zrIpPvFMcPg/szEZomZAPkB9BgbHcjTKwD+le3/Cs6pomzz4= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cbd245f6-d078-484b-0b51-08d6ae416918 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2019 21:08:47.8244 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3308 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHPffh7kaD43z9WBk5GpHlqySKwgz8QwKpP/pD0rClF10+uXdJ GsiQhq8UdVFq+MhGmTVmKiUiVkMUNbHSzGmFuhVKsylqQ8pq213Rf5/v43fgd85hSFkpLWfU uRqWy1VlK3wlVEPSs4Jw1bY+JapWH3J0YMVExqEEg2GLOIvOS06ks9nqApaLjL0oyXxkaaXy Z+GqtWwdaVEZVCCGARwDze+jK5CEkeFBBKsbm0gQ3xHovjmIf+LpjUVSEAYCZu2dHkHhGhLu Gh1UBRK7Ej0BW6M5QmsewfCMlnQHvjgKmvq1vm4OwADlm89FbvbHx8C5soQEPxaGSo2EwBFQ ZVz2HEphJVQvrnpYik/C3Pq450yEg8A5+tjTJ3EwzNpaPAwYg6F/ghQ4EJatv2g3B+JI6Kme p4TZC6DT3aaFTiiMDbR7+yHwtqUSCZwIVW1DIvcygC2uZZbMIiEIgw8lVm9JDk7rmtfPguFa GyXwLjBZ2ghhuIuGko07vsIVsfDAqPMO74aOqgWqBoU3/rdEo+tVSLwfTH2Rgp0A95u7RQKH ws3KBQ9LsR+MNNioVkR3oECe5S/lZBw6HMFy6jSez8uNyGU1Xcj1PV72/FD2okn7KTPCDFLs kOY79CkyWlXAF+aYETCkIkDal+yypOmqwiKWy0vlrmSzvBntZChFsPSnzC9FhjNUGjaLZfNZ 7m9KMGK5FkVPFy3vkTvGjh+8rqwVS7Ob4sVHONOLyfYYaia8ODk+qfF10FeipTvP3zKyMH4g da/P5xoTLn8ytoYGHiZqqqqN6pWJ8Wt1H+Om7p251Wnflth8nF+G6junztWG0nldYmXvO85Q nXI5bV9x4ptXxYPzpk/+VN3pmWn6d71dN6eg+ExVdBjJ8ao/pOvEFBoDAAA= Archived-At: Subject: [core] Choice of signature Algorithm(s) in Group OSCORE 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, 21 Mar 2019 21:08:54 -0000 IEkgdGhpbmsgd2UgbmVlZCBzb21lIG1vcmUgZGlzY3Vzc2lvbiBvZiB3aGljaCBzaWduYXR1cmUg YWxnb3JpdGhtcyB0byB1c2UuIENhbmRpZGF0ZXMgd291bGQgYmU6DQoNCkFsZ29yaXRobSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU2lnbmF0dXJlIHNpemUgICAgIFNlY3VyaXR5IGxl dmVsDQpFQ0RTQSBzZWNwMjI0cjEgKFAtMjI0KSAgICA1NiBieXRlcyAgICAgICAgICAgICAgIDEx Mg0KRUNEU0Egc2VjcDI1NnIxIChQLTI1NikgICAgNjQgYnl0ZXMgICAgICAgICAgICAgICAxMjgN CkVDRFNBIHNlY3AyNTZrMSAgICAgICAgICAgICAgICAgIDY0IGJ5dGVzICAgICAgICAgICAgICAg MTI4DQpFZDI1NTE5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDY0IGJ5dGVzICAg ICAgICAgICAgICAgMTI4DQoNClRoZSBDRlJHIHJldmlldyBvZiBFREhPQyBicm91Z2h0IHVwIHRo ZSBxZXVzdGlvbiBpZiBub3QgUC0yMjQgd291bGQgYmUgYSBiZXR0ZXIgY2hvaWNlIGlmIHRoZSBt YWluIGdvYWwgaXMgdG8gZ2V0IHNtYWxsZXIgbWVzc2FnZXMuIEVDRFNBIHdpdGggUC0yMjQgaGFz IHRoZSBvYnZpb3VzIGFkdmFudGFnZSBvZiBoYXZpbmcgc2lnbmF0dXJlcyB0aGF0IGFyZSA4IGJ5 dGVzIHNob3J0ZXIuDQoNCjExMi1iaXQgc2VjdXJpdHkgaXMgYWNjb3JkaW5nIHRvIE5JU1Qgb2sg dG8gdXNlIHVudGlsIDIwMzAuDQoNCkVDRFNBIHdpaCBQLTIyNCBpcyBzaWduaWZpY2FudGx5IGZh c3RlciB0aGFuIEVDRFNBIHdpdGggUC0yNTYsIGFyb3VuZCAyLzMgdGhlIG51bWJlciBvZiBvcGVy YXRpb25zL3RpbWUuIHNlY3AyNTZrMSBpcyBhcm91bmQgMzAwICUgZmFzdGVyIHRoYW4gc2VjcDI1 NnIxLiBIYXJkZXIgdG8gZmluZCBjb21wYXJpc2lvbnMgd2l0aCBFZDI1NTE5LiBNb3N0IG9mIHRo ZSBzcGVlZCB3aWxsIGRlcGVuZCBvbiB0aGUgY3VydmUsIGJ1dCBFZERTQSAoU2Nobm9ycikgYWxz byBoYXZlIG90aGVyIGFkdmFudGFnZXMgdGhhdCBzcGVlZCB1cCBzaWduaW5nIGNvbXBhcmVkIHRv IEVDRFNBLiBFZDI1NTE5IHZlcmlmeSBpcyBsaWtlbHkgYXQgbGVhc3QgYXMgZmFzdCBhcyBFQ0RT QSB3aXRoIFAtMjI0IG9uIGFsbCBwbGF0Zm9ybXMgYW5kIHNpZ25pZmljYW50bHkgZmFzdGVyIGZv ciBzaWduaW5nIG9uIGFsbCBwbGF0Zm9ybXMuIE9uIHNvbWUgcGxhdGZvcm1zIEkgdGhpbmsgRWQy NTUxOSBpcyBzaWduaWZpY2FudGx5IGZhc3RlciBhbHNvIGZvciB2ZXJpZmljYXRpb24uDQoNCklu IHRlcm1zIG9mIG51bWJlciBvZiBpbXBsZW1lbnRhdGlvbiwgSSB0aGluayBFQ0RTQSB3aXRoIFAt MjU2IGluIGlzIHRoZSBsZWFkLCB3aXRoIEVDRFNBIFAtMjI0IGFzIHNlY29uZCwgYW5kIEVkMjU1 MTkgaW4gbGFzdCBwbGFjZS4NCg0KSSBhbSBsZWFuaW5nIHRvd2FyZHMgdGhhdCBQLTIyNCBzaG91 bGQgcHJvYmFibHkgYmUgc3VwcG9ydGVkICh0aGVuIEVTMjI0IG5lZWQgdG8gYmUgc3RhbmRhcmRp emVkIGluIENPU0UpLiBUaGUgb3RoZXIgdGhyZWUgYXJlIGFscmVhZHkgcmVnaXN0ZXJlZCBmb3Ig Q09TRS4gVGhlIGhhcmRlciBxdWVzdGlvbiBpcyB3aGljaCBzaG91bGQgYmUgTVRJLiBTZXZlcmFs IHBlb3BsZSBoYXZlIHN0YXRlZCB0aGF0IGxhdGVuY3kgaXMgb2YgdXRoZXJtb3N0IGltcG9ydGFu Y2UsIGluIGNhc2UgdGhlIGN1cnJlbnQgY2hvaWNlIG9mIEVkMjU1MTkgYXMgTVRJIGlzIGxpa2Vs eSB0aGUgY29ycmVjdCBjaG9pY2UuDQoNCkEgZ29vZCBidXQgYSBsaXR0bGUgYml0IGRhdGVkIGNv bXBhcmlzaW9uIG9mIGRpZmZlcmVudCBhbGdvcml0aG1zIG9uIEFSTSBwcm9jZXNzb3JzOg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzkyL21hdGVyaWFscy9zbGlkZXMtOTIt bHdpZy0zDQoNClRoZSBjaG9pY2UgYWxzbyBkZXBlbmRzIG9uIGlmIHRoZXJlIGFyZSBmYXN0IGlt cGxlbWVudGF0aW9ucyBhdmFpbGFibGUuIEFzc2VtYmx5IG9wdGltaXplZCB2ZXJzaW9uIG9mIHRo ZSBOSVNUIGN1cnZlcyBpcyBsaWtlbHkgYXMgZmFzdCBvciBmYXN0ZXIgdGhhbiBhIGN1cnZlMjU1 MTkgaW1wbGVtZW50YXRpb24gd3JpdHRlbiBpbiBDLg0KDQpodHRwczovL2dpdGh1Yi5jb20va21h Y2theS9taWNyby1lY2MgaGFzIHZlcnkgZmFzdCBpbXBsZW1lbnRhdGlvbnMgKGZvciBBUk0pIG9m IEVDREggYW5kIEVDRFNBIHdpdGggc2VjcDE2MHIxLCBzZWNwMTkycjEsIHNlY3AyMjRyMSwgc2Vj cDI1NnIxLCBhbmQgc2VjcDI1NmsxLiBJIGNhbm5vdCBmaW5kIGFueXRoaW5nIHNpbWlsYXIgZm9y IEVkRFNBLg0KDQpDaGVlcnMsDQpKb2huDQoNCg== From nobody Thu Mar 21 14:25:12 2019 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 486BA1277CC for ; Thu, 21 Mar 2019 14:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLwujglaS5PG for ; Thu, 21 Mar 2019 14:25:08 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0: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 CEBDD12762F for ; Thu, 21 Mar 2019 14:25:07 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id l4so3467309ite.1 for ; Thu, 21 Mar 2019 14:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=WsvVZksvBcfyQdZtqLMfFeZiWFmRxPCvv/DTgHSzgnU=; b=NJ5+TdrNSrSbhiHUlDG51+MyZlD0hb15t/QYDPSmwslvS+VO6aAV9s/UoSgAPC2+VM lDMqFSyHZh594Ja6faVj6peV7DsLSWUcqMuXwyaf0UHPWleJiXEQd/aeFKiryKPOCk3L upN5OOisHESJPNk6Tzt2Vs2sxTtCF2w5Mdukf2Sk8zQHLBwOY0rwNSj6BlSZ+eYBPznT 2zq4n/Ihb/uiMO3TnbDNMm1V0gg/8C92MyzBbBwvznbsSS56ga71R6yHv2fR3maDSRqX Jz3pUG8RLmZP9YlHsLFGaFId4ONL19Ig9wK5Yj6HIrx/yPrwszFmL/hZmN/SV83WVWak lplg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=WsvVZksvBcfyQdZtqLMfFeZiWFmRxPCvv/DTgHSzgnU=; b=RsGIlhBRgxVRDatlCIycbgmrN5kPapwXBR6hwT7PrIF/1T847lWrRHAuSPGMZuW3ni fsMPkvYx63xASe99KclhRZJxvrHzcIA6D5/J270M44KM7MVH/B1/BedGKX7gIXFmw5bz BR8V53HbFIw50UCpKmTbfOFNEVP3XQTSrebvp50SUhSYfAv5XTKVRqqkwdW5LOwHzY1P /ppMt4grqouzlir5UAjLV1OkVLzI9faG2icFALqfODiLbPXg1LyB3Xzxe6+oH4NGKj9a alxmOJKrcKkXRyQG3CFV1fedVI5V/h0HJbT6rAx9qZsNVgxTxjHh2UmT2zoQ/pZaJhws ETow== X-Gm-Message-State: APjAAAWai2tIJIFOZnN+Obl+IbTPSPH30KOpeoAH+iDpD7IliJAXN0w0 wiHcC4E71qfW1XrrCDeZQRTS41Mj X-Google-Smtp-Source: APXvYqxa7opnBYrFJN2G+o9Xxyhvi0x1yn6+aAnNNhZCGsSCg/u+g+xm96etM+vZxmFb33FtSoqXMA== X-Received: by 2002:a24:9a83:: with SMTP id l125mr690672ite.59.1553203507028; Thu, 21 Mar 2019 14:25:07 -0700 (PDT) Received: from ?IPv6:2607:fea8:69f:f5eb:fc5f:12b:d173:619a? ([2607:fea8:69f:f5eb:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id 187sm386898itl.27.2019.03.21.14.25.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Mar 2019 14:25:06 -0700 (PDT) To: John Mattsson , core References: From: Rene Struik Message-ID: Date: Thu, 21 Mar 2019 17:25:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [core] Choice of signature Algorithm(s) in Group OSCORE 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, 21 Mar 2019 21:25:10 -0000 Hi John: A few remarks: 1) Point decompression with the P-224 NIST curve is somewhat harder (due to the prime field p=2^224-2^96+1 used). As a result, if one wishes to "ship" a compressed point (to save bytes), one needs more complicated code for point compression. 2) BSI suggests that the curve should have bit-size at least 250 [1], so if one wishes to deploy in regulatory regimes where BSI stamps of approval are required one should take that into account. 3) Lots of internet drafts use ECDH or ECDSA with the P-256 NIST curve. 4) Reusing existing high-quality code that has been carefully designed to withstand implementation attacks for one curve may allow a more economical way of development and maintenance than providing this same functionality for multiple curves. In short: I think venturing off into this direction is not necessarily the wisest move. Best regards, Rene == Ref: [1] BSI - Technical Guidance TR-02102-1 (Kryptographishe Verfahren, Empfehlungen and Schussellangen (February 22, 2019) On 3/21/2019 5:08 PM, John Mattsson wrote: > I think we need some more discussion of which signature algorithms to use. Candidates would be: > > Algorithm Signature size Security level > ECDSA secp224r1 (P-224) 56 bytes 112 > ECDSA secp256r1 (P-256) 64 bytes 128 > ECDSA secp256k1 64 bytes 128 > Ed25519 64 bytes 128 > > The CFRG review of EDHOC brought up the qeustion if not P-224 would be a better choice if the main goal is to get smaller messages. ECDSA with P-224 has the obvious advantage of having signatures that are 8 bytes shorter. > > 112-bit security is according to NIST ok to use until 2030. > > ECDSA wih P-224 is significantly faster than ECDSA with P-256, around 2/3 the number of operations/time. secp256k1 is around 300 % faster than secp256r1. Harder to find comparisions with Ed25519. Most of the speed will depend on the curve, but EdDSA (Schnorr) also have other advantages that speed up signing compared to ECDSA. Ed25519 verify is likely at least as fast as ECDSA with P-224 on all platforms and significantly faster for signing on all platforms. On some platforms I think Ed25519 is significantly faster also for verification. > > In terms of number of implementation, I think ECDSA with P-256 in is the lead, with ECDSA P-224 as second, and Ed25519 in last place. > > I am leaning towards that P-224 should probably be supported (then ES224 need to be standardized in COSE). The other three are already registered for COSE. The harder question is which should be MTI. Several people have stated that latency is of uthermost importance, in case the current choice of Ed25519 as MTI is likely the correct choice. > > A good but a little bit dated comparision of different algorithms on ARM processors: > https://datatracker.ietf.org/meeting/92/materials/slides-92-lwig-3 > > The choice also depends on if there are fast implementations available. Assembly optimized version of the NIST curves is likely as fast or faster than a curve25519 implementation written in C. > > https://github.com/kmackay/micro-ecc has very fast implementations (for ARM) of ECDH and ECDSA with secp160r1, secp192r1, secp224r1, secp256r1, and secp256k1. I cannot find anything similar for EdDSA. > > Cheers, > John > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Thu Mar 21 14:46:19 2019 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 29345131111 for ; Thu, 21 Mar 2019 14:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7n-A4u0L5Wx for ; Thu, 21 Mar 2019 14:46:15 -0700 (PDT) Received: from sonic301-28.consmr.mail.gq1.yahoo.com (sonic301-28.consmr.mail.gq1.yahoo.com [98.137.64.154]) (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 CDE421310EE for ; Thu, 21 Mar 2019 14:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1553204775; bh=15E9Dj7VpYf7/IsmI68t7V5lb677F2Lc6LQXQFK+IaE=; h=Date:Subject:From:To:From:Subject; b=rifFhU2mNYtGV7FLLYqDT7EpzH8aDMzDfunvDvY3NIq0ckN4vadIAmWpkhV/EFGyjlUAsZarXLpWdLb26O/oqWi/0wwfzlbKOFa8Owbt7pXzZm1R+s43sEseZta0iB9Q8YQix/jsn1cHkzvrIQC6Jpl9oaZJWJsGvtI+RL8hl7i0wKEzcASB1K8BSmAlLHyIclUi9NRxmkjvluSoCxRmsnClsKhQBq7Xgeaq0SBwh6vg9BmJIZKmGjdAgFHRyTpUB8DWsil/TrpAsTDWFibHMC6RGSDYO1ZMV5jFbLBSXYVmO6v41NJwCo4yWqliATgpVLHZtaheXWtNOnOPU6pYvA== X-YMail-OSG: WT9GZHAVM1lrfSa9K3dVn6thU7h.jSZ6yzqrZxGCb7Dv9sJnUFaNqPoiAxBIqQe rPrQBe.cbmhrniiXbWk1VI1WDeQaWrlg4wxRyAkjyzBI60w5sXop_WV_fdPVVJoMKfi6cUTn.7gL 4oFKyDhcRjrd6OwKYMVx2D_livQ2uYkw0NA38FuIsub35i.Pytxov5FiWWIAfITPpIt303IRHEzk HwqfssF.7_sSPbxWQ1p1H_de4ZYLL8qOUN5qoR.QCTTOoZHr_eT.otMwKjQp3LknPGEtFAJqZCnn kWXk4NfJYGKDCG5ecc2LqeAOFBA9yELV7dp3zInbdTmytIy4WS4zYcXZXBcGGR_0HNkDdaPP6we6 4HUGQtxjBpXY0.k1f54oMHWQbJn8cMZGh.Th.sw_7Sey70lM74VyZ1kzmrYMcCXFB1uqEWpd0krd Q_yDpFmK18KwdDG7eYwy4sPT.iMNdUDzD9i4.92ys6uR0MWsnAfxzX7uvmq_eCGV3dGOGkt7y_6S p8nSbQnyzwbv_kQJuNILA7qKtroedaA5mgrYkpkGVCvsD3cwjD8EgZNs5FP9VwP32KLdxM4QBhNF TP5luhMtvq6WvAo4lXzLMpuDHFP7fBNvAN01.9FPTSet.8nDBzMPPCyYMKx89gBzl0UfZQctCKvG vTohkIZpDrMIRFPF2zWC4hFNB_GDR0xK6y5EuBL4Z7EG5olETmGcYj2_xASN7uPtTegGFFj.hfUI R41.d25IfOWrbWx91X42VpA7xRePCkM1lKpPVzmcPe5K669zpaa_q56lh033qjmiaEJU7P88n7py jnQW4yKdpwu2eLRDwOGtJTjNHLUbLj02vwxU9VD6Y7XkRwxVrE6OvHWMffesKBkTs.Yux90sLujk Mb9K9AlQbqjBk7uac61feWT_jl3nGenJNaGo9lmn4vfAU6CTdFqGks5pyg0O.LeJ_30ZfOm0joxI a8CNQaJ1I3MucjYy1SUcPwVNowCEkBNJTJjvOUn.7uxXTby1BpbtQc81DqLcLTWAfN.0vN3grXqE 2KesjsDgwr2DEwEk0Kfc663ksugGehWOvrjzW_eSOSDazQZ8Sr1MyvkUQrepjnBICtYgOrhqZimO kFG1k97uRp30P8xbk8cRTpda8Oxk- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 21 Mar 2019 21:46:15 +0000 Received: from 67.159.150.85 (EHLO [192.168.1.2]) ([67.159.150.85]) by smtp405.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9781d6a7d97a409de8bd6f19fcd9bb28; Thu, 21 Mar 2019 21:46:12 +0000 (UTC) User-Agent: Microsoft-MacOutlook/10.16.1.190220 Date: Thu, 21 Mar 2019 14:46:09 -0700 From: Mehmet Adalier To: John Mattsson , core Message-ID: <8CE1C6CC-3D3A-4D8A-ABA7-600EC42A7ED1@antarateknik.com> Thread-Topic: [core] Choice of signature Algorithm(s) in Group OSCORE Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [core] Choice of signature Algorithm(s) in Group OSCORE 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, 21 Mar 2019 21:46:18 -0000 John, My suggestion is to stay with the ECDSA secp256r1 curve. It is safer (128-b= it strength) and fast implementations do exist. See 1. Here are perf numbers using our taraCRYPT(tm) engine on ARM64 A53 (1.2GHz).= =20 ECC-P256 Keygen: 6,269 Ops/sec; ECC-P256 Sign: 5,987 Ops/sec; ECC-P256 Veri= fy: 3,288 Ops/sec And on late generation 3.8GHz X86.. ECC-P256 Keygen: 85,631 Ops/sec; ECC-P256 Sign: 73,706 Ops/sec; ECC-P256 Ve= rify: 59,530 Ops/sec The ARM port can be further optimized.=20 As a reference, we have implemented an adaptation of CoAP over the Bundle P= rotocol for space use. We utilize ECDSA secp256r1. for a summary see 2. 1. M. Adalier, =E2=80=9CEfficient and Secure Elliptic Curve Cryptography Implemen= tation of Curve P-256,=E2=80=9D NIST Workshop on Elliptic Curve Cryptography Stand= ards, June 11, 2015 2. M. Adalier, S. Burleigh, "Cross-domain Autonomous Communication Protocol= for Delay Tolerant Networks," NAECON 2018, Proceedings of the IEEE 2018 Nat= ional Aerospace and Electronics Conference: Dayton, OH, July 2018 Best, Mehmet Adalier Antara Teknik LLC =EF=BB=BFOn 3/21/19, 2:09 PM, "core on behalf of John Mattsson" wrote: I think we need some more discussion of which signature algorithms to = use. Candidates would be: =20 Algorithm Signature size Security le= vel ECDSA secp224r1 (P-224) 56 bytes 112 ECDSA secp256r1 (P-256) 64 bytes 128 ECDSA secp256k1 64 bytes 128 Ed25519 64 bytes 128 =20 The CFRG review of EDHOC brought up the qeustion if not P-224 would be = a better choice if the main goal is to get smaller messages. ECDSA with P-22= 4 has the obvious advantage of having signatures that are 8 bytes shorter. =20 112-bit security is according to NIST ok to use until 2030. =20 ECDSA wih P-224 is significantly faster than ECDSA with P-256, around 2= /3 the number of operations/time. secp256k1 is around 300 % faster than secp= 256r1. Harder to find comparisions with Ed25519. Most of the speed will depe= nd on the curve, but EdDSA (Schnorr) also have other advantages that speed u= p signing compared to ECDSA. Ed25519 verify is likely at least as fast as EC= DSA with P-224 on all platforms and significantly faster for signing on all = platforms. On some platforms I think Ed25519 is significantly faster also fo= r verification. =20 In terms of number of implementation, I think ECDSA with P-256 in is th= e lead, with ECDSA P-224 as second, and Ed25519 in last place. =20 I am leaning towards that P-224 should probably be supported (then ES22= 4 need to be standardized in COSE). The other three are already registered f= or COSE. The harder question is which should be MTI. Several people have sta= ted that latency is of uthermost importance, in case the current choice of E= d25519 as MTI is likely the correct choice. =20 A good but a little bit dated comparision of different algorithms on AR= M processors: https://datatracker.ietf.org/meeting/92/materials/slides-92-lwig-3 =20 The choice also depends on if there are fast implementations available.= Assembly optimized version of the NIST curves is likely as fast or faster t= han a curve25519 implementation written in C. =20 https://github.com/kmackay/micro-ecc has very fast implementations (for= ARM) of ECDH and ECDSA with secp160r1, secp192r1, secp224r1, secp256r1, and= secp256k1. I cannot find anything similar for EdDSA. =20 Cheers, John =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 From nobody Fri Mar 22 01:25:17 2019 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 BC841130DEA for ; Fri, 22 Mar 2019 01:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=PHvgCJba; dkim=pass (1024-bit key) header.d=ericsson.com header.b=YHYVn6te Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DBZA5Sc5siQ for ; Fri, 22 Mar 2019 01:25:08 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDA0130EC0 for ; Fri, 22 Mar 2019 01:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1553243105; x=1555835105; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bN3o7oO56yuWubt1IPTooXufF5rpmVS8EaLSv8e5zPg=; b=PHvgCJbaRe1RBpHF4W5AoQ+653TKDZ9HfAONSxLcxzpd7Q+TDLSk/2xjTjr1u8wz 0R/rivqvKtQRi+CrQWQE971TKg+xvhRxNX0LnLFf2iT7/Qo1v/ddpcG7zygtxzdI V1OtBJoOFFMlBPHxngNXmZYBOAOrYy+8ZU1e21pi7tE=; X-AuditID: c1b4fb3a-02fff70000001645-0e-5c949be18057 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D6.1D.05701.1EB949C5; Fri, 22 Mar 2019 09:25:05 +0100 (CET) Received: from ESESSMR504.ericsson.se (153.88.183.126) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 22 Mar 2019 09:25:05 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMR504.ericsson.se (153.88.183.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 22 Mar 2019 09:25:05 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Fri, 22 Mar 2019 09:25:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bN3o7oO56yuWubt1IPTooXufF5rpmVS8EaLSv8e5zPg=; b=YHYVn6te5EMVkM+n4RLz5DdSU07iHf8vl5O6D77GjmcRqgOeLsYmXa31H81yJuKqTJnDA31r5o0wb5+UAoli9rB469aUgzxhntAQJXq6BVaOTBp26cct9S8Y2/HtCaaoYGc3TFzqtmFM6nqqO4uKJ3MLaK2XuWlfid91M3ROdcM= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2410.eurprd07.prod.outlook.com (10.168.128.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.11; Fri, 22 Mar 2019 08:25:03 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d%6]) with mapi id 15.20.1730.013; Fri, 22 Mar 2019 08:25:03 +0000 From: Francesca Palombini To: Carsten Bormann CC: "core@ietf.org" , Ace Wg Thread-Topic: [core] Pub Sub and multicast Thread-Index: AQHU3/siSpHHSsIZz0arCk9g1aR/4qYWP2OAgAEi6IA= Date: Fri, 22 Mar 2019 08:25:03 +0000 Message-ID: References: <1CA68BFD-B585-4CB0-9303-7E2A6FC2B005@ericsson.com> <2A2E572D-D00C-443B-B42D-CC6C9500474D@tzi.org> In-Reply-To: <2A2E572D-D00C-443B-B42D-CC6C9500474D@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 30ddee02-f23c-436a-782f-08d6ae9fe242 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2410; x-ms-traffictypediagnostic: HE1PR0701MB2410: x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(39860400002)(346002)(396003)(376002)(189003)(199004)(8676002)(99286004)(44832011)(4744005)(68736007)(446003)(76176011)(14454004)(256004)(229853002)(66066001)(14444005)(3846002)(6116002)(6916009)(97736004)(26005)(11346002)(186003)(6246003)(4326008)(6512007)(102836004)(53936002)(71190400001)(71200400001)(36756003)(54906003)(316002)(81166006)(8936002)(82746002)(81156014)(83716004)(486006)(25786009)(105586002)(106356001)(2616005)(476003)(5660300002)(33656002)(305945005)(6486002)(7736002)(6506007)(86362001)(478600001)(2906002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2410; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wraHTak2RcD4Bqy1vNraA7O2aqleaZNdysgLYWGAnDjgvttSpEg9ASvaFmVIWPRQhEh4IHjO95HEMGoux7M0amRLOEOeBIv/JN53jTXJnrdQ+1ttbXFMy3kbGkxLvqfNm2KVGhkhz1BN2eTjt0pD0fcWaUEiluENtijiash0tA7MtoswcgFcAdHjdEDxmXl+/ufsEUQRvvmeWzMJfM66FgExoLHpw5GXfLbXPiRq0ku7HF4DhzQDk3Zxo5WpsigQahT04vgostpSxLGBBrcTgGo/1037JgXnzMq+RYGfLzM8p5Is8naIThXANdZF0O9lk6+4xAaFHjGxHoOupFduVD5BcMrOOeQ144dCpzioxPAI1D1RvQW9TEkY8c2ncLrE79KPJWrHTbsLDDHIliz0gKryt0einhe52aYzdcXlUFo= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 30ddee02-f23c-436a-782f-08d6ae9fe242 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 08:25:03.6842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2410 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUyM2J7le7D2VNiDPpmq1p8/9bDbHFkyl1W i31v1zM7MHssWfKTyWPaoswApigum5TUnMyy1CJ9uwSujFXfgwuecFU0nXFrYDzA1cXIySEh YCIxo2c7YxcjF4eQwBFGia1n/7FCON8YJc6v/sYC5/Qem8oO4Sxhkjiz/DxYhkVgArPE4wen oDIzmCT2rDvMBuE8Y5RYu7ePEWQNm4CNxIWH71lBbBEBJYkLF9ewgdjMAlYS3x6BdHNyCAto Sny+spUFokZLYuGxHWwQtpVE//YzYDUsAqoSPy8vA4vzCthLfFm8HGymkECBxJ87f8B6OQWs JVb/3MUEYjMKyEp8aVzNDLFLXOLWk/lMEG8LSCzZc54ZwhaVePn4HytEfbLEldt97BBxZYn3 F04zQtiyEpfmd0PZvhKbP10Fe19C4DajxMpTO9kgEjoSu/qPQTXnS1y5fxMqLiPRdHAGK4T9 nFXi4TIhiKNTJZavbWWcwKg3C8l9sxg5gGxNifW79CHCHhLXNx1ng7AVJaZ0P2SfBfa+oMTJ mU9YFjCyrmIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQITCsHt/y22sF48LnjIUYBDkYlHl7v mikxQqyJZcWVuYcYJTiYlUR4d0VPjhHiTUmsrEotyo8vKs1JLT7EKM3BoiTO+0dIMEZIID2x JDU7NbUgtQgmy8TBKdXAWHkk9kStzq4FO7miG/fkiEzw3+HKkPjBuDz9osO3EpWnStr3Qztf /vgiu3DNBI+ZH/vKyrUWB0W1erhvDHtXmKVwddfP1FKR/Rfu+kh/W6b88WLurBdx+9Zuvf1K +WEK/4nLm+V/rH/fuPtEqXJTKecV7tVnT61L/1d/fILCG4HTV5wulP599laJpTgj0VCLuag4 EQDatnz8JwMAAA== Archived-At: Subject: Re: [core] Pub Sub and multicast 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, 22 Mar 2019 08:25:10 -0000 SGkgQ2Fyc3RlbiwNCg0KWWVzLCB0aGUgcGhyYXNpbmcgaXMgbm90IGdvb2Qgb24gdGhhdCBzbGlk ZS4uLiBJZiB5b3Ugbm90aWNlLCB0aGUgInByb3Bvc2FscyIgYWZ0ZXJ3YXJkIHBvaW50IHRvIGEg Z2VuZXJhbCAiRG9TIHByb3RlY3Rpb24gbWVjaGFuaXNtIi4gSG93IHRoYXQgaXMgZG9uZSByZWFs bHkgZGVwZW5kcyBvbiB0aGUgdG9vbHMgYXZhaWxhYmxlLCBmb3IgZXhhbXBsZSB0aGUgYnJva2Vy IG1pZ2h0IG9ubHkgc2VuZCBub3RpZmljYXRpb25zIHRvIHN1YnNjcmliZXJzIHRoYXQgaGF2ZSBi ZWVuIGFkZGVkIHRvIGFuIE9TQ09SRSBncm91cCwgYnV0IGVjaG8gaXMgZGVmaW5pdGVseSBhbm90 aGVyIHdheSBvZiBkb2luZyB0aGF0Lg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0K77u/T24gMjEv MDMvMjAxOSwgMTc6MDQsICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+IHdyb3RlOg0K DQogICAgSeKAmW0gY2VydGFpbmx5IGludGVyZXN0ZWQuDQogICAgDQogICAgTm90IHN1cmUgSSB1 bmRlcnN0YW5kIOKAnAnigKIgQWRkaXRpb25hbGx5LCB0aGUgU3Vic2NyaWJlciBtdXN0IGJlIGF1 dGhvcml6ZWQgdG8gc3Vic2NyaWJlLCBvdGhlcndpc2UgYW4gYXR0YWNrZXIgY291bGQgRG9TIGV4 dGVybmFsIG5vZGVzIHRoYXQgZG8gbm90IHdhbnQgdG8gcmVjZWl2ZSB0aGUgcHVibGljYXRpb25z 4oCdLiAgV2hldGhlciB0aGUgYXR0YWNrZXIgaXMgYXV0aG9yaXplZCB0byBzdWJzY3JpYmUgYW5k IHdoZXRoZXIgdGhlIGFjdHVhbCBub3RpZmljYXRpb24gcmVjZWl2ZXIgaXMgaW50ZXJlc3RlZCBp cyBraW5kIG9mIG9ydGhvZ29uYWwuDQogICAgDQogICAgR2VuZXJhbGx5LCB3ZeKAmWQgbmVlZCBh IHdheSB0byBwcm92ZSBhZGRyZXNzIG93bmVyc2hpcCBmb3Igc2V0dGluZyB1cCBvYnNlcnZhdGlv biBpbnRlcmVzdC4gIFRoZSBFY2hvIG9wdGlvbiBjYW4gYmUgdXNlZCBmb3IgdGhhdOKApg0KICAg IA0KICAgIEdyw7zDn2UsIENhcnN0ZW4NCiAgICANCiAgICANCg0K From nobody Fri Mar 22 05:43:01 2019 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 60A6A1277C9; Fri, 22 Mar 2019 05:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMh_mvN-eVlU; Fri, 22 Mar 2019 05:42:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C26D126D00; Fri, 22 Mar 2019 05:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4639; q=dns/txt; s=iport; t=1553258570; x=1554468170; h=from:to:subject:date:message-id:mime-version; bh=16fXKugIl+GfiSQgcYAbomxdQWHvRxZwiFi7NQJKVPQ=; b=YJ3+t7Or5mUlz2uiGYKULUmdt7om9dSqESnyrXRQKUf/J1V9fotPADEz frvzQPlYdX7y4vQhyRZGs6sjbPkETOLoi198NriFxkC1t5dozmMqeWrMz WOVx5O/p9x3X2sZRoE00Moqtej7KH6SWIw6gi+i1npGa+SFM0lssB+wDS w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAABm15Rc/5RdJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGBDoECaIEDMZc/lE6Hcg0BAYlqIjcGDQEBAwE?= =?us-ascii?q?BCQEDAm0ohX5eAYEAJgEEARqDG4ERZKsFijKBLwGLMReBQD+BEY11A4o1hlO?= =?us-ascii?q?UBQkCky4hk3yLGJMkAhEVgS41IiiBLnAVgyiQSkGOEoEfAQE?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208,217";a="453476679" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2019 12:42:48 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x2MCgmO7012903 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2019 12:42:48 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 07:42:48 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 22 Mar 2019 07:42:48 -0500 From: "Rob Wilton (rwilton)" To: "core@ietf.org" , "netconf@ietf.org" Thread-Topic: YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87Vg== Date: Fri, 22 Mar 2019 12:42:47 +0000 Message-ID: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.76.6] Content-Type: multipart/alternative; boundary="_000_6235c6683ff14848a661f8b8cec94280XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [core] YANG encoding in CBOR 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, 22 Mar 2019 12:42:53 -0000 --_000_6235c6683ff14848a661f8b8cec94280XCHRCD007ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As part of YANG evolution discussion, that was some talk about using a bina= ry encoding of YANG in NETCONF or RESTCONF. CBOR looks like a good fit for this, and obviously CORE WG are working on d= raft-ietf-core-yang-cbor-07, but one comment came up from Andy that the CBO= R encoding of YANG cannot handle all YANG data models. In particular, beca= use of the way that the encoding works there are limitations on how unions = of enums work. Is that still the case? Hence I was wondering whether it would be better to encode enum values in C= BOR using module-qualified names, or also assign them SIDs and use the SIDs= . Has this approach been considered at all? Or, is there an alternative approach to how we could/should consider using = CBOR as a binary encoding for YANG data in NETCONF or RESTCONF? Do you think it would be possible to get interested parties together to dis= cuss this at some point in Prague? Thanks, Rob --_000_6235c6683ff14848a661f8b8cec94280XCHRCD007ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As part of YANG evolution discussion, that was some = talk about using a binary encoding of YANG in NETCONF or RESTCONF.

 

CBOR looks like a good fit for this, and obviously C= ORE WG are working on draft-ietf-core-yang-cbor-07, but one comment came up= from Andy that the CBOR encoding of YANG cannot handle all YANG data model= s.  In particular, because of the way that the encoding works there are limitations on how unions of enums w= ork.  Is that still the case?

 

Hence I was wondering whether it would be better to = encode enum values in CBOR using module-qualified names, or also assign the= m SIDs and use the SIDs.  Has this approach been considered at all?

 

Or, is there an alternative approach to how we could= /should consider using CBOR as a binary encoding for YANG data in NETCONF o= r RESTCONF?

 

Do you think it would be possible to get interested = parties together to discuss this at some point in Prague?

 

Thanks,
Rob

 

--_000_6235c6683ff14848a661f8b8cec94280XCHRCD007ciscocom_-- From nobody Fri Mar 22 08:45:39 2019 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 07CB31310A8; Fri, 22 Mar 2019 08:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRyd6FD68k0y; Fri, 22 Mar 2019 08:45:34 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820118.outbound.protection.outlook.com [40.107.82.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402D01310AE; Fri, 22 Mar 2019 08:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zpDojyMD0CmH4rudlXA9iwXvS2DJbH/e6EwbjArTXSA=; b=xX8mBn0R5+7ThCAX6UV/rsF8x8IyWqNKAPovOdPHfRWa1qqCK3VHQjj0vkNF5hWeovPa8tSm3FFYeZp7XM8jKl4RyV/bqVd/LX/Mg735BIP1rVTp4HGmSgha6XwSQ/fqaZU1DoJ+Izi4mqvCucezf8mH7ZnPHbuwfr7Syf169Is= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4609.namprd06.prod.outlook.com (20.177.145.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Fri, 22 Mar 2019 15:45:27 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d%3]) with mapi id 15.20.1730.017; Fri, 22 Mar 2019 15:45:27 +0000 From: Michel Veillette To: "Rob Wilton (rwilton)" , "core@ietf.org" , "netconf@ietf.org" Thread-Topic: YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQ Date: Fri, 22 Mar 2019 15:45:27 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> In-Reply-To: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 26a46e2e-c34c-40cb-35fc-08d6aedd6837 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4609; x-ms-traffictypediagnostic: BL0PR06MB4609: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(39850400004)(376002)(366004)(199004)(189003)(110136005)(68736007)(9686003)(2906002)(606006)(6246003)(71200400001)(99286004)(53936002)(476003)(26005)(71190400001)(316002)(11346002)(7696005)(5660300002)(3846002)(478600001)(446003)(6116002)(53546011)(97736004)(186003)(76176011)(6506007)(790700001)(102836004)(8936002)(486006)(7736002)(74316002)(25786009)(86362001)(52536014)(33656002)(2201001)(81166006)(6306002)(229853002)(72206003)(966005)(2501003)(55016002)(8676002)(6436002)(106356001)(54896002)(256004)(66066001)(3480700005)(105586002)(236005)(14454004)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4609; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HK6m1mIEdcft0HAw/nxyNQDgKkPCj8ZfYjTSIn7v6X2XsMrrqxFTA2x8DI8eue0XQdwmdSCZfb8ythShE1bJkgxxkJ9kzvWDBoTRX7mlAavn1qCbRCG4m2ISbaU0U/Aune/7jaE2KrHbHCBLSfqfpVIi7FD8LIPLwkBg4/OjMT3w2AxD+Z7e17AY9QkyncOiuYlTaWpGTCbZqAV7t4MOivM26bCabCp4XFa7Y7BJA8fqBOvT1B5OfRaOJ3m0oP/6lGVN+AHNkvRZSK/t+REC5oz63o4ri6wYgmVv9gM3ScP+HcrCoPBaUTaSR4aae3Dlf80lhfsqwcVv/P1+6lOi2tCzdSl0RTfUaMSO5NymSZxeSt+sFgLjpmuCsoeuAfFIzpRp912/0im7Gm5Puq3yVvSHHrdR8W+8TSMzIKxI8oE= Content-Type: multipart/alternative; boundary="_000_BL0PR06MB5042823429DB7CDA0F33408B9A430BL0PR06MB5042namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 26a46e2e-c34c-40cb-35fc-08d6aedd6837 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 15:45:27.7216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4609 Archived-At: Subject: Re: [core] YANG encoding in CBOR 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, 22 Mar 2019 15:45:37 -0000 --_000_BL0PR06MB5042823429DB7CDA0F33408B9A430BL0PR06MB5042namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About "I was wondering whether it would be better to encode enum values ...= " YANG assigns either explicitly or implicitly to each enumeration, a unique = integer value, see https://tools.ietf.org/html/rfc7950#section-9.6.4.2. In CBOR, these values are used, see https://tools.ietf.org/html/draft-ietf-= core-yang-cbor-07#section-6.6 When used outside of a union, I don't see any issues with those values. Andy, do you have a specific example for which, the current encoding is amb= iguous? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The encoding of union is defined in: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section-6.12 Currently, each YANG datatype in a union is encoded differently to avoid an= y ambiguities between them. For example, integer 4 is encoded as: 04 # unsigned(4) enumerator value 4 is encoded as (assuming the allocated tag is 99): D8 63 # tag(99) 04 # unsigned(4) The list of these encoding is shown below: - unsigned integer --> CBOR unsigned integer - integer --> CBOR unsigned integer, CBOR negative integer - enumeration --> CBOR tag - identityref as SID --> CBOR tag - string --> CBOR text string - identityref as name --> CBOR tag - bits --> CBOR tag - binary --> CBOR byte string - decimal64 --> CBOR tag 4 - boolean --> CBOR simple value The only potential problem I aware is when multiple enumerations are part o= f the same union. Value 4 from enumeration A will be encoded the same way as Value 4 from enu= meration B. Is it a real problem is proactive? If so, how this can be resolved? I won't be present at the Prague meeting, but I'm certainly available to di= scuss this topic by email. I will be present at the Montreal meeting for any remaining discussions on = this draft. Note: I'm currently updating the draft to remove any dependencies with RFC = 7951, to resolve a comment sent by Andy. Regards Michel From: core On Behalf Of Rob Wilton (rwilton) Sent: Friday, March 22, 2019 8:43 AM To: core@ietf.org; netconf@ietf.org Subject: [core] YANG encoding in CBOR Hi, As part of YANG evolution discussion, that was some talk about using a bina= ry encoding of YANG in NETCONF or RESTCONF. CBOR looks like a good fit for this, and obviously CORE WG are working on d= raft-ietf-core-yang-cbor-07, but one comment came up from Andy that the CBO= R encoding of YANG cannot handle all YANG data models. In particular, beca= use of the way that the encoding works there are limitations on how unions = of enums work. Is that still the case? Hence I was wondering whether it would be better to encode enum values in C= BOR using module-qualified names, or also assign them SIDs and use the SIDs= . Has this approach been considered at all? Or, is there an alternative approach to how we could/should consider using = CBOR as a binary encoding for YANG data in NETCONF or RESTCONF? Do you think it would be possible to get interested parties together to dis= cuss this at some point in Prague? Thanks, Rob --_000_BL0PR06MB5042823429DB7CDA0F33408B9A430BL0PR06MB5042namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rob

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

About "I was wondering whether it would be better to encode enum values= …"

 

YANG assigns either explicitly or implicitly to each= enumeration, a unique integer value, see https://tools.ietf.org/html/rfc7950#section-= 9.6.4.2.

In CBOR, these values are used, see https://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section= -6.6

When used outside of a union, I don't see any issues= with those values.

Andy, do you have a specific example for which, the = current encoding is ambiguous?

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The encoding of union is defined in:

https://tools.ietf.org/html/draft-ietf-core-y= ang-cbor-07#section-6.12

 

Currently, each YANG datatype in a union is encoded = differently to avoid any ambiguities between  them.

For example, integer 4 is encoded as:

 

04 # unsigned(4)

 

enumerator value 4 is encoded as (assuming the alloc= ated tag is 99):

 

D8 63 # tag(99)

   04 # unsigned(4)

 

The list of these encoding is shown below:

- unsigned integer --> CBOR unsigned integer=

- integer --> CBOR unsigned integer, CBOR negativ= e integer

- enumeration --> CBOR tag <TBD>=

- identityref as SID --> CBOR tag <TBD>

- string --> CBOR text string

- identityref as name --> CBOR tag <TBD>

- bits --> CBOR tag <TBD>

- binary --> CBOR byte string

- decimal64 --> CBOR tag 4

- boolean --> CBOR simple value

 

The only potential problem I aware is when multiple = enumerations are part of the same union.

Value 4 from enumeration A will be encoded the same = way as Value 4 from enumeration B.

 

Is it a real problem is proactive?

If so, how this can be resolved?

 

I won't be present at the Prague meeting, but I'm ce= rtainly available to discuss this topic by email.

I will be present at the Montreal meeting for any re= maining discussions on this draft.

 

Note: I'm currently updating the draft to remove any= dependencies with RFC 7951, to resolve a comment sent by Andy.<= /p>

 

Regards

Michel

 

 

From: core <core-bounces@ietf.org> O= n Behalf Of Rob Wilton (rwilton)
Sent: Friday, March 22, 2019 8:43 AM
To: core@ietf.org; netconf@ietf.org
Subject: [core] YANG encoding in CBOR

 

Hi,

 

As part of YANG evolution discu= ssion, that was some talk about using a binary encoding of YANG in NETCONF = or RESTCONF.

 

CBOR looks like a good fit for = this, and obviously CORE WG are working on draft-ietf-core-yang-cbor-07, bu= t one comment came up from Andy that the CBOR encoding of YANG cannot handl= e all YANG data models.  In particular, because of the way that the encoding works there are limitations on how un= ions of enums work.  Is that still the case?

 

Hence I was wondering whether i= t would be better to encode enum values in CBOR using module-qualified name= s, or also assign them SIDs and use the SIDs.  Has this approach been = considered at all?

 

Or, is there an alternative app= roach to how we could/should consider using CBOR as a binary encoding for Y= ANG data in NETCONF or RESTCONF?

 

Do you think it would be possib= le to get interested parties together to discuss this at some point in Prag= ue?

 

Thanks,
Rob

 

--_000_BL0PR06MB5042823429DB7CDA0F33408B9A430BL0PR06MB5042namp_-- From nobody Fri Mar 22 09:08:28 2019 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 DF05B13119A; Fri, 22 Mar 2019 09:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 kmk-N-Jis68w; Fri, 22 Mar 2019 09:08:25 -0700 (PDT) Received: from smtp.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 ECB1413117D; Fri, 22 Mar 2019 09:08:24 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44QpVG4gXKzyqr; Fri, 22 Mar 2019 17:08:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Fri, 22 Mar 2019 17:08:20 +0100 Cc: "Rob Wilton (rwilton)" , "core@ietf.org" , "netconf@ietf.org" X-Mao-Original-Outgoing-Id: 574963698.633944-551f0089e61a74a3cc3522d0d5977c73 Content-Transfer-Encoding: quoted-printable Message-Id: <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> To: Michel Veillette X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 22 Mar 2019 16:08:27 -0000 On Mar 22, 2019, at 16:45, Michel Veillette = wrote: >=20 > The only potential problem I aware is when multiple enumerations are = part of the same union. > Value 4 from enumeration A will be encoded the same way as Value 4 = from enumeration B. =E2=80=A6 and that is not a problem for the XML version, because the = string is being used instead of the value. (But then if two = enumerations share a string, you have the equivalent problem in the XML = serialization.) Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actually = has this problem, so I would be a bit reluctant to make CBOR-based = implementations more complex (and less efficient) so solve this = (non-?)problem. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 22 09:38:14 2019 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 B9049131273 for ; Fri, 22 Mar 2019 09:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnncGzjBvBhv for ; Fri, 22 Mar 2019 09:38:03 -0700 (PDT) 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 8676713126F for ; Fri, 22 Mar 2019 09:38:02 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id q66so2594803ljq.7 for ; Fri, 22 Mar 2019 09:38:02 -0700 (PDT) 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=XbV+v0F4IWhHYrZLR1LxIz8hjL3gK1t4DnGZMzQqnlE=; b=ueOc43Hxjwr37UTVgJNCeWc7guqlZN6yFMaho0H5iVHYiX2ghbGZFYQMzYcuwjElha VsX80ebkxAK6Zgc0Vgd08+77JILTBImMHZL75omvo1gHs+SmivWKOldr+ec5j51Ja4HR jO06Pc7gkSRT/8yAxUIjIuxByoxeGoTg1CaPEDk1xPccqX0MpwPjS8OSpXRUgJWtA9cD Va3JWtXYRHMb0Z0FI6adlsphWderhEHHXC4bc6Zn3bC6znFSJVGUw/TkzLK5VGM71/Sv HSPq5KOZ1MnNr+MNs//+tqJCLbjQYOWpTuCnMQNCYc62qyy4d+mzk6BcTPbQS04vpW+d KLfQ== 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=XbV+v0F4IWhHYrZLR1LxIz8hjL3gK1t4DnGZMzQqnlE=; b=hP6j6k3zj5RjgJgG5ZP2G7BZ+TvLzI2hdTNf5QaKAROPvSuUexz2Tf1DRvsbg2Aue0 JJyyPRviNgeYsbnGwnuvb/GFVyZkM7n0Zg9jrT8kH10EXrCBc3VmzAsGh4eN6XVwWJuD trosh1+2C0Se5qmkTXvI7Q+MUMXJ8jk7u7Evk9alizJFblLH7QToh63UNxqX8Py+pDCp UWgtSoY2IfzEkeee23VEcPkCgtT6VD3Nf0eETKzM9l/mQGkfGMx7tdZok6uugNV+l3h5 aNa0xl1m/n3oTolzduWe2dPipFAruCMza8Z4DpfGzIDHzmw+Je2seu/M8Pfofvt8nlJ3 YdYg== X-Gm-Message-State: APjAAAU32glCZvnLm3X0QT/CxMrdWJwTBFTvCpgvNwgQxA0Dqll3y6MB qrhrPBRQZa1+6FybPGA+4qf84Qg5EDle8SBbYrrYdA== X-Google-Smtp-Source: APXvYqzCr9/jMoeCv8dXiX02K4OTjQrk8e/Em+9FLIeQ4jD7B8JMRgFq0F2TAwiXcfObI7b39tyMS9ndwaof6W9vry4= X-Received: by 2002:a2e:551d:: with SMTP id j29mr3704471ljb.180.1553272680645; Fri, 22 Mar 2019 09:38:00 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> In-Reply-To: <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> From: Andy Bierman Date: Fri, 22 Mar 2019 09:37:49 -0700 Message-ID: To: Carsten Bormann Cc: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005ea0a50584b17ad4" Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 22 Mar 2019 16:38:07 -0000 --0000000000005ea0a50584b17ad4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2019 at 9:08 AM Carsten Bormann wrote: > On Mar 22, 2019, at 16:45, Michel Veillette < > Michel.Veillette@trilliant.com> wrote: > > > > The only potential problem I aware is when multiple enumerations are > part of the same union. > > Value 4 from enumeration A will be encoded the same way as Value 4 from > enumeration B. > > =E2=80=A6 and that is not a problem for the XML version, because the stri= ng is > being used instead of the value. (But then if two enumerations share a > string, you have the equivalent problem in the XML serialization.) > > The union data type has similar issues with JSON encoding, where the JSON encoding can influence the YANG decoding. This is not possible with XML since all values are strings. Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actually has= this > problem, so I would be a bit reluctant to make CBOR-based implementations > more complex (and less efficient) so solve this (non-?)problem. > > I agree, but tools still need to identify the problem if it exists and flag the object for different processing or no processing at all (draft says YANG with these conflicts are not allowed). IMO a string encoding should be used. All YANG union types are position-dependent. The parser goes through the member types in order, and first one that accepts the value given wins. (e.g, ip-address, or any union with 2 of the same base type). We discussed this issue during the NETMOD WG virtual interim this week, and wanted clarification on the scope of the problem. It seems to be limited to just multiple enumerations in a union. The rest of the corner-cases are just position-dependent, same as before. Gr=C3=BC=C3=9Fe, Carsten > > Andy > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000005ea0a50584b17ad4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 22, 2019 at 9:08 AM Carst= en Bormann <cabo@tzi.o= rg> wrote:
Michel.Veillette@trilliant.com> wrote:
>
> The only potential problem I aware is when multiple enumerations are p= art of the same union.
> Value 4 from enumeration A will be encoded the same way as Value 4 fro= m enumeration B.

=E2=80=A6 and that is not a problem for the XML version, because the string= is being used instead of the value.=C2=A0 (But then if two enumerations sh= are a string, you have the equivalent problem in the XML serialization.)


The union data type has= similar issues with JSON encoding, where the JSON encoding can
i= nfluence the YANG decoding. This is not possible with XML since all values = are strings.


Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actually has= this problem, so I would be a bit reluctant to make CBOR-based implementat= ions more complex (and less efficient) so solve this (non-?)problem.


I agree, but tools still need to ident= ify the problem if it exists and flag the object for different processing
or no processing at all (draft says YANG with these conflicts are = not allowed). IMO a string encoding
should be used.
All YANG union types are position-dependent.
The pars= er goes through the member types in order, and first one that accepts the v= alue given wins.
(e.g, ip-address, or any union with 2 of the sam= e base type).

We discussed this issue during the N= ETMOD WG virtual interim this week, and wanted clarification
on t= he scope of the problem. It seems to be limited to just multiple enumeratio= ns in a union.
The rest of the corner-cases are just position-dep= endent, same as before.


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


Andy
=C2=A0
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--0000000000005ea0a50584b17ad4-- From nobody Fri Mar 22 09:41:10 2019 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 0428213128A; Fri, 22 Mar 2019 09:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 uPcg3SvLSjYZ; Fri, 22 Mar 2019 09:41:06 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A1213127F; Fri, 22 Mar 2019 09:41:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B3B5D24; Fri, 22 Mar 2019 17:41:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id SDykB8CYOjRq; Fri, 22 Mar 2019 17:41:04 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 22 Mar 2019 17:41:04 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 769A6200A6; Fri, 22 Mar 2019 17:41:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id GfnybAc6SZlS; Fri, 22 Mar 2019 17:41:04 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 36BA1200A5; Fri, 22 Mar 2019 17:41:04 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 22 Mar 2019 17:41:03 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 47BCD300779637; Fri, 22 Mar 2019 17:41:03 +0100 (CET) Date: Fri, 22 Mar 2019 17:41:02 +0100 From: Juergen Schoenwaelder To: Carsten Bormann CC: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190322164102.pa6xl5elsavqrk6q@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 22 Mar 2019 16:41:09 -0000 On Fri, Mar 22, 2019 at 05:08:20PM +0100, Carsten Bormann wrote: >=20 > Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actually= has this problem, so I would be a bit reluctant to make CBOR-based imple= mentations more complex (and less efficient) so solve this (non-?)problem= . > I think we need to make sure that the interpretation of yang-defined data is _always_ the same and does not depend on the encoding negotiated between a client and a server. Efficiency is nice, avoiding ambiguity is a must. Avoiding ambiguity can be achieved in different ways, such as making sure all encodings are designed to not allow different interpretations (even if that means a loss of efficiency in some cases) or by changing YANG (or YANG usage guidelines) such that constructs that may lead to ambiguities are impossible or at least flagged and then avoided. I guess this is why this topic pops up in the context of YANG next and we need to figure out which road to take. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 22 10:30:16 2019 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 9BE3A131351; Fri, 22 Mar 2019 10:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQH4D6Wphttm; Fri, 22 Mar 2019 10:30:12 -0700 (PDT) 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 99180131350; Fri, 22 Mar 2019 10:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1832; q=dns/txt; s=iport; t=1553275812; x=1554485412; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HUMyYHwwn7vEgR9EnhHmJD5dtpUju1yHshbww2VzeyM=; b=NsYVSkkJqBufihbkA1xcqHRH6e2n17Iu3knME3wi9EGxv/YAZtEayNbp ocA9spdDrxJXP+RBuhj+J2Tv6roCtiFtMyK/zUc0LudQJlg6Q+DeBWALZ +3pqXfL0zdf/5fD5np1RCuuoLxxyT53vixKkbGc7UC6DYTR5nSJRvsBbO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADKGpVc/51dJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBghCBaycKhASIHI0tmDiBew0BAYRsAhe?= =?us-ascii?q?EZSI0CQ0BAQMBAQkBAwJtKIVKAQEBBCMRRQwEAgEGAg4DBAEBAQICJgICAjA?= =?us-ascii?q?VCAgBAQQBDQUIhRCNZZtmgS+KL4ELJAGLMReBQD+BEYMSPoRLM4JQglcDjG2?= =?us-ascii?q?YIAkCky4hk3yLGJMkAhEVgS4fOIFWcBWDJ5BLQTGNY4EfAQE?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208";a="248849769" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2019 17:30:11 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x2MHU6GQ021002 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2019 17:30:10 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 12:30:09 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 22 Mar 2019 12:30:09 -0500 From: "Rob Wilton (rwilton)" To: Carsten Bormann , Michel Veillette CC: "core@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAA12kQAAB/hI0A== Date: Fri, 22 Mar 2019 17:30:09 +0000 Message-ID: <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> In-Reply-To: <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.76.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 22 Mar 2019 17:30:15 -0000 SSBndWVzcyB0aGF0IHRoZSBjb25jZXJuIGlzIHRoYXQgdGhpcyBpbnRyb2R1Y2VzIG1vcmUgdmFy aWF0aW9uIGluIGhvdyBkYXRhIGlzIGludGVycHJldGVkIGJldHdlZW4gdGhlIGRpZmZlcmVudCBY TUwvSlNPTi9DQk9SIGVuY29kaW5ncy4NCg0KRS5nLiBpZiBzb21lb25lIHN3aXRjaGVkIGZyb20g WE1MIHRvIENCT1IsIHN1ZGRlbmx5IHRoZSBjb25maWd1cmF0aW9uIG9yIHN0YXRlIGRhdGEgbWF5 IGhhdmUgYSBkaWZmZXJlbnQgbWVhbmluZy4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9y Zz4NCj4gU2VudDogMjIgTWFyY2ggMjAxOSAxNjowOA0KPiBUbzogTWljaGVsIFZlaWxsZXR0ZSA8 TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPg0KPiBDYzogUm9iIFdpbHRvbiAocndpbHRv bikgPHJ3aWx0b25AY2lzY28uY29tPjsgY29yZUBpZXRmLm9yZzsNCj4gbmV0Y29uZkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW25ldGNvbmZdIFlBTkcgZW5jb2RpbmcgaW4gQ0JPUg0KPiANCj4g T24gTWFyIDIyLCAyMDE5LCBhdCAxNjo0NSwgTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxs ZXR0ZUB0cmlsbGlhbnQuY29tPg0KPiB3cm90ZToNCj4gPg0KPiA+IFRoZSBvbmx5IHBvdGVudGlh bCBwcm9ibGVtIEkgYXdhcmUgaXMgd2hlbiBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgYXJlIHBhcnQg b2YNCj4gdGhlIHNhbWUgdW5pb24uDQo+ID4gVmFsdWUgNCBmcm9tIGVudW1lcmF0aW9uIEEgd2ls bCBiZSBlbmNvZGVkIHRoZSBzYW1lIHdheSBhcyBWYWx1ZSA0IGZyb20NCj4gZW51bWVyYXRpb24g Qi4NCj4gDQo+IOKApiBhbmQgdGhhdCBpcyBub3QgYSBwcm9ibGVtIGZvciB0aGUgWE1MIHZlcnNp b24sIGJlY2F1c2UgdGhlIHN0cmluZyBpcyBiZWluZyB1c2VkDQo+IGluc3RlYWQgb2YgdGhlIHZh bHVlLiAgKEJ1dCB0aGVuIGlmIHR3byBlbnVtZXJhdGlvbnMgc2hhcmUgYSBzdHJpbmcsIHlvdSBo YXZlIHRoZQ0KPiBlcXVpdmFsZW50IHByb2JsZW0gaW4gdGhlIFhNTCBzZXJpYWxpemF0aW9uLikN Cj4gDQo+IEFueXdheSwgSSBoYXZlbuKAmXQgc2VlbiBhIHBpZWNlIG9mIHJlYWwtd29ybGQgWUFO RyB0aGF0IGFjdHVhbGx5IGhhcyB0aGlzDQo+IHByb2JsZW0sIHNvIEkgd291bGQgYmUgYSBiaXQg cmVsdWN0YW50IHRvIG1ha2UgQ0JPUi1iYXNlZCBpbXBsZW1lbnRhdGlvbnMNCj4gbW9yZSBjb21w bGV4IChhbmQgbGVzcyBlZmZpY2llbnQpIHNvIHNvbHZlIHRoaXMgKG5vbi0/KXByb2JsZW0uDQo+ IA0KPiBHcsO8w59lLCBDYXJzdGVuDQoNCg== From nobody Fri Mar 22 10:32:51 2019 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 002E113124D; Fri, 22 Mar 2019 10:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kESfwdQ52kJy; Fri, 22 Mar 2019 10:32:42 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AC3131362; Fri, 22 Mar 2019 10:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16959; q=dns/txt; s=iport; t=1553275962; x=1554485562; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cAZv961zRktHDt5LV5+eOjxytb5d77os58Lam1lZSr8=; b=RjbQzFNepV1HAo4KrNprMgo9z6YF/jfwH4jHMZvXHoJfd36ifZdZZ0iT 2lr1bPlEZ6Iv6Lz87U7o2zhxKvktij+EWXDXc/qsODXG6exO0kdERp5wN 0yl97/x2ba+pNlJFaZW5HBfefbQ1TvEs8gKBhNlMWlPGuYQNp8KkXYrlI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAC4G5Vc/4kNJK1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDoECaIEDJwqMIIsggg2SQYV3FIFnDQEBI4R?= =?us-ascii?q?JAoR8IjQJDQEBAwEBCQEDAm0cDIVKAQEBBCcGXAIBCBEEAQEoBzIUCQgBAQQ?= =?us-ascii?q?BEgiDG4ERZA+qPjOKKQWBLwGLMReBQD+BEYMSPoJhAQECAYErARIBLSiFKwO?= =?us-ascii?q?KFSCGUx6TB2AJAodhi00hk3yLGIYCjSICERWBLh84KD1xcBU7gmyCFheIX4U?= =?us-ascii?q?/QTEBAQGMQYEfgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208,217";a="251126838" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2019 17:32:37 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2MHWbbi001478 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2019 17:32:37 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 12:32:36 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 22 Mar 2019 12:32:36 -0500 From: "Rob Wilton (rwilton)" To: Michel Veillette , "core@ietf.org" , "netconf@ietf.org" Thread-Topic: YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAXew9A= Date: Fri, 22 Mar 2019 17:32:36 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.76.6] Content-Type: multipart/alternative; boundary="_000_edbd00c68ad2440684d61160be263e9cXCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [core] YANG encoding in CBOR 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, 22 Mar 2019 17:32:45 -0000 --_000_edbd00c68ad2440684d61160be263e9cXCHRCD007ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, Indeed, it was the encoding of unions containing more than one enum that wa= s the concern raised in the meeting. Thanks, Rob From: Michel Veillette Sent: 22 March 2019 15:45 To: Rob Wilton (rwilton) ; core@ietf.org; netconf@ietf.o= rg Subject: RE: YANG encoding in CBOR Hi Rob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About "I was wondering whether it would be better to encode enum values ...= " YANG assigns either explicitly or implicitly to each enumeration, a unique = integer value, see https://tools.ietf.org/html/rfc7950#section-9.6.4.2. In CBOR, these values are used, see https://tools.ietf.org/html/draft-ietf-= core-yang-cbor-07#section-6.6 When used outside of a union, I don't see any issues with those values. Andy, do you have a specific example for which, the current encoding is amb= iguous? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The encoding of union is defined in: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section-6.12 Currently, each YANG datatype in a union is encoded differently to avoid an= y ambiguities between them. For example, integer 4 is encoded as: 04 # unsigned(4) enumerator value 4 is encoded as (assuming the allocated tag is 99): D8 63 # tag(99) 04 # unsigned(4) The list of these encoding is shown below: - unsigned integer --> CBOR unsigned integer - integer --> CBOR unsigned integer, CBOR negative integer - enumeration --> CBOR tag - identityref as SID --> CBOR tag - string --> CBOR text string - identityref as name --> CBOR tag - bits --> CBOR tag - binary --> CBOR byte string - decimal64 --> CBOR tag 4 - boolean --> CBOR simple value The only potential problem I aware is when multiple enumerations are part o= f the same union. Value 4 from enumeration A will be encoded the same way as Value 4 from enu= meration B. Is it a real problem is proactive? If so, how this can be resolved? I won't be present at the Prague meeting, but I'm certainly available to di= scuss this topic by email. I will be present at the Montreal meeting for any remaining discussions on = this draft. Note: I'm currently updating the draft to remove any dependencies with RFC = 7951, to resolve a comment sent by Andy. Regards Michel From: core > On Behalf = Of Rob Wilton (rwilton) Sent: Friday, March 22, 2019 8:43 AM To: core@ietf.org; netconf@ietf.org Subject: [core] YANG encoding in CBOR Hi, As part of YANG evolution discussion, that was some talk about using a bina= ry encoding of YANG in NETCONF or RESTCONF. CBOR looks like a good fit for this, and obviously CORE WG are working on d= raft-ietf-core-yang-cbor-07, but one comment came up from Andy that the CBO= R encoding of YANG cannot handle all YANG data models. In particular, beca= use of the way that the encoding works there are limitations on how unions = of enums work. Is that still the case? Hence I was wondering whether it would be better to encode enum values in C= BOR using module-qualified names, or also assign them SIDs and use the SIDs= . Has this approach been considered at all? Or, is there an alternative approach to how we could/should consider using = CBOR as a binary encoding for YANG data in NETCONF or RESTCONF? Do you think it would be possible to get interested parties together to dis= cuss this at some point in Prague? Thanks, Rob --_000_edbd00c68ad2440684d61160be263e9cXCHRCD007ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michael,

 

Indeed, it was the encoding of unions containing more than one enum th= at was the concern raised in the meeting.

 

Thanks,

Rob

 

 

From: Michel Veillette <Michel.Veillette@trilliant.com>
Sent: 22 March 2019 15:45
To: Rob Wilton (rwilton) <rwilton@cisco.com>; core@ietf.org; n= etconf@ietf.org
Subject: RE: YANG encoding in CBOR

 

Hi Rob

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

About "I was wonder= ing whether it would be better to encode enum values …"

 

YANG assigns either explicitly = or implicitly to each enumeration, a unique integer value, see https://tools.ietf.org/html/rfc7950#s= ection-9.6.4.2.

In CBOR, these values are used,= see https://tools.ietf.org/html/draft-ietf-core-yang= -cbor-07#section-6.6

When used outside of a union, I= don't see any issues with those values.

Andy, do you have a specific ex= ample for which, the current encoding is ambiguous?

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

The encoding of union is define= d in:

https://tools.ietf.org/h= tml/draft-ietf-core-yang-cbor-07#section-6.12

 

Currently, each YANG datatype i= n a union is encoded differently to avoid any ambiguities between  the= m.

For example, integer 4 is encod= ed as:

 

04 # unsigned(4)

 

enumerator value 4 is encoded a= s (assuming the allocated tag is 99):

 

D8 63 # tag(99)

   04 # unsigned(4)

 

The list of these encoding is s= hown below:

- unsigned integer --> CBOR = unsigned integer

- integer --> CBOR unsigned = integer, CBOR negative integer

- enumeration --> CBOR tag &= lt;TBD>

- identityref as SID --> CBO= R tag <TBD>

- string --> CBOR text strin= g

- identityref as name --> CB= OR tag <TBD>

- bits --> CBOR tag <TBD&= gt;

- binary --> CBOR byte strin= g

- decimal64 --> CBOR tag 4

- boolean --> CBOR simple va= lue

 

The only potential problem I aw= are is when multiple enumerations are part of the same union.

Value 4 from enumeration A will= be encoded the same way as Value 4 from enumeration B.

 

Is it a real problem is proacti= ve?

If so, how this can be resolved= ?

 

I won't be present at the Pragu= e meeting, but I'm certainly available to discuss this topic by email.=

I will be present at the Montre= al meeting for any remaining discussions on this draft.

 

Note: I'm currently updating th= e draft to remove any dependencies with RFC 7951, to resolve a comment sent= by Andy.

 

Regards

Michel

 

 

From: core <core-bounces@= ietf.org> On Behalf Of Rob Wilton (rwilton)
Sent: Friday, March 22, 2019 8:43 AM
To: core@ietf.org; netconf@ietf.org
Subject: [core] YANG encoding in CBOR

 

Hi,

 

As part of YANG evolution discussion, that was some = talk about using a binary encoding of YANG in NETCONF or RESTCONF.

 

CBOR looks like a good fit for this, and obviously C= ORE WG are working on draft-ietf-core-yang-cbor-07, but one comment came up= from Andy that the CBOR encoding of YANG cannot handle all YANG data model= s.  In particular, because of the way that the encoding works there are limitations on how unions of enums w= ork.  Is that still the case?

 

Hence I was wondering whether it would be better to = encode enum values in CBOR using module-qualified names, or also assign the= m SIDs and use the SIDs.  Has this approach been considered at all?

 

Or, is there an alternative approach to how we could= /should consider using CBOR as a binary encoding for YANG data in NETCONF o= r RESTCONF?

 

Do you think it would be possible to get interested = parties together to discuss this at some point in Prague?

 

Thanks,
Rob

 

--_000_edbd00c68ad2440684d61160be263e9cXCHRCD007ciscocom_-- From nobody Fri Mar 22 11:34:18 2019 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 A4E39131430; Fri, 22 Mar 2019 11:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDGIHNZsZS_m; Fri, 22 Mar 2019 11:34:04 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680123.outbound.protection.outlook.com [40.107.68.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1860413142E; Fri, 22 Mar 2019 11:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2I3cDsw5K7wkdV7T5zOjGmfE/lybhT6U1fv4k+FFHns=; b=qmhObOpBhvVF9GYOZBEYOZognvUAGrZPMD4eXQDxG/4Kkqrrp+j44m0RN7qPAPexrJqnhM6uDHuhGSpO9qWzTFPy6LB7f0k/Vi85DvJo8Rctn++4tGVjPF1OdIbl/fk3GlNkjdrvi4YKqhD+IvAVKyZKdPtHHyc/8rHh2VxHNcA= Received: from DM6PR06MB5049.namprd06.prod.outlook.com (20.176.122.224) by DM6PR06MB5946.namprd06.prod.outlook.com (20.179.163.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.15; Fri, 22 Mar 2019 18:34:00 +0000 Received: from DM6PR06MB5049.namprd06.prod.outlook.com ([fe80::1cf7:3307:9831:558e]) by DM6PR06MB5049.namprd06.prod.outlook.com ([fe80::1cf7:3307:9831:558e%4]) with mapi id 15.20.1709.015; Fri, 22 Mar 2019 18:34:00 +0000 From: Michel Veillette To: "Rob Wilton (rwilton)" , "core@ietf.org" , "netconf@ietf.org" Thread-Topic: YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAXew9AAAeuD8A== Date: Fri, 22 Mar 2019 18:34:00 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 547e9d3f-3261-4656-fede-08d6aef4f3ee x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR06MB5946; x-ms-traffictypediagnostic: DM6PR06MB5946: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39830400003)(396003)(366004)(376002)(199004)(189003)(478600001)(6116002)(81156014)(6436002)(6246003)(9686003)(6306002)(54896002)(72206003)(14454004)(229853002)(8676002)(55016002)(7696005)(2501003)(3846002)(99286004)(68736007)(25786009)(5660300002)(966005)(74316002)(236005)(790700001)(105586002)(110136005)(53936002)(8936002)(86362001)(486006)(2906002)(71200400001)(52536014)(11346002)(446003)(106356001)(2201001)(97736004)(7736002)(476003)(71190400001)(3480700005)(26005)(102836004)(6506007)(66066001)(53546011)(81166006)(76176011)(606006)(186003)(33656002)(256004)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR06MB5946; H:DM6PR06MB5049.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HcLxRl3D0FCsq/IsL7EX4ihOBgQZWyhWODV0EVpXjrQ2q79JkmiWgqq2zeNvhJp3aKYbvKoJHA+NIQJZPRJgqrMAVeoERV3K9Nda94IZSeW6b37h/82u216Eb2J05HtOE03TE4kL0EP9+GNL6cxaMN7Gyb2P9QPmepx9Bjzo0H8Kr35IYyqJQziJRIGRmwzkWvwi1bxLOn8cgWtiHefvMtSC+IZ10dkNckwRhwJ8DwjU5O5N+rVKTxhEPSIgF2I6GYxqRzn5q4CN8wfZh+QN66jqgVgo0evibdK4IV0ehQ+t65IPqul4hVO5AmJAz/M0XOBPf6jkkJTkAi453Sl+hzbEjruriTN9OAQPtVTWvBo+OUB1E5utWGa9R0O4DkiT0Q+tZWBKPxZO3qsJtzsIzYQ8A7G+unX7mUeLk83jYgk= Content-Type: multipart/alternative; boundary="_000_DM6PR06MB50497E9F418DF2F9EEA2E5469A430DM6PR06MB5049namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 547e9d3f-3261-4656-fede-08d6aef4f3ee X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 18:34:00.5221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB5946 Archived-At: Subject: Re: [core] YANG encoding in CBOR 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, 22 Mar 2019 18:34:08 -0000 --_000_DM6PR06MB50497E9F418DF2F9EEA2E5469A430DM6PR06MB5049namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rob Any solutions have been discussed or proposed? Encoding enumerators part of a union as CBOR text string might be the simpl= es solution. Would you please discuss this proposed solution with any and any other inte= rested parties in Prague. Regards Michel From: Rob Wilton (rwilton) Sent: Friday, March 22, 2019 1:33 PM To: Michel Veillette ; core@ietf.org; netco= nf@ietf.org Subject: RE: YANG encoding in CBOR Hi Michael, Indeed, it was the encoding of unions containing more than one enum that wa= s the concern raised in the meeting. Thanks, Rob From: Michel Veillette > Sent: 22 March 2019 15:45 To: Rob Wilton (rwilton) >; cor= e@ietf.org; netconf@ietf.org Subject: RE: YANG encoding in CBOR Hi Rob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About "I was wondering whether it would be better to encode enum values ...= " YANG assigns either explicitly or implicitly to each enumeration, a unique = integer value, see https://tools.ietf.org/html/rfc7950#section-9.6.4.2. In CBOR, these values are used, see https://tools.ietf.org/html/draft-ietf-= core-yang-cbor-07#section-6.6 When used outside of a union, I don't see any issues with those values. Andy, do you have a specific example for which, the current encoding is amb= iguous? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The encoding of union is defined in: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section-6.12 Currently, each YANG datatype in a union is encoded differently to avoid an= y ambiguities between them. For example, integer 4 is encoded as: 04 # unsigned(4) enumerator value 4 is encoded as (assuming the allocated tag is 99): D8 63 # tag(99) 04 # unsigned(4) The list of these encoding is shown below: - unsigned integer --> CBOR unsigned integer - integer --> CBOR unsigned integer, CBOR negative integer - enumeration --> CBOR tag - identityref as SID --> CBOR tag - string --> CBOR text string - identityref as name --> CBOR tag - bits --> CBOR tag - binary --> CBOR byte string - decimal64 --> CBOR tag 4 - boolean --> CBOR simple value The only potential problem I aware is when multiple enumerations are part o= f the same union. Value 4 from enumeration A will be encoded the same way as Value 4 from enu= meration B. Is it a real problem is real life? If so, how this can be resolved? I won't be present at the Prague meeting, but I'm certainly available to di= scuss this topic by email. I will be present at the Montreal meeting for any remaining discussions on = this draft. Note: I'm currently updating the draft to remove any dependencies with RFC = 7951, to resolve a comment sent by Andy. Regards Michel From: core > On Behalf = Of Rob Wilton (rwilton) Sent: Friday, March 22, 2019 8:43 AM To: core@ietf.org; netconf@ietf.org Subject: [core] YANG encoding in CBOR Hi, As part of YANG evolution discussion, that was some talk about using a bina= ry encoding of YANG in NETCONF or RESTCONF. CBOR looks like a good fit for this, and obviously CORE WG are working on d= raft-ietf-core-yang-cbor-07, but one comment came up from Andy that the CBO= R encoding of YANG cannot handle all YANG data models. In particular, beca= use of the way that the encoding works there are limitations on how unions = of enums work. Is that still the case? Hence I was wondering whether it would be better to encode enum values in C= BOR using module-qualified names, or also assign them SIDs and use the SIDs= . Has this approach been considered at all? Or, is there an alternative approach to how we could/should consider using = CBOR as a binary encoding for YANG data in NETCONF or RESTCONF? Do you think it would be possible to get interested parties together to dis= cuss this at some point in Prague? Thanks, Rob --_000_DM6PR06MB50497E9F418DF2F9EEA2E5469A430DM6PR06MB5049namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rob

 

Any solutions have been discuss= ed or proposed?

 

Encoding enumerators part of a = union as CBOR text string might be the simples solution.<= /p>

Would you please discuss this p= roposed solution with any and any other interested parties in Prague.<= /o:p>

 

Regards

Michel

 

From: Rob Wilton (rwilton) <rwilton@cisco.= com>
Sent: Friday, March 22, 2019 1:33 PM
To: Michel Veillette <Michel.Veillette@trilliant.com>; core@ie= tf.org; netconf@ietf.org
Subject: RE: YANG encoding in CBOR

 

Hi Mich= ael,

&n= bsp;

Indeed,= it was the encoding of unions containing more than one enum that was the c= oncern raised in the meeting.

&n= bsp;

Thanks,=

Rob

&n= bsp;

&n= bsp;

From: Michel Veillette <Michel.Veillette@trilliant.com>
Sent: 22 March 2019 15:45
To: Rob Wilton (rwilton) <rw= ilton@cisco.com>; core@ietf.org; netconf@ietf.org
Subject: RE: YANG encoding in CBOR

 

Hi Rob

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

About "I was wondering whether it would be better to encode enum values= …"

 

YANG assigns either explicitly or implicitly to each= enumeration, a unique integer value, see = https://tools.ietf.org/html/rfc7950#section-9.6.4.2.=

In CBOR, these values are used, see https://tools.ietf.org/h= tml/draft-ietf-core-yang-cbor-07#section-6.6

When used outside of a union, I don't see any issues= with those values.

Andy, do you have a specific example for which, the = current encoding is ambiguous?

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The encoding of union is defined in:

https= ://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section-6.12

 

Currently, each YANG datatype in a union is encoded = differently to avoid any ambiguities between  them.

For example, integer 4 is encoded as:

 

04 # unsigned(4)

 

enumerator value 4 is encoded as (assuming the alloc= ated tag is 99):

 

D8 63 # tag(99)

   04 # unsigned(4)

 

The list of these encoding is shown below:

- unsigned integer --> CBOR unsigned integer=

- integer --> CBOR unsigned integer, CBOR negativ= e integer

- enumeration --> CBOR tag <TBD>=

- identityref as SID --> CBOR tag <TBD>

- string --> CBOR text string

- identityref as name --> CBOR tag <TBD>

- bits --> CBOR tag <TBD>

- binary --> CBOR byte string

- decimal64 --> CBOR tag 4

- boolean --> CBOR simple value

 

The only potential problem I aware is when multiple = enumerations are part of the same union.

Value 4 from enumeration A will be encoded the same = way as Value 4 from enumeration B.

 

Is it a real problem is real life?

If so, how this can be resolved?

 

I won't be present at the Prague meeting, but I'm ce= rtainly available to discuss this topic by email.

I will be present at the Montreal meeting for any re= maining discussions on this draft.

 

Note: I'm currently updating the draft to remove any= dependencies with RFC 7951, to resolve a comment sent by Andy.<= /p>

 

Regards

Michel

 

 

From: core <core-bounces@ietf.org> On Behalf Of Rob Wilton (rwilton)
Sent: Friday, March 22, 2019 8:43 AM
To: core@ietf.org; netconf@ietf.org
Subject: [core] YANG encoding in CBOR

 

Hi,

 

As part of YANG evolution discu= ssion, that was some talk about using a binary encoding of YANG in NETCONF = or RESTCONF.

 

CBOR looks like a good fit for = this, and obviously CORE WG are working on draft-ietf-core-yang-cbor-07, bu= t one comment came up from Andy that the CBOR encoding of YANG cannot handl= e all YANG data models.  In particular, because of the way that the encoding works there are limitations on how un= ions of enums work.  Is that still the case?

 

Hence I was wondering whether i= t would be better to encode enum values in CBOR using module-qualified name= s, or also assign them SIDs and use the SIDs.  Has this approach been = considered at all?

 

Or, is there an alternative app= roach to how we could/should consider using CBOR as a binary encoding for Y= ANG data in NETCONF or RESTCONF?

 

Do you think it would be possib= le to get interested parties together to discuss this at some point in Prag= ue?

 

Thanks,
Rob

 

--_000_DM6PR06MB50497E9F418DF2F9EEA2E5469A430DM6PR06MB5049namp_-- From nobody Sat Mar 23 02:03:47 2019 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 0BBDD1279B2; Sat, 23 Mar 2019 02:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w58uE-mG-bvx; Sat, 23 Mar 2019 02:03:36 -0700 (PDT) Received: from smtp.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 E9776127985; Sat, 23 Mar 2019 02:03:35 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44RF1d3ZKszyvb; Sat, 23 Mar 2019 10:03:33 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> Date: Sat, 23 Mar 2019 10:03:32 +0100 Cc: "core@ietf.org" , "netconf@ietf.org" , "Rob Wilton (rwilton)" X-Mao-Original-Outgoing-Id: 575024610.781531-fa120bcd936fa8f445d28822f35fb82a Content-Transfer-Encoding: quoted-printable Message-Id: <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> To: Michel Veillette X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 23 Mar 2019 09:03:38 -0000 Well, if that is a problem, we can go for a longer representation within = unions (section 6.12). Theoretically, we could do that only of there is = more than one enum in the union type (so things stay efficient if there = is only one), but that might pose difficulties with model evolution. Going for a string representation repeats the feature of XML YANG (which = was ported over to JSON YANG): typedef foo { type union { type enumeration { enum red { value 1; } enum breen { value 2; } enum glue { value 3; } } type enumeration { enum tacks { value 1; } enum nails { value 2; } enum glue { value 3; } } } } If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of the = enumerations are being used. Using SIDs, we can do better. So what do we have to do to get the SID tool to allocate SIDs for enum = values? We could then define the CBOR tag for enums in unions to take the usual = SID difference (delta relative to the environment, I=E2=80=99d think), = not an integer value. Several of us are at the hackathon and could make something happen today = and tomorrow. Gr=C3=BC=C3=9Fe, Carsten > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: >=20 > I guess that the concern is that this introduces more variation in how = data is interpreted between the different XML/JSON/CBOR encodings. >=20 > E.g. if someone switched from XML to CBOR, suddenly the configuration = or state data may have a different meaning. >=20 > Thanks, > Rob >=20 >=20 >> -----Original Message----- >> From: Carsten Bormann >> Sent: 22 March 2019 16:08 >> To: Michel Veillette >> Cc: Rob Wilton (rwilton) ; core@ietf.org; >> netconf@ietf.org >> Subject: Re: [netconf] YANG encoding in CBOR >>=20 >> On Mar 22, 2019, at 16:45, Michel Veillette = >> wrote: >>>=20 >>> The only potential problem I aware is when multiple enumerations are = part of >> the same union. >>> Value 4 from enumeration A will be encoded the same way as Value 4 = from >> enumeration B. >>=20 >> =E2=80=A6 and that is not a problem for the XML version, because the = string is being used >> instead of the value. (But then if two enumerations share a string, = you have the >> equivalent problem in the XML serialization.) >>=20 >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that = actually has this >> problem, so I would be a bit reluctant to make CBOR-based = implementations >> more complex (and less efficient) so solve this (non-?)problem. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 From nobody Sat Mar 23 03:10:13 2019 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 0F10D130E6D; Sat, 23 Mar 2019 03:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 0BoL83C6vWdl; Sat, 23 Mar 2019 03:10:07 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B1E1293B1; Sat, 23 Mar 2019 03:10:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CE8866F4; Sat, 23 Mar 2019 11:10:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Q_4hyp3vGCha; Sat, 23 Mar 2019 11:10:05 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 23 Mar 2019 11:10:05 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8EF04200A6; Sat, 23 Mar 2019 11:10:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id YRAKQ_jvn_vC; Sat, 23 Mar 2019 11:10:05 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 06C30200A5; Sat, 23 Mar 2019 11:10:05 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sat, 23 Mar 2019 11:10:04 +0100 Received: by anna.localdomain (Postfix, from userid 501) id D700A30077A954; Sat, 23 Mar 2019 11:10:03 +0100 (CET) Date: Sat, 23 Mar 2019 11:10:03 +0100 From: Juergen Schoenwaelder To: Carsten Bormann CC: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 23 Mar 2019 10:10:11 -0000 I think we need to look at the whole picture and in which direction we want to go. In the longer term, I would prefer a solution where the values of a union are discriminated. The current XML encoding behaviour of 'first match wins' is fragile (for example, if someone adds an enum to a type, the interpretation of data can change). Look at this: typedef bar { type union { type enumeration { enum "1"; value 2; enum "2"; value 1; } type uint8; } } We have some encodings that send the string representations of the values and some encodings that prefer to send numeric representations where possible. In order to have a robust solution, encodings should likely indicate to which type the value belongs. /js On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > Well, if that is a problem, we can go for a longer representation withi= n unions (section 6.12). Theoretically, we could do that only of there i= s more than one enum in the union type (so things stay efficient if there= is only one), but that might pose difficulties with model evolution. >=20 > Going for a string representation repeats the feature of XML YANG (whic= h was ported over to JSON YANG): >=20 > typedef foo { > type union { > type enumeration { > enum red { value 1; } > enum breen { value 2; } > enum glue { value 3; } > } > type enumeration { > enum tacks { value 1; } > enum nails { value 2; } > enum glue { value 3; } > } > } > } >=20 > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of the = enumerations are being used. >=20 > Using SIDs, we can do better. >=20 > So what do we have to do to get the SID tool to allocate SIDs for enum = values? >=20 > We could then define the CBOR tag for enums in unions to take the usual= SID difference (delta relative to the environment, I=E2=80=99d think), n= ot an integer value. >=20 > Several of us are at the hackathon and could make something happen toda= y and tomorrow. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) w= rote: > >=20 > > I guess that the concern is that this introduces more variation in ho= w data is interpreted between the different XML/JSON/CBOR encodings. > >=20 > > E.g. if someone switched from XML to CBOR, suddenly the configuration= or state data may have a different meaning. > >=20 > > Thanks, > > Rob > >=20 > >=20 > >> -----Original Message----- > >> From: Carsten Bormann > >> Sent: 22 March 2019 16:08 > >> To: Michel Veillette > >> Cc: Rob Wilton (rwilton) ; core@ietf.org; > >> netconf@ietf.org > >> Subject: Re: [netconf] YANG encoding in CBOR > >>=20 > >> On Mar 22, 2019, at 16:45, Michel Veillette > >> wrote: > >>>=20 > >>> The only potential problem I aware is when multiple enumerations ar= e part of > >> the same union. > >>> Value 4 from enumeration A will be encoded the same way as Value 4 = from > >> enumeration B. > >>=20 > >> =E2=80=A6 and that is not a problem for the XML version, because the= string is being used > >> instead of the value. (But then if two enumerations share a string,= you have the > >> equivalent problem in the XML serialization.) > >>=20 > >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actua= lly has this > >> problem, so I would be a bit reluctant to make CBOR-based implementa= tions > >> more complex (and less efficient) so solve this (non-?)problem. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >=20 > >=20 > >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > Well, if that is a problem, we can go for a longer representation withi= n unions (section 6.12). Theoretically, we could do that only of there i= s more than one enum in the union type (so things stay efficient if there= is only one), but that might pose difficulties with model evolution. >=20 > Going for a string representation repeats the feature of XML YANG (whic= h was ported over to JSON YANG): >=20 > typedef foo { > type union { > type enumeration { > enum red { value 1; } > enum breen { value 2; } > enum glue { value 3; } > } > type enumeration { > enum tacks { value 1; } > enum nails { value 2; } > enum glue { value 3; } > } > } > } >=20 > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of the = enumerations are being used. >=20 > Using SIDs, we can do better. >=20 > So what do we have to do to get the SID tool to allocate SIDs for enum = values? >=20 > We could then define the CBOR tag for enums in unions to take the usual= SID difference (delta relative to the environment, I=E2=80=99d think), n= ot an integer value. >=20 > Several of us are at the hackathon and could make something happen toda= y and tomorrow. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) w= rote: > >=20 > > I guess that the concern is that this introduces more variation in ho= w data is interpreted between the different XML/JSON/CBOR encodings. > >=20 > > E.g. if someone switched from XML to CBOR, suddenly the configuration= or state data may have a different meaning. > >=20 > > Thanks, > > Rob > >=20 > >=20 > >> -----Original Message----- > >> From: Carsten Bormann > >> Sent: 22 March 2019 16:08 > >> To: Michel Veillette > >> Cc: Rob Wilton (rwilton) ; core@ietf.org; > >> netconf@ietf.org > >> Subject: Re: [netconf] YANG encoding in CBOR > >>=20 > >> On Mar 22, 2019, at 16:45, Michel Veillette > >> wrote: > >>>=20 > >>> The only potential problem I aware is when multiple enumerations ar= e part of > >> the same union. > >>> Value 4 from enumeration A will be encoded the same way as Value 4 = from > >> enumeration B. > >>=20 > >> =E2=80=A6 and that is not a problem for the XML version, because the= string is being used > >> instead of the value. (But then if two enumerations share a string,= you have the > >> equivalent problem in the XML serialization.) > >>=20 > >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actua= lly has this > >> problem, so I would be a bit reluctant to make CBOR-based implementa= tions > >> more complex (and less efficient) so solve this (non-?)problem. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >=20 > >=20 > >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Mar 23 03:27:14 2019 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 6295612D84C; Sat, 23 Mar 2019 03:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiGe99i_Qcwl; Sat, 23 Mar 2019 03:27:11 -0700 (PDT) Received: from smtp.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 AA2E612D4F2; Sat, 23 Mar 2019 03:27:10 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44RGt44Q06zyw5; Sat, 23 Mar 2019 11:27:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> Date: Sat, 23 Mar 2019 11:27:08 +0100 Cc: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575029626.264401-255d07e5b71704ba7c6158fb07a891bf Content-Transfer-Encoding: quoted-printable Message-Id: <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 23 Mar 2019 10:27:13 -0000 On Mar 23, 2019, at 11:10, Juergen Schoenwaelder = wrote: >=20 > I think we need to look at the whole picture and in which direction we > want to go. In the longer term, I would prefer a solution where the > values of a union are discriminated. The current XML encoding > behaviour of =E2=80=98first match wins' Can you point to chapter and verse? > is fragile (for example, if someone > adds an enum to a type, the interpretation of data can change). >=20 > Look at this: >=20 > typedef bar { > type union { > type enumeration { enum "1"; value 2; enum "2"; value 1; } > type uint8; > } > } >=20 > We have some encodings that send the string representations of the > values and some encodings that prefer to send numeric representations > where possible. In order to have a robust solution, encodings should > likely indicate to which type the value belongs. In a serialization that has more type information (such as yang-cbor), = you can reliably distinguish any usage of the uint8 from the usage of = the enumerations. We put in the CBOR tags to enable that even though = enumeration values are normally represented by their =E2=80=9Cvalue=E2=80=9D= field. The part that I don=E2=80=99t understand is what is the plan with = handling conflicts between the enumerations. I=E2=80=99m not sure what = the equivalence model is, here =E2=80=94 do YANG enums employ structural = equivalence? There is no name up there, so it can=E2=80=99t really be = name equivalence, unless there is an implicit name being inferred from = the schema tree. Gr=C3=BC=C3=9Fe, Carsten >=20 > /js >=20 > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> Well, if that is a problem, we can go for a longer representation = within unions (section 6.12). Theoretically, we could do that only of = there is more than one enum in the union type (so things stay efficient = if there is only one), but that might pose difficulties with model = evolution. >>=20 >> Going for a string representation repeats the feature of XML YANG = (which was ported over to JSON YANG): >>=20 >> typedef foo { >> type union { >> type enumeration { >> enum red { value 1; } >> enum breen { value 2; } >> enum glue { value 3; } >> } >> type enumeration { >> enum tacks { value 1; } >> enum nails { value 2; } >> enum glue { value 3; } >> } >> } >> } >>=20 >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of = the enumerations are being used. >>=20 >> Using SIDs, we can do better. >>=20 >> So what do we have to do to get the SID tool to allocate SIDs for = enum values? >>=20 >> We could then define the CBOR tag for enums in unions to take the = usual SID difference (delta relative to the environment, I=E2=80=99d = think), not an integer value. >>=20 >> Several of us are at the hackathon and could make something happen = today and tomorrow. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: >>>=20 >>> I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. >>>=20 >>> E.g. if someone switched from XML to CBOR, suddenly the = configuration or state data may have a different meaning. >>>=20 >>> Thanks, >>> Rob >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Carsten Bormann >>>> Sent: 22 March 2019 16:08 >>>> To: Michel Veillette >>>> Cc: Rob Wilton (rwilton) ; core@ietf.org; >>>> netconf@ietf.org >>>> Subject: Re: [netconf] YANG encoding in CBOR >>>>=20 >>>> On Mar 22, 2019, at 16:45, Michel Veillette = >>>> wrote: >>>>>=20 >>>>> The only potential problem I aware is when multiple enumerations = are part of >>>> the same union. >>>>> Value 4 from enumeration A will be encoded the same way as Value 4 = from >>>> enumeration B. >>>>=20 >>>> =E2=80=A6 and that is not a problem for the XML version, because = the string is being used >>>> instead of the value. (But then if two enumerations share a = string, you have the >>>> equivalent problem in the XML serialization.) >>>>=20 >>>> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that = actually has this >>>> problem, so I would be a bit reluctant to make CBOR-based = implementations >>>> more complex (and less efficient) so solve this (non-?)problem. >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 >=20 > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> Well, if that is a problem, we can go for a longer representation = within unions (section 6.12). Theoretically, we could do that only of = there is more than one enum in the union type (so things stay efficient = if there is only one), but that might pose difficulties with model = evolution. >>=20 >> Going for a string representation repeats the feature of XML YANG = (which was ported over to JSON YANG): >>=20 >> typedef foo { >> type union { >> type enumeration { >> enum red { value 1; } >> enum breen { value 2; } >> enum glue { value 3; } >> } >> type enumeration { >> enum tacks { value 1; } >> enum nails { value 2; } >> enum glue { value 3; } >> } >> } >> } >>=20 >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of = the enumerations are being used. >>=20 >> Using SIDs, we can do better. >>=20 >> So what do we have to do to get the SID tool to allocate SIDs for = enum values? >>=20 >> We could then define the CBOR tag for enums in unions to take the = usual SID difference (delta relative to the environment, I=E2=80=99d = think), not an integer value. >>=20 >> Several of us are at the hackathon and could make something happen = today and tomorrow. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: >>>=20 >>> I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. >>>=20 >>> E.g. if someone switched from XML to CBOR, suddenly the = configuration or state data may have a different meaning. >>>=20 >>> Thanks, >>> Rob >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Carsten Bormann >>>> Sent: 22 March 2019 16:08 >>>> To: Michel Veillette >>>> Cc: Rob Wilton (rwilton) ; core@ietf.org; >>>> netconf@ietf.org >>>> Subject: Re: [netconf] YANG encoding in CBOR >>>>=20 >>>> On Mar 22, 2019, at 16:45, Michel Veillette = >>>> wrote: >>>>>=20 >>>>> The only potential problem I aware is when multiple enumerations = are part of >>>> the same union. >>>>> Value 4 from enumeration A will be encoded the same way as Value 4 = from >>>> enumeration B. >>>>=20 >>>> =E2=80=A6 and that is not a problem for the XML version, because = the string is being used >>>> instead of the value. (But then if two enumerations share a = string, you have the >>>> equivalent problem in the XML serialization.) >>>>=20 >>>> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that = actually has this >>>> problem, so I would be a bit reluctant to make CBOR-based = implementations >>>> more complex (and less efficient) so solve this (non-?)problem. >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 >=20 From nobody Sat Mar 23 06:35:33 2019 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 5971012795E; Sat, 23 Mar 2019 06:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 jvr6EQVbYalG; Sat, 23 Mar 2019 06:35:23 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18E9128664; Sat, 23 Mar 2019 06:35:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4B0278B2; Sat, 23 Mar 2019 14:35:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 9Fk1rxaIeq-w; Sat, 23 Mar 2019 14:35:21 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 23 Mar 2019 14:35:21 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E213200A6; Sat, 23 Mar 2019 14:35:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id MsqfPOtV-UwO; Sat, 23 Mar 2019 14:35:20 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5F566200A5; Sat, 23 Mar 2019 14:35:20 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sat, 23 Mar 2019 14:35:19 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 6C88530077AB2F; Sat, 23 Mar 2019 14:35:19 +0100 (CET) Date: Sat, 23 Mar 2019 14:35:19 +0100 From: Juergen Schoenwaelder To: Carsten Bormann CC: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 23 Mar 2019 13:35:26 -0000 On Sat, Mar 23, 2019 at 11:27:08AM +0100, Carsten Bormann wrote: > On Mar 23, 2019, at 11:10, Juergen Schoenwaelder wrote: > >=20 > > I think we need to look at the whole picture and in which direction w= e > > want to go. In the longer term, I would prefer a solution where the > > values of a union are discriminated. The current XML encoding > > behaviour of =E2=80=98first match wins' >=20 > Can you point to chapter and verse? RFC 7950 section 9.12: When generating an XML encoding, a value is encoded according to the rules of the member type to which the value belongs. When interpreting an XML encoding, a value is validated consecutively against each member type, in the order they are specified in the "type" statement, until a match is found. The type that matched will be the type of the value for the node that was validated, and the encoding is interpreted according to the rules for that type. =20 > > is fragile (for example, if someone > > adds an enum to a type, the interpretation of data can change). > >=20 > > Look at this: > >=20 > > typedef bar { > > type union { > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > type uint8; > > } > > } > >=20 > > We have some encodings that send the string representations of the > > values and some encodings that prefer to send numeric representations > > where possible. In order to have a robust solution, encodings should > > likely indicate to which type the value belongs. >=20 > In a serialization that has more type information (such as yang-cbor), = you can reliably distinguish any usage of the uint8 from the usage of the= enumerations. We put in the CBOR tags to enable that even though enumer= ation values are normally represented by their =E2=80=9Cvalue=E2=80=9D fi= eld. The JSON encoding (RFC 7951 section 6.10) also can distinguish between the enum and the uint8 but it can't distinguish between other types that all map to a JSON string. Can the CBOR encoding distinguish between two uint8 values (or two string values) in a union? typedef temperature { type union { type fahrenheit; // an int16 type celsius; // an int16 } } > The part that I don=E2=80=99t understand is what is the plan with handl= ing conflicts between the enumerations. Depends on what you consider a conflict. My problem is that I see three encodings that all appear to do something slightly different and the problem seems to be that YANG kind of defers the interpretation of unions to encodings. Things would be robust if even the above case would be unambiguous in all encodings, i.e., the union would be a discriminated or tagged union. /js > I=E2=80=99m not sure what the equivalence model is, here =E2=80=94 do Y= ANG enums employ structural equivalence? There is no name up there, so i= t can=E2=80=99t really be name equivalence, unless there is an implicit n= ame being inferred from the schema tree. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 >=20 > >=20 > > /js > >=20 > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > >> Well, if that is a problem, we can go for a longer representation wi= thin unions (section 6.12). Theoretically, we could do that only of ther= e is more than one enum in the union type (so things stay efficient if th= ere is only one), but that might pose difficulties with model evolution. > >>=20 > >> Going for a string representation repeats the feature of XML YANG (w= hich was ported over to JSON YANG): > >>=20 > >> typedef foo { > >> type union { > >> type enumeration { > >> enum red { value 1; } > >> enum breen { value 2; } > >> enum glue { value 3; } > >> } > >> type enumeration { > >> enum tacks { value 1; } > >> enum nails { value 2; } > >> enum glue { value 3; } > >> } > >> } > >> } > >>=20 > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of t= he enumerations are being used. > >>=20 > >> Using SIDs, we can do better. > >>=20 > >> So what do we have to do to get the SID tool to allocate SIDs for en= um values? > >>=20 > >> We could then define the CBOR tag for enums in unions to take the us= ual SID difference (delta relative to the environment, I=E2=80=99d think)= , not an integer value. > >>=20 > >> Several of us are at the hackathon and could make something happen t= oday and tomorrow. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >>=20 > >>=20 > >>> On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: > >>>=20 > >>> I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. > >>>=20 > >>> E.g. if someone switched from XML to CBOR, suddenly the configurati= on or state data may have a different meaning. > >>>=20 > >>> Thanks, > >>> Rob > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: Carsten Bormann > >>>> Sent: 22 March 2019 16:08 > >>>> To: Michel Veillette > >>>> Cc: Rob Wilton (rwilton) ; core@ietf.org; > >>>> netconf@ietf.org > >>>> Subject: Re: [netconf] YANG encoding in CBOR > >>>>=20 > >>>> On Mar 22, 2019, at 16:45, Michel Veillette > >>>> wrote: > >>>>>=20 > >>>>> The only potential problem I aware is when multiple enumerations = are part of > >>>> the same union. > >>>>> Value 4 from enumeration A will be encoded the same way as Value = 4 from > >>>> enumeration B. > >>>>=20 > >>>> =E2=80=A6 and that is not a problem for the XML version, because t= he string is being used > >>>> instead of the value. (But then if two enumerations share a strin= g, you have the > >>>> equivalent problem in the XML serialization.) > >>>>=20 > >>>> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that act= ually has this > >>>> problem, so I would be a bit reluctant to make CBOR-based implemen= tations > >>>> more complex (and less efficient) so solve this (non-?)problem. > >>>>=20 > >>>> Gr=C3=BC=C3=9Fe, Carsten > >>>=20 > >>>=20 > >>>=20 > >>=20 > >> _______________________________________________ > >> netconf mailing list > >> netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > Fax: +49 421 200 3103 > >=20 > >=20 > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > >> Well, if that is a problem, we can go for a longer representation wi= thin unions (section 6.12). Theoretically, we could do that only of ther= e is more than one enum in the union type (so things stay efficient if th= ere is only one), but that might pose difficulties with model evolution. > >>=20 > >> Going for a string representation repeats the feature of XML YANG (w= hich was ported over to JSON YANG): > >>=20 > >> typedef foo { > >> type union { > >> type enumeration { > >> enum red { value 1; } > >> enum breen { value 2; } > >> enum glue { value 3; } > >> } > >> type enumeration { > >> enum tacks { value 1; } > >> enum nails { value 2; } > >> enum glue { value 3; } > >> } > >> } > >> } > >>=20 > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of t= he enumerations are being used. > >>=20 > >> Using SIDs, we can do better. > >>=20 > >> So what do we have to do to get the SID tool to allocate SIDs for en= um values? > >>=20 > >> We could then define the CBOR tag for enums in unions to take the us= ual SID difference (delta relative to the environment, I=E2=80=99d think)= , not an integer value. > >>=20 > >> Several of us are at the hackathon and could make something happen t= oday and tomorrow. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >>=20 > >>=20 > >>> On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: > >>>=20 > >>> I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. > >>>=20 > >>> E.g. if someone switched from XML to CBOR, suddenly the configurati= on or state data may have a different meaning. > >>>=20 > >>> Thanks, > >>> Rob > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: Carsten Bormann > >>>> Sent: 22 March 2019 16:08 > >>>> To: Michel Veillette > >>>> Cc: Rob Wilton (rwilton) ; core@ietf.org; > >>>> netconf@ietf.org > >>>> Subject: Re: [netconf] YANG encoding in CBOR > >>>>=20 > >>>> On Mar 22, 2019, at 16:45, Michel Veillette > >>>> wrote: > >>>>>=20 > >>>>> The only potential problem I aware is when multiple enumerations = are part of > >>>> the same union. > >>>>> Value 4 from enumeration A will be encoded the same way as Value = 4 from > >>>> enumeration B. > >>>>=20 > >>>> =E2=80=A6 and that is not a problem for the XML version, because t= he string is being used > >>>> instead of the value. (But then if two enumerations share a strin= g, you have the > >>>> equivalent problem in the XML serialization.) > >>>>=20 > >>>> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that act= ually has this > >>>> problem, so I would be a bit reluctant to make CBOR-based implemen= tations > >>>> more complex (and less efficient) so solve this (non-?)problem. > >>>>=20 > >>>> Gr=C3=BC=C3=9Fe, Carsten > >>>=20 > >>>=20 > >>>=20 > >>=20 > >> _______________________________________________ > >> netconf mailing list > >> netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > Fax: +49 421 200 3103 > >=20 > >=20 >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Mar 23 17:27:54 2019 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 69B6B12797A; Sat, 23 Mar 2019 17:27:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155338727338.15565.5871340473693646708@ietfa.amsl.com> Date: Sat, 23 Mar 2019 17:27:53 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-echo-request-tag-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 00:27:54 -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 : CoAP: Echo, Request-Tag, and Token Processing Authors : Christian Amsüss John Mattsson Göran Selander Filename : draft-ietf-core-echo-request-tag-04.txt Pages : 24 Date : 2019-03-23 Abstract: This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match Block-Wise message fragments belonging to the same request. The updated Token processing requirements for clients ensure secure binding of responses to requests when CoAP is used with security. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-echo-request-tag-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-echo-request-tag-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 24 02:47:45 2019 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 97455127979; Sun, 24 Mar 2019 02:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 LBsRUhASQU8W; Sun, 24 Mar 2019 02:47:40 -0700 (PDT) Received: from smtp.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 BF83312785F; Sun, 24 Mar 2019 02:47:39 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44Rsy15ShKzyWC; Sun, 24 Mar 2019 10:47:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> Date: Sun, 24 Mar 2019 10:47:36 +0100 Cc: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575113655.050311-985b8fd567a067a29b90e8ebdddf768f Content-Transfer-Encoding: quoted-printable Message-Id: <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 24 Mar 2019 09:47:42 -0000 On Mar 23, 2019, at 14:35, Juergen Schoenwaelder = wrote: >=20 > RFC 7950 section 9.12: Thank you, this is very useful. Let me try to ask my other question in a very concrete way: If I have > typedef foo { > type union { > type enumeration { > enum red { value 1; } > enum breen { value 2; } > enum glue { value 3; } > } > type enumeration { > enum tacks { value 1; } > enum nails { value 2; } > enum glue { value 3; } > } > } > } in one place, and > typedef bar { > type union { > type enumeration { > enum red { value 1; } > enum breen { value 2; } > enum glue { value 3; } > } > type enumeration { > enum sparkling { value 1; } > enum blinking { value 2; } > enum steady { value 3; } > } > } > } in another place, is the value =E2=80=9Cred=E2=80=9D between the two = types referring to the =E2=80=9Csame thing=E2=80=9D? If there were a typedef for the two anonymous enumerations that both = look the same, as in typedef color { > type enumeration { > enum red { value 1; } > enum breen { value 2; } > enum glue { value 3; } > } } and that typedef being referenced from both unions instead of = copy-pasting it, would that change the answer? Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Mar 24 04:30:02 2019 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 D80E61200B3 for ; Sun, 24 Mar 2019 04:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYTdJJ3aFZMc for ; Sun, 24 Mar 2019 04:29:59 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 98C00128BE6 for ; Sun, 24 Mar 2019 04:29:58 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id 10so4118493lfr.8 for ; Sun, 24 Mar 2019 04:29:58 -0700 (PDT) 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=86u4rCtozzj8VkUZGpOwDr1VvmXXNVeMmeKVB4jZp0Y=; b=ed+RnGxUruuJ5yZMRXzBODo9flZKHhCQEf6zB25R2PpEujTh4BgwyzfbJ4nMsmVWoQ lu+gVzClXcfmqlVxmaMJdw1Dsw+R+VtbomLkX0PHeWN/oBCMHyDmQDLw7YJZwerWoMND Nx38i39gY7YFId7Yfdue1mg1b4+JujpWfF2j0/XDADm6XFmEH2JMr0RVFn6m3TCy3sQJ Nuz6+4qXg5xaY97Y1YW4EAVpRtLToC6qNrgeI4vaEIxm2iLWnDNr5u7esHXt0i3HUBqn 9WO4TkOndg3yubMqYRu76Ex5GHoukBO9aQRw4lhuFhN5hb6PM/mgspxPSVFz/TJNT+C1 ynYg== 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=86u4rCtozzj8VkUZGpOwDr1VvmXXNVeMmeKVB4jZp0Y=; b=U71U0xNoUTz8jrnGThG3il1NIbsZGIkQSfXZkq6awLa+OL+wBwTDaOnjyNGtuyxzHF SN6JvS5cS1C6CGyTgXJ8YnjE1vMM8UB7Z7/sPOfWBPMKn4p0pxr4vYrV5bZsLmc9bmnV ddmSgm3E1eUlE7fRBCY5PUp3hGGpA/zyxjbssBTga1odJXG6LR00m7+V9uHz72Uq0635 DFVhpQWRu99+okxsUF0kaszvWWq7DiDDvji5LWwmLJNtlgh4Q7pStSe+9qPvubUmlYvV vcxvTy7QMc2ewRbsb23pbvVqndRj10iDEl3VONFPRnc09BVdK+pO6w0d6mPMMv7NjZi1 d9jg== X-Gm-Message-State: APjAAAVKeO3XRDbS9cA7Z7+q3TJGQfhCPV1rpERk4EeoNhlnD2gZPPN/ ZY28QLvMPg5oIl4ZLrFhabGc3d+jPhUZwDqaGCLCFg== X-Google-Smtp-Source: APXvYqxXyt4mZu+8LXD+16/Omjo/DtPZNlwK9g9seEjVPHxQCvDmFIzNinkW7LdjCkr64k37KqBmwQNo80yYwQbZAC8= X-Received: by 2002:ac2:569b:: with SMTP id 27mr10336213lfr.24.1553426996571; Sun, 24 Mar 2019 04:29:56 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> In-Reply-To: <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> From: Andy Bierman Date: Sun, 24 Mar 2019 04:29:45 -0700 Message-ID: To: Carsten Bormann Cc: Juergen Schoenwaelder , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="00000000000050d1ab0584d56848" Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 24 Mar 2019 11:30:01 -0000 --00000000000050d1ab0584d56848 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 24, 2019 at 2:47 AM Carsten Bormann wrote: > On Mar 23, 2019, at 14:35, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > RFC 7950 section 9.12: > > Thank you, this is very useful. > > Let me try to ask my other question in a very concrete way: > > If I have > > > typedef foo { > > type union { > > type enumeration { > > enum red { value 1; } > > enum breen { value 2; } > > enum glue { value 3; } > > } > > type enumeration { > > enum tacks { value 1; } > > enum nails { value 2; } > > enum glue { value 3; } > > } > > } > > } > > in one place, and > > > typedef bar { > > type union { > > type enumeration { > > enum red { value 1; } > > enum breen { value 2; } > > enum glue { value 3; } > > } > > type enumeration { > > enum sparkling { value 1; } > > enum blinking { value 2; } > > enum steady { value 3; } > > } > > } > > } > > in another place, is the value =E2=80=9Cred=E2=80=9D between the two type= s referring to > the =E2=80=9Csame thing=E2=80=9D? > > no -- and this is not an error, although it is position-dependent: typedef baz { type union { type foo; type bar; } } The issue for CBOR applies to both bits and enumerations. The probability of 2 enum names clashing is almost zero. The probability of 2 value-stmts clashing is almost 100% The answer seems to be simple but inefficient: Always encode bits or enumeration as a string, if this is within a union type. There are not many of these -- more likely to find strings with different patterns where first-match-wins is no different than before (for XML) > If there were a typedef for the two anonymous enumerations that both look > the same, as in > > typedef color { > > type enumeration { > > enum red { value 1; } > > enum breen { value 2; } > > enum glue { value 3; } > > } > } > > and that typedef being referenced from both unions instead of copy-pastin= g > it, would that change the answer? > > I think first-match-wins still dictates the result. The JSON issue (and maybe CBOR) is what Juergen is talking about: typedef maybe-first { type union { type string; type int32; } } Use 42 as an example... The XML encoding 42 will always match string. The JSON (or CBOR) encoding { "foo": 42 } will always match int32 We want YANG data to maintain fidelity and still be encoding-independent, but this is broken for union types. Gr=C3=BC=C3=9Fe, Carsten > > Andy > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000050d1ab0584d56848 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 24, 2019 at 2:47 AM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
On Mar 23, 2019,= at 14:35, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>
> RFC 7950 section 9.12:

Thank you, this is very useful.

Let me try to ask my other question in a very concrete way:

If I have

> typedef foo {
>=C2=A0 type union {
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum red { value 1; }
>=C2=A0 =C2=A0 =C2=A0 enum breen { value 2; }
>=C2=A0 =C2=A0 =C2=A0 enum glue { value 3; }
>=C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum tacks { value 1; }
>=C2=A0 =C2=A0 =C2=A0 enum nails { value 2; }
>=C2=A0 =C2=A0 =C2=A0 enum glue { value 3; }
>=C2=A0 =C2=A0 }
>=C2=A0 }
> }

in one place, and

> typedef bar {
>=C2=A0 type union {
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum red { value 1; }
>=C2=A0 =C2=A0 =C2=A0 enum breen { value 2; }
>=C2=A0 =C2=A0 =C2=A0 enum glue { value 3; }
>=C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum sparkling { value 1; }
>=C2=A0 =C2=A0 =C2=A0 enum blinking { value 2; }
>=C2=A0 =C2=A0 =C2=A0 enum steady { value 3; }
>=C2=A0 =C2=A0 }
>=C2=A0 }
> }

in another place, is the value =E2=80=9Cred=E2=80=9D between the two types = referring to the =E2=80=9Csame thing=E2=80=9D?






where first-match-wins is no different than before (for XML)
If there were a typedef for the two anonymous enumerations that both look t= he same, as in

=C2=A0 typedef color {
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum red { value 1; }
>=C2=A0 =C2=A0 =C2=A0 enum breen { value 2; }
>=C2=A0 =C2=A0 =C2=A0 enum glue { value 3; }
>=C2=A0 =C2=A0 }
=C2=A0 }

and that typedef being referenced from both unions instead of copy-pasting = it, would that change the answer?





--00000000000050d1ab0584d56848-- From nobody Sun Mar 24 07:40:54 2019 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 3EBAC129619; Sun, 24 Mar 2019 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 1CBn5dZGZMGD; Sun, 24 Mar 2019 07:40:51 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2C71294B6; Sun, 24 Mar 2019 07:40:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DF52D3D; Sun, 24 Mar 2019 15:40:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id WSV4IvdO_E7T; Sun, 24 Mar 2019 15:40:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sun, 24 Mar 2019 15:40:49 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id C80AB200A7; Sun, 24 Mar 2019 15:40:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id B8S7xlLUImxj; Sun, 24 Mar 2019 15:40:49 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 6B02B200A6; Sun, 24 Mar 2019 15:40:49 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sun, 24 Mar 2019 15:40:48 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 8781230077BEFE; Sun, 24 Mar 2019 15:40:48 +0100 (CET) Date: Sun, 24 Mar 2019 15:40:48 +0100 From: Juergen Schoenwaelder To: Andy Bierman CC: Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190324144048.xz3ovvuyqaygoimy@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 24 Mar 2019 14:40:53 -0000 On Sun, Mar 24, 2019 at 04:29:45AM -0700, Andy Bierman wrote: > On Sun, Mar 24, 2019 at 2:47 AM Carsten Bormann wrote: >=20 > > On Mar 23, 2019, at 14:35, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > RFC 7950 section 9.12: > > > > Thank you, this is very useful. > > > > Let me try to ask my other question in a very concrete way: > > > > If I have > > > > > typedef foo { > > > type union { > > > type enumeration { > > > enum red { value 1; } > > > enum breen { value 2; } > > > enum glue { value 3; } > > > } > > > type enumeration { > > > enum tacks { value 1; } > > > enum nails { value 2; } > > > enum glue { value 3; } > > > } > > > } > > > } > > > > in one place, and > > > > > typedef bar { > > > type union { > > > type enumeration { > > > enum red { value 1; } > > > enum breen { value 2; } > > > enum glue { value 3; } > > > } > > > type enumeration { > > > enum sparkling { value 1; } > > > enum blinking { value 2; } > > > enum steady { value 3; } > > > } > > > } > > > } > > > > in another place, is the value =E2=80=9Cred=E2=80=9D between the two = types referring to > > the =E2=80=9Csame thing=E2=80=9D? > > > > >=20 > no -- and this is not an error, although it is position-dependent: >=20 > typedef baz { > type union { > type foo; > type bar; > } > } >=20 > The issue for CBOR applies to both bits and enumerations. > The probability of 2 enum names clashing is almost zero. > The probability of 2 value-stmts clashing is almost 100% Enum names like 'unknown' do have a probability to clash that is larger than 0%. =20 > The answer seems to be simple but inefficient: > Always encode bits or enumeration as a string, if this is within a unio= n > type. > There are not many of these -- more likely to find strings with differe= nt > patterns > where first-match-wins is no different than before (for XML) The first match wins rule is debatable. Someone adds an enum to an enumeration that you import and suddenly the interpretation of config changes. Not very robust. > > If there were a typedef for the two anonymous enumerations that both = look > > the same, as in > > > > typedef color { > > > type enumeration { > > > enum red { value 1; } > > > enum breen { value 2; } > > > enum glue { value 3; } > > > } > > } > > > > and that typedef being referenced from both unions instead of copy-pa= sting > > it, would that change the answer? > > > > >=20 > I think first-match-wins still dictates the result. >=20 > The JSON issue (and maybe CBOR) is what Juergen is talking about: >=20 > typedef maybe-first { > type union { > type string; > type int32; > } > } >=20 > Use 42 as an example... > The XML encoding 42 will always match string. > The JSON (or CBOR) encoding { "foo": 42 } will always match int32 > We want YANG data to maintain fidelity and still be encoding-independen= t, > but this is broken for union types. If we plan to improve things we have we should improve the union construct by turning it into a tagged union (and do away with the 'first match wins' rule but leave it for backwards compatibility for untagged unions as long as they are used). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Mar 24 13:53:34 2019 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 4880B1200F1 for ; Sun, 24 Mar 2019 13:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 iSKII4_ilhLs for ; Sun, 24 Mar 2019 13:53:30 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9411200C4 for ; Sun, 24 Mar 2019 13:53:30 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id C4B3D40225 for ; Sun, 24 Mar 2019 21:53:26 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 00EE736 for ; Sun, 24 Mar 2019 21:53:25 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [83.208.252.99]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9E3967A for ; Sun, 24 Mar 2019 21:53:25 +0100 (CET) Received: (nullmailer pid 16007 invoked by uid 1000); Sun, 24 Mar 2019 20:53:23 -0000 Date: Sun, 24 Mar 2019 21:53:23 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core WG Message-ID: <20190324205323.GA9387@hephaistos.amsuess.com> References: <20190321084706.GA17128@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <20190321084706.GA17128@hephaistos.amsuess.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Observe updates, and call for proxy implementations 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, 24 Mar 2019 20:53:33 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello WG, brief update after some discussion primarily with Klaus: On Thu, Mar 21, 2019 at 09:47:08AM +0100, Christian Ams=FCss wrote: > * Block1 and Observe. Observe came first, so blockwise needs to be fixed. It's not this thread's problem, issue closed. More seriously: The behavior that probably follows from RFC8132 (fetch) and observation seems simple, but the handling of observation resumption is not trivial (in some cases sending the last Block1 request can be sufficient to resume, sometimes the whole request operation needs to be resumed). Next step: Sketch it up for corr-clar. > * Pinning of response content formats. Seemed to be a straightforward idea at the time that wasn't throught through in combination with what we know now (how could it). Next step: Write update text, decide whether to spool it with any other document or do a single-page update document that removes the restriction. State that no proxies are known to enforce it. (Can't just sit-and-wait in corr-clar as that is needed for any type of pubsub that switch between empty-thing and value representations). > * Pinning of all request options except ETag. This one is not that simple, but in no hurry to solve. Adding ETags has the (maybe unique) property that a response that the meaning of responses is not modified; if any request reaffirming messages get mixed up, worst to happen is a 2.01 rather than a 2.03. It might be a good idea to steer this into deprecating ETag updates. Might also be worth looking into in combination with nontraditional responses. Next steps: Further discussion, but no hurry either. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyX7j0ACgkQOY0REtOk veHe6RAAxPfOcjRUm7brAA/9Wt140JiHXmr26CzfaNVEYMnegca2M8rrE3tmwNe/ PNjBl4JPpLb2kVbT1pz6XiLMHKi5tmgByDoZNzlQrySoBsCyKskKlFpJHSy/gKYi bKj8oovbn/qCv2ryksj5YzIQD49prfC4l1g3xJHSW3cpTcRyv38HJPiv+80fXDbO T0aS8NoQ0CG1zRz5H9EQkdsDGvWsIEFVUcZL9Ma57i5k3KA8q/XMQz/lfxA4sLhX F2jRhxNQIVgVZZ3sLcl+ipY9NslIlrcH0EwaFeDnfk8mS0klBk/D7oIgo17pwpHI 05MnzQFHX0mt4TYuW0i2rr1wheuRKE/u70wK6huO7GFVkwPsJiZQWxsPIUQ0ioIB nEcDVYTx8LX+kYQ/4j1k3/iLRRmecc+IoyTHtXuIvQF8fHXWVa/LPX3sWEfm97fN nSRbPe9X8R1Yd98s1JdBe3Cl+0MGTn4An6NYSX52C520ZS3d9qL0RJuODHlw0N3E ayBkvkeDe4ywk7XSfR1PL3jBdzbm3rUNmhO25OFsYeVSWwEyf/lEdWZkax6Yna+q GSxYH1vku7tqONN6A/2lAVvF9fGTNTHru2GtJs4ZyITmO8e2dOODL2kHhms4MJBV uZatXXJk7Lbk2RIry+i0iy8dz7C9D93bJW617RamFS092uWe8RM= =upPD -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From nobody Sun Mar 24 15:24:25 2019 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 40F29120162; Sun, 24 Mar 2019 15:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 F7QfvduC11dU; Sun, 24 Mar 2019 15:24:16 -0700 (PDT) Received: from smtp.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 6CA6D120161; Sun, 24 Mar 2019 15:24:16 -0700 (PDT) Received: from surfer-172-30-2-245-hotspot.internet-for-guests.com (107.223.broadband2.iol.cz [83.208.223.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SBl20Pwlzyhl; Sun, 24 Mar 2019 23:24:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Sun, 24 Mar 2019 23:24:12 +0100 Cc: Juergen Schoenwaelder , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575159051.249061-d1cd3989a1f1a6d61b43376ae4697251 Content-Transfer-Encoding: quoted-printable Message-Id: <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> To: Andy Bierman X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 24 Mar 2019 22:24:18 -0000 On Mar 24, 2019, at 12:29, Andy Bierman wrote: >=20 > The answer seems to be simple but inefficient: > Always encode bits or enumeration as a string, if this is within a = union type. For enum values within unions (which are already handled specially by = giving them a CBOR tag) we could simply use a SID (that we then would = have to generate for each enum value) instead of a string. We could = also extend this to enums outside unions; but here the recurrence to the = (outside unions unambiguous) value sounds better to me. Bits. Oh. Same procedure, I=E2=80=99d say. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Mar 24 15:52:38 2019 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 8EDC41201AD for ; Sun, 24 Mar 2019 15:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQesE7NWVemD for ; Sun, 24 Mar 2019 15:52:34 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A3A120196 for ; Sun, 24 Mar 2019 15:52:34 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id p14so5177051ljg.5 for ; Sun, 24 Mar 2019 15:52:34 -0700 (PDT) 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=TM8maVfyZAVSpKur4uiZMSzyyF02YYyriq21lI9lGow=; b=qxjA3Z7guLGI6LpkeuJlD4JEWg1GP4zrwVTo7sVzjbkW9DxzlSjY63+ffncfS9grjK 4gK/ryfxX8M6HumwZtliDJlakUWeD54jcoWAzPNhnR9XfZd1j2O1T2ixa0QcZzROd1nM Kw3tsfI21Y0wJcxZLxCXTUiJIn62AfJXeCZ6wHld3y4ojiF4Ie6qGi/5y9V7o8PNUFTR Jwct3DMpogLQCLkd0OJf0FyXCxgDID87BAJ3nm3/CeeCjL5yjQuh1iOhGGGRaUlrQ/KC nel9gTfH11wPe06vgC8/OXeIPIXHgiRQfrGYVHhdWnm+Be1JyW3JXWl9TOUrND5Ultga 04cQ== 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=TM8maVfyZAVSpKur4uiZMSzyyF02YYyriq21lI9lGow=; b=hJi7gRptUV5gMyfuTii1/mmy3obFSNpCq7Aaj2Pzi+UrCH+xHHf4fAUE32lVx/wuq9 z/gQwo7U887OCPegb0Zstbs69a+X8v/SCl2hgTlAAnD/+qyu0qB0pKnt+v5NMAmr5u8L p/ir/d+07v+rz22vPXeOgLRg+3OlUy4oxtuVtG8o7KZCuxlMYlEdYOppNGSHCvJRN+D/ ar0mdPR6tdV9WX2hP5/zw39818eaNYQaRKFjxl3k5z2eC3dWFrjawed5WUQ7NfAvT9oF JdNYXnJ5JpRe3dDXywN9KR5mh6ebRHF+jaXTM8PJh8Bp28L0ynAVViWBG5r45/9+cGLo MFiA== X-Gm-Message-State: APjAAAVHElDHgdnmsFZibuXiuLiWNALQX3S0fgDl4a3oc3VnnG667H+c ZHiHM1I/1e75NXAOvcKk/9XX5W6V5smZO4Y6unnDmQ== X-Google-Smtp-Source: APXvYqwj/ToUFdKyV1COGhFT29ws1WklEsfeixiu3jAcWWj3j7txvY8oVcGIrxPOfWUX1heOV6HU1CaICcVYCjAFbNM= X-Received: by 2002:a2e:8616:: with SMTP id a22mr11493244lji.173.1553467952179; Sun, 24 Mar 2019 15:52:32 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> In-Reply-To: <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> From: Andy Bierman Date: Sun, 24 Mar 2019 15:52:21 -0700 Message-ID: To: Carsten Bormann Cc: Juergen Schoenwaelder , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="00000000000075be580584def1ba" Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 24 Mar 2019 22:52:37 -0000 --00000000000075be580584def1ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 24, 2019 at 3:24 PM Carsten Bormann wrote: > On Mar 24, 2019, at 12:29, Andy Bierman wrote: > > > > The answer seems to be simple but inefficient: > > Always encode bits or enumeration as a string, if this is within a unio= n > type. > > For enum values within unions (which are already handled specially by > giving them a CBOR tag) we could simply use a SID (that we then would hav= e > to generate for each enum value) instead of a string. We could also exte= nd > this to enums outside unions; but here the recurrence to the (outside > unions unambiguous) value sounds better to me. > > Bits. Oh. Same procedure, I=E2=80=99d say. > > This seems like it would make the SID file very complicated. Not sure it would work since leaf/leaf-list can define their own types. Plus, all the enum typedefs would have to be numbered this way. Maybe the SID authors can comment on how this would be done. > Gr=C3=BC=C3=9Fe, Carsten > > Andy --00000000000075be580584def1ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 24, 2019 at 3:24 PM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
On Mar 24, 2019,= at 12:29, Andy Bierman <andy@yumaworks.com> wrote:
>
> The answer seems to be simple but inefficient:
> Always encode bits or enumeration as a string, if this is within a uni= on type.

For enum values within unions (which are already handled specially by givin= g them a CBOR tag) we could simply use a SID (that we then would have to ge= nerate for each enum value) instead of a string.=C2=A0 We could also extend= this to enums outside unions; but here the recurrence to the (outside unio= ns unambiguous) value sounds better to me.

Bits.=C2=A0 Oh.=C2=A0 Same procedure, I=E2=80=99d say.


This seems like it would make the SID = file very complicated.
Not sure it would work since leaf/leaf-lis= t can define their own types.
Plus, all the enum typedefs would h= ave to be numbered this way.
Maybe the SID authors can comment on= how this would be done.


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


Andy
=C2=A0
--00000000000075be580584def1ba-- From nobody Sun Mar 24 23:23:50 2019 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 3F96E120360; Sun, 24 Mar 2019 23:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3wgb2uN70ua; Sun, 24 Mar 2019 23:23:47 -0700 (PDT) Received: from smtp.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 C4DEE12035F; Sun, 24 Mar 2019 23:23:46 -0700 (PDT) Received: from surfer-172-30-2-245-hotspot.internet-for-guests.com (107.223.broadband2.iol.cz [83.208.223.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SPNJ5BnRz10Q6; Mon, 25 Mar 2019 07:23:44 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 25 Mar 2019 07:23:44 +0100 Cc: Juergen Schoenwaelder , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575187822.01148-4f3da4270b3f661c3b433a83b313ed81 Content-Transfer-Encoding: quoted-printable Message-Id: <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> To: Andy Bierman X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 25 Mar 2019 06:23:49 -0000 Hi Andy, > On Sun, Mar 24, 2019 at 3:24 PM Carsten Bormann wrote: > On Mar 24, 2019, at 12:29, Andy Bierman wrote: > >=20 > > The answer seems to be simple but inefficient: > > Always encode bits or enumeration as a string, if this is within a = union type. >=20 > For enum values within unions (which are already handled specially by = giving them a CBOR tag) we could simply use a SID (that we then would = have to generate for each enum value) instead of a string. We could = also extend this to enums outside unions; but here the recurrence to the = (outside unions unambiguous) value sounds better to me. >=20 > Bits. Oh. Same procedure, I=E2=80=99d say. > On Mar 24, 2019, at 23:52, Andy Bierman wrote: >=20 > This seems like it would make the SID file very complicated. Not necessarily: > Not sure it would work since leaf/leaf-list can define their own = types. > Plus, all the enum typedefs would have to be numbered this way. Right! It would amount to defining an identifier scheme for all the so far = anonymous enums (and bits defs, I gather). > Maybe the SID authors can comment on how this would be done. Well, such an identifier scheme would benefit the whole YANG ecosystem, = so you can have a transition from =E2=80=9Cfirst match wins=E2=80=9D to = proper name equivalence. So we would need to do it in a way that over = time it can become part of the core YANG definition. We can maybe cheat: Use strings for enums inside unions for now, and = values only outside. But it would be good if the SID files generated (and registered) for a = YANG module already had those enum/bits type identifiers so we only have = to do the SID generation once, so I=E2=80=99m not sure if I like = cheating; doing the SIDs for those identifiers right from the outset = would win so much more. So does anyone have an idea how such an identifier scheme might look = like? Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Mar 24 23:53:29 2019 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 7184A12025C for ; Sun, 24 Mar 2019 23:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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-u09GXNxeFu for ; Sun, 24 Mar 2019 23:53:16 -0700 (PDT) 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 8321F12035D for ; Sun, 24 Mar 2019 23:53:16 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id 4so7608125wmf.1 for ; Sun, 24 Mar 2019 23:53:16 -0700 (PDT) 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=6EMXkItCK0kpVrtZFSfnBdseXv0IoyzlCNFV9Uoc6Cg=; b=pTHtEd+lvTFdjvSH5N5XqRhTMEM/KVNAhBSvwc48SJJwx3GicVu0V4wcSBTePmY7iW sM2WEvzwjAR1szLEX0x055M4ooel3u0AeI0qBZ+Ulo9/07o/SqtaY6s7k1wrqNXDAgl4 06VaYsXNl6631FUiSq4RSEuk+SxmPi+Fuk7o+45xCz2kVf/RUqpdHilkkoqzqqo0gFXv OX+ELoz2e6xP57kPKhobnIS0J2WD7a5sziyldNXxhrbZq12O4Q0ovTYUJala3TSk51CT diYVzDX6qQOKCvvHH+54JsWkZDfX5BgvdUdEke5rhElQcmJWONKPUUVC3iFCLYEi1e3l Z8uA== 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=6EMXkItCK0kpVrtZFSfnBdseXv0IoyzlCNFV9Uoc6Cg=; b=hKwbpqchvkFXmTf/YQPUNs6Su9eMiZY1FaYVhGZ1sQm3S7o8hHP2tK0/Bnl/Cy1R5n 16cpEKrsS/CCqorQMfXxKSKh80r/NiEDAIaj4IYMVAT+6xYT1202jPc1le82Y//BUx8g EP1wIOqDddPz/hjdcxg0lFLASAMbTXTbuoRX7Vrgf2x5iVxX5hXzX6E/czGXH+EvRKvD SA2sVaTzLf/8n5rlDwkgqRji0VEu98r8ZkVYPBuMwQawpkqBNz/O1ofztFebjPniqEt1 ZHathOxWmJhag8brc81XcwmXaA23zu03l0n44Yt0DdiWuW3hUxwqAQFQxrkesZj6DNpT PAAg== X-Gm-Message-State: APjAAAV0AubUFo8sNaiIHcwrm1Q9aG2pRdCttWxWIskAMSmN2gllc8Z3 w4a7dZQPgBHo/tucGmBfpWd2a2jFOKefRHBe+SwOMA== X-Google-Smtp-Source: APXvYqyKqaozDkTQNmsPN1bMjWMucG7NQz1/PLpk/fDj/uryl40yjeXrsDu+uDVKKtovtJ56nPA/12JjWslMDCtDe40= X-Received: by 2002:a1c:7008:: with SMTP id l8mr9927014wmc.63.1553496794858; Sun, 24 Mar 2019 23:53:14 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> In-Reply-To: <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> From: ivaylo petrov Date: Mon, 25 Mar 2019 07:52:47 +0100 Message-ID: To: Carsten Bormann Cc: Andy Bierman , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009e17290584e5a821" Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 25 Mar 2019 06:53:20 -0000 --0000000000009e17290584e5a821 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, On Mon, Mar 25, 2019 at 7:23 AM Carsten Bormann wrote: > Hi Andy, > > > On Sun, Mar 24, 2019 at 3:24 PM Carsten Bormann wrote: > > On Mar 24, 2019, at 12:29, Andy Bierman wrote: > > > > > > The answer seems to be simple but inefficient: > > > Always encode bits or enumeration as a string, if this is within a > union type. > > > > For enum values within unions (which are already handled specially by > giving them a CBOR tag) we could simply use a SID (that we then would hav= e > to generate for each enum value) instead of a string. We could also exte= nd > this to enums outside unions; but here the recurrence to the (outside > unions unambiguous) value sounds better to me. > > > > Bits. Oh. Same procedure, I=E2=80=99d say. > > > > On Mar 24, 2019, at 23:52, Andy Bierman wrote: > > > > This seems like it would make the SID file very complicated. > > Not necessarily: > > > Not sure it would work since leaf/leaf-list can define their own types. > > Plus, all the enum typedefs would have to be numbered this way. > > Right! > It would amount to defining an identifier scheme for all the so far > anonymous enums (and bits defs, I gather). > > > Maybe the SID authors can comment on how this would be done. > > Well, such an identifier scheme would benefit the whole YANG ecosystem, s= o > you can have a transition from =E2=80=9Cfirst match wins=E2=80=9D to prop= er name > equivalence. So we would need to do it in a way that over time it can > become part of the core YANG definition. > > We can maybe cheat: Use strings for enums inside unions for now, and > values only outside. > But it would be good if the SID files generated (and registered) for a > YANG module already had those enum/bits type identifiers so we only have = to > do the SID generation once, so I=E2=80=99m not sure if I like cheating; d= oing the > SIDs for those identifiers right from the outset would win so much more. > > [IP]: Carsten, your idea for the good solution would be to keep the way enum values are sent now outside of unions and only send the SIDs inside unions, is that correct? If so, this sounds as a very good solution to me. It might add a bit of complexity in the SID generation, but I would expect it to be rather small. > So does anyone have an idea how such an identifier scheme might look like= ? > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Best regards, Ivaylo Petrov --0000000000009e17290584e5a821 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif;color:#= 0b5394">On Mon, Mar 25, 2019 at 7:23 AM Carsten Bormann <cabo@tzi.org> wrote:
Hi And= y,

> On Sun, Mar 24, 2019 at 3:24 PM Carsten Bormann <cabo@tzi.org> wrote:
> On Mar 24, 2019, at 12:29, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > The answer seems to be simple but inefficient:
> > Always encode bits or enumeration as a string, if this is within = a union type.
>
> For enum values within unions (which are already handled specially by = giving them a CBOR tag) we could simply use a SID (that we then would have = to generate for each enum value) instead of a string.=C2=A0 We could also e= xtend this to enums outside unions; but here the recurrence to the (outside= unions unambiguous) value sounds better to me.
>
> Bits.=C2=A0 Oh.=C2=A0 Same procedure, I=E2=80=99d say.


> On Mar 24, 2019, at 23:52, Andy Bierman <andy@yumaworks.com> wrote:
>
> This seems like it would make the SID file very complicated.

Not necessarily:

> Not sure it would work since leaf/leaf-list can define their own types= .
> Plus, all the enum typedefs would have to be numbered this way.

Right!
It would amount to defining an identifier scheme for all the so far anonymo= us enums (and bits defs, I gather).

> Maybe the SID authors can comment on how this would be done.

Well, such an identifier scheme would benefit the whole YANG ecosystem, so = you can have a transition from =E2=80=9Cfirst match wins=E2=80=9D to proper= name equivalence.=C2=A0 So we would need to do it in a way that over time = it can become part of the core YANG definition.

We can maybe cheat:=C2=A0 Use strings for enums inside unions for now, and = values only outside.
But it would be good if the SID files generated (and registered) for a YANG= module already had those enum/bits type identifiers so we only have to do = the SID generation once, so I=E2=80=99m not sure if I like cheating; doing = the SIDs for those identifiers right from the outset would win so much more= .


[IP]: Carst= en, your idea for the good solution would be to keep the way enum values ar= e sent now outside of unions and only send the SIDs inside unions, is that = correct? If so, this sounds as a very good solution to me. It might add a b= it of complexity in the SID generation, but I would expect it to be rather = small.
=C2=A0
So does anyone have an idea how such an identifier scheme might look like?<= br>
Gr=C3=BC=C3=9Fe, Carsten

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

Best regards,
Ivaylo P= etrov
--0000000000009e17290584e5a821-- From nobody Mon Mar 25 00:53:41 2019 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 34575120373; Mon, 25 Mar 2019 00:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlRFp4zCH9JS; Mon, 25 Mar 2019 00:53:33 -0700 (PDT) Received: from smtp.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 081D81203C5; Mon, 25 Mar 2019 00:53:33 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SRMt6wVtz10fS; Mon, 25 Mar 2019 08:53:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> Date: Mon, 25 Mar 2019 08:53:35 +0100 Cc: "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575193213.31462-92804bf67652a0f2903a58c87e29ee27 Content-Transfer-Encoding: quoted-printable Message-Id: <5774A58B-6CEC-4969-8C31-D4BDAE600D69@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> To: Andy Bierman X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 25 Mar 2019 07:53:40 -0000 On Mar 25, 2019, at 07:23, Carsten Bormann wrote: >=20 > We can maybe cheat: Use strings for enums inside unions for now, and = values only outside. Or, if it takes too long to do the identifier scheme: We could define SIDs for each module for the enum and bits strings used = in that module. That would mean we=E2=80=99d have multiple SIDs for the same strings all = over the YANG universe, but it is something we don=E2=80=99t have to = wait for and can do locally. So a decoder knowing the module at all would also know what string to = imagine (it never has to be reified!) for that SID. An encoder has a = slightly harder time, as it has to use a SID from a module the decoder = will know; I=E2=80=99d imagine that won=E2=80=99t be too hard to glean = from the context though. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 25 00:58:07 2019 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 6FF2F12025C; Mon, 25 Mar 2019 00:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2lZBHeSW-h1; Mon, 25 Mar 2019 00:57:58 -0700 (PDT) Received: from smtp.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 EBC3D120370; Mon, 25 Mar 2019 00:57:57 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SRT01N79z13cY; Mon, 25 Mar 2019 08:57:56 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 25 Mar 2019 08:57:55 +0100 Cc: Andy Bierman , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575193472.169531-a1e767f94b0f600a97b0c3815ca0b763 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> To: ivaylo petrov X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 25 Mar 2019 07:58:00 -0000 On Mar 25, 2019, at 07:52, ivaylo petrov wrote: >=20 > [IP]: Carsten, your idea for the good solution would be to keep the = way enum values are sent now outside of unions and only send the SIDs = inside unions, is that correct? Yes, as most enums occur outside unions, so good design principles say = the cost of the feature of unions of enums should only be paid by those = who actually use them. > If so, this sounds as a very good solution to me. It might add a bit = of complexity in the SID generation, but I would expect it to be rather = small. I think we need to make a few examples to check out how that would look = like. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 25 01:06:58 2019 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 B9979120370; Mon, 25 Mar 2019 01:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ymlrML5U9rm; Mon, 25 Mar 2019 01:06:54 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8D41D120365; Mon, 25 Mar 2019 01:06:53 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 903AF18204C5; Mon, 25 Mar 2019 09:06:35 +0100 (CET) Received: from localhost (dhcp-82e3.meeting.ietf.org [31.133.130.227]) by trail.lhotka.name (Postfix) with ESMTPSA id E58671820047; Mon, 25 Mar 2019 09:06:18 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , Carsten Bormann Cc: Michel Veillette , "netconf\@ietf.org" , "core\@ietf.org" In-Reply-To: <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> Date: Mon, 25 Mar 2019 09:06:33 +0100 Message-ID: <871s2vqsxi.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 25 Mar 2019 08:06:57 -0000 Juergen Schoenwaelder writes: > I think we need to look at the whole picture and in which direction we > want to go. In the longer term, I would prefer a solution where the > values of a union are discriminated. The current XML encoding > behaviour of 'first match wins' is fragile (for example, if someone > adds an enum to a type, the interpretation of data can change). > > Look at this: > > typedef bar { > type union { > type enumeration { enum "1"; value 2; enum "2"; value 1; } > type uint8; > } > } > > We have some encodings that send the string representations of the > values and some encodings that prefer to send numeric representations > where possible. In order to have a robust solution, encodings should > likely indicate to which type the value belongs. Perhaps the easiest way would be to use (optional) annotation that specifies, using an ordinal number, which of the member types is used for the particular instance. But since there can be unions inside unions, a list of numbers would be needed in general. Lada > > /js > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> Well, if that is a problem, we can go for a longer representation within= unions (section 6.12). Theoretically, we could do that only of there is m= ore than one enum in the union type (so things stay efficient if there is o= nly one), but that might pose difficulties with model evolution. >>=20 >> Going for a string representation repeats the feature of XML YANG (which= was ported over to JSON YANG): >>=20 >> typedef foo { >> type union { >> type enumeration { >> enum red { value 1; } >> enum breen { value 2; } >> enum glue { value 3; } >> } >> type enumeration { >> enum tacks { value 1; } >> enum nails { value 2; } >> enum glue { value 3; } >> } >> } >> } >>=20 >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of the e= numerations are being used. >>=20 >> Using SIDs, we can do better. >>=20 >> So what do we have to do to get the SID tool to allocate SIDs for enum v= alues? >>=20 >> We could then define the CBOR tag for enums in unions to take the usual = SID difference (delta relative to the environment, I=E2=80=99d think), not = an integer value. >>=20 >> Several of us are at the hackathon and could make something happen today= and tomorrow. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wr= ote: >> >=20 >> > I guess that the concern is that this introduces more variation in how= data is interpreted between the different XML/JSON/CBOR encodings. >> >=20 >> > E.g. if someone switched from XML to CBOR, suddenly the configuration = or state data may have a different meaning. >> >=20 >> > Thanks, >> > Rob >> >=20 >> >=20 >> >> -----Original Message----- >> >> From: Carsten Bormann >> >> Sent: 22 March 2019 16:08 >> >> To: Michel Veillette >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org; >> >> netconf@ietf.org >> >> Subject: Re: [netconf] YANG encoding in CBOR >> >>=20 >> >> On Mar 22, 2019, at 16:45, Michel Veillette >> >> wrote: >> >>>=20 >> >>> The only potential problem I aware is when multiple enumerations are= part of >> >> the same union. >> >>> Value 4 from enumeration A will be encoded the same way as Value 4 f= rom >> >> enumeration B. >> >>=20 >> >> =E2=80=A6 and that is not a problem for the XML version, because the = string is being used >> >> instead of the value. (But then if two enumerations share a string, = you have the >> >> equivalent problem in the XML serialization.) >> >>=20 >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actual= ly has this >> >> problem, so I would be a bit reluctant to make CBOR-based implementat= ions >> >> more complex (and less efficient) so solve this (non-?)problem. >> >>=20 >> >> Gr=C3=BC=C3=9Fe, Carsten >> >=20 >> >=20 >> >=20 >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> Well, if that is a problem, we can go for a longer representation within= unions (section 6.12). Theoretically, we could do that only of there is m= ore than one enum in the union type (so things stay efficient if there is o= nly one), but that might pose difficulties with model evolution. >>=20 >> Going for a string representation repeats the feature of XML YANG (which= was ported over to JSON YANG): >>=20 >> typedef foo { >> type union { >> type enumeration { >> enum red { value 1; } >> enum breen { value 2; } >> enum glue { value 3; } >> } >> type enumeration { >> enum tacks { value 1; } >> enum nails { value 2; } >> enum glue { value 3; } >> } >> } >> } >>=20 >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of the e= numerations are being used. >>=20 >> Using SIDs, we can do better. >>=20 >> So what do we have to do to get the SID tool to allocate SIDs for enum v= alues? >>=20 >> We could then define the CBOR tag for enums in unions to take the usual = SID difference (delta relative to the environment, I=E2=80=99d think), not = an integer value. >>=20 >> Several of us are at the hackathon and could make something happen today= and tomorrow. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wr= ote: >> >=20 >> > I guess that the concern is that this introduces more variation in how= data is interpreted between the different XML/JSON/CBOR encodings. >> >=20 >> > E.g. if someone switched from XML to CBOR, suddenly the configuration = or state data may have a different meaning. >> >=20 >> > Thanks, >> > Rob >> >=20 >> >=20 >> >> -----Original Message----- >> >> From: Carsten Bormann >> >> Sent: 22 March 2019 16:08 >> >> To: Michel Veillette >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org; >> >> netconf@ietf.org >> >> Subject: Re: [netconf] YANG encoding in CBOR >> >>=20 >> >> On Mar 22, 2019, at 16:45, Michel Veillette >> >> wrote: >> >>>=20 >> >>> The only potential problem I aware is when multiple enumerations are= part of >> >> the same union. >> >>> Value 4 from enumeration A will be encoded the same way as Value 4 f= rom >> >> enumeration B. >> >>=20 >> >> =E2=80=A6 and that is not a problem for the XML version, because the = string is being used >> >> instead of the value. (But then if two enumerations share a string, = you have the >> >> equivalent problem in the XML serialization.) >> >>=20 >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actual= ly has this >> >> problem, so I would be a bit reluctant to make CBOR-based implementat= ions >> >> more complex (and less efficient) so solve this (non-?)problem. >> >>=20 >> >> Gr=C3=BC=C3=9Fe, Carsten >> >=20 >> >=20 >> >=20 >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Mar 25 01:10:01 2019 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 84908120372 for ; Mon, 25 Mar 2019 01:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 FQp4eEvRnuT1 for ; Mon, 25 Mar 2019 01:09:57 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF8A120370 for ; Mon, 25 Mar 2019 01:09:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7927D24 for ; Mon, 25 Mar 2019 09:09:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id YL4i6huFfopX for ; Mon, 25 Mar 2019 09:09:55 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 25 Mar 2019 09:09:55 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 653D9200A8 for ; Mon, 25 Mar 2019 09:09:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id kcw_1OBovMb6 for ; Mon, 25 Mar 2019 09:09:55 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 35068200A7 for ; Mon, 25 Mar 2019 09:09:55 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Mon, 25 Mar 2019 09:09:54 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 549F230077CF6F; Mon, 25 Mar 2019 09:09:54 +0100 (CET) Date: Mon, 25 Mar 2019 09:09:54 +0100 From: Juergen Schoenwaelder To: Message-ID: <20190325080954.kcitgr7bapz6y3wg@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: core@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: [core] move sid typedef from draft-ietf-core-comi to draft-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, 25 Mar 2019 08:09:59 -0000 Hi, draft-ietf-core-sid-05 depends on draft-ietf-core-comi-04 because it imports the definition of the sid type. I think this is a bit cumbersome and I suggest that the definition of the sid type becomes part of draft-ietf-core-sid-05. SIDs do not depend on COMI and they may be used in other protocol contexts (e.g., RESTCONF using CBOR encoding). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 25 01:13:10 2019 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 6C5EF120379; Mon, 25 Mar 2019 01:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg4uzpY_qQOm; Mon, 25 Mar 2019 01:12:56 -0700 (PDT) Received: from smtp.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 8BFB912039D; Mon, 25 Mar 2019 01:12:56 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SRpG2JvHzybw; Mon, 25 Mar 2019 09:12:54 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <871s2vqsxi.fsf@nic.cz> Date: Mon, 25 Mar 2019 09:12:53 +0100 Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575194371.287631-8b6bceeb2497f787752a48fea9763ca6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 25 Mar 2019 08:13:04 -0000 On Mar 25, 2019, at 09:06, Ladislav Lhotka wrote: >=20 > Perhaps the easiest way would be to use (optional) annotation that > specifies, using an ordinal number, which of the member types is used > for the particular instance. But since there can be unions inside > unions, a list of numbers would be needed in general. Is the sequential number of the alternative supposed to be =E2=80=9Cstable= =E2=80=9D? (I.e., would there be confusion if an alternative is inserted in the = middle? Which you may want to do while we still do =E2=80=9Cfirst match = wins=E2=80=9D.) If yes, a list of those numbers may indeed be sufficient to always stay = with values for CBOR. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 25 01:17:40 2019 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 553E8120373 for ; Mon, 25 Mar 2019 01:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkiRt-JSdgtc for ; Mon, 25 Mar 2019 01:17:36 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0032.hostedemail.com [216.40.44.32]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26D04120368 for ; Mon, 25 Mar 2019 01:17:35 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 985A418010BF3 for ; Mon, 25 Mar 2019 08:17:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:subject:reply-to :in-reply-to:references:message-id; s=key; bh=J/uVdOA6c26ghEKKNj hNt1GIuxbFQSNeytESUoL44cs=; b=DjjScOhzlpQwaG8nlNxPh3ccOHSj9R3UFo fAbUnKmta56dmaXYC9v0a5fKJUdanX6u9lBlhTGrNgWKe98jNKy7fW28iTjIgPOY /EoKIozhLBfqxWdSt1kXiFqF7aEGlmzFjU6fBcQtfyjxBQNo+Yh0zd3/11P3fyDT QG0k3+TuY= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :, RULES_HIT:41:152:355:379:582:599:962:967:973:988:989:1152:1189:1221:1260:1313:1314:1345:1359:1381:1436:1437:1516:1517:1518:1534:1540:1567:1575:1588:1589:1592:1594:1711:1714:1730:1777:1792:2198:2199:2528:2553:2559:2562:3138:3139:3140:3141:3142:3865:3866:3868:3870:3871:3872:3874:4184:4250:4321:5007:6117:6261:6657:6659:6678:7875:7903:8603:10004:10214:10400:10848:11232:11658:11914:12109:12114:12740:12895:13139:13439:14096:14180:14721:21060:21080:21433:21451:21627:30054:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:29, LUA_SUMMARY:none X-HE-Tag: voice33_7c541e0732056 X-Filterd-Recvd-Size: 2668 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf04.hostedemail.com (Postfix) with ESMTPA for ; Mon, 25 Mar 2019 08:17:34 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_65f64970d3a4bfd3dd6c3c6987f9a22a" Date: Mon, 25 Mar 2019 01:17:33 -0700 From: Peter van der Stok To: core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20190325080954.kcitgr7bapz6y3wg@anna.jacobs.jacobs-university.de> References: <20190325080954.kcitgr7bapz6y3wg@anna.jacobs.jacobs-university.de> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [31.133.149.21] Archived-At: Subject: Re: [core] move sid typedef from draft-ietf-core-comi to draft-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, 25 Mar 2019 08:17:38 -0000 --=_65f64970d3a4bfd3dd6c3c6987f9a22a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII +1 Peter Juergen Schoenwaelder schreef op 2019-03-25 01:09: > Hi, > > draft-ietf-core-sid-05 depends on draft-ietf-core-comi-04 because it > imports the definition of the sid type. I think this is a bit > cumbersome and I suggest that the definition of the sid type becomes > part of draft-ietf-core-sid-05. SIDs do not depend on COMI and they > may be used in other protocol contexts (e.g., RESTCONF using CBOR > encoding). > > /js --=_65f64970d3a4bfd3dd6c3c6987f9a22a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 +1

Peter

Juergen Schoenwaelder schreef op 2019-03-25 01:09:

= Hi,

draft-ietf-core-sid-05 depends on draft-ietf-core-comi-04 = because it
imports the definition of the sid type. I think this is a = bit
cumbersome and I suggest that the definition of the sid type beco= mes
part of draft-ietf-core-sid-05. SIDs do not depend on COMI and th= ey
may be used in other protocol contexts (e.g., RESTCONF using CBOR<= br /> encoding).

/js
--=_65f64970d3a4bfd3dd6c3c6987f9a22a-- From nobody Mon Mar 25 01:19:28 2019 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 349B1120365 for ; Mon, 25 Mar 2019 01:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeSdciv9yVk5 for ; Mon, 25 Mar 2019 01:19:24 -0700 (PDT) Received: from smtp.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 496CA120370 for ; Mon, 25 Mar 2019 01:19:24 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SRxk57LFz13cY; Mon, 25 Mar 2019 09:19:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190325080954.kcitgr7bapz6y3wg@anna.jacobs.jacobs-university.de> Date: Mon, 25 Mar 2019 09:19:22 +0100 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 575194760.249521-bfd45aa53558529b5f700369e36a8bbf Content-Transfer-Encoding: quoted-printable Message-Id: <3FF1CB41-3A23-48A1-8597-F9FA2352F1B1@tzi.org> References: <20190325080954.kcitgr7bapz6y3wg@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] move sid typedef from draft-ietf-core-comi to draft-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, 25 Mar 2019 08:19:26 -0000 Good point. So: YANG-CBOR depends on none of the other documents (but has informative = references to SID and COMI); I=E2=80=99m not sure the SID reference can = stay informative though. SID depends on none of the other documents (with an informative = reference to COMI only?). COMI needs both, of course, and also the core-yang-library (which we = still need to adopt!). Gr=C3=BC=C3=9Fe, Carsten > On Mar 25, 2019, at 09:09, Juergen Schoenwaelder = wrote: >=20 > Hi, >=20 > draft-ietf-core-sid-05 depends on draft-ietf-core-comi-04 because it > imports the definition of the sid type. I think this is a bit > cumbersome and I suggest that the definition of the sid type becomes > part of draft-ietf-core-sid-05. SIDs do not depend on COMI and they > may be used in other protocol contexts (e.g., RESTCONF using CBOR > encoding). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From nobody Mon Mar 25 01:32:55 2019 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 00F4D1203C8; Mon, 25 Mar 2019 01:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOiLA_o0pfze; Mon, 25 Mar 2019 01:32:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B34120395; Mon, 25 Mar 2019 01:30:41 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:67c:370:128:e0e6:7446:b50f:deb9]) by mail.nic.cz (Postfix) with ESMTPSA id A2A2E633D3; Mon, 25 Mar 2019 09:30:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553502639; bh=MbVdsq8Dbpd2AO3RlZhKCq0R2aLD9/ds8hAH6B0tC/k=; h=From:To:Date; b=RNkD8J+9s1QmrY/hk1aVV5B1OsKrRSStVrQKpNIHlP5mCdQ/XOzWwnNkFyjGYC9c4 m4QfmxOIDWKAd9LwpDCynBCwnz3o25J8c3yrHSIDENUJWAgJoBdAGr933iN9pFKrCO FmtFQmHtQiYgFN04ybdCFVtnDe89MuimgfTQENvY= Message-ID: <44a564649dd1d9b8947483e8a7b94d71ddcbaa51.camel@nic.cz> From: Ladislav Lhotka To: Carsten Bormann Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Date: Mon, 25 Mar 2019 09:30:39 +0100 In-Reply-To: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 25 Mar 2019 08:32:54 -0000 Carsten Bormann píše v Po 25. 03. 2019 v 09:12 +0100: > On Mar 25, 2019, at 09:06, Ladislav Lhotka wrote: > > Perhaps the easiest way would be to use (optional) annotation that > > specifies, using an ordinal number, which of the member types is used > > for the particular instance. But since there can be unions inside > > unions, a list of numbers would be needed in general. > > Is the sequential number of the alternative supposed to be “stable”? > (I.e., would there be confusion if an alternative is inserted in the middle? > Which you may want to do while we still do “first match wins”.) Inserting a new member type in the middle also affects the current algorithm for union type resolution, so it is not permitted by the module update rules (sec. 11 in RFC 7950). > > If yes, a list of those numbers may indeed be sufficient to always stay with > values for CBOR. And it is also a solution that works the same for any data representation, as long as it can encode annotations. Lada > > Grüße, Carsten > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Mar 25 01:42:38 2019 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 B7462120365; Mon, 25 Mar 2019 01:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXjtyBVnORT3; Mon, 25 Mar 2019 01:42:29 -0700 (PDT) Received: from smtp.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 8EA91120375; Mon, 25 Mar 2019 01:42:29 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SSSM3qdSzyVT; Mon, 25 Mar 2019 09:42:27 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <871s2vqsxi.fsf@nic.cz> Date: Mon, 25 Mar 2019 09:42:27 +0100 Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575196145.1692851-255ae6164aeae56d13124db86e6e1293 Content-Transfer-Encoding: quoted-printable Message-Id: <552AC13F-A862-4F72-A6BB-2385A2089194@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 25 Mar 2019 08:42:32 -0000 On Mar 25, 2019, at 09:06, Ladislav Lhotka wrote: >=20 > use (optional) annotation What do I have to read to learn more about YANG annotations? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 25 01:46:14 2019 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 D91B41203E9; Mon, 25 Mar 2019 01:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOy_BQ96vBwi; Mon, 25 Mar 2019 01:45:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890921203C0; Mon, 25 Mar 2019 01:45:57 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:67c:370:128:e0e6:7446:b50f:deb9]) by mail.nic.cz (Postfix) with ESMTPSA id 5D09C6055E; Mon, 25 Mar 2019 09:45:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553503555; bh=R0tKRbeEg+G13yGNu1lCTmH7wRcfRKgo5GLxfIuFNjE=; h=From:To:Date; b=xYjzkZb1rXK9QkN+E1cpa2cmdbsYMGRGMnqedtGQ4qSL9EK1lFp8EdkB1sVdp7U7t bEfSTErr744erNRvxLRcIbVERJLZTlckf4wX+XlYv9ksyVKAVZeYMm/l0kD15gFrog m6ZOoErnYGmbKZPW1beQ9VgPTjagwb0d9KtwUQKI= Message-ID: <07e6c05a708ed1b8010f3fc69b6dc45da8de83ea.camel@nic.cz> From: Ladislav Lhotka To: Carsten Bormann Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Date: Mon, 25 Mar 2019 09:45:55 +0100 In-Reply-To: <552AC13F-A862-4F72-A6BB-2385A2089194@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <552AC13F-A862-4F72-A6BB-2385A2089194@tzi.org> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 25 Mar 2019 08:46:04 -0000 Carsten Bormann píše v Po 25. 03. 2019 v 09:42 +0100: > On Mar 25, 2019, at 09:06, Ladislav Lhotka wrote: > > use (optional) annotation > > What do I have to read to learn more about YANG annotations? RFC 7952. Lada > > Grüße, Carsten > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Mar 25 06:06:14 2019 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 591E11203F0 for ; Mon, 25 Mar 2019 06:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 jiYdxBB7uhLF for ; Mon, 25 Mar 2019 06:06:09 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 1E90C1203FD for ; Mon, 25 Mar 2019 06:06:09 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id p10so10082884wrq.1 for ; Mon, 25 Mar 2019 06:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Pz46HY8dNZcFjV7N9MfoUYcYenc6Nw6X8sXhu+gDtQI=; b=efI7PlCVx6Qqoe7wqLFK4I0swJvkrFIOm3wwfYl09plixbS04FA7SABSaIprS7v/z2 i7N1/oRIRHbV6tH0ZwpVe8Js7iIl6SGajY3Oitg+XbOChxsdBUk0Ze+hxxY86rqEJFdZ 85CRKbqsZPuYU7OYzoWntHV+QTHRtZTNtf2kZ59hLWa+v0UXrcYrNcYxXd7OmYNWCY9O mr/MwbCZ3lV6OsFCziPOo3MXxB5+cU6XNiUlNmiog2gsyLcUiJLYqeRK+6LUfslTT/6d N+peg5ecr/gIfd8LXerpqCu8hxiBy2xQZ7W5Ta6123CndKLpEFPlpeCfo7tesOvokJdy Sh5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Pz46HY8dNZcFjV7N9MfoUYcYenc6Nw6X8sXhu+gDtQI=; b=PYLZ7tKUkGSZjMirLq7Fya6ap/EuybT/udgh3psiumeAD0/jPuJ4YsZJmwpz1diQ0l 4hHs4B2KeYDaWBeBfB6GLC4ezQw3o6PaaBnWaGXePOhzU1iepwQc4iPsN7xYPfbu6e73 Dtv+ADx1gb0qVV0GZO5xETLmTyx0v32NxAkKIzZPdjrOdBt0+lI27FkE3YcH1h4XFXMz D62woNka6COgRt/t2fCaWGYrNC8dLIg77bpYkUgvmJJ/U8tUGsWDybCifr32T47vm6L5 tA5H13ErMX43ps9wZpsyw44/E5BZbohx+M4TKM9wUlekFSWJgnoQDgxqmmxCyAQNmafI JUJA== X-Gm-Message-State: APjAAAXk4O7KEnljfwSVAw3YnFHOX3B3a6D5Ge7kDe3M2YHpG1kpUj9U CbXoQgjH9suUjyUF1agcmNeo4dgNBw/2xzLL X-Google-Smtp-Source: APXvYqwGDFK6+8y2MqvHl7hIwumYLevedcMYBKERIfGoDwmxXfeXaeqXUrT9McHrHD6f59nhDwP1LQ== X-Received: by 2002:a5d:6b4a:: with SMTP id x10mr15316420wrw.63.1553519167294; Mon, 25 Mar 2019 06:06:07 -0700 (PDT) Received: from dhcp-889a.meeting.ietf.org (dhcp-889a.meeting.ietf.org. [31.133.136.154]) by smtp.gmail.com with ESMTPSA id s21sm14731013wmh.22.2019.03.25.06.06.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 06:06:06 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7FEC9ADF-5FF7-479E-9249-231B31FD19D2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Mon, 25 Mar 2019 14:06:04 +0100 In-Reply-To: Cc: Stuart Cheshire To: "core@ietf.org" References: X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 25 Mar 2019 13:06:13 -0000 --Apple-Mail=_7FEC9ADF-5FF7-479E-9249-231B31FD19D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 21, 2019, at 5:32 PM, Jaime Jim=C3=A9nez = wrote: > Please take some time to carefully review the latest version and = provide feedback by 2019-04-17 , specially those of you that contribute = to other organisations that make use of some version of the document. Carsten asked me to look at the CORE server discovery text. It mostly = looks good, although I don=E2=80=99t understand why there are so many = options. If the intention is to have different profiles for different = types of constrained networks, it would be good to say that explicitly. = It doesn=E2=80=99t make much sense to pre-configure devices to discover = the resource directory using different mechanisms. If that is really = what is intended, then how this is going to be managed should be = discussed. The text about DNSSD is somewhat problematic: 3. It may be configured to use a service discovery mechanism such as DNS-SD [RFC6763 ]. The = present specification suggests configuring the service with name rd._sub._coap._udp, preferably within the domain of the querying nodes. DNSSD works by first enumerating services, then choosing a service from = among those services, then connecting to that service. It looks like = the idea here is that the default server name will be =E2=80=9Crd=E2=80=9D= , but that isn=E2=80=99t stated explicitly. Some discussion about how = devices are suppose to choose between advertised RD servers is necessary = here. If the intention is that only one RD server ever be present or = discoverable, then you could say that enumeration is not done at all, = but then this isn=E2=80=99t much different than just using DNS to = resolve the hostname. Based on the discussions that I=E2=80=99ve had in certain other = standards bodies on how to use Core RD, I think that leaving this very = loosely specified is probably not the right thing to do. If in fact = the intention is that other per-network-type specifications will decide = how Core RD servers will be discovered on networks of the type discussed = by those specifications, then this document should be written to = explicitly support that use. If this is the case, what is said here = isn=E2=80=99t general enough. I=E2=80=99m writing this with the goal of starting the discussion, = rather than saying what needs to be said, because I haven=E2=80=99t been = privy to the discussion that led to the text as it is written in the = current document. It would help to understand what the authors/wg had = in mind when this text was written. Thanks! --Apple-Mail=_7FEC9ADF-5FF7-479E-9249-231B31FD19D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Mar 21, 2019, at 5:32 PM, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com> wrote:
Please take some time to = carefully review the latest version and provide feedback = by 2019-04-17 , = specially those of you that contribute to other organisations that make = use of some version of the document.
Carsten asked me to look at the CORE server = discovery text.   It mostly looks good, although I don=E2=80=99t = understand why there are so many options.   If the intention is to = have different profiles for different types of constrained networks, it = would be good to say that explicitly.   It doesn=E2=80=99t make = much sense to pre-configure devices to discover the resource = directory using different mechanisms.   If that is really what is = intended, then how this is going to be managed should be = discussed.

The text about DNSSD is somewhat = problematic:

   3.  It may be configured to use a service =
discovery mechanism such as
       DNS-SD [RFC6763].=
  The present specification suggests configuring
       the service with name =
rd._sub._coap._udp, preferably within the

       domain of =
the querying nodes.

DNSSD works by first enumerating services, then choosing a = service from among those services, then connecting to that service. =  It looks like the idea here is that the default server name will = be =E2=80=9Crd=E2=80=9D, but that isn=E2=80=99t stated explicitly. =   Some discussion about how devices are suppose to choose between = advertised RD servers is necessary here.   If the intention is that = only one RD server ever be present or discoverable, then you could say = that enumeration is not done at all, but then this isn=E2=80=99t much = different than just using DNS to resolve the hostname.

Based on the discussions = that I=E2=80=99ve had in certain other standards bodies on how to use = Core RD, I think that leaving this very loosely specified is probably = not the right thing to do.   If in fact the intention is that other = per-network-type specifications will decide how Core RD servers will be = discovered on networks of the type discussed by those specifications, = then this document should be written to explicitly support that use. =   If this is the case, what is said here isn=E2=80=99t general = enough.

I=E2=80=99= m writing this with the goal of starting the discussion, rather than = saying what needs to be said, because I haven=E2=80=99t been privy to = the discussion that led to the text as it is written in the current = document.   It would help to understand what the authors/wg had in = mind when this text was written.

Thanks!

= --Apple-Mail=_7FEC9ADF-5FF7-479E-9249-231B31FD19D2-- From nobody Mon Mar 25 06:10:01 2019 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 B594C1204A3 for ; Mon, 25 Mar 2019 06:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 N6BR3sNYMxBH for ; Mon, 25 Mar 2019 06:09:56 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 7F05F12045A for ; Mon, 25 Mar 2019 06:09:56 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id o1so10033669wrs.13 for ; Mon, 25 Mar 2019 06:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=UkYwa1wfXRw6YwNHlyypAgMD6F7TeqKrNxOGZhCp/G0=; b=1+k43an8kA/d1OSwBQGqycrYzkA+4ZGKG8RoEqYyNdj9lRHLscRxjSyXKx8cXNVPE6 R5ZufqzSbAJCIyQFr+h1fGRjYuOYKXQhBXlL1wrbh+OpfPww4y4T6E9yBgQOCjn8a5DT FUAsDO4A3koZZmAwuvEiKTRn0zEDv3WybsNnBCWae0JY6Fvs41VTCgLqhnKc3KJ1XOL7 Avmx2JsEaOH1+bpJ335zPn6L/yzI75U92dTyuzouzBARPBK7J87AL/md3vP7QiXS6e2w fHcjhszKNGx16WXUgn8OarQSeuBkMZekmW0SJFXtggv30h6+VydVgembXnSn05ZwrtpQ ZeNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=UkYwa1wfXRw6YwNHlyypAgMD6F7TeqKrNxOGZhCp/G0=; b=Y5ByR4afXOxzRVEUNPTXHSbD/zghRnubcGMkaTG3fSRCaY/FgP0Syxbr3s5zOGmfag yRwmDCMoB1rAmqc6Td+h66scFpLaeRzJOFYdf5T/X4jHPZjiHCOVOl6hM9Yk5ZGm698q nKQZWVO1n3nvsgWz5R52X3BqN6waU9Ph8hYTKtb8g8RWJisrZxEirpG6bhW5lkFl4oah Jx/Q/pi8r+QvITN5jJ3sRySey+PUF+7a9ooCcXoCfINTuurpM1XsVZgPBvJunzTajxtz DbUR93U09GrABsKvbwGbwFA+7D/QSzQgUX4nD2+Upw/2ZJg0YEKNtHJou7X+XnZCqRXc Nekg== X-Gm-Message-State: APjAAAWYiZLD2SJuw5A9eyZ8AePB/CGmFLlPr1RoVPa10E1uTgbU1PhU vvuJC91c9u7w9qZg1ZLVOC60l7rRt4JXGAla X-Google-Smtp-Source: APXvYqw8+VxVSS/48ylI/3nIwINUiS0ySnH/trOAEsJ68tV/n+0Eg6FOUlpCutmjt3QAsnBHtmpdzw== X-Received: by 2002:a5d:5343:: with SMTP id t3mr16256151wrv.49.1553519394694; Mon, 25 Mar 2019 06:09:54 -0700 (PDT) Received: from dhcp-889a.meeting.ietf.org (dhcp-889a.meeting.ietf.org. [31.133.136.154]) by smtp.gmail.com with ESMTPSA id z13sm13374133wrw.36.2019.03.25.06.09.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 06:09:54 -0700 (PDT) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_0912EE40-CAD7-4568-A0AD-FE161B00C759" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Mon, 25 Mar 2019 14:09:52 +0100 References: To: "core@ietf.org" In-Reply-To: Message-Id: <669A037D-5400-4D0A-A14D-C672E4698D2B@fugue.com> X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 25 Mar 2019 13:10:00 -0000 --Apple-Mail=_0912EE40-CAD7-4568-A0AD-FE161B00C759 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Another thing to add here is that the spec also proposes using RA or = DHCP to tell the client what RD server to contact. However, in = practice it appears that different IoT frameworks use different RDs. = If it is ever going to be the case that more than one IoT framework is = in use on the same link, which I suspect is likely, then a method for = differentiating between these is necessary. This means that whatever = is offered by DHCP or RA would need to have server address/tag pairs, = rather than just addresses, with the tags used to select the RD server = based on the IoT framework that is in use by a particular device. > On Mar 25, 2019, at 2:06 PM, Ted Lemon wrote: >=20 > On Mar 21, 2019, at 5:32 PM, Jaime Jim=C3=A9nez = > wrote: >> Please take some time to carefully review the latest version and = provide feedback by 2019-04-17 , specially those of you that contribute = to other organisations that make use of some version of the document. >=20 > Carsten asked me to look at the CORE server discovery text. It = mostly looks good, although I don=E2=80=99t understand why there are so = many options. If the intention is to have different profiles for = different types of constrained networks, it would be good to say that = explicitly. It doesn=E2=80=99t make much sense to pre-configure = devices to discover the resource directory using different mechanisms. = If that is really what is intended, then how this is going to be managed = should be discussed. >=20 > The text about DNSSD is somewhat problematic: >=20 > 3. It may be configured to use a service discovery mechanism such = as > DNS-SD [RFC6763 ]. The = present specification suggests configuring > the service with name rd._sub._coap._udp, preferably within the > domain of the querying nodes. >=20 > DNSSD works by first enumerating services, then choosing a service = from among those services, then connecting to that service. It looks = like the idea here is that the default server name will be =E2=80=9Crd=E2=80= =9D, but that isn=E2=80=99t stated explicitly. Some discussion about = how devices are suppose to choose between advertised RD servers is = necessary here. If the intention is that only one RD server ever be = present or discoverable, then you could say that enumeration is not done = at all, but then this isn=E2=80=99t much different than just using DNS = to resolve the hostname. >=20 > Based on the discussions that I=E2=80=99ve had in certain other = standards bodies on how to use Core RD, I think that leaving this very = loosely specified is probably not the right thing to do. If in fact = the intention is that other per-network-type specifications will decide = how Core RD servers will be discovered on networks of the type discussed = by those specifications, then this document should be written to = explicitly support that use. If this is the case, what is said here = isn=E2=80=99t general enough. >=20 > I=E2=80=99m writing this with the goal of starting the discussion, = rather than saying what needs to be said, because I haven=E2=80=99t been = privy to the discussion that led to the text as it is written in the = current document. It would help to understand what the authors/wg had = in mind when this text was written. >=20 > Thanks! >=20 --Apple-Mail=_0912EE40-CAD7-4568-A0AD-FE161B00C759 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Another thing to add here is that the spec also proposes = using RA or DHCP to tell the client what RD server to contact.   = However, in practice it appears that different IoT frameworks use = different RDs.   If it is ever going to be the case that more than = one IoT framework is in use on the same link, which I suspect is likely, = then a method for differentiating between these is necessary.   = This means that whatever is offered by DHCP or RA would need to have = server address/tag pairs, rather than just addresses, with the tags used = to select the RD server based on the IoT framework that is in use by a = particular device.

On Mar 25, 2019, at 2:06 PM, = Ted Lemon <mellon@fugue.com> wrote:

On Mar 21, 2019, at = 5:32 PM, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com> wrote:
Please take some time to = carefully review the latest version and provide feedback = by 2019-04-17 , = specially those of you that contribute to other organisations that make = use of some version of the document.
Carsten asked me to look at the CORE = server discovery text.   It mostly looks good, although I don=E2=80=99= t understand why there are so many options.   If the intention is = to have different profiles for different types of constrained networks, = it would be good to say that explicitly.   It doesn=E2=80=99t make = much sense to pre-configure devices to discover the resource = directory using different mechanisms.   If that is really what is = intended, then how this is going to be managed should be = discussed.

The text about DNSSD is = somewhat problematic:

   3.  It may be =
configured to use a service discovery mechanism such as
       DNS-SD [RFC6763].=
  The present specification suggests configuring
 =
      the service with name rd._sub._coap._udp, preferably within =
the

       domain of the querying =
nodes.

DNSSD = works by first enumerating services, then choosing a service from among = those services, then connecting to that service.  It looks like the = idea here is that the default server name will be =E2=80=9Crd=E2=80=9D, = but that isn=E2=80=99t stated explicitly.   Some discussion about = how devices are suppose to choose between advertised RD servers is = necessary here.   If the intention is that only one RD server ever = be present or discoverable, then you could say that enumeration is not = done at all, but then this isn=E2=80=99t much different than just using = DNS to resolve the hostname.

Based on the discussions that I=E2=80=99v= e had in certain other standards bodies on how to use Core RD, I think = that leaving this very loosely specified is probably not the right thing = to do.   If in fact the intention is that other per-network-type = specifications will decide how Core RD servers will be discovered on = networks of the type discussed by those specifications, then this = document should be written to explicitly support that use.   If = this is the case, what is said here isn=E2=80=99t general = enough.

I=E2=80=99= m writing this with the goal of starting the discussion, rather than = saying what needs to be said, because I haven=E2=80=99t been privy to = the discussion that led to the text as it is written in the current = document.   It would help to understand what the authors/wg had in = mind when this text was written.

Thanks!


= --Apple-Mail=_0912EE40-CAD7-4568-A0AD-FE161B00C759-- From nobody Mon Mar 25 06:37:14 2019 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 539591203F0 for ; Mon, 25 Mar 2019 06:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgF08b2uwBfY for ; Mon, 25 Mar 2019 06:37:09 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9140D120381 for ; Mon, 25 Mar 2019 06:37:09 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5A7794380B for ; Mon, 25 Mar 2019 14:37:06 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 65F4636 for ; Mon, 25 Mar 2019 14:37:02 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2001:67c:1232:144:53b4:478e:561d:3782]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 130127A for ; Mon, 25 Mar 2019 14:37:02 +0100 (CET) Received: (nullmailer pid 18371 invoked by uid 1000); Mon, 25 Mar 2019 13:37:01 -0000 Date: Mon, 25 Mar 2019 14:37:01 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core WG Message-ID: <20190325133701.GA17631@hephaistos.amsuess.com> References: <20190321084706.GA17128@hephaistos.amsuess.com> <20190324205323.GA9387@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <20190324205323.GA9387@hephaistos.amsuess.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Observe updates, and call for proxy implementations 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, 25 Mar 2019 13:37:13 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE, On Sun, Mar 24, 2019 at 09:53:23PM +0100, Christian Ams=FCss wrote: > > * Pinning of response content formats. >=20 > Next step: Write update text, decide whether to spool it with any other > document or do a single-page update document that removes the restriction. > State that no proxies are known to enforce it. I've moved this together with the Accept-Any text from the pubsub keep-it-simple/never-reified-unions thread[1], and written a short draft[2] to specify it. Abstract: This memo defines the Accept-Any option, which provides a more flexible content negotiation than the one originally specified for the Constrained Application Protocol (CoAP) in [RFC7252]. As this is particularly useful with but ruled out in CoAP observation ([RFC7641]), that is updated to allow it. Kind regards Christian [1]: https://mailarchive.ietf.org/arch/msg/core/81SjKzfMJtSx6x8sc2P_RNq-M30 [2]: https://tools.ietf.org/html/draft-amsuess-core-accept-any-00 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyY2XoACgkQOY0REtOk veFGQBAApvYPN0VhgOSP9oEVw3ROMSasuSmKW1X06sD1+MVRhPm3R1YCOCVIqOLX BQco/ICEoKFiQ3s6bjZ8NXGQkH3JeP5wJ2ZJ7YCyypPQLbvUPfkgoAfE7h5wtsu9 f+BdSzVExeWvCB5a9BSQ36Aw7cBLyOZ0QPsk8hudNZFkP1TGgcIoyAkp15rT8FGP OhOam6GB0nmTX1K/tze9XHip11IOCl6i+BSgavPhsacV4fMIyY3JO4TUugO7lmGA W7GTIr89dLAUBKpeGt6zSnFiiXhV8W1XpX9bXfiZ6IOvqzWwl7GOsVz3o3holeGz v6XelnBHDQQZqsU/ubqBhgFsBQEee0Iv4kV/sQRHkLSsC6PAS5QvD0D4FgSRWhQg W0eXl9qSrdc6SoHz7cfNRfJzx4jE3ct0kz//V45NIi7x2EHNv8jSU5+ZbqGjZHpy FyRY2n8GEUUYAG880wqTaczzviA7i9VjUwWxIb6dlWFSw3JSX56xk45TslqBVZsE G6ja6DZPR0qFXKzHHVqqZym0QjPBqEPitNsE1ze1OVlM8B72anO7haXrtJA6Ry4s STr/Gk/S51IVVVJ04I8NJ7D2Mw6860wcIksVvTwT5Si4Jk8A9lo6WLUn/JspQKbh 42bfVqtdicsXaevjXPEE/1CSRVT+9dkupz1dGpl3baeKa/nkv18= =wdAh -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From nobody Mon Mar 25 23:16:52 2019 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 2CC0112015E; Mon, 25 Mar 2019 23:16:50 -0700 (PDT) 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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155358101013.24325.2478322663378563768@ietfa.amsl.com> Date: Mon, 25 Mar 2019 23:16:50 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-cbor-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: Tue, 26 Mar 2019 06:16:50 -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 : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Alexander Pelov Abhinav Somaraju Randy Turner Ana Minaburo Ivaylo Petrov Filename : draft-ietf-core-yang-cbor-08.txt Pages : 36 Date : 2019-03-25 Abstract: This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output and notifications defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-08 https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-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 Tue Mar 26 02:30:08 2019 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 246461202A1; Tue, 26 Mar 2019 02:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnUEsXcAJQe6; Tue, 26 Mar 2019 02:30:03 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB28120282; Tue, 26 Mar 2019 02:30:00 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id AC2EC4380B; Tue, 26 Mar 2019 10:29:58 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 30FE136; Tue, 26 Mar 2019 10:29:57 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2001:67c:370:128:7cd3:6870:45f3:3bdb]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C539774; Tue, 26 Mar 2019 10:29:56 +0100 (CET) Received: (nullmailer pid 7736 invoked by uid 1000); Tue, 26 Mar 2019 09:29:56 -0000 Date: Tue, 26 Mar 2019 10:29:56 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-stateless@ietf.org Cc: core@ietf.org Message-ID: <20190326092954.GA3240@hephaistos.amsuess.com> References: <155229700298.16968.3257053096174949406@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <155229700298.16968.3257053096174949406@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-stateless-01.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: Tue, 26 Mar 2019 09:30:06 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Klaus, On Mon, Mar 11, 2019 at 02:36:43AM -0700, internet-drafts@ietf.org wrote: > Title : Extended Tokens and Stateless Clients in the Co= nstrained Application Protocol (CoAP) > Author : Klaus Hartke > Filename : draft-ietf-core-stateless-01.txt given this is listed on today's agenda with "WGLC!", I've looked through the current version. I'm generally happy with the text. In section 3.3, I've had a hard time plucking out what the parts of the message processing those MUSTs relate to, and would have it easier if it'd either (in an informative way) briefly describe what can *not* be done in the stateless case that could be done with a short token, or give an example. Thanks for your work on this Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlyZ8RAACgkQOY0REtOk veGGNg//Q0HwmIFyBcIdHFvswDnx0kx7ig8UqDCZwi5OtwsPjS+tV0Io4vR1+0dB a1408nGwc79xLV+EoIiOKhMVHWOMCmIlJyAQQEwuAijuqnDFxqw5xHGxUkrc5xKb d+/F4wbn9toPaGi/zxcZxEOwjN9KMWB4ke7JDwElQlV6sIDaah3IAbcA1+Ig6YId +kG5hJF/2SkDglUk7XU11/xNJNRgIOdPjUjf4FKn71GHD/i9V04mjwwyCaReRyu7 3PGZzyiljjWSBnZZOvgrdXTVRqy3f7h0bNXApwzJzMLvAW2ODk8FpJZffns9R/3C drqY8Qg4vvYSALPluIIi0mr6PrJIvwgZgj+Q0ZyJrt8spdUthik64qsdTAH/Cdga c6XXKg3hZAMStebRrxgMp0Y/vr8zZhGQGUzsXKy1PtcY3YoHA59KfocxaxRDyl7N xUcy9zS5nM8iqN1uPn3c8WR+EEF6BBpC/eTMV+HPj2e8aAT4r1Es+LX/fWIzVBvO Wj/ukcUTAH6/0LSqL09hD8LR7w2AZGg0Izs+x5uapeXHe1kUfI9jdPBs1Q/SwXZI fPKu1zu0dwSfeI3DLArKlbtjXoPsQN06yBaJqZ4JVHfPo3I8D4u3B0sZpZULy/Wm jWcBghxJEKmKdPINj/OUpLeHLHBLXxzsx9fW0bHv/rlkK9RdA74= =ejwn -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From nobody Tue Mar 26 05:08:32 2019 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 982361202DC for ; Tue, 26 Mar 2019 05:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6uoNOQjbviBF for ; Tue, 26 Mar 2019 05:08:28 -0700 (PDT) Received: from smtp.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 B885B1202BC for ; Tue, 26 Mar 2019 05:08:28 -0700 (PDT) Received: from client-0071.vpn.uni-bremen.de (client-0071.vpn.uni-bremen.de [134.102.107.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44T8zb0fGYzyZn; Tue, 26 Mar 2019 13:08:27 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <155338727338.15565.5871340473693646708@ietfa.amsl.com> Date: Tue, 26 Mar 2019 13:08:26 +0100 X-Mao-Original-Outgoing-Id: 575294904.709197-9b7e53d205207d0818009c07638dc21d Content-Transfer-Encoding: quoted-printable Message-Id: <4FEAEA56-D979-4435-B5D6-EF6362E3D7FB@tzi.org> References: <155338727338.15565.5871340473693646708@ietfa.amsl.com> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-echo-request-tag-04.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: Tue, 26 Mar 2019 12:08:31 -0000 On Mar 24, 2019, at 01:27, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Constrained RESTful Environments WG = of the IETF. >=20 > Title : CoAP: Echo, Request-Tag, and Token Processing > Authors : Christian Ams=C3=BCss > John Mattsson > G=C3=B6ran Selander > Filename : draft-ietf-core-echo-request-tag-04.txt > Pages : 24 > Date : 2019-03-23 Thank you! I only have two editorial to semi-editorial comments (chairs-hat-off) = about Section 5, which can be handled during the WGLC: =E2=80=94 I don=E2=80=99t know how to formally prove that a counter is = =E2=80=9Ceasiest=E2=80=9D. So I would probably avoid the absolute. = Calling out more explicitly what scope that counter has (I.e., the = messages covered by the matching rule) might help, too. =E2=80=94 I don=E2=80=99t understand the comment about length-value = coding. There already is a length that governs the token. The encoding = informally described as =E2=80=9Co256=E2=80=9D in Appendix A.4 of = draft-bormann-coap-misc-27.txt works well for me. Maybe you mean that. = (Feel free to copy-paste that appendix.) Gr=C3=BC=C3=9Fe, Carsten # byte strings lexicographically goedelized as numbers (one+256 = coding) def o256_encode(num) str =3D empty_buffer while num > 0 num -=3D 1 str << (num & 0xFF) num >>=3D 8 end str.reverse end def o256_decode(str) num =3D 0 str.each_byte do |b| num <<=3D 8 num +=3D b + 1 end num end From nobody Tue Mar 26 05:27:00 2019 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 7DBF71202DB for ; Tue, 26 Mar 2019 05:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 AIpLKSj3vhU4 for ; Tue, 26 Mar 2019 05:26:50 -0700 (PDT) Received: from smtp.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 DCF2F1202DD for ; Tue, 26 Mar 2019 05:26:49 -0700 (PDT) Received: from client-0071.vpn.uni-bremen.de (client-0071.vpn.uni-bremen.de [134.102.107.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44T9Nl3wncz1J0Z; Tue, 26 Mar 2019 13:26:47 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 575296004.627775-d6293806e9d6576cabb496d1f6062141 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 26 Mar 2019 13:26:46 +0100 Message-Id: <621EAA51-47D9-4AF6-9261-EB3A4F2745F7@tzi.org> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] CoRE@IETF104 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, 26 Mar 2019 12:26:53 -0000 h= ttps://datatracker.ietf.org/meeting/104/materials/slides-104-core-consolid= ated-slides Presenters: please check versions and completeness. See you in 24 minutes=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 26 06:12:59 2019 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 73AC4120003 for ; Tue, 26 Mar 2019 06:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xWfj_aUVcpe3 for ; Tue, 26 Mar 2019 06:12:54 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 4FA0E120004 for ; Tue, 26 Mar 2019 06:12:54 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id y7so10169982wrn.11 for ; Tue, 26 Mar 2019 06:12:54 -0700 (PDT) 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=jGyT6dRdHrNwygRNNJLO+ne/3z85YTK+FavCCEhs96g=; b=iXK4REfSxK6gFWgbAzvL1klP6c0gaVRpAO3vSwPWXepezH/Q9ORuv4nef/n/ysi2Q+ CW+6z/iMfn2mwau0FwgpwXGkvzEvLS7fJ+ICBUIagVnnHhSbnO6a+JR1RIZhH5Yvi2RR 9iuOK0OfmN92ptKsftqhLHkicaE3w2HH7z1r5ULcXALUWDvrlvQysw8FS8woaONdls/R t94ZCoZ7t/809lKYIo3uomI7hSrlbEAV49DyyYEQak9idt/Lo6bwQ1DC2ZJWpdo8oZJd KpMc5VsFFod8Y1y/+XZ7IB0meNvpH95hsJ2+Px/2YXqAflXdie1u7dDwpzymzNCqDo0e bAVA== 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=jGyT6dRdHrNwygRNNJLO+ne/3z85YTK+FavCCEhs96g=; b=sEMfZrWUWic+rzQPTLhYswS/tRIcQ8tur22RMN/AODC9GE8zVfrvPcHT7Rd5+fOhSW vy2gZwQ/WwT6ioUMCzA7tYnrSuQd4IAymyQj77gRxKHifMTAacSW4FTCOEh5Ar7LU4q1 A5fTHGP4BfrWiPwyuaHD03ORC+6c1iI5RelRvcQBTQCl8DqI5YxRNPRrra5ZQ+SLFRxy VguZAFFdwf1h4Q1KDIgpzW0YzIejH+UCGw43U0+obouWlQ38gIzWV6fZX6UiHUlF3T8y 5w+PBH2J7Bstfq4yHICjJ/qQEMmgjDzM+ZHA9ULkeI25YgKuFsts4plB7l8EwBGMxx6e Ugmw== X-Gm-Message-State: APjAAAVr3+JVfoXOyhNNihFxqvdj7XHlvLifVS7Plw/UV71sa4L/M+Rl Cgu+fEg+cF3DYtNT3qZ7VnvO/PQCGOUXrdZ6hTvNQw== X-Google-Smtp-Source: APXvYqyNHhviVK6UEKX/jSMZvlD5VQuiQosGJJ9FzTjtl75t49Cvi2ldR4cS334TMFcC+JgGw04bM/xnn/5degEZNjs= X-Received: by 2002:a5d:6987:: with SMTP id g7mr8388277wru.299.1553605972553; Tue, 26 Mar 2019 06:12:52 -0700 (PDT) MIME-Version: 1.0 References: <20190325080954.kcitgr7bapz6y3wg@anna.jacobs.jacobs-university.de> <3FF1CB41-3A23-48A1-8597-F9FA2352F1B1@tzi.org> In-Reply-To: <3FF1CB41-3A23-48A1-8597-F9FA2352F1B1@tzi.org> From: ivaylo petrov Date: Tue, 26 Mar 2019 14:12:26 +0100 Message-ID: To: Carsten Bormann Cc: Juergen Schoenwaelder , core@ietf.org Content-Type: multipart/alternative; boundary="0000000000001d8dc40584ff140b" Archived-At: Subject: Re: [core] move sid typedef from draft-ietf-core-comi to draft-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, 26 Mar 2019 13:12:58 -0000 --0000000000001d8dc40584ff140b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Thank you for bringing it to our attention! Yes, it is already included in the next version that is currently being developed. Best regards, Ivaylo Petrov On Mon, Mar 25, 2019 at 9:19 AM Carsten Bormann wrote: > Good point. > > So: > > YANG-CBOR depends on none of the other documents (but has informative > references to SID and COMI); I=E2=80=99m not sure the SID reference can s= tay > informative though. > > SID depends on none of the other documents (with an informative reference > to COMI only?). > > COMI needs both, of course, and also the core-yang-library (which we stil= l > need to adopt!). > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > On Mar 25, 2019, at 09:09, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > Hi, > > > > draft-ietf-core-sid-05 depends on draft-ietf-core-comi-04 because it > > imports the definition of the sid type. I think this is a bit > > cumbersome and I suggest that the definition of the sid type becomes > > part of draft-ietf-core-sid-05. SIDs do not depend on COMI and they > > may be used in other protocol contexts (e.g., RESTCONF using CBOR > > encoding). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > 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 > --0000000000001d8dc40584ff140b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Thank you= for bringing it to our attention! Yes, it is already included in the next = version that is currently being developed.=C2=A0

Best regards,
Ivaylo Petrov

On Mon, Mar 25, 2019= at 9:19 AM Carsten Bormann <cabo@tzi.or= g> wrote:
Good point.

So:

YANG-CBOR depends on none of the other documents (but has informative refer= ences to SID and COMI); I=E2=80=99m not sure the SID reference can stay inf= ormative though.

SID depends on none of the other documents (with an informative reference t= o COMI only?).

COMI needs both, of course, and also the core-yang-library (which we still = need to adopt!).

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




> On Mar 25, 2019, at 09:09, Juergen Schoenwaelder <j.schoenwaelder@ja= cobs-university.de> wrote:
>
> Hi,
>
> draft-ietf-core-sid-05 depends on draft-ietf-core-comi-04 because it > imports the definition of the sid type. I think this is a bit
> cumbersome and I suggest that the definition of the sid type becomes > part of draft-ietf-core-sid-05. SIDs do not depend on COMI and they > may be used in other protocol contexts (e.g., RESTCONF using CBOR
> encoding).
>
> /js
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;https://www.jacobs-university.de/>
>
> _______________________________________________
> 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
--0000000000001d8dc40584ff140b-- From nobody Tue Mar 26 10:41:54 2019 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 D376F12049F for ; Tue, 26 Mar 2019 10:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VwNJSjaq5t5 for ; Tue, 26 Mar 2019 10:41:47 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10127.outbound.protection.outlook.com [40.107.1.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCDB120736 for ; Tue, 26 Mar 2019 10:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuni.onmicrosoft.com; s=selector1-tuni-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y/cETUsvpLG5+dWoxJT8mCke7W4M2VDQxdh/hkXn4r8=; b=Mx/3oOI/RB17GbzDuGKmLl5tQF1HBuWCcICoydz76TXQ6inkqf82rjXToRbthB9PSYO9W1gFADWpwmTTyETdbgMcW8LTK8RD4K0Y/fezO9mCf9K8Pdo8lxoU1Rp3uwoUvjMzyJX/qWaY03msmY8u1tQxrjaaBgcFLDxeLJn51AY= Received: from AM0PR08MB4482.eurprd08.prod.outlook.com (20.179.34.77) by AM0PR08MB4612.eurprd08.prod.outlook.com (20.178.83.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Tue, 26 Mar 2019 17:41:43 +0000 Received: from AM0PR08MB4482.eurprd08.prod.outlook.com ([fe80::1d2c:375b:f42d:f70b]) by AM0PR08MB4482.eurprd08.prod.outlook.com ([fe80::1d2c:375b:f42d:f70b%3]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 17:41:43 +0000 From: "Bilhanan Silverajan (TAU)" To: Core WG mailing list Thread-Topic: Protocol negotiation hallway meeting @IETF104 Thread-Index: AQHU4/stgOWqswvVtUC73OP18lKm8w== Date: Tue, 26 Mar 2019 17:41:43 +0000 Message-ID: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM6PR03CA0027.eurprd03.prod.outlook.com (2603:10a6:20b::40) To AM0PR08MB4482.eurprd08.prod.outlook.com (2603:10a6:208:140::13) authentication-results: spf=none (sender IP is ) smtp.mailfrom=bilhanan.silverajan@tuni.fi; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:1232:184:55e4:cb1d:7311:c2b5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e78f80a-a649-41d9-4a56-08d6b2124f9b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:AM0PR08MB4612; x-ms-traffictypediagnostic: AM0PR08MB4612: x-microsoft-antispam-prvs: x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(39860400002)(396003)(136003)(199004)(189003)(6506007)(31696002)(186003)(102836004)(305945005)(6116002)(6486002)(486006)(386003)(4744005)(5660300002)(7736002)(8936002)(46003)(99286004)(8676002)(106356001)(105586002)(36756003)(86362001)(97736004)(6512007)(81166006)(476003)(256004)(14454004)(81156014)(2616005)(478600001)(25786009)(6916009)(74482002)(316002)(2906002)(68736007)(53936002)(6436002)(52116002)(71190400001)(71200400001)(31686004)(786003)(11634002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR08MB4612; H:AM0PR08MB4482.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: tuni.fi does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OL+a2alTWBBzw3vdIEFzwHh7cNxtRpSqFn12JKyjuWH/yQvMWDoa6uMLix0MBcKxA2lb8vezRcyd2ughNF+wOeIk1WZi8HHsQVZGCmaKlwf8rNFjizROKWaT+S6+mX/XcZ+uGN95BBQtupbT7poXxIla9CQywx0xxMPEoop2yAdTlWOfambAze/EKCejoZYAsBniKMOORgg+kXi2W3JY/v7fjCZ0C59yI190TzBGiyj/RxVqqsZs10wBOEL8DUUtBC1mMBNLI6oUBJlWAdUUzRKrcDg/hDNERkuhnLzxHlco5zDpjXOPka6AYw613OblKz17wqAs1LlJW+2QKq9FRQ2g0VALbkKYZbYtWOYjqcachxFSzjuAo1QaO8TsY+D5OEko8HGa02bYqkUrXdiIvLY5HWdpPSRqZpErgksYzcc= Content-Type: text/plain; charset="utf-8" Content-ID: <89D5708A21803F42BC4F32F1E73E6D66@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: tuni.fi X-MS-Exchange-CrossTenant-Network-Message-Id: 5e78f80a-a649-41d9-4a56-08d6b2124f9b X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 17:41:43.7398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa6944af-cc7c-4cd8-9154-c01132798910 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4612 Archived-At: Subject: [core] Protocol negotiation hallway meeting @IETF104 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, 26 Mar 2019 17:41:53 -0000 SGVsbG8gQ29SRSwNCg0KQXMgSSBtZW50aW9uZWQgYXQgdG9kYXkncyBDb1JFIG1lZXRpbmcsIHdl J2xsIGhhdmUgYSBoYWxsd2F5IGRpc2N1c3Npb24gDQpvbiBDb0FQIHByb3RvY29sIG5lZ290aWF0 aW9uIA0KKGRyYWZ0LXNpbHZlcmFqYW4tY29yZS1jb2FwLXByb3RvY29sLW5lZ290aWF0aW9uKSBh bmQgYWxzbyBwb3NzaWJseSBvbiANCnRoZSAiY29hcCthdDoiIFVSSSBzY2hlbWUgdGhhdCBDaHJp c3RpYW4gbWVudGlvbmVkIGluIHRoZSB0MnRyZyBtZWV0aW5nLiANClBsZWFzZSBmZWVsIGZyZWUg dG8gam9pbiB1cyBpbiB0aGUgSUVURiBjb2RlIGxvdW5nZSBhdCAxMi4zMHBtIHRvbW9ycm93IA0K KFdlZG5lc2RheSkgaWYgeW91J3JlIGludGVyZXN0ZWQuDQoNCkJlc3QgcmVnYXJkcywNCg0KQmls bA0KDQoNCg== From nobody Tue Mar 26 18:12:59 2019 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 AF65C120165; Tue, 26 Mar 2019 18:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut0f4SB4HCqG; Tue, 26 Mar 2019 18:12:55 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760091.outbound.protection.outlook.com [40.107.76.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F0A12010E; Tue, 26 Mar 2019 18:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9u5WYVgClj6tJnHYMfY9F6TezUFZDpNTJkXqaVkH99Q=; b=h+Hc/VwmXxOchz6tO6LcW9MxRUzM6Bti/e1ksIrgbI8q6XN0FD2zoQvb6YxU9huTV+MqldPImRGyal4e/4LF8G57MY4sdHIx7svxqu+jsPxgNmsdQfiVQ++4tRHej0qeFk7hOFsXHxrE2axt331uYbiWpxwqwT9mwoEkpVAKvik= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4193.namprd06.prod.outlook.com (10.167.179.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Wed, 27 Mar 2019 01:12:52 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d%3]) with mapi id 15.20.1730.019; Wed, 27 Mar 2019 01:12:52 +0000 From: Michel Veillette To: Ladislav Lhotka , Juergen Schoenwaelder , Carsten Bormann CC: "netconf@ietf.org" , "core@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAL8XAAAAtt/gAAgmRkAAAJStYAAYEUIgABUqX2Q Date: Wed, 27 Mar 2019 01:12:52 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> In-Reply-To: <871s2vqsxi.fsf@nic.cz> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [184.162.192.248] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ac3ded06-5667-4074-e904-08d6b251562a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:BL0PR06MB4193; x-ms-traffictypediagnostic: BL0PR06MB4193: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0989A7979C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(366004)(136003)(39850400004)(199004)(189003)(13464003)(52314003)(6246003)(71200400001)(52536014)(97736004)(7696005)(53546011)(76176011)(106356001)(105586002)(71190400001)(6506007)(30864003)(14454004)(99286004)(966005)(8936002)(86362001)(53936002)(102836004)(2906002)(72206003)(5660300002)(45080400002)(14444005)(3846002)(5024004)(81156014)(186003)(229853002)(8676002)(6116002)(81166006)(305945005)(9686003)(55016002)(68736007)(478600001)(25786009)(316002)(7736002)(114624004)(33656002)(486006)(6436002)(93886005)(54906003)(99936001)(4326008)(110136005)(66066001)(74316002)(476003)(26005)(11346002)(446003)(6306002)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4193; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: m7Pa1E4i5yKeBbcgbOXLdPk1G9NiZmSoRiR2kmnr/L5nBqTbsDw2h/DxouWydU2PGjdCseuatF3LfLdWkTiPa8aSRODpk7rUGTJx/R5idv2+uemOTqkffaf/rHqN0xdZqrw8sHMwO02YfHNBqzSKtDAxPrsGkKytVq9jkoljjcQwq07JN80mBxICiChmt65Q6H7DO1IGYWR7/0MT8CtzBLcCDL0Z9Xl+zdMHWMuvMmVqUeQiEonIRiZEsdp6zqoriqvh0Ee+ZNXSgLeTwW/kZ7OHLNDYY2/BSHcg/bPLGGRK2zsTWMlij7uMtJ2MrlY+Q3qtSfPh6++QQN/zXZjV42i4A++zoDG/dxVsrRqr74zjpxuRvNmsLC9MfpY4SRCIIV9wmYuR1bO5EO0LTLUa1fn6AOrHt8RRLg/SShL4kA4= Content-Type: multipart/mixed; boundary="_002_BL0PR06MB5042C9AA6B4A0CCD913F50D89A580BL0PR06MB5042namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: ac3ded06-5667-4074-e904-08d6b251562a X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 01:12:52.5250 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4193 Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 27 Mar 2019 01:12:59 -0000 --_002_BL0PR06MB5042C9AA6B4A0CCD913F50D89A580BL0PR06MB5042namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGFkaXNsYXYNCg0KSWYgSSBzdW1tYXJpemUgdGhpcyBpc3N1ZSBvZiBtdWx0aXBsZSBlbnVt ZXJhdGlvbnMgb3IgYml0cyBpbiBhIHVuaW9uLCB0aGlzIHByb2JsZW0gY2FuIGJlIHNvbHZlIGJ5 IHRoZSBmb2xsb3dpbmcgYXBwcm9hY2hlczoNCg0KLSBUbyBub3QgYWxsb3dzIHRoZXNlIGR1cGxp Y2F0ZSB2YWx1ZXMgb3IgcG9zaXRpb25zIHRvIGhhcHBlbiBpbiBZQU5HDQotIFRvIGVuY29kZSBl bnVtZXJhdGlvbnMgYW5kIGJpdHMgYXMgc3RyaW5nIChpbiBhbGwgdW5pb25zIG9yIG9ubHkgd2hl biBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgb3IgYml0cyBhcmUgZGVmaW5lZCkNCi0gVG8gZW5jb2Rl IGVudW1lcmF0aW9ucyBhbmQgYml0cyBhcyBTSUQgKGluIGFsbCB1bmlvbnMgb3Igb25seSB3aGVu IG11bHRpcGxlIGVudW1lcmF0aW9ucyBvciBiaXRzIGFyZSBkZWZpbmVkKQ0KLSBUbyBlbmNvZGUg ZW51bWVyYXRpb25zIGFuZCBiaXRzIGFzIGRlbHRhIGJldHdlZW4gdGhlIHZhbHVlIFNJRCBhbmQg dGhlIGxlYWYgU0lEIChpbiBhbGwgdW5pb25zIG9yIG9ubHkgd2hlbiBtdWx0aXBsZSBlbnVtZXJh dGlvbnMgb3IgYml0cyBhcmUgZGVmaW5lZCkNCg0KSW4gdGhpcyBlbWFpbCwgSSB3aWxsIGxpa2Ug dG8gZm9jdXMgb24gdGhlIGZpcnN0IG9wdGlvbiwgZml4aW5nIHRoZSBwcm9ibGVtIGRpcmVjdGx5 IGluIFlBTkcgaW5zdGVhZCBvZiBmaXhpbmcgdGhlIGNvbnNlcXVlbmNlcy4NCg0KV2l0aG91dCBh bnkgY2hhbmdlcyBpbiBZQU5HLCBhIHVuaW9uIHdpdGggbXVsdGlwbGUgZW51bWVyYXRpb24gb3Ig Yml0cyBjYW4gYmUgY29uc3RydWN0ZWQgd2l0aG91dCB2YWx1ZSBvciBwb3NpdGlvbiBvdmVybGFw cy4NCkZvciBleGFtcGxlOg0KDQogIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25zLXRlc3QtMSB7 DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgICAgZW51 bSAiTW9uZGF5IiB7IHZhbHVlIDA7IH0NCiAgICAgICAgZW51bSAiVHVlc2RheSIgeyB2YWx1ZSAx OyB9DQogICAgICAgIGVudW0gIldlZG5lc2RheSIgeyB2YWx1ZSAyOyB9DQogICAgICAgIGVudW0g IlRodXJzZGF5IiB7IHZhbHVlIDM7IH0NCiAgICAgICAgZW51bSAiRnJpZGF5IiB7IHZhbHVlIDQ7 IH0NCg0KICAgICAgfQ0KICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICAgIGVudW0gIlNh dHVyZGF5IiB7IHZhbHVlIDU7IH0NCiAgICAgICAgZW51bSAiU3VuZGF5IiB7IHZhbHVlIDY7IH0N CiAgICAgIH0NCiAgICB9DQogIH0NCg0KICBsZWFmIG11bHRpcGxlLWJpdHMtdGVzdC0xIHsNCiAg ICB0eXBlIHVuaW9uIHsNCiAgICAgIHR5cGUgYml0cyB7DQogICAgICAgIGJpdCAgIk1vbmRheSIg eyBwb3NpdGlvbiAgMDsgfQ0KICAgICAgICBiaXQgIlR1ZXNkYXkiIHsgcG9zaXRpb24gIDE7IH0N CiAgICAgICAgYml0ICJXZWRuZXNkYXkiIHsgcG9zaXRpb24gIDI7IH0NCiAgICAgICAgYml0ICJU aHVyc2RheSIgeyBwb3NpdGlvbiAgMzsgfQ0KICAgICAgICBiaXQgIkZyaWRheSIgeyBwb3NpdGlv biAgNDsgfQ0KDQogICAgICB9DQogICAgICB0eXBlIGJpdHMgew0KICAgICAgICBiaXQgIlNhdHVy ZGF5IiB7IHBvc2l0aW9uIDU7IH0NCiAgICAgICAgYml0ICJTdW5kYXkiIHsgcG9zaXRpb24gNjsg fQ0KICAgICAgfQ0KICAgIH0NCiAgfQ0KDQpXaGVuIHVzaW5nIGFscmVhZHkgZGVmaW5lZCB0eXBl ZGVmLCBhdm9pZGluZyBvdmVybGFwIGlzIGxlc3Mgb2J2aW91cyB3aXRob3V0IHNvbWUgaGVscC4N ClRvIGhlbHAgYnVpbGRpbmcgdW5pb25zIHdpdGggYWxyZWFkeSBkZWZpbmVkIHR5cGVkZWZzLCBJ IHByb3Bvc2UgdG8gaW50cm9kdWNlIHR3byBleHRlbnNpb25zLiANCg0KICBleHRlbnNpb24gdmFs dWUtb2Zmc2V0IHsNCiAgICBhcmd1bWVudCBvZmZzZXQgew0KICAgICAgeWluLWVsZW1lbnQgdHJ1 ZTsNCiAgICB9DQogICAgZGVzY3JpcHRpb24NCiAgICAgICJPZmZzZXQgYWRkZWQgdG8gZWFjaCBl bnVtIHZhbHVlIG9mIHRoZSBhc3NvY2lhdGVkIGVudW1lcmF0aW9uLiI7DQogIH0NCiAgDQogIGV4 dGVuc2lvbiBwb3NpdGlvbi1vZmZzZXQgew0KICAgIGFyZ3VtZW50IG9mZnNldCB7DQogICAgICB5 aW4tZWxlbWVudCB0cnVlOw0KICAgIH0NCiAgICBkZXNjcmlwdGlvbg0KICAgICAgIk9mZnNldCB2 YWx1ZSBhZGRlZCB0byBlYWNoIGJpdCBwb3NpdGlvbiBvZiB0aGUgYXNzb2NpYXRlZCBiaXRzLiI7 DQogIH0NCg0KVGhlIHZhbHVlLW9mZnNldCBleHRlbnNpb24gY2FuIGJlIHVzZWQgYXMgZm9sbG93 Og0KDQogICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICBlbnVtICJNb25kYXkiOw0KICAgICAg ZW51bSAiVHVlc2RheSI7DQogICAgICBlbnVtICJXZWRuZXNkYXkiOw0KICAgICAgZW51bSAiVGh1 cnNkYXkiOw0KICAgICAgZW51bSAiRnJpZGF5IjsNCiAgICB9DQogIH0NCg0KICB0eXBlZGVmIHdl ZWtlbmQgew0KICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAgICAgZW51bSAiU2F0dXJkYXkiOw0K ICAgICAgZW51bSAiU3VuZGF5IjsNCiAgICB9DQogIH0NCiAgDQogIGxlYWYgbXVsdGlwbGUtZW51 bWVyYXRpb25zLXRlc3QtMyB7DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIHdlZWtkYXlz Ow0KICAgICAgdHlwZSB3ZWVrZW5kIHsNCiAgICAgICAgZXh0OnZhbHVlLW9mZnNldCA1Ow0KICAg ICAgfQ0KICAgIH0NCiAgfQ0KDQpUaGUgcG9zaXRpb24tb2Zmc2V0IGV4dGVuc2lvbiBjYW4gYmUg dXNlZCBhcyBmb2xsb3c6DQoNCiAgdHlwZWRlZiB3ZWVrZGF5cy1mbGFncyB7DQogICAgdHlwZSBi aXRzIHsNCiAgICAgIGJpdCAiTW9uZGF5IjsNCiAgICAgIGJpdCAiVHVlc2RheSI7DQogICAgICBi aXQgIldlZG5lc2RheSI7DQogICAgICBiaXQgIlRodXJzZGF5IjsNCiAgICAgIGJpdCAiRnJpZGF5 IjsNCiAgICB9DQogIH0NCg0KICB0eXBlZGVmIHdlZWtlbmQtZmxhZ3Mgew0KICAgIHR5cGUgYml0 cyB7DQogICAgICBiaXQgIlNhdHVyZGF5IjsNCiAgICAgIGJpdCAiU3VuZGF5IjsNCiAgICB9DQog IH0NCiAgDQogIGxlYWYgbXVsdGlwbGUtYml0cy10ZXN0LTMgew0KICAgIHR5cGUgdW5pb24gew0K ICAgICAgdHlwZSB3ZWVrZGF5cy1mbGFnczsNCiAgICAgIHR5cGUgd2Vla2VuZC1mbGFncyB7DQog ICAgICAgIGV4dDpwb3NpdGlvbi1vZmZzZXQgNTsNCiAgICAgIH0NCiAgICB9DQogIH0NCg0KVGhl IHlhbmcgZmlsZSBpbiBhdHRhY2htZW50IHNob3cgZGlmZmVyZW50IGV4YW1wbGVzIGJhc2VkIG9u IHRoaXMgYXBwcm9hY2guDQpUaGlzIG1vZHVsZSBoYXZlIGJlZW4gdmFsaWRhdGVkIHVzaW5nIGh0 dHA6Ly93d3cueWFuZ3ZhbGlkYXRvci5jb20vdmFsaWRhdG9yIA0KSWYgdGhpcyBhcHByb2FjaCBp cyBhY2NlcHRlZCwgdG9vbHMgbGlrZSBweWFuZyBzaG91bGQgYmUgdXBkYXRlZCB0byBwcm9kdWNl IGFuIGVycm9yIGlmIG11bHRpcGxlIGVudW1lcmF0aW9ucyBvciBiaXRzIGFyZSBkZWZpbmVkIHdp dGggdmFsdWUgb3IgcG9zaXRpb24gb3ZlcmxlYXBzLg0KDQpQbGVhc2UgY29tbWVudCwNCk1pY2hl bA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGFkaXNsYXYgTGhvdGthIDxs aG90a2FAbmljLmN6PiANClNlbnQ6IE1vbmRheSwgTWFyY2ggMjUsIDIwMTkgNDowNyBBTQ0KVG86 IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPjsgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQpDYzogTWljaGVsIFZlaWxsZXR0 ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPjsgbmV0Y29uZkBpZXRmLm9yZzsgY29y ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGluIENCT1IN Cg0KSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGU+IHdyaXRlczoNCg0KPiBJIHRoaW5rIHdlIG5lZWQgdG8gbG9vayBhdCB0aGUgd2hvbGUg cGljdHVyZSBhbmQgaW4gd2hpY2ggZGlyZWN0aW9uIHdlIA0KPiB3YW50IHRvIGdvLiBJbiB0aGUg bG9uZ2VyIHRlcm0sIEkgd291bGQgcHJlZmVyIGEgc29sdXRpb24gd2hlcmUgdGhlIA0KPiB2YWx1 ZXMgb2YgYSB1bmlvbiBhcmUgZGlzY3JpbWluYXRlZC4gVGhlIGN1cnJlbnQgWE1MIGVuY29kaW5n IA0KPiBiZWhhdmlvdXIgb2YgJ2ZpcnN0IG1hdGNoIHdpbnMnIGlzIGZyYWdpbGUgKGZvciBleGFt cGxlLCBpZiBzb21lb25lIA0KPiBhZGRzIGFuIGVudW0gdG8gYSB0eXBlLCB0aGUgaW50ZXJwcmV0 YXRpb24gb2YgZGF0YSBjYW4gY2hhbmdlKS4NCj4NCj4gTG9vayBhdCB0aGlzOg0KPg0KPiB0eXBl ZGVmIGJhciB7DQo+ICAgdHlwZSB1bmlvbiB7DQo+ICAgICB0eXBlIGVudW1lcmF0aW9uIHsgZW51 bSAiMSI7IHZhbHVlIDI7IGVudW0gIjIiOyB2YWx1ZSAxOyB9DQo+ICAgICB0eXBlIHVpbnQ4Ow0K PiAgIH0NCj4gfQ0KPg0KPiBXZSBoYXZlIHNvbWUgZW5jb2RpbmdzIHRoYXQgc2VuZCB0aGUgc3Ry aW5nIHJlcHJlc2VudGF0aW9ucyBvZiB0aGUgDQo+IHZhbHVlcyBhbmQgc29tZSBlbmNvZGluZ3Mg dGhhdCBwcmVmZXIgdG8gc2VuZCBudW1lcmljIHJlcHJlc2VudGF0aW9ucyANCj4gd2hlcmUgcG9z c2libGUuIEluIG9yZGVyIHRvIGhhdmUgYSByb2J1c3Qgc29sdXRpb24sIGVuY29kaW5ncyBzaG91 bGQgDQo+IGxpa2VseSBpbmRpY2F0ZSB0byB3aGljaCB0eXBlIHRoZSB2YWx1ZSBiZWxvbmdzLg0K DQpQZXJoYXBzIHRoZSBlYXNpZXN0IHdheSB3b3VsZCBiZSB0byB1c2UgKG9wdGlvbmFsKSBhbm5v dGF0aW9uIHRoYXQgc3BlY2lmaWVzLCB1c2luZyBhbiBvcmRpbmFsIG51bWJlciwgd2hpY2ggb2Yg dGhlIG1lbWJlciB0eXBlcyBpcyB1c2VkIGZvciB0aGUgcGFydGljdWxhciBpbnN0YW5jZS4gQnV0 IHNpbmNlIHRoZXJlIGNhbiBiZSB1bmlvbnMgaW5zaWRlIHVuaW9ucywgYSBsaXN0IG9mIG51bWJl cnMgd291bGQgYmUgbmVlZGVkIGluIGdlbmVyYWwuDQoNCkxhZGENCg0KPg0KPiAvanMNCj4NCj4g T24gU2F0LCBNYXIgMjMsIDIwMTkgYXQgMTA6MDM6MzJBTSArMDEwMCwgQ2Fyc3RlbiBCb3JtYW5u IHdyb3RlOg0KPj4gV2VsbCwgaWYgdGhhdCBpcyBhIHByb2JsZW0sIHdlIGNhbiBnbyBmb3IgYSBs b25nZXIgcmVwcmVzZW50YXRpb24gd2l0aGluIHVuaW9ucyAoc2VjdGlvbiA2LjEyKS4gIFRoZW9y ZXRpY2FsbHksIHdlIGNvdWxkIGRvIHRoYXQgb25seSBvZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25l IGVudW0gaW4gdGhlIHVuaW9uIHR5cGUgKHNvIHRoaW5ncyBzdGF5IGVmZmljaWVudCBpZiB0aGVy ZSBpcyBvbmx5IG9uZSksIGJ1dCB0aGF0IG1pZ2h0IHBvc2UgZGlmZmljdWx0aWVzIHdpdGggbW9k ZWwgZXZvbHV0aW9uLg0KPj4gDQo+PiBHb2luZyBmb3IgYSBzdHJpbmcgcmVwcmVzZW50YXRpb24g cmVwZWF0cyB0aGUgZmVhdHVyZSBvZiBYTUwgWUFORyAod2hpY2ggd2FzIHBvcnRlZCBvdmVyIHRv IEpTT04gWUFORyk6DQo+PiANCj4+IHR5cGVkZWYgZm9vIHsNCj4+ICAgdHlwZSB1bmlvbiB7DQo+ PiAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+PiAgICAgICBlbnVtIHJlZCB7IHZhbHVlIDE7IH0N Cj4+ICAgICAgIGVudW0gYnJlZW4geyB2YWx1ZSAyOyB9DQo+PiAgICAgICBlbnVtIGdsdWUgeyB2 YWx1ZSAzOyB9DQo+PiAgICAgfQ0KPj4gICAgIHR5cGUgZW51bWVyYXRpb24gew0KPj4gICAgICAg ZW51bSB0YWNrcyB7IHZhbHVlIDE7IH0NCj4+ICAgICAgIGVudW0gbmFpbHMgeyB2YWx1ZSAyOyB9 DQo+PiAgICAgICBlbnVtIGdsdWUgeyB2YWx1ZSAzOyB9DQo+PiAgICAgfQ0KPj4gICB9DQo+PiB9 DQo+PiANCj4+IElmIHlvdSB1c2Ug4oCcZ2x1ZeKAnSwgeW91IGRvbuKAmXQga25vdyB3aGljaCBv ZiB0aGUgZW51bWVyYXRpb25zIGFyZSBiZWluZyB1c2VkLg0KPj4gDQo+PiBVc2luZyBTSURzLCB3 ZSBjYW4gZG8gYmV0dGVyLg0KPj4gDQo+PiBTbyB3aGF0IGRvIHdlIGhhdmUgdG8gZG8gdG8gZ2V0 IHRoZSBTSUQgdG9vbCB0byBhbGxvY2F0ZSBTSURzIGZvciBlbnVtIHZhbHVlcz8NCj4+IA0KPj4g V2UgY291bGQgdGhlbiBkZWZpbmUgdGhlIENCT1IgdGFnIGZvciBlbnVtcyBpbiB1bmlvbnMgdG8g dGFrZSB0aGUgdXN1YWwgU0lEIGRpZmZlcmVuY2UgKGRlbHRhIHJlbGF0aXZlIHRvIHRoZSBlbnZp cm9ubWVudCwgSeKAmWQgdGhpbmspLCBub3QgYW4gaW50ZWdlciB2YWx1ZS4NCj4+IA0KPj4gU2V2 ZXJhbCBvZiB1cyBhcmUgYXQgdGhlIGhhY2thdGhvbiBhbmQgY291bGQgbWFrZSBzb21ldGhpbmcg aGFwcGVuIHRvZGF5IGFuZCB0b21vcnJvdy4NCj4+IA0KPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPj4g DQo+PiANCj4+ID4gT24gTWFyIDIyLCAyMDE5LCBhdCAxODozMCwgUm9iIFdpbHRvbiAocndpbHRv bikgPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4+ID4gDQo+PiA+IEkgZ3Vlc3MgdGhhdCB0 aGUgY29uY2VybiBpcyB0aGF0IHRoaXMgaW50cm9kdWNlcyBtb3JlIHZhcmlhdGlvbiBpbiBob3cg ZGF0YSBpcyBpbnRlcnByZXRlZCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgWE1ML0pTT04vQ0JPUiBl bmNvZGluZ3MuDQo+PiA+IA0KPj4gPiBFLmcuIGlmIHNvbWVvbmUgc3dpdGNoZWQgZnJvbSBYTUwg dG8gQ0JPUiwgc3VkZGVubHkgdGhlIGNvbmZpZ3VyYXRpb24gb3Igc3RhdGUgZGF0YSBtYXkgaGF2 ZSBhIGRpZmZlcmVudCBtZWFuaW5nLg0KPj4gPiANCj4+ID4gVGhhbmtzLA0KPj4gPiBSb2INCj4+ ID4gDQo+PiA+IA0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206 IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0KPj4gPj4gU2VudDogMjIgTWFyY2ggMjAx OSAxNjowOA0KPj4gPj4gVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJp bGxpYW50LmNvbT4NCj4+ID4+IENjOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNj by5jb20+OyBjb3JlQGlldGYub3JnOyANCj4+ID4+IG5ldGNvbmZAaWV0Zi5vcmcNCj4+ID4+IFN1 YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFORyBlbmNvZGluZyBpbiBDQk9SDQo+PiA+PiANCj4+ID4+ IE9uIE1hciAyMiwgMjAxOSwgYXQgMTY6NDUsIE1pY2hlbCBWZWlsbGV0dGUgDQo+PiA+PiA8TWlj aGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPg0KPj4gPj4gd3JvdGU6DQo+PiA+Pj4gDQo+PiA+ Pj4gVGhlIG9ubHkgcG90ZW50aWFsIHByb2JsZW0gSSBhd2FyZSBpcyB3aGVuIG11bHRpcGxlIGVu dW1lcmF0aW9ucyANCj4+ID4+PiBhcmUgcGFydCBvZg0KPj4gPj4gdGhlIHNhbWUgdW5pb24uDQo+ PiA+Pj4gVmFsdWUgNCBmcm9tIGVudW1lcmF0aW9uIEEgd2lsbCBiZSBlbmNvZGVkIHRoZSBzYW1l IHdheSBhcyBWYWx1ZSANCj4+ID4+PiA0IGZyb20NCj4+ID4+IGVudW1lcmF0aW9uIEIuDQo+PiA+ PiANCj4+ID4+IOKApiBhbmQgdGhhdCBpcyBub3QgYSBwcm9ibGVtIGZvciB0aGUgWE1MIHZlcnNp b24sIGJlY2F1c2UgdGhlIA0KPj4gPj4gc3RyaW5nIGlzIGJlaW5nIHVzZWQgaW5zdGVhZCBvZiB0 aGUgdmFsdWUuICAoQnV0IHRoZW4gaWYgdHdvIA0KPj4gPj4gZW51bWVyYXRpb25zIHNoYXJlIGEg c3RyaW5nLCB5b3UgaGF2ZSB0aGUgZXF1aXZhbGVudCBwcm9ibGVtIGluIA0KPj4gPj4gdGhlIFhN TCBzZXJpYWxpemF0aW9uLikNCj4+ID4+IA0KPj4gPj4gQW55d2F5LCBJIGhhdmVu4oCZdCBzZWVu IGEgcGllY2Ugb2YgcmVhbC13b3JsZCBZQU5HIHRoYXQgYWN0dWFsbHkgDQo+PiA+PiBoYXMgdGhp cyBwcm9ibGVtLCBzbyBJIHdvdWxkIGJlIGEgYml0IHJlbHVjdGFudCB0byBtYWtlIENCT1ItYmFz ZWQgDQo+PiA+PiBpbXBsZW1lbnRhdGlvbnMgbW9yZSBjb21wbGV4IChhbmQgbGVzcyBlZmZpY2ll bnQpIHNvIHNvbHZlIHRoaXMgKG5vbi0/KXByb2JsZW0uDQo+PiA+PiANCj4+ID4+IEdyw7zDn2Us IENhcnN0ZW4NCj4+ID4gDQo+PiA+IA0KPj4gPiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ PiBuZXRjb25mQGlldGYub3JnDQo+PiBodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cNCj4+IC5pZXRmLm9yZyUyRm1haWxt YW4lMkZsaXN0aW5mbyUyRm5ldGNvbmYmYW1wO2RhdGE9MDIlN0MwMSU3QyU3QzM0M2VhOA0KPj4g ZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQlN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMw NDMwOSU3QzAlN0MxDQo+PiAlN0M2MzY4OTA5ODAxODI1NTM0MDAmYW1wO3NkYXRhPXUxS0ZBWUF1 czE2QjhhN3Nnc0JmUGZJcXVPcHRNbGFPYiUyQjANCj4+IGt2UFpncjRvJTNEJmFtcDtyZXNlcnZl ZD0wDQo+DQo+IC0tIA0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBV bml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAg IENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIx IDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vY2FuMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZSUyRiZh bXA7ZGF0YT0wMiU3QzAxJTdDJTdDMzQzZWE4ZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQlN0M0 ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3QzAlN0MxJTdDNjM2ODkwOTgwMTgyNTUz NDAwJmFtcDtzZGF0YT1UclcyaUwzblVEbFolMkJWdmhQeFdlcWRVMVglMkJxdkZDblh5b2RYNkJ1 MWU5NCUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCj4NCj4NCj4gT24gU2F0LCBNYXIgMjMsIDIwMTkgYXQg MTA6MDM6MzJBTSArMDEwMCwgQ2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0KPj4gV2VsbCwgaWYgdGhh dCBpcyBhIHByb2JsZW0sIHdlIGNhbiBnbyBmb3IgYSBsb25nZXIgcmVwcmVzZW50YXRpb24gd2l0 aGluIHVuaW9ucyAoc2VjdGlvbiA2LjEyKS4gIFRoZW9yZXRpY2FsbHksIHdlIGNvdWxkIGRvIHRo YXQgb25seSBvZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGVudW0gaW4gdGhlIHVuaW9uIHR5cGUg KHNvIHRoaW5ncyBzdGF5IGVmZmljaWVudCBpZiB0aGVyZSBpcyBvbmx5IG9uZSksIGJ1dCB0aGF0 IG1pZ2h0IHBvc2UgZGlmZmljdWx0aWVzIHdpdGggbW9kZWwgZXZvbHV0aW9uLg0KPj4gDQo+PiBH b2luZyBmb3IgYSBzdHJpbmcgcmVwcmVzZW50YXRpb24gcmVwZWF0cyB0aGUgZmVhdHVyZSBvZiBY TUwgWUFORyAod2hpY2ggd2FzIHBvcnRlZCBvdmVyIHRvIEpTT04gWUFORyk6DQo+PiANCj4+IHR5 cGVkZWYgZm9vIHsNCj4+ICAgdHlwZSB1bmlvbiB7DQo+PiAgICAgdHlwZSBlbnVtZXJhdGlvbiB7 DQo+PiAgICAgICBlbnVtIHJlZCB7IHZhbHVlIDE7IH0NCj4+ICAgICAgIGVudW0gYnJlZW4geyB2 YWx1ZSAyOyB9DQo+PiAgICAgICBlbnVtIGdsdWUgeyB2YWx1ZSAzOyB9DQo+PiAgICAgfQ0KPj4g ICAgIHR5cGUgZW51bWVyYXRpb24gew0KPj4gICAgICAgZW51bSB0YWNrcyB7IHZhbHVlIDE7IH0N Cj4+ICAgICAgIGVudW0gbmFpbHMgeyB2YWx1ZSAyOyB9DQo+PiAgICAgICBlbnVtIGdsdWUgeyB2 YWx1ZSAzOyB9DQo+PiAgICAgfQ0KPj4gICB9DQo+PiB9DQo+PiANCj4+IElmIHlvdSB1c2Ug4oCc Z2x1ZeKAnSwgeW91IGRvbuKAmXQga25vdyB3aGljaCBvZiB0aGUgZW51bWVyYXRpb25zIGFyZSBi ZWluZyB1c2VkLg0KPj4gDQo+PiBVc2luZyBTSURzLCB3ZSBjYW4gZG8gYmV0dGVyLg0KPj4gDQo+ PiBTbyB3aGF0IGRvIHdlIGhhdmUgdG8gZG8gdG8gZ2V0IHRoZSBTSUQgdG9vbCB0byBhbGxvY2F0 ZSBTSURzIGZvciBlbnVtIHZhbHVlcz8NCj4+IA0KPj4gV2UgY291bGQgdGhlbiBkZWZpbmUgdGhl IENCT1IgdGFnIGZvciBlbnVtcyBpbiB1bmlvbnMgdG8gdGFrZSB0aGUgdXN1YWwgU0lEIGRpZmZl cmVuY2UgKGRlbHRhIHJlbGF0aXZlIHRvIHRoZSBlbnZpcm9ubWVudCwgSeKAmWQgdGhpbmspLCBu b3QgYW4gaW50ZWdlciB2YWx1ZS4NCj4+IA0KPj4gU2V2ZXJhbCBvZiB1cyBhcmUgYXQgdGhlIGhh Y2thdGhvbiBhbmQgY291bGQgbWFrZSBzb21ldGhpbmcgaGFwcGVuIHRvZGF5IGFuZCB0b21vcnJv dy4NCj4+IA0KPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPj4gDQo+PiANCj4+ID4gT24gTWFyIDIyLCAy MDE5LCBhdCAxODozMCwgUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPiB3 cm90ZToNCj4+ID4gDQo+PiA+IEkgZ3Vlc3MgdGhhdCB0aGUgY29uY2VybiBpcyB0aGF0IHRoaXMg aW50cm9kdWNlcyBtb3JlIHZhcmlhdGlvbiBpbiBob3cgZGF0YSBpcyBpbnRlcnByZXRlZCBiZXR3 ZWVuIHRoZSBkaWZmZXJlbnQgWE1ML0pTT04vQ0JPUiBlbmNvZGluZ3MuDQo+PiA+IA0KPj4gPiBF LmcuIGlmIHNvbWVvbmUgc3dpdGNoZWQgZnJvbSBYTUwgdG8gQ0JPUiwgc3VkZGVubHkgdGhlIGNv bmZpZ3VyYXRpb24gb3Igc3RhdGUgZGF0YSBtYXkgaGF2ZSBhIGRpZmZlcmVudCBtZWFuaW5nLg0K Pj4gPiANCj4+ID4gVGhhbmtzLA0KPj4gPiBSb2INCj4+ID4gDQo+PiA+IA0KPj4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0 emkub3JnPg0KPj4gPj4gU2VudDogMjIgTWFyY2ggMjAxOSAxNjowOA0KPj4gPj4gVG86IE1pY2hl bCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50LmNvbT4NCj4+ID4+IENjOiBS b2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+OyBjb3JlQGlldGYub3JnOyAN Cj4+ID4+IG5ldGNvbmZAaWV0Zi5vcmcNCj4+ID4+IFN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFO RyBlbmNvZGluZyBpbiBDQk9SDQo+PiA+PiANCj4+ID4+IE9uIE1hciAyMiwgMjAxOSwgYXQgMTY6 NDUsIE1pY2hlbCBWZWlsbGV0dGUgDQo+PiA+PiA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQu Y29tPg0KPj4gPj4gd3JvdGU6DQo+PiA+Pj4gDQo+PiA+Pj4gVGhlIG9ubHkgcG90ZW50aWFsIHBy b2JsZW0gSSBhd2FyZSBpcyB3aGVuIG11bHRpcGxlIGVudW1lcmF0aW9ucyANCj4+ID4+PiBhcmUg cGFydCBvZg0KPj4gPj4gdGhlIHNhbWUgdW5pb24uDQo+PiA+Pj4gVmFsdWUgNCBmcm9tIGVudW1l cmF0aW9uIEEgd2lsbCBiZSBlbmNvZGVkIHRoZSBzYW1lIHdheSBhcyBWYWx1ZSANCj4+ID4+PiA0 IGZyb20NCj4+ID4+IGVudW1lcmF0aW9uIEIuDQo+PiA+PiANCj4+ID4+IOKApiBhbmQgdGhhdCBp cyBub3QgYSBwcm9ibGVtIGZvciB0aGUgWE1MIHZlcnNpb24sIGJlY2F1c2UgdGhlIA0KPj4gPj4g c3RyaW5nIGlzIGJlaW5nIHVzZWQgaW5zdGVhZCBvZiB0aGUgdmFsdWUuICAoQnV0IHRoZW4gaWYg dHdvIA0KPj4gPj4gZW51bWVyYXRpb25zIHNoYXJlIGEgc3RyaW5nLCB5b3UgaGF2ZSB0aGUgZXF1 aXZhbGVudCBwcm9ibGVtIGluIA0KPj4gPj4gdGhlIFhNTCBzZXJpYWxpemF0aW9uLikNCj4+ID4+ IA0KPj4gPj4gQW55d2F5LCBJIGhhdmVu4oCZdCBzZWVuIGEgcGllY2Ugb2YgcmVhbC13b3JsZCBZ QU5HIHRoYXQgYWN0dWFsbHkgDQo+PiA+PiBoYXMgdGhpcyBwcm9ibGVtLCBzbyBJIHdvdWxkIGJl IGEgYml0IHJlbHVjdGFudCB0byBtYWtlIENCT1ItYmFzZWQgDQo+PiA+PiBpbXBsZW1lbnRhdGlv bnMgbW9yZSBjb21wbGV4IChhbmQgbGVzcyBlZmZpY2llbnQpIHNvIHNvbHZlIHRoaXMgKG5vbi0/ KXByb2JsZW0uDQo+PiA+PiANCj4+ID4+IEdyw7zDn2UsIENhcnN0ZW4NCj4+ID4gDQo+PiA+IA0K Pj4gPiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+PiBuZXRjb25mQGlldGYub3JnDQo+PiBo dHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cNCj4+IC5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm5ldGNvbmYm YW1wO2RhdGE9MDIlN0MwMSU3QyU3QzM0M2VhOA0KPj4gZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4 NzQlN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3QzAlN0MxDQo+PiAlN0M2MzY4 OTA5ODAxODI1NTM0MDAmYW1wO3NkYXRhPXUxS0ZBWUF1czE2QjhhN3Nnc0JmUGZJcXVPcHRNbGFP YiUyQjANCj4+IGt2UFpncjRvJTNEJmFtcDtyZXNlcnZlZD0wDQo+DQo+IC0tIA0KPiBKdWVyZ2Vu IFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0K PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBC cmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBz Oi8vY2FuMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnd3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZSUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDJTdDMzQz ZWE4ZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQlN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2 MGMwNDMwOSU3QzAlN0MxJTdDNjM2ODkwOTgwMTgyNTUzNDAwJmFtcDtzZGF0YT1UclcyaUwzblVE bFolMkJWdmhQeFdlcWRVMVglMkJxdkZDblh5b2RYNkJ1MWU5NCUzRCZhbXA7cmVzZXJ2ZWQ9MD4N Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g bmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gbmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczovL2NhbjAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cu DQo+IGlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGbmV0Y29uZiZhbXA7ZGF0YT0wMiU3 QzAxJTdDJTdDMzQzZWE4ZDENCj4gY2Y4ZjRlMzlhZmM3MDhkNmIwZjhkODc0JTdDNGY2ZmJkMTMw ZGZiNDE1MDg1YzNkNDMyNjBjMDQzMDklN0MwJTdDMSU3Qw0KPiA2MzY4OTA5ODAxODI1NTM0MDAm YW1wO3NkYXRhPXUxS0ZBWUF1czE2QjhhN3Nnc0JmUGZJcXVPcHRNbGFPYiUyQjBrdlBaDQo+IGdy NG8lM0QmYW1wO3Jlc2VydmVkPTANCg0KLS0NCkxhZGlzbGF2IExob3RrYQ0KSGVhZCwgQ1ouTklD IExhYnMNClBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0K --_002_BL0PR06MB5042C9AA6B4A0CCD913F50D89A580BL0PR06MB5042namp_ Content-Type: application/octet-stream; name="test-union@2019-03-25.yang" Content-Description: test-union@2019-03-25.yang Content-Disposition: attachment; filename="test-union@2019-03-25.yang"; size=3144; creation-date="Wed, 27 Mar 2019 01:08:54 GMT"; modification-date="Wed, 27 Mar 2019 01:08:54 GMT" Content-Transfer-Encoding: base64 bW9kdWxlIHRlc3QtdW5pb24gew0KICBuYW1lc3BhY2UgInVybjppZXRmOnBhcmFtczp4bWw6bnM6 eWFuZzp0ZXN0LXVuaW9uIjsNCiAgcHJlZml4IGV4dDsNCiAgDQogIHJldmlzaW9uIDIwMTktMDMt MjUgew0KICAgICAgZGVzY3JpcHRpb24gIkRyYWZ0LiI7DQogIH0NCg0KICAvLyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAvLyBQcm9wb3NlZCBl eHRlbnNpb25zDQogIA0KICBleHRlbnNpb24gdmFsdWUtb2Zmc2V0IHsNCiAgICBhcmd1bWVudCBv ZmZzZXQgew0KICAgICAgeWluLWVsZW1lbnQgdHJ1ZTsNCiAgICB9DQogICAgZGVzY3JpcHRpb24N CiAgICAgICJPZmZzZXQgYWRkZWQgdG8gZWFjaCBlbnVtIHZhbHVlIG9mIHRoZSBhc3NvY2lhdGVk IGVudW1lcmF0aW9uLiI7DQogIH0NCiAgDQogIGV4dGVuc2lvbiBwb3NpdGlvbi1vZmZzZXQgew0K ICAgIGFyZ3VtZW50IG9mZnNldCB7DQogICAgICB5aW4tZWxlbWVudCB0cnVlOw0KICAgIH0NCiAg ICBkZXNjcmlwdGlvbg0KICAgICAgIk9mZnNldCB2YWx1ZSBhZGRlZCB0byBlYWNoIGJpdCBwb3Np dGlvbiBvZiB0aGUgYXNzb2NpYXRlZCBiaXRzLiI7DQogIH0NCg0KICAvLyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAvLyBNdWx0aXBsZSBlbnVt ZXJhdGlvbnMgaW4gYSB1bmlvbg0KICANCiAgbGVhZiBtdWx0aXBsZS1lbnVtZXJhdGlvbnMtdGVz dC0xIHsNCiAgICB0eXBlIHVuaW9uIHsNCiAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAgICAg ICBlbnVtICJNb25kYXkiIHsgdmFsdWUgMDsgfQ0KICAgICAgICBlbnVtICJUdWVzZGF5IiB7IHZh bHVlIDE7IH0NCiAgICAgICAgZW51bSAiV2VkbmVzZGF5IiB7IHZhbHVlIDI7IH0NCiAgICAgICAg ZW51bSAiVGh1cnNkYXkiIHsgdmFsdWUgMzsgfQ0KICAgICAgICBlbnVtICJGcmlkYXkiIHsgdmFs dWUgNDsgfQ0KDQogICAgICB9DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgICAgZW51 bSAiU2F0dXJkYXkiIHsgdmFsdWUgNTsgfQ0KICAgICAgICBlbnVtICJTdW5kYXkiIHsgdmFsdWUg NjsgfQ0KICAgICAgfQ0KICAgIH0NCiAgfQ0KDQogIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25z LXRlc3QtMiB7DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAg ICAgICAgZW51bSAiTW9uZGF5IjsNCiAgICAgICAgZW51bSAiVHVlc2RheSI7DQogICAgICAgIGVu dW0gIldlZG5lc2RheSI7DQogICAgICAgIGVudW0gIlRodXJzZGF5IjsNCiAgICAgICAgZW51bSAi RnJpZGF5IjsNCiAgICAgIH0NCiAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAgICAgICBleHQ6 dmFsdWUtb2Zmc2V0IDU7DQogICAgICAgIGVudW0gIlNhdHVyZGF5IjsNCiAgICAgICAgZW51bSAi U3VuZGF5IjsNCiAgICAgIH0NCiAgICB9DQogIH0NCg0KICB0eXBlZGVmIHdlZWtkYXlzIHsNCiAg ICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgIGVudW0gIk1vbmRheSI7DQogICAgICBlbnVtICJU dWVzZGF5IjsNCiAgICAgIGVudW0gIldlZG5lc2RheSI7DQogICAgICBlbnVtICJUaHVyc2RheSI7 DQogICAgICBlbnVtICJGcmlkYXkiOw0KICAgIH0NCiAgfQ0KDQogIHR5cGVkZWYgd2Vla2VuZCB7 DQogICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICBlbnVtICJTYXR1cmRheSI7DQogICAgICBl bnVtICJTdW5kYXkiOw0KICAgIH0NCiAgfQ0KICANCiAgbGVhZiBtdWx0aXBsZS1lbnVtZXJhdGlv bnMtdGVzdC0zIHsNCiAgICB0eXBlIHVuaW9uIHsNCiAgICAgIHR5cGUgd2Vla2RheXM7DQogICAg ICB0eXBlIHdlZWtlbmQgew0KICAgICAgICBleHQ6dmFsdWUtb2Zmc2V0IDU7DQogICAgICB9DQog ICAgfQ0KICB9DQogIA0KICAvLyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KICAvLyBNdWx0aXBsZSBiaXRzIGluIGEgdW5pb24NCiAgDQogIGxlYWYg bXVsdGlwbGUtYml0cy10ZXN0LTEgew0KICAgIHR5cGUgdW5pb24gew0KICAgICAgdHlwZSBiaXRz IHsNCiAgICAgICAgYml0ICAiTW9uZGF5IiB7IHBvc2l0aW9uICAwOyB9DQogICAgICAgIGJpdCAi VHVlc2RheSIgeyBwb3NpdGlvbiAgMTsgfQ0KICAgICAgICBiaXQgIldlZG5lc2RheSIgeyBwb3Np dGlvbiAgMjsgfQ0KICAgICAgICBiaXQgIlRodXJzZGF5IiB7IHBvc2l0aW9uICAzOyB9DQogICAg ICAgIGJpdCAiRnJpZGF5IiB7IHBvc2l0aW9uICA0OyB9DQoNCiAgICAgIH0NCiAgICAgIHR5cGUg Yml0cyB7DQogICAgICAgIGJpdCAiU2F0dXJkYXkiIHsgcG9zaXRpb24gNTsgfQ0KICAgICAgICBi aXQgIlN1bmRheSIgeyBwb3NpdGlvbiA2OyB9DQogICAgICB9DQogICAgfQ0KICB9DQogIA0KICBs ZWFmIG11bHRpcGxlLWJpdHMtdGVzdC0yIHsNCiAgICB0eXBlIHVuaW9uIHsNCiAgICAgIHR5cGUg Yml0cyB7DQogICAgICAgIGJpdCAiTW9uZGF5IjsNCiAgICAgICAgYml0ICJUdWVzZGF5IjsNCiAg ICAgICAgYml0ICJXZWRuZXNkYXkiOw0KICAgICAgICBiaXQgIlRodXJzZGF5IjsNCiAgICAgICAg Yml0ICJGcmlkYXkiOw0KICAgICAgfQ0KICAgICAgdHlwZSBiaXRzIHsNCiAgICAgICAgZXh0OnBv c2l0aW9uLW9mZnNldCA1Ow0KICAgICAgICBiaXQgIlNhdHVyZGF5IjsNCiAgICAgICAgYml0ICJT dW5kYXkiOw0KICAgICAgfQ0KICAgIH0NCiAgfQ0KDQogIHR5cGVkZWYgd2Vla2RheXMtZmxhZ3Mg ew0KICAgIHR5cGUgYml0cyB7DQogICAgICBiaXQgIk1vbmRheSI7DQogICAgICBiaXQgIlR1ZXNk YXkiOw0KICAgICAgYml0ICJXZWRuZXNkYXkiOw0KICAgICAgYml0ICJUaHVyc2RheSI7DQogICAg ICBiaXQgIkZyaWRheSI7DQogICAgfQ0KICB9DQoNCiAgdHlwZWRlZiB3ZWVrZW5kLWZsYWdzIHsN CiAgICB0eXBlIGJpdHMgew0KICAgICAgYml0ICJTYXR1cmRheSI7DQogICAgICBiaXQgIlN1bmRh eSI7DQogICAgfQ0KICB9DQogIA0KICBsZWFmIG11bHRpcGxlLWJpdHMtdGVzdC0zIHsNCiAgICB0 eXBlIHVuaW9uIHsNCiAgICAgIHR5cGUgd2Vla2RheXMtZmxhZ3M7DQogICAgICB0eXBlIHdlZWtl bmQtZmxhZ3Mgew0KICAgICAgICBleHQ6cG9zaXRpb24tb2Zmc2V0IDU7DQogICAgICB9DQogICAg fQ0KICB9DQp9 --_002_BL0PR06MB5042C9AA6B4A0CCD913F50D89A580BL0PR06MB5042namp_-- From nobody Tue Mar 26 23:16:49 2019 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 D632A12024B; Tue, 26 Mar 2019 23:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 5J7JaTXq-3Qw; Tue, 26 Mar 2019 23:16:42 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE0E120164; Tue, 26 Mar 2019 23:16:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id EDC06B47; Wed, 27 Mar 2019 07:16:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id puvlUwt_mRJO; Wed, 27 Mar 2019 07:16:39 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Mar 2019 07:16:39 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2A37200A8; Wed, 27 Mar 2019 07:16:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id LjiqpOUwji-L; Wed, 27 Mar 2019 07:16:39 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id F15AF200A7; Wed, 27 Mar 2019 07:16:38 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 27 Mar 2019 07:16:38 +0100 Received: by anna.localdomain (Postfix, from userid 501) id DD88E30079E3AE; Wed, 27 Mar 2019 07:16:37 +0100 (CET) Date: Wed, 27 Mar 2019 07:16:37 +0100 From: Juergen Schoenwaelder To: Michel Veillette CC: Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michel Veillette , Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 27 Mar 2019 06:16:47 -0000 Hi, a union can be formed by using member types that are imported and not under change control of a single author/organization and ideally this should work without complex coordination of name and number spaces. Duplicate enum/bits values are legal in YANG today so an encoding has to deal with this aspect of life. A robust fix to all these problems will be to tag the type members in order to discriminate the values in the encodings. This, however, will take some time to specify and we will need to preserve backwards compatibility with unions without a tag (but compilers can encourage people to add tags whenever modules are updated). /js On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > Hi Ladislav >=20 > If I summarize this issue of multiple enumerations or bits in a union, = this problem can be solve by the following approaches: >=20 > - To not allows these duplicate values or positions to happen in YANG > - To encode enumerations and bits as string (in all unions or only when= multiple enumerations or bits are defined) > - To encode enumerations and bits as SID (in all unions or only when mu= ltiple enumerations or bits are defined) > - To encode enumerations and bits as delta between the value SID and th= e leaf SID (in all unions or only when multiple enumerations or bits are = defined) >=20 > In this email, I will like to focus on the first option, fixing the pro= blem directly in YANG instead of fixing the consequences. >=20 > Without any changes in YANG, a union with multiple enumeration or bits = can be constructed without value or position overlaps. > For example: >=20 > leaf multiple-enumerations-test-1 { > type union { > type enumeration { > enum "Monday" { value 0; } > enum "Tuesday" { value 1; } > enum "Wednesday" { value 2; } > enum "Thursday" { value 3; } > enum "Friday" { value 4; } >=20 > } > type enumeration { > enum "Saturday" { value 5; } > enum "Sunday" { value 6; } > } > } > } >=20 > leaf multiple-bits-test-1 { > type union { > type bits { > bit "Monday" { position 0; } > bit "Tuesday" { position 1; } > bit "Wednesday" { position 2; } > bit "Thursday" { position 3; } > bit "Friday" { position 4; } >=20 > } > type bits { > bit "Saturday" { position 5; } > bit "Sunday" { position 6; } > } > } > } >=20 > When using already defined typedef, avoiding overlap is less obvious wi= thout some help. > To help building unions with already defined typedefs, I propose to int= roduce two extensions.=20 >=20 > extension value-offset { > argument offset { > yin-element true; > } > description > "Offset added to each enum value of the associated enumeration."; > } > =20 > extension position-offset { > argument offset { > yin-element true; > } > description > "Offset value added to each bit position of the associated bits."= ; > } >=20 > The value-offset extension can be used as follow: >=20 > type enumeration { > enum "Monday"; > enum "Tuesday"; > enum "Wednesday"; > enum "Thursday"; > enum "Friday"; > } > } >=20 > typedef weekend { > type enumeration { > enum "Saturday"; > enum "Sunday"; > } > } > =20 > leaf multiple-enumerations-test-3 { > type union { > type weekdays; > type weekend { > ext:value-offset 5; > } > } > } >=20 > The position-offset extension can be used as follow: >=20 > typedef weekdays-flags { > type bits { > bit "Monday"; > bit "Tuesday"; > bit "Wednesday"; > bit "Thursday"; > bit "Friday"; > } > } >=20 > typedef weekend-flags { > type bits { > bit "Saturday"; > bit "Sunday"; > } > } > =20 > leaf multiple-bits-test-3 { > type union { > type weekdays-flags; > type weekend-flags { > ext:position-offset 5; > } > } > } >=20 > The yang file in attachment show different examples based on this appro= ach. > This module have been validated using http://www.yangvalidator.com/vali= dator=20 > If this approach is accepted, tools like pyang should be updated to pro= duce an error if multiple enumerations or bits are defined with value or = position overleaps. >=20 > Please comment, > Michel >=20 > -----Original Message----- > From: Ladislav Lhotka =20 > Sent: Monday, March 25, 2019 4:07 AM > To: Juergen Schoenwaelder ; Carst= en Bormann > Cc: Michel Veillette ; netconf@ietf.org= ; core@ietf.org > Subject: Re: [netconf] YANG encoding in CBOR >=20 > Juergen Schoenwaelder writes: >=20 > > I think we need to look at the whole picture and in which direction w= e=20 > > want to go. In the longer term, I would prefer a solution where the=20 > > values of a union are discriminated. The current XML encoding=20 > > behaviour of 'first match wins' is fragile (for example, if someone=20 > > adds an enum to a type, the interpretation of data can change). > > > > Look at this: > > > > typedef bar { > > type union { > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > type uint8; > > } > > } > > > > We have some encodings that send the string representations of the=20 > > values and some encodings that prefer to send numeric representations= =20 > > where possible. In order to have a robust solution, encodings should=20 > > likely indicate to which type the value belongs. >=20 > Perhaps the easiest way would be to use (optional) annotation that spec= ifies, using an ordinal number, which of the member types is used for the= particular instance. But since there can be unions inside unions, a list= of numbers would be needed in general. >=20 > Lada >=20 > > > > /js > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > >> Well, if that is a problem, we can go for a longer representation wi= thin unions (section 6.12). Theoretically, we could do that only of ther= e is more than one enum in the union type (so things stay efficient if th= ere is only one), but that might pose difficulties with model evolution. > >>=20 > >> Going for a string representation repeats the feature of XML YANG (w= hich was ported over to JSON YANG): > >>=20 > >> typedef foo { > >> type union { > >> type enumeration { > >> enum red { value 1; } > >> enum breen { value 2; } > >> enum glue { value 3; } > >> } > >> type enumeration { > >> enum tacks { value 1; } > >> enum nails { value 2; } > >> enum glue { value 3; } > >> } > >> } > >> } > >>=20 > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of t= he enumerations are being used. > >>=20 > >> Using SIDs, we can do better. > >>=20 > >> So what do we have to do to get the SID tool to allocate SIDs for en= um values? > >>=20 > >> We could then define the CBOR tag for enums in unions to take the us= ual SID difference (delta relative to the environment, I=E2=80=99d think)= , not an integer value. > >>=20 > >> Several of us are at the hackathon and could make something happen t= oday and tomorrow. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >>=20 > >>=20 > >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wrote: > >> >=20 > >> > I guess that the concern is that this introduces more variation in= how data is interpreted between the different XML/JSON/CBOR encodings. > >> >=20 > >> > E.g. if someone switched from XML to CBOR, suddenly the configurat= ion or state data may have a different meaning. > >> >=20 > >> > Thanks, > >> > Rob > >> >=20 > >> >=20 > >> >> -----Original Message----- > >> >> From: Carsten Bormann > >> >> Sent: 22 March 2019 16:08 > >> >> To: Michel Veillette > >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 > >> >> netconf@ietf.org > >> >> Subject: Re: [netconf] YANG encoding in CBOR > >> >>=20 > >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 > >> >> > >> >> wrote: > >> >>>=20 > >> >>> The only potential problem I aware is when multiple enumerations= =20 > >> >>> are part of > >> >> the same union. > >> >>> Value 4 from enumeration A will be encoded the same way as Value= =20 > >> >>> 4 from > >> >> enumeration B. > >> >>=20 > >> >> =E2=80=A6 and that is not a problem for the XML version, because = the=20 > >> >> string is being used instead of the value. (But then if two=20 > >> >> enumerations share a string, you have the equivalent problem in=20 > >> >> the XML serialization.) > >> >>=20 > >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that ac= tually=20 > >> >> has this problem, so I would be a bit reluctant to make CBOR-base= d=20 > >> >> implementations more complex (and less efficient) so solve this (= non-?)problem. > >> >>=20 > >> >> Gr=C3=BC=C3=9Fe, Carsten > >> >=20 > >> >=20 > >> >=20 > >>=20 > >> _______________________________________________ > >> netconf mailing list > >> netconf@ietf.org > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www > >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343= ea8 > >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C= 1 > >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%= 2B0 > >> kvPZgr4o%3D&reserved=3D0 > > > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > Fax: +49 421 200 3103 > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > >> Well, if that is a problem, we can go for a longer representation wi= thin unions (section 6.12). Theoretically, we could do that only of ther= e is more than one enum in the union type (so things stay efficient if th= ere is only one), but that might pose difficulties with model evolution. > >>=20 > >> Going for a string representation repeats the feature of XML YANG (w= hich was ported over to JSON YANG): > >>=20 > >> typedef foo { > >> type union { > >> type enumeration { > >> enum red { value 1; } > >> enum breen { value 2; } > >> enum glue { value 3; } > >> } > >> type enumeration { > >> enum tacks { value 1; } > >> enum nails { value 2; } > >> enum glue { value 3; } > >> } > >> } > >> } > >>=20 > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of t= he enumerations are being used. > >>=20 > >> Using SIDs, we can do better. > >>=20 > >> So what do we have to do to get the SID tool to allocate SIDs for en= um values? > >>=20 > >> We could then define the CBOR tag for enums in unions to take the us= ual SID difference (delta relative to the environment, I=E2=80=99d think)= , not an integer value. > >>=20 > >> Several of us are at the hackathon and could make something happen t= oday and tomorrow. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >>=20 > >>=20 > >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wrote: > >> >=20 > >> > I guess that the concern is that this introduces more variation in= how data is interpreted between the different XML/JSON/CBOR encodings. > >> >=20 > >> > E.g. if someone switched from XML to CBOR, suddenly the configurat= ion or state data may have a different meaning. > >> >=20 > >> > Thanks, > >> > Rob > >> >=20 > >> >=20 > >> >> -----Original Message----- > >> >> From: Carsten Bormann > >> >> Sent: 22 March 2019 16:08 > >> >> To: Michel Veillette > >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 > >> >> netconf@ietf.org > >> >> Subject: Re: [netconf] YANG encoding in CBOR > >> >>=20 > >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 > >> >> > >> >> wrote: > >> >>>=20 > >> >>> The only potential problem I aware is when multiple enumerations= =20 > >> >>> are part of > >> >> the same union. > >> >>> Value 4 from enumeration A will be encoded the same way as Value= =20 > >> >>> 4 from > >> >> enumeration B. > >> >>=20 > >> >> =E2=80=A6 and that is not a problem for the XML version, because = the=20 > >> >> string is being used instead of the value. (But then if two=20 > >> >> enumerations share a string, you have the equivalent problem in=20 > >> >> the XML serialization.) > >> >>=20 > >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that ac= tually=20 > >> >> has this problem, so I would be a bit reluctant to make CBOR-base= d=20 > >> >> implementations more complex (and less efficient) so solve this (= non-?)problem. > >> >>=20 > >> >> Gr=C3=BC=C3=9Fe, Carsten > >> >=20 > >> >=20 > >> >=20 > >>=20 > >> _______________________________________________ > >> netconf mailing list > >> netconf@ietf.org > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www > >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343= ea8 > >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C= 1 > >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%= 2B0 > >> kvPZgr4o%3D&reserved=3D0 > > > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww. > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea= 8d1 > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7= C > > 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0k= vPZ > > gr4o%3D&reserved=3D0 >=20 > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 27 01:25:52 2019 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 392D6120274; Wed, 27 Mar 2019 01:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 00i_fhlNbhj1; Wed, 27 Mar 2019 01:25:44 -0700 (PDT) Received: from smtp.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 BCBD9120273; Wed, 27 Mar 2019 01:25:44 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44Th066RkVzyct; Wed, 27 Mar 2019 09:25:42 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> Date: Wed, 27 Mar 2019 09:25:42 +0100 Cc: Michel Veillette , Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575367940.6541671-11d0d25c658c030fed37d5d31691a56a Content-Transfer-Encoding: quoted-printable Message-Id: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 27 Mar 2019 08:25:46 -0000 On Mar 27, 2019, at 07:16, Juergen Schoenwaelder = wrote: >=20 > A robust fix to all these problems will be to tag the type members in > order to discriminate the values in the encodings. This, however, will > take some time to specify and we will need to preserve backwards > compatibility with unions without a tag (but compilers can encourage > people to add tags whenever modules are updated). And that may be the way forward: As XML and JSON already differ in handling =E2=80=9Cfirst-match wins=E2=80= =9D (as Andy has demonstrated), there is probably not a lot of damage in = CBOR being different again in handling this arcane case, so we can = mostly ship as is (but see below). We then develop the YANG-wide fix together. We=E2=80=99ll make sure = that the CBOR union representation has the right placeholders to put = that in. For that, it would be nice to have a direction about where = exactly that information would be in the instance tree. And, more = importantly, if something needs to be included in the SID files, it = would be good to nail that down now. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 27 01:40:23 2019 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 632FF120277; Wed, 27 Mar 2019 01:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiSctlJq6m8R; Wed, 27 Mar 2019 01:40:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEEA120276; Wed, 27 Mar 2019 01:40:10 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 4AD6D605FC; Wed, 27 Mar 2019 09:40:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553676008; bh=BxpabmPoA5pcWTCBlPBgkrOdUdACty8/51V6MLJCgQU=; h=From:To:Date; b=cNvIN8s5FQTYn0gKDxlM1u/LAgooaULY7U1VpCx7F/qTYxGwarspVwsBLHABNhbrG +L2HM1rfbmMBLUjeH4bte/1DxbPsF6tutDv/R0F1A2LlndF0M2zc4bAKh0VBTe3KKY YCp9hJ3VFxVdj6L5LuPD6R/wQTzNOHHLEuMIo6Po= Message-ID: <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder , Michel Veillette Cc: Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Date: Wed, 27 Mar 2019 09:40:08 +0100 In-Reply-To: <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 27 Mar 2019 08:40:17 -0000 On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > Hi, > > a union can be formed by using member types that are imported and not > under change control of a single author/organization and ideally this > should work without complex coordination of name and number spaces. > Duplicate enum/bits values are legal in YANG today so an encoding has > to deal with this aspect of life. > > A robust fix to all these problems will be to tag the type members in > order to discriminate the values in the encodings. This, however, will > take some time to specify and we will need to preserve backwards > compatibility with unions without a tag (but compilers can encourage > people to add tags whenever modules are updated). I already opened a new issue for this in yang-next: https://github.com/netmod-wg/yang-next/issues/72 Lada > > /js > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > > Hi Ladislav > > > > If I summarize this issue of multiple enumerations or bits in a union, this > > problem can be solve by the following approaches: > > > > - To not allows these duplicate values or positions to happen in YANG > > - To encode enumerations and bits as string (in all unions or only when > > multiple enumerations or bits are defined) > > - To encode enumerations and bits as SID (in all unions or only when > > multiple enumerations or bits are defined) > > - To encode enumerations and bits as delta between the value SID and the > > leaf SID (in all unions or only when multiple enumerations or bits are > > defined) > > > > In this email, I will like to focus on the first option, fixing the problem > > directly in YANG instead of fixing the consequences. > > > > Without any changes in YANG, a union with multiple enumeration or bits can > > be constructed without value or position overlaps. > > For example: > > > > leaf multiple-enumerations-test-1 { > > type union { > > type enumeration { > > enum "Monday" { value 0; } > > enum "Tuesday" { value 1; } > > enum "Wednesday" { value 2; } > > enum "Thursday" { value 3; } > > enum "Friday" { value 4; } > > > > } > > type enumeration { > > enum "Saturday" { value 5; } > > enum "Sunday" { value 6; } > > } > > } > > } > > > > leaf multiple-bits-test-1 { > > type union { > > type bits { > > bit "Monday" { position 0; } > > bit "Tuesday" { position 1; } > > bit "Wednesday" { position 2; } > > bit "Thursday" { position 3; } > > bit "Friday" { position 4; } > > > > } > > type bits { > > bit "Saturday" { position 5; } > > bit "Sunday" { position 6; } > > } > > } > > } > > > > When using already defined typedef, avoiding overlap is less obvious without > > some help. > > To help building unions with already defined typedefs, I propose to > > introduce two extensions. > > > > extension value-offset { > > argument offset { > > yin-element true; > > } > > description > > "Offset added to each enum value of the associated enumeration."; > > } > > > > extension position-offset { > > argument offset { > > yin-element true; > > } > > description > > "Offset value added to each bit position of the associated bits."; > > } > > > > The value-offset extension can be used as follow: > > > > type enumeration { > > enum "Monday"; > > enum "Tuesday"; > > enum "Wednesday"; > > enum "Thursday"; > > enum "Friday"; > > } > > } > > > > typedef weekend { > > type enumeration { > > enum "Saturday"; > > enum "Sunday"; > > } > > } > > > > leaf multiple-enumerations-test-3 { > > type union { > > type weekdays; > > type weekend { > > ext:value-offset 5; > > } > > } > > } > > > > The position-offset extension can be used as follow: > > > > typedef weekdays-flags { > > type bits { > > bit "Monday"; > > bit "Tuesday"; > > bit "Wednesday"; > > bit "Thursday"; > > bit "Friday"; > > } > > } > > > > typedef weekend-flags { > > type bits { > > bit "Saturday"; > > bit "Sunday"; > > } > > } > > > > leaf multiple-bits-test-3 { > > type union { > > type weekdays-flags; > > type weekend-flags { > > ext:position-offset 5; > > } > > } > > } > > > > The yang file in attachment show different examples based on this approach. > > This module have been validated using http://www.yangvalidator.com/validator > > > > If this approach is accepted, tools like pyang should be updated to produce > > an error if multiple enumerations or bits are defined with value or position > > overleaps. > > > > Please comment, > > Michel > > > > -----Original Message----- > > From: Ladislav Lhotka > > Sent: Monday, March 25, 2019 4:07 AM > > To: Juergen Schoenwaelder ; Carsten > > Bormann > > Cc: Michel Veillette ; netconf@ietf.org; > > core@ietf.org > > Subject: Re: [netconf] YANG encoding in CBOR > > > > Juergen Schoenwaelder writes: > > > > > I think we need to look at the whole picture and in which direction we > > > want to go. In the longer term, I would prefer a solution where the > > > values of a union are discriminated. The current XML encoding > > > behaviour of 'first match wins' is fragile (for example, if someone > > > adds an enum to a type, the interpretation of data can change). > > > > > > Look at this: > > > > > > typedef bar { > > > type union { > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > > type uint8; > > > } > > > } > > > > > > We have some encodings that send the string representations of the > > > values and some encodings that prefer to send numeric representations > > > where possible. In order to have a robust solution, encodings should > > > likely indicate to which type the value belongs. > > > > Perhaps the easiest way would be to use (optional) annotation that > > specifies, using an ordinal number, which of the member types is used for > > the particular instance. But since there can be unions inside unions, a list > > of numbers would be needed in general. > > > > Lada > > > > > /js > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > Well, if that is a problem, we can go for a longer representation within > > > > unions (section 6.12). Theoretically, we could do that only of there is > > > > more than one enum in the union type (so things stay efficient if there > > > > is only one), but that might pose difficulties with model evolution. > > > > > > > > Going for a string representation repeats the feature of XML YANG (which > > > > was ported over to JSON YANG): > > > > > > > > typedef foo { > > > > type union { > > > > type enumeration { > > > > enum red { value 1; } > > > > enum breen { value 2; } > > > > enum glue { value 3; } > > > > } > > > > type enumeration { > > > > enum tacks { value 1; } > > > > enum nails { value 2; } > > > > enum glue { value 3; } > > > > } > > > > } > > > > } > > > > > > > > If you use “glue”, you don’t know which of the enumerations are being > > > > used. > > > > > > > > Using SIDs, we can do better. > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for enum > > > > values? > > > > > > > > We could then define the CBOR tag for enums in unions to take the usual > > > > SID difference (delta relative to the environment, I’d think), not an > > > > integer value. > > > > > > > > Several of us are at the hackathon and could make something happen today > > > > and tomorrow. > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) > > > > > wrote: > > > > > > > > > > I guess that the concern is that this introduces more variation in how > > > > > data is interpreted between the different XML/JSON/CBOR encodings. > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the configuration > > > > > or state data may have a different meaning. > > > > > > > > > > Thanks, > > > > > Rob > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Carsten Bormann > > > > > > Sent: 22 March 2019 16:08 > > > > > > To: Michel Veillette > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > netconf@ietf.org > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > wrote: > > > > > > > The only potential problem I aware is when multiple enumerations > > > > > > > are part of > > > > > > the same union. > > > > > > > Value 4 from enumeration A will be encoded the same way as Value > > > > > > > 4 from > > > > > > enumeration B. > > > > > > > > > > > > … and that is not a problem for the XML version, because the > > > > > > string is being used instead of the value. (But then if two > > > > > > enumerations share a string, you have the equivalent problem in > > > > > > the XML serialization.) > > > > > > > > > > > > Anyway, I haven’t seen a piece of real-world YANG that actually > > > > > > has this problem, so I would be a bit reluctant to make CBOR-based > > > > > > implementations more complex (and less efficient) so solve this > > > > > > (non-?)problem. > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > netconf mailing list > > > > netconf@ietf.org > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8 > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > %7C636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > kvPZgr4o%3D&reserved=0 > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 < > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&data=02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sdata=TrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=0 > > > > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > Well, if that is a problem, we can go for a longer representation within > > > > unions (section 6.12). Theoretically, we could do that only of there is > > > > more than one enum in the union type (so things stay efficient if there > > > > is only one), but that might pose difficulties with model evolution. > > > > > > > > Going for a string representation repeats the feature of XML YANG (which > > > > was ported over to JSON YANG): > > > > > > > > typedef foo { > > > > type union { > > > > type enumeration { > > > > enum red { value 1; } > > > > enum breen { value 2; } > > > > enum glue { value 3; } > > > > } > > > > type enumeration { > > > > enum tacks { value 1; } > > > > enum nails { value 2; } > > > > enum glue { value 3; } > > > > } > > > > } > > > > } > > > > > > > > If you use “glue”, you don’t know which of the enumerations are being > > > > used. > > > > > > > > Using SIDs, we can do better. > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for enum > > > > values? > > > > > > > > We could then define the CBOR tag for enums in unions to take the usual > > > > SID difference (delta relative to the environment, I’d think), not an > > > > integer value. > > > > > > > > Several of us are at the hackathon and could make something happen today > > > > and tomorrow. > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) > > > > > wrote: > > > > > > > > > > I guess that the concern is that this introduces more variation in how > > > > > data is interpreted between the different XML/JSON/CBOR encodings. > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the configuration > > > > > or state data may have a different meaning. > > > > > > > > > > Thanks, > > > > > Rob > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Carsten Bormann > > > > > > Sent: 22 March 2019 16:08 > > > > > > To: Michel Veillette > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > netconf@ietf.org > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > wrote: > > > > > > > The only potential problem I aware is when multiple enumerations > > > > > > > are part of > > > > > > the same union. > > > > > > > Value 4 from enumeration A will be encoded the same way as Value > > > > > > > 4 from > > > > > > enumeration B. > > > > > > > > > > > > … and that is not a problem for the XML version, because the > > > > > > string is being used instead of the value. (But then if two > > > > > > enumerations share a string, you have the equivalent problem in > > > > > > the XML serialization.) > > > > > > > > > > > > Anyway, I haven’t seen a piece of real-world YANG that actually > > > > > > has this problem, so I would be a bit reluctant to make CBOR-based > > > > > > implementations more complex (and less efficient) so solve this > > > > > > (non-?)problem. > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > netconf mailing list > > > > netconf@ietf.org > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8 > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > %7C636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > kvPZgr4o%3D&reserved=0 > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 < > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&data=02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sdata=TrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=0 > > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8d1 > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C > > > 636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kvPZ > > > gr4o%3D&reserved=0 > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 27 02:25:42 2019 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 A054C120280 for ; Wed, 27 Mar 2019 02:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojJ1W9VZ1K_j for ; Wed, 27 Mar 2019 02:25:37 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B489112025C for ; Wed, 27 Mar 2019 02:25:37 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 475B34380B; Wed, 27 Mar 2019 10:25:35 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 53EAA36; Wed, 27 Mar 2019 10:25:32 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2001:67c:1232:144:53b4:478e:561d:3782]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0448574; Wed, 27 Mar 2019 10:25:32 +0100 (CET) Received: (nullmailer pid 32062 invoked by uid 1000); Wed, 27 Mar 2019 09:25:31 -0000 Date: Wed, 27 Mar 2019 10:25:31 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "Bilhanan Silverajan (TAU)" Cc: Core WG mailing list Message-ID: <20190327092530.GA28769@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Protocol negotiation hallway meeting @IETF104 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, 27 Mar 2019 09:25:41 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello meeting participants, > As I mentioned at today's CoRE meeting, we'll have a hallway discussion= =20 > on CoAP protocol negotiation [...] and also possibly on the "coap+at:" > URI scheme I'm sketching up a few agenda points and strawman proposals at [1], and would also like to collaboratively take notes there. See you at 12:30 c [1]: https://etherpad.tools.ietf.org/p/notes-core-protocol-negotiation --=20 Most people would leave. Not us. We're Vikings. We have stubbornness issues. -- Hiccup, son of Stoic --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlybQYcACgkQOY0REtOk veFTFxAAvH3mPoZzWBc9bbRM+MH+x9draAQhpcpG6X2pD0aWQ/Bj16QPjc9DfPQq o5eWRie+2X/UeHb1/82f0GU6/snL3A/+HjvNAoa4W6FIEjQJNu1HBVV5EUQS+OoG 3gmY2Hprt7ELBo7ST18W0IbcAgNQQEnZE+yzF479UwFq3w6rVFbdo/mRWU94EJGM soZdwq4eVI0MUkB3OdtJ0+EyaX9Go3uCEYuf3UcD2ZHZgEQqd8Yru11LsOIaRxur hSBHMFoFkRfO4RBcn3oYgtelk9HJjPngDJKCYgEJKWd6u3R41NskM9UHRDDr3TTZ 2U9IhD4u5Ethhz3lAMahvJm9s5guDa7Ii2YcJHrSCqbfbm5kuoE2hF7aXgbhpuF7 k52IKnIevJJ5QOoTJV5wPaOvCzru4yvnmEg3gycIJQ6P0iUnwfUlXZGX1TMnaaNM HEZwKamYPj2i3GK1ODLqK8F1/VBJpTjr2BKs0oag4yeq9hSATakyTCfby5o1/CC+ MQbtV4UOWmnrk7GG7aZICqdc6I452RNCPJCiJZ9A72BJtelsc+HftTcwlxcDXYOr P8946qatVLQdBmtVxbzW3G09SluM3QQlNM9wvYM207j1ijEC6+ssYurW6+/rdzqm zVSR29GU2B705QnZ1XU8ZrPzqPidgS7dc1ibeZVcJ2oO//t6HKg= =z+JJ -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From nobody Wed Mar 27 09:01:23 2019 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 76FE712031B; Wed, 27 Mar 2019 09:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGnGhSLABl4m; Wed, 27 Mar 2019 09:01:16 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750095.outbound.protection.outlook.com [40.107.75.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4611202F9; Wed, 27 Mar 2019 09:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+ELtGtVNoXMPMLQoXI3XME3VYbOHfPwIT1r4GIP5+74=; b=Y45W4hOWwIU3KBn7+ZcqFZFefaTjamnKNHw4NFx8l19+wMZIAuXecZRKsutaHBVmrF9KB3kcLFD7cHNEndIAGIcGSZ803PKv+kJTXLRRhhpQhUrbKYPCDBDvQBfH6/laojzpG04yG93IBdWFVB700NH6G+B+ZDeskD3y92JNFK4= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4963.namprd06.prod.outlook.com (10.167.235.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Wed, 27 Mar 2019 16:00:42 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d%3]) with mapi id 15.20.1730.019; Wed, 27 Mar 2019 16:00:42 +0000 From: Michel Veillette To: Juergen Schoenwaelder CC: Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAL8XAAAAtt/gAAgmRkAAAJStYAAYEUIgABUqX2QAAwU1oAAE3mQoA== Date: Wed, 27 Mar 2019 16:00:42 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> In-Reply-To: <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3abeafcf-7d5a-4ae2-22f9-08d6b2cd5d72 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4963; x-ms-traffictypediagnostic: BL0PR06MB4963: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0989A7979C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(366004)(136003)(396003)(376002)(346002)(52314003)(199004)(189003)(13464003)(26005)(7696005)(97736004)(256004)(76176011)(8936002)(316002)(9686003)(186003)(53946003)(54906003)(5024004)(476003)(14444005)(6436002)(486006)(5660300002)(229853002)(86362001)(114624004)(11346002)(6506007)(71190400001)(99286004)(53546011)(45080400002)(68736007)(102836004)(71200400001)(446003)(2906002)(6916009)(25786009)(3846002)(6116002)(93886005)(4326008)(8676002)(30864003)(105586002)(14454004)(33656002)(305945005)(72206003)(53936002)(7736002)(478600001)(6246003)(74316002)(106356001)(6306002)(66066001)(55016002)(966005)(81156014)(52536014)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4963; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: bknsQaFVkTNWNtH/Z6HhyRUWeQdCLV+vvZqm4ILPJFnj5pmTi6p7wLg6hZwhBeuSWj+348aJyYipF6Qg3dYpYmBEBdp/xXKYZjxkOtK+MT8mLCBg2HHKjh0tX8WGCXnH97TbU5U8wa12JAwSbYVP2+MzdW65VNeLelgJfJCbQLRK6cWqJ4oKnJiXdc78S/i2sUVcojGgTbHKhcoO0iMZfIgUCyJ6n3XjR8fSznCfPatqIFNQShE0fX4FBydSOkBmlyyIxd9Z6fRyrv1BdMlvbKK1xkMDwSqBryFbRcF8oXT02kO87l+ZPVt4PrmJBWcY6mrzPzFZe1UFkvJBOzKsAB5b/QtgIWSyL2arRlXXNrxL0GdhNOc9wSdoMOaJwC/xQAL+OXnx5zbR6Y3uL5sAN1tyZHOr8AjSwMJhcHFAWGo= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3abeafcf-7d5a-4ae2-22f9-08d6b2cd5d72 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 16:00:42.2482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4963 Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 27 Mar 2019 16:01:21 -0000 SGkgSnVlcmdlbg0KDQpZb3Ugd2lsbCBmaW5kIGluIGF0dGFjaG1lbnQgdGhlIHVwZGF0ZWQgdmVy c2lvbiBvZiAndGVzdC11bmlvbkAyMDE5LTAzLTI1LnlhbmcnIGJhc2VkIG9uIHlvdXIgcHJvcG9z ZWQgc29sdXRpb24sIHR5cGUgdGFnZ2luZy4NClRoaXMgbW9kdWxlIGRlZmluZXMgYW4gZXh0ZW5z aW9uIGNhbGxlZCB1bmlvbi10YWcgYXMgZm9sbG93Og0KDQogIGV4dGVuc2lvbiB1bmlvbi10YWcg ew0KICAgIGFyZ3VtZW50IHRhZyB7DQogICAgICB5aW4tZWxlbWVudCB0cnVlOw0KICAgIH0NCiAg ICBkZXNjcmlwdGlvbg0KICAgICAgIkluIHNvbWUgY2FzZXMsIHRoZSBpbnRlcnByZXRhdGlvbiBv ZiBhIHZhbHVlIG9mIGEgdW5pb24gdHlwZSBjYW4gZGlmZmVyDQogICAgICB3aGVuIGVuY29kZWQg dXNpbmcgdGhlIGRpZmZlcmVudCBkYXRhIGZvcm1hdC4gVGhpcyBkaWZmZXJlbmNlIGNvbWVzIGZy b20NCiAgICAgIHRoZSBsZXZlbCBvZiB0eXBlIGluZm9ybWF0aW9uIHN1cHBvcnRlZCBieSB0aGUg ZGlmZmVyZW50IGRhdGEgZm9ybWF0cy4NCiAgICAgIEluIHRoZSBjYXNlIG9mIFhNTCwgYWxsIGVs ZW1lbnRzIGFuZCBhdHRyaWJ1dGVzIGFyZSBlbmNvZGVkIGFzIHN0cmluZw0KICAgICAgYW5kIG5v IHR5cGUgaW5mb3JtYXRpb24gYXJlIGluY2x1ZGVkLiBKU09OIHN1cHBvcnRzIHN0cmluZywgbnVt YmVyIGFuZA0KICAgICAgYm9vbGVhbi4gRmluYWxseSwgQ0JPUiBzdXBwb3J0cyBhbGwgWUFORyBi YXNpYyB0eXBlcy4NCg0KICAgICAgVGhpcyBleHRlbnNpb24gY2FuIGJlIHVzZWQgdG8gYWRkIGEg dGFnIHRvIGEgdHlwZSB3aXRoaW4gYSB1bmlvbiB0bw0KICAgICAgZ3VhcmFudGVlIGl0cyBwcm9w ZXIgaW50ZXJwcmV0YXRpb24gd2hlbiBkZWNvZGVkLiI7DQogIH0NCg0KVGhpcyBleHRlbnNpb24g Y2FuIGJlIHVzZWQgYXMgZm9sbG93Og0KDQogIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25zLXRl c3QtMiB7DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAg ICAgZXh0OnVuaW9uLXRhZyB3ZWVrZGF5czsNCiAgICAgICAgZW51bSAiTW9uZGF5IjsNCiAgICAg ICAgZW51bSAiVHVlc2RheSI7DQogICAgICAgIGVudW0gIldlZG5lc2RheSI7DQogICAgICAgIGVu dW0gIlRodXJzZGF5IjsNCiAgICAgICAgZW51bSAiRnJpZGF5IjsNCiAgICAgIH0NCiAgICAgIHR5 cGUgZW51bWVyYXRpb24gew0KICAgICAgICBleHQ6dW5pb24tdGFnIHdlZWtlbmQ7DQogICAgICAg IGVudW0gIlNhdHVyZGF5IjsNCiAgICAgICAgZW51bSAiU3VuZGF5IjsNCiAgICAgIH0NCiAgICB9 DQogIH0NCg0KSWYgSSBhc3N1bWUgdGhpcyBzb2x1dGlvbiBvciBzaW1pbGFyIHNvbHV0aW9uIGlz IGltcGxlbWVudGVkLCB0aGUgbmV4dCBxdWVzdGlvbiBpcyBob3cgdGhpcyB0YWcgaXMgZW5jb2Rl ZCBpbiBDQk9SLg0KTGV0IGFzc3VtZSB0aGF0IHRoZSBkYXRhIG5vZGUgU0lEIGlzIDE4MjAgYW5k IHRoZSBTSUQgYXNzaWduZWQgdG8gIndlZWtkYXlzIiB0YWcgaXMgIDE4MjEuDQoNCldoZW4gc2V0 IHRvICJUdWVzZGF5IiwgdGhpcyBkYXRhIG5vZGUgY2FuIGJlIGVuY29kZWQgdXNpbmcgYSBDQk9S IG1hcCBhcyBmb2xsb3dzOg0KDQp7DQogICAxODIwIDogeyAid2Vla2RheXMiLCAxfQ0KfQ0KDQpE byB3ZSBuZWVkIHRvIGFkZCBhIENCT1IgdGFnIHRvIHRoaXMgZW5jb2RpbmcgdG8gc3BlY2lmeSB0 aGUgdXNlIG9mIGEgdW5pb24gdGFnPyAoOTkgaW4gdGhpcyBleGFtcGxlKQ0KSSBwZXJzb25hbGx5 IGRvbid0IHRoaW5rIHNvIHNpbmNlIHRoZSB1c2Ugb2YgYSBDQk9SIG1hcCBmb3IgYSB1bmlvbiBk YXRhIG5vZGUgaXMgbm90IGN1cnJlbnRseSBwb3NzaWJsZS4NCg0Kew0KICAgMTgyMCA6ICg5OSkg eyAid2Vla2RheXMiLCAxfQ0KfQ0KDQpTaG91bGQgd2UgdXNlIGEgU0lEIGluc3RlYWQgb2YgdGhl IHRhZz8gDQoNCnsNCiAgIDE4MjAgOiB7IDE4MjEsIDF9DQp9DQoNClNob3VsZCB3ZSB1c2UgYSBk ZWx0YSBiZXR3ZWVuIHRoZSBkYXRhIG5vZGUgU0lEIGFuZCB0aGUgdW5pb24gdGFnIFNJRD8NClRo ZSBkcmF3YmFjayBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgdGhlIHNhbWUgdmFsdWUgYXNzaWdu ZWQgdG8gZGlmZmVyZW50IGRhdGEgbm9kZXMgaXMgZW5jb2RlZCBkaWZmZXJlbnRseS4NCkkgd29u J3QgcGVyc29uYWxseSByZWNvbW1lbmQgdGhpcyBhcHByb2FjaC4NCg0Kew0KICAgMTgyMCA6IHsg MSwgMX0NCn0NCg0KSSBob3BlIHRoaXMgZW1haWwgd2lsbCBoZWxwIG1vdmluZyB0aGUgZGlzY3Vz c2lvbiBjbG9zZXIgdG8gdGhlIGZpbmFsIHNvbHV0aW9uLg0KDQpQbGVhc2UgY29tbWVudHMNCk1p Y2hlbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSnVlcmdlbiBTY2hvZW53 YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IA0KU2VudDogV2Vk bmVzZGF5LCBNYXJjaCAyNywgMjAxOSAyOjE3IEFNDQpUbzogTWljaGVsIFZlaWxsZXR0ZSA8TWlj aGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPg0KQ2M6IExhZGlzbGF2IExob3RrYSA8bGhvdGth QG5pYy5jej47IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPjsgbmV0Y29uZkBpZXRmLm9y ZzsgY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGlu IENCT1INCg0KSGksDQoNCmEgdW5pb24gY2FuIGJlIGZvcm1lZCBieSB1c2luZyBtZW1iZXIgdHlw ZXMgdGhhdCBhcmUgaW1wb3J0ZWQgYW5kIG5vdCB1bmRlciBjaGFuZ2UgY29udHJvbCBvZiBhIHNp bmdsZSBhdXRob3Ivb3JnYW5pemF0aW9uIGFuZCBpZGVhbGx5IHRoaXMgc2hvdWxkIHdvcmsgd2l0 aG91dCBjb21wbGV4IGNvb3JkaW5hdGlvbiBvZiBuYW1lIGFuZCBudW1iZXIgc3BhY2VzLg0KRHVw bGljYXRlIGVudW0vYml0cyB2YWx1ZXMgYXJlIGxlZ2FsIGluIFlBTkcgdG9kYXkgc28gYW4gZW5j b2RpbmcgaGFzIHRvIGRlYWwgd2l0aCB0aGlzIGFzcGVjdCBvZiBsaWZlLg0KDQpBIHJvYnVzdCBm aXggdG8gYWxsIHRoZXNlIHByb2JsZW1zIHdpbGwgYmUgdG8gdGFnIHRoZSB0eXBlIG1lbWJlcnMg aW4gb3JkZXIgdG8gZGlzY3JpbWluYXRlIHRoZSB2YWx1ZXMgaW4gdGhlIGVuY29kaW5ncy4gVGhp cywgaG93ZXZlciwgd2lsbCB0YWtlIHNvbWUgdGltZSB0byBzcGVjaWZ5IGFuZCB3ZSB3aWxsIG5l ZWQgdG8gcHJlc2VydmUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCB1bmlvbnMgd2l0aG91 dCBhIHRhZyAoYnV0IGNvbXBpbGVycyBjYW4gZW5jb3VyYWdlIHBlb3BsZSB0byBhZGQgdGFncyB3 aGVuZXZlciBtb2R1bGVzIGFyZSB1cGRhdGVkKS4NCg0KL2pzDQoNCk9uIFdlZCwgTWFyIDI3LCAy MDE5IGF0IDAxOjEyOjUyQU0gKzAwMDAsIE1pY2hlbCBWZWlsbGV0dGUgd3JvdGU6DQo+IEhpIExh ZGlzbGF2DQo+IA0KPiBJZiBJIHN1bW1hcml6ZSB0aGlzIGlzc3VlIG9mIG11bHRpcGxlIGVudW1l cmF0aW9ucyBvciBiaXRzIGluIGEgdW5pb24sIHRoaXMgcHJvYmxlbSBjYW4gYmUgc29sdmUgYnkg dGhlIGZvbGxvd2luZyBhcHByb2FjaGVzOg0KPiANCj4gLSBUbyBub3QgYWxsb3dzIHRoZXNlIGR1 cGxpY2F0ZSB2YWx1ZXMgb3IgcG9zaXRpb25zIHRvIGhhcHBlbiBpbiBZQU5HDQo+IC0gVG8gZW5j b2RlIGVudW1lcmF0aW9ucyBhbmQgYml0cyBhcyBzdHJpbmcgKGluIGFsbCB1bmlvbnMgb3Igb25s eSANCj4gd2hlbiBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgb3IgYml0cyBhcmUgZGVmaW5lZCkNCj4g LSBUbyBlbmNvZGUgZW51bWVyYXRpb25zIGFuZCBiaXRzIGFzIFNJRCAoaW4gYWxsIHVuaW9ucyBv ciBvbmx5IHdoZW4gDQo+IG11bHRpcGxlIGVudW1lcmF0aW9ucyBvciBiaXRzIGFyZSBkZWZpbmVk KQ0KPiAtIFRvIGVuY29kZSBlbnVtZXJhdGlvbnMgYW5kIGJpdHMgYXMgZGVsdGEgYmV0d2VlbiB0 aGUgdmFsdWUgU0lEIGFuZCANCj4gdGhlIGxlYWYgU0lEIChpbiBhbGwgdW5pb25zIG9yIG9ubHkg d2hlbiBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgb3IgYml0cyANCj4gYXJlIGRlZmluZWQpDQo+IA0K PiBJbiB0aGlzIGVtYWlsLCBJIHdpbGwgbGlrZSB0byBmb2N1cyBvbiB0aGUgZmlyc3Qgb3B0aW9u LCBmaXhpbmcgdGhlIHByb2JsZW0gZGlyZWN0bHkgaW4gWUFORyBpbnN0ZWFkIG9mIGZpeGluZyB0 aGUgY29uc2VxdWVuY2VzLg0KPiANCj4gV2l0aG91dCBhbnkgY2hhbmdlcyBpbiBZQU5HLCBhIHVu aW9uIHdpdGggbXVsdGlwbGUgZW51bWVyYXRpb24gb3IgYml0cyBjYW4gYmUgY29uc3RydWN0ZWQg d2l0aG91dCB2YWx1ZSBvciBwb3NpdGlvbiBvdmVybGFwcy4NCj4gRm9yIGV4YW1wbGU6DQo+IA0K PiAgIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25zLXRlc3QtMSB7DQo+ICAgICB0eXBlIHVuaW9u IHsNCj4gICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ICAgICAgICAgZW51bSAiTW9uZGF5IiB7 IHZhbHVlIDA7IH0NCj4gICAgICAgICBlbnVtICJUdWVzZGF5IiB7IHZhbHVlIDE7IH0NCj4gICAg ICAgICBlbnVtICJXZWRuZXNkYXkiIHsgdmFsdWUgMjsgfQ0KPiAgICAgICAgIGVudW0gIlRodXJz ZGF5IiB7IHZhbHVlIDM7IH0NCj4gICAgICAgICBlbnVtICJGcmlkYXkiIHsgdmFsdWUgNDsgfQ0K PiANCj4gICAgICAgfQ0KPiAgICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4gICAgICAgICBlbnVt ICJTYXR1cmRheSIgeyB2YWx1ZSA1OyB9DQo+ICAgICAgICAgZW51bSAiU3VuZGF5IiB7IHZhbHVl IDY7IH0NCj4gICAgICAgfQ0KPiAgICAgfQ0KPiAgIH0NCj4gDQo+ICAgbGVhZiBtdWx0aXBsZS1i aXRzLXRlc3QtMSB7DQo+ICAgICB0eXBlIHVuaW9uIHsNCj4gICAgICAgdHlwZSBiaXRzIHsNCj4g ICAgICAgICBiaXQgICJNb25kYXkiIHsgcG9zaXRpb24gIDA7IH0NCj4gICAgICAgICBiaXQgIlR1 ZXNkYXkiIHsgcG9zaXRpb24gIDE7IH0NCj4gICAgICAgICBiaXQgIldlZG5lc2RheSIgeyBwb3Np dGlvbiAgMjsgfQ0KPiAgICAgICAgIGJpdCAiVGh1cnNkYXkiIHsgcG9zaXRpb24gIDM7IH0NCj4g ICAgICAgICBiaXQgIkZyaWRheSIgeyBwb3NpdGlvbiAgNDsgfQ0KPiANCj4gICAgICAgfQ0KPiAg ICAgICB0eXBlIGJpdHMgew0KPiAgICAgICAgIGJpdCAiU2F0dXJkYXkiIHsgcG9zaXRpb24gNTsg fQ0KPiAgICAgICAgIGJpdCAiU3VuZGF5IiB7IHBvc2l0aW9uIDY7IH0NCj4gICAgICAgfQ0KPiAg ICAgfQ0KPiAgIH0NCj4gDQo+IFdoZW4gdXNpbmcgYWxyZWFkeSBkZWZpbmVkIHR5cGVkZWYsIGF2 b2lkaW5nIG92ZXJsYXAgaXMgbGVzcyBvYnZpb3VzIHdpdGhvdXQgc29tZSBoZWxwLg0KPiBUbyBo ZWxwIGJ1aWxkaW5nIHVuaW9ucyB3aXRoIGFscmVhZHkgZGVmaW5lZCB0eXBlZGVmcywgSSBwcm9w b3NlIHRvIGludHJvZHVjZSB0d28gZXh0ZW5zaW9ucy4gDQo+IA0KPiAgIGV4dGVuc2lvbiB2YWx1 ZS1vZmZzZXQgew0KPiAgICAgYXJndW1lbnQgb2Zmc2V0IHsNCj4gICAgICAgeWluLWVsZW1lbnQg dHJ1ZTsNCj4gICAgIH0NCj4gICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICJPZmZzZXQgYWRkZWQg dG8gZWFjaCBlbnVtIHZhbHVlIG9mIHRoZSBhc3NvY2lhdGVkIGVudW1lcmF0aW9uLiI7DQo+ICAg fQ0KPiAgIA0KPiAgIGV4dGVuc2lvbiBwb3NpdGlvbi1vZmZzZXQgew0KPiAgICAgYXJndW1lbnQg b2Zmc2V0IHsNCj4gICAgICAgeWluLWVsZW1lbnQgdHJ1ZTsNCj4gICAgIH0NCj4gICAgIGRlc2Ny aXB0aW9uDQo+ICAgICAgICJPZmZzZXQgdmFsdWUgYWRkZWQgdG8gZWFjaCBiaXQgcG9zaXRpb24g b2YgdGhlIGFzc29jaWF0ZWQgYml0cy4iOw0KPiAgIH0NCj4gDQo+IFRoZSB2YWx1ZS1vZmZzZXQg ZXh0ZW5zaW9uIGNhbiBiZSB1c2VkIGFzIGZvbGxvdzoNCj4gDQo+ICAgICB0eXBlIGVudW1lcmF0 aW9uIHsNCj4gICAgICAgZW51bSAiTW9uZGF5IjsNCj4gICAgICAgZW51bSAiVHVlc2RheSI7DQo+ ICAgICAgIGVudW0gIldlZG5lc2RheSI7DQo+ICAgICAgIGVudW0gIlRodXJzZGF5IjsNCj4gICAg ICAgZW51bSAiRnJpZGF5IjsNCj4gICAgIH0NCj4gICB9DQo+IA0KPiAgIHR5cGVkZWYgd2Vla2Vu ZCB7DQo+ICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4gICAgICAgZW51bSAiU2F0dXJkYXkiOw0K PiAgICAgICBlbnVtICJTdW5kYXkiOw0KPiAgICAgfQ0KPiAgIH0NCj4gICANCj4gICBsZWFmIG11 bHRpcGxlLWVudW1lcmF0aW9ucy10ZXN0LTMgew0KPiAgICAgdHlwZSB1bmlvbiB7DQo+ICAgICAg IHR5cGUgd2Vla2RheXM7DQo+ICAgICAgIHR5cGUgd2Vla2VuZCB7DQo+ICAgICAgICAgZXh0OnZh bHVlLW9mZnNldCA1Ow0KPiAgICAgICB9DQo+ICAgICB9DQo+ICAgfQ0KPiANCj4gVGhlIHBvc2l0 aW9uLW9mZnNldCBleHRlbnNpb24gY2FuIGJlIHVzZWQgYXMgZm9sbG93Og0KPiANCj4gICB0eXBl ZGVmIHdlZWtkYXlzLWZsYWdzIHsNCj4gICAgIHR5cGUgYml0cyB7DQo+ICAgICAgIGJpdCAiTW9u ZGF5IjsNCj4gICAgICAgYml0ICJUdWVzZGF5IjsNCj4gICAgICAgYml0ICJXZWRuZXNkYXkiOw0K PiAgICAgICBiaXQgIlRodXJzZGF5IjsNCj4gICAgICAgYml0ICJGcmlkYXkiOw0KPiAgICAgfQ0K PiAgIH0NCj4gDQo+ICAgdHlwZWRlZiB3ZWVrZW5kLWZsYWdzIHsNCj4gICAgIHR5cGUgYml0cyB7 DQo+ICAgICAgIGJpdCAiU2F0dXJkYXkiOw0KPiAgICAgICBiaXQgIlN1bmRheSI7DQo+ICAgICB9 DQo+ICAgfQ0KPiAgIA0KPiAgIGxlYWYgbXVsdGlwbGUtYml0cy10ZXN0LTMgew0KPiAgICAgdHlw ZSB1bmlvbiB7DQo+ICAgICAgIHR5cGUgd2Vla2RheXMtZmxhZ3M7DQo+ICAgICAgIHR5cGUgd2Vl a2VuZC1mbGFncyB7DQo+ICAgICAgICAgZXh0OnBvc2l0aW9uLW9mZnNldCA1Ow0KPiAgICAgICB9 DQo+ICAgICB9DQo+ICAgfQ0KPiANCj4gVGhlIHlhbmcgZmlsZSBpbiBhdHRhY2htZW50IHNob3cg ZGlmZmVyZW50IGV4YW1wbGVzIGJhc2VkIG9uIHRoaXMgYXBwcm9hY2guDQo+IFRoaXMgbW9kdWxl IGhhdmUgYmVlbiB2YWxpZGF0ZWQgdXNpbmcgDQo+IGh0dHBzOi8vY2FuMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGd3d3LnkNCj4gYW5ndmFsaWRh dG9yLmNvbSUyRnZhbGlkYXRvciZhbXA7ZGF0YT0wMiU3QzAxJTdDJTdDYzY5NDI2ZGNhYWY4NDQ4 ZTFkNA0KPiA3MDhkNmIyN2JjNzM1JTdDNGY2ZmJkMTMwZGZiNDE1MDg1YzNkNDMyNjBjMDQzMDkl N0MwJTdDMCU3QzYzNjg5MjY0MjA3DQo+IDMyNTc2NjAmYW1wO3NkYXRhPVhxbzQwbHpCaklOVkZa aElaWkkxTEVrdEFkcTVtZWUyQWR4ZVlxZWZuc0ElM0QmYW1wO3INCj4gZXNlcnZlZD0wIElmIHRo aXMgYXBwcm9hY2ggaXMgYWNjZXB0ZWQsIHRvb2xzIGxpa2UgcHlhbmcgc2hvdWxkIGJlIA0KPiB1 cGRhdGVkIHRvIHByb2R1Y2UgYW4gZXJyb3IgaWYgbXVsdGlwbGUgZW51bWVyYXRpb25zIG9yIGJp dHMgYXJlIGRlZmluZWQgd2l0aCB2YWx1ZSBvciBwb3NpdGlvbiBvdmVybGVhcHMuDQo+IA0KPiBQ bGVhc2UgY29tbWVudCwNCj4gTWljaGVsDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+DQo+IFNlbnQ6IE1vbmRh eSwgTWFyY2ggMjUsIDIwMTkgNDowNyBBTQ0KPiBUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+OyANCj4gQ2Fyc3RlbiBCb3JtYW5u IDxjYWJvQHR6aS5vcmc+DQo+IENjOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRl QHRyaWxsaWFudC5jb20+OyANCj4gbmV0Y29uZkBpZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW25ldGNvbmZdIFlBTkcgZW5jb2RpbmcgaW4gQ0JPUg0KPiANCj4gSnVlcmdl biBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdy aXRlczoNCj4gDQo+ID4gSSB0aGluayB3ZSBuZWVkIHRvIGxvb2sgYXQgdGhlIHdob2xlIHBpY3R1 cmUgYW5kIGluIHdoaWNoIGRpcmVjdGlvbiANCj4gPiB3ZSB3YW50IHRvIGdvLiBJbiB0aGUgbG9u Z2VyIHRlcm0sIEkgd291bGQgcHJlZmVyIGEgc29sdXRpb24gd2hlcmUgDQo+ID4gdGhlIHZhbHVl cyBvZiBhIHVuaW9uIGFyZSBkaXNjcmltaW5hdGVkLiBUaGUgY3VycmVudCBYTUwgZW5jb2Rpbmcg DQo+ID4gYmVoYXZpb3VyIG9mICdmaXJzdCBtYXRjaCB3aW5zJyBpcyBmcmFnaWxlIChmb3IgZXhh bXBsZSwgaWYgc29tZW9uZSANCj4gPiBhZGRzIGFuIGVudW0gdG8gYSB0eXBlLCB0aGUgaW50ZXJw cmV0YXRpb24gb2YgZGF0YSBjYW4gY2hhbmdlKS4NCj4gPg0KPiA+IExvb2sgYXQgdGhpczoNCj4g Pg0KPiA+IHR5cGVkZWYgYmFyIHsNCj4gPiAgIHR5cGUgdW5pb24gew0KPiA+ICAgICB0eXBlIGVu dW1lcmF0aW9uIHsgZW51bSAiMSI7IHZhbHVlIDI7IGVudW0gIjIiOyB2YWx1ZSAxOyB9DQo+ID4g ICAgIHR5cGUgdWludDg7DQo+ID4gICB9DQo+ID4gfQ0KPiA+DQo+ID4gV2UgaGF2ZSBzb21lIGVu Y29kaW5ncyB0aGF0IHNlbmQgdGhlIHN0cmluZyByZXByZXNlbnRhdGlvbnMgb2YgdGhlIA0KPiA+ IHZhbHVlcyBhbmQgc29tZSBlbmNvZGluZ3MgdGhhdCBwcmVmZXIgdG8gc2VuZCBudW1lcmljIA0K PiA+IHJlcHJlc2VudGF0aW9ucyB3aGVyZSBwb3NzaWJsZS4gSW4gb3JkZXIgdG8gaGF2ZSBhIHJv YnVzdCBzb2x1dGlvbiwgDQo+ID4gZW5jb2RpbmdzIHNob3VsZCBsaWtlbHkgaW5kaWNhdGUgdG8g d2hpY2ggdHlwZSB0aGUgdmFsdWUgYmVsb25ncy4NCj4gDQo+IFBlcmhhcHMgdGhlIGVhc2llc3Qg d2F5IHdvdWxkIGJlIHRvIHVzZSAob3B0aW9uYWwpIGFubm90YXRpb24gdGhhdCBzcGVjaWZpZXMs IHVzaW5nIGFuIG9yZGluYWwgbnVtYmVyLCB3aGljaCBvZiB0aGUgbWVtYmVyIHR5cGVzIGlzIHVz ZWQgZm9yIHRoZSBwYXJ0aWN1bGFyIGluc3RhbmNlLiBCdXQgc2luY2UgdGhlcmUgY2FuIGJlIHVu aW9ucyBpbnNpZGUgdW5pb25zLCBhIGxpc3Qgb2YgbnVtYmVycyB3b3VsZCBiZSBuZWVkZWQgaW4g Z2VuZXJhbC4NCj4gDQo+IExhZGENCj4gDQo+ID4NCj4gPiAvanMNCj4gPg0KPiA+IE9uIFNhdCwg TWFyIDIzLCAyMDE5IGF0IDEwOjAzOjMyQU0gKzAxMDAsIENhcnN0ZW4gQm9ybWFubiB3cm90ZToN Cj4gPj4gV2VsbCwgaWYgdGhhdCBpcyBhIHByb2JsZW0sIHdlIGNhbiBnbyBmb3IgYSBsb25nZXIg cmVwcmVzZW50YXRpb24gd2l0aGluIHVuaW9ucyAoc2VjdGlvbiA2LjEyKS4gIFRoZW9yZXRpY2Fs bHksIHdlIGNvdWxkIGRvIHRoYXQgb25seSBvZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGVudW0g aW4gdGhlIHVuaW9uIHR5cGUgKHNvIHRoaW5ncyBzdGF5IGVmZmljaWVudCBpZiB0aGVyZSBpcyBv bmx5IG9uZSksIGJ1dCB0aGF0IG1pZ2h0IHBvc2UgZGlmZmljdWx0aWVzIHdpdGggbW9kZWwgZXZv bHV0aW9uLg0KPiA+PiANCj4gPj4gR29pbmcgZm9yIGEgc3RyaW5nIHJlcHJlc2VudGF0aW9uIHJl cGVhdHMgdGhlIGZlYXR1cmUgb2YgWE1MIFlBTkcgKHdoaWNoIHdhcyBwb3J0ZWQgb3ZlciB0byBK U09OIFlBTkcpOg0KPiA+PiANCj4gPj4gdHlwZWRlZiBmb28gew0KPiA+PiAgIHR5cGUgdW5pb24g ew0KPiA+PiAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ID4+ICAgICAgIGVudW0gcmVkIHsgdmFs dWUgMTsgfQ0KPiA+PiAgICAgICBlbnVtIGJyZWVuIHsgdmFsdWUgMjsgfQ0KPiA+PiAgICAgICBl bnVtIGdsdWUgeyB2YWx1ZSAzOyB9DQo+ID4+ICAgICB9DQo+ID4+ICAgICB0eXBlIGVudW1lcmF0 aW9uIHsNCj4gPj4gICAgICAgZW51bSB0YWNrcyB7IHZhbHVlIDE7IH0NCj4gPj4gICAgICAgZW51 bSBuYWlscyB7IHZhbHVlIDI7IH0NCj4gPj4gICAgICAgZW51bSBnbHVlIHsgdmFsdWUgMzsgfQ0K PiA+PiAgICAgfQ0KPiA+PiAgIH0NCj4gPj4gfQ0KPiA+PiANCj4gPj4gSWYgeW91IHVzZSDigJxn bHVl4oCdLCB5b3UgZG9u4oCZdCBrbm93IHdoaWNoIG9mIHRoZSBlbnVtZXJhdGlvbnMgYXJlIGJl aW5nIHVzZWQuDQo+ID4+IA0KPiA+PiBVc2luZyBTSURzLCB3ZSBjYW4gZG8gYmV0dGVyLg0KPiA+ PiANCj4gPj4gU28gd2hhdCBkbyB3ZSBoYXZlIHRvIGRvIHRvIGdldCB0aGUgU0lEIHRvb2wgdG8g YWxsb2NhdGUgU0lEcyBmb3IgZW51bSB2YWx1ZXM/DQo+ID4+IA0KPiA+PiBXZSBjb3VsZCB0aGVu IGRlZmluZSB0aGUgQ0JPUiB0YWcgZm9yIGVudW1zIGluIHVuaW9ucyB0byB0YWtlIHRoZSB1c3Vh bCBTSUQgZGlmZmVyZW5jZSAoZGVsdGEgcmVsYXRpdmUgdG8gdGhlIGVudmlyb25tZW50LCBJ4oCZ ZCB0aGluayksIG5vdCBhbiBpbnRlZ2VyIHZhbHVlLg0KPiA+PiANCj4gPj4gU2V2ZXJhbCBvZiB1 cyBhcmUgYXQgdGhlIGhhY2thdGhvbiBhbmQgY291bGQgbWFrZSBzb21ldGhpbmcgaGFwcGVuIHRv ZGF5IGFuZCB0b21vcnJvdy4NCj4gPj4gDQo+ID4+IEdyw7zDn2UsIENhcnN0ZW4NCj4gPj4gDQo+ ID4+IA0KPiA+PiA+IE9uIE1hciAyMiwgMjAxOSwgYXQgMTg6MzAsIFJvYiBXaWx0b24gKHJ3aWx0 b24pIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+ID4gDQo+ID4+ID4gSSBndWVzcyB0 aGF0IHRoZSBjb25jZXJuIGlzIHRoYXQgdGhpcyBpbnRyb2R1Y2VzIG1vcmUgdmFyaWF0aW9uIGlu IGhvdyBkYXRhIGlzIGludGVycHJldGVkIGJldHdlZW4gdGhlIGRpZmZlcmVudCBYTUwvSlNPTi9D Qk9SIGVuY29kaW5ncy4NCj4gPj4gPiANCj4gPj4gPiBFLmcuIGlmIHNvbWVvbmUgc3dpdGNoZWQg ZnJvbSBYTUwgdG8gQ0JPUiwgc3VkZGVubHkgdGhlIGNvbmZpZ3VyYXRpb24gb3Igc3RhdGUgZGF0 YSBtYXkgaGF2ZSBhIGRpZmZlcmVudCBtZWFuaW5nLg0KPiA+PiA+IA0KPiA+PiA+IFRoYW5rcywN Cj4gPj4gPiBSb2INCj4gPj4gPiANCj4gPj4gPiANCj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gPj4gRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQo+ ID4+ID4+IFNlbnQ6IDIyIE1hcmNoIDIwMTkgMTY6MDgNCj4gPj4gPj4gVG86IE1pY2hlbCBWZWls bGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50LmNvbT4NCj4gPj4gPj4gQ2M6IFJvYiBX aWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47IGNvcmVAaWV0Zi5vcmc7IA0KPiA+ PiA+PiBuZXRjb25mQGlldGYub3JnDQo+ID4+ID4+IFN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFO RyBlbmNvZGluZyBpbiBDQk9SDQo+ID4+ID4+IA0KPiA+PiA+PiBPbiBNYXIgMjIsIDIwMTksIGF0 IDE2OjQ1LCBNaWNoZWwgVmVpbGxldHRlIA0KPiA+PiA+PiA8TWljaGVsLlZlaWxsZXR0ZUB0cmls bGlhbnQuY29tPg0KPiA+PiA+PiB3cm90ZToNCj4gPj4gPj4+IA0KPiA+PiA+Pj4gVGhlIG9ubHkg cG90ZW50aWFsIHByb2JsZW0gSSBhd2FyZSBpcyB3aGVuIG11bHRpcGxlIA0KPiA+PiA+Pj4gZW51 bWVyYXRpb25zIGFyZSBwYXJ0IG9mDQo+ID4+ID4+IHRoZSBzYW1lIHVuaW9uLg0KPiA+PiA+Pj4g VmFsdWUgNCBmcm9tIGVudW1lcmF0aW9uIEEgd2lsbCBiZSBlbmNvZGVkIHRoZSBzYW1lIHdheSBh cyANCj4gPj4gPj4+IFZhbHVlDQo+ID4+ID4+PiA0IGZyb20NCj4gPj4gPj4gZW51bWVyYXRpb24g Qi4NCj4gPj4gPj4gDQo+ID4+ID4+IOKApiBhbmQgdGhhdCBpcyBub3QgYSBwcm9ibGVtIGZvciB0 aGUgWE1MIHZlcnNpb24sIGJlY2F1c2UgdGhlIA0KPiA+PiA+PiBzdHJpbmcgaXMgYmVpbmcgdXNl ZCBpbnN0ZWFkIG9mIHRoZSB2YWx1ZS4gIChCdXQgdGhlbiBpZiB0d28gDQo+ID4+ID4+IGVudW1l cmF0aW9ucyBzaGFyZSBhIHN0cmluZywgeW91IGhhdmUgdGhlIGVxdWl2YWxlbnQgcHJvYmxlbSBp biANCj4gPj4gPj4gdGhlIFhNTCBzZXJpYWxpemF0aW9uLikNCj4gPj4gPj4gDQo+ID4+ID4+IEFu eXdheSwgSSBoYXZlbuKAmXQgc2VlbiBhIHBpZWNlIG9mIHJlYWwtd29ybGQgWUFORyB0aGF0IGFj dHVhbGx5IA0KPiA+PiA+PiBoYXMgdGhpcyBwcm9ibGVtLCBzbyBJIHdvdWxkIGJlIGEgYml0IHJl bHVjdGFudCB0byBtYWtlIA0KPiA+PiA+PiBDQk9SLWJhc2VkIGltcGxlbWVudGF0aW9ucyBtb3Jl IGNvbXBsZXggKGFuZCBsZXNzIGVmZmljaWVudCkgc28gc29sdmUgdGhpcyAobm9uLT8pcHJvYmxl bS4NCj4gPj4gPj4gDQo+ID4+ID4+IEdyw7zDn2UsIENhcnN0ZW4NCj4gPj4gPiANCj4gPj4gPiAN Cj4gPj4gPiANCj4gPj4gDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4+IG5ldGNvbmZAaWV0 Zi5vcmcNCj4gPj4gaHR0cHM6Ly9jYW4wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGdw0KPiA+PiB3dw0KPiA+PiAuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZuZXRjb25mJmFtcDtkYXRhPTAyJTdDMDElN0MlN0MzNDNlDQo+ID4+IGE4 DQo+ID4+IGQxY2Y4ZjRlMzlhZmM3MDhkNmIwZjhkODc0JTdDNGY2ZmJkMTMwZGZiNDE1MDg1YzNk NDMyNjBjMDQzMDklN0MwJTcNCj4gPj4gQzENCj4gPj4gJTdDNjM2ODkwOTgwMTgyNTUzNDAwJmFt cDtzZGF0YT11MUtGQVlBdXMxNkI4YTdzZ3NCZlBmSXF1T3B0TWxhT2IlMg0KPiA+PiBCMA0KPiA+ PiBrdlBaZ3I0byUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiA+DQo+ID4gLS0gDQo+ID4gSnVlcmdlbiBT Y2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4g PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBC cmVtZW4gfCBHZXJtYW55DQo+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0 cHM6Ly9jYW4wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGd3d3LmphY29icy11bml2ZXJzaXR5LmRlJTJGJmFtcDtkYXRhPTAyJTdDMDElN0MlN0Nj Njk0MjZkY2FhZjg0NDhlMWQ0NzA4ZDZiMjdiYzczNSU3QzRmNmZiZDEzMGRmYjQxNTA4NWMzZDQz MjYwYzA0MzA5JTdDMCU3QzAlN0M2MzY4OTI2NDIwNzMyNTc2NjAmYW1wO3NkYXRhPVJxU1l1TnBs UzRrT0xVMFIzZXRSenJSJTJGVTJjY3dsamtFWmtqSEhEVTFIQSUzRCZhbXA7cmVzZXJ2ZWQ9MD4N Cj4gPg0KPiA+DQo+ID4gT24gU2F0LCBNYXIgMjMsIDIwMTkgYXQgMTA6MDM6MzJBTSArMDEwMCwg Q2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0KPiA+PiBXZWxsLCBpZiB0aGF0IGlzIGEgcHJvYmxlbSwg d2UgY2FuIGdvIGZvciBhIGxvbmdlciByZXByZXNlbnRhdGlvbiB3aXRoaW4gdW5pb25zIChzZWN0 aW9uIDYuMTIpLiAgVGhlb3JldGljYWxseSwgd2UgY291bGQgZG8gdGhhdCBvbmx5IG9mIHRoZXJl IGlzIG1vcmUgdGhhbiBvbmUgZW51bSBpbiB0aGUgdW5pb24gdHlwZSAoc28gdGhpbmdzIHN0YXkg ZWZmaWNpZW50IGlmIHRoZXJlIGlzIG9ubHkgb25lKSwgYnV0IHRoYXQgbWlnaHQgcG9zZSBkaWZm aWN1bHRpZXMgd2l0aCBtb2RlbCBldm9sdXRpb24uDQo+ID4+IA0KPiA+PiBHb2luZyBmb3IgYSBz dHJpbmcgcmVwcmVzZW50YXRpb24gcmVwZWF0cyB0aGUgZmVhdHVyZSBvZiBYTUwgWUFORyAod2hp Y2ggd2FzIHBvcnRlZCBvdmVyIHRvIEpTT04gWUFORyk6DQo+ID4+IA0KPiA+PiB0eXBlZGVmIGZv byB7DQo+ID4+ICAgdHlwZSB1bmlvbiB7DQo+ID4+ICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4g Pj4gICAgICAgZW51bSByZWQgeyB2YWx1ZSAxOyB9DQo+ID4+ICAgICAgIGVudW0gYnJlZW4geyB2 YWx1ZSAyOyB9DQo+ID4+ICAgICAgIGVudW0gZ2x1ZSB7IHZhbHVlIDM7IH0NCj4gPj4gICAgIH0N Cj4gPj4gICAgIHR5cGUgZW51bWVyYXRpb24gew0KPiA+PiAgICAgICBlbnVtIHRhY2tzIHsgdmFs dWUgMTsgfQ0KPiA+PiAgICAgICBlbnVtIG5haWxzIHsgdmFsdWUgMjsgfQ0KPiA+PiAgICAgICBl bnVtIGdsdWUgeyB2YWx1ZSAzOyB9DQo+ID4+ICAgICB9DQo+ID4+ICAgfQ0KPiA+PiB9DQo+ID4+ IA0KPiA+PiBJZiB5b3UgdXNlIOKAnGdsdWXigJ0sIHlvdSBkb27igJl0IGtub3cgd2hpY2ggb2Yg dGhlIGVudW1lcmF0aW9ucyBhcmUgYmVpbmcgdXNlZC4NCj4gPj4gDQo+ID4+IFVzaW5nIFNJRHMs IHdlIGNhbiBkbyBiZXR0ZXIuDQo+ID4+IA0KPiA+PiBTbyB3aGF0IGRvIHdlIGhhdmUgdG8gZG8g dG8gZ2V0IHRoZSBTSUQgdG9vbCB0byBhbGxvY2F0ZSBTSURzIGZvciBlbnVtIHZhbHVlcz8NCj4g Pj4gDQo+ID4+IFdlIGNvdWxkIHRoZW4gZGVmaW5lIHRoZSBDQk9SIHRhZyBmb3IgZW51bXMgaW4g dW5pb25zIHRvIHRha2UgdGhlIHVzdWFsIFNJRCBkaWZmZXJlbmNlIChkZWx0YSByZWxhdGl2ZSB0 byB0aGUgZW52aXJvbm1lbnQsIEnigJlkIHRoaW5rKSwgbm90IGFuIGludGVnZXIgdmFsdWUuDQo+ ID4+IA0KPiA+PiBTZXZlcmFsIG9mIHVzIGFyZSBhdCB0aGUgaGFja2F0aG9uIGFuZCBjb3VsZCBt YWtlIHNvbWV0aGluZyBoYXBwZW4gdG9kYXkgYW5kIHRvbW9ycm93Lg0KPiA+PiANCj4gPj4gR3LD vMOfZSwgQ2Fyc3Rlbg0KPiA+PiANCj4gPj4gDQo+ID4+ID4gT24gTWFyIDIyLCAyMDE5LCBhdCAx ODozMCwgUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4g Pj4gPiANCj4gPj4gPiBJIGd1ZXNzIHRoYXQgdGhlIGNvbmNlcm4gaXMgdGhhdCB0aGlzIGludHJv ZHVjZXMgbW9yZSB2YXJpYXRpb24gaW4gaG93IGRhdGEgaXMgaW50ZXJwcmV0ZWQgYmV0d2VlbiB0 aGUgZGlmZmVyZW50IFhNTC9KU09OL0NCT1IgZW5jb2RpbmdzLg0KPiA+PiA+IA0KPiA+PiA+IEUu Zy4gaWYgc29tZW9uZSBzd2l0Y2hlZCBmcm9tIFhNTCB0byBDQk9SLCBzdWRkZW5seSB0aGUgY29u ZmlndXJhdGlvbiBvciBzdGF0ZSBkYXRhIG1heSBoYXZlIGEgZGlmZmVyZW50IG1lYW5pbmcuDQo+ ID4+ID4gDQo+ID4+ID4gVGhhbmtzLA0KPiA+PiA+IFJvYg0KPiA+PiA+IA0KPiA+PiA+IA0KPiA+ PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+PiBGcm9tOiBDYXJzdGVuIEJv cm1hbm4gPGNhYm9AdHppLm9yZz4NCj4gPj4gPj4gU2VudDogMjIgTWFyY2ggMjAxOSAxNjowOA0K PiA+PiA+PiBUbzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQu Y29tPg0KPiA+PiA+PiBDYzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29t PjsgY29yZUBpZXRmLm9yZzsgDQo+ID4+ID4+IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPj4gPj4gU3Vi amVjdDogUmU6IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGluIENCT1INCj4gPj4gPj4gDQo+ID4+ ID4+IE9uIE1hciAyMiwgMjAxOSwgYXQgMTY6NDUsIE1pY2hlbCBWZWlsbGV0dGUgDQo+ID4+ID4+ IDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudC5jb20+DQo+ID4+ID4+IHdyb3RlOg0KPiA+PiA+ Pj4gDQo+ID4+ID4+PiBUaGUgb25seSBwb3RlbnRpYWwgcHJvYmxlbSBJIGF3YXJlIGlzIHdoZW4g bXVsdGlwbGUgDQo+ID4+ID4+PiBlbnVtZXJhdGlvbnMgYXJlIHBhcnQgb2YNCj4gPj4gPj4gdGhl IHNhbWUgdW5pb24uDQo+ID4+ID4+PiBWYWx1ZSA0IGZyb20gZW51bWVyYXRpb24gQSB3aWxsIGJl IGVuY29kZWQgdGhlIHNhbWUgd2F5IGFzIA0KPiA+PiA+Pj4gVmFsdWUNCj4gPj4gPj4+IDQgZnJv bQ0KPiA+PiA+PiBlbnVtZXJhdGlvbiBCLg0KPiA+PiA+PiANCj4gPj4gPj4g4oCmIGFuZCB0aGF0 IGlzIG5vdCBhIHByb2JsZW0gZm9yIHRoZSBYTUwgdmVyc2lvbiwgYmVjYXVzZSB0aGUgDQo+ID4+ ID4+IHN0cmluZyBpcyBiZWluZyB1c2VkIGluc3RlYWQgb2YgdGhlIHZhbHVlLiAgKEJ1dCB0aGVu IGlmIHR3byANCj4gPj4gPj4gZW51bWVyYXRpb25zIHNoYXJlIGEgc3RyaW5nLCB5b3UgaGF2ZSB0 aGUgZXF1aXZhbGVudCBwcm9ibGVtIGluIA0KPiA+PiA+PiB0aGUgWE1MIHNlcmlhbGl6YXRpb24u KQ0KPiA+PiA+PiANCj4gPj4gPj4gQW55d2F5LCBJIGhhdmVu4oCZdCBzZWVuIGEgcGllY2Ugb2Yg cmVhbC13b3JsZCBZQU5HIHRoYXQgYWN0dWFsbHkgDQo+ID4+ID4+IGhhcyB0aGlzIHByb2JsZW0s IHNvIEkgd291bGQgYmUgYSBiaXQgcmVsdWN0YW50IHRvIG1ha2UgDQo+ID4+ID4+IENCT1ItYmFz ZWQgaW1wbGVtZW50YXRpb25zIG1vcmUgY29tcGxleCAoYW5kIGxlc3MgZWZmaWNpZW50KSBzbyBz b2x2ZSB0aGlzIChub24tPylwcm9ibGVtLg0KPiA+PiA+PiANCj4gPj4gPj4gR3LDvMOfZSwgQ2Fy c3Rlbg0KPiA+PiA+IA0KPiA+PiA+IA0KPiA+PiA+IA0KPiA+PiANCj4gPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gbmV0Y29uZiBtYWlsaW5n IGxpc3QNCj4gPj4gbmV0Y29uZkBpZXRmLm9yZw0KPiA+PiBodHRwczovL2NhbjAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3DQo+ID4+IHd3DQo+ ID4+IC5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm5ldGNvbmYmYW1wO2RhdGE9MDIl N0MwMSU3QyU3QzM0M2UNCj4gPj4gYTgNCj4gPj4gZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQl N0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3QzAlNw0KPiA+PiBDMQ0KPiA+PiAl N0M2MzY4OTA5ODAxODI1NTM0MDAmYW1wO3NkYXRhPXUxS0ZBWUF1czE2QjhhN3Nnc0JmUGZJcXVP cHRNbGFPYiUyDQo+ID4+IEIwDQo+ID4+IGt2UFpncjRvJTNEJmFtcDtyZXNlcnZlZD0wDQo+ID4N Cj4gPiAtLSANCj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2 ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAg Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQy MSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUlMkYm YW1wO2RhdGE9MDIlN0MwMSU3QyU3Q2M2OTQyNmRjYWFmODQ0OGUxZDQ3MDhkNmIyN2JjNzM1JTdD NGY2ZmJkMTMwZGZiNDE1MDg1YzNkNDMyNjBjMDQzMDklN0MwJTdDMCU3QzYzNjg5MjY0MjA3MzI1 NzY2MCZhbXA7c2RhdGE9UnFTWXVOcGxTNGtPTFUwUjNldFJ6clIlMkZVMmNjd2xqa0Vaa2pISERV MUhBJTNEJmFtcDtyZXNlcnZlZD0wPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IG5l dGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuDQo+ID4gaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZuZXRjb25mJmFtcDtkYXRhPTAyJTdDMDElN0MlN0MzNDNlYTgNCj4gPiBk MSANCj4gPiBjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQlN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0 MzI2MGMwNDMwOSU3QzAlN0MxJQ0KPiA+IDdDIA0KPiA+IDYzNjg5MDk4MDE4MjU1MzQwMCZhbXA7 c2RhdGE9dTFLRkFZQXVzMTZCOGE3c2dzQmZQZklxdU9wdE1sYU9iJTJCMGt2DQo+ID4gUFoNCj4g PiBncjRvJTNEJmFtcDtyZXNlcnZlZD0wDQo+IA0KPiAtLQ0KPiBMYWRpc2xhdiBMaG90a2ENCj4g SGVhZCwgQ1ouTklDIExhYnMNCj4gUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQoNCg0K DQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkg QnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5n IDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAg ICAgIDxodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUlMkYmYW1wO2RhdGE9MDIlN0Mw MSU3QyU3Q2M2OTQyNmRjYWFmODQ0OGUxZDQ3MDhkNmIyN2JjNzM1JTdDNGY2ZmJkMTMwZGZiNDE1 MDg1YzNkNDMyNjBjMDQzMDklN0MwJTdDMCU3QzYzNjg5MjY0MjA3MzI2NzY2MCZhbXA7c2RhdGE9 emNRdjRoUjh5a0pGZGh2c2QycW5UUFEzRVBkRVppakRjNGVUJTJCRG1zcXUwJTNEJmFtcDtyZXNl cnZlZD0wPg0K From nobody Wed Mar 27 09:02:32 2019 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 F312C1202F4; Wed, 27 Mar 2019 09:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrBaLDRP0VPa; Wed, 27 Mar 2019 09:02:26 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-sn1nam04on071b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4c::71b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D880120305; Wed, 27 Mar 2019 09:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W9xD9XUrtmdMzI/YcrFAfwj4/4hPRSN6CPG9FyxMceM=; b=FhKd4Mudwwvo2HgeaLObdEFEAzC+ZLsuye5cAWLo8iL10/x8N05zSaT6uhrr+2uBUVhxkR7z/SRVpURIjHrzW+sSY+ppvG6umMShnp3k5Rpa57aHZth0A+CqoT1D3SQ4HiBtSV6ILxE6D4Xc07itkDHzv29HaTGZURlhDnfQBbE= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4914.namprd06.prod.outlook.com (10.167.234.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Wed, 27 Mar 2019 16:01:56 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d%3]) with mapi id 15.20.1730.019; Wed, 27 Mar 2019 16:01:56 +0000 From: Michel Veillette To: Juergen Schoenwaelder CC: Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAL8XAAAAtt/gAAgmRkAAAJStYAAYEUIgABUqX2QAAwU1oAAE3mQoAAA8H+g Date: Wed, 27 Mar 2019 16:01:56 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5af4bcc4-6a92-49f2-8f2e-08d6b2cd898b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:BL0PR06MB4914; x-ms-traffictypediagnostic: BL0PR06MB4914: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0989A7979C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39850400004)(366004)(376002)(346002)(136003)(199004)(189003)(13464003)(52314003)(2906002)(52536014)(4326008)(25786009)(6116002)(114624004)(66066001)(93156006)(3846002)(30864003)(14454004)(53936002)(72206003)(8676002)(81166006)(5024004)(14444005)(33656002)(45080400002)(966005)(76176011)(478600001)(2940100002)(6246003)(71190400001)(5660300002)(26005)(81156014)(86362001)(7696005)(71200400001)(6506007)(102836004)(7736002)(53546011)(316002)(93886005)(99286004)(105586002)(106356001)(6916009)(9686003)(55016002)(54906003)(6306002)(53946003)(446003)(486006)(6436002)(476003)(11346002)(256004)(99936001)(68736007)(74316002)(8936002)(97736004)(186003)(229853002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4914; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0NvUeGnEFeZPawFzjRbRtLaUlMhXYzCoY3RfI5W3jLTVK/JkMlka/RcCrkZBGFSP2607PaZde8Yvg8RpSSVyMKeyd3/XGLN6+wp1DpXR+Y5Xuyc4MgB3TKFqExOZJUiYG45ENGpbtCuda+lNfSo69zu24ek1ew+omOewfkv/lgaaerZsa8z8/h6k8qq64yj8G0W9l8KgIeKCCkRNv8geceUT0dQv/dy6mWxH467QCIcdrHZB0+prr1BRQz8G7VJeQDrQAa35qek8uGyVhlzUtePuVI5vuzk7ibNTG6/f94/CcNIPYC0g2Ed3q4bCLbRVUFISw1XsTPXp5nMPGc3O43rqZ3Lqtltqbj7W8AoXyV2VatqZszQkgB85a/pE20cyzputbQcY+eDwp4SN+p6NwPVcnh6sY8LFP3H9YbzLybs= Content-Type: multipart/mixed; boundary="_002_BL0PR06MB504264D081B40ACBE22CF6C69A580BL0PR06MB5042namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5af4bcc4-6a92-49f2-8f2e-08d6b2cd898b X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 16:01:56.3327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4914 Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 27 Mar 2019 16:02:31 -0000 --_002_BL0PR06MB504264D081B40ACBE22CF6C69A580BL0PR06MB5042namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgZm9yIHRoaXMgZHVwbGljYXRlIGVtYWlsLCBJIGZvcmdvdCB0aGUgYXR0YWNobWVudC4N Cg0KUmVnYXJkcywNCk1pY2hlbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWljaGVsIFZlaWxsZXR0ZSANClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjcsIDIwMTkgMTI6MDEg UE0NClRvOiAnSnVlcmdlbiBTY2hvZW53YWVsZGVyJyA8ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlPg0KQ2M6IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej47IENhcnN0 ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPjsgbmV0Y29uZkBpZXRmLm9yZzsgY29yZUBpZXRmLm9y Zw0KU3ViamVjdDogUkU6IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGluIENCT1INCg0KSGkgSnVl cmdlbg0KDQpZb3Ugd2lsbCBmaW5kIGluIGF0dGFjaG1lbnQgdGhlIHVwZGF0ZWQgdmVyc2lvbiBv ZiAndGVzdC11bmlvbkAyMDE5LTAzLTI1LnlhbmcnIGJhc2VkIG9uIHlvdXIgcHJvcG9zZWQgc29s dXRpb24sIHR5cGUgdGFnZ2luZy4NClRoaXMgbW9kdWxlIGRlZmluZXMgYW4gZXh0ZW5zaW9uIGNh bGxlZCB1bmlvbi10YWcgYXMgZm9sbG93Og0KDQogIGV4dGVuc2lvbiB1bmlvbi10YWcgew0KICAg IGFyZ3VtZW50IHRhZyB7DQogICAgICB5aW4tZWxlbWVudCB0cnVlOw0KICAgIH0NCiAgICBkZXNj cmlwdGlvbg0KICAgICAgIkluIHNvbWUgY2FzZXMsIHRoZSBpbnRlcnByZXRhdGlvbiBvZiBhIHZh bHVlIG9mIGEgdW5pb24gdHlwZSBjYW4gZGlmZmVyDQogICAgICB3aGVuIGVuY29kZWQgdXNpbmcg dGhlIGRpZmZlcmVudCBkYXRhIGZvcm1hdC4gVGhpcyBkaWZmZXJlbmNlIGNvbWVzIGZyb20NCiAg ICAgIHRoZSBsZXZlbCBvZiB0eXBlIGluZm9ybWF0aW9uIHN1cHBvcnRlZCBieSB0aGUgZGlmZmVy ZW50IGRhdGEgZm9ybWF0cy4NCiAgICAgIEluIHRoZSBjYXNlIG9mIFhNTCwgYWxsIGVsZW1lbnRz IGFuZCBhdHRyaWJ1dGVzIGFyZSBlbmNvZGVkIGFzIHN0cmluZw0KICAgICAgYW5kIG5vIHR5cGUg aW5mb3JtYXRpb24gYXJlIGluY2x1ZGVkLiBKU09OIHN1cHBvcnRzIHN0cmluZywgbnVtYmVyIGFu ZA0KICAgICAgYm9vbGVhbi4gRmluYWxseSwgQ0JPUiBzdXBwb3J0cyBhbGwgWUFORyBiYXNpYyB0 eXBlcy4NCg0KICAgICAgVGhpcyBleHRlbnNpb24gY2FuIGJlIHVzZWQgdG8gYWRkIGEgdGFnIHRv IGEgdHlwZSB3aXRoaW4gYSB1bmlvbiB0bw0KICAgICAgZ3VhcmFudGVlIGl0cyBwcm9wZXIgaW50 ZXJwcmV0YXRpb24gd2hlbiBkZWNvZGVkLiI7DQogIH0NCg0KVGhpcyBleHRlbnNpb24gY2FuIGJl IHVzZWQgYXMgZm9sbG93Og0KDQogIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25zLXRlc3QtMiB7 DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgICAgZXh0 OnVuaW9uLXRhZyB3ZWVrZGF5czsNCiAgICAgICAgZW51bSAiTW9uZGF5IjsNCiAgICAgICAgZW51 bSAiVHVlc2RheSI7DQogICAgICAgIGVudW0gIldlZG5lc2RheSI7DQogICAgICAgIGVudW0gIlRo dXJzZGF5IjsNCiAgICAgICAgZW51bSAiRnJpZGF5IjsNCiAgICAgIH0NCiAgICAgIHR5cGUgZW51 bWVyYXRpb24gew0KICAgICAgICBleHQ6dW5pb24tdGFnIHdlZWtlbmQ7DQogICAgICAgIGVudW0g IlNhdHVyZGF5IjsNCiAgICAgICAgZW51bSAiU3VuZGF5IjsNCiAgICAgIH0NCiAgICB9DQogIH0N Cg0KSWYgSSBhc3N1bWUgdGhpcyBzb2x1dGlvbiBvciBzaW1pbGFyIHNvbHV0aW9uIGlzIGltcGxl bWVudGVkLCB0aGUgbmV4dCBxdWVzdGlvbiBpcyBob3cgdGhpcyB0YWcgaXMgZW5jb2RlZCBpbiBD Qk9SLg0KTGV0IGFzc3VtZSB0aGF0IHRoZSBkYXRhIG5vZGUgU0lEIGlzIDE4MjAgYW5kIHRoZSBT SUQgYXNzaWduZWQgdG8gIndlZWtkYXlzIiB0YWcgaXMgIDE4MjEuDQoNCldoZW4gc2V0IHRvICJU dWVzZGF5IiwgdGhpcyBkYXRhIG5vZGUgY2FuIGJlIGVuY29kZWQgdXNpbmcgYSBDQk9SIG1hcCBh cyBmb2xsb3dzOg0KDQp7DQogICAxODIwIDogeyAid2Vla2RheXMiLCAxfQ0KfQ0KDQpEbyB3ZSBu ZWVkIHRvIGFkZCBhIENCT1IgdGFnIHRvIHRoaXMgZW5jb2RpbmcgdG8gc3BlY2lmeSB0aGUgdXNl IG9mIGEgdW5pb24gdGFnPyAoOTkgaW4gdGhpcyBleGFtcGxlKSBJIHBlcnNvbmFsbHkgZG9uJ3Qg dGhpbmsgc28gc2luY2UgdGhlIHVzZSBvZiBhIENCT1IgbWFwIGZvciBhIHVuaW9uIGRhdGEgbm9k ZSBpcyBub3QgY3VycmVudGx5IHBvc3NpYmxlLg0KDQp7DQogICAxODIwIDogKDk5KSB7ICJ3ZWVr ZGF5cyIsIDF9DQp9DQoNClNob3VsZCB3ZSB1c2UgYSBTSUQgaW5zdGVhZCBvZiB0aGUgdGFnPyAN Cg0Kew0KICAgMTgyMCA6IHsgMTgyMSwgMX0NCn0NCg0KU2hvdWxkIHdlIHVzZSBhIGRlbHRhIGJl dHdlZW4gdGhlIGRhdGEgbm9kZSBTSUQgYW5kIHRoZSB1bmlvbiB0YWcgU0lEPw0KVGhlIGRyYXdi YWNrIG9mIHRoaXMgYXBwcm9hY2ggaXMgdGhhdCB0aGUgc2FtZSB2YWx1ZSBhc3NpZ25lZCB0byBk aWZmZXJlbnQgZGF0YSBub2RlcyBpcyBlbmNvZGVkIGRpZmZlcmVudGx5Lg0KSSB3b24ndCBwZXJz b25hbGx5IHJlY29tbWVuZCB0aGlzIGFwcHJvYWNoLg0KDQp7DQogICAxODIwIDogeyAxLCAxfQ0K fQ0KDQpJIGhvcGUgdGhpcyBlbWFpbCB3aWxsIGhlbHAgbW92aW5nIHRoZSBkaXNjdXNzaW9uIGNs b3NlciB0byB0aGUgZmluYWwgc29sdXRpb24uDQoNClBsZWFzZSBjb21tZW50cw0KTWljaGVsDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg PGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NClNlbnQ6IFdlZG5lc2RheSwg TWFyY2ggMjcsIDIwMTkgMjoxNyBBTQ0KVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWls bGV0dGVAdHJpbGxpYW50LmNvbT4NCkNjOiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+ OyBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz47IG5ldGNvbmZAaWV0Zi5vcmc7IGNvcmVA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFORyBlbmNvZGluZyBpbiBDQk9SDQoN CkhpLA0KDQphIHVuaW9uIGNhbiBiZSBmb3JtZWQgYnkgdXNpbmcgbWVtYmVyIHR5cGVzIHRoYXQg YXJlIGltcG9ydGVkIGFuZCBub3QgdW5kZXIgY2hhbmdlIGNvbnRyb2wgb2YgYSBzaW5nbGUgYXV0 aG9yL29yZ2FuaXphdGlvbiBhbmQgaWRlYWxseSB0aGlzIHNob3VsZCB3b3JrIHdpdGhvdXQgY29t cGxleCBjb29yZGluYXRpb24gb2YgbmFtZSBhbmQgbnVtYmVyIHNwYWNlcy4NCkR1cGxpY2F0ZSBl bnVtL2JpdHMgdmFsdWVzIGFyZSBsZWdhbCBpbiBZQU5HIHRvZGF5IHNvIGFuIGVuY29kaW5nIGhh cyB0byBkZWFsIHdpdGggdGhpcyBhc3BlY3Qgb2YgbGlmZS4NCg0KQSByb2J1c3QgZml4IHRvIGFs bCB0aGVzZSBwcm9ibGVtcyB3aWxsIGJlIHRvIHRhZyB0aGUgdHlwZSBtZW1iZXJzIGluIG9yZGVy IHRvIGRpc2NyaW1pbmF0ZSB0aGUgdmFsdWVzIGluIHRoZSBlbmNvZGluZ3MuIFRoaXMsIGhvd2V2 ZXIsIHdpbGwgdGFrZSBzb21lIHRpbWUgdG8gc3BlY2lmeSBhbmQgd2Ugd2lsbCBuZWVkIHRvIHBy ZXNlcnZlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHdpdGggdW5pb25zIHdpdGhvdXQgYSB0YWcg KGJ1dCBjb21waWxlcnMgY2FuIGVuY291cmFnZSBwZW9wbGUgdG8gYWRkIHRhZ3Mgd2hlbmV2ZXIg bW9kdWxlcyBhcmUgdXBkYXRlZCkuDQoNCi9qcw0KDQpPbiBXZWQsIE1hciAyNywgMjAxOSBhdCAw MToxMjo1MkFNICswMDAwLCBNaWNoZWwgVmVpbGxldHRlIHdyb3RlOg0KPiBIaSBMYWRpc2xhdg0K PiANCj4gSWYgSSBzdW1tYXJpemUgdGhpcyBpc3N1ZSBvZiBtdWx0aXBsZSBlbnVtZXJhdGlvbnMg b3IgYml0cyBpbiBhIHVuaW9uLCB0aGlzIHByb2JsZW0gY2FuIGJlIHNvbHZlIGJ5IHRoZSBmb2xs b3dpbmcgYXBwcm9hY2hlczoNCj4gDQo+IC0gVG8gbm90IGFsbG93cyB0aGVzZSBkdXBsaWNhdGUg dmFsdWVzIG9yIHBvc2l0aW9ucyB0byBoYXBwZW4gaW4gWUFORw0KPiAtIFRvIGVuY29kZSBlbnVt ZXJhdGlvbnMgYW5kIGJpdHMgYXMgc3RyaW5nIChpbiBhbGwgdW5pb25zIG9yIG9ubHkgDQo+IHdo ZW4gbXVsdGlwbGUgZW51bWVyYXRpb25zIG9yIGJpdHMgYXJlIGRlZmluZWQpDQo+IC0gVG8gZW5j b2RlIGVudW1lcmF0aW9ucyBhbmQgYml0cyBhcyBTSUQgKGluIGFsbCB1bmlvbnMgb3Igb25seSB3 aGVuIA0KPiBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgb3IgYml0cyBhcmUgZGVmaW5lZCkNCj4gLSBU byBlbmNvZGUgZW51bWVyYXRpb25zIGFuZCBiaXRzIGFzIGRlbHRhIGJldHdlZW4gdGhlIHZhbHVl IFNJRCBhbmQgDQo+IHRoZSBsZWFmIFNJRCAoaW4gYWxsIHVuaW9ucyBvciBvbmx5IHdoZW4gbXVs dGlwbGUgZW51bWVyYXRpb25zIG9yIGJpdHMgDQo+IGFyZSBkZWZpbmVkKQ0KPiANCj4gSW4gdGhp cyBlbWFpbCwgSSB3aWxsIGxpa2UgdG8gZm9jdXMgb24gdGhlIGZpcnN0IG9wdGlvbiwgZml4aW5n IHRoZSBwcm9ibGVtIGRpcmVjdGx5IGluIFlBTkcgaW5zdGVhZCBvZiBmaXhpbmcgdGhlIGNvbnNl cXVlbmNlcy4NCj4gDQo+IFdpdGhvdXQgYW55IGNoYW5nZXMgaW4gWUFORywgYSB1bmlvbiB3aXRo IG11bHRpcGxlIGVudW1lcmF0aW9uIG9yIGJpdHMgY2FuIGJlIGNvbnN0cnVjdGVkIHdpdGhvdXQg dmFsdWUgb3IgcG9zaXRpb24gb3ZlcmxhcHMuDQo+IEZvciBleGFtcGxlOg0KPiANCj4gICBsZWFm IG11bHRpcGxlLWVudW1lcmF0aW9ucy10ZXN0LTEgew0KPiAgICAgdHlwZSB1bmlvbiB7DQo+ICAg ICAgIHR5cGUgZW51bWVyYXRpb24gew0KPiAgICAgICAgIGVudW0gIk1vbmRheSIgeyB2YWx1ZSAw OyB9DQo+ICAgICAgICAgZW51bSAiVHVlc2RheSIgeyB2YWx1ZSAxOyB9DQo+ICAgICAgICAgZW51 bSAiV2VkbmVzZGF5IiB7IHZhbHVlIDI7IH0NCj4gICAgICAgICBlbnVtICJUaHVyc2RheSIgeyB2 YWx1ZSAzOyB9DQo+ICAgICAgICAgZW51bSAiRnJpZGF5IiB7IHZhbHVlIDQ7IH0NCj4gDQo+ICAg ICAgIH0NCj4gICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ICAgICAgICAgZW51bSAiU2F0dXJk YXkiIHsgdmFsdWUgNTsgfQ0KPiAgICAgICAgIGVudW0gIlN1bmRheSIgeyB2YWx1ZSA2OyB9DQo+ ICAgICAgIH0NCj4gICAgIH0NCj4gICB9DQo+IA0KPiAgIGxlYWYgbXVsdGlwbGUtYml0cy10ZXN0 LTEgew0KPiAgICAgdHlwZSB1bmlvbiB7DQo+ICAgICAgIHR5cGUgYml0cyB7DQo+ICAgICAgICAg Yml0ICAiTW9uZGF5IiB7IHBvc2l0aW9uICAwOyB9DQo+ICAgICAgICAgYml0ICJUdWVzZGF5IiB7 IHBvc2l0aW9uICAxOyB9DQo+ICAgICAgICAgYml0ICJXZWRuZXNkYXkiIHsgcG9zaXRpb24gIDI7 IH0NCj4gICAgICAgICBiaXQgIlRodXJzZGF5IiB7IHBvc2l0aW9uICAzOyB9DQo+ICAgICAgICAg Yml0ICJGcmlkYXkiIHsgcG9zaXRpb24gIDQ7IH0NCj4gDQo+ICAgICAgIH0NCj4gICAgICAgdHlw ZSBiaXRzIHsNCj4gICAgICAgICBiaXQgIlNhdHVyZGF5IiB7IHBvc2l0aW9uIDU7IH0NCj4gICAg ICAgICBiaXQgIlN1bmRheSIgeyBwb3NpdGlvbiA2OyB9DQo+ICAgICAgIH0NCj4gICAgIH0NCj4g ICB9DQo+IA0KPiBXaGVuIHVzaW5nIGFscmVhZHkgZGVmaW5lZCB0eXBlZGVmLCBhdm9pZGluZyBv dmVybGFwIGlzIGxlc3Mgb2J2aW91cyB3aXRob3V0IHNvbWUgaGVscC4NCj4gVG8gaGVscCBidWls ZGluZyB1bmlvbnMgd2l0aCBhbHJlYWR5IGRlZmluZWQgdHlwZWRlZnMsIEkgcHJvcG9zZSB0byBp bnRyb2R1Y2UgdHdvIGV4dGVuc2lvbnMuIA0KPiANCj4gICBleHRlbnNpb24gdmFsdWUtb2Zmc2V0 IHsNCj4gICAgIGFyZ3VtZW50IG9mZnNldCB7DQo+ICAgICAgIHlpbi1lbGVtZW50IHRydWU7DQo+ ICAgICB9DQo+ICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAiT2Zmc2V0IGFkZGVkIHRvIGVhY2gg ZW51bSB2YWx1ZSBvZiB0aGUgYXNzb2NpYXRlZCBlbnVtZXJhdGlvbi4iOw0KPiAgIH0NCj4gICAN Cj4gICBleHRlbnNpb24gcG9zaXRpb24tb2Zmc2V0IHsNCj4gICAgIGFyZ3VtZW50IG9mZnNldCB7 DQo+ICAgICAgIHlpbi1lbGVtZW50IHRydWU7DQo+ICAgICB9DQo+ICAgICBkZXNjcmlwdGlvbg0K PiAgICAgICAiT2Zmc2V0IHZhbHVlIGFkZGVkIHRvIGVhY2ggYml0IHBvc2l0aW9uIG9mIHRoZSBh c3NvY2lhdGVkIGJpdHMuIjsNCj4gICB9DQo+IA0KPiBUaGUgdmFsdWUtb2Zmc2V0IGV4dGVuc2lv biBjYW4gYmUgdXNlZCBhcyBmb2xsb3c6DQo+IA0KPiAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ ICAgICAgIGVudW0gIk1vbmRheSI7DQo+ICAgICAgIGVudW0gIlR1ZXNkYXkiOw0KPiAgICAgICBl bnVtICJXZWRuZXNkYXkiOw0KPiAgICAgICBlbnVtICJUaHVyc2RheSI7DQo+ICAgICAgIGVudW0g IkZyaWRheSI7DQo+ICAgICB9DQo+ICAgfQ0KPiANCj4gICB0eXBlZGVmIHdlZWtlbmQgew0KPiAg ICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ICAgICAgIGVudW0gIlNhdHVyZGF5IjsNCj4gICAgICAg ZW51bSAiU3VuZGF5IjsNCj4gICAgIH0NCj4gICB9DQo+ICAgDQo+ICAgbGVhZiBtdWx0aXBsZS1l bnVtZXJhdGlvbnMtdGVzdC0zIHsNCj4gICAgIHR5cGUgdW5pb24gew0KPiAgICAgICB0eXBlIHdl ZWtkYXlzOw0KPiAgICAgICB0eXBlIHdlZWtlbmQgew0KPiAgICAgICAgIGV4dDp2YWx1ZS1vZmZz ZXQgNTsNCj4gICAgICAgfQ0KPiAgICAgfQ0KPiAgIH0NCj4gDQo+IFRoZSBwb3NpdGlvbi1vZmZz ZXQgZXh0ZW5zaW9uIGNhbiBiZSB1c2VkIGFzIGZvbGxvdzoNCj4gDQo+ICAgdHlwZWRlZiB3ZWVr ZGF5cy1mbGFncyB7DQo+ICAgICB0eXBlIGJpdHMgew0KPiAgICAgICBiaXQgIk1vbmRheSI7DQo+ ICAgICAgIGJpdCAiVHVlc2RheSI7DQo+ICAgICAgIGJpdCAiV2VkbmVzZGF5IjsNCj4gICAgICAg Yml0ICJUaHVyc2RheSI7DQo+ICAgICAgIGJpdCAiRnJpZGF5IjsNCj4gICAgIH0NCj4gICB9DQo+ IA0KPiAgIHR5cGVkZWYgd2Vla2VuZC1mbGFncyB7DQo+ICAgICB0eXBlIGJpdHMgew0KPiAgICAg ICBiaXQgIlNhdHVyZGF5IjsNCj4gICAgICAgYml0ICJTdW5kYXkiOw0KPiAgICAgfQ0KPiAgIH0N Cj4gICANCj4gICBsZWFmIG11bHRpcGxlLWJpdHMtdGVzdC0zIHsNCj4gICAgIHR5cGUgdW5pb24g ew0KPiAgICAgICB0eXBlIHdlZWtkYXlzLWZsYWdzOw0KPiAgICAgICB0eXBlIHdlZWtlbmQtZmxh Z3Mgew0KPiAgICAgICAgIGV4dDpwb3NpdGlvbi1vZmZzZXQgNTsNCj4gICAgICAgfQ0KPiAgICAg fQ0KPiAgIH0NCj4gDQo+IFRoZSB5YW5nIGZpbGUgaW4gYXR0YWNobWVudCBzaG93IGRpZmZlcmVu dCBleGFtcGxlcyBiYXNlZCBvbiB0aGlzIGFwcHJvYWNoLg0KPiBUaGlzIG1vZHVsZSBoYXZlIGJl ZW4gdmFsaWRhdGVkIHVzaW5nIA0KPiBodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnd3dy55DQo+IGFuZ3ZhbGlkYXRvci5jb20l MkZ2YWxpZGF0b3ImYW1wO2RhdGE9MDIlN0MwMSU3QyU3Q2M2OTQyNmRjYWFmODQ0OGUxZDQNCj4g NzA4ZDZiMjdiYzczNSU3QzRmNmZiZDEzMGRmYjQxNTA4NWMzZDQzMjYwYzA0MzA5JTdDMCU3QzAl N0M2MzY4OTI2NDIwNw0KPiAzMjU3NjYwJmFtcDtzZGF0YT1YcW80MGx6QmpJTlZGWmhJWlpJMUxF a3RBZHE1bWVlMkFkeGVZcWVmbnNBJTNEJmFtcDtyDQo+IGVzZXJ2ZWQ9MCBJZiB0aGlzIGFwcHJv YWNoIGlzIGFjY2VwdGVkLCB0b29scyBsaWtlIHB5YW5nIHNob3VsZCBiZSANCj4gdXBkYXRlZCB0 byBwcm9kdWNlIGFuIGVycm9yIGlmIG11bHRpcGxlIGVudW1lcmF0aW9ucyBvciBiaXRzIGFyZSBk ZWZpbmVkIHdpdGggdmFsdWUgb3IgcG9zaXRpb24gb3ZlcmxlYXBzLg0KPiANCj4gUGxlYXNlIGNv bW1lbnQsDQo+IE1pY2hlbA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6Pg0KPiBTZW50OiBNb25kYXksIE1hcmNo IDI1LCAyMDE5IDQ6MDcgQU0NCj4gVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53 YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPjsNCj4gQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6 aS5vcmc+DQo+IENjOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFu dC5jb20+OyANCj4gbmV0Y29uZkBpZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW25ldGNvbmZdIFlBTkcgZW5jb2RpbmcgaW4gQ0JPUg0KPiANCj4gSnVlcmdlbiBTY2hvZW53 YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyaXRlczoNCj4g DQo+ID4gSSB0aGluayB3ZSBuZWVkIHRvIGxvb2sgYXQgdGhlIHdob2xlIHBpY3R1cmUgYW5kIGlu IHdoaWNoIGRpcmVjdGlvbiANCj4gPiB3ZSB3YW50IHRvIGdvLiBJbiB0aGUgbG9uZ2VyIHRlcm0s IEkgd291bGQgcHJlZmVyIGEgc29sdXRpb24gd2hlcmUgDQo+ID4gdGhlIHZhbHVlcyBvZiBhIHVu aW9uIGFyZSBkaXNjcmltaW5hdGVkLiBUaGUgY3VycmVudCBYTUwgZW5jb2RpbmcgDQo+ID4gYmVo YXZpb3VyIG9mICdmaXJzdCBtYXRjaCB3aW5zJyBpcyBmcmFnaWxlIChmb3IgZXhhbXBsZSwgaWYg c29tZW9uZSANCj4gPiBhZGRzIGFuIGVudW0gdG8gYSB0eXBlLCB0aGUgaW50ZXJwcmV0YXRpb24g b2YgZGF0YSBjYW4gY2hhbmdlKS4NCj4gPg0KPiA+IExvb2sgYXQgdGhpczoNCj4gPg0KPiA+IHR5 cGVkZWYgYmFyIHsNCj4gPiAgIHR5cGUgdW5pb24gew0KPiA+ICAgICB0eXBlIGVudW1lcmF0aW9u IHsgZW51bSAiMSI7IHZhbHVlIDI7IGVudW0gIjIiOyB2YWx1ZSAxOyB9DQo+ID4gICAgIHR5cGUg dWludDg7DQo+ID4gICB9DQo+ID4gfQ0KPiA+DQo+ID4gV2UgaGF2ZSBzb21lIGVuY29kaW5ncyB0 aGF0IHNlbmQgdGhlIHN0cmluZyByZXByZXNlbnRhdGlvbnMgb2YgdGhlIA0KPiA+IHZhbHVlcyBh bmQgc29tZSBlbmNvZGluZ3MgdGhhdCBwcmVmZXIgdG8gc2VuZCBudW1lcmljIA0KPiA+IHJlcHJl c2VudGF0aW9ucyB3aGVyZSBwb3NzaWJsZS4gSW4gb3JkZXIgdG8gaGF2ZSBhIHJvYnVzdCBzb2x1 dGlvbiwgDQo+ID4gZW5jb2RpbmdzIHNob3VsZCBsaWtlbHkgaW5kaWNhdGUgdG8gd2hpY2ggdHlw ZSB0aGUgdmFsdWUgYmVsb25ncy4NCj4gDQo+IFBlcmhhcHMgdGhlIGVhc2llc3Qgd2F5IHdvdWxk IGJlIHRvIHVzZSAob3B0aW9uYWwpIGFubm90YXRpb24gdGhhdCBzcGVjaWZpZXMsIHVzaW5nIGFu IG9yZGluYWwgbnVtYmVyLCB3aGljaCBvZiB0aGUgbWVtYmVyIHR5cGVzIGlzIHVzZWQgZm9yIHRo ZSBwYXJ0aWN1bGFyIGluc3RhbmNlLiBCdXQgc2luY2UgdGhlcmUgY2FuIGJlIHVuaW9ucyBpbnNp ZGUgdW5pb25zLCBhIGxpc3Qgb2YgbnVtYmVycyB3b3VsZCBiZSBuZWVkZWQgaW4gZ2VuZXJhbC4N Cj4gDQo+IExhZGENCj4gDQo+ID4NCj4gPiAvanMNCj4gPg0KPiA+IE9uIFNhdCwgTWFyIDIzLCAy MDE5IGF0IDEwOjAzOjMyQU0gKzAxMDAsIENhcnN0ZW4gQm9ybWFubiB3cm90ZToNCj4gPj4gV2Vs bCwgaWYgdGhhdCBpcyBhIHByb2JsZW0sIHdlIGNhbiBnbyBmb3IgYSBsb25nZXIgcmVwcmVzZW50 YXRpb24gd2l0aGluIHVuaW9ucyAoc2VjdGlvbiA2LjEyKS4gIFRoZW9yZXRpY2FsbHksIHdlIGNv dWxkIGRvIHRoYXQgb25seSBvZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGVudW0gaW4gdGhlIHVu aW9uIHR5cGUgKHNvIHRoaW5ncyBzdGF5IGVmZmljaWVudCBpZiB0aGVyZSBpcyBvbmx5IG9uZSks IGJ1dCB0aGF0IG1pZ2h0IHBvc2UgZGlmZmljdWx0aWVzIHdpdGggbW9kZWwgZXZvbHV0aW9uLg0K PiA+PiANCj4gPj4gR29pbmcgZm9yIGEgc3RyaW5nIHJlcHJlc2VudGF0aW9uIHJlcGVhdHMgdGhl IGZlYXR1cmUgb2YgWE1MIFlBTkcgKHdoaWNoIHdhcyBwb3J0ZWQgb3ZlciB0byBKU09OIFlBTkcp Og0KPiA+PiANCj4gPj4gdHlwZWRlZiBmb28gew0KPiA+PiAgIHR5cGUgdW5pb24gew0KPiA+PiAg ICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ID4+ICAgICAgIGVudW0gcmVkIHsgdmFsdWUgMTsgfQ0K PiA+PiAgICAgICBlbnVtIGJyZWVuIHsgdmFsdWUgMjsgfQ0KPiA+PiAgICAgICBlbnVtIGdsdWUg eyB2YWx1ZSAzOyB9DQo+ID4+ICAgICB9DQo+ID4+ICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4g Pj4gICAgICAgZW51bSB0YWNrcyB7IHZhbHVlIDE7IH0NCj4gPj4gICAgICAgZW51bSBuYWlscyB7 IHZhbHVlIDI7IH0NCj4gPj4gICAgICAgZW51bSBnbHVlIHsgdmFsdWUgMzsgfQ0KPiA+PiAgICAg fQ0KPiA+PiAgIH0NCj4gPj4gfQ0KPiA+PiANCj4gPj4gSWYgeW91IHVzZSDigJxnbHVl4oCdLCB5 b3UgZG9u4oCZdCBrbm93IHdoaWNoIG9mIHRoZSBlbnVtZXJhdGlvbnMgYXJlIGJlaW5nIHVzZWQu DQo+ID4+IA0KPiA+PiBVc2luZyBTSURzLCB3ZSBjYW4gZG8gYmV0dGVyLg0KPiA+PiANCj4gPj4g U28gd2hhdCBkbyB3ZSBoYXZlIHRvIGRvIHRvIGdldCB0aGUgU0lEIHRvb2wgdG8gYWxsb2NhdGUg U0lEcyBmb3IgZW51bSB2YWx1ZXM/DQo+ID4+IA0KPiA+PiBXZSBjb3VsZCB0aGVuIGRlZmluZSB0 aGUgQ0JPUiB0YWcgZm9yIGVudW1zIGluIHVuaW9ucyB0byB0YWtlIHRoZSB1c3VhbCBTSUQgZGlm ZmVyZW5jZSAoZGVsdGEgcmVsYXRpdmUgdG8gdGhlIGVudmlyb25tZW50LCBJ4oCZZCB0aGluayks IG5vdCBhbiBpbnRlZ2VyIHZhbHVlLg0KPiA+PiANCj4gPj4gU2V2ZXJhbCBvZiB1cyBhcmUgYXQg dGhlIGhhY2thdGhvbiBhbmQgY291bGQgbWFrZSBzb21ldGhpbmcgaGFwcGVuIHRvZGF5IGFuZCB0 b21vcnJvdy4NCj4gPj4gDQo+ID4+IEdyw7zDn2UsIENhcnN0ZW4NCj4gPj4gDQo+ID4+IA0KPiA+ PiA+IE9uIE1hciAyMiwgMjAxOSwgYXQgMTg6MzAsIFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2ls dG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+ID4gDQo+ID4+ID4gSSBndWVzcyB0aGF0IHRoZSBj b25jZXJuIGlzIHRoYXQgdGhpcyBpbnRyb2R1Y2VzIG1vcmUgdmFyaWF0aW9uIGluIGhvdyBkYXRh IGlzIGludGVycHJldGVkIGJldHdlZW4gdGhlIGRpZmZlcmVudCBYTUwvSlNPTi9DQk9SIGVuY29k aW5ncy4NCj4gPj4gPiANCj4gPj4gPiBFLmcuIGlmIHNvbWVvbmUgc3dpdGNoZWQgZnJvbSBYTUwg dG8gQ0JPUiwgc3VkZGVubHkgdGhlIGNvbmZpZ3VyYXRpb24gb3Igc3RhdGUgZGF0YSBtYXkgaGF2 ZSBhIGRpZmZlcmVudCBtZWFuaW5nLg0KPiA+PiA+IA0KPiA+PiA+IFRoYW5rcywNCj4gPj4gPiBS b2INCj4gPj4gPiANCj4gPj4gPiANCj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4gPj4gRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQo+ID4+ID4+IFNl bnQ6IDIyIE1hcmNoIDIwMTkgMTY6MDgNCj4gPj4gPj4gVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1p Y2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50LmNvbT4NCj4gPj4gPj4gQ2M6IFJvYiBXaWx0b24gKHJ3 aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47IGNvcmVAaWV0Zi5vcmc7IA0KPiA+PiA+PiBuZXRj b25mQGlldGYub3JnDQo+ID4+ID4+IFN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFORyBlbmNvZGlu ZyBpbiBDQk9SDQo+ID4+ID4+IA0KPiA+PiA+PiBPbiBNYXIgMjIsIDIwMTksIGF0IDE2OjQ1LCBN aWNoZWwgVmVpbGxldHRlIA0KPiA+PiA+PiA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29t Pg0KPiA+PiA+PiB3cm90ZToNCj4gPj4gPj4+IA0KPiA+PiA+Pj4gVGhlIG9ubHkgcG90ZW50aWFs IHByb2JsZW0gSSBhd2FyZSBpcyB3aGVuIG11bHRpcGxlIA0KPiA+PiA+Pj4gZW51bWVyYXRpb25z IGFyZSBwYXJ0IG9mDQo+ID4+ID4+IHRoZSBzYW1lIHVuaW9uLg0KPiA+PiA+Pj4gVmFsdWUgNCBm cm9tIGVudW1lcmF0aW9uIEEgd2lsbCBiZSBlbmNvZGVkIHRoZSBzYW1lIHdheSBhcyANCj4gPj4g Pj4+IFZhbHVlDQo+ID4+ID4+PiA0IGZyb20NCj4gPj4gPj4gZW51bWVyYXRpb24gQi4NCj4gPj4g Pj4gDQo+ID4+ID4+IOKApiBhbmQgdGhhdCBpcyBub3QgYSBwcm9ibGVtIGZvciB0aGUgWE1MIHZl cnNpb24sIGJlY2F1c2UgdGhlIA0KPiA+PiA+PiBzdHJpbmcgaXMgYmVpbmcgdXNlZCBpbnN0ZWFk IG9mIHRoZSB2YWx1ZS4gIChCdXQgdGhlbiBpZiB0d28gDQo+ID4+ID4+IGVudW1lcmF0aW9ucyBz aGFyZSBhIHN0cmluZywgeW91IGhhdmUgdGhlIGVxdWl2YWxlbnQgcHJvYmxlbSBpbiANCj4gPj4g Pj4gdGhlIFhNTCBzZXJpYWxpemF0aW9uLikNCj4gPj4gPj4gDQo+ID4+ID4+IEFueXdheSwgSSBo YXZlbuKAmXQgc2VlbiBhIHBpZWNlIG9mIHJlYWwtd29ybGQgWUFORyB0aGF0IGFjdHVhbGx5IA0K PiA+PiA+PiBoYXMgdGhpcyBwcm9ibGVtLCBzbyBJIHdvdWxkIGJlIGEgYml0IHJlbHVjdGFudCB0 byBtYWtlIA0KPiA+PiA+PiBDQk9SLWJhc2VkIGltcGxlbWVudGF0aW9ucyBtb3JlIGNvbXBsZXgg KGFuZCBsZXNzIGVmZmljaWVudCkgc28gc29sdmUgdGhpcyAobm9uLT8pcHJvYmxlbS4NCj4gPj4g Pj4gDQo+ID4+ID4+IEdyw7zDn2UsIENhcnN0ZW4NCj4gPj4gPiANCj4gPj4gPiANCj4gPj4gPiAN Cj4gPj4gDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4+IG5ldGNvbmZAaWV0Zi5vcmcNCj4g Pj4gaHR0cHM6Ly9jYW4wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGdw0KPiA+PiB3dw0KPiA+PiAuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZuZXRjb25mJmFtcDtkYXRhPTAyJTdDMDElN0MlN0MzNDNlDQo+ID4+IGE4DQo+ID4+IGQx Y2Y4ZjRlMzlhZmM3MDhkNmIwZjhkODc0JTdDNGY2ZmJkMTMwZGZiNDE1MDg1YzNkNDMyNjBjMDQz MDklN0MwJTcNCj4gPj4gQzENCj4gPj4gJTdDNjM2ODkwOTgwMTgyNTUzNDAwJmFtcDtzZGF0YT11 MUtGQVlBdXMxNkI4YTdzZ3NCZlBmSXF1T3B0TWxhT2IlMg0KPiA+PiBCMA0KPiA+PiBrdlBaZ3I0 byUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiA+DQo+ID4gLS0gDQo+ID4gSnVlcmdlbiBTY2hvZW53YWVs ZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPiBQaG9uZTog KzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBH ZXJtYW55DQo+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly9jYW4w MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3 LmphY29icy11bml2ZXJzaXR5LmRlJTJGJmFtcDtkYXRhPTAyJTdDMDElN0MlN0NjNjk0MjZkY2Fh Zjg0NDhlMWQ0NzA4ZDZiMjdiYzczNSU3QzRmNmZiZDEzMGRmYjQxNTA4NWMzZDQzMjYwYzA0MzA5 JTdDMCU3QzAlN0M2MzY4OTI2NDIwNzMyNTc2NjAmYW1wO3NkYXRhPVJxU1l1TnBsUzRrT0xVMFIz ZXRSenJSJTJGVTJjY3dsamtFWmtqSEhEVTFIQSUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCj4gPg0KPiA+ DQo+ID4gT24gU2F0LCBNYXIgMjMsIDIwMTkgYXQgMTA6MDM6MzJBTSArMDEwMCwgQ2Fyc3RlbiBC b3JtYW5uIHdyb3RlOg0KPiA+PiBXZWxsLCBpZiB0aGF0IGlzIGEgcHJvYmxlbSwgd2UgY2FuIGdv IGZvciBhIGxvbmdlciByZXByZXNlbnRhdGlvbiB3aXRoaW4gdW5pb25zIChzZWN0aW9uIDYuMTIp LiAgVGhlb3JldGljYWxseSwgd2UgY291bGQgZG8gdGhhdCBvbmx5IG9mIHRoZXJlIGlzIG1vcmUg dGhhbiBvbmUgZW51bSBpbiB0aGUgdW5pb24gdHlwZSAoc28gdGhpbmdzIHN0YXkgZWZmaWNpZW50 IGlmIHRoZXJlIGlzIG9ubHkgb25lKSwgYnV0IHRoYXQgbWlnaHQgcG9zZSBkaWZmaWN1bHRpZXMg d2l0aCBtb2RlbCBldm9sdXRpb24uDQo+ID4+IA0KPiA+PiBHb2luZyBmb3IgYSBzdHJpbmcgcmVw cmVzZW50YXRpb24gcmVwZWF0cyB0aGUgZmVhdHVyZSBvZiBYTUwgWUFORyAod2hpY2ggd2FzIHBv cnRlZCBvdmVyIHRvIEpTT04gWUFORyk6DQo+ID4+IA0KPiA+PiB0eXBlZGVmIGZvbyB7DQo+ID4+ ICAgdHlwZSB1bmlvbiB7DQo+ID4+ICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4gPj4gICAgICAg ZW51bSByZWQgeyB2YWx1ZSAxOyB9DQo+ID4+ICAgICAgIGVudW0gYnJlZW4geyB2YWx1ZSAyOyB9 DQo+ID4+ICAgICAgIGVudW0gZ2x1ZSB7IHZhbHVlIDM7IH0NCj4gPj4gICAgIH0NCj4gPj4gICAg IHR5cGUgZW51bWVyYXRpb24gew0KPiA+PiAgICAgICBlbnVtIHRhY2tzIHsgdmFsdWUgMTsgfQ0K PiA+PiAgICAgICBlbnVtIG5haWxzIHsgdmFsdWUgMjsgfQ0KPiA+PiAgICAgICBlbnVtIGdsdWUg eyB2YWx1ZSAzOyB9DQo+ID4+ICAgICB9DQo+ID4+ICAgfQ0KPiA+PiB9DQo+ID4+IA0KPiA+PiBJ ZiB5b3UgdXNlIOKAnGdsdWXigJ0sIHlvdSBkb27igJl0IGtub3cgd2hpY2ggb2YgdGhlIGVudW1l cmF0aW9ucyBhcmUgYmVpbmcgdXNlZC4NCj4gPj4gDQo+ID4+IFVzaW5nIFNJRHMsIHdlIGNhbiBk byBiZXR0ZXIuDQo+ID4+IA0KPiA+PiBTbyB3aGF0IGRvIHdlIGhhdmUgdG8gZG8gdG8gZ2V0IHRo ZSBTSUQgdG9vbCB0byBhbGxvY2F0ZSBTSURzIGZvciBlbnVtIHZhbHVlcz8NCj4gPj4gDQo+ID4+ IFdlIGNvdWxkIHRoZW4gZGVmaW5lIHRoZSBDQk9SIHRhZyBmb3IgZW51bXMgaW4gdW5pb25zIHRv IHRha2UgdGhlIHVzdWFsIFNJRCBkaWZmZXJlbmNlIChkZWx0YSByZWxhdGl2ZSB0byB0aGUgZW52 aXJvbm1lbnQsIEnigJlkIHRoaW5rKSwgbm90IGFuIGludGVnZXIgdmFsdWUuDQo+ID4+IA0KPiA+ PiBTZXZlcmFsIG9mIHVzIGFyZSBhdCB0aGUgaGFja2F0aG9uIGFuZCBjb3VsZCBtYWtlIHNvbWV0 aGluZyBoYXBwZW4gdG9kYXkgYW5kIHRvbW9ycm93Lg0KPiA+PiANCj4gPj4gR3LDvMOfZSwgQ2Fy c3Rlbg0KPiA+PiANCj4gPj4gDQo+ID4+ID4gT24gTWFyIDIyLCAyMDE5LCBhdCAxODozMCwgUm9i IFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4gPj4gPiANCj4g Pj4gPiBJIGd1ZXNzIHRoYXQgdGhlIGNvbmNlcm4gaXMgdGhhdCB0aGlzIGludHJvZHVjZXMgbW9y ZSB2YXJpYXRpb24gaW4gaG93IGRhdGEgaXMgaW50ZXJwcmV0ZWQgYmV0d2VlbiB0aGUgZGlmZmVy ZW50IFhNTC9KU09OL0NCT1IgZW5jb2RpbmdzLg0KPiA+PiA+IA0KPiA+PiA+IEUuZy4gaWYgc29t ZW9uZSBzd2l0Y2hlZCBmcm9tIFhNTCB0byBDQk9SLCBzdWRkZW5seSB0aGUgY29uZmlndXJhdGlv biBvciBzdGF0ZSBkYXRhIG1heSBoYXZlIGEgZGlmZmVyZW50IG1lYW5pbmcuDQo+ID4+ID4gDQo+ ID4+ID4gVGhhbmtzLA0KPiA+PiA+IFJvYg0KPiA+PiA+IA0KPiA+PiA+IA0KPiA+PiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+PiBGcm9tOiBDYXJzdGVuIEJvcm1hbm4gPGNh Ym9AdHppLm9yZz4NCj4gPj4gPj4gU2VudDogMjIgTWFyY2ggMjAxOSAxNjowOA0KPiA+PiA+PiBU bzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPg0KPiA+ PiA+PiBDYzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPjsgY29yZUBp ZXRmLm9yZzsgDQo+ID4+ID4+IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPj4gPj4gU3ViamVjdDogUmU6 IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGluIENCT1INCj4gPj4gPj4gDQo+ID4+ID4+IE9uIE1h ciAyMiwgMjAxOSwgYXQgMTY6NDUsIE1pY2hlbCBWZWlsbGV0dGUgDQo+ID4+ID4+IDxNaWNoZWwu VmVpbGxldHRlQHRyaWxsaWFudC5jb20+DQo+ID4+ID4+IHdyb3RlOg0KPiA+PiA+Pj4gDQo+ID4+ ID4+PiBUaGUgb25seSBwb3RlbnRpYWwgcHJvYmxlbSBJIGF3YXJlIGlzIHdoZW4gbXVsdGlwbGUg DQo+ID4+ID4+PiBlbnVtZXJhdGlvbnMgYXJlIHBhcnQgb2YNCj4gPj4gPj4gdGhlIHNhbWUgdW5p b24uDQo+ID4+ID4+PiBWYWx1ZSA0IGZyb20gZW51bWVyYXRpb24gQSB3aWxsIGJlIGVuY29kZWQg dGhlIHNhbWUgd2F5IGFzIA0KPiA+PiA+Pj4gVmFsdWUNCj4gPj4gPj4+IDQgZnJvbQ0KPiA+PiA+ PiBlbnVtZXJhdGlvbiBCLg0KPiA+PiA+PiANCj4gPj4gPj4g4oCmIGFuZCB0aGF0IGlzIG5vdCBh IHByb2JsZW0gZm9yIHRoZSBYTUwgdmVyc2lvbiwgYmVjYXVzZSB0aGUgDQo+ID4+ID4+IHN0cmlu ZyBpcyBiZWluZyB1c2VkIGluc3RlYWQgb2YgdGhlIHZhbHVlLiAgKEJ1dCB0aGVuIGlmIHR3byAN Cj4gPj4gPj4gZW51bWVyYXRpb25zIHNoYXJlIGEgc3RyaW5nLCB5b3UgaGF2ZSB0aGUgZXF1aXZh bGVudCBwcm9ibGVtIGluIA0KPiA+PiA+PiB0aGUgWE1MIHNlcmlhbGl6YXRpb24uKQ0KPiA+PiA+ PiANCj4gPj4gPj4gQW55d2F5LCBJIGhhdmVu4oCZdCBzZWVuIGEgcGllY2Ugb2YgcmVhbC13b3Js ZCBZQU5HIHRoYXQgYWN0dWFsbHkgDQo+ID4+ID4+IGhhcyB0aGlzIHByb2JsZW0sIHNvIEkgd291 bGQgYmUgYSBiaXQgcmVsdWN0YW50IHRvIG1ha2UgDQo+ID4+ID4+IENCT1ItYmFzZWQgaW1wbGVt ZW50YXRpb25zIG1vcmUgY29tcGxleCAoYW5kIGxlc3MgZWZmaWNpZW50KSBzbyBzb2x2ZSB0aGlz IChub24tPylwcm9ibGVtLg0KPiA+PiA+PiANCj4gPj4gPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiA+ PiA+IA0KPiA+PiA+IA0KPiA+PiA+IA0KPiA+PiANCj4gPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4g Pj4gbmV0Y29uZkBpZXRmLm9yZw0KPiA+PiBodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3DQo+ID4+IHd3DQo+ID4+IC5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm5ldGNvbmYmYW1wO2RhdGE9MDIlN0MwMSU3QyU3 QzM0M2UNCj4gPj4gYTgNCj4gPj4gZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQlN0M0ZjZmYmQx MzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3QzAlNw0KPiA+PiBDMQ0KPiA+PiAlN0M2MzY4OTA5 ODAxODI1NTM0MDAmYW1wO3NkYXRhPXUxS0ZBWUF1czE2QjhhN3Nnc0JmUGZJcXVPcHRNbGFPYiUy DQo+ID4+IEIwDQo+ID4+IGt2UFpncjRvJTNEJmFtcDtyZXNlcnZlZD0wDQo+ID4NCj4gPiAtLSAN Cj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJy ZW1lbiBnR21iSA0KPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJp bmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEw MyAgICAgICAgIDxodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUlMkYmYW1wO2RhdGE9 MDIlN0MwMSU3QyU3Q2M2OTQyNmRjYWFmODQ0OGUxZDQ3MDhkNmIyN2JjNzM1JTdDNGY2ZmJkMTMw ZGZiNDE1MDg1YzNkNDMyNjBjMDQzMDklN0MwJTdDMCU3QzYzNjg5MjY0MjA3MzI1NzY2MCZhbXA7 c2RhdGE9UnFTWXVOcGxTNGtPTFUwUjNldFJ6clIlMkZVMmNjd2xqa0Vaa2pISERVMUhBJTNEJmFt cDtyZXNlcnZlZD0wPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IG5ldGNvbmZAaWV0 Zi5vcmcNCj4gPiBodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuDQo+ID4gaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZuZXRjb25mJmFtcDtkYXRhPTAyJTdDMDElN0MlN0MzNDNlYTgNCj4gPiBkMQ0KPiA+IGNm OGY0ZTM5YWZjNzA4ZDZiMGY4ZDg3NCU3QzRmNmZiZDEzMGRmYjQxNTA4NWMzZDQzMjYwYzA0MzA5 JTdDMCU3QzElDQo+ID4gN0MNCj4gPiA2MzY4OTA5ODAxODI1NTM0MDAmYW1wO3NkYXRhPXUxS0ZB WUF1czE2QjhhN3Nnc0JmUGZJcXVPcHRNbGFPYiUyQjBrdg0KPiA+IFBaDQo+ID4gZ3I0byUzRCZh bXA7cmVzZXJ2ZWQ9MA0KPiANCj4gLS0NCj4gTGFkaXNsYXYgTGhvdGthDQo+IEhlYWQsIENaLk5J QyBMYWJzDQo+IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KDQoNCg0KLS0gDQpKdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkg QnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6 Ly9jYW4wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmphY29icy11bml2ZXJzaXR5LmRlJTJGJmFtcDtkYXRhPTAyJTdDMDElN0MlN0NjNjk0 MjZkY2FhZjg0NDhlMWQ0NzA4ZDZiMjdiYzczNSU3QzRmNmZiZDEzMGRmYjQxNTA4NWMzZDQzMjYw YzA0MzA5JTdDMCU3QzAlN0M2MzY4OTI2NDIwNzMyNjc2NjAmYW1wO3NkYXRhPXpjUXY0aFI4eWtK RmRodnNkMnFuVFBRM0VQZEVaaWpEYzRlVCUyQkRtc3F1MCUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCg== --_002_BL0PR06MB504264D081B40ACBE22CF6C69A580BL0PR06MB5042namp_ Content-Type: application/octet-stream; name="test-union@2019-03-25.yang" Content-Description: test-union@2019-03-25.yang Content-Disposition: attachment; filename="test-union@2019-03-25.yang"; size=4193; creation-date="Wed, 27 Mar 2019 16:01:44 GMT"; modification-date="Wed, 27 Mar 2019 16:01:44 GMT" Content-Transfer-Encoding: base64 bW9kdWxlIHRlc3QtdW5pb24gew0KICBuYW1lc3BhY2UgInVybjppZXRmOnBhcmFtczp4bWw6bnM6 eWFuZzp0ZXN0LXVuaW9uIjsNCiAgcHJlZml4IGV4dDsNCiAgDQogIHJldmlzaW9uIDIwMTktMDMt MjUgew0KICAgICAgZGVzY3JpcHRpb24gIkRyYWZ0LiI7DQogIH0NCg0KICAvLyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAvLyBQcm9wb3NlZCBl eHRlbnNpb25zDQogIA0KICBleHRlbnNpb24gdW5pb24tdGFnIHsNCiAgICBhcmd1bWVudCB0YWcg ew0KICAgICAgeWluLWVsZW1lbnQgdHJ1ZTsNCiAgICB9DQogICAgZGVzY3JpcHRpb24NCiAgICAg ICJJbiBzb21lIGNhc2VzLCB0aGUgaW50ZXJwcmV0YXRpb24gb2YgYSB2YWx1ZSBvZiBhIHVuaW9u IHR5cGUgY2FuIGRpZmZlcg0KICAgICAgd2hlbiBlbmNvZGVkIHVzaW5nIHRoZSBkaWZmZXJlbnQg ZGF0YSBmb3JtYXQuIFRoaXMgZGlmZmVyZW5jZSBjb21lcyBmcm9tDQogICAgICB0aGUgbGV2ZWwg b2YgdHlwZSBpbmZvcm1hdGlvbiBzdXBwb3J0ZWQgYnkgdGhlIGRpZmZlcmVudCBkYXRhIGZvcm1h dHMuDQogICAgICBJbiB0aGUgY2FzZSBvZiBYTUwsIGFsbCBlbGVtZW50cyBhbmQgYXR0cmlidXRl cyBhcmUgZW5jb2RlZCBhcyBzdHJpbmcNCiAgICAgIGFuZCBubyB0eXBlIGluZm9ybWF0aW9uIGFy ZSBpbmNsdWRlZC4gSlNPTiBzdXBwb3J0cyBzdHJpbmcsIG51bWJlciBhbmQNCiAgICAgIGJvb2xl YW4uIEZpbmFsbHksIENCT1Igc3VwcG9ydHMgYWxsIFlBTkcgYmFzaWMgdHlwZXMuDQoNCiAgICAg IFRoaXMgZXh0ZW5zaW9uIGNhbiBiZSB1c2VkIHRvIGFkZCBhIHRhZyB0byBhIHR5cGUgd2l0aGlu IGEgdW5pb24gdG8NCiAgICAgIGd1YXJhbnRlZSBpdHMgcHJvcGVyIGludGVycHJldGF0aW9uIHdo ZW4gZGVjb2RlZC4iOw0KICB9DQoNCiAgLy8gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgLy8gVGhpcyBleGFtcGxlIHNob3dzIGEgY2FzZSBmb3Ig d2hpY2ggYSB0YWcgaXMgbm90IHJlcXVpcmVkDQogIA0KICBsZWFmIG11bHRpcGxlLWVudW1lcmF0 aW9ucy10ZXN0LTEgew0KICAgIHR5cGUgdW5pb24gew0KICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7 DQogICAgICAgIGVudW0gIk1vbmRheSIgeyB2YWx1ZSAwOyB9DQogICAgICAgIGVudW0gIlR1ZXNk YXkiIHsgdmFsdWUgMTsgfQ0KICAgICAgICBlbnVtICJXZWRuZXNkYXkiIHsgdmFsdWUgMjsgfQ0K ICAgICAgICBlbnVtICJUaHVyc2RheSIgeyB2YWx1ZSAzOyB9DQogICAgICAgIGVudW0gIkZyaWRh eSIgeyB2YWx1ZSA0OyB9DQoNCiAgICAgIH0NCiAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAg ICAgICBlbnVtICJTYXR1cmRheSIgeyB2YWx1ZSA1OyB9DQogICAgICAgIGVudW0gIlN1bmRheSIg eyB2YWx1ZSA2OyB9DQogICAgICB9DQogICAgfQ0KICB9DQoNCiAgLy8gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgLy8gVGhlIGZvbGxvd2luZyB0 d28gZXhhbXBsZXMgcmVxdWlyZSB0aGUgdXNlIG9mIGF0IGxlYXN0IG9uZQ0KICAvLyB1bmlvbiB0 YWcgdG8gZ3VhcmFudGVlIHRoZSBwcm9wZXIgaW50ZXJwcmV0YXRpb24gb2YgdGhvc2UgdHdvDQog IC8vIGVudW1lcmF0aW9ucy4gVGhpcyBhYmlsaXR5IHRvIHRhZyBvbmx5IG9uZSBlbnVtZXJhdGlv biBjYW4gYmUNCiAgLy8gdXNlZCB0byBrZWVwIHRoZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdo ZW4gdXBkYXRpbmcgYSBtb2R1bGUNCiAgLy8gd2l0aCBhIHNlY29uZCBlbnVtZXJhdGlvbiwgc2Vl IHNlY29uZCBleGFtcGxlLg0KDQogIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25zLXRlc3QtMiB7 DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgICAgZXh0 OnVuaW9uLXRhZyB3ZWVrZGF5czsNCiAgICAgICAgZW51bSAiTW9uZGF5IjsNCiAgICAgICAgZW51 bSAiVHVlc2RheSI7DQogICAgICAgIGVudW0gIldlZG5lc2RheSI7DQogICAgICAgIGVudW0gIlRo dXJzZGF5IjsNCiAgICAgICAgZW51bSAiRnJpZGF5IjsNCiAgICAgIH0NCiAgICAgIHR5cGUgZW51 bWVyYXRpb24gew0KICAgICAgICBleHQ6dW5pb24tdGFnIHdlZWtlbmQ7DQogICAgICAgIGVudW0g IlNhdHVyZGF5IjsNCiAgICAgICAgZW51bSAiU3VuZGF5IjsNCiAgICAgIH0NCiAgICB9DQogIH0N Cg0KICB0eXBlZGVmIHdlZWtkYXlzIHsNCiAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgIGVu dW0gIk1vbmRheSI7DQogICAgICBlbnVtICJUdWVzZGF5IjsNCiAgICAgIGVudW0gIldlZG5lc2Rh eSI7DQogICAgICBlbnVtICJUaHVyc2RheSI7DQogICAgICBlbnVtICJGcmlkYXkiOw0KICAgIH0N CiAgfQ0KDQogIHR5cGVkZWYgd2Vla2VuZCB7DQogICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAg ICBlbnVtICJTYXR1cmRheSI7DQogICAgICBlbnVtICJTdW5kYXkiOw0KICAgIH0NCiAgfQ0KICAN CiAgbGVhZiBtdWx0aXBsZS1lbnVtZXJhdGlvbnMtdGVzdC0zIHsNCiAgICB0eXBlIHVuaW9uIHsN CiAgICAgIHR5cGUgd2Vla2RheXM7DQogICAgICB0eXBlIHdlZWtlbmQgew0KICAgICAgICBleHQ6 dW5pb24tdGFnIHdlZWtlbmQ7DQogICAgICB9DQogICAgfQ0KICB9DQogIA0KICAvLyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAvLyBUaGlzIGV4 YW1wbGUgc2hvd3MgYSBjYXNlIGZvciB3aGljaCBhIHRhZyBpcyBub3QgcmVxdWlyZWQNCiAgDQog IGxlYWYgbXVsdGlwbGUtYml0cy10ZXN0LTEgew0KICAgIHR5cGUgdW5pb24gew0KICAgICAgdHlw ZSBiaXRzIHsNCiAgICAgICAgYml0ICAiTW9uZGF5IiB7IHBvc2l0aW9uICAwOyB9DQogICAgICAg IGJpdCAiVHVlc2RheSIgeyBwb3NpdGlvbiAgMTsgfQ0KICAgICAgICBiaXQgIldlZG5lc2RheSIg eyBwb3NpdGlvbiAgMjsgfQ0KICAgICAgICBiaXQgIlRodXJzZGF5IiB7IHBvc2l0aW9uICAzOyB9 DQogICAgICAgIGJpdCAiRnJpZGF5IiB7IHBvc2l0aW9uICA0OyB9DQoNCiAgICAgIH0NCiAgICAg IHR5cGUgYml0cyB7DQogICAgICAgIGJpdCAiU2F0dXJkYXkiIHsgcG9zaXRpb24gNTsgfQ0KICAg ICAgICBiaXQgIlN1bmRheSIgeyBwb3NpdGlvbiA2OyB9DQogICAgICB9DQogICAgfQ0KICB9DQoN CiAgLy8gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiAgLy8gVGhlIGZvbGxvd2luZyB0d28gZXhhbXBsZXMgcmVxdWlyZSB0aGUgdXNlIG9mIGF0IGxl YXN0IG9uZQ0KICAvLyB1bmlvbiB0YWcgdG8gZ3VhcmFudGVlIHRoZSBwcm9wZXIgaW50ZXJwcmV0 YXRpb24gb2YgdGhvc2UgdHdvDQogIC8vIGVudW1lcmF0aW9ucy4NCiAgDQogIGxlYWYgbXVsdGlw bGUtYml0cy10ZXN0LTIgew0KICAgIHR5cGUgdW5pb24gew0KICAgICAgdHlwZSBiaXRzIHsNCiAg ICAgICAgZXh0OnVuaW9uLXRhZyB3ZWVrZGF5czsNCiAgICAgICAgYml0ICJNb25kYXkiOw0KICAg ICAgICBiaXQgIlR1ZXNkYXkiOw0KICAgICAgICBiaXQgIldlZG5lc2RheSI7DQogICAgICAgIGJp dCAiVGh1cnNkYXkiOw0KICAgICAgICBiaXQgIkZyaWRheSI7DQogICAgICB9DQogICAgICB0eXBl IGJpdHMgew0KICAgICAgICBleHQ6dW5pb24tdGFnIHdlZWtlbmQ7DQogICAgICAgIGJpdCAiU2F0 dXJkYXkiOw0KICAgICAgICBiaXQgIlN1bmRheSI7DQogICAgICB9DQogICAgfQ0KICB9DQoNCiAg dHlwZWRlZiB3ZWVrZGF5cy1mbGFncyB7DQogICAgdHlwZSBiaXRzIHsNCiAgICAgIGJpdCAiTW9u ZGF5IjsNCiAgICAgIGJpdCAiVHVlc2RheSI7DQogICAgICBiaXQgIldlZG5lc2RheSI7DQogICAg ICBiaXQgIlRodXJzZGF5IjsNCiAgICAgIGJpdCAiRnJpZGF5IjsNCiAgICB9DQogIH0NCg0KICB0 eXBlZGVmIHdlZWtlbmQtZmxhZ3Mgew0KICAgIHR5cGUgYml0cyB7DQogICAgICBiaXQgIlNhdHVy ZGF5IjsNCiAgICAgIGJpdCAiU3VuZGF5IjsNCiAgICB9DQogIH0NCiAgDQogIGxlYWYgbXVsdGlw bGUtYml0cy10ZXN0LTMgew0KICAgIHR5cGUgdW5pb24gew0KICAgICAgdHlwZSB3ZWVrZGF5cy1m bGFnczsNCiAgICAgIHR5cGUgd2Vla2VuZC1mbGFncyB7DQogICAgICAgIGV4dDp1bmlvbi10YWcg d2Vla2VuZDsNCiAgICAgIH0NCiAgICB9DQogIH0NCn0= --_002_BL0PR06MB504264D081B40ACBE22CF6C69A580BL0PR06MB5042namp_-- From nobody Wed Mar 27 09:14:04 2019 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 1ECA3120283 for ; Wed, 27 Mar 2019 09:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClrFik2K8_VJ for ; Wed, 27 Mar 2019 09:13:58 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 72F3212027E for ; Wed, 27 Mar 2019 09:13:57 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id d18so11791969lfn.3 for ; Wed, 27 Mar 2019 09:13:57 -0700 (PDT) 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=jIqIzCDcz6AlsqV2oeQkiEJGGG4zS039EE0DiRtEghU=; b=wLXypH3VNRGMsX3uN0FIlhFz6IFBlRSlLRv9vwZM4f8y3bwrqTKmeC2rMuirwPfVoo rDo/Gz82mwbLqvZ7PR/eLOMFD7O+jBkb6NWeta2IsbsIXRDF5U72OxgSDdYJy8rGWcqp /TBy/uL1YM9oJvpx/7mB3+oqrXCd+MvEETk8U+8Qp1uwoaJy5CWYPRQI6zOkPXRVH8e3 /pD0ipOfzkI4NOWB26dQSyq1StnnlEbeFEvzMzZr/mhpGdvYUuCXmfdxCWMg6DaoBGnc rtgMcjoBmVyQQoPr5cYU4GYLtHrLqZT6EHJi1caJr1rqM8Di4rh18fap3dWnGSMu8wdp 97yw== 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=jIqIzCDcz6AlsqV2oeQkiEJGGG4zS039EE0DiRtEghU=; b=K+W0ntFftdKYXvuveseGNcG3GeSNPvS9OO3bZzJcj5YLA9q/lFgf28yc7MHLAYWQ56 ConGNIemNlyHAFoFxArVaj2K0MzpaFC6edmWoY59ndNTDyRIAqW+GR5pwzAYd8BgZ8Z6 T7wTdCjpMQxdKocWSYceA+6fCqdXVI7/R5pEv05fjiQytT4pnY1JGyFYu8U1OonuC3Pb WUKjElijDlRFyFvvuBMv8KTUj2kbUC+leuoxNVk7TTZj2cId0y00X0oXI2Wpjiobt79O QwyixCrtrAU16h+i8gzWWpuK77Vt7VEYGNZMsCqUX1SKqna8EJy7aiu+SCly2+cygVv1 5d8w== X-Gm-Message-State: APjAAAWdiV/cMDiCb+L/gIZvJxHm0AEw6vgYwKucFFIqAUzDY4l1qRU4 beUVNLAbhKP3/y6OKVB2ESHguL++DEo8hnK2K/Hu8w== X-Google-Smtp-Source: APXvYqxErEw/GrBdRyTJOQJV2Unom9aXZu3m3a8VHw+MtId+QR4MU8G+gieGMD+7Srb4SqSgVTWmFWe6EDob65XInng= X-Received: by 2002:ac2:52a6:: with SMTP id r6mr20160975lfm.27.1553703235362; Wed, 27 Mar 2019 09:13:55 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> In-Reply-To: <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> From: Andy Bierman Date: Wed, 27 Mar 2019 09:13:44 -0700 Message-ID: To: Ladislav Lhotka Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006e38e2058515b90a" Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 27 Mar 2019 16:14:02 -0000 --0000000000006e38e2058515b90a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka wrote: > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > Hi, > > > > a union can be formed by using member types that are imported and not > > under change control of a single author/organization and ideally this > > should work without complex coordination of name and number spaces. > > Duplicate enum/bits values are legal in YANG today so an encoding has > > to deal with this aspect of life. > > > > A robust fix to all these problems will be to tag the type members in > > order to discriminate the values in the encodings. This, however, will > > take some time to specify and we will need to preserve backwards > > compatibility with unions without a tag (but compilers can encourage > > people to add tags whenever modules are updated). > > I already opened a new issue for this in yang-next: > > https://github.com/netmod-wg/yang-next/issues/72 > > We already explored the solution of giving the member types numbers so they could be used in CBOR but this was rejected because it is so complex to implement. Consider when union is within union, and the types are named types from other modules. Union types can be legally updated in new versions of the module, but the position assignments for SID can never change. Even without this complexity this solution would cause the encoder/decoder to be very schema-aware. BTW, creating SIDs for enums and bits will break if the server uses 'deviate replace type'. There is no way to number the deviated type since this is server-specific not part of the original module and the deviation is not actually a data-def-stmt. Lada > > Andy > > > > /js > > > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > > > Hi Ladislav > > > > > > If I summarize this issue of multiple enumerations or bits in a union= , > this > > > problem can be solve by the following approaches: > > > > > > - To not allows these duplicate values or positions to happen in YANG > > > - To encode enumerations and bits as string (in all unions or only wh= en > > > multiple enumerations or bits are defined) > > > - To encode enumerations and bits as SID (in all unions or only when > > > multiple enumerations or bits are defined) > > > - To encode enumerations and bits as delta between the value SID and > the > > > leaf SID (in all unions or only when multiple enumerations or bits ar= e > > > defined) > > > > > > In this email, I will like to focus on the first option, fixing the > problem > > > directly in YANG instead of fixing the consequences. > > > > > > Without any changes in YANG, a union with multiple enumeration or bit= s > can > > > be constructed without value or position overlaps. > > > For example: > > > > > > leaf multiple-enumerations-test-1 { > > > type union { > > > type enumeration { > > > enum "Monday" { value 0; } > > > enum "Tuesday" { value 1; } > > > enum "Wednesday" { value 2; } > > > enum "Thursday" { value 3; } > > > enum "Friday" { value 4; } > > > > > > } > > > type enumeration { > > > enum "Saturday" { value 5; } > > > enum "Sunday" { value 6; } > > > } > > > } > > > } > > > > > > leaf multiple-bits-test-1 { > > > type union { > > > type bits { > > > bit "Monday" { position 0; } > > > bit "Tuesday" { position 1; } > > > bit "Wednesday" { position 2; } > > > bit "Thursday" { position 3; } > > > bit "Friday" { position 4; } > > > > > > } > > > type bits { > > > bit "Saturday" { position 5; } > > > bit "Sunday" { position 6; } > > > } > > > } > > > } > > > > > > When using already defined typedef, avoiding overlap is less obvious > without > > > some help. > > > To help building unions with already defined typedefs, I propose to > > > introduce two extensions. > > > > > > extension value-offset { > > > argument offset { > > > yin-element true; > > > } > > > description > > > "Offset added to each enum value of the associated enumeration.= "; > > > } > > > > > > extension position-offset { > > > argument offset { > > > yin-element true; > > > } > > > description > > > "Offset value added to each bit position of the associated > bits."; > > > } > > > > > > The value-offset extension can be used as follow: > > > > > > type enumeration { > > > enum "Monday"; > > > enum "Tuesday"; > > > enum "Wednesday"; > > > enum "Thursday"; > > > enum "Friday"; > > > } > > > } > > > > > > typedef weekend { > > > type enumeration { > > > enum "Saturday"; > > > enum "Sunday"; > > > } > > > } > > > > > > leaf multiple-enumerations-test-3 { > > > type union { > > > type weekdays; > > > type weekend { > > > ext:value-offset 5; > > > } > > > } > > > } > > > > > > The position-offset extension can be used as follow: > > > > > > typedef weekdays-flags { > > > type bits { > > > bit "Monday"; > > > bit "Tuesday"; > > > bit "Wednesday"; > > > bit "Thursday"; > > > bit "Friday"; > > > } > > > } > > > > > > typedef weekend-flags { > > > type bits { > > > bit "Saturday"; > > > bit "Sunday"; > > > } > > > } > > > > > > leaf multiple-bits-test-3 { > > > type union { > > > type weekdays-flags; > > > type weekend-flags { > > > ext:position-offset 5; > > > } > > > } > > > } > > > > > > The yang file in attachment show different examples based on this > approach. > > > This module have been validated using > http://www.yangvalidator.com/validator > > > > > > If this approach is accepted, tools like pyang should be updated to > produce > > > an error if multiple enumerations or bits are defined with value or > position > > > overleaps. > > > > > > Please comment, > > > Michel > > > > > > -----Original Message----- > > > From: Ladislav Lhotka > > > Sent: Monday, March 25, 2019 4:07 AM > > > To: Juergen Schoenwaelder ; > Carsten > > > Bormann > > > Cc: Michel Veillette ; > netconf@ietf.org; > > > core@ietf.org > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > Juergen Schoenwaelder writes: > > > > > > > I think we need to look at the whole picture and in which direction > we > > > > want to go. In the longer term, I would prefer a solution where the > > > > values of a union are discriminated. The current XML encoding > > > > behaviour of 'first match wins' is fragile (for example, if someone > > > > adds an enum to a type, the interpretation of data can change). > > > > > > > > Look at this: > > > > > > > > typedef bar { > > > > type union { > > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > > > type uint8; > > > > } > > > > } > > > > > > > > We have some encodings that send the string representations of the > > > > values and some encodings that prefer to send numeric > representations > > > > where possible. In order to have a robust solution, encodings shoul= d > > > > likely indicate to which type the value belongs. > > > > > > Perhaps the easiest way would be to use (optional) annotation that > > > specifies, using an ordinal number, which of the member types is used > for > > > the particular instance. But since there can be unions inside unions, > a list > > > of numbers would be needed in general. > > > > > > Lada > > > > > > > /js > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > > Well, if that is a problem, we can go for a longer representation > within > > > > > unions (section 6.12). Theoretically, we could do that only of > there is > > > > > more than one enum in the union type (so things stay efficient if > there > > > > > is only one), but that might pose difficulties with model > evolution. > > > > > > > > > > Going for a string representation repeats the feature of XML YANG > (which > > > > > was ported over to JSON YANG): > > > > > > > > > > typedef foo { > > > > > type union { > > > > > type enumeration { > > > > > enum red { value 1; } > > > > > enum breen { value 2; } > > > > > enum glue { value 3; } > > > > > } > > > > > type enumeration { > > > > > enum tacks { value 1; } > > > > > enum nails { value 2; } > > > > > enum glue { value 3; } > > > > > } > > > > > } > > > > > } > > > > > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which o= f the enumerations are > being > > > > > used. > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for > enum > > > > > values? > > > > > > > > > > We could then define the CBOR tag for enums in unions to take the > usual > > > > > SID difference (delta relative to the environment, I=E2=80=99d th= ink), not > an > > > > > integer value. > > > > > > > > > > Several of us are at the hackathon and could make something happe= n > today > > > > > and tomorrow. > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < > rwilton@cisco.com> > > > > > > wrote: > > > > > > > > > > > > I guess that the concern is that this introduces more variation > in how > > > > > > data is interpreted between the different XML/JSON/CBOR > encodings. > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > configuration > > > > > > or state data may have a different meaning. > > > > > > > > > > > > Thanks, > > > > > > Rob > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Carsten Bormann > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > To: Michel Veillette > > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > > netconf@ietf.org > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > wrote: > > > > > > > > The only potential problem I aware is when multiple > enumerations > > > > > > > > are part of > > > > > > > the same union. > > > > > > > > Value 4 from enumeration A will be encoded the same way as > Value > > > > > > > > 4 from > > > > > > > enumeration B. > > > > > > > > > > > > > > =E2=80=A6 and that is not a problem for the XML version, beca= use the > > > > > > > string is being used instead of the value. (But then if two > > > > > > > enumerations share a string, you have the equivalent problem > in > > > > > > > the XML serialization.) > > > > > > > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YANG tha= t > actually > > > > > > > has this problem, so I would be a bit reluctant to make > CBOR-based > > > > > > > implementations more complex (and less efficient) so solve th= is > > > > > > > (non-?)problem. > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netconf mailing list > > > > > netconf@ietf.org > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww > > > > > .ietf.org > %2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8 > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > > kvPZgr4o%3D&reserved=3D0 > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > Fax: +49 421 200 3103 < > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.j= acobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sd= ata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 > > > > > > > > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > > Well, if that is a problem, we can go for a longer representation > within > > > > > unions (section 6.12). Theoretically, we could do that only of > there is > > > > > more than one enum in the union type (so things stay efficient if > there > > > > > is only one), but that might pose difficulties with model > evolution. > > > > > > > > > > Going for a string representation repeats the feature of XML YANG > (which > > > > > was ported over to JSON YANG): > > > > > > > > > > typedef foo { > > > > > type union { > > > > > type enumeration { > > > > > enum red { value 1; } > > > > > enum breen { value 2; } > > > > > enum glue { value 3; } > > > > > } > > > > > type enumeration { > > > > > enum tacks { value 1; } > > > > > enum nails { value 2; } > > > > > enum glue { value 3; } > > > > > } > > > > > } > > > > > } > > > > > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which o= f the enumerations are > being > > > > > used. > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for > enum > > > > > values? > > > > > > > > > > We could then define the CBOR tag for enums in unions to take the > usual > > > > > SID difference (delta relative to the environment, I=E2=80=99d th= ink), not > an > > > > > integer value. > > > > > > > > > > Several of us are at the hackathon and could make something happe= n > today > > > > > and tomorrow. > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < > rwilton@cisco.com> > > > > > > wrote: > > > > > > > > > > > > I guess that the concern is that this introduces more variation > in how > > > > > > data is interpreted between the different XML/JSON/CBOR > encodings. > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > configuration > > > > > > or state data may have a different meaning. > > > > > > > > > > > > Thanks, > > > > > > Rob > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Carsten Bormann > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > To: Michel Veillette > > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > > netconf@ietf.org > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > wrote: > > > > > > > > The only potential problem I aware is when multiple > enumerations > > > > > > > > are part of > > > > > > > the same union. > > > > > > > > Value 4 from enumeration A will be encoded the same way as > Value > > > > > > > > 4 from > > > > > > > enumeration B. > > > > > > > > > > > > > > =E2=80=A6 and that is not a problem for the XML version, beca= use the > > > > > > > string is being used instead of the value. (But then if two > > > > > > > enumerations share a string, you have the equivalent problem > in > > > > > > > the XML serialization.) > > > > > > > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YANG tha= t > actually > > > > > > > has this problem, so I would be a bit reluctant to make > CBOR-based > > > > > > > implementations more complex (and less efficient) so solve th= is > > > > > > > (non-?)problem. > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netconf mailing list > > > > > netconf@ietf.org > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww > > > > > .ietf.org > %2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8 > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > > kvPZgr4o%3D&reserved=3D0 > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > Fax: +49 421 200 3103 < > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.j= acobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sd= ata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 > > > > > > > > > > > > > _______________________________________________ > > > > netconf mailing list > > > > netconf@ietf.org > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > > > ietf.org > %2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8d1 > > > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C > > > > > 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kvPZ > > > > gr4o%3D&reserved=3D0 > > > > > > -- > > > Ladislav Lhotka > > > Head, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000006e38e2058515b90a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 27, 2019 at 1:40 AM Ladis= lav Lhotka <lhotka@nic.cz> wrote= :
On Wed, 2019-0= 3-27 at 07:16 +0100, Juergen Schoenwaelder wrote:
> Hi,
>
> a union can be formed by using member types that are imported and not<= br> > under change control of a single author/organization and ideally this<= br> > should work without complex coordination of name and number spaces. > Duplicate enum/bits values are legal in YANG today so an encoding has<= br> > to deal with this aspect of life.
>
> A robust fix to all these problems will be to tag the type members in<= br> > order to discriminate the values in the encodings. This, however, will=
> take some time to specify and we will need to preserve backwards
> compatibility with unions without a tag (but compilers can encourage > people to add tags whenever modules are updated).

I already opened a new issue for this in yang-next:

https://github.com/netmod-wg/yang-next/issues/72=


We already explored the solution of gi= ving the member types numbers
so they could be used in CBOR but t= his was rejected because it is so complex to implement.

Consider when union is within union, and the types are named types fr= om
other modules. Union types can be legally updated in new versi= ons of the module,
but the position assignments for SID can never= change.

Even without this complexity this solutio= n would cause the encoder/decoder to
be very schema-aware.=C2=A0<= /div>

BTW, creating SIDs for enums and bits will break i= f the server uses 'deviate replace type'.
There is no way= to number the deviated type since this is server-specific not part of the = original module
and the deviation is not actually a data-def-stmt= .


Lada


Andy
=C2=A0
>
> /js
>
> On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote:
> > Hi Ladislav
> >
> > If I summarize this issue of multiple enumerations or bits in a u= nion, this
> > problem can be solve by the following approaches:
> >
> > - To not allows these duplicate values or positions to happen in = YANG
> > - To encode enumerations and bits as string (in all unions or onl= y when
> > multiple enumerations or bits are defined)
> > - To encode enumerations and bits as SID (in all unions or only w= hen
> > multiple enumerations or bits are defined)
> > - To encode enumerations and bits as delta between the value SID = and the
> > leaf SID (in all unions or only when multiple enumerations or bit= s are
> > defined)
> >
> > In this email, I will like to focus on the first option, fixing t= he problem
> > directly in YANG instead of fixing the consequences.
> >
> > Without any changes in YANG, a union with multiple enumeration or= bits can
> > be constructed without value or position overlaps.
> > For example:
> >
> >=C2=A0 =C2=A0leaf multiple-enumerations-test-1 {
> >=C2=A0 =C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Monday" { value = 0; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Tuesday" { value= 1; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Wednesday" { val= ue 2; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Thursday" { valu= e 3; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Friday" { value = 4; }
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Saturday" { valu= e 5; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Sunday" { value = 6; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0leaf multiple-bits-test-1 {
> >=C2=A0 =C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type bits {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit=C2=A0 "Monday" { p= osition=C2=A0 0; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Tuesday" { positi= on=C2=A0 1; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Wednesday" { posi= tion=C2=A0 2; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Thursday" { posit= ion=C2=A0 3; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Friday" { positio= n=C2=A0 4; }
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type bits {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Saturday" { posit= ion 5; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Sunday" { positio= n 6; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> > When using already defined typedef, avoiding overlap is less obvi= ous without
> > some help.
> > To help building unions with already defined typedefs, I propose = to
> > introduce two extensions.
> >
> >=C2=A0 =C2=A0extension value-offset {
> >=C2=A0 =C2=A0 =C2=A0argument offset {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0yin-element true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Offset added to each enum value o= f the associated enumeration.";
> >=C2=A0 =C2=A0}
> >=C2=A0 =C2=A0
> >=C2=A0 =C2=A0extension position-offset {
> >=C2=A0 =C2=A0 =C2=A0argument offset {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0yin-element true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Offset value added to each bit po= sition of the associated bits.";
> >=C2=A0 =C2=A0}
> >
> > The value-offset extension can be used as follow:
> >
> >=C2=A0 =C2=A0 =C2=A0type enumeration {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Monday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Tuesday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Wednesday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Thursday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Friday";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef weekend {
> >=C2=A0 =C2=A0 =C2=A0type enumeration {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Saturday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Sunday";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >=C2=A0 =C2=A0
> >=C2=A0 =C2=A0leaf multiple-enumerations-test-3 {
> >=C2=A0 =C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekdays;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekend {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ext:value-offset 5;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> > The position-offset extension can be used as follow:
> >
> >=C2=A0 =C2=A0typedef weekdays-flags {
> >=C2=A0 =C2=A0 =C2=A0type bits {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Monday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Tuesday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Wednesday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Thursday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Friday";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef weekend-flags {
> >=C2=A0 =C2=A0 =C2=A0type bits {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Saturday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Sunday";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >=C2=A0 =C2=A0
> >=C2=A0 =C2=A0leaf multiple-bits-test-3 {
> >=C2=A0 =C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekdays-flags;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekend-flags {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ext:position-offset 5;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> > The yang file in attachment show different examples based on this= approach.
> > This module have been validated using http://www.yan= gvalidator.com/validator
> >=C2=A0
> > If this approach is accepted, tools like pyang should be updated = to produce
> > an error if multiple enumerations or bits are defined with value = or position
> > overleaps.
> >
> > Please comment,
> > Michel
> >
> > -----Original Message-----
> > From: Ladislav Lhotka <lhotka@nic.cz>
> > Sent: Monday, March 25, 2019 4:07 AM
> > To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de= >; Carsten
> > Bormann <cab= o@tzi.org>
> > Cc: Michel Veillette <Michel.Veillette@trilliant.com>; netconf@ietf.org;
> > core@ietf.org<= /a>
> > Subject: Re: [netconf] YANG encoding in CBOR
> >
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > writes:
> >
> > > I think we need to look at the whole picture and in which di= rection we
> > > want to go. In the longer term, I would prefer a solution wh= ere the
> > > values of a union are discriminated. The current XML encodin= g
> > > behaviour of 'first match wins' is fragile (for exam= ple, if someone
> > > adds an enum to a type, the interpretation of data can chang= e).
> > >
> > > Look at this:
> > >
> > > typedef bar {
> > >=C2=A0 =C2=A0type union {
> > >=C2=A0 =C2=A0 =C2=A0type enumeration { enum "1"; va= lue 2; enum "2"; value 1; }
> > >=C2=A0 =C2=A0 =C2=A0type uint8;
> > >=C2=A0 =C2=A0}
> > > }
> > >
> > > We have some encodings that send the string representations = of the
> > > values and some encodings that prefer to send numeric repres= entations
> > > where possible. In order to have a robust solution, encoding= s should
> > > likely indicate to which type the value belongs.
> >
> > Perhaps the easiest way would be to use (optional) annotation tha= t
> > specifies, using an ordinal number, which of the member types is = used for
> > the particular instance. But since there can be unions inside uni= ons, a list
> > of numbers would be needed in general.
> >
> > Lada
> >
> > > /js
> > >
> > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wr= ote:
> > > > Well, if that is a problem, we can go for a longer repr= esentation within
> > > > unions (section 6.12).=C2=A0 Theoretically, we could do= that only of there is
> > > > more than one enum in the union type (so things stay ef= ficient if there
> > > > is only one), but that might pose difficulties with mod= el evolution.
> > > >
> > > > Going for a string representation repeats the feature o= f XML YANG (which
> > > > was ported over to JSON YANG):
> > > >
> > > > typedef foo {
> > > >=C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum red { value 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum breen { value 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3; }
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum tacks { value 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum nails { value 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3; }
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > > }
> > > >
> > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t kn= ow which of the enumerations are being
> > > > used.
> > > >
> > > > Using SIDs, we can do better.
> > > >
> > > > So what do we have to do to get the SID tool to allocat= e SIDs for enum
> > > > values?
> > > >
> > > > We could then define the CBOR tag for enums in unions t= o take the usual
> > > > SID difference (delta relative to the environment, I=E2= =80=99d think), not an
> > > > integer value.
> > > >
> > > > Several of us are at the hackathon and could make somet= hing happen today
> > > > and tomorrow.
> > > >
> > > > Gr=C3=BC=C3=9Fe, Carsten
> > > >
> > > >
> > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) &l= t;rwilton@cisco.com<= /a>>
> > > > > wrote:
> > > > >
> > > > > I guess that the concern is that this introduces m= ore variation in how
> > > > > data is interpreted between the different XML/JSON= /CBOR encodings.
> > > > >
> > > > > E.g. if someone switched from XML to CBOR, suddenl= y the configuration
> > > > > or state data may have a different meaning.
> > > > >
> > > > > Thanks,
> > > > > Rob
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Carsten Bormann <cabo@tzi.org>
> > > > > > Sent: 22 March 2019 16:08
> > > > > > To: Michel Veillette <Michel.Veillette@trilliant.= com>
> > > > > > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; core@ietf.org;
> > > > > > netconf@ietf.org
> > > > > > Subject: Re: [netconf] YANG encoding in CBOR<= br> > > > > > >
> > > > > > On Mar 22, 2019, at 16:45, Michel Veillette <= br> > > > > > > <Michel.Veillette@trilliant.com>
> > > > > > wrote:
> > > > > > > The only potential problem I aware is wh= en multiple enumerations
> > > > > > > are part of
> > > > > > the same union.
> > > > > > > Value 4 from enumeration A will be encod= ed the same way as Value
> > > > > > > 4 from
> > > > > > enumeration B.
> > > > > >
> > > > > > =E2=80=A6 and that is not a problem for the X= ML version, because the
> > > > > > string is being used instead of the value.=C2= =A0 (But then if two
> > > > > > enumerations share a string, you have the equ= ivalent problem in
> > > > > > the XML serialization.)
> > > > > >
> > > > > > Anyway, I haven=E2=80=99t seen a piece of rea= l-world YANG that actually
> > > > > > has this problem, so I would be a bit relucta= nt to make CBOR-based
> > > > > > implementations more complex (and less effici= ent) so solve this
> > > > > > (non-?)problem.
> > > > > >
> > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > netconf mailing list
> > > > n= etconf@ietf.org
> > > > https://c= an01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D02%7= C01%7C%7C343ea8
> > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260= c04309%7C0%7C1
> > > > %7C636890980182553400&amp;sdata=3Du1KFAYAus16B8a7sg= sBfPfIquOptMlaOb%2B0
> > > > kvPZgr4o%3D&amp;reserved=3D0
> > >
> > > --
> > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cam= pus Ring 1 | 28759 Bremen | Germany
> > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0<
> > > ht= tps://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.jacob= s-university.de%2F&amp;data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&am= p;sdata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&amp;reserv= ed=3D0
> > > >
> > >
> > >
> > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wr= ote:
> > > > Well, if that is a problem, we can go for a longer repr= esentation within
> > > > unions (section 6.12).=C2=A0 Theoretically, we could do= that only of there is
> > > > more than one enum in the union type (so things stay ef= ficient if there
> > > > is only one), but that might pose difficulties with mod= el evolution.
> > > >
> > > > Going for a string representation repeats the feature o= f XML YANG (which
> > > > was ported over to JSON YANG):
> > > >
> > > > typedef foo {
> > > >=C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum red { value 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum breen { value 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3; }
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum tacks { value 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum nails { value 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3; }
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > > }
> > > >
> > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t kn= ow which of the enumerations are being
> > > > used.
> > > >
> > > > Using SIDs, we can do better.
> > > >
> > > > So what do we have to do to get the SID tool to allocat= e SIDs for enum
> > > > values?
> > > >
> > > > We could then define the CBOR tag for enums in unions t= o take the usual
> > > > SID difference (delta relative to the environment, I=E2= =80=99d think), not an
> > > > integer value.
> > > >
> > > > Several of us are at the hackathon and could make somet= hing happen today
> > > > and tomorrow.
> > > >
> > > > Gr=C3=BC=C3=9Fe, Carsten
> > > >
> > > >
> > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) &l= t;rwilton@cisco.com<= /a>>
> > > > > wrote:
> > > > >
> > > > > I guess that the concern is that this introduces m= ore variation in how
> > > > > data is interpreted between the different XML/JSON= /CBOR encodings.
> > > > >
> > > > > E.g. if someone switched from XML to CBOR, suddenl= y the configuration
> > > > > or state data may have a different meaning.
> > > > >
> > > > > Thanks,
> > > > > Rob
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Carsten Bormann <cabo@tzi.org>
> > > > > > Sent: 22 March 2019 16:08
> > > > > > To: Michel Veillette <Michel.Veillette@trilliant.= com>
> > > > > > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; core@ietf.org;
> > > > > > netconf@ietf.org
> > > > > > Subject: Re: [netconf] YANG encoding in CBOR<= br> > > > > > >
> > > > > > On Mar 22, 2019, at 16:45, Michel Veillette <= br> > > > > > > <Michel.Veillette@trilliant.com>
> > > > > > wrote:
> > > > > > > The only potential problem I aware is wh= en multiple enumerations
> > > > > > > are part of
> > > > > > the same union.
> > > > > > > Value 4 from enumeration A will be encod= ed the same way as Value
> > > > > > > 4 from
> > > > > > enumeration B.
> > > > > >
> > > > > > =E2=80=A6 and that is not a problem for the X= ML version, because the
> > > > > > string is being used instead of the value.=C2= =A0 (But then if two
> > > > > > enumerations share a string, you have the equ= ivalent problem in
> > > > > > the XML serialization.)
> > > > > >
> > > > > > Anyway, I haven=E2=80=99t seen a piece of rea= l-world YANG that actually
> > > > > > has this problem, so I would be a bit relucta= nt to make CBOR-based
> > > > > > implementations more complex (and less effici= ent) so solve this
> > > > > > (non-?)problem.
> > > > > >
> > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > netconf mailing list
> > > > n= etconf@ietf.org
> > > > https://c= an01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D02%7= C01%7C%7C343ea8
> > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260= c04309%7C0%7C1
> > > > %7C636890980182553400&amp;sdata=3Du1KFAYAus16B8a7sg= sBfPfIquOptMlaOb%2B0
> > > > kvPZgr4o%3D&amp;reserved=3D0
> > >
> > > --
> > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cam= pus Ring 1 | 28759 Bremen | Germany
> > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0<
> > > ht= tps://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.jacob= s-university.de%2F&amp;data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&am= p;sdata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&amp;reserv= ed=3D0
> > > >
> > >
> > > _______________________________________________
> > > netconf mailing list
> > > netcon= f@ietf.org
> > > https://can01.= safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D02%7C01%7C%= 7C343ea8d1
> > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%= 7C0%7C1%7C
> > > 636890980182553400&amp;sdata=3Du1KFAYAus16B8a7sgsBfPfIqu= OptMlaOb%2B0kvPZ
> > > gr4o%3D&amp;reserved=3D0
> >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
>
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--0000000000006e38e2058515b90a-- From nobody Wed Mar 27 12:54:23 2019 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 2FE5C120287; Wed, 27 Mar 2019 12:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm55voh0iDFu; Wed, 27 Mar 2019 12:54:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C868E120281; Wed, 27 Mar 2019 12:54:09 -0700 (PDT) Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id A00B260898; Wed, 27 Mar 2019 20:54:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553716447; bh=H4HMDJ54o02EDEIwUM6ZJjBNSI9ooKoSS+AqZl7fsQQ=; h=From:To:Date; b=QorjJM1i7nATsvbEKRWBnPH0hmlPf4m0yfsOZHD/T2xQ5sN3GAP/sjw+s9kFFFL1W g4AFCa5BPLPiL6io/NUh3BUBhk7/4CVFGQWGldyLEeRD2+G5EnZoNOZhTm7Obn4Amy FGa1F/VuSpMhM0yxeeWvzAS3EXN9T1T2RZ5sVhsI= Message-ID: From: Ladislav Lhotka To: Andy Bierman Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Date: Wed, 27 Mar 2019 20:54:07 +0100 In-Reply-To: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 27 Mar 2019 19:54:14 -0000 Andy Bierman píše v St 27. 03. 2019 v 09:13 -0700: > > > On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka wrote: > > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > > Hi, > > > > > > a union can be formed by using member types that are imported and not > > > under change control of a single author/organization and ideally this > > > should work without complex coordination of name and number spaces. > > > Duplicate enum/bits values are legal in YANG today so an encoding has > > > to deal with this aspect of life. > > > > > > A robust fix to all these problems will be to tag the type members in > > > order to discriminate the values in the encodings. This, however, will > > > take some time to specify and we will need to preserve backwards > > > compatibility with unions without a tag (but compilers can encourage > > > people to add tags whenever modules are updated). > > > > I already opened a new issue for this in yang-next: > > > > https://github.com/netmod-wg/yang-next/issues/72 > > > > We already explored the solution of giving the member types numbers > so they could be used in CBOR but this was rejected because it is so complex > to implement. I don't think it is too complex. Get the type in the schema, get the member, that's all. It is much easier and more robust than the current algorithm. > > Consider when union is within union, and the types are named types from Union within union is no problem: it jut requires a sequence of numbers. > other modules. Union types can be legally updated in new versions of the > module, Again, I don't agree. Sec. 11 in RFC 7950 says: o A "type" statement may be replaced with another "type" statement that does not change the syntax or semantics of the type. ... Adding a new member clearly changes the semantics of the type, if not syntax. > but the position assignments for SID can never change. The annotation would also help resolve the differences between JSON and XML. SID is only available in CBOR. > > Even without this complexity this solution would cause the encoder/decoder to > be very schema-aware. The current method of resolving unions is totally schema-aware (somewhat less so in JSON). Lada > > > BTW, creating SIDs for enums and bits will break if the server uses 'deviate > replace type'. > There is no way to number the deviated type since this is server-specific not > part of the original module > and the deviation is not actually a data-def-stmt. > > > > Lada > > > > Andy > > > > > > > /js > > > > > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > > > > Hi Ladislav > > > > > > > > If I summarize this issue of multiple enumerations or bits in a union, > > this > > > > problem can be solve by the following approaches: > > > > > > > > - To not allows these duplicate values or positions to happen in YANG > > > > - To encode enumerations and bits as string (in all unions or only when > > > > multiple enumerations or bits are defined) > > > > - To encode enumerations and bits as SID (in all unions or only when > > > > multiple enumerations or bits are defined) > > > > - To encode enumerations and bits as delta between the value SID and the > > > > leaf SID (in all unions or only when multiple enumerations or bits are > > > > defined) > > > > > > > > In this email, I will like to focus on the first option, fixing the > > problem > > > > directly in YANG instead of fixing the consequences. > > > > > > > > Without any changes in YANG, a union with multiple enumeration or bits > > can > > > > be constructed without value or position overlaps. > > > > For example: > > > > > > > > leaf multiple-enumerations-test-1 { > > > > type union { > > > > type enumeration { > > > > enum "Monday" { value 0; } > > > > enum "Tuesday" { value 1; } > > > > enum "Wednesday" { value 2; } > > > > enum "Thursday" { value 3; } > > > > enum "Friday" { value 4; } > > > > > > > > } > > > > type enumeration { > > > > enum "Saturday" { value 5; } > > > > enum "Sunday" { value 6; } > > > > } > > > > } > > > > } > > > > > > > > leaf multiple-bits-test-1 { > > > > type union { > > > > type bits { > > > > bit "Monday" { position 0; } > > > > bit "Tuesday" { position 1; } > > > > bit "Wednesday" { position 2; } > > > > bit "Thursday" { position 3; } > > > > bit "Friday" { position 4; } > > > > > > > > } > > > > type bits { > > > > bit "Saturday" { position 5; } > > > > bit "Sunday" { position 6; } > > > > } > > > > } > > > > } > > > > > > > > When using already defined typedef, avoiding overlap is less obvious > > without > > > > some help. > > > > To help building unions with already defined typedefs, I propose to > > > > introduce two extensions. > > > > > > > > extension value-offset { > > > > argument offset { > > > > yin-element true; > > > > } > > > > description > > > > "Offset added to each enum value of the associated enumeration."; > > > > } > > > > > > > > extension position-offset { > > > > argument offset { > > > > yin-element true; > > > > } > > > > description > > > > "Offset value added to each bit position of the associated bits."; > > > > } > > > > > > > > The value-offset extension can be used as follow: > > > > > > > > type enumeration { > > > > enum "Monday"; > > > > enum "Tuesday"; > > > > enum "Wednesday"; > > > > enum "Thursday"; > > > > enum "Friday"; > > > > } > > > > } > > > > > > > > typedef weekend { > > > > type enumeration { > > > > enum "Saturday"; > > > > enum "Sunday"; > > > > } > > > > } > > > > > > > > leaf multiple-enumerations-test-3 { > > > > type union { > > > > type weekdays; > > > > type weekend { > > > > ext:value-offset 5; > > > > } > > > > } > > > > } > > > > > > > > The position-offset extension can be used as follow: > > > > > > > > typedef weekdays-flags { > > > > type bits { > > > > bit "Monday"; > > > > bit "Tuesday"; > > > > bit "Wednesday"; > > > > bit "Thursday"; > > > > bit "Friday"; > > > > } > > > > } > > > > > > > > typedef weekend-flags { > > > > type bits { > > > > bit "Saturday"; > > > > bit "Sunday"; > > > > } > > > > } > > > > > > > > leaf multiple-bits-test-3 { > > > > type union { > > > > type weekdays-flags; > > > > type weekend-flags { > > > > ext:position-offset 5; > > > > } > > > > } > > > > } > > > > > > > > The yang file in attachment show different examples based on this > > approach. > > > > This module have been validated using > > http://www.yangvalidator.com/validator > > > > > > > > If this approach is accepted, tools like pyang should be updated to > > produce > > > > an error if multiple enumerations or bits are defined with value or > > position > > > > overleaps. > > > > > > > > Please comment, > > > > Michel > > > > > > > > -----Original Message----- > > > > From: Ladislav Lhotka > > > > Sent: Monday, March 25, 2019 4:07 AM > > > > To: Juergen Schoenwaelder ; > > Carsten > > > > Bormann > > > > Cc: Michel Veillette ; netconf@ietf.org; > > > > > > core@ietf.org > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > Juergen Schoenwaelder writes: > > > > > > > > > I think we need to look at the whole picture and in which direction > > we > > > > > want to go. In the longer term, I would prefer a solution where the > > > > > values of a union are discriminated. The current XML encoding > > > > > behaviour of 'first match wins' is fragile (for example, if someone > > > > > adds an enum to a type, the interpretation of data can change). > > > > > > > > > > Look at this: > > > > > > > > > > typedef bar { > > > > > type union { > > > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > > > > type uint8; > > > > > } > > > > > } > > > > > > > > > > We have some encodings that send the string representations of the > > > > > values and some encodings that prefer to send numeric representations > > > > > where possible. In order to have a robust solution, encodings should > > > > > likely indicate to which type the value belongs. > > > > > > > > Perhaps the easiest way would be to use (optional) annotation that > > > > specifies, using an ordinal number, which of the member types is used > > for > > > > the particular instance. But since there can be unions inside unions, a > > list > > > > of numbers would be needed in general. > > > > > > > > Lada > > > > > > > > > /js > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > > > Well, if that is a problem, we can go for a longer representation > > within > > > > > > unions (section 6.12). Theoretically, we could do that only of > > there is > > > > > > more than one enum in the union type (so things stay efficient if > > there > > > > > > is only one), but that might pose difficulties with model evolution. > > > > > > > > > > > > Going for a string representation repeats the feature of XML YANG > > (which > > > > > > was ported over to JSON YANG): > > > > > > > > > > > > typedef foo { > > > > > > type union { > > > > > > type enumeration { > > > > > > enum red { value 1; } > > > > > > enum breen { value 2; } > > > > > > enum glue { value 3; } > > > > > > } > > > > > > type enumeration { > > > > > > enum tacks { value 1; } > > > > > > enum nails { value 2; } > > > > > > enum glue { value 3; } > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > If you use “glue”, you don’t know which of the enumerations are > > being > > > > > > used. > > > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for > > enum > > > > > > values? > > > > > > > > > > > > We could then define the CBOR tag for enums in unions to take the > > usual > > > > > > SID difference (delta relative to the environment, I’d think), not > > an > > > > > > integer value. > > > > > > > > > > > > Several of us are at the hackathon and could make something happen > > today > > > > > > and tomorrow. > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) > > > > > > > > > wrote: > > > > > > > > > > > > > > I guess that the concern is that this introduces more variation in > > how > > > > > > > data is interpreted between the different XML/JSON/CBOR encodings. > > > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > > configuration > > > > > > > or state data may have a different meaning. > > > > > > > > > > > > > > Thanks, > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Carsten Bormann > > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > > To: Michel Veillette > > > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > > > netconf@ietf.org > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > > > wrote: > > > > > > > > > The only potential problem I aware is when multiple > > enumerations > > > > > > > > > are part of > > > > > > > > the same union. > > > > > > > > > Value 4 from enumeration A will be encoded the same way as > > Value > > > > > > > > > 4 from > > > > > > > > enumeration B. > > > > > > > > > > > > > > > > … and that is not a problem for the XML version, because the > > > > > > > > string is being used instead of the value. (But then if two > > > > > > > > enumerations share a string, you have the equivalent problem in > > > > > > > > the XML serialization.) > > > > > > > > > > > > > > > > Anyway, I haven’t seen a piece of real-world YANG that actually > > > > > > > > has this problem, so I would be a bit reluctant to make CBOR- > > based > > > > > > > > implementations more complex (and less efficient) so solve this > > > > > > > > (non-?)problem. > > > > > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > netconf mailing list > > > > > > netconf@ietf.org > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > > > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8 > > > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > > > %7C636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > > > kvPZgr4o%3D&reserved=0 > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > Fax: +49 421 200 3103 < > > > > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&data=02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sdata=TrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > > > Well, if that is a problem, we can go for a longer representation > > within > > > > > > unions (section 6.12). Theoretically, we could do that only of > > there is > > > > > > more than one enum in the union type (so things stay efficient if > > there > > > > > > is only one), but that might pose difficulties with model evolution. > > > > > > > > > > > > Going for a string representation repeats the feature of XML YANG > > (which > > > > > > was ported over to JSON YANG): > > > > > > > > > > > > typedef foo { > > > > > > type union { > > > > > > type enumeration { > > > > > > enum red { value 1; } > > > > > > enum breen { value 2; } > > > > > > enum glue { value 3; } > > > > > > } > > > > > > type enumeration { > > > > > > enum tacks { value 1; } > > > > > > enum nails { value 2; } > > > > > > enum glue { value 3; } > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > If you use “glue”, you don’t know which of the enumerations are > > being > > > > > > used. > > > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for > > enum > > > > > > values? > > > > > > > > > > > > We could then define the CBOR tag for enums in unions to take the > > usual > > > > > > SID difference (delta relative to the environment, I’d think), not > > an > > > > > > integer value. > > > > > > > > > > > > Several of us are at the hackathon and could make something happen > > today > > > > > > and tomorrow. > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) > > > > > > > > > wrote: > > > > > > > > > > > > > > I guess that the concern is that this introduces more variation in > > how > > > > > > > data is interpreted between the different XML/JSON/CBOR encodings. > > > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > > configuration > > > > > > > or state data may have a different meaning. > > > > > > > > > > > > > > Thanks, > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Carsten Bormann > > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > > To: Michel Veillette > > > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > > > netconf@ietf.org > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > > > wrote: > > > > > > > > > The only potential problem I aware is when multiple > > enumerations > > > > > > > > > are part of > > > > > > > > the same union. > > > > > > > > > Value 4 from enumeration A will be encoded the same way as > > Value > > > > > > > > > 4 from > > > > > > > > enumeration B. > > > > > > > > > > > > > > > > … and that is not a problem for the XML version, because the > > > > > > > > string is being used instead of the value. (But then if two > > > > > > > > enumerations share a string, you have the equivalent problem in > > > > > > > > the XML serialization.) > > > > > > > > > > > > > > > > Anyway, I haven’t seen a piece of real-world YANG that actually > > > > > > > > has this problem, so I would be a bit reluctant to make CBOR- > > based > > > > > > > > implementations more complex (and less efficient) so solve this > > > > > > > > (non-?)problem. > > > > > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > netconf mailing list > > > > > > netconf@ietf.org > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > > > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8 > > > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > > > %7C636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > > > kvPZgr4o%3D&reserved=0 > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > Fax: +49 421 200 3103 < > > > > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&data=02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sdata=TrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=0 > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netconf mailing list > > > > > netconf@ietf.org > > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8d1 > > > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C > > > > > 636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kvPZ > > > > > gr4o%3D&reserved=0 > > > > > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 27 13:11:58 2019 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 07FF0120421 for ; Wed, 27 Mar 2019 13:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ-jcPDOmgRM for ; Wed, 27 Mar 2019 13:11:47 -0700 (PDT) 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 9DE7E12033D for ; Wed, 27 Mar 2019 13:11:46 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id k23so6256642lji.13 for ; Wed, 27 Mar 2019 13:11:46 -0700 (PDT) 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=90TeAK73HHjK9UBzuuhwpkeMXOKnEbcWq+6rGTaEsbQ=; b=QgweE4TrTuQUMPDcqQyVe+3a77my0gT+C9OQsQGwGA7WRHOc72RAd9+oEZAMUkXseO 6misLk3o3CBtvBc03PPneK4DA34WsAulKcZYZEEKgOovr+W9hob2VMU4gyM/oIuc6B65 mbyK64mDK2p4DV++lakKIWdW2RYOO9Z/FTNi9XTPwIbDhsC0AKdJP0P2fEfvbiznqORb dqALb/Q+qsq+4mYT1P1LHY4GCQ37H8YPperJAgSOdMO3OpiPEsFq5KFkPnUaQw+SYIvk 8kHsBJiJeFbCe88XCDwiNrFqZPcNzo6Wesx5nv8K5sbQFfFWvG461dPABFjN2Ir8btS8 ZgTw== 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=90TeAK73HHjK9UBzuuhwpkeMXOKnEbcWq+6rGTaEsbQ=; b=uBT7a9dX/9LjFTFg7T0R1Y1a7LOPRyquHiODKSA/P81r+5Qq6mHGlhlvHyekOMu7s8 bIUyutLyEcKVsqPk2WB838Hakp4YIScZiMroa9RB2bP8esbC4nWjjmRJf3pgb40DpPry A5Tmka6nOM2O3dU8bchtkclRIL5oJYwVmZX+6Bl+M/fyGeWYzz7pU159tevfmI7zljj+ ZOVhkJM9PXib9jmmuRu4QbU8NxDD9M+t4klUCVoTSGasYBfae5HrEmtRJNA7kKIx23cw 15UuHPow0bol17sql6SZKnI3X4jujeJ8sAF3x15pCYWZ/W+rPdrpg9bxxGdQTkZ8/ReK naLw== X-Gm-Message-State: APjAAAXZRjWspse2UdRo8KOnPQbqDadipZJqA7joYKsZLQgB3alYcViV RAePEi7b9Pg7whNsjHLLqPaa09KP1XZNJ8yCHBk8o+6Z X-Google-Smtp-Source: APXvYqw5ulRlB4x7JVZxYDqkw8S0X3B+fZhXRQYDFzXfu8hzVne+gBKUiW4CozzCyvfBuS/DcMH3SDkhL453hhvLbto= X-Received: by 2002:a2e:844a:: with SMTP id u10mr9295158ljh.41.1553717504655; Wed, 27 Mar 2019 13:11:44 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> In-Reply-To: From: Andy Bierman Date: Wed, 27 Mar 2019 13:11:33 -0700 Message-ID: To: Ladislav Lhotka Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f2603d0585190b7c" Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 27 Mar 2019 20:11:57 -0000 --000000000000f2603d0585190b7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 27, 2019 at 12:54 PM Ladislav Lhotka wrote: > Andy Bierman p=C3=AD=C5=A1e v St 27. 03. 2019 v 09:13 -0700: > > > > > > On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka wrote: > > > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > > > Hi, > > > > > > > > a union can be formed by using member types that are imported and n= ot > > > > under change control of a single author/organization and ideally th= is > > > > should work without complex coordination of name and number spaces. > > > > Duplicate enum/bits values are legal in YANG today so an encoding h= as > > > > to deal with this aspect of life. > > > > > > > > A robust fix to all these problems will be to tag the type members = in > > > > order to discriminate the values in the encodings. This, however, > will > > > > take some time to specify and we will need to preserve backwards > > > > compatibility with unions without a tag (but compilers can encourag= e > > > > people to add tags whenever modules are updated). > > > > > > I already opened a new issue for this in yang-next: > > > > > > https://github.com/netmod-wg/yang-next/issues/72 > > > > > > > We already explored the solution of giving the member types numbers > > so they could be used in CBOR but this was rejected because it is so > complex > > to implement. > > I don't think it is too complex. Get the type in the schema, get the > member, > that's all. It is much easier and more robust than the current algorithm. > > no it isn't easier because the algorithm is error-prone. Renumbering un-named types nested within unions and referenced named types over many revisions of the module is not easy. The encoding MUST NOT change EVER -- even if the union type is expanded. > > > > Consider when union is within union, and the types are named types from > > Union within union is no problem: it jut requires a sequence of numbers. > > do not agree since the union can have a member type added > > other modules. Union types can be legally updated in new versions of th= e > > module, > > Again, I don't agree. Sec. 11 in RFC 7950 says: > > o A "type" statement may be replaced with another "type" statement > that does not change the syntax or semantics of the type. > ... > > type uint32 { range "1..8"; } I can refactor that into 2 types (1..4 and 5..8) This does not change the semantics of the union type but it adds a member type Other refactoring is possible that will also change the number of member types. Also, deviations do not follow this rule > Adding a new member clearly changes the semantics of the type, if not > syntax. > > no it doesn't always change the semantics > > but the position assignments for SID can never change. > > The annotation would also help resolve the differences between JSON and > XML. SID > is only available in CBOR. > > > > > Even without this complexity this solution would cause the > encoder/decoder to > > be very schema-aware. > > The current method of resolving unions is totally schema-aware (somewhat > less so > in JSON). > > No -- it just needs to know string vs. number. Not schema aware at all. > Lada > > Andy > > > > > > BTW, creating SIDs for enums and bits will break if the server uses > 'deviate > > replace type'. > > There is no way to number the deviated type since this is > server-specific not > > part of the original module > > and the deviation is not actually a data-def-stmt. > > > > > > > Lada > > > > > > > Andy > > > > > > > > > > /js > > > > > > > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > > > > > Hi Ladislav > > > > > > > > > > If I summarize this issue of multiple enumerations or bits in a > union, > > > this > > > > > problem can be solve by the following approaches: > > > > > > > > > > - To not allows these duplicate values or positions to happen in > YANG > > > > > - To encode enumerations and bits as string (in all unions or onl= y > when > > > > > multiple enumerations or bits are defined) > > > > > - To encode enumerations and bits as SID (in all unions or only > when > > > > > multiple enumerations or bits are defined) > > > > > - To encode enumerations and bits as delta between the value SID > and the > > > > > leaf SID (in all unions or only when multiple enumerations or bit= s > are > > > > > defined) > > > > > > > > > > In this email, I will like to focus on the first option, fixing t= he > > > problem > > > > > directly in YANG instead of fixing the consequences. > > > > > > > > > > Without any changes in YANG, a union with multiple enumeration or > bits > > > can > > > > > be constructed without value or position overlaps. > > > > > For example: > > > > > > > > > > leaf multiple-enumerations-test-1 { > > > > > type union { > > > > > type enumeration { > > > > > enum "Monday" { value 0; } > > > > > enum "Tuesday" { value 1; } > > > > > enum "Wednesday" { value 2; } > > > > > enum "Thursday" { value 3; } > > > > > enum "Friday" { value 4; } > > > > > > > > > > } > > > > > type enumeration { > > > > > enum "Saturday" { value 5; } > > > > > enum "Sunday" { value 6; } > > > > > } > > > > > } > > > > > } > > > > > > > > > > leaf multiple-bits-test-1 { > > > > > type union { > > > > > type bits { > > > > > bit "Monday" { position 0; } > > > > > bit "Tuesday" { position 1; } > > > > > bit "Wednesday" { position 2; } > > > > > bit "Thursday" { position 3; } > > > > > bit "Friday" { position 4; } > > > > > > > > > > } > > > > > type bits { > > > > > bit "Saturday" { position 5; } > > > > > bit "Sunday" { position 6; } > > > > > } > > > > > } > > > > > } > > > > > > > > > > When using already defined typedef, avoiding overlap is less > obvious > > > without > > > > > some help. > > > > > To help building unions with already defined typedefs, I propose = to > > > > > introduce two extensions. > > > > > > > > > > extension value-offset { > > > > > argument offset { > > > > > yin-element true; > > > > > } > > > > > description > > > > > "Offset added to each enum value of the associated > enumeration."; > > > > > } > > > > > > > > > > extension position-offset { > > > > > argument offset { > > > > > yin-element true; > > > > > } > > > > > description > > > > > "Offset value added to each bit position of the associated > bits."; > > > > > } > > > > > > > > > > The value-offset extension can be used as follow: > > > > > > > > > > type enumeration { > > > > > enum "Monday"; > > > > > enum "Tuesday"; > > > > > enum "Wednesday"; > > > > > enum "Thursday"; > > > > > enum "Friday"; > > > > > } > > > > > } > > > > > > > > > > typedef weekend { > > > > > type enumeration { > > > > > enum "Saturday"; > > > > > enum "Sunday"; > > > > > } > > > > > } > > > > > > > > > > leaf multiple-enumerations-test-3 { > > > > > type union { > > > > > type weekdays; > > > > > type weekend { > > > > > ext:value-offset 5; > > > > > } > > > > > } > > > > > } > > > > > > > > > > The position-offset extension can be used as follow: > > > > > > > > > > typedef weekdays-flags { > > > > > type bits { > > > > > bit "Monday"; > > > > > bit "Tuesday"; > > > > > bit "Wednesday"; > > > > > bit "Thursday"; > > > > > bit "Friday"; > > > > > } > > > > > } > > > > > > > > > > typedef weekend-flags { > > > > > type bits { > > > > > bit "Saturday"; > > > > > bit "Sunday"; > > > > > } > > > > > } > > > > > > > > > > leaf multiple-bits-test-3 { > > > > > type union { > > > > > type weekdays-flags; > > > > > type weekend-flags { > > > > > ext:position-offset 5; > > > > > } > > > > > } > > > > > } > > > > > > > > > > The yang file in attachment show different examples based on this > > > approach. > > > > > This module have been validated using > > > http://www.yangvalidator.com/validator > > > > > > > > > > If this approach is accepted, tools like pyang should be updated = to > > > produce > > > > > an error if multiple enumerations or bits are defined with value = or > > > position > > > > > overleaps. > > > > > > > > > > Please comment, > > > > > Michel > > > > > > > > > > -----Original Message----- > > > > > From: Ladislav Lhotka > > > > > Sent: Monday, March 25, 2019 4:07 AM > > > > > To: Juergen Schoenwaelder ; > > > Carsten > > > > > Bormann > > > > > Cc: Michel Veillette ; > netconf@ietf.org; > > > > > > > > core@ietf.org > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > Juergen Schoenwaelder > writes: > > > > > > > > > > > I think we need to look at the whole picture and in which > direction > > > we > > > > > > want to go. In the longer term, I would prefer a solution where > the > > > > > > values of a union are discriminated. The current XML encoding > > > > > > behaviour of 'first match wins' is fragile (for example, if > someone > > > > > > adds an enum to a type, the interpretation of data can change). > > > > > > > > > > > > Look at this: > > > > > > > > > > > > typedef bar { > > > > > > type union { > > > > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > > > > > type uint8; > > > > > > } > > > > > > } > > > > > > > > > > > > We have some encodings that send the string representations of > the > > > > > > values and some encodings that prefer to send numeric > representations > > > > > > where possible. In order to have a robust solution, encodings > should > > > > > > likely indicate to which type the value belongs. > > > > > > > > > > Perhaps the easiest way would be to use (optional) annotation tha= t > > > > > specifies, using an ordinal number, which of the member types is > used > > > for > > > > > the particular instance. But since there can be unions inside > unions, a > > > list > > > > > of numbers would be needed in general. > > > > > > > > > > Lada > > > > > > > > > > > /js > > > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote= : > > > > > > > Well, if that is a problem, we can go for a longer > representation > > > within > > > > > > > unions (section 6.12). Theoretically, we could do that only = of > > > there is > > > > > > > more than one enum in the union type (so things stay efficien= t > if > > > there > > > > > > > is only one), but that might pose difficulties with model > evolution. > > > > > > > > > > > > > > Going for a string representation repeats the feature of XML > YANG > > > (which > > > > > > > was ported over to JSON YANG): > > > > > > > > > > > > > > typedef foo { > > > > > > > type union { > > > > > > > type enumeration { > > > > > > > enum red { value 1; } > > > > > > > enum breen { value 2; } > > > > > > > enum glue { value 3; } > > > > > > > } > > > > > > > type enumeration { > > > > > > > enum tacks { value 1; } > > > > > > > enum nails { value 2; } > > > > > > > enum glue { value 3; } > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know whi= ch of the enumerations are > > > being > > > > > > > used. > > > > > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs > for > > > enum > > > > > > > values? > > > > > > > > > > > > > > We could then define the CBOR tag for enums in unions to take > the > > > usual > > > > > > > SID difference (delta relative to the environment, I=E2=80=99= d think), > not > > > an > > > > > > > integer value. > > > > > > > > > > > > > > Several of us are at the hackathon and could make something > happen > > > today > > > > > > > and tomorrow. > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < > rwilton@cisco.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > I guess that the concern is that this introduces more > variation in > > > how > > > > > > > > data is interpreted between the different XML/JSON/CBOR > encodings. > > > > > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > > > configuration > > > > > > > > or state data may have a different meaning. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Carsten Bormann > > > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > > > To: Michel Veillette > > > > > > > > > Cc: Rob Wilton (rwilton) ; > core@ietf.org; > > > > > > > > > netconf@ietf.org > > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > The only potential problem I aware is when multiple > > > enumerations > > > > > > > > > > are part of > > > > > > > > > the same union. > > > > > > > > > > Value 4 from enumeration A will be encoded the same way > as > > > Value > > > > > > > > > > 4 from > > > > > > > > > enumeration B. > > > > > > > > > > > > > > > > > > =E2=80=A6 and that is not a problem for the XML version, = because > the > > > > > > > > > string is being used instead of the value. (But then if > two > > > > > > > > > enumerations share a string, you have the equivalent > problem in > > > > > > > > > the XML serialization.) > > > > > > > > > > > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YANG= that > actually > > > > > > > > > has this problem, so I would be a bit reluctant to make > CBOR- > > > based > > > > > > > > > implementations more complex (and less efficient) so solv= e > this > > > > > > > > > (non-?)problem. > > > > > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > netconf mailing list > > > > > > > netconf@ietf.org > > > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww > > > > > > > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343e= a8 > > > > > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > > > > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2= B0 > > > > > > > kvPZgr4o%3D&reserved=3D0 > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > > > Fax: +49 421 200 3103 < > > > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.j= acobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sd= ata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote= : > > > > > > > Well, if that is a problem, we can go for a longer > representation > > > within > > > > > > > unions (section 6.12). Theoretically, we could do that only = of > > > there is > > > > > > > more than one enum in the union type (so things stay efficien= t > if > > > there > > > > > > > is only one), but that might pose difficulties with model > evolution. > > > > > > > > > > > > > > Going for a string representation repeats the feature of XML > YANG > > > (which > > > > > > > was ported over to JSON YANG): > > > > > > > > > > > > > > typedef foo { > > > > > > > type union { > > > > > > > type enumeration { > > > > > > > enum red { value 1; } > > > > > > > enum breen { value 2; } > > > > > > > enum glue { value 3; } > > > > > > > } > > > > > > > type enumeration { > > > > > > > enum tacks { value 1; } > > > > > > > enum nails { value 2; } > > > > > > > enum glue { value 3; } > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know whi= ch of the enumerations are > > > being > > > > > > > used. > > > > > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs > for > > > enum > > > > > > > values? > > > > > > > > > > > > > > We could then define the CBOR tag for enums in unions to take > the > > > usual > > > > > > > SID difference (delta relative to the environment, I=E2=80=99= d think), > not > > > an > > > > > > > integer value. > > > > > > > > > > > > > > Several of us are at the hackathon and could make something > happen > > > today > > > > > > > and tomorrow. > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < > rwilton@cisco.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > I guess that the concern is that this introduces more > variation in > > > how > > > > > > > > data is interpreted between the different XML/JSON/CBOR > encodings. > > > > > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > > > configuration > > > > > > > > or state data may have a different meaning. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Carsten Bormann > > > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > > > To: Michel Veillette > > > > > > > > > Cc: Rob Wilton (rwilton) ; > core@ietf.org; > > > > > > > > > netconf@ietf.org > > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > The only potential problem I aware is when multiple > > > enumerations > > > > > > > > > > are part of > > > > > > > > > the same union. > > > > > > > > > > Value 4 from enumeration A will be encoded the same way > as > > > Value > > > > > > > > > > 4 from > > > > > > > > > enumeration B. > > > > > > > > > > > > > > > > > > =E2=80=A6 and that is not a problem for the XML version, = because > the > > > > > > > > > string is being used instead of the value. (But then if > two > > > > > > > > > enumerations share a string, you have the equivalent > problem in > > > > > > > > > the XML serialization.) > > > > > > > > > > > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YANG= that > actually > > > > > > > > > has this problem, so I would be a bit reluctant to make > CBOR- > > > based > > > > > > > > > implementations more complex (and less efficient) so solv= e > this > > > > > > > > > (non-?)problem. > > > > > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > netconf mailing list > > > > > > > netconf@ietf.org > > > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww > > > > > > > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343e= a8 > > > > > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > > > > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2= B0 > > > > > > > kvPZgr4o%3D&reserved=3D0 > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > > > Fax: +49 421 200 3103 < > > > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.j= acobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sd= ata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > netconf mailing list > > > > > > netconf@ietf.org > > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > > > > > ietf.org > %2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8d1 > > > > > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C > > > > > > > 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kvPZ > > > > > > gr4o%3D&reserved=3D0 > > > > > > > > > > -- > > > > > Ladislav Lhotka > > > > > Head, CZ.NIC Labs > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > --000000000000f2603d0585190b7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 27, 2019 at 12:54 PM Ladi= slav Lhotka <lhotka@nic.cz> wrot= e:
Andy Bierman = p=C3=AD=C5=A1e v St 27. 03. 2019 v 09:13 -0700:
>
>
> On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
> > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > > Hi,
> > >
> > > a union can be formed by using member types that are importe= d and not
> > > under change control of a single author/organization and ide= ally this
> > > should work without complex coordination of name and number = spaces.
> > > Duplicate enum/bits values are legal in YANG today so an enc= oding has
> > > to deal with this aspect of life.
> > >
> > > A robust fix to all these problems will be to tag the type m= embers in
> > > order to discriminate the values in the encodings. This, how= ever, will
> > > take some time to specify and we will need to preserve backw= ards
> > > compatibility with unions without a tag (but compilers can e= ncourage
> > > people to add tags whenever modules are updated).
> >
> > I already opened a new issue for this in yang-next:
> >
> > https://github.com/netmod-wg/yang-next/is= sues/72
> >
>
> We already explored the solution of giving the member types numbers > so they could be used in CBOR but this was rejected because it is so c= omplex
> to implement.

I don't think it is too complex. Get the type in the schema, get the me= mber,
that's all. It is much easier and more robust than the current algorith= m.


no it isn't easier because the alg= orithm is error-prone.
Renumbering un-named types nested within u= nions and referenced named types
over many revisions of the modul= e is not easy.
The encoding MUST NOT change EVER -- even if the u= nion type is expanded.
=C2=A0
>
> Consider when union is within union, and the types are named types fro= m

Union within union is no problem: it jut requires a sequence of numbers.

do not agree since the union can have = a member type added

=C2=A0
> other modules. Union types can be legally updated in new versions of t= he
> module,

Again, I don't agree. Sec. 11 in RFC 7950 says:

=C2=A0 =C2=A0o=C2=A0 A "type" statement may be replaced with anot= her "type" statement
=C2=A0 =C2=A0 =C2=A0 that does not change the syntax or semantics of the ty= pe.
=C2=A0 =C2=A0 =C2=A0 ...



=C2=A0 =C2=A0type uint3= 2 { range "1..8"; }

I can refactor that = into 2 types (1..4 and 5..8)
This does not change the semantics o= f the union type but it adds a member type
Other refactoring is p= ossible that will also change the number of member types.

Also, deviations do not follow this rule

= =C2=A0
Adding a new member clearly changes the semantics of the type, if not synta= x.


no it doesn't always change the se= mantics

=C2=A0
> but the position assignments for SID can never change.

The annotation would also help resolve the differences between JSON and XML= . SID
is only available in CBOR.

>
> Even without this complexity this solution would cause the encoder/dec= oder to
> be very schema-aware.

The current method of resolving unions is totally schema-aware (somewhat le= ss so
in JSON).


No -- it just needs to know string vs.= number.
Not schema aware at all.
=C2=A0
Lada


Andy
=C2=A0
>=C2=A0
>
> BTW, creating SIDs for enums and bits will break if the server uses &#= 39;deviate
> replace type'.
> There is no way to number the deviated type since this is server-speci= fic not
> part of the original module
> and the deviation is not actually a data-def-stmt.
>
>
> > Lada
> >
>
> Andy
>=C2=A0
> > >
> > > /js
> > >
> > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette w= rote:
> > > > Hi Ladislav
> > > >
> > > > If I summarize this issue of multiple enumerations or b= its in a union,
> > this
> > > > problem can be solve by the following approaches:
> > > >
> > > > - To not allows these duplicate values or positions to = happen in YANG
> > > > - To encode enumerations and bits as string (in all uni= ons or only when
> > > > multiple enumerations or bits are defined)
> > > > - To encode enumerations and bits as SID (in all unions= or only when
> > > > multiple enumerations or bits are defined)
> > > > - To encode enumerations and bits as delta between the = value SID and the
> > > > leaf SID (in all unions or only when multiple enumerati= ons or bits are
> > > > defined)
> > > >
> > > > In this email, I will like to focus on the first option= , fixing the
> > problem
> > > > directly in YANG instead of fixing the consequences. > > > >
> > > > Without any changes in YANG, a union with multiple enum= eration or bits
> > can
> > > > be constructed without value or position overlaps.
> > > > For example:
> > > >
> > > >=C2=A0 =C2=A0leaf multiple-enumerations-test-1 {
> > > >=C2=A0 =C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Monday"= ; { value 0; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Tuesday&quo= t; { value 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Wednesday&q= uot; { value 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Thursday&qu= ot; { value 3; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Friday"= ; { value 4; }
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Saturday&qu= ot; { value 5; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Sunday"= ; { value 6; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > >=C2=A0 =C2=A0leaf multiple-bits-test-1 {
> > > >=C2=A0 =C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type bits {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit=C2=A0 "Monday= " { position=C2=A0 0; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Tuesday"= ; { position=C2=A0 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Wednesday&qu= ot; { position=C2=A0 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Thursday&quo= t; { position=C2=A0 3; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Friday"= { position=C2=A0 4; }
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type bits {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Saturday&quo= t; { position 5; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Sunday"= { position 6; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > > When using already defined typedef, avoiding overlap is= less obvious
> > without
> > > > some help.
> > > > To help building unions with already defined typedefs, = I propose to
> > > > introduce two extensions.
> > > >
> > > >=C2=A0 =C2=A0extension value-offset {
> > > >=C2=A0 =C2=A0 =C2=A0argument offset {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0yin-element true;
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Offset added to each en= um value of the associated enumeration.";
> > > >=C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0
> > > >=C2=A0 =C2=A0extension position-offset {
> > > >=C2=A0 =C2=A0 =C2=A0argument offset {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0yin-element true;
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Offset value added to e= ach bit position of the associated bits.";
> > > >=C2=A0 =C2=A0}
> > > >
> > > > The value-offset extension can be used as follow:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Monday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Tuesday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Wednesday"; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Thursday"; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Friday";
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > >=C2=A0 =C2=A0typedef weekend {
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Saturday"; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Sunday";
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0
> > > >=C2=A0 =C2=A0leaf multiple-enumerations-test-3 {
> > > >=C2=A0 =C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekdays;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekend {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ext:value-offset 5; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > > The position-offset extension can be used as follow: > > > >
> > > >=C2=A0 =C2=A0typedef weekdays-flags {
> > > >=C2=A0 =C2=A0 =C2=A0type bits {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Monday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Tuesday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Wednesday"; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Thursday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Friday";
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > >=C2=A0 =C2=A0typedef weekend-flags {
> > > >=C2=A0 =C2=A0 =C2=A0type bits {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Saturday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Sunday";
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0
> > > >=C2=A0 =C2=A0leaf multiple-bits-test-3 {
> > > >=C2=A0 =C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekdays-flags;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekend-flags {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ext:position-offset 5;=
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > > The yang file in attachment show different examples bas= ed on this
> > approach.
> > > > This module have been validated using
> > http://www.yangvalidator.com/validator
> > > >=C2=A0
> > > > If this approach is accepted, tools like pyang should b= e updated to
> > produce
> > > > an error if multiple enumerations or bits are defined w= ith value or
> > position
> > > > overleaps.
> > > >
> > > > Please comment,
> > > > Michel
> > > >
> > > > -----Original Message-----
> > > > From: Ladislav Lhotka <lhotka@nic.cz>
> > > > Sent: Monday, March 25, 2019 4:07 AM
> > > > To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni= versity.de>;
> > Carsten
> > > > Bormann <cabo@tzi.org>
> > > > Cc: Michel Veillette <Michel.Veillette@trilliant.com>= ;; netconf@ietf.org;
> >=C2=A0
> > > > core= @ietf.org
> > > > Subject: Re: [netconf] YANG encoding in CBOR
> > > >
> > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-univers= ity.de> writes:
> > > >
> > > > > I think we need to look at the whole picture and i= n which direction
> > we
> > > > > want to go. In the longer term, I would prefer a s= olution where the
> > > > > values of a union are discriminated. The current X= ML encoding
> > > > > behaviour of 'first match wins' is fragile= (for example, if someone
> > > > > adds an enum to a type, the interpretation of data= can change).
> > > > >
> > > > > Look at this:
> > > > >
> > > > > typedef bar {
> > > > >=C2=A0 =C2=A0type union {
> > > > >=C2=A0 =C2=A0 =C2=A0type enumeration { enum "1= "; value 2; enum "2"; value 1; }
> > > > >=C2=A0 =C2=A0 =C2=A0type uint8;
> > > > >=C2=A0 =C2=A0}
> > > > > }
> > > > >
> > > > > We have some encodings that send the string repres= entations of the
> > > > > values and some encodings that prefer to send nume= ric representations
> > > > > where possible. In order to have a robust solution= , encodings should
> > > > > likely indicate to which type the value belongs. > > > >
> > > > Perhaps the easiest way would be to use (optional) anno= tation that
> > > > specifies, using an ordinal number, which of the member= types is used
> > for
> > > > the particular instance. But since there can be unions = inside unions, a
> > list
> > > > of numbers would be needed in general.
> > > >
> > > > Lada
> > > >
> > > > > /js
> > > > >
> > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten = Bormann wrote:
> > > > > > Well, if that is a problem, we can go for a l= onger representation
> > within
> > > > > > unions (section 6.12).=C2=A0 Theoretically, w= e could do that only of
> > there is
> > > > > > more than one enum in the union type (so thin= gs stay efficient if
> > there
> > > > > > is only one), but that might pose difficultie= s with model evolution.
> > > > > >
> > > > > > Going for a string representation repeats the= feature of XML YANG
> > (which
> > > > > > was ported over to JSON YANG):
> > > > > >
> > > > > > typedef foo {
> > > > > >=C2=A0 =C2=A0type union {
> > > > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum red { value 1;= }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum breen { value = 2; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3= ; }
> > > > > >=C2=A0 =C2=A0 =C2=A0}
> > > > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum tacks { value = 1; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum nails { value = 2; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3= ; }
> > > > > >=C2=A0 =C2=A0 =C2=A0}
> > > > > >=C2=A0 =C2=A0}
> > > > > > }
> > > > > >
> > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2= =80=99t know which of the enumerations are
> > being
> > > > > > used.
> > > > > >
> > > > > > Using SIDs, we can do better.
> > > > > >
> > > > > > So what do we have to do to get the SID tool = to allocate SIDs for
> > enum
> > > > > > values?
> > > > > >
> > > > > > We could then define the CBOR tag for enums i= n unions to take the
> > usual
> > > > > > SID difference (delta relative to the environ= ment, I=E2=80=99d think), not
> > an
> > > > > > integer value.
> > > > > >
> > > > > > Several of us are at the hackathon and could = make something happen
> > today
> > > > > > and tomorrow.
> > > > > >
> > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > > >
> > > > > >
> > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (r= wilton) <rwilton@= cisco.com
> > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > I guess that the concern is that this in= troduces more variation in
> > how
> > > > > > > data is interpreted between the differen= t XML/JSON/CBOR encodings.
> > > > > > >
> > > > > > > E.g. if someone switched from XML to CBO= R, suddenly the
> > configuration
> > > > > > > or state data may have a different meani= ng.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Rob
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Carsten Bormann <cabo@tzi.org>
> > > > > > > > Sent: 22 March 2019 16:08
> > > > > > > > To: Michel Veillette <Michel.Veillette@= trilliant.com>
> > > > > > > > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>;= core@ietf.org;
> > > > > > > > netconf@ietf.org
> > > > > > > > Subject: Re: [netconf] YANG encodin= g in CBOR
> > > > > > > >
> > > > > > > > On Mar 22, 2019, at 16:45, Michel V= eillette
> > > > > > > > <Michel.Veillette@trilliant.com>=
> > > > > > > > wrote:
> > > > > > > > > The only potential problem I a= ware is when multiple
> > enumerations
> > > > > > > > > are part of
> > > > > > > > the same union.
> > > > > > > > > Value 4 from enumeration A wil= l be encoded the same way as
> > Value
> > > > > > > > > 4 from
> > > > > > > > enumeration B.
> > > > > > > >
> > > > > > > > =E2=80=A6 and that is not a problem= for the XML version, because the
> > > > > > > > string is being used instead of the= value.=C2=A0 (But then if two
> > > > > > > > enumerations share a string, you ha= ve the equivalent problem in
> > > > > > > > the XML serialization.)
> > > > > > > >
> > > > > > > > Anyway, I haven=E2=80=99t seen a pi= ece of real-world YANG that actually
> > > > > > > > has this problem, so I would be a b= it reluctant to make CBOR-
> > based
> > > > > > > > implementations more complex (and l= ess efficient) so solve this
> > > > > > > > (non-?)problem.
> > > > > > > >
> > > > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _____________________________________________= __
> > > > > > netconf mailing list
> > > > > > netconf@ietf.org
> > > > > >
> > https://can01.safel= inks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> > > > > >
> > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D02%7C01%7C%7C34= 3ea8
> > > > > >
> > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0= %7C1
> > > > > >
> > %7C636890980182553400&amp;sdata=3Du1KFAYAus16B8a7sgsBfPfIquOp= tMlaOb%2B0
> > > > > > kvPZgr4o%3D&amp;reserved=3D0
> > > > >
> > > > > --
> > > > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Jacobs University Bremen gGmbH
> > > > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Campus Ring 1 | 28759 Bremen | Germany
> > > > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<
> > > > >
> > https:/= /can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.jacobs-uni= versity.de%2F&amp;data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%= 7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&amp;sda= ta=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&amp;reserved=3D= 0
> > > > > >
> > > > >
> > > > >
> > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten = Bormann wrote:
> > > > > > Well, if that is a problem, we can go for a l= onger representation
> > within
> > > > > > unions (section 6.12).=C2=A0 Theoretically, w= e could do that only of
> > there is
> > > > > > more than one enum in the union type (so thin= gs stay efficient if
> > there
> > > > > > is only one), but that might pose difficultie= s with model evolution.
> > > > > >
> > > > > > Going for a string representation repeats the= feature of XML YANG
> > (which
> > > > > > was ported over to JSON YANG):
> > > > > >
> > > > > > typedef foo {
> > > > > >=C2=A0 =C2=A0type union {
> > > > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum red { value 1;= }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum breen { value = 2; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3= ; }
> > > > > >=C2=A0 =C2=A0 =C2=A0}
> > > > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum tacks { value = 1; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum nails { value = 2; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3= ; }
> > > > > >=C2=A0 =C2=A0 =C2=A0}
> > > > > >=C2=A0 =C2=A0}
> > > > > > }
> > > > > >
> > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2= =80=99t know which of the enumerations are
> > being
> > > > > > used.
> > > > > >
> > > > > > Using SIDs, we can do better.
> > > > > >
> > > > > > So what do we have to do to get the SID tool = to allocate SIDs for
> > enum
> > > > > > values?
> > > > > >
> > > > > > We could then define the CBOR tag for enums i= n unions to take the
> > usual
> > > > > > SID difference (delta relative to the environ= ment, I=E2=80=99d think), not
> > an
> > > > > > integer value.
> > > > > >
> > > > > > Several of us are at the hackathon and could = make something happen
> > today
> > > > > > and tomorrow.
> > > > > >
> > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > > >
> > > > > >
> > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (r= wilton) <rwilton@= cisco.com
> > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > I guess that the concern is that this in= troduces more variation in
> > how
> > > > > > > data is interpreted between the differen= t XML/JSON/CBOR encodings.
> > > > > > >
> > > > > > > E.g. if someone switched from XML to CBO= R, suddenly the
> > configuration
> > > > > > > or state data may have a different meani= ng.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Rob
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Carsten Bormann <cabo@tzi.org>
> > > > > > > > Sent: 22 March 2019 16:08
> > > > > > > > To: Michel Veillette <Michel.Veillette@= trilliant.com>
> > > > > > > > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>;= core@ietf.org;
> > > > > > > > netconf@ietf.org
> > > > > > > > Subject: Re: [netconf] YANG encodin= g in CBOR
> > > > > > > >
> > > > > > > > On Mar 22, 2019, at 16:45, Michel V= eillette
> > > > > > > > <Michel.Veillette@trilliant.com>=
> > > > > > > > wrote:
> > > > > > > > > The only potential problem I a= ware is when multiple
> > enumerations
> > > > > > > > > are part of
> > > > > > > > the same union.
> > > > > > > > > Value 4 from enumeration A wil= l be encoded the same way as
> > Value
> > > > > > > > > 4 from
> > > > > > > > enumeration B.
> > > > > > > >
> > > > > > > > =E2=80=A6 and that is not a problem= for the XML version, because the
> > > > > > > > string is being used instead of the= value.=C2=A0 (But then if two
> > > > > > > > enumerations share a string, you ha= ve the equivalent problem in
> > > > > > > > the XML serialization.)
> > > > > > > >
> > > > > > > > Anyway, I haven=E2=80=99t seen a pi= ece of real-world YANG that actually
> > > > > > > > has this problem, so I would be a b= it reluctant to make CBOR-
> > based
> > > > > > > > implementations more complex (and l= ess efficient) so solve this
> > > > > > > > (non-?)problem.
> > > > > > > >
> > > > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _____________________________________________= __
> > > > > > netconf mailing list
> > > > > > netconf@ietf.org
> > > > > >
> > https://can01.safel= inks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> > > > > >
> > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D02%7C01%7C%7C34= 3ea8
> > > > > >
> > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0= %7C1
> > > > > >
> > %7C636890980182553400&amp;sdata=3Du1KFAYAus16B8a7sgsBfPfIquOp= tMlaOb%2B0
> > > > > > kvPZgr4o%3D&amp;reserved=3D0
> > > > >
> > > > > --
> > > > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Jacobs University Bremen gGmbH
> > > > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Campus Ring 1 | 28759 Bremen | Germany
> > > > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<
> > > > >
> > https:/= /can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.jacobs-uni= versity.de%2F&amp;data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%= 7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&amp;sda= ta=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&amp;reserved=3D= 0
> > > > > >
> > > > >
> > > > > _______________________________________________ > > > > > netconf mailing list
> > > > > netconf@ietf.org
> > > > > http= s://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D0= 2%7C01%7C%7C343ea8d1
> > > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43= 260c04309%7C0%7C1%7C
> > > > > 636890980182553400&amp;sdata=3Du1KFAYAus16B8a7= sgsBfPfIquOptMlaOb%2B0kvPZ
> > > > > gr4o%3D&amp;reserved=3D0
> > > >
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > >
> > >
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

--000000000000f2603d0585190b7c-- From nobody Wed Mar 27 18:37:36 2019 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 DD25D120154 for ; Wed, 27 Mar 2019 18:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrSBSZZfUUHj for ; Wed, 27 Mar 2019 18:37:29 -0700 (PDT) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 7E5C9120148 for ; Wed, 27 Mar 2019 18:37:28 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id d18so12779787lfn.3 for ; Wed, 27 Mar 2019 18:37:28 -0700 (PDT) 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=tfknNrBJwSLp4kQR0Lu3mUy31/WpYeLthisqCPdE34U=; b=G8Uw1tATUcS9XMk5/OLkXO00hxNoWJb5V4WMpA4oiRmZiI7JUQHqVNS2rmsigTQ1mE zUkS756m5khYWZcMyap9Fyz17sfDMBRAKOcGgTEmuUfrSN7izDtz9ngIdcX/ByQ3LMEh nm3upnwcgcAHZ7fMXTHrahkAxrdrtdSuWT/kAlBT1H4kc0sSJBbAlnUXq7Ieq94yE0Ly L0sHil1EFsjXKCkdyu9UlbBV/QFgTmA2U99sMpQMIwqVxD8ZwpdzJ8hh5420Lu+M1Yxl yivdThzodktWnu406Zb8b8gwLnp0VPRA8wov5Z/0aRcvGfNniZwRmN2vjf5njhc3u++V ASzg== 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=tfknNrBJwSLp4kQR0Lu3mUy31/WpYeLthisqCPdE34U=; b=URaxX/erxdcZ4Q/v28yEXp1KjZOIwOQwGlPkb97s6N2RKwvdQ2Gl5+C/X8TYeDkF+T LdPnIfsVfEWPdmsmPYkQm5hd6Igr7WThxQImxpYbqf2OoYB/YfU11sFiCFwlznjrqwG8 J/WR6ilToe7eVWPGIfXf3klM+GsNIuo1BH6hlLtHj331k0Z7BEKzMDI9geTjOACIwlwY rMA4bGG7qWsxgC+oP8PUoOIW0mx5h2d6NrMNmUXeCLl4u0ZVIETooEB3InAT6XJRQ/9m oPRl2zJKPNWw+XtHRREdsOcWVMzSePm23JAjCSWWek9v8AZBWa/0fbeTpxht+mcAsTqi Hc4w== X-Gm-Message-State: APjAAAX1c7CT0UXcuisSkDEzv6rzzidLh3YBy9AKYH5fSiSSdBTBrivh DpCNgSfnPRaEZU/MD9TPCZcMgaDgz+1sSjkphsNIkQ== X-Google-Smtp-Source: APXvYqyRaPFW0AOUPsnL50Vb9oeZVPLSkndbHZR5bHsKrVcItoOnc1+TXSy79ptu3oPtgU7yxqEMxvijqGI48zQW5TM= X-Received: by 2002:ac2:41c4:: with SMTP id d4mr21103116lfi.104.1553737046602; Wed, 27 Mar 2019 18:37:26 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> In-Reply-To: From: Andy Bierman Date: Wed, 27 Mar 2019 18:37:15 -0700 Message-ID: To: Ladislav Lhotka Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bcd01e05851d98c5" Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 01:37:34 -0000 --000000000000bcd01e05851d98c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Lada, On Wed, Mar 27, 2019 at 12:54 PM Ladislav Lhotka wrote: > Andy Bierman p=C3=AD=C5=A1e v St 27. 03. 2019 v 09:13 -0700: > > > > > > On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka wrote: > > > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > > > Hi, > > > > > > > > a union can be formed by using member types that are imported and n= ot > > > > under change control of a single author/organization and ideally th= is > > > > should work without complex coordination of name and number spaces. > > > > Duplicate enum/bits values are legal in YANG today so an encoding h= as > > > > to deal with this aspect of life. > > > > > > > > A robust fix to all these problems will be to tag the type members = in > > > > order to discriminate the values in the encodings. This, however, > will > > > > take some time to specify and we will need to preserve backwards > > > > compatibility with unions without a tag (but compilers can encourag= e > > > > people to add tags whenever modules are updated). > > > > > > I already opened a new issue for this in yang-next: > > > > > > https://github.com/netmod-wg/yang-next/issues/72 > > > > > > > We already explored the solution of giving the member types numbers > > so they could be used in CBOR but this was rejected because it is so > complex > > to implement. > > I don't think it is too complex. Get the type in the schema, get the > member, > that's all. It is much easier and more robust than the current algorithm. > ... I think a discriminated union is too complex and overkill, considering the low probability of the problem. It's not as if the client or server developers know which union member type each value is using. This is not going to be hard-wired either. Senders do not usually validate data, especially NETCONF servers. It will be very expensive (and very slow) to validate union types in order to determine the member type number. We cannot rely on YANG authors to follow the update rules, especially when they change type definitions to fix bugs. The encoding for a union cannot ever change over time or it will break clients. We want to support clients without requiring any code changes, even when the server is upgraded. I prefer a much easier and faster solution: The client or server must figure out which data nodes have this problem at boot-time. These data nodes will always be sent with a new tag (for DUP-UNION) and the format will always be a string. A receiver must be able to handle DUP-UNION strings and parse them against the union type correctly. All other union type data nodes are sent as normal. Annotations are not needed. The JSON vs. XML ordering problem can be handled with best practices https://tools.ietf.org/html/rfc8407#section-4.11.4 Andy --000000000000bcd01e05851d98c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Lada,

On Wed, Mar 27, 2019 at 12:54 PM Ladislav Lho= tka <lhotka@nic.cz> wrote:
Andy Bierman p=C3=AD= =C5=A1e v St 27. 03. 2019 v 09:13 -0700:
>
>
> On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
> > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > > Hi,
> > >
> > > a union can be formed by using member types that are importe= d and not
> > > under change control of a single author/organization and ide= ally this
> > > should work without complex coordination of name and number = spaces.
> > > Duplicate enum/bits values are legal in YANG today so an enc= oding has
> > > to deal with this aspect of life.
> > >
> > > A robust fix to all these problems will be to tag the type m= embers in
> > > order to discriminate the values in the encodings. This, how= ever, will
> > > take some time to specify and we will need to preserve backw= ards
> > > compatibility with unions without a tag (but compilers can e= ncourage
> > > people to add tags whenever modules are updated).
> >
> > I already opened a new issue for this in yang-next:
> >
> > https://github.com/netmod-wg/yang-next/is= sues/72
> >
>
> We already explored the solution of giving the member types numbers > so they could be used in CBOR but this was rejected because it is so c= omplex
> to implement.

I don't think it is too complex. Get the type in the schema, get the me= mber,
that's all. It is much easier and more robust than the current algorith= m.
...

I think a discriminated union is = too complex and overkill, considering the low probability
of the = problem.

It's not as if the client or server d= evelopers know which union member type each value is using.
This = is not going to be hard-wired either.=C2=A0 Senders do not usually validate= data, especially
NETCONF servers.=C2=A0 It will be very expensiv= e (and very slow) to validate union types
in order to determine t= he member type number.

We cannot rely on YANG auth= ors to follow the update rules, especially when
they change type = definitions to fix bugs.=C2=A0 The encoding for a union cannot ever
change over time or it will break clients. We want to support clients wi= thout requiring
any code changes, even when the server is upgrade= d.

I prefer a much easier and faster solution:

The client or server must figure out which data nodes= have this problem at boot-time.
These data nodes will always be = sent with a new tag (for DUP-UNION) and the
format will always be= a string. A receiver must be able to handle DUP-UNION strings
an= d parse them against the union type correctly.

All= other union type data nodes are sent as normal.
Annotations are = not needed.

The JSON vs. XML ordering problem can = be handled with best practices


Andy

--000000000000bcd01e05851d98c5-- From nobody Thu Mar 28 02:33:22 2019 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 46A32120165; Thu, 28 Mar 2019 02:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgNW019cq-e6; Thu, 28 Mar 2019 02:33:15 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C78141201A7; Thu, 28 Mar 2019 02:33:14 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 2146118204C5; Thu, 28 Mar 2019 10:32:38 +0100 (CET) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 29BEA1820047; Thu, 28 Mar 2019 10:32:31 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman Cc: Juergen Schoenwaelder , Michel Veillette , "netconf\@ietf.org" , "core\@ietf.org" In-Reply-To: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> Date: Thu, 28 Mar 2019 10:33:06 +0100 Message-ID: <87r2armjhp.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 09:33:20 -0000 Andy Bierman writes: > On Wed, Mar 27, 2019 at 12:54 PM Ladislav Lhotka wrote: > >> Andy Bierman p=C3=AD=C5=A1e v St 27. 03. 2019 v 09:13 -0700: >> > >> > >> > On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka wrote: >> > > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: >> > > > Hi, >> > > > >> > > > a union can be formed by using member types that are imported and = not >> > > > under change control of a single author/organization and ideally t= his >> > > > should work without complex coordination of name and number spaces. >> > > > Duplicate enum/bits values are legal in YANG today so an encoding = has >> > > > to deal with this aspect of life. >> > > > >> > > > A robust fix to all these problems will be to tag the type members= in >> > > > order to discriminate the values in the encodings. This, however, >> will >> > > > take some time to specify and we will need to preserve backwards >> > > > compatibility with unions without a tag (but compilers can encoura= ge >> > > > people to add tags whenever modules are updated). >> > > >> > > I already opened a new issue for this in yang-next: >> > > >> > > https://github.com/netmod-wg/yang-next/issues/72 >> > > >> > >> > We already explored the solution of giving the member types numbers >> > so they could be used in CBOR but this was rejected because it is so >> complex >> > to implement. >> >> I don't think it is too complex. Get the type in the schema, get the >> member, >> that's all. It is much easier and more robust than the current algorithm. >> >> > no it isn't easier because the algorithm is error-prone. > Renumbering un-named types nested within unions and referenced named types > over many revisions of the module is not easy. > The encoding MUST NOT change EVER -- even if the union type is expanded. > > >> > >> > Consider when union is within union, and the types are named types from >> >> Union within union is no problem: it jut requires a sequence of numbers. >> >> > do not agree since the union can have a member type added > > > >> > other modules. Union types can be legally updated in new versions of t= he >> > module, >> >> Again, I don't agree. Sec. 11 in RFC 7950 says: >> >> o A "type" statement may be replaced with another "type" statement >> that does not change the syntax or semantics of the type. >> ... >> >> > > type uint32 { range "1..8"; } > > I can refactor that into 2 types (1..4 and 5..8) This looks like a pretty contrived example, why would somebody want to do this? Anyway, regarding updates: one can have this union type union { type uint32 { range "1..3"; } type string; } So, in XML representation, the value of 4 will be classified as a string. Now, according to sec. 11, it is legal to expand the range to 1..10, say. Suddenly, the same value becomes a number. > This does not change the semantics of the union type but it adds a member > type > Other refactoring is possible that will also change the number of member > types. > > Also, deviations do not follow this rule > > > >> Adding a new member clearly changes the semantics of the type, if not >> syntax. >> >> > no it doesn't always change the semantics > > > >> > but the position assignments for SID can never change. >> >> The annotation would also help resolve the differences between JSON and >> XML. SID >> is only available in CBOR. >> >> > >> > Even without this complexity this solution would cause the >> encoder/decoder to >> > be very schema-aware. >> >> The current method of resolving unions is totally schema-aware (somewhat >> less so >> in JSON). >> >> > No -- it just needs to know string vs. number. > Not schema aware at all. Of course it is. With both strings and numbers, you also have to check restrictions if they are specified in the schema (pattern, range etc.), deref leafrefs etc. I think we all agree that unions in YANG are fragile and may cause subtle problems. If a better solution is found, then fine, but IMO it needs to be addressed, and not only in CBOR. Lada > > >> Lada >> >> > Andy > > >> > >> > >> > BTW, creating SIDs for enums and bits will break if the server uses >> 'deviate >> > replace type'. >> > There is no way to number the deviated type since this is >> server-specific not >> > part of the original module >> > and the deviation is not actually a data-def-stmt. >> > >> > >> > > Lada >> > > >> > >> > Andy >> > >> > > > >> > > > /js >> > > > >> > > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: >> > > > > Hi Ladislav >> > > > > >> > > > > If I summarize this issue of multiple enumerations or bits in a >> union, >> > > this >> > > > > problem can be solve by the following approaches: >> > > > > >> > > > > - To not allows these duplicate values or positions to happen in >> YANG >> > > > > - To encode enumerations and bits as string (in all unions or on= ly >> when >> > > > > multiple enumerations or bits are defined) >> > > > > - To encode enumerations and bits as SID (in all unions or only >> when >> > > > > multiple enumerations or bits are defined) >> > > > > - To encode enumerations and bits as delta between the value SID >> and the >> > > > > leaf SID (in all unions or only when multiple enumerations or bi= ts >> are >> > > > > defined) >> > > > > >> > > > > In this email, I will like to focus on the first option, fixing = the >> > > problem >> > > > > directly in YANG instead of fixing the consequences. >> > > > > >> > > > > Without any changes in YANG, a union with multiple enumeration or >> bits >> > > can >> > > > > be constructed without value or position overlaps. >> > > > > For example: >> > > > > >> > > > > leaf multiple-enumerations-test-1 { >> > > > > type union { >> > > > > type enumeration { >> > > > > enum "Monday" { value 0; } >> > > > > enum "Tuesday" { value 1; } >> > > > > enum "Wednesday" { value 2; } >> > > > > enum "Thursday" { value 3; } >> > > > > enum "Friday" { value 4; } >> > > > > >> > > > > } >> > > > > type enumeration { >> > > > > enum "Saturday" { value 5; } >> > > > > enum "Sunday" { value 6; } >> > > > > } >> > > > > } >> > > > > } >> > > > > >> > > > > leaf multiple-bits-test-1 { >> > > > > type union { >> > > > > type bits { >> > > > > bit "Monday" { position 0; } >> > > > > bit "Tuesday" { position 1; } >> > > > > bit "Wednesday" { position 2; } >> > > > > bit "Thursday" { position 3; } >> > > > > bit "Friday" { position 4; } >> > > > > >> > > > > } >> > > > > type bits { >> > > > > bit "Saturday" { position 5; } >> > > > > bit "Sunday" { position 6; } >> > > > > } >> > > > > } >> > > > > } >> > > > > >> > > > > When using already defined typedef, avoiding overlap is less >> obvious >> > > without >> > > > > some help. >> > > > > To help building unions with already defined typedefs, I propose= to >> > > > > introduce two extensions. >> > > > > >> > > > > extension value-offset { >> > > > > argument offset { >> > > > > yin-element true; >> > > > > } >> > > > > description >> > > > > "Offset added to each enum value of the associated >> enumeration."; >> > > > > } >> > > > > >> > > > > extension position-offset { >> > > > > argument offset { >> > > > > yin-element true; >> > > > > } >> > > > > description >> > > > > "Offset value added to each bit position of the associated >> bits."; >> > > > > } >> > > > > >> > > > > The value-offset extension can be used as follow: >> > > > > >> > > > > type enumeration { >> > > > > enum "Monday"; >> > > > > enum "Tuesday"; >> > > > > enum "Wednesday"; >> > > > > enum "Thursday"; >> > > > > enum "Friday"; >> > > > > } >> > > > > } >> > > > > >> > > > > typedef weekend { >> > > > > type enumeration { >> > > > > enum "Saturday"; >> > > > > enum "Sunday"; >> > > > > } >> > > > > } >> > > > > >> > > > > leaf multiple-enumerations-test-3 { >> > > > > type union { >> > > > > type weekdays; >> > > > > type weekend { >> > > > > ext:value-offset 5; >> > > > > } >> > > > > } >> > > > > } >> > > > > >> > > > > The position-offset extension can be used as follow: >> > > > > >> > > > > typedef weekdays-flags { >> > > > > type bits { >> > > > > bit "Monday"; >> > > > > bit "Tuesday"; >> > > > > bit "Wednesday"; >> > > > > bit "Thursday"; >> > > > > bit "Friday"; >> > > > > } >> > > > > } >> > > > > >> > > > > typedef weekend-flags { >> > > > > type bits { >> > > > > bit "Saturday"; >> > > > > bit "Sunday"; >> > > > > } >> > > > > } >> > > > > >> > > > > leaf multiple-bits-test-3 { >> > > > > type union { >> > > > > type weekdays-flags; >> > > > > type weekend-flags { >> > > > > ext:position-offset 5; >> > > > > } >> > > > > } >> > > > > } >> > > > > >> > > > > The yang file in attachment show different examples based on this >> > > approach. >> > > > > This module have been validated using >> > > http://www.yangvalidator.com/validator >> > > > > >> > > > > If this approach is accepted, tools like pyang should be updated= to >> > > produce >> > > > > an error if multiple enumerations or bits are defined with value= or >> > > position >> > > > > overleaps. >> > > > > >> > > > > Please comment, >> > > > > Michel >> > > > > >> > > > > -----Original Message----- >> > > > > From: Ladislav Lhotka >> > > > > Sent: Monday, March 25, 2019 4:07 AM >> > > > > To: Juergen Schoenwaelder ; >> > > Carsten >> > > > > Bormann >> > > > > Cc: Michel Veillette ; >> netconf@ietf.org; >> > > >> > > > > core@ietf.org >> > > > > Subject: Re: [netconf] YANG encoding in CBOR >> > > > > >> > > > > Juergen Schoenwaelder >> writes: >> > > > > >> > > > > > I think we need to look at the whole picture and in which >> direction >> > > we >> > > > > > want to go. In the longer term, I would prefer a solution where >> the >> > > > > > values of a union are discriminated. The current XML encoding >> > > > > > behaviour of 'first match wins' is fragile (for example, if >> someone >> > > > > > adds an enum to a type, the interpretation of data can change). >> > > > > > >> > > > > > Look at this: >> > > > > > >> > > > > > typedef bar { >> > > > > > type union { >> > > > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } >> > > > > > type uint8; >> > > > > > } >> > > > > > } >> > > > > > >> > > > > > We have some encodings that send the string representations of >> the >> > > > > > values and some encodings that prefer to send numeric >> representations >> > > > > > where possible. In order to have a robust solution, encodings >> should >> > > > > > likely indicate to which type the value belongs. >> > > > > >> > > > > Perhaps the easiest way would be to use (optional) annotation th= at >> > > > > specifies, using an ordinal number, which of the member types is >> used >> > > for >> > > > > the particular instance. But since there can be unions inside >> unions, a >> > > list >> > > > > of numbers would be needed in general. >> > > > > >> > > > > Lada >> > > > > >> > > > > > /js >> > > > > > >> > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrot= e: >> > > > > > > Well, if that is a problem, we can go for a longer >> representation >> > > within >> > > > > > > unions (section 6.12). Theoretically, we could do that only= of >> > > there is >> > > > > > > more than one enum in the union type (so things stay efficie= nt >> if >> > > there >> > > > > > > is only one), but that might pose difficulties with model >> evolution. >> > > > > > > >> > > > > > > Going for a string representation repeats the feature of XML >> YANG >> > > (which >> > > > > > > was ported over to JSON YANG): >> > > > > > > >> > > > > > > typedef foo { >> > > > > > > type union { >> > > > > > > type enumeration { >> > > > > > > enum red { value 1; } >> > > > > > > enum breen { value 2; } >> > > > > > > enum glue { value 3; } >> > > > > > > } >> > > > > > > type enumeration { >> > > > > > > enum tacks { value 1; } >> > > > > > > enum nails { value 2; } >> > > > > > > enum glue { value 3; } >> > > > > > > } >> > > > > > > } >> > > > > > > } >> > > > > > > >> > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know wh= ich of the enumerations are >> > > being >> > > > > > > used. >> > > > > > > >> > > > > > > Using SIDs, we can do better. >> > > > > > > >> > > > > > > So what do we have to do to get the SID tool to allocate SIDs >> for >> > > enum >> > > > > > > values? >> > > > > > > >> > > > > > > We could then define the CBOR tag for enums in unions to take >> the >> > > usual >> > > > > > > SID difference (delta relative to the environment, I=E2=80= =99d think), >> not >> > > an >> > > > > > > integer value. >> > > > > > > >> > > > > > > Several of us are at the hackathon and could make something >> happen >> > > today >> > > > > > > and tomorrow. >> > > > > > > >> > > > > > > Gr=C3=BC=C3=9Fe, Carsten >> > > > > > > >> > > > > > > >> > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < >> rwilton@cisco.com >> > > > >> > > > > > > > wrote: >> > > > > > > > >> > > > > > > > I guess that the concern is that this introduces more >> variation in >> > > how >> > > > > > > > data is interpreted between the different XML/JSON/CBOR >> encodings. >> > > > > > > > >> > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the >> > > configuration >> > > > > > > > or state data may have a different meaning. >> > > > > > > > >> > > > > > > > Thanks, >> > > > > > > > Rob >> > > > > > > > >> > > > > > > > >> > > > > > > > > -----Original Message----- >> > > > > > > > > From: Carsten Bormann >> > > > > > > > > Sent: 22 March 2019 16:08 >> > > > > > > > > To: Michel Veillette >> > > > > > > > > Cc: Rob Wilton (rwilton) ; >> core@ietf.org; >> > > > > > > > > netconf@ietf.org >> > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR >> > > > > > > > > >> > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette >> > > > > > > > > >> > > > > > > > > wrote: >> > > > > > > > > > The only potential problem I aware is when multiple >> > > enumerations >> > > > > > > > > > are part of >> > > > > > > > > the same union. >> > > > > > > > > > Value 4 from enumeration A will be encoded the same way >> as >> > > Value >> > > > > > > > > > 4 from >> > > > > > > > > enumeration B. >> > > > > > > > > >> > > > > > > > > =E2=80=A6 and that is not a problem for the XML version,= because >> the >> > > > > > > > > string is being used instead of the value. (But then if >> two >> > > > > > > > > enumerations share a string, you have the equivalent >> problem in >> > > > > > > > > the XML serialization.) >> > > > > > > > > >> > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YAN= G that >> actually >> > > > > > > > > has this problem, so I would be a bit reluctant to make >> CBOR- >> > > based >> > > > > > > > > implementations more complex (and less efficient) so sol= ve >> this >> > > > > > > > > (non-?)problem. >> > > > > > > > > >> > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > netconf mailing list >> > > > > > > netconf@ietf.org >> > > > > > > >> > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www >> > > > > > > >> > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343= ea8 >> > > > > > > >> > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 >> > > > > > > >> > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%= 2B0 >> > > > > > > kvPZgr4o%3D&reserved=3D0 >> > > > > > >> > > > > > -- >> > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> > > > > > Fax: +49 421 200 3103 < >> > > > > > >> > > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= jacobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f= 8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&s= data=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 >> > > > > > > >> > > > > > >> > > > > > >> > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrot= e: >> > > > > > > Well, if that is a problem, we can go for a longer >> representation >> > > within >> > > > > > > unions (section 6.12). Theoretically, we could do that only= of >> > > there is >> > > > > > > more than one enum in the union type (so things stay efficie= nt >> if >> > > there >> > > > > > > is only one), but that might pose difficulties with model >> evolution. >> > > > > > > >> > > > > > > Going for a string representation repeats the feature of XML >> YANG >> > > (which >> > > > > > > was ported over to JSON YANG): >> > > > > > > >> > > > > > > typedef foo { >> > > > > > > type union { >> > > > > > > type enumeration { >> > > > > > > enum red { value 1; } >> > > > > > > enum breen { value 2; } >> > > > > > > enum glue { value 3; } >> > > > > > > } >> > > > > > > type enumeration { >> > > > > > > enum tacks { value 1; } >> > > > > > > enum nails { value 2; } >> > > > > > > enum glue { value 3; } >> > > > > > > } >> > > > > > > } >> > > > > > > } >> > > > > > > >> > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know wh= ich of the enumerations are >> > > being >> > > > > > > used. >> > > > > > > >> > > > > > > Using SIDs, we can do better. >> > > > > > > >> > > > > > > So what do we have to do to get the SID tool to allocate SIDs >> for >> > > enum >> > > > > > > values? >> > > > > > > >> > > > > > > We could then define the CBOR tag for enums in unions to take >> the >> > > usual >> > > > > > > SID difference (delta relative to the environment, I=E2=80= =99d think), >> not >> > > an >> > > > > > > integer value. >> > > > > > > >> > > > > > > Several of us are at the hackathon and could make something >> happen >> > > today >> > > > > > > and tomorrow. >> > > > > > > >> > > > > > > Gr=C3=BC=C3=9Fe, Carsten >> > > > > > > >> > > > > > > >> > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < >> rwilton@cisco.com >> > > > >> > > > > > > > wrote: >> > > > > > > > >> > > > > > > > I guess that the concern is that this introduces more >> variation in >> > > how >> > > > > > > > data is interpreted between the different XML/JSON/CBOR >> encodings. >> > > > > > > > >> > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the >> > > configuration >> > > > > > > > or state data may have a different meaning. >> > > > > > > > >> > > > > > > > Thanks, >> > > > > > > > Rob >> > > > > > > > >> > > > > > > > >> > > > > > > > > -----Original Message----- >> > > > > > > > > From: Carsten Bormann >> > > > > > > > > Sent: 22 March 2019 16:08 >> > > > > > > > > To: Michel Veillette >> > > > > > > > > Cc: Rob Wilton (rwilton) ; >> core@ietf.org; >> > > > > > > > > netconf@ietf.org >> > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR >> > > > > > > > > >> > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette >> > > > > > > > > >> > > > > > > > > wrote: >> > > > > > > > > > The only potential problem I aware is when multiple >> > > enumerations >> > > > > > > > > > are part of >> > > > > > > > > the same union. >> > > > > > > > > > Value 4 from enumeration A will be encoded the same way >> as >> > > Value >> > > > > > > > > > 4 from >> > > > > > > > > enumeration B. >> > > > > > > > > >> > > > > > > > > =E2=80=A6 and that is not a problem for the XML version,= because >> the >> > > > > > > > > string is being used instead of the value. (But then if >> two >> > > > > > > > > enumerations share a string, you have the equivalent >> problem in >> > > > > > > > > the XML serialization.) >> > > > > > > > > >> > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YAN= G that >> actually >> > > > > > > > > has this problem, so I would be a bit reluctant to make >> CBOR- >> > > based >> > > > > > > > > implementations more complex (and less efficient) so sol= ve >> this >> > > > > > > > > (non-?)problem. >> > > > > > > > > >> > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > netconf mailing list >> > > > > > > netconf@ietf.org >> > > > > > > >> > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www >> > > > > > > >> > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343= ea8 >> > > > > > > >> > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 >> > > > > > > >> > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%= 2B0 >> > > > > > > kvPZgr4o%3D&reserved=3D0 >> > > > > > >> > > > > > -- >> > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> > > > > > Fax: +49 421 200 3103 < >> > > > > > >> > > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= jacobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f= 8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&s= data=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 >> > > > > > > >> > > > > > >> > > > > > _______________________________________________ >> > > > > > netconf mailing list >> > > > > > netconf@ietf.org >> > > > > > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >> > > > > > ietf.org >> %2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8d1 >> > > > > > >> cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C >> > > > > > >> 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kvPZ >> > > > > > gr4o%3D&reserved=3D0 >> > > > > >> > > > > -- >> > > > > Ladislav Lhotka >> > > > > Head, CZ.NIC Labs >> > > > > PGP Key ID: 0xB8F92B08A9F76C67 >> > > > >> > > > >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Mar 28 03:03:48 2019 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 54A8F120331; Thu, 28 Mar 2019 03:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG-bQeT3VQjO; Thu, 28 Mar 2019 03:03:24 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 12E6D120480; Thu, 28 Mar 2019 03:03:24 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 6042118204C5; Thu, 28 Mar 2019 11:02:47 +0100 (CET) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id C0F501820047; Thu, 28 Mar 2019 11:02:42 +0100 (CET) From: Ladislav Lhotka To: Michel Veillette , Juergen Schoenwaelder Cc: Carsten Bormann , "netconf\@ietf.org" , "core\@ietf.org" In-Reply-To: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> Date: Thu, 28 Mar 2019 11:03:17 +0100 Message-ID: <87k1gjmi3e.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 10:03:34 -0000 Hi Michel, string tags look like a more robust solution than numeric member positions. It would be better though to have them as a built-in statement, or at least a "critical" extension. Lada Michel Veillette writes: > Hi Juergen > > You will find in attachment the updated version of 'test-union@2019-03-25= .yang' based on your proposed solution, type tagging. > This module defines an extension called union-tag as follow: > > extension union-tag { > argument tag { > yin-element true; > } > description > "In some cases, the interpretation of a value of a union type can d= iffer > when encoded using the different data format. This difference comes= from > the level of type information supported by the different data forma= ts. > In the case of XML, all elements and attributes are encoded as stri= ng > and no type information are included. JSON supports string, number = and > boolean. Finally, CBOR supports all YANG basic types. > > This extension can be used to add a tag to a type within a union to > guarantee its proper interpretation when decoded."; > } > > This extension can be used as follow: > > leaf multiple-enumerations-test-2 { > type union { > type enumeration { > ext:union-tag weekdays; > enum "Monday"; > enum "Tuesday"; > enum "Wednesday"; > enum "Thursday"; > enum "Friday"; > } > type enumeration { > ext:union-tag weekend; > enum "Saturday"; > enum "Sunday"; > } > } > } > > If I assume this solution or similar solution is implemented, the next qu= estion is how this tag is encoded in CBOR. > Let assume that the data node SID is 1820 and the SID assigned to "weekda= ys" tag is 1821. > > When set to "Tuesday", this data node can be encoded using a CBOR map as = follows: > > { > 1820 : { "weekdays", 1} > } > > Do we need to add a CBOR tag to this encoding to specify the use of a uni= on tag? (99 in this example) > I personally don't think so since the use of a CBOR map for a union data = node is not currently possible. > > { > 1820 : (99) { "weekdays", 1} > } > > Should we use a SID instead of the tag?=20 > > { > 1820 : { 1821, 1} > } > > Should we use a delta between the data node SID and the union tag SID? > The drawback of this approach is that the same value assigned to differen= t data nodes is encoded differently. > I won't personally recommend this approach. > > { > 1820 : { 1, 1} > } > > I hope this email will help moving the discussion closer to the final sol= ution. > > Please comments > Michel > > -----Original Message----- > From: Juergen Schoenwaelder =20 > Sent: Wednesday, March 27, 2019 2:17 AM > To: Michel Veillette > Cc: Ladislav Lhotka ; Carsten Bormann ; netc= onf@ietf.org; core@ietf.org > Subject: Re: [netconf] YANG encoding in CBOR > > Hi, > > a union can be formed by using member types that are imported and not und= er change control of a single author/organization and ideally this should w= ork without complex coordination of name and number spaces. > Duplicate enum/bits values are legal in YANG today so an encoding has to = deal with this aspect of life. > > A robust fix to all these problems will be to tag the type members in ord= er to discriminate the values in the encodings. This, however, will take so= me time to specify and we will need to preserve backwards compatibility wit= h unions without a tag (but compilers can encourage people to add tags when= ever modules are updated). > > /js > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: >> Hi Ladislav >>=20 >> If I summarize this issue of multiple enumerations or bits in a union, t= his problem can be solve by the following approaches: >>=20 >> - To not allows these duplicate values or positions to happen in YANG >> - To encode enumerations and bits as string (in all unions or only=20 >> when multiple enumerations or bits are defined) >> - To encode enumerations and bits as SID (in all unions or only when=20 >> multiple enumerations or bits are defined) >> - To encode enumerations and bits as delta between the value SID and=20 >> the leaf SID (in all unions or only when multiple enumerations or bits=20 >> are defined) >>=20 >> In this email, I will like to focus on the first option, fixing the prob= lem directly in YANG instead of fixing the consequences. >>=20 >> Without any changes in YANG, a union with multiple enumeration or bits c= an be constructed without value or position overlaps. >> For example: >>=20 >> leaf multiple-enumerations-test-1 { >> type union { >> type enumeration { >> enum "Monday" { value 0; } >> enum "Tuesday" { value 1; } >> enum "Wednesday" { value 2; } >> enum "Thursday" { value 3; } >> enum "Friday" { value 4; } >>=20 >> } >> type enumeration { >> enum "Saturday" { value 5; } >> enum "Sunday" { value 6; } >> } >> } >> } >>=20 >> leaf multiple-bits-test-1 { >> type union { >> type bits { >> bit "Monday" { position 0; } >> bit "Tuesday" { position 1; } >> bit "Wednesday" { position 2; } >> bit "Thursday" { position 3; } >> bit "Friday" { position 4; } >>=20 >> } >> type bits { >> bit "Saturday" { position 5; } >> bit "Sunday" { position 6; } >> } >> } >> } >>=20 >> When using already defined typedef, avoiding overlap is less obvious wit= hout some help. >> To help building unions with already defined typedefs, I propose to intr= oduce two extensions.=20 >>=20 >> extension value-offset { >> argument offset { >> yin-element true; >> } >> description >> "Offset added to each enum value of the associated enumeration."; >> } >>=20=20=20 >> extension position-offset { >> argument offset { >> yin-element true; >> } >> description >> "Offset value added to each bit position of the associated bits."; >> } >>=20 >> The value-offset extension can be used as follow: >>=20 >> type enumeration { >> enum "Monday"; >> enum "Tuesday"; >> enum "Wednesday"; >> enum "Thursday"; >> enum "Friday"; >> } >> } >>=20 >> typedef weekend { >> type enumeration { >> enum "Saturday"; >> enum "Sunday"; >> } >> } >>=20=20=20 >> leaf multiple-enumerations-test-3 { >> type union { >> type weekdays; >> type weekend { >> ext:value-offset 5; >> } >> } >> } >>=20 >> The position-offset extension can be used as follow: >>=20 >> typedef weekdays-flags { >> type bits { >> bit "Monday"; >> bit "Tuesday"; >> bit "Wednesday"; >> bit "Thursday"; >> bit "Friday"; >> } >> } >>=20 >> typedef weekend-flags { >> type bits { >> bit "Saturday"; >> bit "Sunday"; >> } >> } >>=20=20=20 >> leaf multiple-bits-test-3 { >> type union { >> type weekdays-flags; >> type weekend-flags { >> ext:position-offset 5; >> } >> } >> } >>=20 >> The yang file in attachment show different examples based on this approa= ch. >> This module have been validated using=20 >> https://can01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.y >> angvalidator.com%2Fvalidator&data=3D02%7C01%7C%7Cc69426dcaaf8448e1d4 >> 708d6b27bc735%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C63689264207 >> 3257660&sdata=3DXqo40lzBjINVFZhIZZI1LEktAdq5mee2AdxeYqefnsA%3D&r >> eserved=3D0 If this approach is accepted, tools like pyang should be=20 >> updated to produce an error if multiple enumerations or bits are defined= with value or position overleaps. >>=20 >> Please comment, >> Michel >>=20 >> -----Original Message----- >> From: Ladislav Lhotka >> Sent: Monday, March 25, 2019 4:07 AM >> To: Juergen Schoenwaelder ;=20 >> Carsten Bormann >> Cc: Michel Veillette ;=20 >> netconf@ietf.org; core@ietf.org >> Subject: Re: [netconf] YANG encoding in CBOR >>=20 >> Juergen Schoenwaelder writes: >>=20 >> > I think we need to look at the whole picture and in which direction=20 >> > we want to go. In the longer term, I would prefer a solution where=20 >> > the values of a union are discriminated. The current XML encoding=20 >> > behaviour of 'first match wins' is fragile (for example, if someone=20 >> > adds an enum to a type, the interpretation of data can change). >> > >> > Look at this: >> > >> > typedef bar { >> > type union { >> > type enumeration { enum "1"; value 2; enum "2"; value 1; } >> > type uint8; >> > } >> > } >> > >> > We have some encodings that send the string representations of the=20 >> > values and some encodings that prefer to send numeric=20 >> > representations where possible. In order to have a robust solution,=20 >> > encodings should likely indicate to which type the value belongs. >>=20 >> Perhaps the easiest way would be to use (optional) annotation that speci= fies, using an ordinal number, which of the member types is used for the pa= rticular instance. But since there can be unions inside unions, a list of n= umbers would be needed in general. >>=20 >> Lada >>=20 >> > >> > /js >> > >> > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> >> Well, if that is a problem, we can go for a longer representation wit= hin unions (section 6.12). Theoretically, we could do that only of there i= s more than one enum in the union type (so things stay efficient if there i= s only one), but that might pose difficulties with model evolution. >> >>=20 >> >> Going for a string representation repeats the feature of XML YANG (wh= ich was ported over to JSON YANG): >> >>=20 >> >> typedef foo { >> >> type union { >> >> type enumeration { >> >> enum red { value 1; } >> >> enum breen { value 2; } >> >> enum glue { value 3; } >> >> } >> >> type enumeration { >> >> enum tacks { value 1; } >> >> enum nails { value 2; } >> >> enum glue { value 3; } >> >> } >> >> } >> >> } >> >>=20 >> >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of th= e enumerations are being used. >> >>=20 >> >> Using SIDs, we can do better. >> >>=20 >> >> So what do we have to do to get the SID tool to allocate SIDs for enu= m values? >> >>=20 >> >> We could then define the CBOR tag for enums in unions to take the usu= al SID difference (delta relative to the environment, I=E2=80=99d think), n= ot an integer value. >> >>=20 >> >> Several of us are at the hackathon and could make something happen to= day and tomorrow. >> >>=20 >> >> Gr=C3=BC=C3=9Fe, Carsten >> >>=20 >> >>=20 >> >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: >> >> >=20 >> >> > I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. >> >> >=20 >> >> > E.g. if someone switched from XML to CBOR, suddenly the configurati= on or state data may have a different meaning. >> >> >=20 >> >> > Thanks, >> >> > Rob >> >> >=20 >> >> >=20 >> >> >> -----Original Message----- >> >> >> From: Carsten Bormann >> >> >> Sent: 22 March 2019 16:08 >> >> >> To: Michel Veillette >> >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 >> >> >> netconf@ietf.org >> >> >> Subject: Re: [netconf] YANG encoding in CBOR >> >> >>=20 >> >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 >> >> >> >> >> >> wrote: >> >> >>>=20 >> >> >>> The only potential problem I aware is when multiple=20 >> >> >>> enumerations are part of >> >> >> the same union. >> >> >>> Value 4 from enumeration A will be encoded the same way as=20 >> >> >>> Value >> >> >>> 4 from >> >> >> enumeration B. >> >> >>=20 >> >> >> =E2=80=A6 and that is not a problem for the XML version, because t= he=20 >> >> >> string is being used instead of the value. (But then if two=20 >> >> >> enumerations share a string, you have the equivalent problem in=20 >> >> >> the XML serialization.) >> >> >>=20 >> >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that act= ually=20 >> >> >> has this problem, so I would be a bit reluctant to make=20 >> >> >> CBOR-based implementations more complex (and less efficient) so so= lve this (non-?)problem. >> >> >>=20 >> >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> >=20 >> >> >=20 >> >> >=20 >> >>=20 >> >> _______________________________________________ >> >> netconf mailing list >> >> netconf@ietf.org >> >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw >> >> ww >> >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343e >> >> a8 >> >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7 >> >> C1 >> >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2 >> >> B0 >> >> kvPZgr4o%3D&reserved=3D0 >> > >> > --=20 >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 >> > >> > >> > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> >> Well, if that is a problem, we can go for a longer representation wit= hin unions (section 6.12). Theoretically, we could do that only of there i= s more than one enum in the union type (so things stay efficient if there i= s only one), but that might pose difficulties with model evolution. >> >>=20 >> >> Going for a string representation repeats the feature of XML YANG (wh= ich was ported over to JSON YANG): >> >>=20 >> >> typedef foo { >> >> type union { >> >> type enumeration { >> >> enum red { value 1; } >> >> enum breen { value 2; } >> >> enum glue { value 3; } >> >> } >> >> type enumeration { >> >> enum tacks { value 1; } >> >> enum nails { value 2; } >> >> enum glue { value 3; } >> >> } >> >> } >> >> } >> >>=20 >> >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of th= e enumerations are being used. >> >>=20 >> >> Using SIDs, we can do better. >> >>=20 >> >> So what do we have to do to get the SID tool to allocate SIDs for enu= m values? >> >>=20 >> >> We could then define the CBOR tag for enums in unions to take the usu= al SID difference (delta relative to the environment, I=E2=80=99d think), n= ot an integer value. >> >>=20 >> >> Several of us are at the hackathon and could make something happen to= day and tomorrow. >> >>=20 >> >> Gr=C3=BC=C3=9Fe, Carsten >> >>=20 >> >>=20 >> >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: >> >> >=20 >> >> > I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. >> >> >=20 >> >> > E.g. if someone switched from XML to CBOR, suddenly the configurati= on or state data may have a different meaning. >> >> >=20 >> >> > Thanks, >> >> > Rob >> >> >=20 >> >> >=20 >> >> >> -----Original Message----- >> >> >> From: Carsten Bormann >> >> >> Sent: 22 March 2019 16:08 >> >> >> To: Michel Veillette >> >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 >> >> >> netconf@ietf.org >> >> >> Subject: Re: [netconf] YANG encoding in CBOR >> >> >>=20 >> >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 >> >> >> >> >> >> wrote: >> >> >>>=20 >> >> >>> The only potential problem I aware is when multiple=20 >> >> >>> enumerations are part of >> >> >> the same union. >> >> >>> Value 4 from enumeration A will be encoded the same way as=20 >> >> >>> Value >> >> >>> 4 from >> >> >> enumeration B. >> >> >>=20 >> >> >> =E2=80=A6 and that is not a problem for the XML version, because t= he=20 >> >> >> string is being used instead of the value. (But then if two=20 >> >> >> enumerations share a string, you have the equivalent problem in=20 >> >> >> the XML serialization.) >> >> >>=20 >> >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that act= ually=20 >> >> >> has this problem, so I would be a bit reluctant to make=20 >> >> >> CBOR-based implementations more complex (and less efficient) so so= lve this (non-?)problem. >> >> >>=20 >> >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> >=20 >> >> >=20 >> >> >=20 >> >>=20 >> >> _______________________________________________ >> >> netconf mailing list >> >> netconf@ietf.org >> >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw >> >> ww >> >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343e >> >> a8 >> >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7 >> >> C1 >> >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2 >> >> B0 >> >> kvPZgr4o%3D&reserved=3D0 >> > >> > --=20 >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 >> > >> > _______________________________________________ >> > netconf mailing list >> > netconf@ietf.org >> > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w. >> > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8 >> > d1=20 >> > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1% >> > 7C=20 >> > 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kv >> > PZ >> > gr4o%3D&reserved=3D0 >>=20 >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 > > > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Mar 28 04:31:50 2019 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 2D295120495; Thu, 28 Mar 2019 04:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rJxszafERvZG; Thu, 28 Mar 2019 04:31:27 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0861206AB; Thu, 28 Mar 2019 04:30:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 80A7DB23; Thu, 28 Mar 2019 12:30:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Q85Wbd4PVdug; Thu, 28 Mar 2019 12:30:21 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Mar 2019 12:30:21 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 689EF200A8; Thu, 28 Mar 2019 12:30:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id yvUdl8jHnP1E; Thu, 28 Mar 2019 12:30:20 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 293A4200A7; Thu, 28 Mar 2019 12:30:20 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 28 Mar 2019 12:30:19 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 14C283007A0795; Thu, 28 Mar 2019 12:30:18 +0100 (CET) Date: Thu, 28 Mar 2019 12:30:18 +0100 From: Juergen Schoenwaelder To: Michel Veillette CC: Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michel Veillette , Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 11:31:41 -0000 Michel, I think the YANG part of the problem needs to be resolved as part of the yang next effort. We now have an issue for it so this will not get lost. YANG extensions have their limits; you can not expect that client and server both understand an extension and hence it is a stretch to make the encoding of data depending on tags provided by extensions. So what we need is: a) A CBOR encoding that works with the current YANG rules (even if it may be less efficient CBOR). b) Work on a general solution for tagged unions as part of the YANG next effort. c) Eventually update the XML,JSON,CBOR encodings such that tagged unions are handled properly. Assuming you won't be willing to wait for b), you have to define something that works reasonably with YANG 1.1 (task a) and get prepared to update the CBOR encoding when the YANG next effort has settled on a solution (task c). /js On Wed, Mar 27, 2019 at 04:00:42PM +0000, Michel Veillette wrote: > Hi Juergen >=20 > You will find in attachment the updated version of 'test-union@2019-03-= 25.yang' based on your proposed solution, type tagging. > This module defines an extension called union-tag as follow: >=20 > extension union-tag { > argument tag { > yin-element true; > } > description > "In some cases, the interpretation of a value of a union type can= differ > when encoded using the different data format. This difference com= es from > the level of type information supported by the different data for= mats. > In the case of XML, all elements and attributes are encoded as st= ring > and no type information are included. JSON supports string, numbe= r and > boolean. Finally, CBOR supports all YANG basic types. >=20 > This extension can be used to add a tag to a type within a union = to > guarantee its proper interpretation when decoded."; > } >=20 > This extension can be used as follow: >=20 > leaf multiple-enumerations-test-2 { > type union { > type enumeration { > ext:union-tag weekdays; > enum "Monday"; > enum "Tuesday"; > enum "Wednesday"; > enum "Thursday"; > enum "Friday"; > } > type enumeration { > ext:union-tag weekend; > enum "Saturday"; > enum "Sunday"; > } > } > } >=20 > If I assume this solution or similar solution is implemented, the next = question is how this tag is encoded in CBOR. > Let assume that the data node SID is 1820 and the SID assigned to "week= days" tag is 1821. >=20 > When set to "Tuesday", this data node can be encoded using a CBOR map a= s follows: >=20 > { > 1820 : { "weekdays", 1} > } >=20 > Do we need to add a CBOR tag to this encoding to specify the use of a u= nion tag? (99 in this example) > I personally don't think so since the use of a CBOR map for a union dat= a node is not currently possible. >=20 > { > 1820 : (99) { "weekdays", 1} > } >=20 > Should we use a SID instead of the tag?=20 >=20 > { > 1820 : { 1821, 1} > } >=20 > Should we use a delta between the data node SID and the union tag SID? > The drawback of this approach is that the same value assigned to differ= ent data nodes is encoded differently. > I won't personally recommend this approach. >=20 > { > 1820 : { 1, 1} > } >=20 > I hope this email will help moving the discussion closer to the final s= olution. >=20 > Please comments > Michel >=20 > -----Original Message----- > From: Juergen Schoenwaelder =20 > Sent: Wednesday, March 27, 2019 2:17 AM > To: Michel Veillette > Cc: Ladislav Lhotka ; Carsten Bormann ; ne= tconf@ietf.org; core@ietf.org > Subject: Re: [netconf] YANG encoding in CBOR >=20 > Hi, >=20 > a union can be formed by using member types that are imported and not u= nder change control of a single author/organization and ideally this shou= ld work without complex coordination of name and number spaces. > Duplicate enum/bits values are legal in YANG today so an encoding has t= o deal with this aspect of life. >=20 > A robust fix to all these problems will be to tag the type members in o= rder to discriminate the values in the encodings. This, however, will tak= e some time to specify and we will need to preserve backwards compatibili= ty with unions without a tag (but compilers can encourage people to add t= ags whenever modules are updated). >=20 > /js >=20 > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > > Hi Ladislav > >=20 > > If I summarize this issue of multiple enumerations or bits in a union= , this problem can be solve by the following approaches: > >=20 > > - To not allows these duplicate values or positions to happen in YANG > > - To encode enumerations and bits as string (in all unions or only=20 > > when multiple enumerations or bits are defined) > > - To encode enumerations and bits as SID (in all unions or only when=20 > > multiple enumerations or bits are defined) > > - To encode enumerations and bits as delta between the value SID and=20 > > the leaf SID (in all unions or only when multiple enumerations or bit= s=20 > > are defined) > >=20 > > In this email, I will like to focus on the first option, fixing the p= roblem directly in YANG instead of fixing the consequences. > >=20 > > Without any changes in YANG, a union with multiple enumeration or bit= s can be constructed without value or position overlaps. > > For example: > >=20 > > leaf multiple-enumerations-test-1 { > > type union { > > type enumeration { > > enum "Monday" { value 0; } > > enum "Tuesday" { value 1; } > > enum "Wednesday" { value 2; } > > enum "Thursday" { value 3; } > > enum "Friday" { value 4; } > >=20 > > } > > type enumeration { > > enum "Saturday" { value 5; } > > enum "Sunday" { value 6; } > > } > > } > > } > >=20 > > leaf multiple-bits-test-1 { > > type union { > > type bits { > > bit "Monday" { position 0; } > > bit "Tuesday" { position 1; } > > bit "Wednesday" { position 2; } > > bit "Thursday" { position 3; } > > bit "Friday" { position 4; } > >=20 > > } > > type bits { > > bit "Saturday" { position 5; } > > bit "Sunday" { position 6; } > > } > > } > > } > >=20 > > When using already defined typedef, avoiding overlap is less obvious = without some help. > > To help building unions with already defined typedefs, I propose to i= ntroduce two extensions.=20 > >=20 > > extension value-offset { > > argument offset { > > yin-element true; > > } > > description > > "Offset added to each enum value of the associated enumeration.= "; > > } > > =20 > > extension position-offset { > > argument offset { > > yin-element true; > > } > > description > > "Offset value added to each bit position of the associated bits= ."; > > } > >=20 > > The value-offset extension can be used as follow: > >=20 > > type enumeration { > > enum "Monday"; > > enum "Tuesday"; > > enum "Wednesday"; > > enum "Thursday"; > > enum "Friday"; > > } > > } > >=20 > > typedef weekend { > > type enumeration { > > enum "Saturday"; > > enum "Sunday"; > > } > > } > > =20 > > leaf multiple-enumerations-test-3 { > > type union { > > type weekdays; > > type weekend { > > ext:value-offset 5; > > } > > } > > } > >=20 > > The position-offset extension can be used as follow: > >=20 > > typedef weekdays-flags { > > type bits { > > bit "Monday"; > > bit "Tuesday"; > > bit "Wednesday"; > > bit "Thursday"; > > bit "Friday"; > > } > > } > >=20 > > typedef weekend-flags { > > type bits { > > bit "Saturday"; > > bit "Sunday"; > > } > > } > > =20 > > leaf multiple-bits-test-3 { > > type union { > > type weekdays-flags; > > type weekend-flags { > > ext:position-offset 5; > > } > > } > > } > >=20 > > The yang file in attachment show different examples based on this app= roach. > > This module have been validated using=20 > > https://can01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fww= w.y > > angvalidator.com%2Fvalidator&data=3D02%7C01%7C%7Cc69426dcaaf8448e= 1d4 > > 708d6b27bc735%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C6368926420= 7 > > 3257660&sdata=3DXqo40lzBjINVFZhIZZI1LEktAdq5mee2AdxeYqefnsA%3D&am= p;r > > eserved=3D0 If this approach is accepted, tools like pyang should be=20 > > updated to produce an error if multiple enumerations or bits are defi= ned with value or position overleaps. > >=20 > > Please comment, > > Michel > >=20 > > -----Original Message----- > > From: Ladislav Lhotka > > Sent: Monday, March 25, 2019 4:07 AM > > To: Juergen Schoenwaelder ;=20 > > Carsten Bormann > > Cc: Michel Veillette ;=20 > > netconf@ietf.org; core@ietf.org > > Subject: Re: [netconf] YANG encoding in CBOR > >=20 > > Juergen Schoenwaelder writes: > >=20 > > > I think we need to look at the whole picture and in which direction= =20 > > > we want to go. In the longer term, I would prefer a solution where=20 > > > the values of a union are discriminated. The current XML encoding=20 > > > behaviour of 'first match wins' is fragile (for example, if someone= =20 > > > adds an enum to a type, the interpretation of data can change). > > > > > > Look at this: > > > > > > typedef bar { > > > type union { > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > > type uint8; > > > } > > > } > > > > > > We have some encodings that send the string representations of the=20 > > > values and some encodings that prefer to send numeric=20 > > > representations where possible. In order to have a robust solution,= =20 > > > encodings should likely indicate to which type the value belongs. > >=20 > > Perhaps the easiest way would be to use (optional) annotation that sp= ecifies, using an ordinal number, which of the member types is used for t= he particular instance. But since there can be unions inside unions, a li= st of numbers would be needed in general. > >=20 > > Lada > >=20 > > > > > > /js > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > >> Well, if that is a problem, we can go for a longer representation = within unions (section 6.12). Theoretically, we could do that only of th= ere is more than one enum in the union type (so things stay efficient if = there is only one), but that might pose difficulties with model evolution= . > > >>=20 > > >> Going for a string representation repeats the feature of XML YANG = (which was ported over to JSON YANG): > > >>=20 > > >> typedef foo { > > >> type union { > > >> type enumeration { > > >> enum red { value 1; } > > >> enum breen { value 2; } > > >> enum glue { value 3; } > > >> } > > >> type enumeration { > > >> enum tacks { value 1; } > > >> enum nails { value 2; } > > >> enum glue { value 3; } > > >> } > > >> } > > >> } > > >>=20 > > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of= the enumerations are being used. > > >>=20 > > >> Using SIDs, we can do better. > > >>=20 > > >> So what do we have to do to get the SID tool to allocate SIDs for = enum values? > > >>=20 > > >> We could then define the CBOR tag for enums in unions to take the = usual SID difference (delta relative to the environment, I=E2=80=99d thin= k), not an integer value. > > >>=20 > > >> Several of us are at the hackathon and could make something happen= today and tomorrow. > > >>=20 > > >> Gr=C3=BC=C3=9Fe, Carsten > > >>=20 > > >>=20 > > >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wrote: > > >> >=20 > > >> > I guess that the concern is that this introduces more variation = in how data is interpreted between the different XML/JSON/CBOR encodings. > > >> >=20 > > >> > E.g. if someone switched from XML to CBOR, suddenly the configur= ation or state data may have a different meaning. > > >> >=20 > > >> > Thanks, > > >> > Rob > > >> >=20 > > >> >=20 > > >> >> -----Original Message----- > > >> >> From: Carsten Bormann > > >> >> Sent: 22 March 2019 16:08 > > >> >> To: Michel Veillette > > >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 > > >> >> netconf@ietf.org > > >> >> Subject: Re: [netconf] YANG encoding in CBOR > > >> >>=20 > > >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 > > >> >> > > >> >> wrote: > > >> >>>=20 > > >> >>> The only potential problem I aware is when multiple=20 > > >> >>> enumerations are part of > > >> >> the same union. > > >> >>> Value 4 from enumeration A will be encoded the same way as=20 > > >> >>> Value > > >> >>> 4 from > > >> >> enumeration B. > > >> >>=20 > > >> >> =E2=80=A6 and that is not a problem for the XML version, becaus= e the=20 > > >> >> string is being used instead of the value. (But then if two=20 > > >> >> enumerations share a string, you have the equivalent problem in= =20 > > >> >> the XML serialization.) > > >> >>=20 > > >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that = actually=20 > > >> >> has this problem, so I would be a bit reluctant to make=20 > > >> >> CBOR-based implementations more complex (and less efficient) so= solve this (non-?)problem. > > >> >>=20 > > >> >> Gr=C3=BC=C3=9Fe, Carsten > > >> >=20 > > >> >=20 > > >> >=20 > > >>=20 > > >> _______________________________________________ > > >> netconf mailing list > > >> netconf@ietf.org > > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fw > > >> ww > > >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C3= 43e > > >> a8 > > >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%= 7 > > >> C1 > > >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaO= b%2 > > >> B0 > > >> kvPZgr4o%3D&reserved=3D0 > > > > > > --=20 > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germ= any > > > Fax: +49 421 200 3103 > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > >> Well, if that is a problem, we can go for a longer representation = within unions (section 6.12). Theoretically, we could do that only of th= ere is more than one enum in the union type (so things stay efficient if = there is only one), but that might pose difficulties with model evolution= . > > >>=20 > > >> Going for a string representation repeats the feature of XML YANG = (which was ported over to JSON YANG): > > >>=20 > > >> typedef foo { > > >> type union { > > >> type enumeration { > > >> enum red { value 1; } > > >> enum breen { value 2; } > > >> enum glue { value 3; } > > >> } > > >> type enumeration { > > >> enum tacks { value 1; } > > >> enum nails { value 2; } > > >> enum glue { value 3; } > > >> } > > >> } > > >> } > > >>=20 > > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of= the enumerations are being used. > > >>=20 > > >> Using SIDs, we can do better. > > >>=20 > > >> So what do we have to do to get the SID tool to allocate SIDs for = enum values? > > >>=20 > > >> We could then define the CBOR tag for enums in unions to take the = usual SID difference (delta relative to the environment, I=E2=80=99d thin= k), not an integer value. > > >>=20 > > >> Several of us are at the hackathon and could make something happen= today and tomorrow. > > >>=20 > > >> Gr=C3=BC=C3=9Fe, Carsten > > >>=20 > > >>=20 > > >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wrote: > > >> >=20 > > >> > I guess that the concern is that this introduces more variation = in how data is interpreted between the different XML/JSON/CBOR encodings. > > >> >=20 > > >> > E.g. if someone switched from XML to CBOR, suddenly the configur= ation or state data may have a different meaning. > > >> >=20 > > >> > Thanks, > > >> > Rob > > >> >=20 > > >> >=20 > > >> >> -----Original Message----- > > >> >> From: Carsten Bormann > > >> >> Sent: 22 March 2019 16:08 > > >> >> To: Michel Veillette > > >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 > > >> >> netconf@ietf.org > > >> >> Subject: Re: [netconf] YANG encoding in CBOR > > >> >>=20 > > >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 > > >> >> > > >> >> wrote: > > >> >>>=20 > > >> >>> The only potential problem I aware is when multiple=20 > > >> >>> enumerations are part of > > >> >> the same union. > > >> >>> Value 4 from enumeration A will be encoded the same way as=20 > > >> >>> Value > > >> >>> 4 from > > >> >> enumeration B. > > >> >>=20 > > >> >> =E2=80=A6 and that is not a problem for the XML version, becaus= e the=20 > > >> >> string is being used instead of the value. (But then if two=20 > > >> >> enumerations share a string, you have the equivalent problem in= =20 > > >> >> the XML serialization.) > > >> >>=20 > > >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that = actually=20 > > >> >> has this problem, so I would be a bit reluctant to make=20 > > >> >> CBOR-based implementations more complex (and less efficient) so= solve this (non-?)problem. > > >> >>=20 > > >> >> Gr=C3=BC=C3=9Fe, Carsten > > >> >=20 > > >> >=20 > > >> >=20 > > >>=20 > > >> _______________________________________________ > > >> netconf mailing list > > >> netconf@ietf.org > > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fw > > >> ww > > >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C3= 43e > > >> a8 > > >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%= 7 > > >> C1 > > >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaO= b%2 > > >> B0 > > >> kvPZgr4o%3D&reserved=3D0 > > > > > > --=20 > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germ= any > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww. > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343= ea8 > > > d1=20 > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1= % > > > 7C=20 > > > 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B= 0kv > > > PZ > > > gr4o%3D&reserved=3D0 > >=20 > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 >=20 >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 28 06:47:13 2019 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 0730A1204AF; Thu, 28 Mar 2019 06:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwC5fswHYFrN; Thu, 28 Mar 2019 06:46:56 -0700 (PDT) Received: from smtp.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 DCC801204AA; Thu, 28 Mar 2019 06:46:55 -0700 (PDT) Received: from client-0188.vpn.uni-bremen.de (client-0188.vpn.uni-bremen.de [134.102.107.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44VR4F2G0lzybw; Thu, 28 Mar 2019 14:46:53 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> Date: Thu, 28 Mar 2019 14:46:52 +0100 Cc: Michel Veillette , Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575473610.430299-1be8c2a53aee320582306091876de64f Content-Transfer-Encoding: quoted-printable Message-Id: <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 13:47:06 -0000 So for enum/bits we are back to value outside, string inside union? Can we use SIDs instead of the strings for the latter? This can=E2=80=99t be much more complicated than assigning a SID to each = string that occurs in an enum/bits in a union. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 28 07:06:35 2019 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 0CAD7120318; Thu, 28 Mar 2019 07:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObMS8pxHtdcC; Thu, 28 Mar 2019 07:06:21 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800101.outbound.protection.outlook.com [40.107.80.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E50B120274; Thu, 28 Mar 2019 07:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2kiZbIVUZWwTFQNkbiDo10EzVN4UyN8cz1gP3vevvDM=; b=ee4KIKlE5VCECLiqskW+Poru78SjFKyn775DoUVchBL29bG1+DYNbVTqJPLLSFfx/JKZbxDTfLyENUPfSnbRQz5y09+WO47mGX6ENmPYj04lZOyNNMEdv8hCGbPkHtYYyAp9tUqkj3HVq1Of/oS9QumHX3PDh/N0LldQqi0SLAs= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4370.namprd06.prod.outlook.com (10.167.181.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Thu, 28 Mar 2019 14:06:17 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::6d4a:3963:7ffb:1f30]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::6d4a:3963:7ffb:1f30%2]) with mapi id 15.20.1750.017; Thu, 28 Mar 2019 14:06:17 +0000 From: Michel Veillette To: Carsten Bormann , Juergen Schoenwaelder CC: Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAL8XAAAAtt/gAAgmRkAAAJStYAAYEUIgABUqX2QAAwU1oAAE3mQoAApxZcAAATFAAAAAF65QA== Date: Thu, 28 Mar 2019 14:06:17 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> In-Reply-To: <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a02707fd-b61b-463f-9b29-08d6b3868c17 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4370; x-ms-traffictypediagnostic: BL0PR06MB4370: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(396003)(136003)(39840400004)(189003)(199004)(13464003)(7696005)(53546011)(99286004)(102836004)(2906002)(76176011)(6506007)(186003)(26005)(97736004)(446003)(11346002)(476003)(486006)(106356001)(105586002)(3846002)(478600001)(6116002)(72206003)(14454004)(53936002)(93886005)(86362001)(81166006)(81156014)(8676002)(74316002)(52536014)(7736002)(305945005)(229853002)(8936002)(6436002)(66066001)(110136005)(54906003)(25786009)(55016002)(68736007)(316002)(6306002)(9686003)(4326008)(5660300002)(6246003)(71190400001)(71200400001)(256004)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4370; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2P6tUx3NXX8VZ/OTL7Ty1GGsiiOR7BnnveggRF9Zr4G02NEnA1KFjAz4qTjyu4YNiwnLQbEoPxO2z+ulgsJGfvONqPX8ew5BweA5WyAnlkyfi77InuoUvxEW/rCMYf+qzCUnOX1TEiliBwEhxaaORRHmJRqdqWXCr4YPYVmwP9gyJtgUe1qefYGVeszmWgKSShFcKi0qIRR5LA4wTzIVcaq94OlQFIHhTrLFHK0hLtJrcRzaabt8fjQTtTX1fXjJCmxr/l9Nv3/AfNLu8t+vGpTqGzxUmnorUMpc6CSurbRQvAB7KhMKcXYfUEWd8UvxIScQ/SB6RgSpLe/ZwQ8R7lqREyMWRBli3Dy4Qy+NFxtkAaQUHxuXh4jp4v/kY45c6B9hnFfwD+BEeG+wdEsi4qS7/RY8aYjt+l+0CgE5Iww= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: a02707fd-b61b-463f-9b29-08d6b3868c17 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 14:06:17.5429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4370 Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 14:06:27 -0000 KzEgZm9yIHZhbHVlIG91dHNpZGUsIHN0cmluZyBpbnNpZGUgdW5pb24NCg0KTXkgcmF0aW9uYWw6 DQoNCi0gU0lEIGNhbiBoYXZlIHVwIHRvIDggYnl0ZXMgYW5kIHdpbGwgcHJvdmlkZSBhIG1hcmdp bmFsIGNvbXByZXNzaW9uLg0KLSBHZW5lcmF0aW5nIFNJRCBmb3IgYWxsICdlbnVtZXJhdGlvbicg YW5kICdiaXRzJyBpbiBjYXNlIHRoZXkgYXJlIHVzZWQgaW4gJ3VuaW9uJyBpcyBsb3Qgb2Ygb3Zl cmhlYWQgdG8gcmV2b2x2ZSBhIGNvcm5lciBjYXNlLg0KLSBZQU5HIGFsc28gc3VwcG9ydCB0aGUg J2Nob2ljZScgc3RhdGVtZW50IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNz ZWN0aW9uLTQuMi43KSB3aGljaCBpcyBzaW1pbGFyIHRvDQogICB0aGUgY29uY2VwdCBvZiB0eXBl IHRhZ2dpbmcgd2l0aGluIHVuaW9uLiBUaGlzIGNvbnN0cnVjdCBjYW4gYmUgdXNlZCBieSBZQU5H IG1vZHVsZXMgc3BlY2lmaWNhbGx5IGNyZWF0ZWQgZm9yDQogIGVtYmVkZGVkIGFwcGxpY2F0aW9u cyB0byB0YWtlIGFkdmFudGFnZSBvZiAnZW51bWVyYXRpb24nIGVuY29kZWQgYXMgdmFsdWUgYW5k ICdiaXRzJyBlbmNvZGVkIGFzIGJpdC4NCg0KTWljaGVsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPiANClNlbnQ6IFRo dXJzZGF5LCBNYXJjaCAyOCwgMjAxOSA5OjQ3IEFNDQpUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVy IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQpDYzogTWljaGVsIFZlaWxs ZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPjsgTGFkaXNsYXYgTGhvdGthIDxs aG90a2FAbmljLmN6PjsgbmV0Y29uZkBpZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGluIENCT1INCg0KU28gZm9yIGVudW0vYml0cyB3 ZSBhcmUgYmFjayB0byB2YWx1ZSBvdXRzaWRlLCBzdHJpbmcgaW5zaWRlIHVuaW9uPw0KQ2FuIHdl IHVzZSBTSURzIGluc3RlYWQgb2YgdGhlIHN0cmluZ3MgZm9yIHRoZSBsYXR0ZXI/DQpUaGlzIGNh buKAmXQgYmUgbXVjaCBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gYXNzaWduaW5nIGEgU0lEIHRvIGVh Y2ggc3RyaW5nIHRoYXQgb2NjdXJzIGluIGFuIGVudW0vYml0cyBpbiBhIHVuaW9uLg0KDQpHcsO8 w59lLCBDYXJzdGVuDQoNCg== From nobody Thu Mar 28 07:31:06 2019 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 595171204BB; Thu, 28 Mar 2019 07:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 lD_bQ5UP1GPW; Thu, 28 Mar 2019 07:30:39 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC8B1204D1; Thu, 28 Mar 2019 07:30:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9A977B23; Thu, 28 Mar 2019 15:30:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id zlVCyeSHjk3Z; Thu, 28 Mar 2019 15:30:33 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Mar 2019 15:30:33 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79C55200AC; Thu, 28 Mar 2019 15:30:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id u7ra-Qv1iXeU; Thu, 28 Mar 2019 15:30:33 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 2EDDC200A7; Thu, 28 Mar 2019 15:30:33 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 28 Mar 2019 15:30:32 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 41B6F3007A0C2A; Thu, 28 Mar 2019 15:30:32 +0100 (CET) Date: Thu, 28 Mar 2019 15:30:31 +0100 From: Juergen Schoenwaelder To: Michel Veillette CC: Carsten Bormann , Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190328143031.ho7nmhpg4jb373p7@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michel Veillette , Carsten Bormann , Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" References: <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 14:30:56 -0000 I agree with your points. It seems this is the best we can do right now and hopefully we can do better in the future. /js On Thu, Mar 28, 2019 at 02:06:17PM +0000, Michel Veillette wrote: > +1 for value outside, string inside union >=20 > My rational: >=20 > - SID can have up to 8 bytes and will provide a marginal compression. > - Generating SID for all 'enumeration' and 'bits' in case they are used= in 'union' is lot of overhead to revolve a corner case. > - YANG also support the 'choice' statement (https://tools.ietf.org/html= /rfc7950#section-4.2.7) which is similar to > the concept of type tagging within union. This construct can be used= by YANG modules specifically created for > embedded applications to take advantage of 'enumeration' encoded as v= alue and 'bits' encoded as bit. >=20 > Michel >=20 >=20 > -----Original Message----- > From: Carsten Bormann =20 > Sent: Thursday, March 28, 2019 9:47 AM > To: Juergen Schoenwaelder > Cc: Michel Veillette ; Ladislav Lhotka = ; netconf@ietf.org; core@ietf.org > Subject: Re: [netconf] YANG encoding in CBOR >=20 > So for enum/bits we are back to value outside, string inside union? > Can we use SIDs instead of the strings for the latter? > This can=E2=80=99t be much more complicated than assigning a SID to eac= h string that occurs in an enum/bits in a union. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 28 07:40:33 2019 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 43C04120494 for ; Thu, 28 Mar 2019 07:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 I4d1iD_KT_gF for ; Thu, 28 Mar 2019 07:40:19 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 B5B881202AC for ; Thu, 28 Mar 2019 07:40:18 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id p10so23253953wrq.1 for ; Thu, 28 Mar 2019 07:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SwjP9ELAmVPGfOjvjJcTg+zAXje9vGlU7RzYOrp8g1A=; b=OFENi4WB2FBdtDyU1keOe0mfCkfXBoTIsZwLjJ6E1w49nxaiX1MHmHLnDCLHnoSsD0 NVpROLZnkcHUfd9a6KB4VhKnqoU3lWVxjd2kpGEcRm/6Db5FLV5fpKck0ncEu8g+6dvB fd/dD7ZwypvhYZb3E31AA2Rq+uT39ieBNP8HdJdeR2lqcj3i8bZmaP01jSWu0YYDojuZ 6JbXrHCNe1EvsH9ot6f5GKc3bbIW8x+2J0kW2D0o8xeezQv1tnBQtL4YIMe+VL1CNKJK pNokMU/svCpU3o98nilTQVqvNVcqAq4R/T2lZghP/tpXPJXtvMUxDjOilp8xtwsCyOaI ispA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SwjP9ELAmVPGfOjvjJcTg+zAXje9vGlU7RzYOrp8g1A=; b=NskTP3f3XFOkYAol6uqJ/8szLyJIMUaU3ckbhH4CyJyqrbDZTqA3OlhxdP4yH4f8uU ejGYggIs+XcMCfx5gjtPgUFTB26fqsvEAhAbRh/ZJ9zBUvZthFkj2ZTpQGEwDgqqFaKR p2e6ohcwyOj3XVn8JO3U46O+nHMZ+HE0rH2+AXeQwXKe1NfA/yQlVa20ibRaNb1b53yk jXWZeQKx6HtEqejxIJcMCnTiJediLxqxh+rexiNSsF3Cu2KBrjwYqpgn2veM8kTyr7av /EMnW7lyRnJEKaA0jZutpwSy8rvaJGOwAtglGWvcEyCfgc/fB/75SUWeXXjZ6U0AucSC eKOw== X-Gm-Message-State: APjAAAUtwvxWuQwHUtG/pRIODIMmsAfEte6nIp96RH069+vVHbrOd8DG VUCBoTTheWEhBEk2/gvtmYYrkPcXl6XeKTF0als7wA== X-Google-Smtp-Source: APXvYqzynPH2NhkNOYS4t29EWjddpTPDZB8c0u9yNJ/hYXRs382jVnfpPepEItOexBYNATXKWcsagHCUjT9ImYcnusM= X-Received: by 2002:adf:b68d:: with SMTP id j13mr24358856wre.50.1553784017070; Thu, 28 Mar 2019 07:40:17 -0700 (PDT) MIME-Version: 1.0 References: <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> <20190328143031.ho7nmhpg4jb373p7@anna.jacobs.jacobs-university.de> In-Reply-To: <20190328143031.ho7nmhpg4jb373p7@anna.jacobs.jacobs-university.de> From: ivaylo petrov Date: Thu, 28 Mar 2019 15:39:50 +0100 Message-ID: To: Juergen Schoenwaelder , Michel Veillette , Carsten Bormann , Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000654178058528889f" Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 14:40:30 -0000 --000000000000654178058528889f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I also support value outside and string inside unions. Michel gave a rather good rationale why this is a good option and for me this seems as the best option available right now. Best regards, Ivaylo On Thu, Mar 28, 2019 at 3:32 PM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > I agree with your points. It seems this is the best we can do right > now and hopefully we can do better in the future. > > /js > > On Thu, Mar 28, 2019 at 02:06:17PM +0000, Michel Veillette wrote: > > +1 for value outside, string inside union > > > > My rational: > > > > - SID can have up to 8 bytes and will provide a marginal compression. > > - Generating SID for all 'enumeration' and 'bits' in case they are used > in 'union' is lot of overhead to revolve a corner case. > > - YANG also support the 'choice' statement ( > https://tools.ietf.org/html/rfc7950#section-4.2.7) which is similar to > > the concept of type tagging within union. This construct can be used > by YANG modules specifically created for > > embedded applications to take advantage of 'enumeration' encoded as > value and 'bits' encoded as bit. > > > > Michel > > > > > > -----Original Message----- > > From: Carsten Bormann > > Sent: Thursday, March 28, 2019 9:47 AM > > To: Juergen Schoenwaelder > > Cc: Michel Veillette ; Ladislav Lhotka = < > lhotka@nic.cz>; netconf@ietf.org; core@ietf.org > > Subject: Re: [netconf] YANG encoding in CBOR > > > > So for enum/bits we are back to value outside, string inside union? > > Can we use SIDs instead of the strings for the latter? > > This can=E2=80=99t be much more complicated than assigning a SID to eac= h string > that occurs in an enum/bits in a union. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000654178058528889f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I also su= pport value outside and string inside unions. Michel gave a rather good rat= ionale why this is a good option and for me this seems as the best option a= vailable right now.

Best regards,
Ivaylo

On Thu, Mar 28, 2019 at 3:32 PM Juergen Schoenwaelder <= ;j.schoenwaelder@ja= cobs-university.de> wrote:
I agree with your points. It seems this is the best we ca= n do right
now and hopefully we can do better in the future.

/js

On Thu, Mar 28, 2019 at 02:06:17PM +0000, Michel Veillette wrote:
> +1 for value outside, string inside union
>
> My rational:
>
> - SID can have up to 8 bytes and will provide a marginal compression.<= br> > - Generating SID for all 'enumeration' and 'bits' in c= ase they are used in 'union' is lot of overhead to revolve a corner= case.
> - YANG also support the 'choice' statement (https://tools.ietf.org/html/rfc7950#section-4.2.7) which is simil= ar to
>=C2=A0 =C2=A0 the concept of type tagging within union. This construct = can be used by YANG modules specifically created for
>=C2=A0 =C2=A0embedded applications to take advantage of 'enumeratio= n' encoded as value and 'bits' encoded as bit.
>
> Michel
>
>
> -----Original Message-----
> From: Carsten Bormann <cabo@tzi.org>
> Sent: Thursday, March 28, 2019 9:47 AM
> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&= gt;
> Cc: Michel Veillette <Michel.Veillette@trilliant.com>; Ladislav Lho= tka <lhotka@nic.cz>; netconf@ietf.o= rg; core@ietf.org
> Subject: Re: [netconf] YANG encoding in CBOR
>
> So for enum/bits we are back to value outside, string inside union? > Can we use SIDs instead of the strings for the latter?
> This can=E2=80=99t be much more complicated than assigning a SID to ea= ch string that occurs in an enum/bits in a union.
>
> Gr=C3=BC=C3=9Fe, Carsten
>

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

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000654178058528889f-- From nobody Thu Mar 28 08:51:01 2019 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 CC35D120309 for ; Thu, 28 Mar 2019 08:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvVaKZl2dv-m for ; Thu, 28 Mar 2019 08:50:48 -0700 (PDT) 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 A0387120270 for ; Thu, 28 Mar 2019 08:50:47 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id v22so18088111lje.9 for ; Thu, 28 Mar 2019 08:50:47 -0700 (PDT) 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=VBi5/65t6qirOCDG0oQiS2Vlet1D9L3yon1BaCSU56s=; b=e3DYuFI6VeYHH2OSyfFI9NBL6btTZJwfy6uq998x/CyLUMOKJcp1TEDGNI8NI6bTkB SNdaWPIKlTzJFAllJs6tOqOl4CT5U2toC1aGep8jAQTUmPkcYJoKeCkmIv7Q12CX5jXZ 1eybxGYumQrcZ7kWRR4VerRH4qPWPeKBsHX4vrOlofRwn/zpO3krzd/YceNfUHcUpcaZ EQDedpeG9aYFJ6V97i9roDhoM+L9XnExLmCvZOLqVIRL5uVmDptwN+ea0hKtgb/KiMbL 616nFZrYxikCJHdXvdBLYDUCQ1BnXTtEp3Q09CUeA/rBKTjxZcxqKgZ6baJAkXk1XoZj oQrg== 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=VBi5/65t6qirOCDG0oQiS2Vlet1D9L3yon1BaCSU56s=; b=j1J90jK2CVYaXZ883VYS95ggYtm9MnTa6xee9CNwZHQdinth0HUtH6SVbckThNhHDH 25L6YR2t/WRPO7MmFde8i9iS6HlagLwB3I6+X6wFFjXwlMZRvlOAUuO9iv5ZnmiHfosg Z7uTUgti59TTzB7+EHoBp+BUqw1SG3aI3E36VqWvMFcwLgRMBMOQkYv2wu4cR7a9XI2t ipy209u9hVNGiRvhI9sICh0qiQzQJT4tQg9Mhit3EMa/ZxxIIH3dwCcAIwT1WwItX0Ku OxCCSaGPEhpyXxt6Ki1hmovJONw5KEOWi2gwhzv0BAfj9Ti3UAgElbGIsgrXOA80bOQe 5ZIw== X-Gm-Message-State: APjAAAVH2AN1mQzjrme4S6YTGx9wNczjzwc1kYJiS5+q1uCs1erB/j/q HRb0BXgIt8xkpxNdD5LTH9/tfyMMg79aV0EEoCqesw== X-Google-Smtp-Source: APXvYqz9ioTdszjv1p3sR6NiPNMOd8FocSqCh6twmMD75nfYaf6FfNORIEwCP7VyKKqwoU5dHPqXutogWDKcTMzv/oI= X-Received: by 2002:a2e:9e4d:: with SMTP id g13mr10393892ljk.12.1553788245832; Thu, 28 Mar 2019 08:50:45 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> In-Reply-To: From: Andy Bierman Date: Thu, 28 Mar 2019 08:50:34 -0700 Message-ID: To: Michel Veillette Cc: Carsten Bormann , Juergen Schoenwaelder , "core@ietf.org" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="00000000000073086d058529847c" Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 15:50:54 -0000 --00000000000073086d058529847c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 28, 2019 at 7:06 AM Michel Veillette < Michel.Veillette@trilliant.com> wrote: > +1 for value outside, string inside union > > This is simple, but I was trying to support some very common types (like ip-address) that are unions of strings, and are desirable to send as binary instead of string representation. Andy My rational: > > - SID can have up to 8 bytes and will provide a marginal compression. > - Generating SID for all 'enumeration' and 'bits' in case they are used i= n > 'union' is lot of overhead to revolve a corner case. > - YANG also support the 'choice' statement ( > https://tools.ietf.org/html/rfc7950#section-4.2.7) which is similar to > the concept of type tagging within union. This construct can be used b= y > YANG modules specifically created for > embedded applications to take advantage of 'enumeration' encoded as > value and 'bits' encoded as bit. > > Michel > > > -----Original Message----- > From: Carsten Bormann > Sent: Thursday, March 28, 2019 9:47 AM > To: Juergen Schoenwaelder > Cc: Michel Veillette ; Ladislav Lhotka < > lhotka@nic.cz>; netconf@ietf.org; core@ietf.org > Subject: Re: [netconf] YANG encoding in CBOR > > So for enum/bits we are back to value outside, string inside union? > Can we use SIDs instead of the strings for the latter? > This can=E2=80=99t be much more complicated than assigning a SID to each = string > that occurs in an enum/bits in a union. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --00000000000073086d058529847c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 28, 2019 at 7:06 AM Miche= l Veillette <Michel.Ve= illette@trilliant.com> wrote:
+1 for value outside, string inside union


This is simple, but I was trying to su= pport some very common types (like ip-address)
that are unions of= strings, and are desirable to send as binary instead of string representat= ion.

Andy

My rational:

- SID can have up to 8 bytes and will provide a marginal compression.
- Generating SID for all 'enumeration' and 'bits' in case t= hey are used in 'union' is lot of overhead to revolve a corner case= .
- YANG also support the 'choice' statement (https://tools.ietf.org/html/rfc7950#section-4.2.7) which is similar to=
=C2=A0 =C2=A0the concept of type tagging within union. This construct can b= e used by YANG modules specifically created for
=C2=A0 embedded applications to take advantage of 'enumeration' enc= oded as value and 'bits' encoded as bit.

Michel


-----Original Message-----
From: Carsten Bormann <cabo@tzi.org>
Sent: Thursday, March 28, 2019 9:47 AM
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Cc: Michel Veillette <Michel.Veillette@trilliant.com>; Ladislav Lhotka &= lt;lhotka@nic.cz>= ; netconf@ietf.org; core@ietf.org
Subject: Re: [netconf] YANG encoding in CBOR

So for enum/bits we are back to value outside, string inside union?
Can we use SIDs instead of the strings for the latter?
This can=E2=80=99t be much more complicated than assigning a SID to each st= ring that occurs in an enum/bits in a union.

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

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--00000000000073086d058529847c-- From nobody Thu Mar 28 09:07:28 2019 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 E116C120096; Thu, 28 Mar 2019 09:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 JF2nKNAHHcfK; Thu, 28 Mar 2019 09:07:18 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF337120003; Thu, 28 Mar 2019 09:07:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 48B0340; Thu, 28 Mar 2019 17:07:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id EhkNaw8KA5qc; Thu, 28 Mar 2019 17:07:16 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Mar 2019 17:07:16 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 304B0200A8; Thu, 28 Mar 2019 17:07:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id fdp1hkBlsV4D; Thu, 28 Mar 2019 17:07:15 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id E7CE8200A7; Thu, 28 Mar 2019 17:07:15 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 28 Mar 2019 17:07:15 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 1816C3007A1080; Thu, 28 Mar 2019 17:07:14 +0100 (CET) Date: Thu, 28 Mar 2019 17:07:14 +0100 From: Juergen Schoenwaelder To: Andy Bierman CC: Michel Veillette , Carsten Bormann , "core@ietf.org" , "netconf@ietf.org" Message-ID: <20190328160714.uuzfvxrjjxflktg5@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Michel Veillette , Carsten Bormann , "core@ietf.org" , "netconf@ietf.org" References: <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 16:07:21 -0000 On Thu, Mar 28, 2019 at 08:50:34AM -0700, Andy Bierman wrote: > On Thu, Mar 28, 2019 at 7:06 AM Michel Veillette < > Michel.Veillette@trilliant.com> wrote: > > > +1 for value outside, string inside union > > > > > This is simple, but I was trying to support some very common types (like > ip-address) > that are unions of strings, and are desirable to send as binary instead of > string representation. > How does CBOR deal with say inet:ipv4-address? Does inet:ipv4-address magically get converted into a binary format? If not, the surprise that it is a string in a union is not a bit surprise. It seems to take full advantage of binary formats efficiently we need some additional magic. The YANG language requires the definition of canonical (textual) format. Do we need a way to define corresponding canonical binary formats for some of the types (where the default textual format is inefficient to send as a string)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 28 09:31:03 2019 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 E046A12004B for ; Thu, 28 Mar 2019 09:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCs6eP8z7cP7 for ; Thu, 28 Mar 2019 09:30:58 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B310120077 for ; Thu, 28 Mar 2019 09:30:42 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id f18so18210708lja.10 for ; Thu, 28 Mar 2019 09:30:42 -0700 (PDT) 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; bh=RiosPYGuRqXlxbL/4YNBU0BmgPKmtsXQZ4xHz5XK+H0=; b=Rb2nPCiW/GYc0zu9b3dSc+FVvpzl5uq6rwokFoE3D+MOTtjsMcqkklwIo9lD+TIG93 0C8Y+xiOtGszJ9fG+ihGAzM+9aRiFBpqGXBzjoHhd3ZbKMQt6TfT45qA63jTSupcMh5Z jmC4yo8AQt/pbDfGw2RKjxfiRePO1wRiinaBOi9Qcof7iNLTsPLkNCwiLrGEPnoB+I5B HeISWRtFoknULrVgRhF8BeSbHOmqHbSVIDNSdMdr+vw9FSFKuk3xDob90iPZvNfyCS6E BF6QxeWRzRYkzpq05O4dv7dzLifwa4aluzz6RaDwNdBEE/JKhKrenFIuO7q03IUQPCAN GKtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RiosPYGuRqXlxbL/4YNBU0BmgPKmtsXQZ4xHz5XK+H0=; b=FUREoewy3p/8yMYqXEqb9SZihmdm7WnhGboZ2qRlt+VE9CI2ABPIV9LlwTirk9GyZJ 3wwzWHnb9sQN2jBTYQdiQ6FJcdXgx8AoSilbaic9KzmaPmyj/IOAOVOGD7ilWTFoNDV2 M2Zi1Tc9pGc+JsTjTwdpifggNL0hvMQevjB5gPu+OxA307rn57bOrcThhT6IB/Fmb68M 2PD2JhLKqSgISnpnKo5/OTZACNBKVa9rB8o0I3loEHX7Xer3W+5pC8gecF3ZL/xsC4og PVtyZoCiiXmJ51SGioLTeExbkYhXz8qr/B13/rT1vMFJhlv9hrplh4E1gjQbcNExM5nY g1Ew== X-Gm-Message-State: APjAAAWopmex1EJ/mWfXdauQvv852GeYGm+ui8rZGkTTsJaSPtohTt1w kU0Bx5rzOgG2Je59B1gArf3Xia2dEWRQ0Tv0pxjpqg== X-Google-Smtp-Source: APXvYqxkYd67kF+pX2p9pVK7YaNem36LhJCvYM1LVyPHchWin1m7q1lJNBR0S7xWXAn5s5HVHygfrslJinDJmNrNsgg= X-Received: by 2002:a2e:844a:: with SMTP id u10mr12165033ljh.41.1553790640259; Thu, 28 Mar 2019 09:30:40 -0700 (PDT) MIME-Version: 1.0 References: <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> <20190328160714.uuzfvxrjjxflktg5@anna.jacobs.jacobs-university.de> In-Reply-To: <20190328160714.uuzfvxrjjxflktg5@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Thu, 28 Mar 2019 09:30:28 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Michel Veillette , Carsten Bormann , "core@ietf.org" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002b1c1d05852a136e" Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 16:31:01 -0000 --0000000000002b1c1d05852a136e Content-Type: text/plain; charset="UTF-8" On Thu, Mar 28, 2019 at 9:07 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Mar 28, 2019 at 08:50:34AM -0700, Andy Bierman wrote: > > On Thu, Mar 28, 2019 at 7:06 AM Michel Veillette < > > Michel.Veillette@trilliant.com> wrote: > > > > > +1 for value outside, string inside union > > > > > > > > This is simple, but I was trying to support some very common types (like > > ip-address) > > that are unions of strings, and are desirable to send as binary instead > of > > string representation. > > > > How does CBOR deal with say inet:ipv4-address? Does inet:ipv4-address > magically get converted into a binary format? If not, the surprise that > it is a string in a union is not a bit surprise. > > It seems to take full advantage of binary formats efficiently we need > some additional magic. The YANG language requires the definition of > canonical (textual) format. Do we need a way to define corresponding > canonical binary formats for some of the types (where the default > textual format is inefficient to send as a string)? > > I thought there was a magic tag for an IPv4 address. I don't see it now. Maybe it got removed. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --0000000000002b1c1d05852a136e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 28, 2019 at 9:07 AM Juerg= en Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Mar 28, 2019 at 08:50:34AM -0= 700, Andy Bierman wrote:
> On Thu, Mar 28, 2019 at 7:06 AM Michel Veillette <
> Mi= chel.Veillette@trilliant.com> wrote:
>
> > +1 for value outside, string inside union
> >
> >
> This is simple, but I was trying to support some very common types (li= ke
> ip-address)
> that are unions of strings, and are desirable to send as binary instea= d of
> string representation.
>

How does CBOR deal with say inet:ipv4-address? Does inet:ipv4-address
magically get converted into a binary format? If not, the surprise that
it is a string in a union is not a bit surprise.

It seems to take full advantage of binary formats efficiently we need
some additional magic. The YANG language requires the definition of
canonical (textual) format. Do we need a way to define corresponding
canonical binary formats for some of the types (where the default
textual format is inefficient to send as a string)?


I thought there was a magic tag for an= IPv4 address.
I don't see it now.=C2=A0 Maybe it got removed= .

=C2=A0
/js

Andy
=C2=A0

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>
--0000000000002b1c1d05852a136e-- From nobody Thu Mar 28 11:01:47 2019 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 2C4A31202F5; Thu, 28 Mar 2019 11:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk2jUkp1wasF; Thu, 28 Mar 2019 11:01:39 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750121.outbound.protection.outlook.com [40.107.75.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F701202EF; Thu, 28 Mar 2019 11:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pUAuzwptZV5dJJG9g+pczbGz6Ee9Jayv+Wn9LfvXOSk=; b=Xdn5vVkw3pf3y8bdvD1zj4L1xboxv7tOYKSdLDBsEPG3DsDsr9jn1QqrTARIYLH8Rkn+w9u81d1jpE+diDWjTQDl1DVJw6HN2Tg7WYDCIT5UVqBxk+iordkPS7/4Dl9z/ufNAZ2H95C1fT64nXQtsLq5HSTC7Jdz2LesYCU+AHg= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4227.namprd06.prod.outlook.com (10.167.179.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.19; Thu, 28 Mar 2019 18:01:36 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::6d4a:3963:7ffb:1f30]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::6d4a:3963:7ffb:1f30%2]) with mapi id 15.20.1750.017; Thu, 28 Mar 2019 18:01:36 +0000 From: Michel Veillette To: Andy Bierman CC: Carsten Bormann , Juergen Schoenwaelder , "core@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAL8XAAAAtt/gAAgmRkAAAJStYAAYEUIgABUqX2QAAwU1oAAE3mQoAApxZcAAATFAAAAAF65QAAD8z4AAAQMWjA= Date: Thu, 28 Mar 2019 18:01:36 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d44db18a-4070-489f-bbdb-08d6b3a76b87 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4227; x-ms-traffictypediagnostic: BL0PR06MB4227: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(346002)(136003)(39850400004)(199004)(189003)(13464003)(476003)(2906002)(33656002)(106356001)(105586002)(486006)(8676002)(6306002)(97736004)(66066001)(54896002)(4326008)(229853002)(790700001)(6116002)(6916009)(81166006)(68736007)(11346002)(81156014)(3846002)(6436002)(25786009)(8936002)(446003)(9686003)(72206003)(966005)(478600001)(7736002)(55016002)(236005)(606006)(74316002)(53936002)(14454004)(6246003)(6506007)(26005)(53546011)(316002)(76176011)(186003)(256004)(102836004)(5660300002)(52536014)(71200400001)(71190400001)(86362001)(7696005)(93886005)(99286004)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4227; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xyE/QQ7MRYT7GajVUnCn23nEcbgARMAqPQJpsxfOo30zwI190N2yJwBXwOl+PTT4tukj45aQ8bZ58UR15Ee/lFaElFy9l70PkC6G0cdoSgh+A+SbnOOoSqRPk8vmE8aNTiGU6ZtzGKaZlAslEjO7qeg+m5x1ZRhNxHnHDpkrXBAawsGc6r9Q0EfG0AJJNMIm3WfiZVAIGmCaSTKCYW5R16TRMWay7FxX1ocvVZeg5dqoSnrHX+6FiWtNP34RH0+Q7wfEAFVKRFKPREzNnVxUCnjVy6NdeksMlPBp7p4ffldqtOezcB/PDTvjLelj3QsEvX9aeNeXNyOPGAyM/q2BfXhHmlmFWfWIvaxQU0NB7SpyXGgzkRTKT0CM6/OVR6FMOeIl7LbJ7FSr39gQLaZo2dPtO/p3eRc4SUKi7WpUDFQ= Content-Type: multipart/alternative; boundary="_000_BL0PR06MB504204A4C313AC09CFC8C8EF9A590BL0PR06MB5042namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: d44db18a-4070-489f-bbdb-08d6b3a76b87 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 18:01:36.0899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4227 Archived-At: Subject: Re: [core] [netconf] YANG encoding in CBOR 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, 28 Mar 2019 18:01:45 -0000 --_000_BL0PR06MB504204A4C313AC09CFC8C8EF9A590BL0PR06MB5042namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpUaGUgY3VycmVudCBkaXNjdXNzaW9uIG9uICd1bmlvbicgZG9uJ3QgaGVscCBy ZWR1Y2luZyB0aGUgc2l6ZSBhbmQgY29tcGxleGl0eSBvZiBzb21lIG9mIHRoZSAnaWV0Zi1pbmV0 LXR5cGVzJyB0eXBlcyBzdWNoIGFzOg0KdHlwZWRlZiBpcC1hZGRyZXNzDQp0eXBlZGVmIGlwdjQt YWRkcmVzcw0KdHlwZWRlZiBpcHY2LWFkZHJlc3MNCnR5cGVkZWYgaXAtYWRkcmVzcy1uby16b25l DQp0eXBlZGVmIGlwdjQtYWRkcmVzcy1uby16b25lDQp0eXBlZGVmIGlwdjYtYWRkcmVzcy1uby16 b25lDQp0eXBlZGVmIGlwLXByZWZpeA0KdHlwZWRlZiBpcHY0LXByZWZpeA0KDQpPciBzb21lIG9m IHRoZSAnaWV0Zi15YW5nLXR5cGVzJyB0eXBlcyBzdWNoIGFzOg0KdHlwZWRlZiBkYXRlLWFuZC10 aW1lDQp0eXBlZGVmIHRpbWVzdGFtcA0KdHlwZWRlZiBwaHlzLWFkZHJlc3MNCnR5cGVkZWYgbWFj LWFkZHJlc3MNCnR5cGVkZWYgaGV4LXN0cmluZw0KdHlwZWRlZiB1dWlkDQp0eXBlZGVmIGRvdHRl ZC1xdWFkDQoNClRoZSBzaW1wbGVzIHdheSB0byBhZGRyZXNzIHRob3NlIGlzIHRvIGNyZWF0ZSBh IG5ldyB2ZXJzaW9uIG9mIHRoZXNlIFlBTkcgbW9kdWxlcyBieSBhZGRpbmcgYSBiaW5hcnkgb3B0 aW9uIHVzaW5nIGEgdW5pb24uDQpJIGhvcGUgdGhpcyBjYW4gZXZlbnR1YWxseSBoYXBwZW4gd2hl biB0aGUgQ0JPUiBlbmNvZGluZyBnZXQgbW9yZSBwb3B1bGFyLg0KDQpSZWdhcmRzLA0KTWljaGVs DQoNCg0KRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpTZW50OiBUaHVy c2RheSwgTWFyY2ggMjgsIDIwMTkgMTE6NTEgQU0NClRvOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNo ZWwuVmVpbGxldHRlQHRyaWxsaWFudC5jb20+DQpDYzogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6 aS5vcmc+OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZT47IGNvcmVAaWV0Zi5vcmc7IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbbmV0Y29uZl0gWUFORyBlbmNvZGluZyBpbiBDQk9SDQoNCg0KDQpPbiBUaHUsIE1hciAyOCwg MjAxOSBhdCA3OjA2IEFNIE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxp YW50LmNvbTxtYWlsdG86TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPj4gd3JvdGU6DQor MSBmb3IgdmFsdWUgb3V0c2lkZSwgc3RyaW5nIGluc2lkZSB1bmlvbg0KDQpUaGlzIGlzIHNpbXBs ZSwgYnV0IEkgd2FzIHRyeWluZyB0byBzdXBwb3J0IHNvbWUgdmVyeSBjb21tb24gdHlwZXMgKGxp a2UgaXAtYWRkcmVzcykNCnRoYXQgYXJlIHVuaW9ucyBvZiBzdHJpbmdzLCBhbmQgYXJlIGRlc2ly YWJsZSB0byBzZW5kIGFzIGJpbmFyeSBpbnN0ZWFkIG9mIHN0cmluZyByZXByZXNlbnRhdGlvbi4N Cg0KQW5keQ0KDQpNeSByYXRpb25hbDoNCg0KLSBTSUQgY2FuIGhhdmUgdXAgdG8gOCBieXRlcyBh bmQgd2lsbCBwcm92aWRlIGEgbWFyZ2luYWwgY29tcHJlc3Npb24uDQotIEdlbmVyYXRpbmcgU0lE IGZvciBhbGwgJ2VudW1lcmF0aW9uJyBhbmQgJ2JpdHMnIGluIGNhc2UgdGhleSBhcmUgdXNlZCBp biAndW5pb24nIGlzIGxvdCBvZiBvdmVyaGVhZCB0byByZXZvbHZlIGEgY29ybmVyIGNhc2UuDQot IFlBTkcgYWxzbyBzdXBwb3J0IHRoZSAnY2hvaWNlJyBzdGF0ZW1lbnQgKGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24tNC4yLjc8aHR0cHM6Ly9jYW4wMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5v cmclMkZodG1sJTJGcmZjNzk1MCUyM3NlY3Rpb24tNC4yLjcmZGF0YT0wMiU3QzAxJTdDJTdDOTE2 ZmYwNmNlOTM4NGI4YTEwNGEwOGQ2YjM5NTI1NjElN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2 MGMwNDMwOSU3QzAlN0MwJTdDNjM2ODkzODUwNDkwMzM0Mjk0JnNkYXRhPU85ZjBHTmNSdmc5czVh RSUyQkI5UjQzRGpJMnF1aUt6QWZNZlFjSGhkbnJNZyUzRCZyZXNlcnZlZD0wPikgd2hpY2ggaXMg c2ltaWxhciB0bw0KICAgdGhlIGNvbmNlcHQgb2YgdHlwZSB0YWdnaW5nIHdpdGhpbiB1bmlvbi4g VGhpcyBjb25zdHJ1Y3QgY2FuIGJlIHVzZWQgYnkgWUFORyBtb2R1bGVzIHNwZWNpZmljYWxseSBj cmVhdGVkIGZvcg0KICBlbWJlZGRlZCBhcHBsaWNhdGlvbnMgdG8gdGFrZSBhZHZhbnRhZ2Ugb2Yg J2VudW1lcmF0aW9uJyBlbmNvZGVkIGFzIHZhbHVlIGFuZCAnYml0cycgZW5jb2RlZCBhcyBiaXQu DQoNCk1pY2hlbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJzdGVu IEJvcm1hbm4gPGNhYm9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4NClNlbnQ6IFRodXJz ZGF5LCBNYXJjaCAyOCwgMjAxOSA5OjQ3IEFNDQpUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+DQpDYzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZl aWxsZXR0ZUB0cmlsbGlhbnQuY29tPG1haWx0bzpNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudC5j b20+PjsgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PG1haWx0bzpsaG90a2FAbmljLmN6 Pj47IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+OyBjb3JlQGlldGYu b3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBZQU5HIGVu Y29kaW5nIGluIENCT1INCg0KU28gZm9yIGVudW0vYml0cyB3ZSBhcmUgYmFjayB0byB2YWx1ZSBv dXRzaWRlLCBzdHJpbmcgaW5zaWRlIHVuaW9uPw0KQ2FuIHdlIHVzZSBTSURzIGluc3RlYWQgb2Yg dGhlIHN0cmluZ3MgZm9yIHRoZSBsYXR0ZXI/DQpUaGlzIGNhbuKAmXQgYmUgbXVjaCBtb3JlIGNv bXBsaWNhdGVkIHRoYW4gYXNzaWduaW5nIGEgU0lEIHRvIGVhY2ggc3RyaW5nIHRoYXQgb2NjdXJz IGluIGFuIGVudW0vYml0cyBpbiBhIHVuaW9uLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRjb25mIG1haWxp bmcgbGlzdA0KbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjxodHRwczovL2NhbjAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0 Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZuZXRjb25mJmRhdGE9MDIlN0MwMSU3QyU3Qzkx NmZmMDZjZTkzODRiOGExMDRhMDhkNmIzOTUyNTYxJTdDNGY2ZmJkMTMwZGZiNDE1MDg1YzNkNDMy NjBjMDQzMDklN0MwJTdDMCU3QzYzNjg5Mzg1MDQ5MDM0NDMwOCZzZGF0YT04JTJCR2pyRnVjTSUy QmZzNkwyVFklMkZ2SFVZbDgzQ3E5WWt1cWN4UUFOa1I0aGtRJTNEJnJlc2VydmVkPTA+DQo= --_000_BL0PR06MB504204A4C313AC09CFC8C8EF9A590BL0PR06MB5042namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5IaSBB bmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5UaGUgY3VycmVudCBkaXNjdXNzaW9uIG9uICd1bmlvbicg ZG9uJ3QgaGVscCByZWR1Y2luZyB0aGUgc2l6ZSBhbmQgY29tcGxleGl0eSBvZiBzb21lIG9mIHRo ZSAnaWV0Zi1pbmV0LXR5cGVzJyB0eXBlcyBzdWNoIGFzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj50eXBlZGVmIGlwLWFkZHJl c3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSI+dHlwZWRlZiBpcHY0LWFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+dHlwZWRlZiBpcHY2LWFkZHJlc3M8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSI+dHlwZWRlZiBpcC1hZGRyZXNzLW5vLXpvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+dHlwZWRlZiBpcHY0LWFkZHJl c3Mtbm8tem9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIj50eXBlZGVmIGlwdjYtYWRkcmVzcy1uby16b25lPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPnR5cGVk ZWYgaXAtcHJlZml4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiPnR5cGVkZWYgaXB2NC1wcmVmaXg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei Pk9yIHNvbWUgb2YgdGhlICdpZXRmLXlhbmctdHlwZXMnIHR5cGVzIHN1Y2ggYXM6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPnR5 cGVkZWYgZGF0ZS1hbmQtdGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj50eXBlZGVmIHRpbWVzdGFtcDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj50eXBlZGVm IHBoeXMtYWRkcmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIj50eXBlZGVmIG1hYy1hZGRyZXNzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPnR5cGVkZWYgaGV4 LXN0cmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj50eXBlZGVmIHV1aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+dHlwZWRlZiBkb3R0ZWQtcXVhZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSI+VGhlIHNpbXBsZXMgd2F5IHRvIGFkZHJlc3MgdGhvc2UgaXMgdG8gY3Jl YXRlIGEgbmV3IHZlcnNpb24gb2YgdGhlc2UgWUFORyBtb2R1bGVzIGJ5IGFkZGluZyBhIGJpbmFy eSBvcHRpb24gdXNpbmcgYSB1bmlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+SSBob3BlIHRoaXMgY2FuIGV2ZW50dWFsbHkg aGFwcGVuIHdoZW4gdGhlIENCT1IgZW5jb2RpbmcgZ2V0IG1vcmUgcG9wdWxhci48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPk1pY2hlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyA8YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIE1hcmNoIDI4LCAyMDE5IDExOjUxIEFNPGJyPg0KPGI+VG86PC9iPiBNaWNo ZWwgVmVpbGxldHRlICZsdDtNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBDYXJzdGVuIEJvcm1hbm4gJmx0O2NhYm9AdHppLm9yZyZndDs7IEp1ZXJnZW4g U2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0 OzsgY29yZUBpZXRmLm9yZzsgbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW25ldGNvbmZdIFlBTkcgZW5jb2RpbmcgaW4gQ0JPUjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMjgsIDIwMTkgYXQgNzowNiBBTSBNaWNoZWwgVmVpbGxl dHRlICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tIj5N aWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+JiM0MzsxIGZvciB2YWx1ZSBvdXRzaWRlLCBzdHJpbmcgaW5zaWRl IHVuaW9uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIGlzIHNpbXBsZSwgYnV0IEkgd2FzIHRyeWluZyB0byBzdXBwb3J0IHNv bWUgdmVyeSBjb21tb24gdHlwZXMgKGxpa2UgaXAtYWRkcmVzcyk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYXQgYXJlIHVuaW9ucyBvZiBzdHJp bmdzLCBhbmQgYXJlIGRlc2lyYWJsZSB0byBzZW5kIGFzIGJpbmFyeSBpbnN0ZWFkIG9mIHN0cmlu ZyByZXByZXNlbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSByYXRpb25hbDo8YnI+DQo8YnI+DQotIFNJRCBjYW4g aGF2ZSB1cCB0byA4IGJ5dGVzIGFuZCB3aWxsIHByb3ZpZGUgYSBtYXJnaW5hbCBjb21wcmVzc2lv bi48YnI+DQotIEdlbmVyYXRpbmcgU0lEIGZvciBhbGwgJ2VudW1lcmF0aW9uJyBhbmQgJ2JpdHMn IGluIGNhc2UgdGhleSBhcmUgdXNlZCBpbiAndW5pb24nIGlzIGxvdCBvZiBvdmVyaGVhZCB0byBy ZXZvbHZlIGEgY29ybmVyIGNhc2UuPGJyPg0KLSBZQU5HIGFsc28gc3VwcG9ydCB0aGUgJ2Nob2lj ZScgc3RhdGVtZW50ICg8YSBocmVmPSJodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZy ZmM3OTUwJTIzc2VjdGlvbi00LjIuNyZhbXA7ZGF0YT0wMiU3QzAxJTdDJTdDOTE2ZmYwNmNlOTM4 NGI4YTEwNGEwOGQ2YjM5NTI1NjElN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3 QzAlN0MwJTdDNjM2ODkzODUwNDkwMzM0Mjk0JmFtcDtzZGF0YT1POWYwR05jUnZnOXM1YUUlMkJC OVI0M0RqSTJxdWlLekFmTWZRY0hoZG5yTWclM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNzZWN0aW9uLTQuMi43PC9h PikNCiB3aGljaCBpcyBzaW1pbGFyIHRvPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBjb25jZXB0IG9m IHR5cGUgdGFnZ2luZyB3aXRoaW4gdW5pb24uIFRoaXMgY29uc3RydWN0IGNhbiBiZSB1c2VkIGJ5 IFlBTkcgbW9kdWxlcyBzcGVjaWZpY2FsbHkgY3JlYXRlZCBmb3I8YnI+DQombmJzcDsgZW1iZWRk ZWQgYXBwbGljYXRpb25zIHRvIHRha2UgYWR2YW50YWdlIG9mICdlbnVtZXJhdGlvbicgZW5jb2Rl ZCBhcyB2YWx1ZSBhbmQgJ2JpdHMnIGVuY29kZWQgYXMgYml0Ljxicj4NCjxicj4NCk1pY2hlbDxi cj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogQ2Fy c3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIiB0YXJnZXQ9Il9i bGFuayI+Y2Fib0B0emkub3JnPC9hPiZndDsNCjxicj4NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAy OCwgMjAxOSA5OjQ3IEFNPGJyPg0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJf YmxhbmsiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7PGJyPg0K Q2M6IE1pY2hlbCBWZWlsbGV0dGUgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoZWwuVmVpbGxldHRl QHRyaWxsaWFudC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFu dC5jb208L2E+Jmd0OzsgTGFkaXNsYXYgTGhvdGthICZsdDs8YSBocmVmPSJtYWlsdG86bGhvdGth QG5pYy5jeiIgdGFyZ2V0PSJfYmxhbmsiPmxob3RrYUBuaWMuY3o8L2E+Jmd0OzsNCjxhIGhyZWY9 Im1haWx0bzpuZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRmLm9y ZzwvYT47IDxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpj b3JlQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFORyBlbmNvZGlu ZyBpbiBDQk9SPGJyPg0KPGJyPg0KU28gZm9yIGVudW0vYml0cyB3ZSBhcmUgYmFjayB0byB2YWx1 ZSBvdXRzaWRlLCBzdHJpbmcgaW5zaWRlIHVuaW9uPzxicj4NCkNhbiB3ZSB1c2UgU0lEcyBpbnN0 ZWFkIG9mIHRoZSBzdHJpbmdzIGZvciB0aGUgbGF0dGVyPzxicj4NClRoaXMgY2Fu4oCZdCBiZSBt dWNoIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBhc3NpZ25pbmcgYSBTSUQgdG8gZWFjaCBzdHJpbmcg dGhhdCBvY2N1cnMgaW4gYW4gZW51bS9iaXRzIGluIGEgdW5pb24uPGJyPg0KPGJyPg0KR3LDvMOf ZSwgQ2Fyc3Rlbjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9jYW4wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGbmV0Y29uZiZhbXA7ZGF0YT0wMiU3QzAxJTdDJTdDOTE2ZmYwNmNlOTM4NGI4YTEwNGEwOGQ2 YjM5NTI1NjElN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3QzAlN0MwJTdDNjM2 ODkzODUwNDkwMzQ0MzA4JmFtcDtzZGF0YT04JTJCR2pyRnVjTSUyQmZzNkwyVFklMkZ2SFVZbDgz Q3E5WWt1cWN4UUFOa1I0aGtRJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_BL0PR06MB504204A4C313AC09CFC8C8EF9A590BL0PR06MB5042namp_-- From nobody Thu Mar 28 14:00:12 2019 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 454C11203F7 for ; Thu, 28 Mar 2019 14:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgxIN6Cc-p12 for ; Thu, 28 Mar 2019 14:00:07 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248691203F5 for ; Thu, 28 Mar 2019 14:00:06 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 26C574380B for ; Thu, 28 Mar 2019 22:00:04 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 801BF36 for ; Thu, 28 Mar 2019 22:00:02 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2001:67c:1232:144:53b4:478e:561d:3782]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 359317A for ; Thu, 28 Mar 2019 22:00:02 +0100 (CET) Received: (nullmailer pid 14753 invoked by uid 1000); Thu, 28 Mar 2019 21:00:01 -0000 Date: Thu, 28 Mar 2019 22:00:01 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core WG Message-ID: <20190328210001.GA9474@hephaistos.amsuess.com> References: <20190321084706.GA17128@hephaistos.amsuess.com> <20190324205323.GA9387@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20190324205323.GA9387@hephaistos.amsuess.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Observe updates, and call for proxy implementations 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, 28 Mar 2019 21:00:10 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable One more update here based on continued discussion and to clear out misunderstandings. > > * Pinning of response content formats. >=20 > Seemed to be a straightforward idea at the time that wasn't throught > through in combination with what we know now (how could it). >=20 > Next step: Write update text, decide whether to spool it with any other > document or do a single-page update document that removes the restriction. > State that no proxies are known to enforce it. Note that this proposal is not about changing what happens when an Accept is sent (response is bound to be same format). It only opens up observation to more elaborate negotiation patterns, and removes an unanswered question about permissible error states. The proposed Accept-Any option[1] (that builds on this but is not itself the topic here) should not be used for "send full client supported list" applications, the draft could be way more specific here. It's also worth pointing out that this topic has only become pressing due to the way pubsub handles observations. If nontraditional responses become a part of pubsub, the issue may become a more theoretical one. [1]: https://tools.ietf.org/html/draft-amsuess-core-accept-any-00 > > * Pinning of all request options except ETag. >=20 > This one is not that simple, but in no hurry to solve. >=20 > Adding ETags has the (maybe unique) property that a response that the > meaning of responses is not modified; if any request reaffirming > messages get mixed up, worst to happen is a 2.01 rather than a 2.03. >=20 > It might be a good idea to steer this into deprecating ETag updates. > Might also be worth looking into in combination with nontraditional > responses. >=20 > Next steps: Further discussion, but no hurry either. ETag updates are currently allowed and do have their use, but they also come with considerations to be taken (like the client needing to be prepared to still receive old messages, even for the updated request to get lost if something switches round badly). We could write some implementation guidance that describes the problems, and for some impls it will be easier to just cancel / use a new token. It might be a good idea to give implementation guidance with particular focus on OSCORE as well (and think about OSCORE aware proxies in the course of that). Using an active token (one that was not cancelled) and changing something other than ETag is not conforming to the protocol, and the server or proxy could do all kinds of things. A token is in use until a response arrives on the token that has no Observe option. Kind regards Christian --=20 Most people would leave. Not us. We're Vikings. We have stubbornness issues. -- Hiccup, son of Stoic --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlydNckACgkQOY0REtOk veEKoRAAt3ELADB8xDS48w8dFCOYPcbFBjMS1fGYMEdL/kfnWvl/EKh/YZW/Qk7b oAKxs2I15U5MifrQOc52Q2AFeAbVmPen4DuyhJ6tDN/z6h97rns8p9AuO1T9BVyB t/p8uFA9lNklzMatew3AhFHOGXPFfElMIPk2pOadfqdjiAIXlvqNjM5HW6pynwXm KvWibuOvPuchcR3jx1yrICVpm2rA/hCzeosYtSNMTxdXMZGKgynAHJpWYmkvYm7Q qlofJpMenCI5JR4IuP8RrJ9bI6Qamy4JcdLQ2MBdJC728Cfdvruy9ARS4g5EuTLj u0tjCtpa4MwPm6nGIXgSoNta/uVxALAgABSxGnc11Ies2mraEsjyqI1ETL+e1Cao OcAyuVqD7aquUvi3TGTxbrXJjlz7cckriM+owF+Rxo9CFTOGaCV0yhsFnMq4FLtX xBxg/PEKcAs0um9ymZhiol7Pqv8huombfayZPr1hovry742ZUl9Sg7S9s9kzkZ2R 53PGoAbrVeJ8hBTSKmDTX7/7M3A/80bAk798Q2tBDZbatYps9rbHAX7vqezuOkhB EQGypBFihwy4IvmMizZcmyKcBiixwa7Cc9BwUuN7Lfb7tVRMkKzgrX1GtJw4nA43 Bn7OLqR+XgH90VRlqa1HoSVXEsvXTOVJvkDJQuhsDGQTcjODCDg= =U+nn -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From nobody Thu Mar 28 15:05:23 2019 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 84473120454; Thu, 28 Mar 2019 15:05:12 -0700 (PDT) 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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155381071244.1414.15110813535407686735@ietfa.amsl.com> Date: Thu, 28 Mar 2019 15:05:12 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-06.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, 28 Mar 2019 22:05:21 -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-06.txt Pages : 29 Date : 2019-03-28 Abstract: YANG Schema Item iDentifiers (SID) are globally unique 64-bit unsigned numbers 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-06 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 Mar 28 15:08:28 2019 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 DE28B120044 for ; Thu, 28 Mar 2019 15:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 FytfbWwSBjp2 for ; Thu, 28 Mar 2019 15:08:25 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 860B01202AB for ; Thu, 28 Mar 2019 15:08:22 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id r4so138970wrq.8 for ; Thu, 28 Mar 2019 15:08:22 -0700 (PDT) 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=xGTigrlYqUDcZ2Zhgyj5SqfYE9kDbvlxuk+RXCQVTfU=; b=SXoRd8wyRjmHGVcyDSDYuUg0h+5UNkvX5erZP5Ym12rYNNjDR2i2guFJKyQvPAyopv oFbfYLv88qKP+y7EDe4oJqZR3UiyzoxI96VdLFZGSmccJ+UK6GqHnG9uBy33pY8oB1JV UwNsptXj+Bo5AnjrcxZ6V1Ql/pXiUWAiT+qiKVuLUMmzKyXMA5RlByRkRXQR2VbL84vi Cx0/Kv3eW6FmKPFHKu8VI/yGW6Qipe7LppLayAwUuDzsZBvy9L9bbN/gNEP5i1378NNP c3AByP+E7b2DPbEABzON2Y7NkiaLeZ2ypNaidHzwQs8qscfVf9YxFc1WAU5hN5wB579n tdGw== 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=xGTigrlYqUDcZ2Zhgyj5SqfYE9kDbvlxuk+RXCQVTfU=; b=ROkZm/1lPCGh3V/OCEVZngNZD/gOFoRXOHgV4BCrxYnqL/rOm7QpNdA03BKFmviw5f /af+QjYW170PMPkQdBnQ1xtJDYQfgOVyfZPwWzy6I7alnxcCNA+3Xftq7hJuv89aGw35 oEyYVJW/naC3y+d0laf+m8Yb46wGzcjZrtHfnP1WBcNvgcQLUZVhap3efWC7aBXs9siA vd5sJJDgApAEsSBN2s434sYJ9Mu7mLSZs0YwniSCSAWEcFntAsNwuv++gEw58HBMd2Im uAhuiWEaTKruKDQoQKpLWw4b2HTWI6U473oVlTcsCAa6FCtvtyLu/7FXPdserywIvWWj PWlA== X-Gm-Message-State: APjAAAXItzyP6Uc3Kir5XeyuIGuEr6jbd0W2RrlzFpV/XuxvhbndW69w 6hbmQqCYZvWJl5/FVOOB2aFB1mh5KVFR4Gc4UQKezVz8fMw= X-Google-Smtp-Source: APXvYqwQLdRgjc4PSFvuFmCYgq72RdQC+9lTTr1HtezcNThMCWtA3GIW5DEoPdOFbfxtSg1X40DkvwKut+mZago2i8s= X-Received: by 2002:adf:dcca:: with SMTP id x10mr28638525wrm.57.1553810900760; Thu, 28 Mar 2019 15:08:20 -0700 (PDT) MIME-Version: 1.0 References: <155381071244.1414.15110813535407686735@ietfa.amsl.com> In-Reply-To: <155381071244.1414.15110813535407686735@ietfa.amsl.com> From: ivaylo petrov Date: Thu, 28 Mar 2019 23:07:53 +0100 Message-ID: To: core@ietf.org Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="000000000000c9cafe05852ecac4" Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-sid-06.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: Thu, 28 Mar 2019 22:08:27 -0000 --000000000000c9cafe05852ecac4 Content-Type: text/plain; charset="UTF-8" Dear all, The new version of the sid draft is uploaded to the datatracker. It is the result of a number of discussions with IANA representatives. Please review it and don't hesitate to contact us if you have any questions or comments. Best regards, Ivaylo On Thu, Mar 28, 2019 at 11:05 PM wrote: > > 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-06.txt > Pages : 29 > Date : 2019-03-28 > > Abstract: > YANG Schema Item iDentifiers (SID) are globally unique 64-bit > unsigned numbers 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-06 > https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-06 > > > 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/ > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000c9cafe05852ecac4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

The ne= w version of the sid draft is uploaded to the datatracker. It is the result= of a number of discussions with IANA representatives. Please review it and= don't hesitate to contact us if you have any questions or comments.

Best regards,
Ivaylo

=

= On Thu, Mar 28, 2019 at 11:05 PM <internet-drafts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= YANG Schema Item iDentifier (SID)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= el Veillette
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Alexander Pelov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ivaylo Petrov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-core-sid-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 29
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-03-28

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cor= e-sid/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-sid-06=
https://datatracker.ietf.org/doc/html/dr= aft-ietf-core-sid-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-core-sid-06


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

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

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000c9cafe05852ecac4-- From nobody Fri Mar 29 01:55:32 2019 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 7E46F12023E for ; Fri, 29 Mar 2019 01:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 FP5j64vyIVST for ; Fri, 29 Mar 2019 01:55:28 -0700 (PDT) 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 5C431120026 for ; Fri, 29 Mar 2019 01:55:28 -0700 (PDT) Received: from Jude (31.133.152.241) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 29 Mar 2019 01:55:01 -0700 From: Jim Schaad To: Date: Fri, 29 Mar 2019 09:54:57 +0100 Message-ID: <00ce01d4e60d$1751b0e0$45f512a0$@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: AdTmDOJpMunX6pW7TceYl5ZG+UWKlQ== Content-Language: en-us X-Originating-IP: [31.133.152.241] Archived-At: Subject: [core] PubSub Create/FIrst Publish 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, 29 Mar 2019 08:55:31 -0000 One of the options that I don't remember anybody talking about would be to not set the topic up for discovery until the first publish has been done for "leaf" nodes. This would not be an issue for nodes created with link format as this content is generated by the server and thus always exists. Jim From nobody Fri Mar 29 02:10:48 2019 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 23618120449 for ; Fri, 29 Mar 2019 02:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTdYx1W_R1G6 for ; Fri, 29 Mar 2019 02:10:44 -0700 (PDT) Received: from smtp.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 95AA41203CE for ; Fri, 29 Mar 2019 02:10:44 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44Vwv61pz3zyt0; Fri, 29 Mar 2019 10:10:42 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 575543439.621875-bc2874759d7f4c0237b19a1ac9530d25 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 29 Mar 2019 10:10:41 +0100 Message-Id: <16B3DD63-227A-4969-9330-D52132FF63BD@tzi.org> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] CIRIs: Scheme 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, 29 Mar 2019 09:10:47 -0000 For CIRI Scheme names, do not allow upper case characters =E2=80=94 = scheme namess are case insensitive, and by disallowing upper case they = also become unique. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 29 02:12:04 2019 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 3729C120261 for ; Fri, 29 Mar 2019 02:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_fcBqZSiCXf for ; Fri, 29 Mar 2019 02:12:02 -0700 (PDT) Received: from smtp.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 EF78E12023E for ; Fri, 29 Mar 2019 02:12:01 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44Vwwc1rKBzysS; Fri, 29 Mar 2019 10:12:00 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <541A113C-5FA1-410F-B17F-EC2D194E5079@tzi.org> Date: Fri, 29 Mar 2019 10:11:59 +0100 X-Mao-Original-Outgoing-Id: 575543518.247411-d46b055dcf2019c21be080960eb1800e Content-Transfer-Encoding: quoted-printable Message-Id: References: <541A113C-5FA1-410F-B17F-EC2D194E5079@tzi.org> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Should we bury draft-ietf-core-interfaces? 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, 29 Mar 2019 09:12:03 -0000 The in-room consensus at IETF104 was that we should not =E2=80=9Cbury=E2=80= =9D core-interfaces, but hand it over to T2TRG as raw material (for = their documents on IoT design under the REST paradigm). Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 29 02:23:30 2019 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 628CA1203E1; Fri, 29 Mar 2019 02:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 vIPeW5LI4xj9; Fri, 29 Mar 2019 02:23:19 -0700 (PDT) Received: from smtp.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 D3B83120425; Fri, 29 Mar 2019 02:23:18 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44Vx9c31Wdz1J0Q; Fri, 29 Mar 2019 10:23:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> Date: Fri, 29 Mar 2019 10:23:16 +0100 Cc: "secdispatch@ietf.org" , core X-Mao-Original-Outgoing-Id: 575544194.308044-3bb2360a435ca45f0590dafeb59de71c Content-Transfer-Encoding: quoted-printable Message-Id: <438BFA1F-5EA3-4B8E-A04F-EF643A8725E3@tzi.org> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> To: Roman Danyliw X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [Secdispatch] EDHOC Summary 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, 29 Mar 2019 09:23:29 -0000 The CoRE WG is the owner of the OSCORE specification that is often best = used in conjunction with a low-resource authenticated key agreement = mechanism. At the Friday CoRE meeting at IETF104, we discussed the actions proposed = below.=20 Among the 30 WG members in the room, we had in-room consensus that they = are the best way forward. Gr=C3=BC=C3=9Fe, Carsten > On Mar 28, 2019, at 11:32, Roman Danyliw wrote: >=20 > Hi! >=20 > We have observed the continued discussion and interest in the topics = discussed at the March 2019 Virtual Interim Secdispatch meeting [1]. = Our assessment of the current state of this discuss and as well as = proposed next steps are below. >=20 > Regards, > Roman and Ben >=20 > [1] = https://mailarchive.ietf.org/arch/msg/secdispatch/9AfqrecZfFMlMGxSXOo4ENZt= rVk >=20 > =3D=3D[ Summary of ADs ]=3D=3D > EDHOC Summary >=20 > -----[ 1. What is the problem we are faced with? >=20 > The community needs an AKE that is 'lightweight' (per slide #3 of [2]) = and enables forward security for constrained environments using OSCORE = [13]. 'Lightweight' refers to: >=20 > ** resource consumption, measured by bytes on the wire, wall-clock = time to complete (i.e., the initial latency added to application = protocols by the AKE), or power (per slide #12 of [2]) > ** the amount of new code required on end systems which already have = an OSCORE stack [4]=20 >=20 > -----[ 2. Is the problem understood and narrowly scoped? >=20 > Use with OSCORE implicitly assumes that this AKE would support: > ** transport over CoAP, and > ** COSE algorithms >=20 > The specific constrained environments that we are considering use = NB-IoT, 6TiSCH, and LoRaWAN. The desire is to optimize the AKE to be = 'as [small] ... as reasonably achievable' (per [3]) in these = environments. >=20 > ** With respect to 6TiSCH, IETF consensus on the 6TiSCH WG charter has = already identified the need to "secur[e] the join process and mak[e] = that fit within the constraints of high latency, low throughput and = small frame sizes that characterize IEEE802.15.4 TSCH." [12]. > ** With respect to NB-IoT and LoRaWAN, IETF consensus on the LPWAN WG = charter has identified the need to improve the transport capabilities of = LPWA networks such as NB-IoT and LoRa whose "common traits include ... = frame sizes ... [on] the order of tens of bytes transmitted a few times = per day at ultra-low speeds" [16]. This indicates IETF interest in = supporting these radio environments, though no security-specific = requirements are included in the charter. >=20 > It may be necessary to evaluate options that make different trade-offs = across a number of dimensions. >=20 > ** Per 'bytes on the wire', it is desirable for these AKE messages to = fit into the MTU size of these protocols; and if not possible, within as = few frames as possible. Note that using multiple MTUs can have = significant costs in terms of time and power (listed below). For 6TiSCH = specifically, as a time-sliced network, this metric (or rather, the = quantization into frame count) is particularly noteworthy, since more = frames contribute to congestion for spectrum (and concomitant error = rates) in a non-linear way, especially in scenarios when large numbers = of independent nodes are attempting to execute an AKE to join a network. >=20 > ** Per 'time', it is desirable for the AKE message exchange(s) to = complete in a reasonable amount of time, both for a single uncongested = exchange and when multiple exchanges are running in an interleaved = fashion. This latency may not be a linear function depending on = congestion and the specific radio technology used. For LoRaWAN, which = is legally required to use a 1% (or smaller) duty cycle, a payload split = into two fragments instead of one increases the time to complete the = sending of this payload by 10,000% (per slide #10 of [2]). =20 >=20 > ** Per 'power', it is desirable for the transmission of AKE messages = and crypto to draw as little power as possible The best mechanism for = doing so differs across radio technologies. For example, NB-IoT uses = licensed spectrum and thus can transmit at higher power to improve = coverage, making the transmitted byte count relatively more important = than for other radio technologies. In other cases, the radio = transmitter will be active for a full MTU frame regardless of how much = of the frame is occupied by message content, which makes the byte count = less sensitive for the power consumption. Increased power consumption = is unavoidable in poor network conditions, such as most wide-area = settings including LoRaWAN. >=20 > ** Per 'new code', it is desirable to introduce as little new code as = possible onto OSCORE-enabled devices to support this new AKE. These = devices have on the order of 10s of kB of memory and 100s of kB of = storage on which an embedded OS; a COAP stack; CORE and AKE libraries; = and target applications would run. It is expected that the majority of = this space is available for actual application logic, as opposed to the = support libraries. >=20 > A key question to answer is whether any new solution will reduce these = properties to a sufficient extent to merit investment. >=20 > -----[ 3. Do we believe it is possible to engineer a solution? >=20 > EDHOC [1] appears to be an existence proof that it is possible to = produce an AKE that meaningfully reduces the costs across at least two = dimensions identified in question #1 and 2 (bytes and time). =20 >=20 > EDHOC appears to favorably outperform TLS/CoAP, the current = technology, relative to these dimensions.=20 >=20 > ** Per 'bytes on the wire', MTU sizes and their alignment to the size = of messages of EDHOC vs. TLS/CoAP can be found in slide #33 of [2], and = in [5]. Additional details for 6TiSCH in particular can be found in = slide 36-37 of [2]. >=20 > ** Per 'time', the latency due to back-off time estimates with EDHOC = vs. TLS/CoAP using LoRaWAN can be found in slide #39 of [2] >=20 > ** Per 'power', estimates of the power usage of EDHOC vs TLS/CoAP = using NB-IoT can be found in slide #35 of [2]=20 >=20 > ** Per 'new code', being able to reuse primitives from the existing = COSE stack is expected to benefit the code size for EDHOC, but no hard = data is yet available for comparison. =20 >=20 > Exploratory work with cTLS [10] and femtoTLS [11] has suggested that = certain optimizations used in EDHOC can also be applied to a = TLS/CoAP-variant. How this impacts the original assumptions and = security analysis for (D)TLS is unknown.=20 >=20 > -----[ 4. Is this particular proposal a good basis for working on?=20 >=20 > EDHOC shows gains in defining an AKE with forward secrecy that is = 'reasonably small[er]' than the baseline of (D)TLS. Specifically, it = appears that EDHOC would enable: > ** for 6TiSCH, a more efficient network join operation, with network = join traffic fitting in one frame per flight (that is, the optimal = possible behavior) in up to a 5-hop network [17] > ** for LoRaWAN, an AKE with forward secrecy that avoids the = unacceptable backoff-induced latency=20 >=20 > A limited interop was performed on draft-selander-ace-cose-ecdhe-05 = (EDHOC) at IETF 98 between [14] and [15]. Despite the inherent = challenges of producing a new AKE that is secure, there is reason to = have confidence in the security claims made by EDHOC -- the security = properties of -08 were formally verified by [8][9]. Identified issues = from this formal analysis [8] were addressed in -11. The CFRG crypto = review panel conducted two reviews [6][7]. These reviews confirmed that = the security claims are reasonable, attested that the identified issues = found in the formal analysis [8] were fixed, and provided additional = recommendations. >=20 > Re-encoding of the TLS handshake as suggested by cTLS [10] may be = possible. However, as of yet, cTLS is an incomplete specification, cTLS = has no formal security analysis, and is technically a new protocol. >=20 > -----[ Conclusion >=20 > There appears to be an understood and scoped problem that is feasible = to engineer. Among the available starting points to address the problem = defined in question #1, EDHOC presents a viable choice. =20 >=20 > Chartering a narrowly scoped, short-lived WG in this space with EDHOC = as a starting point seems to be an attractive path forward, but we would = like to receive community feedback on the degree of support for this = approach. >=20 > -----[ References > [1] https://www.ietf.org/id/draft-selander-ace-cose-ecdhe-13.txt > [2] = https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials= /slides-interim-2019-secdispatch-01-sessa-edhoc.pdf > [3] = https://mailarchive.ietf.org/arch/msg/secdispatch/-GPqswnS-DRvrAKsPbdoes4Y= 4lE > [4] = https://mailarchive.ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril-wIV= n_0 > [5] = https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsM= Ulh-k > [6] = https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8 > [7] = https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ > [8] https://alessandrobruni.name/papers/18-edhoc.pdf > [9] https://github.com/theisgroenbech/edhoc-proverif > [10] https://tools.ietf.org/html/draft-rescorla-tls-ctls-01 > [11] https://github.com/bifurcation/mint/compare/ftls > [12] https://datatracker.ietf.org/doc/charter-ietf-6tisch/ > [13] https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ > [14] https://github.com/alexkrontiris/EDHOC-C > [15] https://github.com/jimsch/EDHOC-csharp > [16] https://datatracker.ietf.org/doc/charter-ietf-lpwan/ > [17] = https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-jo= in >=20 > =3D=3D[ End ]=3D=3D >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch >=20 From nobody Fri Mar 29 04:04:24 2019 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 E4855120271 for ; Fri, 29 Mar 2019 04:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTflUhZMp4wd for ; Fri, 29 Mar 2019 04:04:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BCA12026A for ; Fri, 29 Mar 2019 04:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20826; q=dns/txt; s=iport; t=1553857458; x=1555067058; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Eo7h42mXP+wTc0mqiPy55lmNV3kmihyEe0Vkg3dA3xY=; b=Cx0lmEEMeRgKi2JEDoN4G5OQnpMY5TiEwgWq3eWwpkbgiSvv3sGSTSqa bDp/G6BW0rffiYwUZV1Js9tM1DcmfBjGH374i/tDOtqWvyzCH+yAJG8OY y6yeKblmz4Mod8+F7Q0iGNjYmZ5S1bsokZE6X6+VQO1kLeakZlN9Cx0zt 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACF+51c/5FdJa1aChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYEOgQJogQMnCoQEiByLKYINkkWFdxS?= =?us-ascii?q?BZw0BARgBCoRJAheFICI0CQ0BAQMBAQkBAwJtHAyFSgEBAQQBASEKQRsCAQY?= =?us-ascii?q?CEQQBAQEnAwICAiULFAkIAgQBEggGgxWBdQ+NRZtmgS+ENAIOQYUeD4EvAYs?= =?us-ascii?q?xF4FAP4ERgxI+gmEBAQIBARaBDw1hglSCVwOMeYQilBAJAoRlgwWGAIVTIoI?= =?us-ascii?q?DXYUlikqBPYsshgmNMQIRFYEuDRI4gVZwFRohgmwJgg0Xg0uFFIU/QTGOVoE?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.60,284,1549929600"; d="scan'208,217";a="530466411" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Mar 2019 11:04:12 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2TB4CNn023297 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Mar 2019 11:04:12 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 06:04:11 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 29 Mar 2019 06:04:11 -0500 From: "Rob Wilton (rwilton)" To: ivaylo petrov , "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-sid-06.txt Thread-Index: AQHU5bJfckruPp1PlkWr7DQgfIKwn6Yh7c6AgAB/fEA= Date: Fri, 29 Mar 2019 11:04:11 +0000 Message-ID: References: <155381071244.1414.15110813535407686735@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.63.23.177] Content-Type: multipart/mixed; boundary="_004_a38236292e544680ac61d3708bf5c1e7XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-sid-06.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: Fri, 29 Mar 2019 11:04:23 -0000 --_004_a38236292e544680ac61d3708bf5c1e7XCHRCD007ciscocom_ Content-Type: multipart/alternative; boundary="_000_a38236292e544680ac61d3708bf5c1e7XCHRCD007ciscocom_" --_000_a38236292e544680ac61d3708bf5c1e7XCHRCD007ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSXZheWxvLA0KDQpJIGhhdmUgbWFkZSBjb21tZW50cyBvbiB0aGUgLTA1IHZlcnNpb24sIGFu ZCB0aGUgc2FtZSBjb21tZW50cyBvbiBwcmV2aW91cyB2ZXJzaW9ucywgdGhhdCBoYXZlIGJlZW4g ZGlzY3Vzc2VkIHdpdGggQ2Fyc3RlbiB0d2ljZSwgYnV0IHRoZXNlIGNvbW1lbnRzIGhhdmUgbm90 IGdvbmUgYW55IGZ1cnRoZXIgd2l0aG91dCBhbnkgZXhwbGFuYXRpb24gd2h5LiAgUGVyaGFwcyB0 aGV5IGhhdmUganVzdCBiZWVuIG1pc3NlZD8NCg0KUGxlYXNlIGNhbiB5b3UgY2hlY2sgYmFjayBv biB0aG9zZSB0aHJlYWRzIGFuZCBlaXRoZXIgaW5jb3Jwb3JhdGUgdGhlIGFwcHJvcHJpYXRlIGNo YW5nZXMgaW50byB0aGUgZHJhZnQsIG9yIGV4cGxhaW4gd2h5IHlvdSBkb27igJl0IHdhbnQgdG8g bWFrZSB0aGVtLg0KDQpLaW5kIHJlZ2FyZHMsDQpSb2INCg0KDQpGcm9tOiBjb3JlIDxjb3JlLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBpdmF5bG8gcGV0cm92DQpTZW50OiAyOCBNYXJj aCAyMDE5IDIyOjA4DQpUbzogY29yZUBpZXRmLm9yZw0KQ2M6IGktZC1hbm5vdW5jZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtjb3JlXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNvcmUtc2lkLTA2 LnR4dA0KDQpEZWFyIGFsbCwNCg0KVGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBzaWQgZHJhZnQgaXMg dXBsb2FkZWQgdG8gdGhlIGRhdGF0cmFja2VyLiBJdCBpcyB0aGUgcmVzdWx0IG9mIGEgbnVtYmVy IG9mIGRpc2N1c3Npb25zIHdpdGggSUFOQSByZXByZXNlbnRhdGl2ZXMuIFBsZWFzZSByZXZpZXcg aXQgYW5kIGRvbid0IGhlc2l0YXRlIHRvIGNvbnRhY3QgdXMgaWYgeW91IGhhdmUgYW55IHF1ZXN0 aW9ucyBvciBjb21tZW50cy4NCg0KQmVzdCByZWdhcmRzLA0KSXZheWxvDQoNCg0KT24gVGh1LCBN YXIgMjgsIDIwMTkgYXQgMTE6MDUgUE0gPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYuLm9yZz4+IHdyb3RlOg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3Jp ZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb25zdHJhaW5lZCBSRVNUZnVs IEVudmlyb25tZW50cyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAg OiBZQU5HIFNjaGVtYSBJdGVtIGlEZW50aWZpZXIgKFNJRCkNCiAgICAgICAgQXV0aG9ycyAgICAg ICAgIDogTWljaGVsIFZlaWxsZXR0ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBBbGV4YW5k ZXIgUGVsb3YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgSXZheWxvIFBldHJvdg0KICAgICAg ICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWNvcmUtc2lkLTA2LnR4dA0KICAgICAgICBQ YWdlcyAgICAgICAgICAgOiAyOQ0KICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE5LTAzLTI4 DQoNCkFic3RyYWN0Og0KICAgWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVycyAoU0lEKSBhcmUg Z2xvYmFsbHkgdW5pcXVlIDY0LWJpdA0KICAgdW5zaWduZWQgbnVtYmVycyB1c2VkIHRvIGlkZW50 aWZ5IFlBTkcgaXRlbXMuICBUaGlzIGRvY3VtZW50IGRlZmluZXMNCiAgIHRoZSBzZW1hbnRpY3Ms IHRoZSByZWdpc3RyYXRpb24sIGFuZCBhc3NpZ25tZW50IHByb2Nlc3NlcyBvZiBTSURzLg0KICAg VG8gZW5hYmxlIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGVzZSBwcm9jZXNzZXMsIHRoaXMgZG9j dW1lbnQgYWxzbw0KICAgZGVmaW5lcyBhIGZpbGUgZm9ybWF0IHVzZWQgdG8gcGVyc2lzdCBhbmQg cHVibGlzaCBhc3NpZ25lZCBTSURzLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1jb3JlLXNpZC8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMg YXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29y ZS1zaWQtMDYNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi1jb3JlLXNpZC0wNg0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp bGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1j b3JlLXNpZC0wNg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rv b2xzLmlldGYub3JnPi4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFp bGluZyBsaXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= --_000_a38236292e544680ac61d3708bf5c1e7XCHRCD007ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkhpIEl2YXlsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkkgaGF2ZSBtYWRlIGNvbW1lbnRzIG9uIHRoZSAtMDUgdmVyc2lvbiwgYW5kIHRo ZSBzYW1lIGNvbW1lbnRzIG9uIHByZXZpb3VzIHZlcnNpb25zLCB0aGF0IGhhdmUgYmVlbiBkaXNj dXNzZWQgd2l0aCBDYXJzdGVuIHR3aWNlLCBidXQNCiB0aGVzZSBjb21tZW50cyBoYXZlIG5vdCBn b25lIGFueSBmdXJ0aGVyIHdpdGhvdXQgYW55IGV4cGxhbmF0aW9uIHdoeS4mbmJzcDsgUGVyaGFw cyB0aGV5IGhhdmUganVzdCBiZWVuIG1pc3NlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlBsZWFzZSBjYW4geW91IGNoZWNrIGJhY2sgb24gdGhvc2UgdGhyZWFkcyBh bmQgZWl0aGVyIGluY29ycG9yYXRlIHRoZSBhcHByb3ByaWF0ZSBjaGFuZ2VzIGludG8gdGhlIGRy YWZ0LCBvciBleHBsYWluIHdoeSB5b3UgZG9u4oCZdA0KIHdhbnQgdG8gbWFrZSB0aGVtLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+S2luZCByZWdhcmRzLDxicj4NClJv YjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IGNvcmUgJmx0O2NvcmUtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8 L2I+aXZheWxvIHBldHJvdjxicj4NCjxiPlNlbnQ6PC9iPiAyOCBNYXJjaCAyMDE5IDIyOjA4PGJy Pg0KPGI+VG86PC9iPiBjb3JlQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtjb3JlXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLWNvcmUtc2lkLTA2LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMEI1Mzk0Ij5EZWFyIGFsbCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwQjUzOTQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzBCNTM5NCI+VGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBz aWQgZHJhZnQgaXMgdXBsb2FkZWQgdG8gdGhlIGRhdGF0cmFja2VyLiBJdCBpcyB0aGUgcmVzdWx0 IG9mIGEgbnVtYmVyIG9mIGRpc2N1c3Npb25zIHdpdGggSUFOQSByZXByZXNlbnRhdGl2ZXMuIFBs ZWFzZSByZXZpZXcgaXQgYW5kIGRvbid0IGhlc2l0YXRlIHRvDQogY29udGFjdCB1cyBpZiB5b3Ug aGF2ZSBhbnkgcXVlc3Rpb25zIG9yIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzBCNTM5NCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMEI1Mzk0Ij5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMEI1Mzk0Ij5JdmF5bG88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMjgs IDIwMTkgYXQgMTE6MDUgUE0gJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi4ub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMu PGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29uc3RyYWluZWQgUkVTVGZ1 bCBFbnZpcm9ubWVudHMgV0cgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs6IFlBTkcgU2NoZW1hIEl0ZW0gaURlbnRpZmllciAoU0lEKTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzog TWljaGVsIFZlaWxsZXR0ZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBB bGV4YW5kZXIgUGVsb3Y8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSXZh eWxvIFBldHJvdjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtY29yZS1zaWQtMDYudHh0PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs6IDI5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERh dGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTktMDMtMjg8 YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7WUFORyBTY2hlbWEgSXRlbSBp RGVudGlmaWVycyAoU0lEKSBhcmUgZ2xvYmFsbHkgdW5pcXVlIDY0LWJpdDxicj4NCiZuYnNwOyAm bmJzcDt1bnNpZ25lZCBudW1iZXJzIHVzZWQgdG8gaWRlbnRpZnkgWUFORyBpdGVtcy4mbmJzcDsg VGhpcyBkb2N1bWVudCBkZWZpbmVzPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBzZW1hbnRpY3MsIHRo ZSByZWdpc3RyYXRpb24sIGFuZCBhc3NpZ25tZW50IHByb2Nlc3NlcyBvZiBTSURzLjxicj4NCiZu YnNwOyAmbmJzcDtUbyBlbmFibGUgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZXNlIHByb2Nlc3Nl cywgdGhpcyBkb2N1bWVudCBhbHNvPGJyPg0KJm5ic3A7ICZuYnNwO2RlZmluZXMgYSBmaWxlIGZv cm1hdCB1c2VkIHRvIHBlcnNpc3QgYW5kIHB1Ymxpc2ggYXNzaWduZWQgU0lEcy48YnI+DQo8YnI+ DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWNvcmUtc2lkLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtY29yZS1zaWQvPC9hPjxicj4NCjxicj4NClRoZXJlIGFyZSBhbHNv IGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLXNpZC0wNiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtc2lkLTA2PC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi1jb3JlLXNpZC0wNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLXNpZC0wNjwvYT48YnI+DQo8YnI+DQpBIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY29yZS1zaWQt MDYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1jb3JlLXNpZC0wNjwvYT48YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRv b2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jb3JlQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29y ZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y29yZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_a38236292e544680ac61d3708bf5c1e7XCHRCD007ciscocom_-- --_004_a38236292e544680ac61d3708bf5c1e7XCHRCD007ciscocom_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 29 Mar 2019 11:04:10 GMT"; modification-date="Fri, 29 Mar 2019 11:04:10 GMT" Received: from xch-rtp-007.cisco.com (64.101.220.147) by xch-rcd-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Mailbox Transport; Fri, 15 Mar 2019 10:42:58 -0500 Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 15 Mar 2019 11:42:57 -0400 Received: from rcdn-iport-5.cisco.com (173.37.86.76) by mail.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 15 Mar 2019 11:42:57 -0400 Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Mar 2019 15:42:54 +0000 Received: from alln-inbound-d.cisco.com (alln-inbound-d.cisco.com [173.37.147.234]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x2FFgsOV016653 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 15 Mar 2019 15:42:54 GMT Received: from mailhost.informatik.uni-bremen.de ([IPv6:2001:638:708:30c9::12]) by alln-inbound-d.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Mar 2019 15:42:32 +0000 Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x2FFgNCc015386; Fri, 15 Mar 2019 16:42:28 +0100 (CET) Received: from [IPv6:2001:638:708:30da:350e:7c7:5611:1727] (unknown [IPv6:2001:638:708:30da:350e:7c7:5611:1727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44LVFW09Txz1Bp8; Fri, 15 Mar 2019 16:42:22 +0100 (CET) From: Carsten Bormann To: "Rob Wilton (rwilton)" CC: Michael Richardson , "cbor@ietf.org" , "core@ietf.org" Subject: Re: [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 Thread-Topic: [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 Thread-Index: AQHU0if+rkpVL8iC4E+Vyl/vbXGKcaYMvJmQgAB+RAA= Date: Fri, 15 Mar 2019 15:42:22 +0000 Message-ID: References: <21467.1551662213@localhost> <92df97c1457947f09a2de92d740de925@XCH-RCD-007.cisco.com> In-Reply-To: <92df97c1457947f09a2de92d740de925@XCH-RCD-007.cisco.com> Content-Language: en-GB X-MS-Exchange-Organization-AuthSource: XCH-RTP-010.cisco.com X-MS-Has-Attach: X-MS-TNEF-Correlator: received-spf: None (alln-inbound-d.cisco.com: no sender authenticity information available from domain of postmaster@mailhost.informatik.uni-bremen.de) identity=helo; client-ip=2001:638:708:30c9::12; receiver=alln-inbound-d.cisco.com; envelope-from="cabo@tzi.org"; x-sender="postmaster@mailhost.informatik.uni-bremen.de"; x-conformance=spf_only Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 T24gTWFyIDE1LCAyMDE5LCBhdCAxNDoyNCwgUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25A Y2lzY28uY29tPiB3cm90ZToNCj4NCj4gSW4gc2hvcnQsIEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBi ZSBtb3JlIHByYWdtYXRpYyBpZiBTSURzIGFyZSByZXN0cmljdGVkIHRvIHRoZSBub24tbmVnYXRp dmUgcmFuZ2Ugb2YgdGhlIHNpZ25lZCA2NCBiaXQgaW50ZWdlciB0eXBlLiAgSS5lLiBkaXNhbGxv dyB2YWx1ZXMgZnJvbSAoMl42MyB0aHJvdWdoIDJeNjQgLSAxKS4NCg0KU0lEcyBhcmUgdW5zaWdu ZWQgaW50ZWdlcnMuICBIb3dldmVyLCB0aGVyZSBhcmUgc3RpbGwgbGFuZ3VhZ2VzIHRoYXQgaGF2 ZSBhIGhhcmQgdGltZSB3aXRoIHRob3NlLiAgQW5kIGl0IGhlbHBzIGlmIGFsbCBTSUQgZGVsdGFz IGZpdCBpbnRvIGEgc2lnbmVkIDY0LWJpdCBpbnRlZ2VyLg0KU28gbWF5YmUgbGltaXRpbmcgU0lE cyB0byB0aGUgKG5vbi1uZWdhdGl2ZSkgcmFuZ2Ugb2Ygc2lnbmVkIDY0LWJpdCBpbnRlZ2VycyBp cyBhIHJlc3RyaWN0aW9uIHRoYXQgbWFrZXMgc2Vuc2UuDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9j b3JlLXdnL3lhbmctY2JvciBoYXMgdGhyZWUgcHVsbCByZXF1ZXN0cywgYnV0IG5vIGlzc3Vlcy4N CihUaGlzIGFwcGFyZW50bHkgYWxzbyBoYXBwZW5zIHRvIGJlIHRoZSByZXBvIGZvciB0aGUgU0lE IHNwZWNpZmljYXRpb24uKQ0KDQpTaG91bGQgd2UgcHV0IHVwIHRoZSBpc3N1ZXMgdGhlcmU/DQoN Ckdyw7zDn2UsIENhcnN0ZW4NCg0K --_004_a38236292e544680ac61d3708bf5c1e7XCHRCD007ciscocom_-- From nobody Fri Mar 29 12:34:44 2019 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 2F3741202DA; Fri, 29 Mar 2019 12:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 biMHZUXaKjnK; Fri, 29 Mar 2019 12:34:40 -0700 (PDT) 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 776AB120304; Fri, 29 Mar 2019 12:34:37 -0700 (PDT) Received: from Jude (62.168.35.125) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 29 Mar 2019 12:34:31 -0700 From: Jim Schaad To: CC: Date: Fri, 29 Mar 2019 20:34:25 +0100 Message-ID: <012e01d4e666$6d291a90$477b4fb0$@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: AdTmZZECUL3REi7MT9avKUcTbpATeA== Content-Language: en-us X-Originating-IP: [62.168.35.125] Archived-At: Subject: [core] Mail regarding draft-zcao-core-speedy-blocktran 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, 29 Mar 2019 19:34:43 -0000 In today's F2F meeting one of the reasons for doing this that was brought up was that this would be more efficient under a TCP situation. I would like to point out that the BERT extension in the TCP (Section 6 of RFC 8323) is designed so that multiples of 1024B blocks can be sent as a single block operation. Additionally, it would be possible to just get an entire huge response in a single GET although this may cause problems with the network processing for the device. For these reasons I do not believe that this is a protocol that should ever be thought of as running over a reliable transport. Much better options already exist. Jim