Subject: [core] Review of draft-ietf-core-coap-pubsub-06

From: Jim Schaad <[email-masked]>
Date: Wed, 9 Jan 2019 16:21:40 -0800

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Jan 2019 13:53:00 +0100

> have been the topic lifetime.

The default value for Max-Age is defined in RFC 7252 and cannot be altered here.

E.g., the sentence

   Broker SHOULD retain a
   topic indefinitely if the Max-Age option is elided or is set to zero
   upon topic creation. 

is broken as, if the option is elided, its value is 60.  Or, in other words, every CoAP message has a max-age, which is 60 (seconds) unless specified explicitly.

Also, using zero as indefinite value is very odd.  (Zero usually means “don’t cache”.)

Thank you for the review, Jim!

See you all in three hours (and, yes, the chairs are hammering together an agenda as I speak…)

Grüße, Carsten