IETF Logo Mail Archive

Re: [netmod] 6021 ipv4-prefix

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 30 April 2019 08:46 UTC

Return-Path: <swmike@swm.pp.se>
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 77C061200F5 for <netmod@ietfa.amsl.com>; Tue, 30 Apr 2019 01:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 Ram77QtEd8ua for <netmod@ietfa.amsl.com>; Tue, 30 Apr 2019 01:46:38 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C748C120072 for <netmod@ietf.org>; Tue, 30 Apr 2019 01:46:37 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id D0ED9AF; Tue, 30 Apr 2019 10:46:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1556613994; bh=B+ruB9P4H5ZhES2+LDxmM9atp6ifXUCzmzlZlG3xRmc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=MLgOdAE4vG6IALxv2CMwFD6ElyDR6jFTl4OF4HQUhXv7sjI9cTmC704PqLlLJQqWZ SxmJOVZ9iANSblQY1ZJ+A0wQYNeKJuHil0PDMbh0qcq4DrK3P/Nh21c1oRcEqto9LM p7GS1KmJb3BZXLbZv7Itd6Vrm1OsAl1IGF0RPMEw=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CD12F9F; Tue, 30 Apr 2019 10:46:34 +0200 (CEST)
Date: Tue, 30 Apr 2019 10:46:34 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
cc: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
In-Reply-To: <20190430061737.vvxghxyacd57k73i@anna.jacobs.jacobs-university.de>
Message-ID: <alpine.DEB.2.20.1904301038570.3490@uplift.swm.pp.se>
References: <20190429100213.vukmmbdsz5zlw6w5@anna.jacobs.jacobs-university.de> <bbf252aaca86418ca80b3bf04a910aff@XCH-RCD-007.cisco.com> <20190429103451.yink4bdvvmlh7ohe@anna.jacobs.jacobs-university.de> <c03aa9a27ed544c5be88fd0750d782e3@XCH-RCD-007.cisco.com> <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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/gqgvv5--CLBgnxKW1rISP0TKsVM>
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: Tue, 30 Apr 2019 08:46:40 -0000

On Tue, 30 Apr 2019, Juergen Schoenwaelder wrote:

> I think we go in circles in this thread and I will stop explaining
> things again and again. I suggest people look at the next revision
> and if anything remains unclear, people can send concrete edit
> proposals.

You don't have to explain it. Let me try in a different way.

https://tools.ietf.org/html/rfc7950#section-9.1

"For most types, there is a single canonical representation of the
    type's values."

Is it generally ok that the canonical value potentially represents a 
different bit field/value than what the client sent?

If it is (and that's fine by me), I think this should be made more clear 
in the next rev of the YANG specification. I feel the whole 
"canonical/lexical format" concept is underspecified, for instance in the 
case of ipv6-prefix. In the text you suggested before that fixes 
ipv6-prefix. Do we have more types where this needs to be fixed?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email