Re: [yang-doctors] 6991bis

Robert Wilton <> Thu, 22 March 2018 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 977A112D890 for <>; Thu, 22 Mar 2018 08:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K3NLaSShJyFQ for <>; Thu, 22 Mar 2018 08:03:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92B8D12D88D for <>; Thu, 22 Mar 2018 08:03:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4178; q=dns/txt; s=iport; t=1521730990; x=1522940590; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=1dJoDBTSzuzOHR0343sFiHgMVShKrKlPJaElKN7dFv8=; b=SjLPJgGKk1gsNhcge+yUQLzrgN+5TsnCNM3EyM/r6m9aOZf1b767/fkI nPVUGWbS0Ca16Z2EZ7u7V8Uf2Q3lAFa9/DT1GCCNp4OKOqVfMlqqUGbG0 dLBPzLm62fKdQN89EBbEQpVwqaRt3McLClkmHE7DKBMeG+iJnWwHE8odY c=;
X-IronPort-AV: E=Sophos;i="5.48,345,1517875200"; d="scan'208";a="2773368"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2018 15:03:08 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id w2MF37Im018437; Thu, 22 Mar 2018 15:03:08 GMT
To: "Reshad Rahman (rrahman)" <>, "" <>
References: <> <20180322110052.7nz7q7tzrntkuetj@elstar.local> <> <> <20180322113912.brriajkiregcawdi@elstar.local>
From: Robert Wilton <>
Message-ID: <>
Date: Thu, 22 Mar 2018 15:03:07 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180322113912.brriajkiregcawdi@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [yang-doctors] 6991bis
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Mar 2018 15:03:17 -0000

Hi Juergen,

I agree that care is needed with floats/doubles, and I also agree that 
in many cases decimal64 is a better choice.  But that doesn't seem like 
a good argument to exclude them from the language entirely.

Performance wise, or modern hardware, floats/doubles are comparable to 
32/64 bit integers, and in some scenarios faster (e.g. divide operations).

I think that as YANG potentially extends to control/configure more 
devices than just network devices (e.g. servers, or as operators use 
YANG to model services and higher level abstractions, they will probably 
find the omission of floating point types to be somewhat frustrating).

But I can see that this is really a discussion for rather than 


On 22/03/2018 11:39, Juergen Schoenwaelder wrote:
> There was a long discussion during the design of YANG whether YANG
> should have floating point types and the outcome back then was it
> should not. I understand that some QoS standards do use floating point
> formats but in general networking stacks do prefer to not use floating
> point numbers - due to hardware constraints but also due to floating
> point numbers are fragile and easily "wrong" unless you are very
> careful with them. Unless you need to cover a huge range, types such
> as decimal64 are usually faster and much more precise.
> /js
> On Thu, Mar 22, 2018 at 11:16:13AM +0000, Robert Wilton wrote:
>> Not necessarily a discussion for here (and I've been told that it has
>> happened before), but Rob/Lou were discussing their desire to see IEEE float
>> (and presumably also IEEE double) types defined in YANG.
>> routing-types.yang (RFC 8294) defines bandwidth-ieee-float32, but ends up
>> using a string as the base type (fine for text based encoding schemes, not
>> so great for binary encoding schemes). Apparently OpenConfig have a similar
>> definition that ends up with binary as the base type, but that also has its
>> own problems.
>> Thanks,
>> Rob
>> On 22/03/2018 11:04, Reshad Rahman (rrahman) wrote:
>>> Date is the only definition I am aware of, I was expecting/hoping the more experienced YDs would have more.
>>> Regards,
>>> Reshad.
>>> On 2018-03-22, 11:01 AM, "Juergen Schoenwaelder" <> wrote:
>>>       On Thu, Mar 22, 2018 at 10:28:02AM +0000, Reshad Rahman (rrahman) wrote:
>>>       >
>>>       > On Tuesday we discussed adding a typedef for date to avoid modules having to define their own. Is it worth doing a bis document just for this? Are there more common YANG types which need to be added?
>>>       >
>>>       What we can do is to start a 6991bis I-D to collect new definitions
>>>       but pushing such a bis I-D through the whole process just for adding
>>>       'date' is likely too costly.
>>>       The last time we updated the common typedefs, the comments received
>>>       during IESG processing were mostly concerning definitions we did not
>>>       add or change, and this might happen again. Some of that was useful
>>>       since terminology is often becoming better defined but sometimes this
>>>       also leads to interesting alignment and compability issues. While
>>>       there are errata pointing to 'internal' (yang related) terminology
>>>       issues, it may be necessary to also carefully check alignment with
>>>       other terminology documents that are coming along, such as
>>>       draft-ietf-dnsop-terminology-bis-09.
>>>       Anyway, which other definitions have we seen commonly used that could
>>>       benefit from moving into 6991bis (and which are not covered by say
>>>       routing types)?
>>>       /js
>>>       --
>>>       Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>       Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>       Fax:   +49 421 200 3103         <>
>>> _______________________________________________
>>> yang-doctors mailing list