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

[Cigdem Sengul <[e-mail]>]

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
>