Hello Benjamin:
Again and again, many thanks, it's really a pleasure to work on your reviews.
My plan is a single publication for all 3 emails.
I'm merging the 2 mails on the same thread and removing all the items for which
we reached an agreement, I hope that helps.
Let's see
> I guess
Dear all :
As you may know, draft-ietf-roll-unaware-leaves is blocking the whole cluster
C130 https://www.rfc-editor.org/cluster_info.php?cid=C310 and we want to ship
it now (WG milestone: Mar 2020 - Initial submission). The issue we have with it
is the fact that we allow encapsulate the ARO
to know the
difference
Pascal
From: Rahul Jadhav
Sent: mardi 10 mars 2020 15:58
To: Pascal Thubert (pthubert) ; Routing Over Low power and
Lossy networks
Cc: 6lo@ietf.org
Subject: Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage
Please find my comment [RJ] inline
True, we could.
Note that we might understand the "A" bit differently. For me the flag means
that the definition of the value is inherited from a 6lo spec, it does not mean
that in runtime the status was imported from a 6lo message.
Now if the node moves to a different root that is attached to
Hello Rahul
Sorry I was deep into the IESG review of other draft in C310.
Let’s see below
From: Roll On Behalf Of Rahul Jadhav
Sent: mardi 25 février 2020 06:03
To: Routing Over Low power and Lossy networks
Subject: Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage
I would like to
Hello Mirja:
Again many thanks for your very deep review.
I published -14 to propose some changes that address your DISCUSS comments as
well as Benjamin's
Please see
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14 .
Then I published
Hello Again Benjamin,
Continuing with the COMMENT piece of your really appreciated deep review below:
And as usual please find the diffs, and since this impacts both drafts we get:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-14
Hello Magnus:
Many thanks for your review!
Let's see below:
> --
> COMMENT:
> --
>
> I am uncertain if there is security risk that is poorly noted. I don't
Hello Mirja
A great many thanks for your really deep review, this is both really
appreciated and incredibly useful.
If that's OK with you let's make a round to clear the DISCUSSes separately like
I did for Benjamin's review.
Also considering the breadth of the discuss alone, I'd rather
Hello Eric:
Many thanks for your review!
Please find the proposed changes discussed below in
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14 that I
just published
Let's see below, and please let me know if the proposed changes work:
>
>
>
Hello Warren
Many thanks for your review!
Please find the proposed changes discussed below in
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14
Let's see below:
> --
> DISCUSS:
>
Hello again Benjamin
You really made those drafts I'm editing a lot better by your keen reviews and
this is another incredible one. Many thanks!!!
Let's go with the Discuss to start with?
> --
> DISCUSS:
>
Then we're cool, since Murray's comment collided with one from Ben that I
addressed in -13.
Many thanks to you and Murray!
Pascal
> -Original Message-
> From: Barry Leiba
> Sent: jeudi 5 mars 2020 18:29
> To: Pascal Thubert (pthubert)
> Cc: The IESG ; draft-ietf-6l
Hello Eric:
Many thanks for your review and time : )
You and Ben has similar concerns and I published 13 to try to address both.
I compiled the proposed changes in an early publication
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-13
Let's see below for the details:
>
Dear Benjamin
Many thanks for your review this time again!
As usual I compiled the proposed changes in an early publication
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-13
Let's see below for the other COMMENTs:
>
>
Hello Barry
It seems that this is the review you made on version 10. I scanned and could
not make a difference. I attached the emails for reference.
I believe that the issues are solved for the most part in
https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-11.txt
Could it be
Hello Eric and Ben:
> > == COMMENTS ==
> >
> > Is there a reason why this document uses "Link-Layer address" while
> > the companion, draft-ietf-6lo-fragment-recovery, uses "MAC address" ?
> > This is cosmetic of course but if the concept is the same, using the
> > same wording could only improve
Dear Benjamin
Many thanks for your review this time again!
I answered the track question separately (with you and Mirja), this is a
conscious discussion that was debated with Suresh in Singapore, we decided for
STD track and made the changes accordingly.
Let's address the DISCUSS first, more
hnique.
Also please find below the message that triggered the change:
"
All the best
Pascal
-Original Message-
From: Carles Gomez Montenegro
Sent: mardi 26 novembre 2019 18:41
To: Pascal Thubert (pthubert)
Cc: 6lo-cha...@ietf.org
Subject: Re: minimal fragments
Dear Pascal
Dear Mirja (and Ben),
Many thanks for reviewing this document!
> --
> COMMENT:
> --
>
> I agree with one of Ben's comments in that I'm not certain about the
Dear Roman and Benjamin
Many thanks for your reviews!
I took the liberty to merge your comments on section 11 in a single thread,
since they have commonalities.
Also, I'll try to answer the questions with my own words as they come, and then
propose a global change to section 11 at the end of
Many thanks Barry!
The next phase is to help us generalize the proactive ND to classical networks
(6MAN). Are you with us?
Take care,
Pascal
> -Original Message-
> From: Barry Leiba via Datatracker
> Sent: mardi 18 février 2020 21:25
> To: The IESG
> Cc:
Hello Benjamin
Again and again, many thanks for your arch-fantastic reviews!
Continuing:
>
> --
> COMMENT:
> --
>
> In Section 3 we talk about the Binding
Hello Benjamin:
> Sorry to make you interrupt your holiday!
Had to go back to hard unwork. But back now : )
> > >
> > > --
> > > DISCUSS:
> > >
> > > --
>
Hello Benjamin
Again many thanks for your arch-fantastic reviews!
Let me handle the DISCUSS first and then I'll come back to you asap for the
rest.
I published 17 since the proposed change had me take a global look at the
proposed change vs. original ND.
Please see
Many thanks for your review, Roman!
Let's see below
>
>
> --
> COMMENT:
> --
>
> Thank you for this easy to read document.
>
> ** Section 5.1. Per “There
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
Many thanks for reviewing this doc Roman!
We debated with Barry and concluded that the references you mentioned should
stay non normative. One is abandoned and the other would be a downref.
Is it ok to stick with this?
Pascal
> Le 17 févr. 2020 à 00:18, Roman Danyliw via Datatracker a
>
Hello Colin
Many thanks for your review!
I published -12 to make it easier for you to review the changes I'm suggesting
based on your review,
The delta is visible here:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-12
Let's see below for the discussion:
> The document
Looks good, Schwetha.
From: 6lo <6lo-boun...@ietf.org> On Behalf Of Shwetha Bhandari (shwethab)
Sent: samedi 8 février 2020 01:09
To: 6lo@ietf.org
Cc: Carles Gomez Montenegro ; Suresh Krishnan
Subject: [6lo] Feedback on proposed changes to draft-ietf-6lo-deadline-time-05
Hello All,
This is to
(pthubert)
Cc: tsv-...@ietf.org; last-c...@ietf.org;
draft-ietf-6lo-backbone-router@ietf.org; 6lo@ietf.org
Subject: Re: Tsvart last call review of draft-ietf-6lo-backbone-router-13
Let's try this again.
On Fri, Feb 7, 2020 at 5:48 AM Pascal Thubert (pthubert)
mailto:pthub...@cisco.com>>
Samsung tablet.
Original message
From: "Pascal Thubert (pthubert)"
Date: 07/02/2020 13:36 (GMT+00:00)
To: Elwyn Davies , gen-...@ietf.org
Cc: last-c...@ietf.org, draft-ietf-6lo-backbone-router@ietf.org,
6lo@ietf.org
Subject: RE: Genart last call review of draft-ietf-6l
Hello Barry:
>
> >>This specification uses the following terms:
> >>
> >> I would say it “defines” these terms, no?
> >
> > Not really, they appear in RFC 4944, but ok
>
> OK, no... I hadn't realized (and didn't check) that they were defined in 4944.
> Sorry; leave as is.
Will roll back
Hello Barry:
Many thanks for your review!
I published a new version with the outcome of this first pass, so you can
easily check the changes in
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-11
Please find the discussion below:
>
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 Kyle
Many thanks for your review!
Let's see below:
> I see no specifically transport-related issues in this draft, but I note a
> few nits
> as well as unaddressed issues raised by RFC 4903.
>
> Potential issues: The draft addresses ND, DAD, and to some extent link-scoped
> multicast
Oh it’s the JWK encoding, right?
Would we speed things up if we just imported the IANA section from the LWIG
draft?
Regards,
Pascal
> Le 6 févr. 2020 à 19:09, Pascal Thubert (pthubert) a
> écrit :
>
> Hello Benjamin
>
>
>> "backward compatibility with"
n!
Pascal
> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Benjamin Kaduk
> Sent: jeudi 6 février 2020 18:31
> To: Pascal Thubert (pthubert)
> Cc: draft-ietf-6lo-ap...@ietf.org; 6lo-cha...@ietf.org; The IESG
> ; Shwetha Bhandari (shwethab) ;
> 6lo@i
Hello Benjamin
> "backward compatibility with" is easy to misparse, so maybe add a comma, or
> go with "backward compatibility but adds the capability"?
> > We're getting there. I snipped the places were we appear to have converged.
> >
> > Please let me know if the DISCUSS is now solved (we
Hello Dominique:
Many thanks for your great review! Considering its width and breadth, I
published -14 for that review alone.
Diffs available here:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-backbone-router-14
Continuing from 3.4
> 3.4
> “Addresses in a LLN … must be
> > See also the discussion with IANA and Benjamin. The idea is that if someone
> wants to add a curve or a hash function, but following the method in this
> draft.
> Do we really need an RFC or is the IANA registry the reference? The idea is
> that
> the IESG should be able to determine that
Maybe like this?
Regards,
Pascal
> Le 6 févr. 2020 à 10:48, Pascal Thubert (pthubert) a
> écrit :
>
> Hello Benjamin
>
> We're getting there. I snipped the places were we appear to have converged.
>
> Please let me know if the DISCUSS is now solved (
:
> -Original Message-
> From: Benjamin Kaduk
> Sent: mercredi 5 février 2020 22:20
> To: Pascal Thubert (pthubert)
> Cc: The IESG ; draft-ietf-6lo-ap...@ietf.org; Shwetha
> Bhandari
> (shwethab) ; 6lo-cha...@ietf.org; 6lo@ietf.org
> Subject: Re: Benjamin Kaduk
Hello Roman:
Many thanks for your review!
I'm publishing -19 to cover the proposed changes, in association with some more
nits from the discussion with Benjamin
The diffs here may help you through your validation:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-19
For the
:
> -Original Message-
> From: Benjamin Kaduk
> Sent: mercredi 5 février 2020 22:20
> To: Pascal Thubert (pthubert)
> Cc: The IESG ; draft-ietf-6lo-ap...@ietf.org; Shwetha Bhandari
> (shwethab) ; 6lo-cha...@ietf.org; 6lo@ietf.org
> Subject: Re: Benjamin Kaduk's Discuss
Hello again Benjamin:
About your discuss below we published -18 that has text from Rene that removes
the uncertainty on compression.
Please have a look at https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18
and let us know if the diffs correct the issue properly.
Many thanks again
Hello Alissa
Many thanks for your review !
I committed the proposed changes as -18 so you can review them in the final
version, but we can certainly adapt and do more, see
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18 . Note that the
commit also adds text to answer a DISCUSS by
This was truncated when I received the echo, retrying...
> -Original Message-
> From: Pascal Thubert (pthubert)
> Sent: mardi 4 février 2020 15:14
> To: Benjamin Kaduk
> Cc: The IESG ; draft-ietf-6lo-ap...@ietf.org; Shwetha
> Bhandari (shwethab) ; 6lo-cha...@ietf.o
Dear Benjamin
Many thanks for your in depth review!
Considering the amount of changes I published 16 just to make a statement of
the current exchange.
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-16
Hopefully this should make you validation of the proposed changes easier.
Please
Dear all
During SEC-DIR review, Benjamin pointed out:
> I worry a little bit that we haven't fully specified the entire list of steps
> the 6LR
> takes to follow the cryptographic chain and validate that the 6LN holds the
> key
> in question and registers the address in question to the
Dear all
During SEC-DIR review, Benjamin pointed out:
>
> [just to check: JWK-encoding means that we have an injective map and aren't
> subject to some sort of extension attack? Not that such a thing would be easy
> to pull off, with a strict registry of Crypto-Types, of course]
Any idea
Hello Benjamin
> > CC'ing SEC-DIR: Please help: if there is a reference for that practice,
> > what it
> > takes to maintain a nonce, and why we have a nonce from both sides? Trying
> > to reinvent that text does not look like a good idea for this draft.
>
> It's pretty standard, so I'm not
Hello Sarah:
Many thanks for your review : )
> -Original Message-
> From: Sarah Banks via Datatracker
> Sent: vendredi 31 janvier 2020 17:40
> To: ops-...@ietf.org
> Cc: draft-ietf-6lo-minimal-fragment@ietf.org; last-c...@ietf.org;
> 6lo@ietf.org
> Subject: Opsdir last call review
lewind (IETF)
> Sent: vendredi 31 janvier 2020 16:49
> To: Pascal Thubert (pthubert)
> Cc: draft-ietf-6lo-ap...@ietf.org; 6lo-cha...@ietf.org; The IESG
> ; Shwetha Bhandari (shwethab) ;
> 6lo@ietf.org
> Subject: Re: [6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-ap-nd-14:
&
Hello Mirja:
Many thanks for your review : )
> --
> COMMENT:
> --
>
> A couple of small comments:
>
> 1) Sec 2.2: If actually all terms from all the RFC
vyncke)
> Sent: mercredi 29 janvier 2020 16:47
> To: Pascal Thubert (pthubert) ; The IESG
>
> Cc: draft-ietf-6lo-ap...@ietf.org; Shwetha Bhandari (shwethab)
> ; 6lo-cha...@ietf.org; 6lo@ietf.org; sec...@ietf.org
> Subject: Re: Éric Vyncke's Discuss on draft-ietf-6lo-ap-nd-13: (wi
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
Many thanks Joerg!
Please see below:
> Generally, the document is in good state and almost ready to publish. A few
> nits, one on protocol state management below:
>
> Nits:
>
> The text uses both "6lo fragments" and "6LoWPAN fragments".
Changed to 6LoWPAN fragments everywhere
>
> Section
All good then!
Again, many thanks.
Pascal
> -Original Message-
> From: MORTON, ALFRED C (AL)
> Sent: lundi 6 janvier 2020 14:45
> To: Pascal Thubert (pthubert) ; ops-...@ietf.org
> Cc: last-c...@ietf.org; draft-ietf-6lo-ap-nd@ietf.org; 6lo@ietf.org
> Subject: RE
Hello Al
Many thanks for your review!
Please see below:
> This is the OPS-DIR review of -12
> 1) "This specification introduces a new token called a cryptographic
>identifier (Crypto-ID) that is used to prove indirectly the ownership
>of an address that is being registered by means of
Hello Adam
Many thanks for your review
Please see below:
> 1. In the first exchange with a 6LR: "When a 6LR receives a NS(EARO)
> registration with a new Crypto-ID as a ROVR, it SHOULD challenge by
> responding with a NA(EARO) with a status of "Validation Requested"". Under
> what
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 Erik
Many thanks for your in-depth review!
Let's see below:
> Section 4.3 seems to silently assume that all fragments of a datagram go
> through the same intermediate hops. This should at a minimum be made
> explicit.
This is in fact inherited from the parent
-Layer address of the fragment, the
forwarding node MUST assign a new datagram_tag from its own namespace for the
next hop and rewrite the fragment header of each fragment with that
datagram_tag.
“
Works?
Pascal
From: Dave Thaler
Sent: jeudi 14 novembre 2019 03:33
To: Pascal Thubert (pthuber
Hello Dave
Le 13 nov. 2019 à 09:02, Dave Thaler a écrit :
Pascal wrote:
[…]
of the destination. Upon a first fragment, a node creates a state
and forwards the fragment.
I’d recommend “a node *attempts to* create state and forward the fragment”,
since either of those could potentially
Hello Dave
Continued below
Le 13 nov. 2019 à 04:28, Dave Thaler a écrit :
From: Pascal Thubert (pthubert)
Sent: Friday, November 8, 2019 5:25 AM
To: Dave Thaler
Cc: int-...@ietf.org; draft-ietf-6lo-minimal-fragment@ietf.org; 6lo@ietf.org
Subject: RE: Intdir last call review of draft
fragments.
I guess we need a better introduction on ff and a section before 3 that
discusses the concepts of FF that the LWIG implements.
I need to work on that before coming back to you.
Regards,
Pascal
Le 8 nov. 2019 à 08:50, Pascal Thubert (pthubert) a écrit :
Hello Dave
More below
Pascal
Hello Dave
Please see in-line
Le 7 nov. 2019 à 22:22, Dave Thaler a écrit :
Responses inline below.
Pascal Thubert (pthubert) wrote:
> The title implies the document specifies a forwarding mechanism, but
> it does not, it merely provides discussion of two mechanisms in other
>
Hello Dave
Many thanks for being so reactive
Please see below
> -Original Message-
> From: Dave Thaler via Datatracker
> Sent: jeudi 7 novembre 2019 00:10
> To: int-...@ietf.org
> Cc: draft-ietf-6lo-minimal-fragment@ietf.org; last-c...@ietf.org;
> 6lo@ietf.org
> Subject: Intdir
Fantastic Martine.
Please note that you do not need to send the message in error back in full.
Only up to the offset where the error is detected. Since the control is in the
first fragment there is no point reassembling in the middle of the network. The
hard question that we discuss in the
did you already
loose track of the compressed packet? I thought you’d keep it to forward it
because most times there’s no need to change the iphc piece.
Regards,
Pascal
Le 6 nov. 2019 à 18:42, Martine Lenders a écrit :
Hi Pascal,
Am Mi., 6. Nov. 2019 um 18:16 Uhr schrieb Pascal Thubert
and the receiver should abort the flow.
That “too much” decision is left to implementation.
Regards,
Pascal
Le 23 oct. 2019 à 14:29, Martine Lenders a écrit :
Hi Pascal,
Am Mo., 21. Okt. 2019 um 18:14 Uhr schrieb Pascal Thubert (pthubert)
mailto:pthub...@cisco.com>>:
Hello Again
I reread th
Cool : )
I published 07, please see the diffs.
All the best;
Pascal
From: 6lo <6lo-boun...@ietf.org> On Behalf Of Martine Lenders
Sent: mercredi 23 octobre 2019 14:46
To: Pascal Thubert (pthubert)
Cc: 6lo@ietf.org
Subject: Re: [6lo] draft-ietf-6lo-fragment-recovery: Send a FULL bitma
Sorry I missed that Martine!
The ALL 1s was already sent when the last fragment was received. This text
happens later.
It is supposed to have been processed along the way back. The receiving end
node maintains a state for a “short” time after the message processing to
absorb packets that may
Dear authors:
Please find some comments below.
<
some IEEE 802.15.4 link
"
Please reword to "IEEE Std 802.15.4" and include a reference. You may use
IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access
Control (MAC) and Physical Layer (PHY)
Many thanks Tim!
Regards,
Pascal
Le 1 oct. 2019 à 17:19, Timothy Winters a écrit :
Hi Pascal,
Sorry for the delay in responding. I think the text you added was exactly what
I was thinking and resolves all my comments.
~Tim
On Fri, Sep 20, 2019 at 9:41 AM Pascal Thubert (pthubert
septembre 2019 02:42
To: Pascal Thubert (pthubert) ; Timothy Winters
; Eric Levy- Abegnoli (elevyabe) ;
'Charles E. Perkins (charles.perk...@earthlink.net)' ;
6lo-cha...@ietf.org
Cc: '6lo@ietf.org' <6lo@ietf.org>
Subject: Re: [6lo] I-D Action: draft-ietf-6lo-backbone-router-13.txt
Many thanks
Dear all:
This addresses the review by Tim * Many thanks Tim! *
Mostly: I clarified that the ND proxy does the MLD work by referring to section
7.2.1. of [RFC4861] where it is all described.
Dear chairs: I guess we can now go for publication. Hoping 13 is not a bad
number ; )
Take care
Hello Tim:
(adding int-ads)
> I've reviewed this document and overall I think it's a good shape. I have a
> couple of nits and comments that I've included below. (Note I reviewed -12).
> - I have a question about Backbone side and multicast snooping. If there
> is a switch running
age-
> From: internet-dra...@ietf.org
> Sent: lundi 29 juillet 2019 12:20
> To: Pascal Thubert (pthubert) ; Eric Levy- Abegnoli
> (elevyabe)
> Subject: New Version Notification for draft-thubert-6man-unicast-lookup-
> 00.txt
>
>
> A new version of I-D, draft-thubert-6man-un
Hello Brian
You may like RFC 6282, RFC 8138 or SCHC from LPWAN
Regards,
Pascal
> Le 21 juil. 2019 à 16:44, Brian E Carpenter a
> écrit :
>
> Hi,
>
> On Wednesday July 24 morning, from 08:30 to 09:45, in room Notre Dame,
> we'll introduce and discuss two new drafts:
>
> Asymmetric IPv6,
Hello Carles
Manu thanks for you review!
Please see below
>
> - "LLN" is used in the title and in the abstract, but the actual body of the
> document uses the term "6LoWPAN" (or "6Lo"), which in fact is more specific.
> Should "LLN" be replaced with "6LoWPAN" (or "6Lo")? (I tend to think
Hello Carles
No, I'm not aware of any IPR that applies to this any version of
draft-ietf-6lo-minimal-fragment-02
All the best,
Pascal
> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Carles Gomez Montenegro
> Sent: mercredi 17 juillet 2019 08:33
> To:
Hello Carsten:
The 6LR, or 6LBR, are logical functions. A L3-switch is a box that has its
differences with a router.
All the best,
Pascal
> -Original Message-
> From: Carsten Bormann
> Sent: lundi 8 juillet 2019 14:51
> To: Pascal Thubert (pthubert)
> Cc: Mark
the best,
Pascal
From: Mark Smith
Sent: jeudi 4 juillet 2019 14:39
To: Pascal Thubert (pthubert)
Cc: Carsten Bormann ; Michael Richardson ;
V6 Ops List ; 6man <6...@ietf.org>; 6lo@ietf.org
Subject: Re: [6lo] Advocating a generalization of RFC8505 to non-6lo LANs
On Thu., 4 Jul. 2019, 21:38
--Original Message-
> From: Carsten Bormann
> Sent: jeudi 4 juillet 2019 13:22
> To: Pascal Thubert (pthubert)
> Cc: Michael Richardson ; 6lo@ietf.org; V6 Ops List
> ; 6man <6...@ietf.org>
> Subject: Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo LANs
>
>
n E Carpenter a
> écrit :
>
> On 03-Jul-19 20:13, Pascal Thubert (pthubert) wrote:
>
> ...
>> I'm baffled that the reactive ND is still the official technique for IPv6
>> lookup at 6MAN.
>
> How can it be otherwise when a node can give itself a new address at
Hello Michael
Please see below
>
> Pascal Thubert (pthubert) wrote:
>> 6LoWPAN ND is immune to the remote DOS attacks on the ND cache, the
>> ones coming from the outside of the subnet, i.e., from a place that is
>> out of touch and virtually nowhere.
>
>&g
Hello Jen
The routers that Michael is talking about are real routers, deployed in large
volumes in the field, e.g., in Smartgrid networks.
They are not running ND as RFC 4861/4862 but as RFC 6775/8505, and then operate
RPL routing within the ML subnet.
It would be great to have a section that
Hello Shwetha:
I’d like to solicit presentation opportunities in 6Lo at IETF 105.
Presenter name: Pascal Thubert
Presenter in-room/Remote : in-room
Draft name Time needed
Purpose of the
Hello Carles:
02 was published with the comments listed below addressed.
All the best,
Pascal
> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Carles Gomez Montenegro
> Sent: mercredi 15 mai 2019 09:35
> To: 6lo@ietf.org
> Subject: Re: [6lo] WG Last Call:
Hello Dominique:
Many thanks for your review!
Please see below:
> Section 1, Overview:
> "Each fragment can be uniquely identified by the source and destination link-
> layer addresses of the frame that carries it, and the datagram_tag."
> It seems to me that "datagram_offset" should also be
Hello Yatch;
In the security section is changed the text to:
"
An attacker can perform a Denial-of-Service (DoS) attack on a node implementing
VRB by generating a large number of bogus "fragment 1" fragments without
sending subsequent fragments.
This causes the VRB table to fill up. Note that
Hello Georgios
Many thanks for your review, please see below:
>In Figure 1, a packet forwarded by node A to node B is cut into nine
>fragments, numbered 1 to 9. Each fragment is represented by the '#'
>symbol. Node A has sent fragments 1, 2, 3, 5, 6 to node B. Node B
>has
Hello Yatch
This dates a bit but I think none of us answered so let me take a look:
>
> (1) https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-01#section-2.2
> > Assuming 1 kB reassembly
> >buffers, typical nodes only have enough memory
Many Thanks Carles!
Please see below
> -- Review --
>
> - Page 2: "in all cases" can be removed
>
done
> - Page 2: "a firmware upgrades" -> perhaps remove "a" (or apply other
>changes)
>
done
Great!
Point is you need to provide the format of the uncompressed form so the root
can uncompress and forward.
All the best,
Pascal
From: 6lo <6lo-boun...@ietf.org> On Behalf Of Lijo Thomas
Sent: jeudi 23 mai 2019 15:16
To: Pascal Thubert (pthubert)
Cc: draft-ietf-6lo-deadline-t...@ie
Baryun
Sent: jeudi 23 mai 2019 13:31
To: Pascal Thubert (pthubert)
Cc: draft-ietf-6lo-deadline-t...@ietf.org; 6lo@ietf.org
Subject: Re: [6lo] uncompressed form
On Thu, May 23, 2019 at 7:54 AM Pascal Thubert (pthubert)
mailto:pthub...@cisco.com>> wrote:
Dear all:
I was rereading de
Dear all:
I was rereading deadline and realized that the draft does not provide an
umcompressed form. What of the packet flies beyond the RPL domain? I think the
information should be useful there too.
Also we always claimed that RFC8138 is an encoding and that we can always turn
a packet to
Hello Michael
> Pascal Thubert (pthubert) wrote:
> > During the review by Laurent, a question came up on whether the receiver
> > could asynchronously send RFRAG Acks e.g., to transport an ECN
> > indication.
>
> So would the ACKs be out of order, ackn
101 - 200 of 304 matches
Mail list logo
