[Ace] Review of draft-palombini-ace-coap-pubsub-profile-01

[Jim Schaad <[e-mail]>]

Here are some comments on this draft.

1.  I find it difficult to call this a profile of the Oauth document in one
way.  This looks to me more of a "This is how you use the Oauth" document.
This echoes a comment that I made on the ACE base Oauth document.

2.  Introduction:  I think you should give a (very) brief introduction into
the pub sub system here rather than assuming that people are going to read
the pub/sub draft first.

3.  Overview:  I have a slight problem with the title of this section.  To
me I would expect an "Overview" and an "Introduction" to be the same
section.  Think about combining the sections together or rename this section
to be more specific.

4.  Overview:  this is a nit - I think that you want a different term than
scenario here.

5.  Overview:  You need to expand and define RS and AS on first usage.

6.  Overview:  One of the things that I am not currently happy with is that
you are looking at AS1 and AS2 as being independent appliers of access
control logic without any communication between them.  I think that AS1
needs the ability to give policy to AS2 on a topic after it has been created
and before any subscribers get keys.  In the case they are co-resident this
is trivial, in other cases it may not be.

7. Overview:  It is not clear to me that your allocation of roles to AS1 and
AS2 I correct.  If you have a second publisher, does it need to talk to both
AS1 and AS2 or just to AS2?  Is this really an AS1 controls creation of
topics and AS2 controls publishing and subscribing to topics?  If the
publisher loses its membership in the group for any reason, should it be
able to publish willy-nilly anyway?  I.e. should AS2 be able to "revoke" the
publishers right to publish?

8.  Overview:  I don't think the picture is correct at the bottom of the
section.  You have a Publisher-Subscriber client/client association

9.   Overview:  Is there any expectation that the broker should be notified
on a "revocation" of a publisher's right to publish?  (As opposed to the
right just expiring.)  There is no need to enforce subscribers right to
subscribe since a key roll over means that they are getting gibberish.

10.  Section 3 - I would remove 'D' from the picture as it gets a confusion
between updating the tokens and publishing content.  It is covered just fine
by the core document.  If you are using it as a 'publish' operation, then it
does not belong in the first bullet point.  It could also be the difference
between pushing the token and getting a session.  Again I don't think these
need to be separate, that is clear from the core document and you are not
doing anything different.

11.  Section 3.1 - I don't' think that the returned info on the first
request is going to be the same for publishers and subscribers.  Not sure
what this should really look like.

12. Section 3.1 - I am unsure what you believe is going to be accomplished
by doing a RD lookup.  You can get the name of the resource, but it would
not necessarily return the AS1, AS2 strings.

13.  Section 3.1 - On the unauthorized response, I think you want to be
returning different responses to subscriber vs the broker.  A subscriber
does not need to know about AS1.  Also I think you should be using the same
tag as the base profile for at least one of them - probably the first one
you would contact.

14.  Section 3.1 - I am not sure that it makes any sense to set an audience.
If the scope is the topic then all information exists.  The audience really
the subscriber.

15. Section 3.1 - You state that the algorithm must be a CE algorithm, but I
think you mean a signing algorithm.

16.  Section 3.1 - why not use the cnf return value for the key?  Also there
is no reason to make it a bstr rather than a map.

17.  Section 3.1 - need to define a signers_keys element which returns all
of the signing keys.  Defined as an array of keys.  Return other signers for
multiple publishers.

18.  Section 3.2 - see above about strings to be returned here.

19.  Section 5 - Need to talk about how to deal with multiple publishers -
are you assigning different keys or are you using different IV sections?
Need to ensure that you don't have an error from using the same key/iv pair.

20.  Section 5 - Are you containing a coap payload or a complete coap
message in the payload.  

21.  Section 5.  Do you want to talk about coordination of the observer
number and the iv of a message?