Zaheduzzaman Sarker's No Objection on draft-ietf-6man-grand-05: (with COMMENT)

Zaheduzzaman Sarker via Datatracker <> Tue, 29 June 2021 18:12 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 1B8773A3C9C; Tue, 29 Jun 2021 11:12:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Zaheduzzaman Sarker via Datatracker <>
To: The IESG <>
Cc:,,, Bob Hinden <>,
Subject: Zaheduzzaman Sarker's No Objection on draft-ietf-6man-grand-05: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 7.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Zaheduzzaman Sarker <>
Message-ID: <>
Date: Tue, 29 Jun 2021 11:12:51 -0700
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Jun 2021 18:12:51 -0000

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-6man-grand-05: 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
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thanks for the very good document. It was clear about the need and the solution

I have some comments, addressing them  I believe will improve the document even
more -

   * Section 3: already a great job done in the terminology section, please add
   the STALE definition to that list with reference.

   * Section 4.1:
      * Please provide ref to "onlink routers" or add verbose description of
      it. Best to add this to section 3, even if this might be very well known
      term to the active participants.

      * It would be great if there is some text describing what if "multicast
      traffic should not
   increase" is not true and what precaution should be taken.

   * Section 4.2 : this section might be improved by providing some information
   about duplicate entries unless there is no chance of duplicate addresses in
   case of unsolicited NAs. May be a hint is enough that it is covered in
   section X.X.

And one question -

   * Section 5.2 :
       "Those packets would be sent to the
      host with the optimistic address instead of its rightful owner."

      Could this problem be amplified to create issues in the network?