Re: [6lo] Warren Kumari's No Objection on draft-ietf-6lo-rfc6775-update-16: (with COMMENT)

Warren Kumari <warren@kumari.net> Tue, 03 April 2018 16:34 UTC

Return-Path: <warren@kumari.net>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D453012EA64 for <6lo@ietfa.amsl.com>; Tue, 3 Apr 2018 09:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 TxQu4FXtfReR for <6lo@ietfa.amsl.com>; Tue, 3 Apr 2018 09:34:44 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF8F12D7E6 for <6lo@ietf.org>; Tue, 3 Apr 2018 09:34:40 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id p9so34748577wmc.3 for <6lo@ietf.org>; Tue, 03 Apr 2018 09:34:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/4VxRgdwmxfsSJ8zu8fWyIG2uKO6MoSUixGpFrOpVFQ=; b=TSLZ3pev2gsf70xoWpBWnpraZA0W2j8JIdy1zlpCVn7ibTcIb/cFoiH5Utfl2ZVRJ+ QZDl/l3LY3zJkaCgS0VrzqaKfDIWLxWRDTXFpDSGV0CKKvWWpxw8sIlLXGmITMp8l6AN RwIfpnNWL0zyFcZnRWz7BzPsGPBK0lNIbB/Fs55RChWwrtS8pLE5GQi4Vz0BlBqY4ivz ZEZuVye0hrxbd7VprkWGWDj1mbIwPoiql7ndWqdINARso72dHEAVo3sTN9aKDbmlC4I/ kx+i8NEL6c4ODbrvw54eTn4y0YpIMyslnXCBjvTD7fB371PrHMOiEFK/Zik4IQE/WqTF drGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/4VxRgdwmxfsSJ8zu8fWyIG2uKO6MoSUixGpFrOpVFQ=; b=pvEXyXMZ0/NeeYppM01vWLUrgmsPtpseF9HyqstMl3bQBf7LgEuNCsgUiL6EOmgixi SE32atgM0P7R4NDOx/qfe/3rv/iz7ER4j8fdUAR8xNoTaN+vJO3j6d+Pe3zP1SszAwE3 xH3cLMkZ/3YAmm0CqwLUvYNPzMAU2qlDmsEklivDjO6Yy+NS7K44ytypV7FwA6jbikAD KIW1Nev9gjQMBAWp40R6psgXrlPwmz+nwhaei0AMtMjV1OSXdVdr7Q9uh3LkE5jlvE9p 7Dvckkk6Fy4ulnmfS33nyErRloIZ6Dg5coMWNl+7OKtZVAg6U5dGLTXOwwE9k4g2+IQd NDjw==
X-Gm-Message-State: ALQs6tBKMdu/QEP6rDnlocx06genGOD1j1x1NJTDZudHnyk1KX07hJZP P0xFqGnkkGSX5OdheexBDp03bUxPwxucmJNKjY/omQ==
X-Google-Smtp-Source: AIpwx4/KPeDi68lmO72gwf++lpPZikZjZ7qhwb0KCQpo4VqEthTpX02PQdAondDz7Kmlg3em4FDpLjTIYBkiuW4FG+E=
X-Received: by 10.28.160.5 with SMTP id j5mr4312057wme.7.1522773278790; Tue, 03 Apr 2018 09:34:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.226.76 with HTTP; Tue, 3 Apr 2018 09:33:58 -0700 (PDT)
In-Reply-To: <d9a120fee2f84a8b804f3f4029bb0298@XCH-RCD-001.cisco.com>
References: <152269886675.7469.1079237057065588163.idtracker@ietfa.amsl.com> <095ba71ade394fab86ba57201159f5ee@XCH-RCD-001.cisco.com> <CAHw9_iLa5xjrid9SCf2meXYEuPCWyWFPe_ietW7mFaxwyETKpg@mail.gmail.com> <d9a120fee2f84a8b804f3f4029bb0298@XCH-RCD-001.cisco.com>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 03 Apr 2018 12:33:58 -0400
Message-ID: <CAHw9_iJwQbP=xZQLQhY6c0uvqW-Je3=zFsAE83fYhjRQVNF9iw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: The IESG <iesg@ietf.org>, Dave Thaler <dthaler@microsoft.com>, "draft-ietf-6lo-rfc6775-update@ietf.org" <draft-ietf-6lo-rfc6775-update@ietf.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "Gabriel.Montenegro@microsoft.com" <Gabriel.Montenegro@microsoft.com>, "6lo@ietf.org" <6lo@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/S1FEtTQlCexHOgjnW3uKhzuljD4>
Subject: Re: [6lo] Warren Kumari's No Objection on draft-ietf-6lo-rfc6775-update-16: (with COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2018 16:34:46 -0000

On Tue, Apr 3, 2018 at 12:27 PM, Pascal Thubert (pthubert)
<pthubert@cisco.com> wrote:
> Hello Warren:
>
> Super! We're getting there already.
>>
>> Great.
>>
>> > I wanted to point out that NCEs that are not in use can be flushed, so I also
>> meant to limit the need of memory to IP addresses that are currently in active
>> conversations via this router.
>> > If there are more conversations than NCEs then caching/flushing becomes
>> ineffective. What about:
>> >  "for all directly connected addresses to which it is currently forwarding
>> packets , but entries that do not appear to in use may be flushed."
>>
>> Sounds good, or "for all directly connected addresses to which it is currently
>> forwarding packets (entries that do not appear to in use may be flushed)."
>> I'm fine with either.
>
> [PT>] Done; the section now reads as
>
>     In IPv6 ND <xref target="RFC4861"/>, a router needs enough storage
>     to hold NCEs for all directly connected addresses to which it is currently
>     forwarding packets (entries that do not appear to be in use may be flushed).
>     In contrast, a router serving the Address Registration mechanism
>     needs enough storage to hold NCEs for all the addresses that may be
>     registered to it, regardless of whether or not they are actively
>     communicating.
>
>

Awesome, thanks.

>> >
>> >> Nits:
>> >> Section 4.2.1.  Comparing TID values
>> >> "In order to keep this document self-contained and yet compatible,
>> >> the text below is an exact copy from section 7.2.  "Sequence Counter
>> >> Operation" of [RFC6550]."" I think that it would be helpful to
>> >> delimit the copied text (perhaps by indenting it) -- it was unclear
>> >> to me where the copied text started and ended, and so I had to go
>> >> read RFC6550 (which kind of defeats the purpose of copying it).
>> > [PT>]  This text quoted above was discussed at the meeting. The group
>> wanted to detach from RFC 6550 and not give an impression that this spec
>> would inherit RPL's evolution should the referred behavior change. The text
>> was replaced by:
>> > "
>> >         As a note to the implementer, the operation of the TID is fully
>> >         compatible with that of the RPL Path Sequence counter as described in
>> >         the "Sequence Counter Operation" section of the "IPv6 Routing Protocol
>> >          for Low-Power and Lossy Networks [RFC6550] specification.
>> > "
>> >
>>
>> Sorry, I guess I was unclear in my note -- I was suggesting something like:
>> "In order to keep this document self-contained and yet compatible, the text
>> below (to the end of the section) is an exact copy from section 7.2."
>> or
>> "In order to keep this document self-contained and yet compatible, the text
>> below (from <BEGIN> to <END> is an exact copy from section 7.2."
>> or something.
>> But, this was just a suggestion - I'm fine with the original too.
>>
>>
> [PT>] yes but the WG wanted the whole sentence away. We do not mention the act of copy any more, just the fact that we are compatible.
>

Ah, now I understand.

>>
>> >>
>> >> Section Appendix B.  Requirements (Not Normative) "This section lists
>> >> requirements that were discussed discussed by the 6lo WG..."
>> >> I guess that they were discussed at length? :-P
>> >>
>> > [PT>] to death as https://tools.ietf.org/html/draft-thubert-6lo-rfc6775-
>> update-reqs-07 but for the section I added based on Juergen's comments for
>> manageability "Requirements Related to Operations and Management". This
>> one came in late and I need your and Juergen's comments on it.
>> >
>>
>> Sorry, I was overly terse -- I was just referring to the "discussed discussed".
> [PT>] Oups, done : )
>
>> > [PT>] done! Please let me know if you are OK with the changes above
>> > and I'll publish rev-17
>>
>> Yup, I'm a happy camper. Thank you very much for such a quick turnaround.
>> W
>
> [PT>] Will publish right now : )
>
> Take care,
>

Thanks, you too.
W

>
> Pascal



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf