Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

From: Daniel Migault <[email-masked]>
Date: Tue, 2 Mar 2021 09:27:02 -0500

Hi everyone,

This is just a follow-up. I would like to be able to close this issue by
the end of the week, and so far I have not heard any issues for profile
mandating a protocol. On the other hand, not mandating a specific protocol
comes with interoperability issues. So unless more feed back is provided, I
am currently leaning toward ensuring interoperability.

It  would be good for me to hear from the WG and understand what concrete
deployment issues the two statements below would raise:
    * OSCORE profile mandating the AS to support OSCORE and have the C <->
AS using OSCORE.
    * DTLS profile mandating the AS to support DTLS and have the C <-> AS
using DTLS.

Yours,
Daniel

On Mon, Feb 22, 2021 at 10:00 AM Daniel Migault <[email-masked]> wrote:

> Thanks Gorand,
>
> I think the text goes in the right direction. I am reading this as
> the framework defines the protocol should be used between the client and AS
> or client and RS. It is not mandatory, sure, but at that point, my
> understanding is that it makes it clear that if you do not follow the
> recommendations you are at your own risks and so that interoperability is
> provided by this recommendation.
> I am wondering if the framework prevents a profile to mandate a protocol
> ?. I assume not
>
> The one point I need to document in my shepherd is why recommendation is
> sufficient to provide interoperability. I am happy to hear why the WG
> thinks it is sufficient other than we want to leave that open.
>
> It  would be good for me to hear from the WG and understand what concrete
> deployment issues the two statements below would raise:
>     * OSCORE profile mandating the AS to support OSCORE and have the C <->
> AS using OSCORE.
>     * DTLS profile mandating the AS to support DTLS and have the C <-> AS
> using DTLS.
>
> Yours,
> Daniel
>
> On Mon, Feb 22, 2021 at 4:53 AM Göran Selander <
> [email-masked]> wrote:
>
>> Hi Daniel and all,
>>
>> It seems to me that there is no full consensus, so we probably have to
>> inform the AD about the disagreement. However, we do seem to agree that we
>> want to clarify some parts of the framework. Here is yet another proposal:
>>
>> Section 5:
>> OLD
>> "Profiles MUST specify a communication security protocol that provides
>> the features required above."
>>
>> NEW
>> "Profiles MUST specify a communication security protocol between client
>> and RS that provides the features required above. Profiles MUST  specify a
>> communication security protocol RECOMMENDED to be used between client and
>> AS that provides the features required above. Profiles MUST  specify a
>> communication security protocol RECOMMENDED to be used between RS and AS
>> that provides the features required above."
>>
>>
>> Section 6.2:
>> OLD
>>   "Profiles MUST specify how communication security according
>>    to the requirements in Section 5 is provided."
>> NEW
>> "The requirements for communication security of profiles are specified
>> in Section 5."
>>
>>
>> If there is an unequivocal positive response from the WG then I may be
>> able to publish a new version today.
>>
>> Göran
>>
>>
>>
>> On 2021-02-18, 23:03, "Daniel Migault" <daniel.migault=
>> [email-masked]> wrote:
>>
>>     Hi Russ,
>>
>>     Thanks for the follow-up. I was waiting clearer agreement from eth WG
>> before pinging you back. I think I agree with your understanding. My
>> understanding is that the WG is willing to specify one way (RECOMMMEND) and
>> not leave that unspecified while not preventing other configurations (MAY).
>> This obviously results in implementation not following the RECOMMENDED way
>> do not interoperate with those following these recommendations.
>>
>>     The question remains open on whether we should favor openness or
>> inter-operability. I suppose that this will be raised at the IESG so we
>> need to address this issue clearly.
>>
>>     Going back to the profiles, it would be good to understand what
>> concrete deployment issues the two statements below would raise:
>>
>>     * OSCORE profile mandating the AS to support OSCORE and have the C
>> <-> AS using OSCORE.
>>     * DTLS profile mandating the AS to support DTLS and have the C <-> AS
>> using DTLS.
>>
>>
>>
>>     Yours,
>>     Daniel
>>
>>     ________________________________________
>>     From: Russ Mundy <[email-masked]>
>>     Sent: Thursday, February 18, 2021 3:38 PM
>>     To: Daniel Migault <[email-masked]>
>>     Cc: Russ Mundy <[email-masked]>; Stefanie Gerdes <[email-masked]>;
>> Daniel Migault <[email-masked]>; Francesca Palombini <
>> [email-masked]>; Göran Selander <goran.selander=
>> [email-masked]>; Olaf Bergmann <[email-masked]>;
>> [email-masked] <[email-masked]>
>>     Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
>>
>>     Hi Daniel & others,
>>     Thanks for the continuing effort to make the documents more clear and
>> understandable.
>>
>>     I think that there may be a fairly fundamental difficulty
>> understanding (possibly on my part) about the intended relationship between
>> the ACE framework and profile documents.  It seems appropriate to me that
>> the framework would define the overall requirements (especially security
>> requirements) that implementers need to meet and profiles provide the ‘how’
>> for implementers so the result is secure, interoperable implementations
>> potentially from multiple different implementers of the framework using a
>> particular profile for that framework.
>>
>>     If I’m following the discussion correctly, the changes being proposed
>> to the framework would only require a profile to define one ‘example (or
>> description)’ definition that met the security requirements of the
>> framework (even if it was the RECOMMENDED protocol set) but other protocol
>> set(s) could be used (MAY) within the definition of a profile.  Including
>> what amounts to unspecified protocol set(s) that do not define how they
>> will meet security requirements of the framework will likely result in
>> different implementations that comply with the profile but do not
>> interoperate from either a protocol or a security basis (or both).
>>
>>     Regards,
>>     Russ
>>
>>
>>     On Feb 17, 2021, at 11:16 AM, Daniel Migault <
>> [email-masked]> wrote:
>>
>>     Hi,
>>
>>     I think that could work for me. If the changes address the initial
>> concerns, we may publish these changes in the coming days.
>>
>>     Yours,.
>>     Daniel
>>     ________________________________________
>>     From: Stefanie Gerdes <[email-masked]>
>>     Sent: Wednesday, February 17, 2021 8:51 AM
>>     To: Daniel Migault <[email-masked]>; Daniel Migault <
>> [email-masked]>; Francesca Palombini <
>> [email-masked]>
>>     Cc: Göran Selander <goran.selander=[email-masked]>;
>> Russ Mundy <[email-masked]>; Olaf Bergmann <[email-masked]>;
>> [email-masked] <[email-masked]>
>>     Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
>>
>>     Hi Daniel,
>>
>>     On 02/16/2021 04:53 PM, Daniel Migault wrote:
>>
>>     > Section 5:
>>     > OLD
>>     > "Profiles MUST specify a communication security protocol that
>> provides
>>     >    the features required above."
>>     > NEW
>>     > "Profiles MUST specify at least one communication security protocol
>> that provides the features required above."
>>     >
>>     > <mglt>
>>     > I have the impression that with MUST specify one expects a
>> mandatory protocol to be provided. Would the following text be acceptable ?
>>     >
>>     > NEW2:
>>     > "Profiles RECOMMENDs at least one communication security protocol
>> that provides the features required above."
>>     > </mglt>
>>
>>     I don't understand it like that but I see your point. But I think
>>     "RECOMMENDS" leaves too much wiggle room :). The profiles could then
>>     omit the protocols completely, which I think is a bad idea.
>> Implementers
>>     should have at least one example how the communication between C and
>> AS
>>     is protected. Since we don't provide it in the framework we must have
>> it
>>     in the profiles. How about:
>>
>>     NEW3:
>>     "Profiles MUST specify at least one communication security protocol
>> that
>>     provides the features required above as an example how the respective
>>     communication can be secured."
>>
>>     Viele Grüße
>>     Steffi
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Daniel Migault
> Ericsson
>

-- 
Daniel Migault
Ericsson

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 02 Mar 2021 16:20:39 +0100

Hi Daniel,

On 2021-03-02, Daniel Migault <[email-masked]> wrote:

> This is just a follow-up. I would like to be able to close this issue
> by the end of the week, and so far I have not heard any issues for
> profile mandating a protocol. On the other hand, not mandating a
> specific protocol comes with interoperability issues. So unless more
> feed back is provided, I am currently leaning toward ensuring
> interoperability.
>
> It  would be good for me to hear from the WG and understand what concrete deployment
> issues the two statements below would raise:
>     * OSCORE profile mandating the AS to support OSCORE and have the C <-> AS using
> OSCORE. 
>     * DTLS profile mandating the AS to support DTLS and have the C <-> AS using DTLS. 

I think the major issue is that a client that implements both OSCORE and
DTLS cannot just switch from one mechanism to the other because it must
stick to either one or the other. This also raises the question what
happens if an AS is contacted by the client via OSCORE but the RS only
supports DTLS: Is the client allowed to switch from OSCORE to DTLS if
the AS says so?

Another aspect is that we would need to add another specification if a
client implementing the DTLS profile wants to contact the AS via TLS. As
CoAP over TLS is well-defined, this would not make any difference
regarding the security or the handling in the application, but mandating
DTLS in the profile would currently preclude the use of TLS.

Grüße
Olaf

---

From: Daniel Migault <[email-masked]>
Date: Tue, 2 Mar 2021 23:09:10 -0500

Thanks for the feedbacks Olaf. So I understand why we need such flexibility
on the client side. The main reason seems that the communication with the
AS is seen as bootstrapping the communication between the client and the RS
and as such we would like to keep them as independent as possible.

I see interoperability being achieved when a) client, RS, and AS
implemented by independent vendors and b) all three follow the framework
and the given profile is sufficient to make them work together. Currently
the client - RS communication is well defined, but the client AS
communication is left to a RECOMMENDATION.

RFC2119 defines RECOMMEND as follows:

SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

The question becomes how RECOMMENDED is sufficient or not.

It seems to me the definition above makes it clear that
the recommended protocol is expected to be supported, and AS or clients
that are independently developed are expected to support the recommended
protocol. To ensure the implementers are well aware of the consequences of
the implication we could clarify this explicitly. Of course this does not
provide a formal proof for interoperability, but this seems acceptable in
the scope of a framework.

>From the latest suggestion, I would propose the following changes, - that I
expect will reach consensus. Please let us know by Friday  March 5 if you
agree or disagree with the proposed changes.

 Section 5:
OLD
"Profiles MUST specify a communication security protocol that provides the
features required above."

NEW
"Profiles MUST specify a communication security protocol between client and
RS that provides the features required above. Profiles MUST  specify a
communication security protocol RECOMMENDED to be used between client and
AS that provides the features required above. Profiles MUST  specify for
introspection a communication security protocol RECOMMENDED to be used
between RS and AS that provides the features required above. Such
recommendations are expected, among others, to guarantee independent
implementations interoperate."

Section 6.2:
OLD

Yours,
Daniel

On Tue, Mar 2, 2021 at 10:20 AM Olaf Bergmann <[email-masked]> wrote:

> <-> AS using

-- 
Daniel Migault
Ericsson

---

From: Francesca Palombini <[email-masked]>
Date: Fri, 5 Mar 2021 16:03:26 +0000

Hi,

(Adding back the ace ml that was dropped at some point)

Here is a proposal for the paragraph in Section 5 with a different last sentence to hopefully clarify the need for recommendations but not mandate only one sec protocol per profile:

Section 5:
OLD
    "Profiles MUST specify a communication security protocol that provides the features required above."

  NEW
    "Profiles MUST specify a communication security protocol between client and RS that provides the features required above. Profiles MUST  specify a communication security protocol RECOMMENDED to be used between client and AS that provides the features required above. Profiles MUST  specify for introspection a communication security protocol RECOMMENDED to be used between RS and AS that provides the features required above. These recommendations enable interoperability between different implementations, without the need to define a new profile if the communication between C/RS and AS is protected with a different security protocol complying with the security requirements above."

The proposal for the other section looks good to me.
Francesca

From: Daniel Migault <[email-masked]>
Date: Thursday, 4 March 2021 at 17:49
To: Göran Selander <[email-masked]>
Cc: Stefanie Gerdes <[email-masked]>, Olaf Bergmann <[email-masked]>, Francesca Palombini <[email-masked]>, Russ Mundy <[email-masked]>, "[email-masked]" <[email-masked]>, Loganaden Velvindron <[email-masked]>
Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

HI Goran,

sure any wordsmithing / alternative are fine to me. For the second alternative the repetition of "with" may sound to me a bit strange.

Unless anyone objects that would be greatly appreciate to have a new version submitted. Thanks!

Yours,
Daniel

On Thu, Mar 4, 2021 at 11:12 AM Göran Selander <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

The proposal coincides with the text I proposed Feb 22 except for one sentence:

"Such recommendations are expected, among others, to guarantee independent implementations interoperate."

This sentence does not read well to me, perhaps we can change it? For example:

"These recommendations are expected to enable interoperability between independent implementations."

 . . . or even add the reason why it is only a recommendation:

"These recommendations are expected to enable interoperability between independent implementations, without preventing this profile to be used with other security protocols with the AS complying with the security requirements."

I can make the changes and submit a new version of draft-ietf-ace-oauth-authz in the beginning of next week when ID submission has reopened.

Regards
Göran

On 2021-03-04, 15:54, "Daniel Migault" <[email-masked]<mailto:[email-masked]>> wrote:

    Hi all,
    I know everyone is very busy by now, but I am wondering if you could provide your input so that we can think of closing this issue before the IETF 110 - or at least as soon as possible. Our initial milestones were to send these doc in February ;-)

    Yours,
    Logan and Daniel
    ---------- Forwarded message ---------
    From: Daniel Migault <[email-masked]<mailto:[email-masked]>>
    Date: Tue, Mar 2, 2021 at 11:09 PM
    Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
    To: Olaf Bergmann <[email-masked]<mailto:[email-masked]>>
    Cc: Göran Selander <[email-masked]<mailto:[email-masked]>>, Olaf Bergmann <[email-masked]<mailto:[email-masked]>>, Russ Mundy <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Stefanie Gerdes <[email-masked]<mailto:[email-masked]>>, Francesca Palombini <[email-masked]<mailto:[email-masked]>>, Daniel Migault <daniel.migault=[email-masked]<mailto:[email-masked]>>

    Thanks for the feedbacks Olaf. So I understand why we need such flexibility on the client side. The main reason seems that the communication with the AS is seen as bootstrapping the communication between the client and the RS and as such we would like to keep them as independent as possible.
    I see interoperability being achieved when a) client, RS, and AS implemented by independent vendors and b) all three follow the framework and the given profile is sufficient to make them work together. Currently the client - RS communication is well defined, but the client AS communication is left to a RECOMMENDATION.

    It seems to me the definition above makes it clear that the recommended protocol is expected to be supported, and AS or clients that are independently developed are expected to support the recommended protocol. To ensure the implementers are well aware of the consequences of the implication we could clarify this explicitly. Of course this does not provide a formal proof for interoperability, but this seems acceptable in the scope of a framework.

    From the latest suggestion, I would propose the following changes, - that I expect will reach consensus. Please let us know by Friday  March 5 if you agree or disagree with the proposed changes.

     Section 5:
    OLD
    "Profiles MUST specify a communication security protocol that provides the features required above."

    NEW
    "Profiles MUST specify a communication security protocol between client and RS that provides the features required above. Profiles MUST  specify a communication security protocol RECOMMENDED to be used between client and AS that provides the features required above. Profiles MUST  specify for introspection a communication security protocol RECOMMENDED to be used between RS and AS that provides the features required above. Such recommendations are expected, among others, to guarantee independent implementations interoperate."

    Section 6.2:
    OLD

    Yours,
    Daniel

    On Tue, Mar 2, 2021 at 10:20 AM Olaf Bergmann <[email-masked]<mailto:[email-masked]>> wrote:

    Hi Daniel,

    Grüße
    Olaf

    --
    Daniel Migault

    Ericsson

    --
    Daniel Migault

    Ericsson

--
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Fri, 5 Mar 2021 16:22:53 -0500

Thanks. "C/RS and AS" may not be very clear as it seems - at least to me -
to include the communication between the client and the RS. It seems to me
that  only communications between Client and AS as well as between AS and
RS are in scope. If that is correct, I would suggest expanding "C/RS and
AS" accordingly.

Yours,
Daniel

On Fri, Mar 5, 2021 at 11:03 AM Francesca Palombini <
[email-masked]> wrote:

> Here is a proposal for the paragraph in Section 5 with a different last
> sentence to hopefully clarify the need for recommendations but not mandate
> only one sec protocol per profile:
>
> Section 5:
> OLD
>     "Profiles MUST specify a communication security protocol between
> client and RS that provides the features required above. Profiles MUST
> specify a communication security protocol RECOMMENDED to be used between
> client and AS that provides the features required above. Profiles MUST
> specify for introspection a communication security protocol RECOMMENDED to
> be used between RS and AS that provides the features required above. These
> recommendations enable interoperability between different implementations,
> without the need to define a new profile if the communication between C/RS
> and AS is protected with a different security protocol complying with the
> security requirements above."
>
>
>
>
>
> *From: *Daniel Migault <[email-masked]>
> *Date: *Thursday, 4 March 2021 at 17:49
> *To: *Göran Selander <[email-masked]>
> *Cc: *Stefanie Gerdes <[email-masked]>, Olaf Bergmann <[email-masked]>,
> Francesca Palombini <[email-masked]>, Russ Mundy <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, Loganaden Velvindron <
> [email-masked]>
> *Subject: *Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
>
>
>
> HI Goran,
>
>
>
> sure any wordsmithing / alternative are fine to me. For the second
> alternative the repetition of "with" may sound to me a bit strange.
>
>
>
> On Thu, Mar 4, 2021 at 11:12 AM Göran Selander <
> "These recommendations are expected to enable interoperability between
> independent implementations, without preventing this profile to be used
> with other security protocols with the AS complying with the security
> requirements."
>
> I can make the changes and submit a new version of
> draft-ietf-ace-oauth-authz in the beginning of next week when ID submission
> has reopened.
>
> Regards
> Göran
>
>
>
> On 2021-03-04, 15:54, "Daniel Migault" <[email-masked]> wrote:
>
>
>     Hi all,
>     I know everyone is very busy by now, but I am wondering if you could
> provide your input so that we can think of closing this issue before the
> IETF 110 - or at least as soon as possible. Our initial milestones were to
> send these doc in February ;-)
>
>     Yours,
>     Logan and Daniel
>     To: Olaf Bergmann <[email-masked]>
>     Cc: Göran Selander <[email-masked]>, Olaf Bergmann <
> [email-masked]>, Russ Mundy <[email-masked]>, [email-masked] <
> [email-masked]>, Stefanie Gerdes <[email-masked]>, Francesca Palombini <
> [email-masked]>, Daniel Migault <daniel.migault=
> [email-masked]>
>
>
>
>     Thanks for the feedbacks Olaf. So I understand why we need such
> flexibility on the client side. The main reason seems that the
> communication with the AS is seen as bootstrapping the communication
> between the client and the RS and as such we would like to keep them as
> independent as possible.
>     It seems to me the definition above makes it clear that the
> recommended protocol is expected to be supported, and AS or clients that
> are independently developed are expected to support the recommended
>     From the latest suggestion, I would propose the following changes, -
> that I expect will reach consensus. Please let us know by Friday  March 5
> if you agree or disagree with the proposed changes.
>
>
>      Section 5:
>     OLD
>     "Profiles MUST specify a communication security protocol between
> client and RS that provides the features required above. Profiles MUST
> specify a communication security protocol RECOMMENDED to be used between
> client and AS that provides the features required above. Profiles MUST
> specify for introspection a communication security protocol RECOMMENDED to
> be used between RS and AS that provides the features required above. Such

-- 
Daniel Migault
Ericsson

---

From: Göran Selander <[email-masked]>
Date: Mon, 8 Mar 2021 07:35:04 +0000

Hi Daniel,

Here is a proposed changed to the last sentence:

    Section 5:
    OLD

      NEW
        "Profiles MUST specify a communication security protocol between client and RS that provides the features required above. Profiles MUST  specify a communication security protocol RECOMMENDED to be used between client and AS that provides the features required above. Profiles MUST  specify for introspection a communication security protocol RECOMMENDED to be used between RS and AS that provides the features required above. These recommendations enable interoperability between different implementations without the need to define a new profile if the communication between C and AS, or between RS and AS, is protected with a different security protocol complying with the security requirements above."

Göran

On 2021-03-05, 22:23, "Daniel Migault" <[email-masked]> wrote:

    Thanks. "C/RS and AS" may not be very clear as it seems - at least to me -  to include the communication between the client and the RS. It seems to me that  only communications between Client and AS as well as between AS and RS are in scope. If that is correct, I would suggest expanding "C/RS and AS" accordingly.
    Yours, 
    Daniel

    On Fri, Mar 5, 2021 at 11:03 AM Francesca Palombini <[email-masked]> wrote:

    Hi,

    Section 5:
    OLD

      NEW

    HI Goran, 

    Yours, 
    Daniel 

    On Thu, Mar 4, 2021 at 11:12 AM Göran Selander <[email-masked]> wrote:

    Hi Daniel,

    Regards
    Göran

        Hi all, 

        Yours, 
        Logan and Daniel
        ---------- Forwarded message ---------
        From: Daniel Migault <[email-masked]>
        Date: Tue, Mar 2, 2021 at 11:09 PM
        Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
        To: Olaf Bergmann <[email-masked]>
        Cc: Göran Selander <[email-masked]>, Olaf Bergmann <[email-masked]>, Russ Mundy <[email-masked]>, [email-masked] <[email-masked]>, Stefanie Gerdes <[email-masked]>, Francesca Palombini <[email-masked]>, Daniel Migault <daniel.migault=[email-masked]>

         Section 5:
        OLD

        NEW

        Section 6.2:
        OLD

        Yours, 
        Daniel  

        Hi Daniel,

        Grüße
        Olaf

        -- 
        Daniel Migault

        Ericsson

        -- 
        Daniel Migault

        Ericsson

    -- 
    Daniel Migault

    Ericsson

    -- 
    Daniel Migault

    Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Mon, 8 Mar 2021 07:13:58 -0500

Thanks Goran, It looks good to me. I believe that a new version can be
published to reflect the changes and close this issue.

Yours,
Daniel

On Mon, Mar 8, 2021 at 2:35 AM Göran Selander <[email-masked]>
wrote:

> provides the features required above."
>
>       NEW
> recommendations enable interoperability between different implementations
> without the need to define a new profile if the communication between C and
> AS, or between RS and AS, is protected with a different security protocol
> complying with the security requirements above."
>
>
> Göran
>
>
>     Thanks. "C/RS and AS" may not be very clear as it seems - at least to
> me -  to include the communication between the client and the RS. It seems
> to me that  only communications between Client and AS as well as between AS
> and RS are in scope. If that is correct, I would suggest expanding "C/RS
> and AS" accordingly.
>     Yours,
>     Daniel
>
>
>     Here is a proposal for the paragraph in Section 5 with a different
> last sentence to hopefully clarify the need for recommendations but not
> mandate only one sec protocol per profile:
>
>     Section 5:
>     OLD
> provides the features required above."
>
>       NEW
>     Cc: Stefanie Gerdes <[email-masked]>, Olaf Bergmann <[email-masked]>,
>     "Such recommendations are expected, among others, to guarantee
> independent implementations interoperate."
>
> independent implementations."
>
>         I know everyone is very busy by now, but I am wondering if you
> could provide your input so that we can think of closing this issue before
> the IETF 110 - or at least as soon as possible. Our initial milestones were
> to send these doc in February ;-)
>
>         Yours,
>         Logan and Daniel
>         From the latest suggestion, I would propose the following changes,
> - that I expect will reach consensus. Please let us know by Friday  March 5
> provides the features required above."
>
>         NEW

-- 
Daniel Migault
Ericsson

---

From: Göran Selander <[email-masked]>
Date: Mon, 8 Mar 2021 14:55:19 +0000

Hi Daniel,

I just submitted -38 which includes these changes and some nits.

Göran

On 2021-03-08, 13:14, "Daniel Migault" <[email-masked]> wrote:

    Thanks Goran, It looks good to me. I believe that a new version can be published to reflect the changes and close this issue. 
    Yours, 
    Daniel 

    On Mon, Mar 8, 2021 at 2:35 AM Göran Selander <[email-masked]> wrote:

    Hi Daniel,

        Section 5:
        OLD

          NEW

    Göran

        Hi,

        Section 5:
        OLD

          NEW

        HI Goran, 

        Yours, 
        Daniel 

        Hi Daniel,

        Regards
        Göran

            Hi all, 

            Yours, 
            Logan and Daniel
            ---------- Forwarded message ---------

             Section 5:
            OLD

            NEW

            Section 6.2:
            OLD

            Yours, 
            Daniel  

            Hi Daniel,

            Grüße
            Olaf

            -- 
            Daniel Migault

            Ericsson

            -- 
            Daniel Migault

            Ericsson

        -- 
        Daniel Migault

        Ericsson

        -- 
        Daniel Migault

        Ericsson

    -- 
    Daniel Migault

    Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Mon, 8 Mar 2021 16:50:01 +0000

Thanks! My understanding is that these documents are ready to be moved forward to the IESG.

Anyone thinking otherwise, please let us know as soon a spossible.

Yours,
Daniel
________________________________
From: Ace <[email-masked]> on behalf of Göran Selander <goran.selander=[email-masked]>
Sent: Monday, March 8, 2021 9:55 AM
To: Daniel Migault <[email-masked]>
Cc: Loganaden Velvindron <[email-masked]>; Olaf Bergmann <[email-masked]>; [email-masked] <[email-masked]>; Russ Mundy <[email-masked]>; Ace Wg <[email-masked]>; Stefanie Gerdes <[email-masked]>; Francesca Palombini <[email-masked]>
Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

Hi Daniel,

Göran

    Hi Daniel,

        Section 5:
        OLD

          NEW

    Göran

        Hi,

        Section 5:
        OLD

          NEW

        HI Goran,

        Yours,
        Daniel

        Hi Daniel,

        Regards
        Göran

            Hi all,

            Yours,
            Logan and Daniel
            ---------- Forwarded message ---------

             Section 5:
            OLD

            NEW

            Section 6.2:
            OLD

            Yours,
            Daniel

            Hi Daniel,

            Grüße
            Olaf

            --
            Daniel Migault

            Ericsson

            --
            Daniel Migault

            Ericsson

        --
        Daniel Migault

        Ericsson

        --
        Daniel Migault

        Ericsson

    --
    Daniel Migault

    Ericsson

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 9 Mar 2021 07:51:46 -0800

On Tue, Mar 09, 2021 at 10:36:01AM -0500, Russ Mundy wrote:
> All, thanks very much to everyone that contributed to resolving this issue.  I agree with Daniel that the issue can be closed, i.e., the issue I raised in my secdir review has been satisfactorily addressed and resolved.

Hi Russ,

A big thank-you to you as well for doing the review and following-up about
it!  I think the document suite ended up in a better place as a result, and
I'm glad to hear that you agree that the issue is resolved.

Thanks again,

Ben

---

From: Daniel Migault <[email-masked]>
Date: Tue, 9 Mar 2021 13:36:13 -0500

Hi Russ,

Thanks Russ for raising this issue and doing the followup. I am glad we
clarified it.

Yours,
Daniel

On Tue, Mar 9, 2021 at 10:51 AM Benjamin Kaduk <[email-masked]> wrote:

> > All, thanks very much to everyone that contributed to resolving this
> issue.  I agree with Daniel that the issue can be closed, i.e., the issue I
> raised in my secdir review has been satisfactorily addressed and resolved.
>
> Hi Russ,
>

-- 
Daniel Migault
Ericsson