[Ace] AD review of draft-ietf-ace-extend-dtls-authorize-04

[Roman Danyliw <[e-mail]>]

Hi!

Paul and I are load balancing, so I'll be the responsible AD for draft-ietf-ace-extend-dtls-authorize-04 moving forward.  I performed an AD review on the document and my feedback is as follows:

** Document Meta-data. s/Updates: draft-ietf-ace-dtls-authorize  /Updates: RFC9202/

** Abstract.  The abstract text needs to name the RFC that it is updating per the metadata.

OLD
This document updates the CoAP-DTLS profile for ACE by specifying
   that the profile applies to TLS as well as DTLS.

NEW
This document updates the CoAP-DTLS profile for ACE described in RFC9202 by specifying that the profile applies to TLS as well as DTLS.

** Section 1.  Editorial clarity

OLD
This feature is supported
   by the OSCORE profile [RFC9203] but is lacking in the DTLS profile.

NEW
This dual support for TLS and DTLS is already supported by the OSCORE profile [RFC9203].

** Section 1
The same access rights are valid in
   case transport layer security is provided by either DTLS or TLS, and
   the same access token can be used.  

Could this language please be refined so it is clearer on who the target is?  Is guidance to the RS (that given a token, it should read anything into whether it was presented over DTLS or TLS)?

** Section 3.
   the Client MAY try to
   connect to the Resource Server via TLS, or try TLS and DTLS in
   parallel to accelerate the session setup.

What happens if the RS responds to a connection on both protocols?

** Section 3.
This
   error SHOULD be handled by the Client in the same way as unsupported
   ACE profiles.   

Can this be explained a bit more.  The client has a token with "coap_dtls" but the connection failed.  How would it distinguish between the peer being misconfigured (and not responding) vs. not supporting this protocol?  What is the alternative way to handle it (given that this is SHOULD as opposed to a MUST)?

** Section 3.

If the Client is modified accordingly or it learns
   that the Resource Server has been, the Client may try to connect to
   the Resource Server using the transport layer security mechanism that
   was previously not mutually supported. 

Does this imply some kind of state is kept?  If so, how is that managed?

** Section 3.
If this message exchange
   succeeds, the Client SHOULD first use the same underlying transport
   protocol for the establishment of the security association as well

Is this the same things as roughly saying that the Client SHOULD connect to the AS for the token request over the same protocol it successfully contacted the RS?  Recommend explicitly mentioning the AS here.

** Section 3.

Clients
   that support either DTLS or TLS but not both SHOULD use the transport
   protocol underlying the supported transport layer security mechanism
   also for an initial unauthorized resource request.

I'm not following something here.  If the Client only supports one of the protocols, what's the optionality suggested by the SHOULD in using it.  Either it tries to uses the single protocol it supports, or no connection can be made.

** Section 4.  Please Use the exact registry field names:

OLD
   The following updates have been done for the "ACE Profiles" registry
   for the profile with Profile ID 1 and Profile name coap_dtls:

NEW
The following updates have been done to the "ACE Profiles" registry for the profile with a "CBOR Value" field value of 1 and "Name" of "coap_dtls":

** Section 4. Is the WG sure it doesn't want two references, [RFC9202] and this [RFC-XXXX]

** Section 5.  Should draft-ietf-uta-rfc7525bis apply here instead of RFC7525?

** Section 5.  Don't the security considerations of RFC9202 also still apply here?

Regards,
Roman