Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

Hello Hannes,

Thank you very much for your comments. My responses are inside.

>
> From the text you cited regarding MQTT v5 it is not backwards compatible
> to version 3.1.1. The exact impact of working between two devices of
> different versions has not been described in the spec either. The follow
> sentence in your introduction can easily give readers the impression that
> the two versions are backwards compatible. Here is the sentence:
>
> " It is expected that MQTT
>    deployments will retain backward compatibility for MQTT v3.1.1
>    clients, and therefore, this document also describes a reduced set of
>    protocol interactions for MQTT v3.1.1 - the OASIS Standard
>    [MQTT-OASIS-Standard].
> "

> Maybe you want to change the wording a little bit.  I think the reason why
> you want to describe a solution for v3.1.1 is that this is the widely
> deployed version.
>
>

I see where I am creating confusion. I should distinguish better that I
expect solution providers to still support MQTT v3.1 clients by
implementing both MQTT v5 and MQTT v3.1.1 servers, as you said because
3.1.1 is widely deployed. I was not meaning spec backward compatibility.

> Regarding the broker term: It is probably a matter of taste but I would
> refer to the terms used in the spec and would not replicate the terminology
> from the OASIS MQTT specs in the draft.

Someone who implements the draft will have to become familiar with MQTT
> anyway. But that’s just me. For example, I often see people using the term
> “certificate authorities (CA)” in their write-ups. RFC 5280 defines and
> uses the term “certification authority (CA)". While the two sound and look
> similar only one is actually correct.
>

OK, you suggest we use MQTT server. I expect broker is more widely-used in
practice, and it is not a misspelling of another term either. I would want
to keep it, but I would like to see if others prefer MQTT server rather.

>
> I noticed you have put a normative dependency on
> [I-D.palombini-ace-coap-pubsub-profile]. I don't think it is necessary
> because it is not a requirement to implement the spec.

You could use it on top of it -- or you could use something else as well. I
> would move it to the informative part.  The added benefit of doing that is
> that you do not block your spec till that draft becomes RFC.

  True. Will fix.

> On the other hand, RFC 6749, RFC 7800, and
> I-D.ietf-ace-cwt-proof-of-possession cannot be informative references when
> you use PoP tokens in your solution.
>
> Yes, indeed. Will fix.

> You might be interesting to hear that there is currently no way to obtain
> the keys for a PoP token over HTTP, which your solution requires. The
> virtual interim meeting in the OAuth group should probably be of interest
> to you.
>

I plan to join. I  have been aware of the issue, but could not follow how
it was planned to be resolved.
I was looking at this: draft-ietf-oauth-pop-key-distribution

Thanks again,
--Cigdem

>
> From: Cigdem Sengul <cigdem.sengul@gmail.com>
> Sent: Tuesday, February 25, 2020 3:10 PM
> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> Cc: ace@ietf.org
> Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03
>
> Hello Hannes,
>
> We used  broker as it is a widely accepted term in the MQTT Community for
> "server" e.g.,
> majority of the provider would list also a broker implementation to refer
> to their server implementation.
>
> With respect to whether 3.1,1 clients talking to v5, there may be some
> issues. This is what the spec says:
>
> Non-normative Comment
> If the Server distributes Application Messages to Clients at different
> protocol levels (such as MQTT V3.1.1) which do not support properties or
> other features provided by this specification, some information in the
> Application Message can be lost, and applications which depend on this
> information might not work correctly.
>
> The spec also defines a protocol version error message:
> If the [Client's] Protocol Version [in the CONNECT packet] is not 5 and
> the Server does not want to accept the CONNECT packet, the Server MAY send
> a CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version) and
> then MUST close the Network Connection
>
> So, whether a broker provides dual support would depend on the provider.
> E.g., the Mosquitto broker supports the different protocol versions.
>
> Thanks,
> --Cigdem
>
> On Tue, Feb 25, 2020 at 10:01 AM Hannes Tschofenig <mailto:
> Hannes.Tschofenig@arm.com> wrote:
> Hi Cigdem, Hi Anthony, Hi Paul,
>
> Why are you using the term MQTT broker? My understanding of the MQTT spec
> is that there are only clients and servers - nothing more.
>
> Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT
> v3.1.1 client talk to a MQTT v5 client via a server that supports both
> v3.1.1 and v5?
>
> Ciao
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> Ace mailing list
> mailto:Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>