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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux