Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-02.txt

Havard Eidnes <he@uninett.no> Mon, 02 November 2015 09:52 UTC

Return-Path: <he@uninett.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C101A0378 for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 01:52:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 aN0tjhAW4DyZ for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 01:52:30 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA161A02B1 for <v6ops@ietf.org>; Mon, 2 Nov 2015 01:52:30 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id D8BFC3D0B3; Mon, 2 Nov 2015 10:52:28 +0100 (CET)
Date: Mon, 02 Nov 2015 10:52:28 +0100
Message-Id: <20151102.105228.439899806.he@uninett.no>
To: markzzzsmith@gmail.com
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <CAO42Z2yMbiqeYAaK7nHJR5sUCeur+0k+eJFcUFvf941v7Nw=Lw@mail.gmail.com>
References: <CAO42Z2ySFh5fKEVaVBRKFP_79qNyUUODwNHV1JnsQZemH7Z-8A@mail.gmail.com> <alpine.DEB.2.02.1511020255350.15542@uplift.swm.pp.se> <CAO42Z2yMbiqeYAaK7nHJR5sUCeur+0k+eJFcUFvf941v7Nw=Lw@mail.gmail.com>
X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/HEBzs3I40yGhWtD-ipvh6M1OMm4>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-02.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 02 Nov 2015 09:52:32 -0000

>>> I agree with making sure to avoiding ambiguity, I know on occasion it
>>> hasn't been clear to me whether somebody is describing a prefix with a
>>> smaller number of addresses, or a shorter prefix length, which obviously
>>> mean the complete opposites in terms of number of addresses within the
>>> prefix, when they use "smaller prefix".
>>
>> What about "smaller/larger sized prefix"?
>
> That would be clearer.

To me that's still borderline ambigious, and I don't understand
why anyone would want to use borderline ambigious wording when
writing RFCs or discussing them.

It's not clear whether it's the prefix-length which is "smaller"
or "larger" or the address space covered which is "smaller" or
"larger", and they each point in the direction of different
interpretations.  In other words, you don't "size" a prefix, but
you "size" the address space covered.  A prefix, on the other
hand, has length, so to my eyes the above looks ... awkward.

Therefore I'm suggesting the more unambigious "shorter/longer
prefix" as preferable.

Regards,

- Håvard