Many Thanks Elwynd:
>
> s6.3, next to last para. s8 and s 12.2: In view of the statement in s6.3:
> The RPL Root MUST set the 'E' flag to 1 for all rejection and unknown status
> codes. The status codes in the 1-10 range [RFC8505] are all considered
> rejections. I think that IANA should be
Hello Elwyn;
Many thanks for your review! It was very thorough and helpful.
I placed the first round of corrections here:
https://github.com/roll-wg/roll-unaware-leaves/commit/523bd3c7b59a8eca822482a8a26b4cbd6b87c190
There are a few items left open, in particular the RPL-Unaware Leaves vs.
: Pascal Thubert (pthubert)
Sent: mercredi 19 août 2020 10:20
To: Meral Shirazipour ; gen-art@ietf.org;
draft-ietf-roll-turnon-rfc8138@ietf.org
Subject: RE: Gen-ART Last Call review of draft-ietf-roll-turnon-rfc8138-09
Hello Meral
Many thanks for your review!
For now there is the MoP value
Hello Meral
Many thanks for your review!
For now there is the MoP value for 7 is not defined. When it is, it will signal
an extension. So it means future. This draft covers the transition with legacy
nodes. A MoP of 7 when defined will not be usable with legacy nodes, there will
be a flag day
Many thanks for your review Peter!
I applied all your typo fix suggestions that are not discussed below.
> Page 14, 3rd paragraph, 1st sentence: change “a same” to one of “any”, “any
> single”, or something similar. These suggestions are based on the assumption
> that fragments from disparate
Samsung tablet.
Original message
From: "Pascal Thubert (pthubert)"
Date: 07/02/2020 13:36 (GMT+00:00)
To: Elwyn Davies , gen-art@ietf.org
Cc: last-c...@ietf.org, draft-ietf-6lo-backbone-router@ietf.org,
6...@ietf.org
Subject: RE: Genart last call review of draf
Hello Elwyn:
Many thanks for your review!
Let's see below:
> General: s/i.e. /i.e., / (4 places), s/e.g. /e.g.,/ (2 places)
Done
>
> Abbreviations: The definition of abbreviations in this document is
> inconistent.
> There is a list of abbreviations but it is not complete; many
Hello Peter:
Many thanks for your review!
I published 09 so the next reviewers will not have to suffer from my nits, and
we can progress from there if my proposals are not satisfactory.
The delta is available here, please see below for more:
Hello Francesca:
Many thanks for your review : )
> Summary: This draft is basically ready for publication. However, I noticed the
> normative reference to an informative document, draft-ietf-lwig-6lowpan-
> virtual-reassembly (ref. 'LWIG-VRB'), which is problematic, since this draft
> is
> on
Hello Vijay
Good point. I suggest to add text in the intro that defines the acronym. The
proposed modified sentence is;
"
In particular, 6LoWPAN ND introduces a unicast host Address Registration
mechanism
that reduces the use of multicast compared to the Duplicate Address Detection
(DAD)
Hello Francis
Many thanks for your review. It clearly indicates a thorough reading, this is
much appreciated.
I fixed all the nits in -24. Please see nbelow:
> - 1 page 3: the IT abbrev is not introduced
>
> - 2.1 page 5 (bundle), page 9 (slotOffset), 4.61 page 38 (2.): i.e. -> i.e.,
>
> -
Many thanks, Matthew.
This will be fixed in the next update of the draft, already fixed in bitbucket.
Take care,
Pascal
> -Original Message-
> From: Matthew Miller
> Sent: jeudi 25 octobre 2018 20:02
> To: gen-art@ietf.org
> Cc: det...@ietf.org; i...@ietf.org;
Hello János
I's change reasonably to strictly.
The whole point of bounded in detnet is that it is not a vague boundary but a
hard, guaranteed one, regardless of any other activity in the network.
All the best,
Pascal
> -Original Message-
> From: János Farkas
> Sent: vendredi 19
Dear Francis:
Under Jari 's heavy pressure - ; ) - , I applied your recommendations and
published.
URL:
https://www.ietf.org/internet-drafts/draft-ietf-roll-routing-dispatch-05.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/
Htmlized:
/watch/7011357/
-Original Message-
From: david.bl...@emc.com [mailto:david.bl...@emc.com]
Sent: Thursday, February 24, 2011 12:46 AM
To: Pascal Thubert (pthubert); hous...@vigilsec.com; i...@ietf.org;
lars.egg...@nokia.com
Cc: 6lowpan-cha...@tools.ietf.org; draft-ietf-6lowpan
Hi Lars,
On 2011-1-18, at 20:41, Pascal Thubert (pthubert) wrote:
I'm still unhappy since the text allows a middle point to recomputed
the
checksum which then might be delivered erroneously to the wrong IP or
port.
This was done to ensure that a packet that flows on the Internet
would
Hi Lars and David:
After the first round, the text would now look like this:
4.3.2. Compressing UDP checksum
The UDP checksum operation is mandatory with IPv6 [RFC2460] for all
packets. For that reason [RFC4944] disallows the compression of the
UDP checksum.
With this
[mailto:david.bl...@emc.com]
Sent: Monday, January 17, 2011 9:33 PM
To: j...@archrock.com; Pascal Thubert (pthubert); gen-art@ietf.org
Cc: david.bl...@emc.com; c...@tzi.org; geoff.i...@mulligan.com;
rdroms.i...@gmail.com; 6low...@ietf.org
Subject: Gen-ART review of draft-ietf-6lowpan-hc-13.txt
I
18 matches
Mail list logo
