[core] Review of draft-ietf-core-coap-pubsub-06
Jim Schaad <ietf@augustcellars.com> Thu, 10 January 2019 00:21 UTC
Return-Path: <ietf@augustcellars.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 8D31812DDA3; Wed, 9 Jan 2019 16:21:52 -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 h2fVDLaJHjK3; Wed, 9 Jan 2019 16:21:50 -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 8A69812D4F0; Wed, 9 Jan 2019 16:21:50 -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, 9 Jan 2019 16:21:44 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-core-coap-pubsub@ietf.org
CC: core@ietf.org
Date: Wed, 09 Jan 2019 16:21:40 -0800
Message-ID: <011001d4a87a$76f82f40$64e88dc0$@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: AdSoYpc9WpNBdaL4QWqOngnIYB9bOw==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/5-OySY_ku3hj18yamZwx5yMCHyw>
Subject: [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" <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: Thu, 10 Jan 2019 00:21:53 -0000
Here is a more detailed review of this document: 1. Section 2 - You should update the keywords with text from RFC 8174 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 3. Section 3.5 - I think that the brokerless in the title should be capitalized. 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. 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. 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. 7. Section 4.1 - I am not completely clear on this. Is DISCOVERY only supported by rt=coap.ps.discovery or is it also supported by rt=coap.ps? 8. Section 4.1 - Is discovery only permitted to find those resources which are subordinate to it for rt=coap.ps.discovery or can it search all topics published in the PS? 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. 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. 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. 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. Jim
- [core] Review of draft-ietf-core-coap-pubsub-06 Jim Schaad
- Re: [core] Review of draft-ietf-core-coap-pubsub-… Carsten Bormann
- Re: [core] Review of draft-ietf-core-coap-pubsub-… Michael Koster
- Re: [core] Review of draft-ietf-core-coap-pubsub-… Jim Schaad