Subject: Re: [Ace] Roman Danyliw's Discuss on draft-ietf-ace-oscore-profile-17: (with DISCUSS and COMMENT)

From: Francesca Palombini <[email-masked]>
Date: Wed, 14 Apr 2021 16:39:51 +0000

Hi Roman! 

Thank you very much for the review! We have incorporated your changes in the newly submitted v-18 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-18 , but you can also see the specific changes in the github commits:
https://github.com/ace-wg/ace-oscore-profile/commit/d64f5563d5be185cd7dcb6b8972dce33ae31c9c2 
https://github.com/ace-wg/ace-oscore-profile/commit/8ad0db81cb391742887d5e1cae2cf33b0702836f
https://github.com/ace-wg/ace-oscore-profile/commit/a8caabb2ae5588a5923ac569a2fe85262031ed0c 

Answers inline.

Thanks again,
Francesca

On 23/03/2021, 04:28, "Roman Danyliw via Datatracker" <[email-masked]> wrote:

    Roman Danyliw has entered the following ballot position for
    draft-ietf-ace-oscore-profile-17: Discuss

    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)

    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.

    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/

    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------

    (A simple editorial fix) Per Section 5.8.2 of [I-D.ietf-ace-oauth-authz], the
    name of the parameter in the C-to-AS communication is “ace_profile” (not
    “profile”).  The “ace_profile” parameter is mistakenly referenced as “profile”
    in the following place:

    (a) Section 3.2.
       The AS can signal that the use of OSCORE is REQUIRED for a specific
       access token by including the "profile" parameter with the value
       "coap_oscore" in the access token response

FP: Good catch! Fixed 

    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Thank you to Kathleen Moriarty for the SECDIR review.

    ** In addition to the normative text noted in the DISCUSS, the examples in
    Figure 4 and Figure 7 also have the same typo (but that doesn’t rise to a
    DISCUSS)

FP: Indeed, fixed.

    ** Section 7.  Per “Developers should avoid using multiple access tokens for a
    same client”, is there a reason not to use a normative SHOULD here?  The DTLS
    profile has nearly the identical words and uses a normative SHOULD?

    Likewise should “This profile recommends that the that RS maintains a single
    access token for each client” be “This profile RECOMMENDS”?

FP: Right, now using BCP14 SHOULD and RECOMMENDS as you suggest.

    ** Editorial nits
    Section 3.2.  Typo. s/The applications needs/The application needs/

FP: Fixed.

    Section 3.2.  Typo. s/parameeter/parameter/

FP: Fixed.

    Section 4.  Typo. s/Note that the RS and client authenticates/Note that the RS
    and client authenticate/

FP: Fixed.

    Section 4.1.  Typo. s/The client may also chose/The client may also choose/

FP: Fixed.