Re: [netmod] 6991bis: address-with-prefix-length

"Acee Lindem (acee)" <acee@cisco.com> Tue, 02 April 2019 16:00 UTC

Return-Path: <acee@cisco.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 B1E0212028A for <netmod@ietfa.amsl.com>; Tue, 2 Apr 2019 09:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IFx1H/TC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BYNmKXIZ
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 yx1ttxQuTDYW for <netmod@ietfa.amsl.com>; Tue, 2 Apr 2019 09:00:22 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5717E1202F5 for <netmod@ietf.org>; Tue, 2 Apr 2019 08:52:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9172; q=dns/txt; s=iport; t=1554220356; x=1555429956; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=u5PrDC4hCkvVZfOK+kANtd8WWQjfYxk7MloYAlhYJkE=; b=IFx1H/TCfX7pw0amPky11cAOeMzDoaMCUDod/nH1Ji/UEuFP5/sgg7Be SDZN5+1dBRn6FADf4Zwgh6YrIfKj2nEiVQN1RBS9whb6iKJ6R5OU8naIv /bchNsM0WzDrVViTF5vnBsg07fLbHlxK3d6WeOaaAj9e1o2wN09lghbQ+ c=;
IronPort-PHdr: 9a23:MjLuwxYbujZHfbR2aIZjA9n/LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el20QKbRp3VvvRDjeee87vtX2AN+96giDgDa9QNHwQAld1QmgUhBMCfDkiuJfXnYgQxHd9JUxlu+HToeUU=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAABJhKNc/5NdJa1iAxkBAQEBAQEBAQEBAQEHAQEBAQEBgVIDAQEBAQELAYE9UANodAQLJwqEBINHA485gleJOI1ZgS6BJANUDgEBGAsJg3pGAheFJSI1CA0BAQMBAQkBAwJtHAyFSgEBAQECAQEBIREMAQEsCwELAgICAQgQAQQBAQECAiYCAgIZBgYLFQgIAgQBDQWDIgGBXQMNCAEOoygCihRxgS+CeQEBBYUIDQuCDAMFBYEGJAGEXYZVF4F/gREnH4JMPoIaRwEBgXgKJoJDMYImilCCNYRDk1k2CQKMOINtg0EalDiLRodVjAcCBAIEBQIOAQEFgU8BNYFWcBU7KgGCQYIKg24zhGGFP3KBKI4SAYEeAQE
X-IronPort-AV: E=Sophos;i="5.60,301,1549929600"; d="scan'208";a="253383468"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2019 15:52:30 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x32FqUcX010826 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Apr 2019 15:52:30 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 10:52:29 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 11:52:28 -0400
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 2 Apr 2019 11:52:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u5PrDC4hCkvVZfOK+kANtd8WWQjfYxk7MloYAlhYJkE=; b=BYNmKXIZddf46BZyg/7RJ4VftM0WomxF+5ljYufm+syT/AZiHn2XZDAjCOYCA2/csVxWAJY0+uLAKFTZ1g0mt4PNwtRDSvgN9ei4vqhx30HA5CNTjt0RXyo0sdupI0hwrLXy6XF6pIKRJZxXJZEXE3efBVl2FTVAOxdFP5wFE9o=
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2129.namprd11.prod.outlook.com (10.174.117.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.16; Tue, 2 Apr 2019 15:52:26 +0000
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1]) by BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1%8]) with mapi id 15.20.1750.017; Tue, 2 Apr 2019 15:52:26 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] 6991bis: address-with-prefix-length
Thread-Index: AQHU6JixdGMCt4a400OFM02B5CwunKYoym0AgAAInQCAAC+hAP//wTeA
Date: Tue, 02 Apr 2019 15:52:26 +0000
Message-ID: <ABA52E74-E523-4E83-90FA-581EAEA3657F@cisco.com>
References: <7d368608-7c73-4287-bfa3-69a8db8576a2@Spark> <082d01d4e944$aae0e3a0$4001a8c0@gateway.2wire.net> <20190402121550.7da6lxd6n5qiphsd@anna.jacobs.jacobs-university.de> <20190402.144640.408659609107514722.mbj@tail-f.com> <ebdf44cb1f47475fb44a51e01c9a809e@XCH-RCD-007.cisco.com>
In-Reply-To: <ebdf44cb1f47475fb44a51e01c9a809e@XCH-RCD-007.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com;
x-originating-ip: [173.38.117.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1d0496dd-9af9-47d7-c552-08d6b7833456
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BN6PR1101MB2129;
x-ms-traffictypediagnostic: BN6PR1101MB2129:
x-ms-exchange-purlcount: 2
x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr
x-microsoft-antispam-prvs: <BN6PR1101MB2129A3B46AA582CACA10A3CDC2560@BN6PR1101MB2129.namprd11.prod.outlook.com>
x-forefront-prvs: 0995196AA2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(366004)(136003)(396003)(54094003)(13464003)(51444003)(199004)(189003)(486006)(33656002)(106356001)(186003)(76176011)(7736002)(86362001)(99286004)(105586002)(66066001)(36756003)(6246003)(8936002)(14454004)(110136005)(6116002)(2616005)(93886005)(68736007)(82746002)(81156014)(8676002)(81166006)(476003)(6306002)(561944003)(102836004)(6436002)(26005)(53546011)(6506007)(5660300002)(6512007)(478600001)(256004)(2501003)(83716004)(97736004)(4326008)(71190400001)(446003)(316002)(229853002)(3846002)(53936002)(71200400001)(966005)(305945005)(11346002)(2906002)(25786009)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2129; H:BN6PR1101MB2226.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: sRvX3O8kuvdZJEVosbKj94SaNFyVf3z9YM6xBQ6xBPeBtXtjOGemNPlMRIbdyhJDUrwbPUPTGPF0sXrNwXyFlTbnz4/YDVlUUmyGAYoI9h7FfOSvxw8kJz1kDUMb99Td4eK9pTYZHblDQReWtrjpZ12oVir6F87KZfc1vT++zNo4aneQ24w2GGDL5lJqOMg3pRDE7kkoC+ohLVmLdGOF8+qvy52kqkFk/elv37FSMgWPRYGWVedNKcYWdBUUo5Y9YURplTMaCCFQCzi039O+ipr5P/u2/qWnKzyc7iZrnySAibt+opqTVY9dPn2L7eyWtt51Ja5PHTK//+lyii5iniWcjSD0HpI+XerPCh9vKyIO7xhl2b1pRfVnhsFFXx5atR6XMhmzSoWMZmo18D8WtICXENFZxqRD9LiF4IfmFJs=
Content-Type: text/plain; charset="utf-8"
Content-ID: <4ABAC944D71B8C4D919CCB21AA45CECA@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d0496dd-9af9-47d7-c552-08d6b7833456
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2019 15:52:26.3872 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2129
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/r7Z_QrAHt11ZmKM9INxzs826Fjw>
Subject: Re: [netmod] 6991bis: address-with-prefix-length
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: Tue, 02 Apr 2019 16:00:27 -0000

Hi Rob, 

On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)" <netmod-bounces@ietf.org on behalf of rwilton@cisco.com> wrote:

    
    
    > -----Original Message-----
    > From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Bjorklund
    > Sent: 02 April 2019 13:47
    > To: j.schoenwaelder@jacobs-university.de
    > Cc: netmod@ietf.org
    > Subject: Re: [netmod] 6991bis: address-with-prefix-length
    > 
    > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
    > > If you go back ~20 messages, my proposal was ip-address-prefix,
    > > ipv4-address-prefix, and ipv6-address-prefix.
    > 
    > Do we agree that this type really specifies two values in one?  If so I think the
    > "and" is useful.
    
    Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?

This was my confusion as well since the ipv4-prefix and ipv6-prefix types (ietf-inet-types) have been used when they probably shouldn't have been.  Note that they both have the constraint of not allowing the host bits to be set should they should be used in situations like interface address assignment. 

Excerpted from RFC6991 ipv4-type definition (note the last sentence): 
     description
        "The ipv4-prefix type represents an IPv4 address prefix.
         The prefix length is given by the number following the
         slash character and must be less than or equal to 32.

         A prefix length value of n corresponds to an IP address
         mask that has n contiguous 1-bits from the most
         significant bit (MSB) and all other bits set to 0.

         The canonical format of an IPv4 prefix has all bits of
         the IPv4 address set to zero that are not part of the
         IPv4 prefix.";
    
    So, I think that the names above are probably right, or otherwise if you want the "and" then perhaps it should be "ip-address-and-prefix-length" - which seems clunky?

I think the original suggestion of ipxx-address-prefix would be ok. 

Thanks,
Acee
    
    Thanks,
    Rob
    
    
    > 
    > Also note that the current text in RFC 6991 says:
    > 
    >      The ipv4-prefix type represents an IPv4 address prefix.
    > 
    > so having a type ipv4-address-prefix for something that is not (only) an
    > "ipv4 address prefix" is imo confusing.
    > 
    > 
    > /martin
    > 
    > 
    > 
    > 
    > >
    > > /js
    > >
    > > On Tue, Apr 02, 2019 at 11:13:09AM +0000, tom petch wrote:
    > > > ----- Original Message -----
    > > > From: "Jeff Tantsura" <jefftant.ietf@gmail.com>
    > > > To: <netmod@ietf.org>; "Kristian Larsson" <kristian@spritelink.net>
    > > > Sent: Monday, April 01, 2019 11:09 PM
    > > >
    > > > What Kristian has proposed makes sense, in favor.
    > > >
    > > > <tp>
    > > >
    > > > Yes, I support this idea and we should be able to come up with a
    > > > more user-friendly name;  address-prefix or address-length ?
    > > >
    > > > Tom Petch
    > > >
    > > > p.s.
    > > >
    > > >    identifier          = (ALPHA / "_")
    > > >                          *(ALPHA / DIGIT / "_" / "-" / ".")
    > > >
    > > > Cheers,
    > > > Jeff
    > > > On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson
    > > > <kristian@spritelink.net>, wrote:
    > > > > Hello Mahesh,
    > > > >
    > > > > On 2019-04-01 21:40, Mahesh Jethanandani wrote:
    > > > > >
    > > > > > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund <mbj@tail-f.com>
    > > > wrote:
    > > > > > >
    > > > > > > I know that this type is convenient, esp. if you use it for
    > > > > > > manual input, but I wonder if it really is good practice to
    > > > > > > squeeze two values into one.
    > > > > >
    > > > > > Agree. The combination makes sense for CLI, but for modeling the
    > > > address and prefix should be separate.
    > > > >
    > > > > Okay, then why do we have an ip-prefix data type at all? With the
    > > > > same line of argument you apply, it should be split up.
    > > > >
    > > > > So you're the third person bringing up CLI. I don't get this at
    > > > > all. I don't see how CLI are different from everything else. This
    > > > > is about
    > > > data
    > > > > modeling and data modeling is about expressing the world in a data
    > > > > modeling language. It's like painting a picture but instead of a
    > > > > brush you have a schema language like YANG. What do you see?
    > > > > Express it. It doesn't matter if the purpose is a CLI, a web page
    > > > > or just exposing it via NETCONF for another system to consume.
    > > > >
    > > > > I think address-and-prefix-length is natural. JUNOS uses this format.
    > > > XR
    > > > > uses this format (for IPv6 at least). Nokia SROS uses this format.
    > > > >
    > > > > We have written a bunch of models where the lack of this IMHO
    > > > > makes
    > > > them
    > > > > less elegant. I'd like for there to be an IETF standard data type
    > > > > to make those models more elegant.
    > > > >
    > > > > Kind regards,
    > > > > Kristian.
    > > > >
    > > > > _______________________________________________
    > > > > netmod mailing list
    > > > > netmod@ietf.org
    > > > > https://www.ietf.org/mailman/listinfo/netmod
    > > >
    > > >
    > > >
    > > > --------------------------------------------------------------------
    > > > ----
    > > > --------
    > > >
    > > >
    > > > > _______________________________________________
    > > > > netmod mailing list
    > > > > netmod@ietf.org
    > > > > https://www.ietf.org/mailman/listinfo/netmod
    > > > >
    > > >
    > > > _______________________________________________
    > > > netmod mailing list
    > > > netmod@ietf.org
    > > > https://www.ietf.org/mailman/listinfo/netmod
    > >
    > > --
    > > 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
    > >
    > 
    > _______________________________________________
    > netmod mailing list
    > netmod@ietf.org
    > https://www.ietf.org/mailman/listinfo/netmod
    
    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod