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
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
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
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
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
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
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.
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.
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)
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
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.
>
>
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)
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
Ø 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
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
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
16 matches
Mail list logo