Re: [Ace] Artart last call review of draft-ietf-ace-mqtt-tls-profile-14

[Cigdem Sengul <[e-mail]>]

Hello Jean,

Thank you for your feedback on the changes.
I have updated the pull request with a new commit:
https://github.com/ace-wg/mqtt-tls-profile/pull/102/commits/75ac0c0a86812f359471a63f6b481b0b80482b97

Responses to questions/comments are inline below.

On Wed, 9 Mar 2022 at 23:18, A. Jean Mahoney <[e-mail]> wrote:

> Cigdem,
>
> Thank you for reply and for incorporating the feedback into a PR. I have
> few comments and questions below.
>
>
> > references due to changes of text etc.) I have still kept MQTT as
> > normative, as the document is about MQTT, but is it expected to be
> > informative when the reference is a non-RFC?
>
> [JM] I think that is okay. The document shepherd indicated in his
> writeup that he thinks the MQTT reference should be normative
> (
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/shepherdwriteup/).
>
>
> [CS: OK, will leave as is.]


>
> >
> >     Section 2.2.4.2.2: I'm having difficulty parsing the following
> normative
> >     statements. Does "MUST" also cover the Authentication Data (i.e.,
> >     MUST be set
> >     to "ace" and MUST contain Authentication Data)? If the
> >     Authentication Data MUST
> >     NOT be empty, MUST it contain the 8-byte RS nonce or could it
> >     contain something
> >     else?
> >
> >     Current:
> >         The AUTH packet to continue authentication includes the
> >         Authentication Method, which MUST be set to "ace" and
> Authentication
> >         Data.  The Authentication Data MUST NOT be empty and contains an
> >         8-byte RS nonce as a challenge for the Client (Figure 6).
> >
> >
> > [CS: Revised as:
> > The Broker continues authentication using an AUTH packet that contains
> > the Authentication Method
> > and the Authentication Data. The Authentication Method MUST be set to
> > "ace", and the Authentication Data MUST NOT be empty and contain
> > an 8-byte RS nonce as a challenge for the Client.
> > ]
>
> [JM] This is better, but the last half of the last sentence could be
> interpreted as saying "MUST NOT be empty and MUST NOT contain...".
> Perhaps it could just say "the Authentication Data MUST contain an
> 8-byte RS nonce..."?
>

[CS: True, revised as your suggestion.]


>
> >
> >
> >     Section 6.1: Could more guidance or examples of necessary policies
> >     be provided
> >     here?
> >
> >     Current:
> >         However, stored Session state can be discarded as a
> >         result of administrator policies, and Brokers SHOULD implement
> the
> >         necessary policies to limit misuse.
> >
> >
> > [CS: Revised as:
> > "However, stored Session state can be discarded as a result
> > of administrator action or policies (e.g. defining an automated
> > response based on storage capabilities), and Brokers SHOULD implement
> > the necessary policies to limit
> > misuse."
> >
> > Would this work?
> > ]
>
> [JM] I like the added example. As someone unfamiliar with MQTT, I was
> wondering what "necessary policies" might look like. That is, if I were
> to build a Broker implementation, what sort of things SHOULD my
> implementation be doing here? An example or two might clarify.
>

[CS: The example regarding defining an automated response based on storage
capabilities come from the MQTT standard.
The standard itself does not define policies explicitly. I changed the
wording from "necessary policies" to "administrative policies" to avoid
misunderstanding. Such policies may include setting quotas on storage,
connection rates etc, but since they are not explained as such in the MQTT
standard, I would like to avoid specifying them here as well]

>
>
> >
> >        -- Possible downref: Non-RFC (?) normative reference: ref.
> >           'MQTT-OASIS-Standard'
> >
> >        -- Possible downref: Non-RFC (?) normative reference: ref.
> >           'MQTT-OASIS-Standard-v5'
> >
> >
> > [CS: OK for these two, I feel on the fence as the document is about MQTT.
> > Is the downref suggested because this is a Non-RFC and a standard coming
> > from OASIS]
>
> [JM] The idnits script calls out any normative reference that is not a
> Standards Track RFC. Documents from other standards bodies can be
> approved by the IESG to be listed in the Normative References section.
> The MQTT refs shouldn't be an issue. More info about downrefs can be
> found in RFC 8067.
>

[CS: Thanks, then I will keep things as they are.]

>
> >
> >
> >        ** Downref: Normative reference to an Informational RFC: RFC 6234
> >
> >
> > [CS: Moved to Informative references]
>
> [JM] RFC 6234 should be okay as a normative reference because it has
> been normatively referenced in other RFCs
> (https://datatracker.ietf.org/doc/rfc6234/referencedby/) and the
> following sentence says "mandatory to implement":
>
>     HS256 (HMAC-SHA-256) [RFC6234] and Ed25519 [RFC8032] are mandatory
>     to implement for the Broker.
>
[CS: OK, moved back to normative]

>
> >
> >
> >        ** Downref: Normative reference to an Informational RFC: RFC 7251
> >
> >
> > [CS: Reference removed] >
> >
> >        ** Downref: Normative reference to an Informational RFC: RFC 8032
> >
> >
> >   [CS: Moved to informative]
>
> [JM] Same as RFC 6234, RFC 8032 can be normative.
>
> https://datatracker.ietf.org/doc/rfc8032/referencedby/


[CS: Moved back to normative]

>
> Thanks again.
Kind regards,
--Cigdem

>
> >
> > _______________________________________________
> > art mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/art
>