Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07

David Farmer <farmer@umn.edu> Wed, 08 March 2017 16:42 UTC

Return-Path: <farmer@umn.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 7A4C71295F2 for <ipv6@ietfa.amsl.com>; Wed, 8 Mar 2017 08:42:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.801
X-Spam-Level:
X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.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 gNCuU4LLHz_W for <ipv6@ietfa.amsl.com>; Wed, 8 Mar 2017 08:42:01 -0800 (PST)
Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1051295C7 for <ipv6@ietf.org>; Wed, 8 Mar 2017 08:42:01 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 8F2AF9BC for <ipv6@ietf.org>; Wed, 8 Mar 2017 16:42:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtcdSNs4LKge for <ipv6@ietf.org>; Wed, 8 Mar 2017 10:42:00 -0600 (CST)
Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 56952747 for <ipv6@ietf.org>; Wed, 8 Mar 2017 10:42:00 -0600 (CST)
Received: by mail-ua0-f200.google.com with SMTP id 81so56445873ual.3 for <ipv6@ietf.org>; Wed, 08 Mar 2017 08:42:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+LO1QVgQlwGZhAsvRLLyyKLu7xVYNuwgMKxp26JWYEQ=; b=ZO+/ACpcKiVycK43KV6usekt3QiF75OqOXzP4R1IKzR/fAWR3Z5tFH1mZIv9kAMmtA 0pq2UZQD5PcCbV6mE2GCRBFLtkVAmuyVJbw8PH9+nX7OhAJSiDXiPYSel480rU79EzLN WGaOXrtUkc9FzeN7ArT9jp+1pbJuR+xznKMG7FswIatqAcpfNghoncguB0n9Zor+VaR3 8WdttIiAq0YQHVjmVU0aTH+MIslzLeV4Fls926DWaBo7OFa3c7OCTDmMXf/vpZ++v5gP HwcmaIA53jVHBbRxwUBn8VTBh945ay4mt4K9HFmPaAqA8FfLE3iEurAyC9fQQaCLtUIC 9xLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+LO1QVgQlwGZhAsvRLLyyKLu7xVYNuwgMKxp26JWYEQ=; b=pagSJMpVwvetg9FbYf9siqdghHikZ182bYaxhGHcvsMAvqnkKVHf4nzNb/I+QLNH7H F1PjkQlms33AMSyxMX46d0p58imL6JKLkqmV/p+ubHEpIZC8mY+0RY9yKbTGx4jGpQou 5b18osN5zJH+3vvmzQBY9mrwuwGYoBEIMWWhoXXO1SaNQjrlZU4l2W1b8ae3br7ITyDb wIPxeJ71TnVkI92mayN1v+RBEXY3EfN7D/iHDqziHShoAsdhgnKg5rqyDtRP5t4tQDcV OtrKYTQ1+q8AhlCmVXHX+UCDCXGDB9YxOJg9wD2wxav9Pj1bYFiYs+ozVz3J1RubHxCT h+7g==
X-Gm-Message-State: AMke39n3OItrKILhWp9narCEbUmDBX8afhzwaTCwfCCfcN52ljDUithMdc3ADdwxKcUCWQdYHDaSLVJXw1xMaxNtyulyAiGwBxRxUxaotbZ3IBTnMjLteDxi5e6G6gCJo7p3OSEoYKkwF+mfIrk=
X-Received: by 10.31.192.204 with SMTP id q195mr4294727vkf.155.1488991319674; Wed, 08 Mar 2017 08:41:59 -0800 (PST)
X-Received: by 10.31.192.204 with SMTP id q195mr4294718vkf.155.1488991319471; Wed, 08 Mar 2017 08:41:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.134.129 with HTTP; Wed, 8 Mar 2017 08:41:58 -0800 (PST)
In-Reply-To: <CAO42Z2woVonRm45TLWY2s+sP=wPw+Y1=Wud6Q-6t-MfzPYZ2+g@mail.gmail.com>
References: <CAN-Dau3BOVo3UhyGEdxKR-YgqpLqJVxV7uswCCXFsaQoKRaKHw@mail.gmail.com> <CAKD1Yr2UFnVyFptyLD5EqchLNWJyGhoBk2RKNavP1Gc2_zSUVw@mail.gmail.com> <e8b5d239-e6d1-9996-12ab-96729763ab9b@gmail.com> <CAO42Z2woVonRm45TLWY2s+sP=wPw+Y1=Wud6Q-6t-MfzPYZ2+g@mail.gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Wed, 08 Mar 2017 10:41:58 -0600
Message-ID: <CAN-Dau2WFLGi=mUGzcq2jRJWQgsWf9QfTJ-ypyY4wLa+n2qj8g@mail.gmail.com>
Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07
To: Mark Smith <markzzzsmith@gmail.com>
Content-Type: multipart/alternative; boundary="001a114388ccabd3ab054a3ace8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jqLc9LQAEi5Lxvi9bgsbpy-uFGo>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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, 08 Mar 2017 16:42:02 -0000

On Wed, Mar 8, 2017 at 6:13 AM, Mark Smith <markzzzsmith@gmail.com> wrote:

> On 7 Mar. 2017 7:47 am, "Alexandre Petrescu"
> <alexandre.petrescu@gmail.com> wrote:
>
> agreed with some of the things that I cut but I have one question.
>
>
> Le 06/03/2017 à 19:46, Lorenzo Colitti a écrit :
> >
> > If we allow the boundary to change, there is a near certainty that
> > too-small subnets *will* be configured in some places,
> >and is IETF a place to make recommendations of making big or small
> > subnets?  Isnt it for the RIRs to make such recommendations?
>
>
> Protocol designers have to make addressing design decisions, such as
> the structure of addresses and special address value semantics. If
> they didn't, then it would only be possible to have a single
> forwarding method and no other semantics embedded in addresses for the
> entire address space.
>
> For example, if the entire address space is chosen to be destination
> based unicast addresses, because only a single choice can be made,
> there will be no possibility of any multicast forwarding, or a special
> purpose loopback address or prefix.
>
> It is also useful if they choose general defaults, so that things can
> work without significant or ideally any configuration.
>
> Imagine the situation of buying a car, and not being able to drive it,
> because none of its tunable parameters had been set to reasonable
> defaults. Mechanics wouldn't have a problem, and may enjoy the
> experience of setting all the parameters to make the car work. The
> rest of wouldn't find buying a car an easy experience at all.
> Mechanics would lobby against making cars (literally) turn-key,
> because they would be making money from setting all the parameters.
>

Following that analogy, I'd agree that most cars have default parameters
and they should, but almost all car actually have parameters, sometime thos
parameters are exposed to the most naive users, not just expert users.
 (e.g. many cars have a Sport/Econo button on the dashboard, and then
almost all cars have tunable parameters under the hood).

Lorenzo seems to be arguing that all cars must not have any tunable
parameters, at least none that are exposed on the dashboard.  And I have to
disagree.


> Regards,
> Mark.
>



-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================