Re: [netmod] 6021 ipv4-prefix

Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 26 April 2019 05:51 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6D12016E for <netmod@ietfa.amsl.com>; Thu, 25 Apr 2019 22:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ptcMWdv74eoe for <netmod@ietfa.amsl.com>; Thu, 25 Apr 2019 22:51:06 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 26F80120112 for <netmod@ietf.org>; Thu, 25 Apr 2019 22:51:06 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id j26so1051027pgl.5 for <netmod@ietf.org>; Thu, 25 Apr 2019 22:51:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wzI39aWKCsK0H47D0aDXA4TXSXltOHhVV3yAWLjPkAo=; b=TPZ+VRIXXeQRvBPdIgHYAGp0YIvhK2pJFlC1zAQRFngPNcbkNwPJ+YCgfbIeSbc8E5 soc6+mYJJ9zwCQ6+jWQ8Q80lS/JxOWvr33/UAQUyFGO9ye5WSLA2vf7d1oygVAPPHHUZ 2/ost1sU7K2aDayxKw3Gk0VojsBasiy9YfMLk0R8XhkGkuEupxxjNP47Xy/00xXHmdwM nH54r/ff5lM+Sq6xKeJaNXVnSrFcDY3H2JrOeiq/2NEG9vEnDhTHQggFh00Wtrb+QEDC DwiB1k0RtJcZESL7UFgCLUFpCNrRsMwBF9Gat/8UDc7ZYWqyAOtFKSTCViMpTbE7WSv2 g+Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wzI39aWKCsK0H47D0aDXA4TXSXltOHhVV3yAWLjPkAo=; b=G674L9oaDuMjXBj8h3Bn2nnugLUKZXy4PjUcG2qwTjuXnRWkUBZE8c8GKFTHJp3nt2 48U96g8yqyRYoCmSrMzgcbr/MFArrQM+nYe0kk8hqH8yzQFc7JttkPO3BVT2A/z7HYmN ghpLgEOrtYZJQGT22huRaiN0QthKsfH0MRhm4cg2y5re95f4zOLuoE10oBEXKQVDQ4Pv 3mXgTo1sNHQW7iQxpSPCv4pWrsSCaJBIxqLqjR/ZwHSxT9cTA0pBh3BXhpHJ4vA2K0VD /QRawk5i0knP0wbw32nw2UBs9PXR5FnoIJii1rB0zujKBgYfvov+xZ4YH3p5PbJ0D3Yo 8nXQ==
X-Gm-Message-State: APjAAAUO5x4pV2fV8d07UrLloZSivecVC1XGZ8lJgHzUGQl9SO4+ub0b ztijdIRkhwXXTLzeyb2mYXc=
X-Google-Smtp-Source: APXvYqyWgxfIqNFF3V87jyjbo2F9FhZ1XZRhzUzusuR9iUT/RGjVM4EQSYTP0KxMj1SYpzaTw55e9A==
X-Received: by 2002:a63:cc0d:: with SMTP id x13mr41548085pgf.280.1556257865431; Thu, 25 Apr 2019 22:51:05 -0700 (PDT)
Received: from [192.168.1.13] (c-73-189-13-44.hsd1.ca.comcast.net. [73.189.13.44]) by smtp.gmail.com with ESMTPSA id s79sm48119657pfa.31.2019.04.25.22.51.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 22:51:04 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura <jefftant.ietf@gmail.com>
X-Mailer: iPad Mail (16E227)
In-Reply-To: <5e98661c-dbec-42dd-82da-5410418709a3@labn.net>
Date: Thu, 25 Apr 2019 22:51:03 -0700
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1E0D539-FDE7-4BB3-8456-FADE4BF97F6C@gmail.com>
References: <003301d4f498$4f593640$ee0ba2c0$@gmail.com> <alpine.DEB.2.20.1904180906360.3490@uplift.swm.pp.se> <20190418080643.gcdi5x4dtn64adwc@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1904181128480.3490@uplift.swm.pp.se> <20190418102604.y5wyqflcudiywj2i@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1904181251000.3490@uplift.swm.pp.se> <5e98661c-dbec-42dd-82da-5410418709a3@labn.net>
To: Lou Berger <lberger@labn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/lxUOGYBwxpNwOn1pzFXb9SUPaNk>
Subject: Re: [netmod] 6021 ipv4-prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2019 05:51:08 -0000

+1

Cheers,
Jeff

> On Apr 18, 2019, at 6:12 AM, Lou Berger <lberger@labn.net> wrote:
> 
> Having worked with UIs that have the behavior of accepting an address/prefix-len and mapping it to a prefix, (i.e., network/prefix-len and zeroing out the non-significant bits)  - some users really like it as they don't have to do the transformation from address to network, notably for odd length prefixes, while other users hate it as the system shows/does something different than what they entered.
> 
> In the end the current definition is what it is.  If we want something different we can define it. I personally think an address/prefix-len would be useful, and would leave ip-prefix as is.  (again just an individual's opinion.)
> 
> Lou
> 
>> On 4/18/2019 6:53 AM, Mikael Abrahamsson wrote:
>>> On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
>>> 
>>>> On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
>>>> 
>>>> 2001:db8::/64 and 2001:db8::1/64 are NOT the same if you use them.
>>> Why are they not the same if you define a prefix?
>> Because they're not. One of them is a valid prefix, the other one isn't.
>> 
>>> +17.4 is not an integer, so this is an error (not because of the + but
>>> because of the . followed by additional digits). +17 is I think a valid
>>> integer value but the + will be dropped in the canonical representation.
>> Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
>> the prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
>> rounded if an integer input is expected?
>> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod