Re: Warren Kumari's No Objection on draft-ietf-6man-rfc6434-bis-08: (with COMMENT)

Timothy Winters <twinters@iol.unh.edu> Wed, 11 July 2018 20:45 UTC

Return-Path: <twinters@iol.unh.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E788A130ECC for <ipv6@ietfa.amsl.com>; Wed, 11 Jul 2018 13:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu
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 Lf51s8J0LPHP for <ipv6@ietfa.amsl.com>; Wed, 11 Jul 2018 13:45:07 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 C2078130FD3 for <ipv6@ietf.org>; Wed, 11 Jul 2018 13:45:00 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id s13-v6so463305wmc.1 for <ipv6@ietf.org>; Wed, 11 Jul 2018 13:45:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QUMEddh5OYbKPuqQHBqS/Lx/GhCLXN2Tokmfs7ecdbY=; b=boi89k8i8Rkpu0jkwPKV/JgCqbT9t+BCVfbpTn6tNHzdJXXtos/USWArZDZXhB8Ohy KAXXn93igwOOlrWErGHjp3VdNC0S3Btg2bfvpfFe9CGewPut1AmjZ32TTCs2Nd1oSd4q wscD60h5YOVzWOfyOxvSoPiiR9W9wZZNg//F8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QUMEddh5OYbKPuqQHBqS/Lx/GhCLXN2Tokmfs7ecdbY=; b=UV6ufqazA+e8qwuhzI/TnmftX72bEzW2ULwhQ/oBWnS0qbFdXVZqRHX6r2028wDn1e KKj1qyi4oIggSPvsWpKKa5JeqefNY2a57AvVqxmSKDjcsyC1h+qfDnrbWlrA6DZq1+St bY6TA8xP15RtzYR/8yK+nrNeHW0S6hvETkk1/GxGw2sXlh9uX/aV6FxYWLWCYxjTNdMT m/eRPcy3FyDjTAKgsUH/Dp3HMYdr1+M53pY4mAVHYWpjz6LvRZE/ZaO/HR/HhOudJG9+ yEMDxj1z9Gz3Hl96XCFhNJJLO+MKTerSgULBOrWZ4pJxhXvsekBuuos9I0w1sV9HnF/1 RH+Q==
X-Gm-Message-State: AOUpUlFZfCLC3XWlE+nZ3p7aCnxm05d2DTgbLtt43yOFygh9/6V0tz0h qGMgjrN2/OgYamfIE743IrfUcxsm4szarKSq32In5Q==
X-Google-Smtp-Source: AAOMgpfujXbTThOuJHQF/avK1l3GmnMcAh+syQz+OgiWaxzw+eN0MZ3QvMoytEWQ9j3c415IJ2srKPp8gAIV1/nkB1c=
X-Received: by 2002:a1c:b208:: with SMTP id b8-v6mr46418wmf.131.1531341898865; Wed, 11 Jul 2018 13:44:58 -0700 (PDT)
MIME-Version: 1.0
References: <153072815195.27351.5059287323725577376.idtracker@ietfa.amsl.com>
In-Reply-To: <153072815195.27351.5059287323725577376.idtracker@ietfa.amsl.com>
From: Timothy Winters <twinters@iol.unh.edu>
Date: Wed, 11 Jul 2018 16:44:47 -0400
Message-ID: <CAOSSMjWKNQOrPo77X2oKrWBftmjsNZvAwU-cH_+-ZYkZ5s0Nvg@mail.gmail.com>
Subject: Re: Warren Kumari's No Objection on draft-ietf-6man-rfc6434-bis-08: (with COMMENT)
To: warren@kumari.net
Cc: iesg@ietf.org, 6man WG <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, draft-ietf-6man-rfc6434-bis@ietf.org, 6man-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e971b00570bf51ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QHMfONL2dE0UXrL8885KkXKxOJE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
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: Wed, 11 Jul 2018 20:45:09 -0000

Hi Warren,

Good point about the backbone router.   While I think the answer is a
router that is only connected to other routers.  So If an implementor isn't
sure if the Router they should implement them.

OLD:
Redirects are only useful on networks supporting hosts. In core networks
dominated by routers, Redirects are typically disabled. The sending of
Redirects SHOULD be disabled by default on backbone routers. They MAY be
enabled by default on routers intended to support hosts on edge networks.
NEW:

Redirects are only useful on networks supporting hosts. In core networks
dominated by routers, Redirects are typically disabled. The sending of
Redirects SHOULD be disabled by default on routers intended to deployed on
core networks. They MAY be enabled by default on routers intended to
support hosts on edge networks.

Thanks for nits they are addressed in draft 9.

~Tim

On Wed, Jul 4, 2018 at 2:16 PM Warren Kumari <warren@kumari.net> wrote:

> Warren Kumari has entered the following ballot position for
> draft-ietf-6man-rfc6434-bis-08: 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 IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for this - it is a large amount of work!
>
> I had a question, and a few nits.
>
> Question:
> "In core networks dominated by routers, Redirects are typically disabled.
> The
> sending of Redirects SHOULD be disabled by default on backbone routers.
> They
> MAY be enabled by default on routers intended to support hosts on edge
> networks." The SHOULD here concerns me, but only because a "backbone
> router"
> isn't really defined. I know one when I see one, but if I'm an implementer
> I
> don't really know if the box is a backbone router or not (todays backbone
> gear
> becomes tomorrow's edge gear, and next week's boat anchor). I have no
> suggestions for how to address this (and feel free to ignore it!)
>
> Nits (I'm sure the RFC Ed would have caught them, but doesn't hurt to make
> their lives easier) Section 5.3.  Protecting a node from excessive EH
> options
> "If a packet is received and the number of destination or hop-by-hop
> optines
> exceeds the limit, then the packet should be silently discarded." options
>
> Section  5.4.  Neighbor Discovery for IPv6 - RFC 4861
> "  [RFC7559] discusses packet loss resliency for Router Solicitations,"
> resiliency
>
> Section 5.7.1.  Path MTU Discovery - RFC 8201
> " For example, this will result in connections that
>    complete the TCP three- way handshake"
> three-way.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>