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

[Reese Enghardt <[e-mail]>]

Hi,

Thank you for the changes and additional context.

This looks good to me!

Best,
Reese (aka Theresa)


On 3/5/22 05:40, Cigdem Sengul wrote:
> Hello,
> I've created a new pull request for the changes: 
> https://github.com/ace-wg/mqtt-tls-profile/pull/101
> Explanations are below.
>
>
>
>     > > [CS: Introduced a formal definition of Network Connection to
>     > > MQTT-related terminology - as defined in MQTT standard.
>     > > To the Will definition, added the situations when the
>     connection is
>     > > considered not to have closed normally.
>     > > Question: Normal disconnection is DISCONNECT with reason code
>     is 0x00,
>     > > according to MQTT standard - is this definition also needed?"
>     >
>     > [TE] So "not closed normally" means any way to terminate the
>     Network
>     > Connection, other than DISCONNECT with reason code 0x00? If so,
>     I think
>     > this would be a good addition to the definition, either as its own
>     > definition or added to the "Will" definition.
>
>     I think that's right, but Cigdem knows MQTT better than me and she
>     should
>     confirm.
>
> [CS: Yes, added the DISCONNECT packet definition. I also took the MQTT 
> standard text to specify more formally
> situations for sending a Will, which included a definition for normal 
> disconnection. I reduced the Will-specific text in the
> main document, as this definition now is comprehensive.]
>
>
>     >
>     > >
>     > >     Section 2.1
>     > >
>     > > [CS: Added for cnf:
>
>     > >
>     > > rs_cnf:
>
>     >
>     > [TE] These explanations already help, thanks! However, and this
>     might
>     > just be me, but I keep wondering what 'cnf' stands for, i.e., if
>     it is
>     > an acronym for something, and if it is, if it makes sense to
>     expand the
>     > acronym. But it might just be a string that comes from "somewhere",
>     > which is fine with me, too. :)
>
>     I think the lineage of "cnf" can be traced back to at least RFC
>     7800, so at
>     this point it's probably a fairly well established part of the greater
>     OAuth ecosystem.
>
>     Which is not to say that we can't try to make the document more
>     accessible
>     to new readers, of course.  The ACE framework itself relies pretty
>     heavily
>     on proof of possession semantics for JWT/CWT tokens, so perhaps the
>     implicit reliance on draft-ietf-ace-oauth-authz and its
>     terminology would
>     suffice.  Happy to hear further thoughts.
>
>
> [CS: Added   --> 'cnf' (confirmation) claim in its first instance. We 
> are referencing the params document as well for both confirmation related
> claims (cnf, rs_cnf). Would this be enough?]
>
> Kind regards,
> --Cigdem
>
>
>     -Ben
>