Subject: Re: [Ace] Benoit Claise's Block on charter-ietf-ace-00-01: (with BLOCK)

From: Benoit Claise <[email-masked]>
Date: Tue, 03 Jun 2014 11:57:27 +0200

On 15/05/2014 23:13, Likepeng wrote:
>> What are "resources?  It seems they are applications, but the charter doesn't make that clear.
> I think I have explained in another thread. Resources are not applications, and the resource concept is taken from HTTP protocol.
>
> About the "resource", we can take the definition from RFC2616:
>
>    resource
>       A network data object or service that can be identified by a URI,
>       as defined in section 3.2. Resources may be available in multiple
>       representations (e.g. multiple languages, data formats, size, and
>       resolutions) or vary in other ways.
>
> For example, resources can be temperature sensors on a data collection node, or a list of alarms on a home security controller. [RFC6690]
>
> Maybe we can add two explanations: one is that resources can be identified by a URI, two is that resources are hosted on the resource server.
>
> "Access to a resource" means Get, Put, Post and Delete to a resource.
>
>> ...
>> This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access to resources in constrained environments.
>> ...
> This sentence has been revised to:
>
> NEW
> This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments.
> END
That solves the first part of my DISCUSS.

Thanks, Benoit
>
> Hope it clarifies.
>
> Thanks,
> Kind Regards
> Kepeng
>
> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Benoit Claise
> 发送时间: 2014年5月15日 6:12
> 收件人: The IESG
> 抄送: [email-masked]; [email-masked]
> 主题: [Ace] Benoit Claise's Block on charter-ietf-ace-00-01: (with BLOCK)
>
> Benoit Claise has entered the following ballot position for
> charter-ietf-ace-00-01: Block
>
> 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.)
>
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/charter-ietf-ace/
>
>
>
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
>
> Reaction from the AAA-doctors.
>
> 1.
>  I haven't been following it in detail, but it does seem rather vague.
>
> ...
> This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access to resources in constrained environments.
> ...
>
>   What are "resources?  It seems they are applications, but the charter doesn't make that clear.  Also, if the "constrained environments" are using DTLS, they don't seem that constrained to me.
>
>   It looks to be a slight variation on existing technologies.  e.g. we want X, Y and Z, but in situation B instead of A.  So... we're going to design something completely new.
>
>   On the other hand, I'm happy to see people paying attention to authentication and authorization.  Too many protocols are designed to solve a problem first, and second to add security.
>
> 2. 
> The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments. AAA protocols were deployed in the 1990s to support extremely limited NAS devices and Internet hosts with tiny fractions of the power of today's systems.  Any device that can run IP can authenticate against a AAA server.
>
> Let me include the AAA-doctors in the discussion
>
>
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Benoit Claise <[email-masked]>
Date: Tue, 03 Jun 2014 12:15:35 +0200

Hi,

> Hello all,
>
> Based on recent discussions, I made a revised charter proposal, as included in this email, not on the webpage yet.
>
> Please take a look and let us know if you have any further comments.
>
> @Adrian and @Benoit, please check if the proposed texts can resolve your comments.
>
> Thanks,
> Kind Regards
> Kepeng
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
> Compared with charter-ietf-ace-00-01 on the webpage, the changes are:
>
> (1)	Add one clarification sentence about REST architecture:
> OLD
> The IETF has recently developed protocols for use in constrained
> environments, where network nodes are limited in CPU, memory and power.
> REST architecture is widely used for such constrained environments.
>
> NEW
> The IETF has recently developed protocols for use in constrained
> environments, where network nodes are limited in CPU, memory and power.
> REST architecture is widely used for such constrained environments.
> END
Considering that OLD is

    OLD

    The IETF has recently developed protocols for use in constrained

    environments, where network nodes are limited in CPU, memory and power.

... fine with me
>
> (2)	Remove “AAA protocol” from the charter:
> OLD
> The IETF has a long history in developing three-party authentication and
> authorization protocols for distributed environments. Examples include
> Kerberos, the Public Key Infrastructure (PKI), the Authentication,
> Authorization and Accounting (AAA) infrastructure, and the Web
> Authorization Protocol (OAuth).
>
> NEW
> The IETF has a long history in developing three-party authentication and
> authorization protocols for distributed environments. Examples include
> Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization Protocol (OAuth).
> END
We have AAA-doctors telling: maybe RADIUS is applicable?
Personally, I don't know and it doesn't matter at this point.
We received feedback such as:

    Let's be clear here: It was never said (in the charter or anywhere
    else in the group to my knowledge) that RADIUS (or indeed any other
    AAA protocol) would not run on constrained devices (RFC 7228). The
    charter simply said the protocols were not optimised for constrained
    devices. That does not preclude considering any protocol for
    suitability for constrained devices either a) as is, b) in a
    restricted way or c) in an adapted way.

    So, at this stage, I don't think any protocols should be excluded
    from consideration and should certainly not be eliminated on a hunch
    that they might be "too big". Let's do the assessment properly at
    the appropriate time. As a reminder - the focus now is to complete
    the charter.

Or

    >>The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments.

    In fact, the charter does not say that. But to avoid confusion, let's remove AAA protocol from the charter.

    In the charter, we mentioned that we want to reuse existing authentication and authorization protocols where applicable to build the constrained-environment solution.

... which I read as: let's consider the AAA protocols, and evaluate if 
they would work in constrained devices.
I don't understand the logic: why do you want to remove AAA from the 
charter?
Not only would I keep "AAA", but I would propose

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated 
and re-used where
applicable to build the constrained-environment solution

Regards, Benoit
>
> (3) Clarify the scope:
> OLD:
> Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
> Other security protocols may be considered as long as the primary focus is maintained.
> Other application protocols and protocols at other layers in the stack are out of scope.
>
> NEW
> Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
> Other security protocols may be considered as long as the primary focus is maintained.
> The group is scoped to work only on the web protocols and data carried within them.
> END
>
> (4)	Update milestones for the use case & requirements document:
> OLD:
> Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC.
>
> NEW
> Dec 2014 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC.
> END
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Charter charter-ietf-ace-00-02
> Authentication and Authorization for Constrained
> Environment (ACE)
>
> The IETF has recently developed protocols for use in constrained
> environments, where network nodes are limited in CPU, memory and power.
> REST architecture is widely used for such constrained environments.
> It has been observed that Internet protocols can be applied to these
> constrained environments, often only requiring minor tweaking and
> profiling. In other cases, new protocols have been defined to address
> the specific requirements of constrained environments. An example of
> such a protocol is the Constrained Application Protocol (CoAP).
>
> As in other environments, authentication and authorization questions
> also arise in constrained environments. For example, a door lock has to
> authorize the person seeking access using a "digital key". Where is the
> authorization policy stored? How does the digital key communicate with
> the lock? Does the lock interact with an authorization server to obtain
> authorization information? How can access be temporarily granted to
> other persons? How can access be revoked? These types of questions have
> been answered by existing protocols for use cases outside constrained
> environments, however in constrained environments, additional and
> different requirements pose challenges for the use of various security
> protocols. In particular, the need arises for a dynamic and fine grained
> access control mechanism, where clients and/or resource servers are
> constrained.
>
> The IETF has a long history in developing three-party authentication and
> authorization protocols for distributed environments. Examples include
> Kerberos, the Public Key Infrastructure (PKI), and the Web
> Authorization Protocol (OAuth). All these protocols enjoy widespread
> deployment on the Internet. Although they all aim to solve a similar
> goal, at an abstract level, they offer quite different functions and
> utilize different message exchanges. These differences result from the
> main deployment use cases they were designed for respectively.
>
> Requirements derived from use cases indicate the suitability of existing
> work as a solution for constrained environments. These protocols,
> however, were not optimized for constrained environments. Additional
> requirements that need to be taken into account are the lack of a
> suitable user-interface and the inability of embedded devices to contact
> an authorization server in real-time with every resource access request
> due to intermittent connectivity, etc.
>
> This working group therefore aims to produce a standardized solution for
> authentication and authorization to enable authorized access (GET, PUT, POST,
> DELETE) to resources identified by a URI and hosted on a resource
> server in constrained environments. As a starting point, the working
> group will assume that access to resources at a resource server by a
> client device takes place using CoAP and is protected by DTLS. Both
> resource server and client may be constrained. This access will be
> mediated by an authorization server, which is not considered to be
> constrained.
>
> Existing authentication and authorization protocols will be used where
> applicable to build the constrained-environment solution. This requires
> relevant specifications to be reviewed for suitability, selecting a
> subset of them and restricting the options within each of the
> specifications. Some functionality, however, may not be available in
> existing protocols, in which case the solution may also involve new
> protocol work. Leveraging existing work means the working group benefits
> from available security analysis, implementation, and deployment
> experience. Moreover, a standardized solution for federated
> authentication and authorization will help to stimulate the deployment
> of constrained devices that provide increased security.
>
> Once progress in identifying suitable candidate solutions has been made,
> the working group will verify whether the same mechanisms are also
> applicable beyond the use of CoAP and DTLS, which are the two main
> protocols the group will focus on for access to resources. In
> particular, the ability to use the developed solution over HTTP and TLS
> will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
> Other security protocols may be considered as long as the primary focus is maintained.
> The group is scoped to work only on the web protocols and data carried within them.
> Furthermore, to guarantee smooth transition, the
> integration with existing deployments will be studied, particularly
> concerning the use of protocol translation proxies.
>
> This work does not make the assumption that the party offering
> application layer services is always the same party offering network
> access services.
>
> The working group has the following tasks:
>
> 1) Produce use cases and requirements
>
> 2) Identify authentication and authorization mechanisms suitable for
> resource access in constrained environments.
>
> Milestones:
>
> Jul 2014 Submit "Use cases and Requirements" as a WG item.
> Dec 2014 Submit "Authentication and Authorization Solution" as a WG item.
> Dec 2014 Optionally, submit "Use cases and Requirements" document
> to the IESG for publication as an Informational RFC.
> Jul 2016 Submit "Authentication and Authorization Solution"
> specification to the IESG for publication as a Proposed Standard.
>
> Proposed Milestones
> No milestones for charter found.

---

From: Likepeng <[email-masked]>
Date: Tue, 3 Jun 2014 10:31:56 +0000

Hi Benoit,

>Not only would I keep "AAA",

OK.

>but I would propose

>Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution.

>NEW:
Existing authentication and authorization protocols will be evaluated and re-used where
applicable to build the constrained-environment solution.

OK, fine with me.

Thanks for the feedback.

Kind Regards
Kepeng

发件人: Benoit Claise [mailto:[email-masked]]
发送时间: 2014年6月3日 12:16
收件人: Likepeng; Kathleen Moriarty; [email-masked]
抄送: [email-masked]; The IESG; [email-masked]
主题: Re: Revised charter proposal: charter-ietf-ace-00-02

Hi,

Hello all,

Thanks,

Kind Regards

Kepeng

OLD

NEW

END
Considering that OLD is

OLD

OLD

NEW

END
We have AAA-doctors telling: maybe RADIUS is applicable?
Personally, I don't know and it doesn't matter at this point.
We received feedback such as:
Let's be clear here: It was never said (in the charter or anywhere else in the group to my knowledge) that RADIUS (or indeed any other AAA protocol) would not run on constrained devices (RFC 7228). The charter simply said the protocols were not optimised for constrained devices. That does not preclude considering any protocol for suitability for constrained devices either a) as is, b) in a restricted way or c) in an adapted way.

So, at this stage, I don't think any protocols should be excluded from consideration and should certainly not be eliminated on a hunch that they might be "too big". Let's do the assessment properly at the appropriate time. As a reminder - the focus now is to complete the charter.
Or

In the charter, we mentioned that we want to reuse existing authentication and authorization protocols where applicable to build the constrained-environment solution.
... which I read as: let's consider the AAA protocols, and evaluate if they would work in constrained devices.
I don't understand the logic: why do you want to remove AAA from the charter?
Not only would I keep "AAA", but I would propose

OLD:

NEW:
Existing authentication and authorization protocols will be evaluated and re-used where
applicable to build the constrained-environment solution

Regards, Benoit

(3) Clarify the scope:

OLD:

NEW

END

OLD:

NEW

END

Environment (ACE)

constrained.

constrained.

access services.

Milestones:

Proposed Milestones

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 3 Jun 2014 08:29:36 -0400

Hi Kepeng,

If we are at a point where I can update the charter, seems that way, please
send the latest version that has been agreed upon and I'll take care of the
update.

Thanks.

On Tue, Jun 3, 2014 at 6:31 AM, Likepeng <[email-masked]> wrote:

> *发件人:* Benoit Claise [mailto:[email-masked]]
> *发送时间:* 2014年6月3日 12:16
> *收件人:* Likepeng; Kathleen Moriarty; [email-masked]
> *抄送:* [email-masked]; The IESG; [email-masked]
> *主题:* Re: Revised charter proposal: charter-ietf-ace-00-02
>
>
>
> Hi,
>
> Hello all,
>
>
>
> Let's be clear here: It was never said (in the charter or anywhere else in
> the group to my knowledge) that RADIUS (or indeed any other AAA protocol)
> would not run on constrained devices (RFC 7228). The charter simply said
> the protocols were not optimised for constrained devices. That does not
> preclude considering any protocol for suitability for constrained devices
> either a) as is, b) in a restricted way or c) in an adapted way.
>
> So, at this stage, I don't think any protocols should be excluded from
> consideration and should certainly not be eliminated on a hunch that they
> might be "too big". Let's do the assessment properly at the appropriate
> time. As a reminder - the focus now is to complete the charter.
>
> Or
>

-- 

Best regards,
Kathleen

---

From: Likepeng <[email-masked]>
Date: Tue, 3 Jun 2014 14:26:23 +0000

Hi Kathleen and all,

This is what I have now:

Change #1: (Proposed by Kepeng, confirmed by Benoit)

OLD

NEW

END

Change #2: (Proposal from Rene, supported by Stefanie)

OLD:

work as a solution for constrained environments

NEW:

Requirements derived from use cases may indicate that existing work is

 useful as basis for as a solution for constrained environments

Change #3: (Proposal from Jari, supported by Barry, Robert and Behcet)

OLD:

NEW

END

Change 4: (Proposal from Jari, revised by Rene, supported by Stefanie)

OLD:

NEW

Dec 2014 Submit "Use cases and Requirements" as a WG item.

Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for

publication as an Informational RFC.

END

I think we covered all of the IESG review comments.

If there is any open issue, please let us know.

Thanks,

Kind Regards
Kepeng
--------------------------------------------------------------------------------------------------------------------------------------------------------

Authorization and Accounting (AAA) infrastructure,and the Web

Requirements derived from use cases may indicate that existing work is
useful as basis for as a solution for constrained environments.
These protocols,
however, were not optimized for constrained environments. Additional
requirements that need to be taken into account are the lack of a
suitable user-interface and the inability of embedded devices to contact
an authorization server in real-time with every resource access request
due to intermittent connectivity, etc.

and re-used where applicable to build the constrained-environment solution.
This requires

Milestones:

Dec 2014 Submit "Use cases and Requirements" as a WG item.
Dec 2014 Submit "Authentication and Authorization Solution" as a WG item.
Apr 2015 Optionally, submit "Use cases and Requirements" document
to the IESG for publication as an Informational RFC.
Jul 2016 Submit "Authentication and Authorization Solution"
specification to the IESG for publication as a Proposed Standard.

Proposed Milestones

发件人: Kathleen Moriarty [mailto:[email-masked]]
发送时间: 2014年6月3日 14:30
收件人: Likepeng
抄送: Benoit Claise; [email-masked]; [email-masked]; The IESG; [email-masked]
主题: Re: Revised charter proposal: charter-ietf-ace-00-02

Hi Kepeng,

If we are at a point where I can update the charter, seems that way, please send the latest version that has been agreed upon and I'll take care of the update.

Thanks.

On Tue, Jun 3, 2014 at 6:31 AM, Likepeng <[email-masked]<mailto:[email-masked]>> wrote:
Hi Benoit,

OK.

OK, fine with me.

Thanks for the feedback.

Kind Regards
Kepeng

发件人: Benoit Claise [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2014年6月3日 12:16
收件人: Likepeng; Kathleen Moriarty; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; The IESG; [email-masked]<mailto:[email-masked]>
主题: Re: Revised charter proposal: charter-ietf-ace-00-02

Hi,

Hello all,

Thanks,

Kind Regards

Kepeng

OLD

NEW

END
Considering that OLD is

OLD

OLD

NEW

END

OLD:

NEW:

Regards, Benoit

(3) Clarify the scope:

OLD:

NEW

END

OLD:

NEW

END

Environment (ACE)

constrained.

constrained.

access services.

Milestones:

Proposed Milestones

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 3 Jun 2014 10:39:39 -0400

I believe there is agreement on the proposed changes.  I'll make the
updates later in the day (it's about 11:30 my time, maybe at 4) in case
anyone wants to chime in.  If we are all in agreement, I'll have it sent
for IETF review at that point.

Thank you!

On Tue, Jun 3, 2014 at 10:26 AM, Likepeng <[email-masked]> wrote:

> *发件人:* Kathleen Moriarty [mailto:[email-masked]]
> *发送时间:* 2014年6月3日 14:30
> *收件人:* Likepeng
> *抄送:* Benoit Claise; [email-masked]; [email-masked]; The IESG;
> [email-masked]
> If we are at a point where I can update the charter, seems that way,
> please send the latest version that has been agreed upon and I'll take care
> of the update.
>
>
>
> Thanks.
>
>
>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 3 Jun 2014 16:27:27 -0400

The charter text has been updated,
https://datatracker.ietf.org/doc/charter-ietf-ace/

Thank you all for your input and assistance.  If this is good, we'll move
it forward for IETF review.

On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriarty <
[email-masked]> wrote:

>> *抄送:* Benoit Claise; [email-masked]; [email-masked]; The
>> IESG; [email-masked]
>> Let's be clear here: It was never said (in the charter or anywhere else
>> in the group to my knowledge) that RADIUS (or indeed any other AAA
>> protocol) would not run on constrained devices (RFC 7228). The charter
>> simply said the protocols were not optimised for constrained devices. That
>> does not preclude considering any protocol for suitability for constrained
>> devices either a) as is, b) in a restricted way or c) in an adapted way.
>>

-- 

Best regards,
Kathleen

---

From: Benoit Claise <[email-masked]>
Date: Wed, 04 Jun 2014 08:49:36 +0200

Hi Likepeng,

You forgot
OLD:

NEW:

Regards, Benoit
> *发件人:*Kathleen Moriarty [mailto:[email-masked]]
> *发送时间:*2014年6月3日14:30
> *收件人:*Likepeng
> *抄送:*Benoit Claise; [email-masked]; [email-masked]; The 
> IESG; [email-masked]
> *主题:*Re: Revised charter proposal: charter-ietf-ace-00-02
>
> Hi Kepeng,
>
> please send the latest version that has been agreed upon and I'll take 
> care of the update.
>
> Thanks.
>
> *发件人:*Benoit Claise [mailto:[email-masked] 
> <mailto:[email-masked]>]
> *发送时间:*2014年6月3日12:16
>
> *收件人:*Likepeng; Kathleen Moriarty; [email-masked] 
> <mailto:[email-masked]>
>
> *抄送:[email-masked] <mailto:[email-masked]>; The IESG; 
> [email-masked] <mailto:[email-masked]>
>
> *主题:*Re: Revised charter proposal: charter-ietf-ace-00-02
>
> Hi,
>
>     Hello all,
>
>       
>
> (2)     Remove“AAA protocol”  from the charter:
> OLD
> consideration and should certainly not be eliminated on a hunch that 
> they might be "too big". Let's do the assessment properly at the 
> appropriate time. As a reminder - the focus now is to complete the 
> charter.
>
> Or
>
> Jul 2015 Submit“Use cases and Requirements”  document to IESG for publication as informational RFC.
>   
> NEW

---

From: Göran Selander <[email-masked]>
Date: Wed, 4 Jun 2014 07:06:31 +0000

Hi Kathleen,

In change #3 of the summary Kepeng made below I find the sentence: >>Other security protocols may be considered as long as the primary focus is maintained. >> This sentence seems to be missing from charter-ietf-ace-00-04.

Regards,
Göran

From: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 3 June 2014 22:27
To: Likepeng <[email-masked]<mailto:[email-masked]>>
Cc: Benoit Claise <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02

The charter text has been updated, https://datatracker.ietf.org/doc/charter-ietf-ace/

Thank you all for your input and assistance.  If this is good, we'll move it forward for IETF review.

On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
I believe there is agreement on the proposed changes.  I'll make the updates later in the day (it's about 11:30 my time, maybe at 4) in case anyone wants to chime in.  If we are all in agreement, I'll have it sent for IETF review at that point.

Thank you!

On Tue, Jun 3, 2014 at 10:26 AM, Likepeng <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kathleen and all,

This is what I have now:

OLD

NEW

END

OLD:

NEW:

OLD:

NEW

END

OLD:

NEW

END

Thanks,

Kind Regards
Kepeng

Milestones:

Proposed Milestones

发件人: Kathleen Moriarty [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2014年6月3日 14:30
收件人: Likepeng
抄送: Benoit Claise; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG; [email-masked]<mailto:[email-masked]>
主题: Re: Revised charter proposal: charter-ietf-ace-00-02

Hi Kepeng,

Thanks.

OK.

OK, fine with me.

Thanks for the feedback.

Kind Regards
Kepeng

Hi,

Hello all,

Thanks,

Kind Regards

Kepeng

OLD

NEW

END
Considering that OLD is

OLD

OLD

NEW

END

OLD:

NEW:

Regards, Benoit

(3) Clarify the scope:

OLD:

NEW

END

OLD:

NEW

END

Environment (ACE)

constrained.

constrained.

access services.

Milestones:

Proposed Milestones

--

Best regards,
Kathleen

--

Best regards,
Kathleen

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Jun 2014 10:05:37 -0400

Thank you, Göran.

It must have been a cut-n-paste error.  The first sentence for the
'replace' did not match the original or the new either.  If the next
version isn't quite right, pasting in a new full version may be better.
 I'll look back through Benoit's comment now as well.

On Wed, Jun 4, 2014 at 3:06 AM, Göran Selander <[email-masked]>
wrote:

>  Hi Kathleen,
>
>   In change #3 of the summary Kepeng made below I find the sentence: >>Other
> security protocols may be considered as long as the primary focus is
> maintained. >> This sentence seems to be missing from
> charter-ietf-ace-00-04.
>
>  Regards,
> Göran
>
>
>   From: Kathleen Moriarty <[email-masked]>
> To: Likepeng <[email-masked]>
> Cc: Benoit Claise <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, The IESG <
> [email-masked]>, "[email-masked]" <[email-masked]>

-- 

Best regards,
Kathleen

---

From: Likepeng <[email-masked]>
Date: Wed, 4 Jun 2014 14:54:42 +0000

Hi Benoit,

Sorry, my mistake. I forgot to make that change.

@Kethleen, please help to make the suggested change.

Thanks a lot,

Kind Regards
Kepeng

发件人: Ace [mailto:[email-masked]] 代表 Benoit Claise
发送时间: 2014年6月4日 8:50
收件人: Likepeng; Kathleen Moriarty
抄送: [email-masked]; [email-masked]; The IESG; [email-masked]
主题: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02

Hi Likepeng,

You forgot
OLD:

NEW:

Regards, Benoit

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Jun 2014 10:56:27 -0400

Benoit had one other change mentioned in a previous email that was left
out. He agrees that it is editorial.  I'm fine with adding it if that is
okay, but would prefer to leave "used" in instead of "re-used" as it isn't
needed (IMO).

Is the last option agreeable and would it clear your concerns, Benoit?

OLD:

NEW:
Existing authentication and authorization protocols will be evaluated and
re-used where
applicable to build the constrained-environment solution

NEWER:
Existing authentication and authorization protocols will be evaluated and
used where
applicable to build the constrained-environment solution

On Wed, Jun 4, 2014 at 10:05 AM, Kathleen Moriarty <
[email-masked]> wrote:

> On Wed, Jun 4, 2014 at 3:06 AM, Göran Selander <
> [email-masked]> wrote:
>
>>  Hi Kathleen,
>>

-- 

Best regards,
Kathleen

---

From: Benoit Claise <[email-masked]>
Date: Wed, 04 Jun 2014 18:38:27 +0200

Hi Kathleen,

Fine with me

Regards, B.
> Benoit had one other change mentioned in a previous email that was 
> left out. He agrees that it is editorial.  I'm fine with adding it if 
> that is okay, but would prefer to leave "used" in instead of "re-used" 
> as it isn't needed (IMO).
>
>     Existing authentication and authorization protocols will be
>     evaluated and used where
> On Wed, Jun 4, 2014 at 10:05 AM, Kathleen Moriarty 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Thank you, Göran.
>
>     'replace' did not match the original or the new either.  If the
>     next version isn't quite right, pasting in a new full version may
>     be better.  I'll look back through Benoit's comment now as well.
>
>
>     On Wed, Jun 4, 2014 at 3:06 AM, Göran Selander
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         Hi Kathleen,
>
>         In change #3 of the summary Kepeng made below I find the
>         sentence: >>Other security protocols may be considered as long
>         as the primary focus is maintained. >> This sentence seems to
>         be missing from charter-ietf-ace-00-04.
>
>         Regards,
>         Göran
>
>
>         From: Kathleen Moriarty <[email-masked]
>         <mailto:[email-masked]>>
>         To: Likepeng <[email-masked] <mailto:[email-masked]>>
>         Cc: Benoit Claise <[email-masked]
>         <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
>         The IESG <[email-masked] <mailto:[email-masked]>>,
>         "[email-masked] <mailto:[email-masked]>"
>         <[email-masked] <mailto:[email-masked]>>
>             Thank you all for your input and assistance.  If this is
>             good, we'll move it forward for IETF review.
>
>
>
>             On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriarty
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 I believe there is agreement on the proposed changes.
>                  I'll make the updates later in the day (it's about
>                 11:30 my time, maybe at 4) in case anyone wants to
>                 chime in.  If we are all in agreement, I'll have it
>                 sent for IETF review at that point.
>
>                 Thank you!
>
>
>                 On Tue, Jun 3, 2014 at 10:26 AM, Likepeng
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>
>                     Hi Kathleen and all,
>
>                     This is what I have now:
>
>                     *发件人:*Kathleen Moriarty
>                     [mailto:[email-masked]
>                     <mailto:[email-masked]>]
>                     *发送时间:*2014年6月3日14:30
>                     *收件人:*Likepeng
>                     *抄送:*Benoit Claise; [email-masked]
>                     <mailto:[email-masked]>; [email-masked]
>                     <mailto:[email-masked]>; The IESG;
>                     If we are at a point where I can update the
>                     charter, seems that way, please send the latest
>                     version that has been agreed upon and I'll take
>                     care of the update.
>
>                     Thanks.
>
>                     On Tue, Jun 3, 2014 at 6:31 AM, Likepeng
>                     <[email-masked] <mailto:[email-masked]>>
>                     wrote:
>
>                     Hi Benoit,
>
>                     Existing authentication and authorization
>                     protocols will be evaluated and re-used where
>
>                     *收 件人:*Likepeng; Kathleen Moriarty;
>                     [email-masked] <mailto:[email-masked]>
>
>                     *抄 送:[email-masked]
>                     <mailto:[email-masked]>; The IESG;
>                     *主 题:*Re: Revised charter proposal:
>                     charter-ietf-ace-00-02
>
>                     Hi,
>
>                         Hello all,
>
>                           
>
>                     Let's be clear here: It was never said (in the
>                     charter or anywhere else in the group to my
>                     knowledge) that RADIUS (or indeed any other AAA
>                     protocol) would not run on constrained devices
>                     (RFC 7228). The charter simply said the protocols
>                     were not optimised for constrained devices. That
>                     does not preclude considering any protocol for
>                     suitability for constrained devices either a) as
>                     is, b) in a restricted way or c) in an adapted way.
>
>                     So, at this stage, I don't think any protocols
>                     should be excluded from consideration and should
>                     certainly not be eliminated on a hunch that they
>                     might be "too big". Let's do the assessment
>                     properly at the appropriate time. As a reminder -
>                     the focus now is to complete the charter.
>
>                     Or
>
>                     ... which I read as: let's consider the AAA
>                     protocols, and evaluate if they would work in
>                     constrained devices.
>                     Existing authentication and authorization
>                     protocols will be evaluated and re-used where

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Jun 2014 13:04:44 -0400

Thanks, Benoit!

The change has been made.  Once agreed upon and cleared, I'll progress this.

On Wed, Jun 4, 2014 at 12:38 PM, Benoit Claise <[email-masked]> wrote:

>>>>> *收 件人:* Likepeng; Kathleen Moriarty; [email-masked]
>>>>>
>>>>> *抄 送:* [email-masked]; The IESG; [email-masked]
>>>>>
>>>>> *主 题:* Re: Revised charter proposal: charter-ietf-ace-00-02
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Hello all,
>>>>>
>>>>>
>>>>>
>>>>> else in the group to my knowledge) that RADIUS (or indeed any other AAA

-- 

Best regards,
Kathleen