Murray Kucherawy's No Objection on draft-ietf-6man-grand-06: (with COMMENT)
Murray Kucherawy via Datatracker <noreply@ietf.org> Thu, 01 July 2021 05:20 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B513A10D0; Wed, 30 Jun 2021 22:20:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-grand@ietf.org, 6man-chairs@ietf.org, ipv6@ietf.org, Bob Hinden <bob.hinden@gmail.com>
Subject: Murray Kucherawy's No Objection on draft-ietf-6man-grand-06: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 7.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <162511685047.13937.3295227847101089364@ietfa.amsl.com>
Date: Wed, 30 Jun 2021 22:20:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/LgZeKVBjUGfhojVtY-sMzyDp6yk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2021 05:20:51 -0000
Murray Kucherawy has entered the following ballot position for draft-ietf-6man-grand-06: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-grand/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't see a lot of transport documents that make me think this, but: Kudos for an easy read. In Sections 6.1.1 and 6.1.2, there are the following uses of BCP 14 language: * "Routers SHOULD create a new entry ..." * "In such cases a node SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT Neighbor Advertisement messages." * "If the address is preferred then the Override flag SHOULD NOT be set." * "The destination address SHOULD be set to the all-routers multicast address." * "The first advertisement SHOULD be sent as soon as one of the following events happens:" To a transport expert the answer to this may be obvious, but I'm left wondering why these are only SHOULD [NOT]s. Is there a ever a good reason to deviate from those instructions? I generally find it helps to, when using SHOULD [NOT], include a sentence or two about why it might be necessary to do something else, to guide novice readers. It's not strictly necessary, but something to consider here. Apart from that, I have only a couple of boring nits to offer: Section 1: * "It can causes ..." -- s/causes/cause/ Section 5: * "The section 2.2 of ..." -- s/The section/Section/
- Murray Kucherawy's No Objection on draft-ietf-6ma… Murray Kucherawy via Datatracker
- Re: Murray Kucherawy's No Objection on draft-ietf… Jen Linkova
- Re: Murray Kucherawy's No Objection on draft-ietf… Murray S. Kucherawy