Subject: Re: [Ace] Doodle for ACE virtual interim meeting

From: "Kepeng Li" <[email-masked]>
Date: Fri, 13 Jan 2017 17:44:35 +0800

Hallo all,

According to the doodle poll, let’s have a call on 14th Feb, GMT 15:00 ~
15:59.

We have the same amount of participants about Option 1, 2, and 4.

Considering that Mike has strong position about this draft, so I accommodate
his choice to allow him to participate.

Authors, please prepare some slides for the discussion.

I will send the WebEx information later.

Thanks,

Kind Regards
Kepeng

发件人:  Ace <[email-masked]> on behalf of Li Kepeng
<[email-masked]>
日期:  Saturday, 7 January 2017 at 8:43 PM
至:  ace <[email-masked]>
抄送:  Kathleen Moriarty <[email-masked]>, Hannes
Tschofenig <[email-masked]>
主题:  [Ace] Doodle for ACE virtual interim meeting

Hi all,

To speed up our progress on group communication security draft, we plan to
have a virtual interim meeting in the middle of Feb.

I proposed four options for the meeting time:
1. 9th Feb, Thursday, GMT 14:00 ~ 15:00.
2. 9th Feb, Thursday, GMT 15:00 ~ 15:59.
3. 14th Feb, Tuesday, GMT 14:00 ~ 15:00.
4. 14th Feb, Tuesday, GMT 15:00 ~ 15:59.

Please indicate your available time from the doodle poll:
http://doodle.com/poll/v6nbeggazekaq2ut

We will mainly discuss this draft:
https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/

Thanks,

Kind Regards
Kepeng 

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

---

From: Michael StJohns <[email-masked]>
Date: Fri, 13 Jan 2017 11:28:39 -0500

On 1/13/2017 4:44 AM, Kepeng Li wrote:
> Hallo all,
>
> According to the doodle poll, let’s have a call on 14th Feb, GMT 15:00 
> ~ 15:59.
>
> Considering that Mike has strong position about this draft, so I 
> accommodate his choice to allow him to participate.
Sorry what?   I'm assuming by "Mike" you mean me. I missed the original 
doodle call and haven't actually made a choice.  I can't actually make 
the 14th as I'm on a plane.

I can make either of the Thursday 9 February times though.

In any event, if the slides are ready ahead of time I'll just provide 
some commentary on the mailing list.   I note that the authors haven't 
engaged with the comments provided by Jim Schaad and it would be useful 
if they do so.

WRT to the document, its difficult to make any judgements or suggest any 
improvements without understanding the goals of the document. As a bare 
minimum, up front the document should a) define "low latency" including 
each element that contributes to the calculation (this has been a moving 
target - it was something like 250ms for DICE and appears to have moved 
downward in ACE) and b) define the security services that are to be 
provided when using the keys served up by this protocol.   (e.g. it 
currently appears that the document is proposing a key management scheme 
for group confidentiality, group integrity and group authentication).   
Lastly, the document needs to include any other constraints.  In the 
instant case, low latency may be accomplished by hardware for public key 
operations - but there is a constraint never actually cited in the 
document - low/no cost for the build of the product (it's referred to 
obliquely as processing cost for the constrained device and is more 
properly attributed to the BOM).

If there is any other application besides lighting that has a use for 
this protocol - now is the time to bring it forward.

Finally, a statement of security requirements for the exemplar 
application (lighting) should be provided so that the protocol can be 
evaluated against those requirements to see if we've actually managed to 
come up with something that meets the needs.

Mike

> 发件人: Ace <[email-masked] <mailto:[email-masked]>> on 
> behalf of Li Kepeng <[email-masked] 
> <mailto:[email-masked]>>
> 至: ace <[email-masked] <mailto:[email-masked]>>
> 抄送: Kathleen Moriarty <[email-masked] 
> <mailto:[email-masked]>>, Hannes Tschofenig 
> <[email-masked] <mailto:[email-masked]>>
> To speed up our progress on group communication security draft, we 
> plan to have a virtual interim meeting in the middle of Feb.
>
> [email-masked] <mailto:[email-masked]> 
> https://www.ietf.org/mailman/listinfo/ace
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: "Kepeng Li" <[email-masked]>
Date: Sat, 14 Jan 2017 10:00:36 +0800

Oh, sorry, my mistake.

I made a mistake between you and Mike Jones.

Let’s change our call to Option 1, 9th Feb, Thursday, GMT 14:00 ~ 15:00.

I will send out the WebEx info later.

Kind Regards
Kepeng

发件人:  Ace <[email-masked]> on behalf of Michael StJohns
<[email-masked]>
日期:  Saturday, 14 January 2017 at 12:28 AM
至:  <[email-masked]>
主题:  Re: [Ace] Doodle for ACE virtual interim meeting

 Sorry what?   I'm assuming by "Mike" you mean me. I missed the original
doodle call and haven't actually made a choice.  I can't actually make the
14th as I'm on a plane.

 In any event, if the slides are ready ahead of time I'll just provide some
commentary on the mailing list.   I note that the authors haven't engaged
with the comments provided by Jim Schaad and it would be useful if they do
so.
 
 WRT to the document, its difficult to make any judgements or suggest any
improvements without understanding the goals of the document.  As a bare
minimum, up front the document should a) define "low latency" including each
element that contributes to the calculation  (this has been a moving target
- it was something like 250ms for DICE and appears to have moved downward in
ACE) and b) define the security services that are to be provided when using
the keys served up by this protocol.   (e.g. it currently appears that the
document is proposing a key management scheme for group confidentiality,
group integrity and group authentication).   Lastly, the document needs to
include any other constraints.  In the instant case, low latency may be
accomplished by hardware for public key operations - but there is a
constraint never actually cited in the document - low/no cost for the build
of the product (it's referred to obliquely as processing cost for the
constrained device and is more properly attributed to the BOM).
 
 If there is any other application besides lighting that has a use for this
protocol - now is the time to bring it forward.
 
 Finally, a statement of security requirements for the exemplar application
(lighting) should be provided so that the protocol can be evaluated against
those requirements to see if we've actually managed to come up with
something that meets the needs.
 
 Mike

>  抄送:  Kathleen Moriarty <[email-masked]>, Hannes Tschofenig
> <[email-masked]>
>  _______________________________________________ Ace mailing list [email-masked]
> [email-masked]://www.ietf.org/mailman/listinfo/ace
>

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Sat, 14 Jan 2017 12:00:28 +0000

I think at least one of the draft authors is away until the 8th.  Can we push out a week?

Eliot

On Jan 13, 2017, at 6:01 PM, Kepeng Li <[email-masked]<mailto:[email-masked]>> wrote:

Oh, sorry, my mistake.

Let's change our call to Option 1, 9th Feb, Thursday, GMT 14:00 ~ 15:00.

Kind Regards
Kepeng

???: Ace <[email-masked]<mailto:[email-masked]>> on behalf of Michael StJohns <[email-masked]<mailto:[email-masked]>>
??: Saturday, 14 January 2017 at 12:28 AM
?: <[email-masked]<mailto:[email-masked]>>
??: Re: [Ace] Doodle for ACE virtual interim meeting

According to the doodle poll, let's have a call on 14th Feb, GMT 15:00 ~ 15:59.

Considering that Mike has strong position about this draft, so I accommodate his choice to allow him to participate.
Sorry what?   I'm assuming by "Mike" you mean me. I missed the original doodle call and haven't actually made a choice.  I can't actually make the 14th as I'm on a plane.

In any event, if the slides are ready ahead of time I'll just provide some commentary on the mailing list.   I note that the authors haven't engaged with the comments provided by Jim Schaad and it would be useful if they do so.

WRT to the document, its difficult to make any judgements or suggest any improvements without understanding the goals of the document.  As a bare minimum, up front the document should a) define "low latency" including each element that contributes to the calculation  (this has been a moving target - it was something like 250ms for DICE and appears to have moved downward in ACE) and b) define the security services that are to be provided when using the keys served up by this protocol.   (e.g. it currently appears that the document is proposing a key management scheme for group confidentiality, group integrity and group authentication).   Lastly, the document needs to include any other constraints.  In the instant case, low latency may be accomplished by hardware for public key operations - but there is a constraint never actually cited in the document - low/no cost for the build of the product (it's referred to obliquely as processing cost for the constrained device and is more properly attributed to the BOM).

If there is any other application besides lighting that has a use for this protocol - now is the time to bring it forward.

Finally, a statement of security requirements for the exemplar application (lighting) should be provided so that the protocol can be evaluated against those requirements to see if we've actually managed to come up with something that meets the needs.

Mike

Thanks,

Kind Regards
Kepeng

???: Ace <[email-masked]<mailto:[email-masked]>> on behalf of Li Kepeng <[email-masked]<mailto:[email-masked]>>
??: Saturday, 7 January 2017 at 8:43 PM
?: ace <[email-masked]<mailto:[email-masked]>>
??: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
??: [Ace] Doodle for ACE virtual interim meeting

Hi all,

To speed up our progress on group communication security draft, we plan to have a virtual interim meeting in the middle of Feb.

Thanks,

Kind Regards
Kepeng

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

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

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

---

From: "Kepeng Li" <[email-masked]>
Date: Mon, 16 Jan 2017 21:55:40 +0800

OK. 

I added two more options in the original doodle poll:
Option 5. 16th Feb, Thursday, GMT 14:00 ~ 15:00.
Option 6. 16th Feb, Thursday, GMT 15:00 ~ 15:59.

Please fill out the two additional doodle poll options:
http://doodle.com/poll/v6nbeggazekaq2ut

I will check the results at the end of this week.

Thanks,
Kind Regards
Kepeng

发件人:  "Eliot Lear (elear)" <[email-masked]>
日期:  Saturday, 14 January 2017 at 8:00 PM
至:  Li Kepeng <[email-masked]>
抄送:  Michael StJohns <[email-masked]>, "[email-masked]" <[email-masked]>
主题:  Re: [Ace] Doodle for ACE virtual interim meeting

I think at least one of the draft authors is away until the 8th.  Can we
push out a week?

Eliot

On Jan 13, 2017, at 6:01 PM, Kepeng Li <[email-masked]> wrote:

> Sorry what?   I'm assuming by "Mike" you mean me. I missed the original doodle
> call and haven't actually made a choice.  I can't actually make the 14th as
> I'm on a plane.
> 
> commentary on the mailing list.   I note that the authors haven't engaged with
> the comments provided by Jim Schaad and it would be useful if they do so.
> 
> element that contributes to the calculation  (this has been a moving target -
> it was something like 250ms for DICE and appears to have moved downward in
> document is proposing a key management scheme for group confidentiality, group
> integrity and group authentication).   Lastly, the document needs to include
> any other constraints.  In the instant case, low latency may be accomplished
> by hardware for public key operations - but there is a constraint never
> actually cited in the document - low/no cost for the build of the product
> (it's referred to obliquely as processing cost for the constrained device and
> is more properly attributed to the BOM).
> 
> those requirements to see if we've actually managed to come up with something
> that meets the needs.
> 
> Mike
> 
> 
>>