[core] pubsub draft review
Peter van der Stok <stokcons@bbhmail.nl> Fri, 27 July 2018 08:03 UTC
Return-Path: <stokcons@bbhmail.nl>
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 0C41812F295 for <core@ietfa.amsl.com>; Fri, 27 Jul 2018 01:03:17 -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, HTML_MESSAGE=0.001, 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 kvmZNRsaAZee for <core@ietfa.amsl.com>; Fri, 27 Jul 2018 01:03:12 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0254.hostedemail.com [216.40.44.254]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E191130DC9 for <core@ietf.org>; Fri, 27 Jul 2018 01:03:11 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 8D64718016111; Fri, 27 Jul 2018 08:03:10 +0000 (UTC)
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:2:4:41:72:152:355:379:582:800:920:962:967:968:973:982:983:988:989:1152:1189:1208:1221:1260:1263:1313:1314:1345:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1617:1730:1776:1792:2196:2198:2199:2200:2525:2527:2553:2561:2564:2682:2685:2692:2693:2731:2737:2829:2859:2894:2895:2898:2902:2911:2924:2925:2926:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3586:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4051:4250:4321:4418:4419:4425:4557:4659:4860:5007:6119:6261:6298:6659:6678:7464:7774:7875:7903:7974:8603:8957:9010:9015:9025:9177:9388:9389:10848:11232:11657:11658:11914:12043:12219:12291:12295:12438:12555:12663:12679:12683:12895:12903:12986:13139:13144:13160:13161:13199:13229:13230:13548:13846:13869:13972:14096:14110:14149:21060:21063:21080:21433:21451:21525:21625:21691:30005:30025:30029:30034:30041:30045:30048:30054:30070:3007
X-HE-Tag: grain43_55dbc09653625
X-Filterd-Recvd-Size: 17598
Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf11.hostedemail.com (Postfix) with ESMTPA; Fri, 27 Jul 2018 08:03:09 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_443054dde2bf2f6f95960b9417c23da4"
Date: Fri, 27 Jul 2018 10:03:09 +0200
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Michael Koster <michaeljohnkoster@gmail.com>
Cc: Core <core@ietf.org>
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org, stokcons@bbhmail.nl
Mail-Reply-To: consultancy@vanderstok.org, stokcons@bbhmail.nl
Message-ID: <04f8af968af10d46c69c46aa1a437ddb@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
User-Agent: Roundcube Webmail/1.2.7
X-Originating-IP: [5.206.216.229]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/qhDfjl40libB3ZSzBBIKYuXq0g8>
Subject: [core] pubsub draft review
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.27
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, 27 Jul 2018 08:03:17 -0000
Hi Michael, below my review of the pubsub draft. My main focus was the alignment with RD draft, internal terminology and alignment with pubsub security draft. Please do not hesitate to question my suggestions. Hope this helps, Greetings, peter __________________________________________________________________________________ Review of PubSub broker for coap Section 2, Publish-Subscribe: OLD: The publishers do not (need to) know where the message will be eventually sent: the publications and subscriptions are matched by a Broker and publications are delivered by the Broker to subscribed receivers. NEW: The publishers do not (need to) know where the message will be eventually sent: the publication-messages and subscription-messages are matched by a Broker and publication-messages are delivered by the Broker to subscribed receivers. OLD: CoAP pub/sub Broker: A server node capable of receiving messages (publications) from and sending messages to other nodes, and able to match subscriptions and publications in order to route messages to the right destinations. NEW: CoAP pub/sub Broker: A server node capable of receiving publication-messages and subscription-messages and sending publication-messages to subscribing nodes, and able to match subscription-messages and publication-messages to route messages to the right destinations. What are notifications? They appear more often in the text. Are they observe messages? If so, introduce that in this section OLD: Topic: A unique identifier for a particular item being published and/or subscribed to. NEW: Topic: A unique message-identifier to match publication-messages and subscription-messages. Section 3.2 /clients to use to/clients to/ Section 3.3 Why introduce data-sinks and data sources. Not used anywhere else. Suggestion rephrase section 3.3 with other already introduced terminology. Section 3.4 The representation text is not very clear; do you mean: "The links of every topic are represented according to one or multiple content-formats" A suggestion to rephrase the topic name space: The topic name space is structured as a tree expressed as a resource path. The topic hierarchy is structured identically to the hierarchy of the URI path. Section 3.5 I don't understand. I do see brokers in Figure 2. How are they different from Figure 1? The location? IF yes, please clarify. Section 4.1 /the link relation rt=core.ps/the resource type value rt=core.ps/ 2nd al: …. a topic discovery entry point, called DISCOVER,…. Can figures 3 and 4 be moved up the text? Please use rt=ps.temperature instead of rt=temperature Everywhere: .well-known/core -> /.well-known/core Page 7: /{create}/{{create}} /limit amount/limit the amount/ OLD: The client can then perform discovery for the parent topics it wants to discover the sub-topics. NEW: The client can choose to discover the sub-topics from the discovered topic list. Everywhere: In URI template variable; please use same terminology and constraints as for RD. For example, /ps cannot be prescribed. It should be an example value used in the draft. Content-format: here only one is specified, where later in the text, and earlier multiple content-formats are allowed. "Success 2.05: SHOULD use the value /ps"; NO, Never SHOULD. /ps is an example path. Fig 3-5 two cts are allowed here?? 4.2 Create: /the target of the link/the reference of the link/ /for publishes to the topic/ to represent the topic links/ Page 9: "If a topic .. Figure 7"; I don't understand this sentence. /Ony one/Only one/ /used in the link target/ used in the URI reference of the link// /exactly one content format/at least one content format/ unless I have not understood anything earlier. /publishes to the topic/receiving any publication-messages for this topic/ /elided/not present/ ; elide is an action not a state. ".. with a target of an existing topic"; Don't understand this phrase. 4.3 PUBLISH "PUBLISH to topics on the broker" This is new not-introduced terminology; please continue with terminology of section 2. Concerning the paragraph: "A Broker MUST .. PUT requests": - Links are replaced not representations. - What is "resolution of notifications"? Page 12: do the figure 9 and 10 references in the text match the figures? Figure 8 and 9 Do "1033.3" represent the payload? Please explain. Does not follow from the template. Fig 10: no value in return of GET? Page 16: It only becomes clear now that the observe numbers 0, 1, etc have a meaning. It would be beneficial to explain that earlier with a table. 4.7 REMOVE; Is there a restriction on removal, like only the creating client can remove the topics it has created. To be enforced with PubSub security. Page19: OLD: 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. NEW: A client which registers pub/sub Topics with an RD MUST use the Registration Base URI parameter (base=) [I-D.ietf-core-resource-directory] to indicate that the Registration Base URI of the registered links is the pub/sub Broker. OLD: A CoAP pub/sub Broker may alternatively register links to its topics to a Resource Directory by triggering the RD to retrieve it's links from .well-known/core. NEW: A CoAP pub/sub Broker may alternatively use "Simple Registration", section 5.3.1. of [I-D.ietf-core-resource-directory], by triggering the RD to retrieve it's links from its resource /.well-known/core. Remove: "the pub/sub broker triggers .. further details" 6 Sleep-Wake operation I assume this section is about sleepy nodes and how to handle them. I don't think the statement that the broker keeps the state is correct. The Broker keeps publication messages which contain part of the state. Combining multiple messages about different topics from the same sleepy node may reconstitute the state. I recommend to change this section and write that for sleepy nodes it is recommended that a sleepy node provides only one topic that covers the whole state of the sleepy node. The draft should also point out that the update of the sleepy node or its reconfiguration is not covered. 7 Simple flow control /publish messages/publication messages/ 8 security considerations I don't think that end-to-end security solves your problems of the second paragraph; You also need Proof of possession. I don't understand the last paragraph: "Depending on the level .. to the subscribers". I am missing security objectives; see an example described in appendix A.2 of core-oscore-groupcomm. Once these objectives are described, it can be verified in pubsub-profile draft that they are realized. For example, I don't see any statement about which clients are authorized to delete topics. Probably section 6 followed by section 6.1 in ace-coap-pubsub-profile is closest to what is needed, but with much more pubsub functional details. -- 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
- [core] pubsub draft review Peter van der Stok