Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00

Owen DeLong <owen@delong.com> Wed, 14 August 2013 20:33 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8AD11E81A7 for <v6ops@ietfa.amsl.com>; Wed, 14 Aug 2013 13:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level:
X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHe3b2pggxoy for <v6ops@ietfa.amsl.com>; Wed, 14 Aug 2013 13:33:16 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id ADBB511E81A6 for <v6ops@ietf.org>; Wed, 14 Aug 2013 13:33:16 -0700 (PDT)
Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7EKSeg5016410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Aug 2013 13:28:41 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7EKSeg5016410
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376512121; bh=5I9kdwIMWlU7FYqZDgzwMiefY7c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jzg3MPA3yGh0Yx3fSgG2lE00na9VYWg3KmNNyn8GNo8lBZL6nzC+yqep7HCTY7RUK jXZF1nzBiOyFMOXx5oYxUgJz5COAeKb9+SFQFAnq2KsbR75a3+5Hd/BB2ccegCHct1 4U1PdWFhE65L3IUjXCVmZYenp8PwbOEy719K2wOc=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439B6F9C3@PRVPEXVS15.corp.twcable.com>
Date: Wed, 14 Aug 2013 13:28:41 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D30E14A7-68EB-4D58-97C3-3274B3BD4853@delong.com>
References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <CA+z-_EWFAGFqyo3E3LzrEhpMRV6axdLJTC50BNwXMNGuJtZuTA@mail.gmail.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <A84D9405-B3D2-4D55-BAEE-FE25ACE45EB6@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <520AD94F.1050604@nic.br> <1376445275.5223.YahooMailNeo@web142501.mail.bf1.yahoo.com> <520B029C.3010308@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439B6F9C3@PRVPEXVS15.corp.twcable.com>
To: "George, Wes" <wesley.george@twcable.com>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 14 Aug 2013 13:28:41 -0700 (PDT)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Aug 2013 20:33:17 -0000

On Aug 14, 2013, at 05:40 , "George, Wes" <wesley.george@twcable.com> wrote:

> 
>> From: Antonio M. Moreiras [mailto:moreiras@nic.br]
>> 
>> On 13/08/13 22:54, Mark ZZZ Smith wrote:
>>> ----- Original Message -----
>>>> For one of our trainings at NIC.br, [snip]
>>> 
>>> ISPs don't just get a /32, they can get larger if they need it.
>> Placing too much value on using a /32 in your examples can strongly
>> imply that all IPv6 addressing plans must fit within a /32.
>> 
>> We are the NIR in our country, we are aware of that. But the vast
>> majority of our allocations are indeed /32. The BCOP are also aware of
>> that, and if we want a experiment where we can follow strictly its
>> recommendations, then we need a /32 or something shorter.
>> 
>>> The trouble is that if you are too prescriptive, it then creates
>> opportunities for people to be lazy in their learning. They rote learn
>> rather than understand, and that means they may not be able to cope with
>> the situation is even the slightest bit different.
>>> 
>>> I think teaching people to subnet using a range of bits should be
>> taught first, so that they can work with a range allocations. Whether it
>> is a /32, a /48 or a /29 then doesn't matter. Then give examples of how
>> to apply those techniques to various sized IPv6 prefixes to re-enforce
>> the methods.
>> 
> [WEG] +1. I think there's a fine line between trying to avoid confusion and making it too easy to verbatim copy something without understanding it.
> 

I completely agree and I'm pretty sure that Antonio would agree as well.
>>>> In some situations, for teaching, or writing scripts for labs,
>> howtos,
>>> 
>>>> books, brochures, etc, it's better, simpler, easier, more precise,
>> more
>>>> clear, to use a prefix shorter than /32. In some situations we are
>> doing
>>>> that, and we have seen other groups doing the same.
>>>> 
> [WEG] I think over the course of this discussion, you've built a reasonable case for this with real-world examples to back up your assertions. However, just as teachers like you to show your work when solving a math problem, I strongly suggest that you revise the draft to include this supporting information in order to build the case, else you'll have this conversation every time someone reads the draft and is skeptical that more space is needed. I realize that 3849 is light on justification and you patterned this draft after that document, but few would argue that at least one prefix for documentation is necessary and appropriate. As you've seen, fewer are convinced that additional prefixes or larger prefixes are needed without some background information from those with experience in training and documentation that have observed some real-world problems with the current solution. I can't guarantee that you won't have more "you're doing it wrong" arguments, but at least you'
> re demonstrating that it's not an arbitrary request.

I support adding the supporting details to the draft. I think that's an excellent suggestion. It will not only make the draft more palatable to a wider audience, it will also help inform future instructors that may be reading the draft about things like the need to teach VLSM as a core principle prior to showing examples of predetermined prefix sizes.


> Wes George
> 
> Anything below this line has been added by my company's mail server, I have no control over it.
> -----------------

Does this mean that I am now a Time Warner mail server?

(sorry, couldn't resist)

Owen