Re: [core] Chair's review of draft-ietf-core-resource-directory-19

Jaime Jiménez <jaime.jimenez@ericsson.com> Fri, 01 March 2019 12:05 UTC

Return-Path: <jaime.jimenez@ericsson.com>
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 <core@ietfa.amsl.com>; 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 <core@ietfa.amsl.com>; 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 <core@ietf.org>; 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=?= <jaime.jimenez@ericsson.com>
To: =?utf-8?B?Q2hyaXN0aWFuIE0uIEFtc8O8c3M=?= <christian@amsuess.com>
CC: core <core@ietf.org>, Carsten Bormann <cabo@tzi.org>, "draft-ietf-core-resource-directory@ietf.org" <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: <E80F6DD3-0483-432B-86C9-CBBBD242F95E@ericsson.com>
References: <AM5PR0701MB2307AF330344860328775506977F0@AM5PR0701MB2307.eurprd07.prod.outlook.com> <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: <AM5PR0701MB2324FB5A751B127F7EC2173C97760@AM5PR0701MB2324.eurprd07.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/core/wy46a4ywpH-WIPr3AMEbvvSrkrk>
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" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2019 12:05:24 -0000

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>
>>            <PAYLOAD>
>> <Response>: <Code>
>>            <PAYLOAD>
>> 
>> Which in markdown would look like:
>> ~~~~
>>  Int: EP -> IPv6 Multicast Address (FF0X::FE) or [MCD1]
>>  Req: GET coap://[MCD1]/.well-known/core?rt=core.rd*
>>  Res: 2.05 Content
>>       </rd>;rt="core.rd";ct=40,
>>       </rd-lookup/ep>;rt="core.rd-lookup-ep";ct=40,
>>       </rd-lookup/res>;rt="core.rd-lookup-res";ct=40,
>> ~~~~
>> 
> 
> 
>> 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-directory-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’s 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’t know any. I just assumed that it’d 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 – 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 “Registration" to “RD Registration”. 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’s 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-20180710-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 ≤ 63 bytes. But we need to say that it is a UTF-8 string. Not entirely sure we want 😈👄👽 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:########-####-####-####-############” and ”🤔💡🤘”
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