[core] pubsub review

Peter van der Stok <stokcons@bbhmail.nl> Thu, 24 January 2019 18:14 UTC

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_c5ccb014e3757d36227ea75fce2e0edb"
Date: Thu, 24 Jan 2019 19:14:45 +0100
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Core <core@ietf.org>
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: <0cc85dc403a5329a6af0f81bf63861c3@bbhmail.nl>
User-Agent: Roundcube Webmail/1.2.7
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/X92xtF6uxMmH_2sAWVFxpTje22Q>
Subject: [core] pubsub review
Precedence: list

Hi Michael,

The document is progressing nicely but still needs some work.

Below my main comments:

Brokerless pub/sub is very confusing, because there is a broker,
Simply saying in the introduction that the broker is a server that can
be installed on any device, and that the broker can be present on the
same device as a client is more than enough.

I don't understand why the first publication can create a subtopic
without creating the parent and the Create cannot.
Why is there a CREATE anyway? Would be nice if this is motivated.

What about the lifetime of the subscribers. It is non-existent but makes
the lifetime of the subscriber very different over all implementations.
A defaut lifetime would be appreciated.

A table covering the use of POST and PUT for PUBLISH and CREATE with a
short motivation would be welcome.

An update of the resource-discovery text is really needed. You can use
the terms like simple registration and refer to the section numbers.
context is non-existent these days.

Sleep-wake operation.
Nice that you address the sleepy nodes, bur it really deserves more
text. First the context of sleepy node , proxy and client needs
description. Some text is available in Zotti draft.
Followed by a mapping of pubsub functionlity to wanted sleepy-node
functionality.
Also the update of a sleepy node by a client warrants some text. If you
think that this is too much honor for the subject, I suggest to remove
section 6.

Security considerations:
You do not mention the resource exhaustion by creating too many topics.
May I suggest to look at draft-ietf-ace-key-groupcomm-00 and provide 
some concrete links to that draft, possibly with examples?

Some text:
s/receival/reception
3.2 Broker needs to be reachable to its clients (not all)
section 4.3 first paragraph seems to contradict second paragraph (MUST,
MAY)

hope this is relevant,
cheerio,

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

[core] pubsub review Peter van der Stok