Re: a draft about on-link and submit prefixes

Havard Eidnes <he@uninett.no> Tue, 14 March 2017 17:30 UTC

Return-Path: <he@uninett.no>
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 19DB11329F4 for <ipv6@ietfa.amsl.com>; Tue, 14 Mar 2017 10:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 N-e2UDFQRwIb for <ipv6@ietfa.amsl.com>; Tue, 14 Mar 2017 10:30:11 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by ietfa.amsl.com (Postfix) with ESMTP id F16D71329F3 for <ipv6@ietf.org>; Tue, 14 Mar 2017 10:30:10 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 2555943E9C9; Tue, 14 Mar 2017 18:30:07 +0100 (CET)
Date: Tue, 14 Mar 2017 18:30:01 +0100
Message-Id: <20170314.183001.1219187989044942807.he@uninett.no>
To: otroan@employees.org
Cc: Tim.Chown@jisc.ac.uk, ipv6@ietf.org, jinmei@wide.ad.jp
Subject: Re: a draft about on-link and submit prefixes
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org>
References: <BD1C6A8D-F9D6-44D4-9911-20E1DE3F1658@employees.org> <49C05C3D-9594-4A46-BBA4-5767A9FDD34A@jisc.ac.uk> <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/q1gLvh4QURxE6nhRrvPa9_7odyM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.21
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: Tue, 14 Mar 2017 17:30:13 -0000

>>>>> I agree that a generalization is a good idea. In particular, it would
>>>>> be good to have (in one place) a definition of what an IPv6 subnet is,
>>>>> especially if a subnet can be spread across multiple links (which is
>>>>> *not* obvious to me from reading RFC 4861 and RFC 4862).
>>>> 
>>>> I like this idea. Examples along the lines that Lorenzo
>>>> included in his email would also be useful to include, with
>>>> notes on use cases.
>>> 
>>> Any idea of what problem we're trying to solve...?
>> 
>> I think it’s adding Informational clarity, especially for
>> those familiar with thinking ’the IPv4 way’, without adding
>> unnecessary wordage directly to 4291-bis.
> 
> Right, that was what I feared.
> Including esoteric examples and examples bordering on
> configuration errors, just isn't going to add clarity in my
> opinion.

I disagree.  Making a clarification implies delineating the border,
and not neccessarily describing the typical situation or usage.  By
necessity you will have to find edge cases along the border.

Do you think there's something which is factually or technically
inaccurate in the draft Jinmei posted?  Do you think some of the
setups which are described are still "within the border" of what's
described in the stadnards but should not be?

It may not be pretty, but it's perhaps time to own up to what we've
begat?

Regards,

- Håvard