Subject: [Ace] Francesca Palombini's Discuss on draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Thu, 10 Mar 2022 02:03:18 -0800

Francesca Palombini has entered the following ballot position for
draft-ietf-ace-mqtt-tls-profile-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Updating my ballot after reviewing draft-ietf-ace-aif-06. Just want to make
sure we don't miss anything, please feel free to correct me if I missed the
mark here.

FP: https://datatracker.ietf.org/doc/html/draft-ietf-ace-aif-06#section-4
states:

default values are the values "URI-local-
   part" for Toid and "REST-method-set" for Tperm, as per Section 3 of
   the present specification.

   A specification that wants to use Generic AIF with different Toid
   and/or Tperm is expected to request these as media type parameters
   (Section 5.2) and register a corresponding Content-Format
   (Section 5.3).

FP: I wonder if this document should define a new media type parameter for
Tperm (as REST-method-set is not appropriate for "pub"/"sub" value) and
register a corresponding Content-Format as indicated in the paragraph above.
CC'ing Carsten for his opinion.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work on this document

Many thanks to Jean Mahoney for her ART ART review:
https://mailarchive.ietf.org/arch/msg/art/REdbeKR0FBJ1CnVtKOUaJnaeONk/, and to
the authors for addressing it.

Only two minor comments easy to fix, see below.

Francesca

1. -----

FP: Please replace references to RFC7230 with draft-ietf-httpbis-semantics-19
which will obsolete it once published. Note that
draft-ietf-httpbis-semantics-19 is already with the RFC Editor so will not
delay publication of your document.

2. -----

Section 7.3

FP: I believe this profile should be registered in the Standards track portion
of the registry - please add a note about it so that IANA is aware, changing
for example:

OLD:
*  CBOR Value: To be assigned by IANA
NEW:
*  CBOR Value: To be assigned by IANA in the (-256, 255) range

---

From: Cigdem Sengul <[email-masked]>
Date: Thu, 10 Mar 2022 11:56:47 +0000

Hello Francesca,

Thank you for your feedback. My response is below.

On Thu, 10 Mar 2022 at 10:03, Francesca Palombini via Datatracker <
[email-masked]> wrote:

> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

CS: Since we considered this for the Broker's consumption using MQTT,
registration of a new media type looks like it was overlooked.
I assume you are raising this issue as the client may use the scope for
token requests using application/ace+json(cbor) application/aif+json(cbor)
If that is the case, I suggest the following text for AIF and  MQTT
Permissions registry (with Expert Review registration procedure) similar to
https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ -

AIF

   For the media-types application/aif+cbor and application/aif+json
   defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to
   register the following entries for the two media-type parameters Toid
   and Tperm, in the respective sub-registry defined in Section 5.2 of
   [I-D.ietf-ace-aif] within the "MIME Media Type Sub-Parameter"
   registry group.

   *  Name: mqtt-topic-filter

   *  Description/Specification: topic filter used in MQTT

   *  Reference: [[This document]]

   *  Name: mqtt-permissions

   *  Description/Specification: permissions for MQTT client.

   *  Reference: [[This document]]

  MQTT Permissions

   This document establishes the IANA "MQTT Permissions" registry.
   The registry has been created to use the "Expert Review" registration
   procedure [RFC8126].

   This registry includes the possible permissions of MQTT clients
when communicating
   with an MQTT broker.

   The columns of this registry are:

   *  Name: A value that can be used in documents for easier
      comprehension, to identify a possible permissions of MQTT clients.

   *  Description: This field contains a brief description of the permission.

   *  Reference: This contains a pointer to the public specification for
      the permission.

   This registry will be initially populated by the names "pub", "sub".

   The Reference column for all of these entries will be [[This
   document]].

Are there any other registries involved?
Thanks,

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 10 Mar 2022 12:35:13 +0000

Hi Cigdem,

Thank you for the quick reply!
The two additional registrations for the parameters Toid and Tperm look good, although I have a couple of suggestions:

  1.  For Toid I would add a reference to Section 1.3 (and maybe capitalize Topic Filter, just to be nitpicking). I would also mention that this is ancoded ass a text string (or point to section 2.3).
  2.  For Tperm, I don’t think it is needed to create an additional registry, unless you foresee that there might be need to add new methods other than “pub” and “sub” in the future, in which case I agree with you that the IANA registry is the best choice. If you don’t, I would remove the new registry and just mention that the Tperm is a text string with value either “pub” or “sub”, and reference section 2.3.
I think that should cover it. Again, Carsten’s opinion is welcome as the creator of the registry (lacking the Designated expert that is not yet assigned).

Francesca

From: Cigdem Sengul <[email-masked]>
Date: Thursday, 10 March 2022 at 12:57
To: Francesca Palombini <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Ace Wg <[email-masked]>, Daniel Migault <[email-masked]>, Carsten Bormann <[email-masked]>
Subject: Re: Francesca Palombini's Discuss on draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)
Hello Francesca,

On Thu, 10 Mar 2022 at 10:03, Francesca Palombini via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Francesca Palombini has entered the following ballot position for
draft-ietf-ace-mqtt-tls-profile-15: Discuss

CS: Since we considered this for the Broker's consumption using MQTT, registration of a new media type looks like it was overlooked.
I assume you are raising this issue as the client may use the scope for token requests using application/ace+json(cbor) application/aif+json(cbor)
If that is the case, I suggest the following text for AIF and  MQTT Permissions registry (with Expert Review registration procedure) similar to https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ -

AIF

   registry group.

   *  Name: mqtt-permissions

MQTT Permissions

   procedure [RFC8126].

   This registry includes the possible permissions of MQTT clients when communicating

   with an MQTT broker.

      the permission.

   document]].

Francesca

1. -----

2. -----

Section 7.3

OLD:

---

From: Cigdem Sengul <[email-masked]>
Date: Thu, 10 Mar 2022 12:42:39 +0000

Hello Francesca,

Thank you. I welcome these suggestions - I do not foresee other permission
keywords looking at the MQTT vocabulary (control packets); happy to
"hard-code" "pub" and "sub".
If there aren't any other opinions, I will implement them this way.
There are a  few other minor clarifications I am waiting for feedback, and
with those clarified, I will be ready to publish a new ID.

Kind regards,
--Cigdem

On Thu, 10 Mar 2022 at 12:35, Francesca Palombini <
[email-masked]> wrote:

> The two additional registrations for the parameters Toid and Tperm look
> good, although I have a couple of suggestions:
>
>    1. For Toid I would add a reference to Section 1.3 (and maybe
>    capitalize Topic Filter, just to be nitpicking). I would also mention that
>    this is ancoded ass a text string (or point to section 2.3).
>    2. For Tperm, I don’t think it is needed to create an additional
>    registry, unless you foresee that there might be need to add new methods
>    other than “pub” and “sub” in the future, in which case I agree with you
>    that the IANA registry is the best choice. If you don’t, I would remove the
>    new registry and just mention that the Tperm is a text string with value
>    either “pub” or “sub”, and reference section 2.3.
>
> I think that should cover it. Again, Carsten’s opinion is welcome as the
> creator of the registry (lacking the Designated expert that is not yet
> assigned).
>
>
>
>
>
> Francesca
>
>
>
> *From: *Cigdem Sengul <[email-masked]>
> *Date: *Thursday, 10 March 2022 at 12:57
> *To: *Francesca Palombini <[email-masked]>
> *Cc: *The IESG <[email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <
> [email-masked]>, Ace Wg <[email-masked]>, Daniel Migault <
> [email-masked]>, Carsten Bormann <[email-masked]>
> *Subject: *Re: Francesca Palombini's Discuss on
> draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)
>
> Hello Francesca,
>
>
>