Thanks! This version addresses all my comments. Clearing my DISCUSS now.
/a
On 12/5/19 8:43 AM, Mališa Vučinić wrote:
Dear Adam,
Please note that we have just published a new version of the minimal-security
document addressing, we believe, all the issues raised in your review. Could
you
Hi Malisa.
Thanks to your explanation, I get the point.
how could we ensure that the “acceptable” amount of unauthenticated traffic
that actually gets forwarded does not trigger cell allocation?
It'd be fine to trigger cell allocations by *acceptable* amount of
unauthenticated traffic if
The “join rate” parameter takes care that any single JP at the edge of the
network does not inject too much traffic. But this traffic is forwarded along
multiple hops towards the root, and therefore gets aggregated with (join)
traffic from other JPs in the network. The purpose of the traffic
Hello Tengfei
Architecturally speaking, MSF right now is used to allocate cells in the L3
bundle with a parent.
“
Layer-2 vs. Layer-3 bundle:
Bundles are associated for either Layer-2 (switching) or Layer-3 (routing)
forwarding operations. A pair of Layer-3 bundles (one for each direction)
Hi,
On 12/5/2019 5:17 PM, Tengfei Chang wrote:
Does anyone know other way to make the SF not adapt to unsecured traffic
without knowing upper layer field?
I have no idea...
Why can't the "join rate" avoid such undesired cell allocations? If the
join rate is properly configured, incoming
Hi All,
For securing the MSF, (comments from minimal security, thanks for the
input!)
In the next version of MSF, we need to add sentence saying MSF only adapts
the traffic which is secured, practically by checking the DSCP value set
with zero or no, which is in IPv6 header.
In other hands, MSF
Mališa Vučinić wrote:
> This text should end up in the next version of the MSF draft, as it is
> the scheduling function that triggers 6P to add/delete cells. We added
> some text on it already for the security considerations, what remains
> to be done is to align the MSF
This text should end up in the next version of the MSF draft, as it is the
scheduling function that triggers 6P to add/delete cells. We added some text on
it already for the security considerations, what remains to be done is to align
the MSF algorithm with the requirement of not adapting to
Ah, great, missed that edit. That makes sense! Thanks!
> On 5. Dec 2019, at 15:37, Mališa Vučinić wrote:
>
> Dear Mirja,
>
> Thank you for the prompt reaction! The Parameter Update Response message has
> been removed in the latest version as it was indeed redundant given that the
> Parameter
Mirja Kuehlewind wrote:
>>> I would think it
>>> either sets it to AF43 or it does nothing about it because DSCP is not
>>> really used in that network.
>>
>> In 6tisch networks, different DSCP points can be used to get different
>> behaviours, see UHM. Let me get
Mirja Kuehlewind wrote:
> Sorry for my late reply (but I guess you could have just went ahead and
> push a new version anyway…). Please see below.
My edits went into a new version which Malisa did push out.
>>
>>
>>> Further on there seems to be an implicit requirement that
Dear Adam,
Please note that we have just published a new version of the minimal-security
document addressing, we believe, all the issues raised in your review. Could
you take a look?
Thanks.
Mališa
> On 2 Nov 2019, at 22:40, Michael Richardson wrote:
>
>
> Adam Roach wrote:
>>> How/where
Dear Ben,
We have just published a new version of the minimal-security document
addressing, we believe, all your remarks. Would you mind checking it out,
please?
Mališa
> On 19 Nov 2019, at 09:06, Michael Richardson wrote:
>
> On 2019-10-31 2:24 a.m., Benjamin Kaduk via Datatracker wrote:
Dear Mirja,
Thank you for the prompt reaction! The Parameter Update Response message has
been removed in the latest version as it was indeed redundant given that the
Parameter Update Message is a CoAP CON. Thank you for that remark!
Regards,
Mališa
> On 5 Dec 2019, at 15:30, Mirja Kühlewind
Mirja Kühlewind has entered the following ballot position for
draft-ietf-6tisch-minimal-security-14: No Objection
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.)
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG
of the IETF.
Title : Constrained Join Protocol (CoJP) for 6TiSCH
Authors : Malisa Vucinic
Regards,
Pascal
> Le 5 déc. 2019 à 04:06, Mirja Kuehlewind a écrit :
>
> Hi Michael,
>
> Sorry for my late reply (but I guess you could have just went ahead and push
> a new version anyway…). Please see below.
>
>>> On 1. Nov 2019, at 22:15, Michael Richardson wrote:
>>>
>>>
>>>
17 matches
Mail list logo
