Robert Wilton's No Objection on draft-ietf-6man-grand-06: (with COMMENT)
Robert Wilton via Datatracker <noreply@ietf.org> Thu, 01 July 2021 08:25 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 99FD03A1C9E; Thu, 1 Jul 2021 01:25:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton 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>, bob.hinden@gmail.com
Subject: Robert Wilton'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: Robert Wilton <rwilton@cisco.com>
Message-ID: <162512790860.6559.14490468072475126698@ietfa.amsl.com>
Date: Thu, 01 Jul 2021 01:25:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jKhEvhXnNOnRGjiebMdReY5mjCE>
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 08:25:09 -0000
Robert Wilton 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: ---------------------------------------------------------------------- Thanks for this document. I was surprised that ND didn't already have this behavior so its addition is clearly a good thing. A couple of minor comments: (1) I wasn't really familiar with the term "off-link" and I was wondering whether it's definition should be imported here, although I note that ND does define and use this term, so readers familiar with the ND RFC would presumably be familiar with it. (2) I actually found the normative text updating RFC4861 in section 6.1.1 to not be that readable, and I had to scan it a couple of times to spot the distinction between router and host. Possibly laying out the text slightly differently would make the distinction between host and router behaviour more obvious. E.g., When a valid Neighbor Advertisement is received (either solicited or unsolicited), the Neighbor Cache is searched for the target's entry. If no entry exists: Hosts SHOULD silently discard the advertisement. There is no need to create an entry if none exists, since the recipient has apparently not initiated any communication with the target. Routers SHOULD create a new entry for the target address with the link-layer address set to the Target link-layer address option (if supplied). The entry's reachability state MUST be set to STALE. If the received Neighbor Advertisement does not contain the Target link-layer address option the advertisement SHOULD be silently discarded.
- Robert Wilton's No Objection on draft-ietf-6man-g… Robert Wilton via Datatracker
- Re: Robert Wilton's No Objection on draft-ietf-6m… Jen Linkova
- RE: Robert Wilton's No Objection on draft-ietf-6m… Rob Wilton (rwilton)
- Re: Robert Wilton's No Objection on draft-ietf-6m… Alexandre Petrescu
- Re: Robert Wilton's No Objection on draft-ietf-6m… Jen Linkova
- on-link and off-link addresses, side discussion Alexandre Petrescu
- Re: on-link and off-link addresses, side discussi… Simon Hobson
- Re: on-link and off-link addresses, side discussi… Alexandre Petrescu
- Re: on-link and off-link addresses, side discussi… Philip Homburg
- Re: on-link and off-link addresses, side discussi… Simon Hobson
- Re: Robert Wilton's No Objection on draft-ietf-6m… Wes Beebee (wbeebee)
- Re: why "is /64 [a] "default" prefix length when … Alexandre Petrescu
- Re: on-link and off-link Alexandre Petrescu
- Re: on-link and off-link Philip Homburg
- RE: on-link and off-link Vasilenko Eduard
- RE: on-link and off-link Pascal Thubert (pthubert)
- RE: on-link and off-link Vasilenko Eduard
- RE: on-link and off-link Pascal Thubert (pthubert)
- Re: why "is /64 [a] "default" prefix length when … Wes Beebee (wbeebee)
- Re: on-link and off-link Wes Beebee (wbeebee)
- RE: on-link and off-link Vasilenko Eduard