Subject: [yang-doctors] 6991bis

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 22 Mar 2018 10:28:02 +0000

Hi,

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?

Regards,
Reshad.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Mar 2018 12:00:52 +0100

> 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 adde…

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         <https://www.jacobs-university.de/>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 22 Mar 2018 11:04:06 +0000

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" <[email-masked]> wrote:

    

    /js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 22 Mar 2018 11:16:13 +0000

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:
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Mar 2018 12:39:12 +0100

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:
> 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
> 
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 22 Mar 2018 15:03:07 +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 YANG.next rather than 
6991bis.

Thanks,
Rob