[Ace] Comments on draft-tiloca-ace-oscoap-joining

[Jim Schaad]

After the interim meeting, I read this document through in order to produce
a review.  Instead you are going to get a meta-review.

I am having a hard to seeing why this document exists in its current form
and it is not some type of simple profile of the pub-sub security draft.
While I am not sure that this document is a sub-set of that document, it
appears to be about 90-99% a sub set of that document.  Consider the
following:

You have both the publisher and subscriber roles as in the pub-sub draft.

You have an entity which is doing key distribution in the system.  For the
pub-sub draft this is AS2 for you it is the RS, but they are performing the
exact same set of tasks.

The pub-sub draft as and endpoint which holds the encrypted messages, in its
place you are using the multi-cast UDP channel.  In both cases they are
basically unprotected-untrusted entities to distribute the content message.
The only difference is that in the pub-sub model the RS will also provide
restricted access to publishing which is not enforceable here.

Both of these documents are missing what I would consider to be core pieces.
The pub-sub document does initial key distribution, while this document does
not.  Neither document does any discussion of how subsequent key
distribution is done to deal with forward and backward security of messages.


This document probably needs to define a new relationship, which might be
more generally used, to say - this URL is where you get the security
information for this URL which is published in the directory - esp in the
case of multi-cast address URLs in the resource directory.  You might also
find that the correct answer is not to use a separate resource for each
channel, but to allow for the use of URI path elements to define the
security for a resource.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap

[Kepeng Li]

Thanks for your feedback.

Please find the revised minutes here:
https://datatracker.ietf.org/meeting/interim-2017-ace-02/materials/minutes-i
nterim-2017-ace-02-201710181300/

Kind Regards
Kepeng

发件人:  Renzo Navas 
日期:  Thursday, 19 October 2017 at 4:33 PM
至:  Hannes Tschofenig 
抄送:  Li Kepeng , Kathleen Moriarty
, Hannes Tschofenig
, ace 
主题:  Re: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about
ACE roadmap


On Thu, Oct 19, 2017 at 10:27 AM, Hannes Tschofenig
 wrote:
> Ø I don't see my votes recorder, (neither Ludwig's);
> 
>  
> We copied what was in the chat Window
>  

Ok then probably was a comparibilitty issue? I was on Linux HTML version of
Webex, and Ludwig too -by his comments-. I sent my chat/votes (I could see
them) , and I could also see (If I recall properly... now Im in doubt)
Ludwig's voties too.
In any case the conclusions reflect the consensus anyway.
 

>  
> 
> Ø I don't know if the consensus was that MQTT is mid priority (and pub/sub
> relegated to low), just that mqtt is rather new draft and we should discuss it
> more.
> 
>  
> 
> I prefer to say that there are high priority items and then there is the rest,
> which requires further thoughts.


I agree!
 

Saludos,

Renzo



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag

[Jim Schaad]

The type of location where  it might show up is where one does a value that is 
placed in an array where it can be either an A or a B and you use the tag to 
distinguish between the two options.  This can be very useful in those cases.  



> -Original Message-
> From: Carsten Bormann [mailto:c...@tzi.org]
> Sent: Thursday, October 19, 2017 1:32 PM
> To: Hannes Tschofenig 
> Cc: Mike Jones ; Jim Schaad
> ; ace@ietf.org
> Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag
> 
> On Oct 19, 2017, at 21:30, Hannes Tschofenig
>  wrote:
> >
> > For the cost  saving of one byte we are essentially introduction options
> here. I am wondering whether this byte is worth it.
> 
> Two bytes.
> 
> It’s not really an option, as in every context there will be a single right 
> way to
> do this.
> But yes, there are naked and tagged CWTs now.
> 
> (If we only define the tagged version, very quickly there will be specs that
> define a “compressed CWT” that just leaves out those first two bytes…)
> 
> Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] multicast

[Hannes Tschofenig]

No problem. Take your time.

Ciao
Hannes

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Beck, Stefan
Sent: 19 October 2017 22:15
To: ace@ietf.org
Subject: Re: [Ace] multicast

As mentioned in yesterday's call: give me/us some more time to work it out more 
precisely first.
We have a meeting on Monday to verify and consolidate the current proposal - I 
believe I shouldn't speak up before that.
(And I don't want to risk a shit-storm in case I get some parts wrong or 
immature; most of the people on this list are much smarter than me regarding 
these topics ;-)

Stevie

> -Original Message-
> From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com]
> Sent: Thursday, October 19, 2017 10:03 PM
> To: Beck, Stefan ; ace@ietf.org
> Subject: RE: [Ace] multicast
>
> So, what are you suggesting?
>
> -Original Message-
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Beck, Stefan
> Sent: 19 October 2017 21:59
> To: ace@ietf.org
> Subject: Re: [Ace] multicast
>
> I totally agree with Mike.
> BTW, Hannes, this was "part a." of Idea #1 - the only added value I've
> seen was that the device could raise an alarm - so there is awareness
> of an attack at least "after the fact". However, it adds complexity to
> the constrained device - and alternatively, one could just use one
> separate listener to the multicast group, that just does this job.
> It's multicast, so a single listener is sufficient to handle such type
> of alarms.
>
> "Part b." would even be more important to me: the multicasters (not
> the
> listeners) are the constrained devices that are unable to sign their
> messages in time. (Think of battery-powered low cost wall switches).
> In that case they would need to pre-compile their multicast message
> (or set of
> messages-
> eg. one or more for turn off / turn on / dim level x events), so they
> just fire them when the event happens.
> Again, this adds a lot of complexity, and may even not be feasible at
> all (in case you have timing constraints in the crypto operations)
>
> Stevie
>
> > -Original Message-
> > From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael StJohns
> > Sent: Thursday, October 19, 2017 6:38 PM
> > To: ace@ietf.org
> > Subject: Re: [Ace] multicast
> >
> > On 10/19/2017 10:59 AM, Hannes Tschofenig wrote:
> > > I suspect the idea is the following:
> > >
> > > 1) First, you would decrypt the packet and validate the mac
> > > (assuming that it is an AEAD cipher)
> > > 2) You execute the operation to meet the latency requirements.
> > > 3) Then, you can take time to verify the digital signature
> > > (outside the latency requirements)
> > >
> > > Is that the idea?
> > >
> >
> > It can't possibly be.   What do you do if the digital signature doesn't
> > verify?  Reverse the operation?   Flicker the lights?  Go back to the
> > original
> > levels?  Flash "OOPS" in morse code?
> >
> > You need to verify the signature in advance of doing an operation
> > authenticated and authorized by that signature
> >
> > Mike
> >
> > ___
> > Ace mailing list
> > Ace@ietf.org
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> > ww
> > .i
> >
> etf.org%2Fmailman%2Flistinfo%2Face=02%7C01%7C%7Cd6a2b032140a4
> >
> 8082e1908d5170fc763%7Cec1ca250c2344d56a76b7dfb9eee0c46%7C0%7C0%7
> >
> C636440278895347864=fpqgRpYFEvJxQUc4l2zlHM%2BUc7VaYLcp217q3
> > 2kHgLQ%3D=0
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] multicast

[Beck, Stefan]

As mentioned in yesterday's call: give me/us some more time to work it out 
more precisely first.
We have a meeting on Monday to verify and consolidate the current proposal - I 
believe
I shouldn't speak up before that.
(And I don't want to risk a shit-storm in case I get some parts wrong or 
immature; most of
the people on this list are much smarter than me regarding these topics ;-)

Stevie

> -Original Message-
> From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com]
> Sent: Thursday, October 19, 2017 10:03 PM
> To: Beck, Stefan ; ace@ietf.org
> Subject: RE: [Ace] multicast
>
> So, what are you suggesting?
>
> -Original Message-
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Beck, Stefan
> Sent: 19 October 2017 21:59
> To: ace@ietf.org
> Subject: Re: [Ace] multicast
>
> I totally agree with Mike.
> BTW, Hannes, this was "part a." of Idea #1 - the only added value I've seen 
> was
> that the device could raise an alarm - so there is awareness of an attack at 
> least
> "after the fact". However, it adds complexity to the constrained device - 
> and
> alternatively, one could just use one separate listener to the multicast 
> group,
> that just does this job. It's multicast, so a single listener is sufficient 
> to handle
> such type of alarms.
>
> "Part b." would even be more important to me: the multicasters (not the
> listeners) are the constrained devices
> that are unable to sign their messages in time. (Think of battery-powered 
> low
> cost wall switches).
> In that case they would need to pre-compile their multicast message (or set 
> of
> messages-
> eg. one or more for turn off / turn on / dim level x events), so they just 
> fire them
> when the event happens.
> Again, this adds a lot of complexity, and may even not be feasible at all 
> (in case
> you have timing constraints in the crypto operations)
>
> Stevie
>
> > -Original Message-
> > From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael StJohns
> > Sent: Thursday, October 19, 2017 6:38 PM
> > To: ace@ietf.org
> > Subject: Re: [Ace] multicast
> >
> > On 10/19/2017 10:59 AM, Hannes Tschofenig wrote:
> > > I suspect the idea is the following:
> > >
> > > 1) First, you would decrypt the packet and validate the mac
> > > (assuming that it is an AEAD cipher)
> > > 2) You execute the operation to meet the latency requirements.
> > > 3) Then, you can take time to verify the digital signature (outside
> > > the latency requirements)
> > >
> > > Is that the idea?
> > >
> >
> > It can't possibly be.   What do you do if the digital signature doesn't
> > verify?  Reverse the operation?   Flicker the lights?  Go back to the
> > original
> > levels?  Flash "OOPS" in morse code?
> >
> > You need to verify the signature in advance of doing an operation
> > authenticated and authorized by that signature
> >
> > Mike
> >
> > ___
> > Ace mailing list
> > Ace@ietf.org
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > .i
> >
> etf.org%2Fmailman%2Flistinfo%2Face=02%7C01%7C%7Cd6a2b032140a4
> >
> 8082e1908d5170fc763%7Cec1ca250c2344d56a76b7dfb9eee0c46%7C0%7C0%7
> >
> C636440278895347864=fpqgRpYFEvJxQUc4l2zlHM%2BUc7VaYLcp217q3
> > 2kHgLQ%3D=0
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended 
> recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in 
> any
> medium. Thank you.


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] multicast

[Beck, Stefan]

I totally agree with Mike.
BTW, Hannes, this was "part a." of Idea #1 - the only added value I've seen 
was that the device
could raise an alarm - so there is awareness of an attack at least "after the 
fact". However,
it adds complexity to the constrained device - and alternatively, one could 
just use one
separate listener to the multicast group, that just does this job. It's 
multicast, so a single listener
is sufficient to handle such type of alarms.

"Part b." would even be more important to me: the multicasters (not the 
listeners) are the constrained devices
that are unable to sign their messages in time. (Think of battery-powered low 
cost wall switches).
In that case they would need to pre-compile their multicast message (or set of 
messages-
eg. one or more for turn off / turn on / dim level x events), so they just 
fire them when the event happens.
Again, this adds a lot of complexity, and may even not be feasible at all (in 
case you have timing constraints in the crypto operations)

Stevie

> -Original Message-
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael StJohns
> Sent: Thursday, October 19, 2017 6:38 PM
> To: ace@ietf.org
> Subject: Re: [Ace] multicast
>
> On 10/19/2017 10:59 AM, Hannes Tschofenig wrote:
> > I suspect the idea is the following:
> >
> > 1) First, you would decrypt the packet and validate the mac (assuming
> > that it is an AEAD cipher)
> > 2) You execute the operation to meet the latency requirements.
> > 3) Then, you can take time to verify the digital signature (outside
> > the latency requirements)
> >
> > Is that the idea?
> >
>
> It can't possibly be.   What do you do if the digital signature doesn't
> verify?  Reverse the operation?   Flicker the lights?  Go back to the 
> original
> levels?  Flash "OOPS" in morse code?
>
> You need to verify the signature in advance of doing an operation 
> authenticated
> and authorized by that signature
>
> Mike
>
> ___
> Ace mailing list
> Ace@ietf.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Face=02%7C01%7C%7Cd6a2b032140a4
> 8082e1908d5170fc763%7Cec1ca250c2344d56a76b7dfb9eee0c46%7C0%7C0%7
> C636440278895347864=fpqgRpYFEvJxQUc4l2zlHM%2BUc7VaYLcp217q3
> 2kHgLQ%3D=0


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag

[Mike Jones]

I also agree that the spec already has this right.  Typically no tag will be 
needed because the application knows the data structure is a CWT from context.  
The tag is available for any use cases where it's needed to resolve ambiguity 
that might otherwise be present.

-- Mike

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Carsten Bormann
Sent: Thursday, October 19, 2017 10:05 AM
To: Jim Schaad 
Cc: Hannes Tschofenig ; ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag

On Oct 19, 2017, at 18:41, Jim Schaad  wrote:
> 
>   • I already know that this is going to be a CWT so I save a byte.
>   • I don’t know so I waste a tag byte in that case.

Right.  In REST protocols, we usually have a media type, so we don’t need the 
CBOR Tag.
Within some other data structures, or in legacy protocols such as MQTT, we may 
not have that, so a tag is a good single standard way to indicate this.

(Does the latter case need to be a single byte [which is then preceded by 0xd8, 
by the way]?  Maybe that would not have been necessary(*), but then CWTs are 
going to be rather common.  
And 61 is a “=“, which is cool for our hexdump reading population :-)

Grüße, Carsten

(*) The number is already assigned, BTW.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag

[Carsten Bormann]

On Oct 19, 2017, at 18:41, Jim Schaad  wrote:
> 
>   • I already know that this is going to be a CWT so I save a byte.
>   • I don’t know so I waste a tag byte in that case.

Right.  In REST protocols, we usually have a media type, so we don’t need the 
CBOR Tag.
Within some other data structures, or in legacy protocols such as MQTT, we may 
not have that, so a tag is a good single standard way to indicate this.

(Does the latter case need to be a single byte [which is then preceded by 0xd8, 
by the way]?  Maybe that would not have been necessary(*), but then CWTs are 
going to be rather common.  
And 61 is a “=“, which is cool for our hexdump reading population :-)

Grüße, Carsten

(*) The number is already assigned, BTW.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] multicast

[Beck, Stefan]

Hi Derek,

The requirement roughly is:
Assume a few light switches as multicasters and many luminaires as listeners
- turning lights on / off via multicast
The end-2-end processing (multicaster to encrypt the message, the
network to transmit the message, and the listeners to validate the
message) should not exceed ~200 ms.

Stevie

> -Original Message-
> From: Derek Atkins [mailto:de...@ihtfp.com]
> Sent: Thursday, October 19, 2017 3:51 PM
> To: Beck, Stefan 
> Cc: Hannes Tschofenig ; ace@ietf.org
> Subject: Re: [Ace] multicast
> 
> Hi,
> 
> "Beck, Stefan"  writes:
> 
> [snip]
> > even supporting the "low-latency" requirements we need, also
> > considering the
> [snip]
> 
> Could you provide some more concrete numbers for your definition of "low-
> latency" requirements?
> 
> Thanks,
> 
> -derek
> 
> --
>Derek Atkins 617-623-3745
>de...@ihtfp.com
> https://emea01.safelinks.protection.outlook.com/?url=www.ihtfp.com=0
> 2%7C01%7C%7C015cc4c4b8da4534720808d516f87712%7Cec1ca250c2344d56a
> 76b7dfb9eee0c46%7C0%7C0%7C636440178780250813=C3WzL%2FAdUd
> wWhHz3aaAg0V4TZgBCWIkYqqH%2FF3tMjDw%3D=0
>Computer and Internet Security Consultant


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] multicast

[Derek Atkins]

Hi,

"Beck, Stefan"  writes:

[snip]
> even supporting the "low-latency" requirements we need, also considering the
[snip]

Could you provide some more concrete numbers for your definition of
"low-latency" requirements?

Thanks,

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] multicast

[Beck, Stefan]

Yes, correct.

Stevie

> -Original Message-
> From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com]
> Sent: Thursday, October 19, 2017 2:52 PM
> To: Beck, Stefan ; ace@ietf.org
> Subject: RE: multicast
> 
> Hi Stefan,
> 
> I am trying to understand your ideas.
> 
> ~snip ~
> 
> > For multicast, my focus is on using asymmetric encryption for
> authentication & integrity, and using symmetric encryption for
confidentiality.
> 
> In your view, you are sending a multicast message that will contain a
digital
> signature and is also encrypted using symmetric key crypto?
> 
> Is this correct?
> 
> Ciao
> Hannes
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
recipient,
> please notify the sender immediately and do not disclose the contents to
any
> other person, use it for any purpose, or store or copy the information in
any
> medium. Thank you.


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] I-D Action: draft-ietf-ace-oauth-authz-08.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : Authentication and Authorization for Constrained 
Environments (ACE)
Authors : Ludwig Seitz
  Goeran Selander
  Erik Wahlstroem
  Samuel Erdtman
  Hannes Tschofenig
Filename: draft-ietf-ace-oauth-authz-08.txt
Pages   : 70
Date: 2017-10-19

Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments.  The
   framework is based on a set of building blocks including OAuth 2.0
   and CoAP, thus making a well-known and widely used authorization
   solution suitable for IoT devices.  Existing specifications are used
   where possible, but where the constraints of IoT devices require it,
   extensions are added and profiles are defined.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap

[Renzo Navas]

On Thu, Oct 19, 2017 at 10:27 AM, Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Ø  I don't see my votes recorder, (neither Ludwig's);
>
>
>
> We copied what was in the chat Window
>
>
>

Ok then probably was a comparibilitty issue? I was on Linux HTML version
of  Webex, and Ludwig too -by his comments-. I sent my chat/votes (I could
see them) , and I could also see (If I recall properly... now Im in doubt)
Ludwig's voties too.
In any case the conclusions reflect the consensus anyway.



>
> Ø  I don't know if the consensus was that MQTT is mid priority (and
> pub/sub relegated to low), just that mqtt is rather new draft and we should
> discuss it more.
>
>
>
> I prefer to say that there are high priority items and then there is the
> rest, which requires further thoughts.
>


I agree!


Saludos,

Renzo
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap

[Hannes Tschofenig]

Ø  I don't see my votes recorder, (neither Ludwig's);

We copied what was in the chat Window



Ø  I don't know if the consensus was that MQTT is mid priority (and pub/sub 
relegated to low), just that mqtt is rather new draft and we should discuss it 
more.

I prefer to say that there are high priority items and then there is the rest, 
which requires further thoughts.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap

[Renzo Navas]

Hi Kepeng, all

thank you for the resumé.
I don't see my votes recorder, (neither Ludwig's);

I strongly support OSCOAP; then pub/sub and Multicast OSCOAP.

In any case, I agree with the  conclusions 1 , 2.


I don't know if the consensus was that MQTT is mid priority (and pub/sub
relegated to low), just that mqtt is rather new draft and we should discuss
it more.

Regards!

Renzo

On Thu, Oct 19, 2017 at 8:52 AM, Kepeng Li 
wrote:

> Hello all,
>
> Please find the initial minutes from the link below:
> https://datatracker.ietf.org/meeting/interim-2017-ace-02/
> materials/minutes-interim-2017-ace-02-201710181300/
>
> Please take a look and let me know if you have any corrections.
>
> Thanks,
> Kind Regards
> Kepeng
>
> 发件人: Ace  on behalf of Li Kepeng <
> kepeng@alibaba-inc.com>
> 日期: Wednesday, 4 October 2017 at 11:06 PM
> 至: ace 
> 抄送: Kathleen Moriarty , Hannes
> Tschofenig 
> 主题: [Ace] ACE virtual interim meeting on 18th Oct to discuss ACE roadmap
>
> Hello all,
>
> Please find the attached WebEx meeting information, and save it to your
> calendar.
>
> It can be also found below:
>
> Time: 18th Oct, GMT 13:00 ~ 14:00.
> Agenda item: ACE roadmap, the output from the Wiki activity.
> Link: https://trac.ietf.org/trac/ace/wiki/WikiStart
>
> JOIN WEBEX MEETING
> https://ietf.webex.com/ietf/j.php?MTID=m81fae81e933f9aaedf62bdadf1e6f441
> Meeting number (access code): 313 154 691
> Host key: 710338
> Meeting password: 22JqEbFK
>
> JOIN BY PHONE
> 1-877-668-4493 Call-in toll free number (US/Canada)
> 1-650-479-3208 Call-in toll number (US/Canada)
>
> Toll-free dialing restrictions:
> https://www.webex.com/pdf/tollfree_restrictions.pdf
>
> Can't join the meeting? Contact support here:
> https://ietf.webex.com/ietf/mc
>
> IMPORTANT NOTICE: Please note that this WebEx service allows audio and
> other information sent during the session to be recorded, which may be
> discoverable in a legal matter. You should inform all meeting attendees
> prior to recording if you intend to record the meeting.
>
> Kind Regards
> Kepeng & Hannes
>
> ___ Ace mailing list
> Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
>
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Minutes of ACE virtual interim meeting on 18th Oct about ACE roadmap

[Kepeng Li]

Hello all,

Please find the initial minutes from the link below:
https://datatracker.ietf.org/meeting/interim-2017-ace-02/materials/minutes-i
nterim-2017-ace-02-201710181300/

Please take a look and let me know if you have any corrections.

Thanks,
Kind Regards
Kepeng

发件人:  Ace  on behalf of Li Kepeng

日期:  Wednesday, 4 October 2017 at 11:06 PM
至:  ace 
抄送:  Kathleen Moriarty , Hannes
Tschofenig 
主题:  [Ace] ACE virtual interim meeting on 18th Oct to discuss ACE roadmap

Hello all,

Please find the attached WebEx meeting information, and save it to your
calendar.

It can be also found below:

Time: 18th Oct, GMT 13:00 ~ 14:00.
Agenda item: ACE roadmap, the output from the Wiki activity.
Link: https://trac.ietf.org/trac/ace/wiki/WikiStart
 
JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=m81fae81e933f9aaedf62bdadf1e6f441
Meeting number (access code): 313 154 691
Host key: 710338
Meeting password: 22JqEbFK

JOIN BY PHONE
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)

Toll-free dialing restrictions:
https://www.webex.com/pdf/tollfree_restrictions.pdf

Can't join the meeting? Contact support here:
https://ietf.webex.com/ietf/mc

IMPORTANT NOTICE: Please note that this WebEx service allows audio and other
information sent during the session to be recorded, which may be
discoverable in a legal matter. You should inform all meeting attendees
prior to recording if you intend to record the meeting.

Kind Regards
Kepeng & Hannes

___ Ace mailing list
Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace