Re: [netmod] 6021 ipv4-prefix

tom petch <ietfc@btconnect.com> Thu, 02 May 2019 09:06 UTC

Return-Path: <ietfc@btconnect.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 C9A6C120159 for <netmod@ietfa.amsl.com>; Thu, 2 May 2019 02:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.249
X-Spam-Level:
X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, LOTS_OF_MONEY=0.001, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 xCBE3PBLGUvb for <netmod@ietfa.amsl.com>; Thu, 2 May 2019 02:06:52 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30102.outbound.protection.outlook.com [40.107.3.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881B112001E for <netmod@ietf.org>; Thu, 2 May 2019 02:06:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mF1G13dBwhYY/CsRpkIVjKMeWQHTta/omDqX95zkNb0=; b=XS+mMdBmC8sXmCaOuWY9OGXf945+DqWMEtETdRvkOocbQ5t1yuoXp5KMtixxWIe09DibFg1GDRAXR8Km0Rh6Rp15NCuC4HsDMD4WW+lMnVJEROOaieRZXDEV7FuXoVeqsqv0lVH1Zu3vfmUVpNLpg5LHV5yJt2G03DlE0AQ8hak=
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB6079.eurprd07.prod.outlook.com (20.178.124.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.7; Thu, 2 May 2019 09:06:49 +0000
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1878.004; Thu, 2 May 2019 09:06:49 +0000
From: tom petch <ietfc@btconnect.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Mikael Abrahamsson <swmike@swm.pp.se>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] 6021 ipv4-prefix
Thread-Index: AQHVAMZf50mA7zDduEuOBh3Lqw5YqA==
Date: Thu, 2 May 2019 09:06:49 +0000
Message-ID: <031e01d500c5$e41a8c00$4001a8c0@gateway.2wire.net>
References: <20190429134615.f32zkbia6fqwk3to@anna.jacobs.jacobs-university.de> <b404565930694fd8af93326b5e754a2b@XCH-RCD-007.cisco.com> <0c4265d31adbf208a680f76216cc4bc42c766eae.camel@nic.cz> <959ed1a8092f4798ac0b923384962049@XCH-RCD-007.cisco.com> <20190429153643.oxfcq7ze6ttdihb4@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1904300713100.3490@uplift.swm.pp.se> <20190430061737.vvxghxyacd57k73i@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1904301038570.3490@uplift.swm.pp.se> <20190430090905.qsa3r4dwauilsxur@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1905011051160.1824@uplift.swm.pp.se> <20190501111712.347bpz26br6ox3jp@anna.jacobs.jacobs-university.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0011.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::23) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 16aa6986-79c6-429e-9611-08d6cedd820f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB6079;
x-ms-traffictypediagnostic: VI1PR07MB6079:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <VI1PR07MB607999B9AFB8B1CFE2123893A0340@VI1PR07MB6079.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 0025434D2D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39860400002)(136003)(396003)(51444003)(13464003)(189003)(199004)(386003)(84392002)(3846002)(86362001)(61296003)(68736007)(6506007)(25786009)(4326008)(5660300002)(2906002)(44716002)(62236002)(66066001)(6436002)(6116002)(6486002)(966005)(6512007)(86152003)(9686003)(6306002)(44736005)(50226002)(476003)(26005)(71190400001)(52116002)(486006)(81816011)(81686011)(8936002)(316002)(6246003)(76176011)(110136005)(446003)(478600001)(71200400001)(305945005)(64756008)(66446008)(81166006)(14454004)(8676002)(81156014)(73956011)(1556002)(66556008)(66476007)(66946007)(256004)(53936002)(102836004)(99286004)(7736002)(4720700003)(186003)(14496001)(229853002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB6079; H:VI1PR07MB3118.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: mTsI3p5rCYIZ0cmz4Git+4cMr8IMYxnI2yp5e3hByRnmpp0dTEeVt7JoFc9cY3JxDLVv7jE/xqW4/slU9jF/otidRCghuWeTeWYENnpiE0kqw2ZfgY6AL/v+i5zVD39GeiAZwc99UhNJHsYNkeaIn6LlyChNni5Yi+n8tiY/6OoFCIKdo+TdLpFdXR8Eo9dokltUFHKwXr7+q12THfZU3OqfFIGzgjBd3ok2FMF8ocrwLoZhMYO/8vl49W9AmYZEAfeN7hjxb8wdkDk7AWbZMVnWpPTMRe9KcjIydOM3mdfWtIgia7VZbMBxK/UDRdJNKC2TBDeMYZQnzWjRbYoKGvCRB3zJ1Bw4crMOh82DV1xkJCbVbeCAhQ7tKZyw3KxrytRG/cE9/tUW3zyIFMvl6lFdxxIpW2ZtF3awGK7azeM=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <699CA5BD506D5744819643FE669B421D@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 16aa6986-79c6-429e-9611-08d6cedd820f
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 09:06:49.4761 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6079
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jAhr_t9iCGRBD9Xc7Ys4n0YgtVQ>
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: Thu, 02 May 2019 09:06:56 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>
Sent: Wednesday, May 01, 2019 12:17 PM

> On Wed, May 01, 2019 at 10:55:38AM +0200, Mikael Abrahamsson wrote:
> >
> > So while you seem to think I am not reading your text, it seems to
me you're
> > not reading what I am saying either. You're not responding to the
points I
> > am trying to make anyway.
> >
> > https://tools.ietf.org/html/rfc7950#section-9.1
> >
> > This talks about *values*. If you drop bits in IPv6-prefix, then
it's not
> > the same *value* anymore.
>
> I personally do take the standpoint that irrelevant bits do not matter
> for the value of a prefix, i.e., 192.168.0.1/24 and 192.168.0.0/24 are
> two different representations for the same prefix. You seem to take
> the standpoint that 192.168.0.1/24 and 192.168.0.0/24 are different
> prefixes since bits that are irrelevant do differ.
>
> Apparently there are different views that people have concerning
> prefixes. I think I have seen the following three alternatives:
>
> a) non-prefix bits that are set to one are illegal in a prefix
> b) non-prefix bits are irrelevant but they need to be preserved
> c) non-prefix bits are irrelevant, ignore them and the canonical
>    representation has non-prefix bits set to zero
>
> The RFC 6991 definitions do c). If there is consensus that c) is
> wrong, we need to deprecate the definitions and create new ones after
> finding consensus on either b) or a).

And I think that c) is the correct answer (and would be for those not
involved in netmod but who have experience of the IETF - did I hear 'be
liberal in what you accept'?)

I have worked with systems that made every effort to find a reason not
to accept something that had been input, and I have worked with systems
that bend over backwards to accept something a bit flaky; different
developers have different cultures but I have always found the culture
of the IETF to be very clear on this point.  Mac, Linux and Windows have
different cultures.

There is a caveat and it is that the context must be clear.  Randy cited
' ... 1234567.89 and if it
subsequently chooses to display it as "1.234.567,89 USD" '
Well, where he is, may be, but not here where it could be

1.234.567,89 Euro
1,234,567.89 Euro
123456789 Yen
or ...
depending on the locale.

Going back to
192.168.0.1/24
then the meaning is clear as long as it is unambiguous that it is a
prefix and not more; as has been commented on (a lot of messages ago),
this could be a compound object, specifying
address+ mask
address + prefix + prefix length
etc
so it matters that the context is clear, both for the object instance
and for the organisation doing the specification.

Tom Petch

> System/kernel interfaces seem to show different behaviours. My Linux
> box seems to do a), my MacOS box seems to do c). The system/kernel
> interfaces likely all do the same if all non-prefix bits are zero,
> i.e., when the system receives data in the canonical format.
>
> Option b) seems to be the most expensive to implement (your server may
> have to clear non-prefix bits before pushing the prefix into the
> kernel and it needs to map data received from the kernel back to a
> prefix that has unused bits preserved in the datastore). Hence, for me
> the choice is between a) and c) and given that we have c) already
> defined for years, my first preference is to just keep things as they
> are.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod