From nobody Thu Apr 15 23:48:22 2021 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69443A18E5; Thu, 15 Apr 2021 23:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIX9f-Ak2dsn; Thu, 15 Apr 2021 23:48:07 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0222.hostedemail.com [216.40.44.222]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587223A18E3; Thu, 15 Apr 2021 23:48:06 -0700 (PDT) Received: from omf08.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 6AAF5180721B1; Fri, 16 Apr 2021 06:48:05 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: stokcons@bbhmail.nl) by omf08.hostedemail.com (Postfix) with ESMTPA id 000411A29F6; Fri, 16 Apr 2021 06:48:04 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 16 Apr 2021 08:48:04 +0200 From: Peter van der Stok To: Alvaro Retana Cc: Peter Van der Stok , last-call@ietf.org, roll@ietf.org, draft-ietf-roll-aodv-rpl.all@ietf.org, iot-directorate@ietf.org Reply-To: consultancy@vanderstok.org In-Reply-To: References: <161848055597.18527.2186863564067252978@ietfa.amsl.com> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <2899fa5646cea7c4de6b34ee3f9436dd@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy Content-Type: multipart/alternative; boundary="=_0bb9c5a8d41ec8a255cb093248a20a7c" X-Stat-Signature: mwxy4fg83td6ccrt6jbnbxufcstyhszq X-Rspamd-Server: rspamout05 X-Rspamd-Queue-Id: 000411A29F6 X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Session-ID: U2FsdGVkX19uXRGIPzsBadxQkgV41og9ewJreYXw4Z8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h=mime-version:date:from:to:cc:subject:reply-to:in-reply-to:references:message-id:content-type; s=key; bh=Qu9ssatUenWdKXWuRAcBEuoHi+Eu5nh6pnQ13nf3nVY=; b=ghnItR9frfBkmP1+mvBlWLqeo6l8TpAJVhKlRbRjxUdRihw3BN8xIqVAvdOpM4Yutsn+s/LRwKRKgWzo72i81AP0E8l9l3mgkLhOdW0vcCasBvVqb0+t/wy/6Fb3aG8Wpj7/gwhi0K8QP2urAwNfLTf+/07q581ya2LeNbs3nXU= X-HE-Tag: 1618555684-566776 Archived-At: Subject: Re: [Roll] [Iot-directorate] Iotdir telechat review of draft-ietf-roll-aodv-rpl-10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 06:48:13 -0000 --=_0bb9c5a8d41ec8a255cb093248a20a7c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi Alvaro, Yes, I'm fine; I hope you are also in good health. Since a year I am not following the undercurrents in the ROLL WG. I am unable to tell you what they think about replacing rfc6997 currently. When I was chair, I was more concerned with the continuation of the document than eventual consequences for rfc6697. However, I think that this is the right moment to reconsider the replacement question. Having two aodv documents may be confusing for ROLL adopters. BTW, I encouraged the creation and development of rfc6697 for the reasons mentioned in the document. When replacement is considered, this motivation is needed in the new aodv draft. Hope this explains a bit better my review remarks. Greetings, Peter Alvaro Retana schreef op 2021-04-15 20:57: > On April 15, 2021 at 5:55:57 AM, Peter Van der Stok wrote: > > Peter: > > Hi! I hope you're doing well! > >> In general, the document is well written. By looking regularly into >> RFC 6550, >> I am rather sure that I could implement the protocol. The question >> remains >> how this draft relates to RFC 6997. When the WG decides that this >> draft >> replaces RFC 6997, then it would be good to copy some text from 6997 >> to this >> draft, because RFC 6997 is more explicit about the use of RPL >> parameters as >> specified in RFC 6550 and presents more explicit motivation. > > As you know, the roll WG considered the question of replacing rfc6997 > as part of my AD review [1 [1]]. At the time there didn't seem to be > any > strong interest in doing so. Do you think that has changed? > > Thanks for the review! > > Alvaro. > > [1] > https://mailarchive.ietf.org/arch/msg/roll/r3MP2MKrWqTMVmAQjKJDfU6iu-A/ Links: ------ [1] https://mailarchive.ietf.org/arch/msg/roll/r3MP2MKrWqTMVmAQjKJDfU6iu-A/ --=_0bb9c5a8d41ec8a255cb093248a20a7c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Alvaro,

Yes, I'm fine; I hope you are also in good health.
Since a year I am not following the undercurrents in the ROLL WG= =2E I am unable to tell you what they think about replacing rfc6997 current= ly.
When I was chair, I was more concerned with the continuation of th= e document than eventual consequences for rfc6697.

However, I th= ink that this is the right moment to reconsider the replacement question.Having two aodv documents may be confusing for ROLL adopters.


BTW, I encouraged the creation and development of rfc6697 for the r= easons mentioned in the document.
When replacement is considered, this= motivation is needed in the new aodv draft.

Hope this explains = a bit better my review remarks.

Greetings,

Peter

Alvaro Retana schreef op 2021-04-15 20:57:

= On April 15, 2021 at 5:55:57 AM, Peter Van der Stok wrote:


Peter:

Hi!  I hope you're doing well!


In general, the document is well written. By looking r= egularly into RFC 6550,
I am rather sure that I could implement the pr= otocol. The question remains
how this draft relates to RFC 6997. When = the WG decides that this draft
replaces RFC 6997, then it would be goo= d to copy some text from 6997 to this
draft, because RFC 6997 is more = explicit about the use of RPL parameters as
specified in RFC 6550 and = presents more explicit motivation.

As you know, the roll WG considered the question of replacing rfc6997=
as part of my AD review [1].  At the time there didn't seem to be any
stron= g interest in doing so.  Do you think that has changed?

Tha= nks for the review!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/rol= l/r3MP2MKrWqTMVmAQjKJDfU6iu-A/
--=_0bb9c5a8d41ec8a255cb093248a20a7c--