Hi Lars,

Thank you for your detailed comments, and sorry for the late reply. We
addressed the issues as suggested. Sorry for the late reply.

Thank you for your time,
Steffi


On 3/24/21 6:56 PM, Lars Eggert via Datatracker wrote:
> Lars Eggert has entered the following ballot position for
> draft-ietf-ace-dtls-authorize-16: No Objection
> 
> 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-dtls-authorize/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 3.4, paragraph 4, comment:
>>    The resource server MUST only accept an incoming CoAP request as
>>    authorized if the following holds:
> 
> "MUST only" is odd, suggest to rephrase. (See below.)
> 
> -------------------------------------------------------------------------------
> All comments below are very minor change suggestions that you may choose to
> incorporate in some way (or ignore), as you see fit. There is no need to let 
> me
> know what you did with these suggestions.
> 
> Section 11.1, paragraph 12, nit:
>>    [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
>>               RFC 8152, DOI 10.17487/RFC8152, July 2017,
>>               <https://www.rfc-editor.org/info/rfc8152>.
> 
> Unused Reference: 'RFC8152' is defined on line 1144, but no explicit reference
> was found in the text
> 
> Section 11.1, paragraph 16, nit:
>>    [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
>>               "Transport Layer Security (TLS) Session Resumption without
>>               Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
>>               January 2008, <https://www.rfc-editor.org/info/rfc5077>.
> 
> Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted 
> by
> RFC 8446)
> 
> Section 11.1, paragraph 22, nit:
>>    [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
>>               "Object Security for Constrained RESTful Environments
>>               (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
>>               <https://www.rfc-editor.org/info/rfc8613>.
> 
> Unused Reference: 'RFC8613' is defined on line 1208, but no explicit reference
> was found in the text
> 
> Section 3.2.2, paragraph 3, nit:
> -    To be consistent with [RFC7252] which allows for shortened MAC tags
> +    To be consistent with [RFC7252], which allows for shortened MAC tags
> +                                   +
> 
> Section 3.3.2, paragraph 3, nit:
> -    be consistent with the recommendations in [RFC7252] a client is
> +    be consistent with the recommendations in [RFC7252], a client is
> +                                                       +
> 
> Section 3.4, paragraph 4, nit:
> -    The resource server MUST only accept an incoming CoAP request as
> -                             ^^^^
> -    authorized if the following holds:
> -                                ^^ --
> +    The resource server MUST NOT accept an incoming CoAP request as
> +                             ^^^
> +    authorized if any of the following fail:
> +                  +++++++              ^^^
> 
> Section 7.1, paragraph 3, nit:
> -    [RFC7925] requires clients to decline any renogiation attempt.  A
> -                                                  ^
> +    [RFC7925] requires clients to decline any renegotiation attempt.  A
> +                                                 ++ ^
> 
> 
> 

_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace

Reply via email to