[netmod] Impact of changing an import statement on YANG versioning (https://github.com/netmod-wg/yang-ver-dt/issues/4)

[Reshad Rahman (rrahman)]

Hi,

We’ve been having discussions on the impact of changing an import statement and 
would like to get thoughts from the WG.

Consider module A which imports module B.

  1.  Module A revision 1.0.0 has “revision-or-derived 1.0.0” for import of 
module B.
import moduleB {
  rev:revision-or-derived 1.0.0;
}
  2.  An update to module A so that it needs to import at least 2.0.0 of module 
B
import moduleB {
  rev:revision-or-derived 2.0.0;
}

When module’s A import is updated in step b, we’ve discussed 3 options:

  1.  Always consider the change as BC (new revision 1.1.0 for module A) and 
let the client figure out the impact on its use of module A
  2.  Always consider the change as NBC (new revision 2.0.0 for module A, tag 
the import as NBC using nbc-change extension) and let the client figure out the 
impact on its use of module A
  3.  Handle this conditionally. So if the impact on module A is NBC (depending 
on whether module A’s namespace has been impacted in NBC way),  do as in 2 
(this can have ripple effect on importing module hierarchy, e.g. module C uses 
module A, module D uses module C etc). If the impact on module A is BC, do as 
in 1

Regards,
Reshad.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Ladislav Lhotka]

On 07. 07. 20 16:40, David Spakes wrote:
> Like Lada, I know nothing about geo-location formats.  But this
> discussion sounds familiar because it keeps coming up time and
> again.  There are arguments for and against decimal64, and people
> have before expressed a need for a variable-precision type.
> 
> I proposed the following compromise/solution in 2009 and again in 2014.
> Now, I'll propose it again: a derived type that solidifies the
> position/preservation of decimal64 and builds on it to deliver the
> desired feature.

This type might be much more useful if the effective union member could
be determined from the data. It is often important to differentiate
between 1.23 and 1.230, but this wouldn't be possible here, due to the
canonical form for "decimal64" (sec. 9.3.2 in RFC 7950).

Lada

> 
> 
>    typedef real {
>  type union {
>    type decimal64 {
>  fraction-digits 18;
>  range "-0.99 .. 0.99";
>    }
>    type decimal64 {
>  fraction-digits 17;
>  range "-9.9 .. 9.9";
>    }
>    type decimal64 {
>  fraction-digits 16;
>  range "-99. .. 99.";
>    }
>    type decimal64 {
>  fraction-digits 15;
>  range "-999.999 .. 999.999";
>    }
>    type decimal64 {
>  fraction-digits 14;
>  range "-.99 .. .99";
>    }
>    type decimal64 {
>  fraction-digits 13;
>  range "-9.9 .. 9.9";
>    }
>    type decimal64 {
>  fraction-digits 12;
>  range "-99. .. 99.";
>    }
>    type decimal64 {
>  fraction-digits 11;
>  range "-999.999 .. 999.999";
>    }
>    type decimal64 {
>  fraction-digits 10;
>  range "-.99 .. .99";
>    }
>    type decimal64 {
>  fraction-digits 9;
>  range "-9.9 .. 9.9";
>    }
>    type decimal64 {
>  fraction-digits 8;
>  range "-99. .. 99.";
>    }
>    type decimal64 {
>  fraction-digits 7;
>  range "-999.999 .. 999.999";
>    }
>    type decimal64 {
>  fraction-digits 6;
>  range "-.99 .. .99";
>    }
>    type decimal64 {
>  fraction-digits 5;
>  range "-9.9 .. 9.9";
>    }
>    type decimal64 {
>  fraction-digits 4;
>  range "-99. .. 99.";
>    }
>    type decimal64 {
>  fraction-digits 3;
>  range "-999.999 .. 999.999";
>    }
>    type decimal64 {
>  fraction-digits 2;
>  range "-.99 .. .99";
>    }
>    type decimal64 {
>  fraction-digits 1;
>  range "-9.9 .. 9.9";
>    }
>    type enumeration {
>  enum overflow;
>  enum underflow;
>    }
>  }
>  description
>    "The real type defines a large, finite set of real numbers with
>     varying degrees of magnitude and precision.  An object of type
>     real is able to express configuration and state data as any of
>     the real numbers in the set.  The real type is suitable for
>     applications that deal with ratios in which the decimal point is
>     not fixed to a single position.
> 
>     Positive numbers larger than 9.9 in state data
>     SHALL be represented as an overflow.  The enumerated value
>     overflow is not valid for an  operation.
> 
>     Negative numbers larger than -9.9 in state data
>     SHALL be represented as an underflow.  The enumerated value
>     underflow is not valid for an  operation.
> 
>     Real numbers between -9.9 and 9.9
>     (inclusive) having a combination of magnitude and precision that
>     falls outside of one of the range substatements in the union--
>     including irrational numbers such as 'pi'--may only be
>     represented by the real type through rounding or truncation.
>     For example, pi could be rounded (up) to 3.14159265358979324 or
>     truncated to 3.14159265358979323 to preserve as much of the
>     precision information as possible.  Note that an application
>     could choose to round (down) the value of pi to 3.14 or truncate
>     the value of pi to 3.14.  This specification does not define
>     rules for the rounding or truncating of such values, considering
>     these decisions to be application-specific.";

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[David Spakes]

Like Lada, I know nothing about geo-location formats.  But this
discussion sounds familiar because it keeps coming up time and
again.  There are arguments for and against decimal64, and people
have before expressed a need for a variable-precision type.

I proposed the following compromise/solution in 2009 and again in 2014.
Now, I'll propose it again: a derived type that solidifies the
position/preservation of decimal64 and builds on it to deliver the
desired feature.


   typedef real {
 type union {
   type decimal64 {
 fraction-digits 18;
 range "-0.99 .. 0.99";
   }
   type decimal64 {
 fraction-digits 17;
 range "-9.9 .. 9.9";
   }
   type decimal64 {
 fraction-digits 16;
 range "-99. .. 99.";
   }
   type decimal64 {
 fraction-digits 15;
 range "-999.999 .. 999.999";
   }
   type decimal64 {
 fraction-digits 14;
 range "-.99 .. .99";
   }
   type decimal64 {
 fraction-digits 13;
 range "-9.9 .. 9.9";
   }
   type decimal64 {
 fraction-digits 12;
 range "-99. .. 99.";
   }
   type decimal64 {
 fraction-digits 11;
 range "-999.999 .. 999.999";
   }
   type decimal64 {
 fraction-digits 10;
 range "-.99 .. .99";
   }
   type decimal64 {
 fraction-digits 9;
 range "-9.9 .. 9.9";
   }
   type decimal64 {
 fraction-digits 8;
 range "-99. .. 99.";
   }
   type decimal64 {
 fraction-digits 7;
 range "-999.999 .. 999.999";
   }
   type decimal64 {
 fraction-digits 6;
 range "-.99 .. .99";
   }
   type decimal64 {
 fraction-digits 5;
 range "-9.9 .. 9.9";
   }
   type decimal64 {
 fraction-digits 4;
 range "-99. .. 99.";
   }
   type decimal64 {
 fraction-digits 3;
 range "-999.999 .. 999.999";
   }
   type decimal64 {
 fraction-digits 2;
 range "-.99 .. .99";
   }
   type decimal64 {
 fraction-digits 1;
 range "-9.9 .. 9.9";
   }
   type enumeration {
 enum overflow;
 enum underflow;
   }
 }
 description
   "The real type defines a large, finite set of real numbers with
varying degrees of magnitude and precision.  An object of type
real is able to express configuration and state data as any of
the real numbers in the set.  The real type is suitable for
applications that deal with ratios in which the decimal point is
not fixed to a single position.

Positive numbers larger than 9.9 in state data
SHALL be represented as an overflow.  The enumerated value
overflow is not valid for an  operation.

Negative numbers larger than -9.9 in state data
SHALL be represented as an underflow.  The enumerated value
underflow is not valid for an  operation.

Real numbers between -9.9 and 9.9
(inclusive) having a combination of magnitude and precision that
falls outside of one of the range substatements in the union--
including irrational numbers such as 'pi'--may only be
represented by the real type through rounding or truncation.
For example, pi could be rounded (up) to 3.14159265358979324 or
truncated to 3.14159265358979323 to preserve as much of the
precision information as possible.  Note that an application
could choose to round (down) the value of pi to 3.14 or truncate
the value of pi to 3.14.  This specification does not define
rules for the rounding or truncating of such values, considering
these decisions to be application-specific.";
   }



David Spakes



On Tue, Jul 07, 2020 at 08:27:19AM -0400, Christian Hopps wrote:


Mentioned in the earlier mail

instead of

"decimal64"

use

"type string { pattern '[0-9]+(\.[0-9]+)?'; }"




On Tue, 7 Jul 2020, Ladislav Lhotka wrote:


On 07. 07. 20 13:24, Juergen Schoenwaelder wrote:

Precision often means different things to different people. Here is my
take:

- Floating point numbers have almost always rounding errors. And
  floating point numbers use binary fractions, a decimal fraction like
  1.0 has no precise 

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Juergen Schoenwaelder]

On Tue, Jul 07, 2020 at 04:24:03PM +0200, Ladislav Lhotka wrote:
> 
> > ASN.1 had INTEGER, a type of unlimited precision. In the early SNMP
> > days things started to fail to interoperate when you hit the 16-bit
> > limit. JSON (much newer) has numbers that start to become interesting
> > when you need more precision, a simple 64-bit counter starts falls
> > apart in JSON.
> 
> If you mean "counter64" in the ietf-yang-types module, then it doesn't
> fall apart in JSON, provided that the rules of RFC 7951 are followed.
>

I was alluding to plain JSON where you encode a number as a number
until you realize that some numbers must be encoded as strings to
avoid surprises. RFC 7951 does this for YANG defined data.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Ladislav Lhotka]

On 07. 07. 20 15:57, Juergen Schoenwaelder wrote:
> On Tue, Jul 07, 2020 at 09:24:31AM -0400, Christian Hopps wrote:
>>
>> I dislike having to specify arbitrary limits b/c of the type. I think it 
>> would be useful to have integer and real number support that allowed for 
>> specifying "at least" precision, but not forcing the model to specify an "at 
>> most".
>>
> 
> You can have defined limits or undefined limits with implementation
> specific limits (only rarely you find implementations that de-facto
> have no limits).
> 
>> In generally I dislike many of the specified semantic restrictions I
>> find in YANG models, they seem to be the most oft-cited examples of
>> when a "backward incompatible" change might need to be made to a
>> model.
>  
> ASN.1 had INTEGER, a type of unlimited precision. In the early SNMP
> days things started to fail to interoperate when you hit the 16-bit
> limit. JSON (much newer) has numbers that start to become interesting
> when you need more precision, a simple 64-bit counter starts falls
> apart in JSON.

If you mean "counter64" in the ietf-yang-types module, then it doesn't
fall apart in JSON, provided that the rules of RFC 7951 are followed.

Lada

> 
> I can't tell how many of the "backward incompatible" changes are due
> to picking too restrictive types.
> 
> /js
> 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Juergen Schoenwaelder]

On Tue, Jul 07, 2020 at 09:24:31AM -0400, Christian Hopps wrote:
> 
> I dislike having to specify arbitrary limits b/c of the type. I think it 
> would be useful to have integer and real number support that allowed for 
> specifying "at least" precision, but not forcing the model to specify an "at 
> most".
>

You can have defined limits or undefined limits with implementation
specific limits (only rarely you find implementations that de-facto
have no limits).

> In generally I dislike many of the specified semantic restrictions I
> find in YANG models, they seem to be the most oft-cited examples of
> when a "backward incompatible" change might need to be made to a
> model.
 
ASN.1 had INTEGER, a type of unlimited precision. In the early SNMP
days things started to fail to interoperate when you hit the 16-bit
limit. JSON (much newer) has numbers that start to become interesting
when you need more precision, a simple 64-bit counter starts falls
apart in JSON.

I can't tell how many of the "backward incompatible" changes are due
to picking too restrictive types.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Christian Hopps]

> On Jul 7, 2020, at 8:30 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Tue, Jul 07, 2020 at 08:27:19AM -0400, Christian Hopps wrote:
>> 
>> Mentioned in the earlier mail
>> 
>> instead of
>> 
>>"decimal64"
>> 
>> use
>> 
>>"type string { pattern '[0-9]+(\.[0-9]+)?'; }"
>> 
> 
> And then everybody implements what he/she likes? That would be a big
> step backward since every implementation will then interpret the
> numbers differently.

I dislike having to specify arbitrary limits b/c of the type. I think it would 
be useful to have integer and real number support that allowed for specifying 
"at least" precision, but not forcing the model to specify an "at most".

In generally I dislike many of the specified semantic restrictions I find in 
YANG models, they seem to be the most oft-cited examples of when a "backward 
incompatible" change might need to be made to a model.

BTW, I think decimal64 is fine for this use-case, I mainly asked on the list 
b/c I'm curious about the more general use-case.

Thanks,
Chris.

> 
> /js
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Juergen Schoenwaelder]

On Tue, Jul 07, 2020 at 08:27:19AM -0400, Christian Hopps wrote:
> 
> Mentioned in the earlier mail
> 
> instead of
> 
> "decimal64"
> 
> use
> 
> "type string { pattern '[0-9]+(\.[0-9]+)?'; }"
> 

And then everybody implements what he/she likes? That would be a big
step backward since every implementation will then interpret the
numbers differently.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Christian Hopps]

> On Jul 7, 2020, at 8:18 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Tue, Jul 07, 2020 at 07:53:19AM -0400, Christian Hopps wrote:
>> 
>> So do you think it's enough to just use decimal64, and not justify it's use 
>> over strings?
> 
> I do not know what 'strings' are here.

Mentioned in the earlier mail

instead of

"decimal64"

use

"type string { pattern '[0-9]+(\.[0-9]+)?'; }"

> In the xml and json encodings, everything finally has a string
> representation. But what matters is how the strings are interpreted
> since computers internally often do not use strings when it comes to
> numbers or addresses or ...

But they can operate with arbitrarily precise numbers (e.g., python mpmath, or 
even decimal with some arbitrarily large precision specified).

Thanks,
Chris.

> 
> /js
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Juergen Schoenwaelder]

On Tue, Jul 07, 2020 at 07:53:19AM -0400, Christian Hopps wrote:
> 
> So do you think it's enough to just use decimal64, and not justify it's use 
> over strings?

I do not know what 'strings' are here.

In the xml and json encodings, everything finally has a string
representation. But what matters is how the strings are interpreted
since computers internally often do not use strings when it comes to
numbers or addresses or ...

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Christian Hopps]

> On Jul 7, 2020, at 7:24 AM, Juergen Schoenwaelder 
>  wrote:
> 
> Precision often means different things to different people. Here is my
> take:
> 
> - Floating point numbers have almost always rounding errors. And
>  floating point numbers use binary fractions, a decimal fraction like
>  1.0 has no precise representation as a binary fraction. Type 0.1 +
>  0.2 into python or haskell or any other language that gives you bare
>  floating point numbers and enjoy the result.
> 
> - Fixed precision decimal numbers do not have rounding errors since
>  they are essentially scaled integers and hence they are precise as
>  long as calculations stay within the range.
> 
> - Floating point numbers can cover a large number space (from very
>  tiny to really big), fixed precision decimal numbers are much more
>  restrictive.
> 
> - In XML and JSON, numbers are rendered in strings that likely do not
>  look much different if its a decimal64 or a float or ... If you really
>  care about size, use a binary encoding like CBOR.

So do you think it's enough to just use decimal64, and not justify it's use 
over strings? I don't necessarily think we need to talk to it in the document, 
but it was raised in the review so I figured some discussion on the list was at 
least merited.

While I haven't done any binary stuff with YANG, I think it's definitely usable 
that way (e.g., to define binary APIs in software where you probably wouldn't 
want to be using XML or JSON).

Thanks,
Chris.


> 
> /js
> 
> On Tue, Jul 07, 2020 at 07:06:20AM -0400, Christian Hopps wrote:
>> I received feedback in my YANG doctor review (thanks Mahesh) regarding the 
>> use of decimal64 for most of the values in the geo location grouping 
>> (https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04). In my 
>> comparison sections I note that some precision (at the very extremes) may be 
>> lost when converting from other geo location formats that use string (or 
>> double for w3c) to decimal64. Given that mention of loss of extreme 
>> precision, the reviewer was asking if some justification for the decimal64 
>> should be given in the document.
>> 
>> What are the advantages to using decimal64 for floating point numbers vs 
>> using a string with a pattern "[0-9]+(\.[0-9]+)?" (convert that to yang 
>> pattern language). The advantage of using a string is that the precision of 
>> the value is not restricted by the model. Does the YANG decimal64 values 
>> have a concise binary format that can be more efficiently transported or 
>> stored in binary form? If so is this the only advantage, and is it enough of 
>> one to limit the precision in the model?
>> 
>> It's definitely worth noting that the precision of the decimal64 values seem 
>> vastly adequate for geo location data (e.g., for Cartesian coordinates and 
>> height values which are measured in meters the fractional digits is 6 which 
>> means the surface could be up to 9 billion kilometers large (or away from 
>> for height) and the precision is to the micrometer. For ellipsoidal 
>> coordinates there are 12 fractional digits for the degrees.
>> 
>> Thanks,
>> Chris.
> 
> 
> 
>> ___
>> 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 
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Ladislav Lhotka]

On 07. 07. 20 13:24, Juergen Schoenwaelder wrote:
> Precision often means different things to different people. Here is my
> take:
> 
> - Floating point numbers have almost always rounding errors. And
>   floating point numbers use binary fractions, a decimal fraction like
>   1.0 has no precise representation as a binary fraction. Type 0.1 +
>   0.2 into python or haskell or any other language that gives you bare
>   floating point numbers and enjoy the result.
> 
> - Fixed precision decimal numbers do not have rounding errors since
>   they are essentially scaled integers and hence they are precise as
>   long as calculations stay within the range.
> 
> - Floating point numbers can cover a large number space (from very
>   tiny to really big), fixed precision decimal numbers are much more
>   restrictive.
> 
> - In XML and JSON, numbers are rendered in strings that likely do not
>   look much different if its a decimal64 or a float or ... If you really
>   care about size, use a binary encoding like CBOR.

I know nothing about geo-location formats, but I suspect that the string
representation is based on some assumptions regarding the underlying
numeric type. So one option might be to define a new type derived from
"string", and specify these assumptions in the description.

Lada

> 
> /js
> 
> On Tue, Jul 07, 2020 at 07:06:20AM -0400, Christian Hopps wrote:
>> I received feedback in my YANG doctor review (thanks Mahesh) regarding the 
>> use of decimal64 for most of the values in the geo location grouping 
>> (https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04). In my 
>> comparison sections I note that some precision (at the very extremes) may be 
>> lost when converting from other geo location formats that use string (or 
>> double for w3c) to decimal64. Given that mention of loss of extreme 
>> precision, the reviewer was asking if some justification for the decimal64 
>> should be given in the document.
>>
>> What are the advantages to using decimal64 for floating point numbers vs 
>> using a string with a pattern "[0-9]+(\.[0-9]+)?" (convert that to yang 
>> pattern language). The advantage of using a string is that the precision of 
>> the value is not restricted by the model. Does the YANG decimal64 values 
>> have a concise binary format that can be more efficiently transported or 
>> stored in binary form? If so is this the only advantage, and is it enough of 
>> one to limit the precision in the model?
>>
>> It's definitely worth noting that the precision of the decimal64 values seem 
>> vastly adequate for geo location data (e.g., for Cartesian coordinates and 
>> height values which are measured in meters the fractional digits is 6 which 
>> means the surface could be up to 9 billion kilometers large (or away from 
>> for height) and the precision is to the micrometer. For ellipsoidal 
>> coordinates there are 12 fractional digits for the degrees.
>>
>> Thanks,
>> Chris.
> 
> 
> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Juergen Schoenwaelder]

Precision often means different things to different people. Here is my
take:

- Floating point numbers have almost always rounding errors. And
  floating point numbers use binary fractions, a decimal fraction like
  1.0 has no precise representation as a binary fraction. Type 0.1 +
  0.2 into python or haskell or any other language that gives you bare
  floating point numbers and enjoy the result.

- Fixed precision decimal numbers do not have rounding errors since
  they are essentially scaled integers and hence they are precise as
  long as calculations stay within the range.

- Floating point numbers can cover a large number space (from very
  tiny to really big), fixed precision decimal numbers are much more
  restrictive.

- In XML and JSON, numbers are rendered in strings that likely do not
  look much different if its a decimal64 or a float or ... If you really
  care about size, use a binary encoding like CBOR.

/js

On Tue, Jul 07, 2020 at 07:06:20AM -0400, Christian Hopps wrote:
> I received feedback in my YANG doctor review (thanks Mahesh) regarding the 
> use of decimal64 for most of the values in the geo location grouping 
> (https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04). In my 
> comparison sections I note that some precision (at the very extremes) may be 
> lost when converting from other geo location formats that use string (or 
> double for w3c) to decimal64. Given that mention of loss of extreme 
> precision, the reviewer was asking if some justification for the decimal64 
> should be given in the document.
> 
> What are the advantages to using decimal64 for floating point numbers vs 
> using a string with a pattern "[0-9]+(\.[0-9]+)?" (convert that to yang 
> pattern language). The advantage of using a string is that the precision of 
> the value is not restricted by the model. Does the YANG decimal64 values have 
> a concise binary format that can be more efficiently transported or stored in 
> binary form? If so is this the only advantage, and is it enough of one to 
> limit the precision in the model?
> 
> It's definitely worth noting that the precision of the decimal64 values seem 
> vastly adequate for geo location data (e.g., for Cartesian coordinates and 
> height values which are measured in meters the fractional digits is 6 which 
> means the surface could be up to 9 billion kilometers large (or away from for 
> height) and the precision is to the micrometer. For ellipsoidal coordinates 
> there are 12 fractional digits for the degrees.
> 
> Thanks,
> Chris.



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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Justification for decimal64 over string for floating point values in geo location data?

[Christian Hopps]

I received feedback in my YANG doctor review (thanks Mahesh) regarding the use 
of decimal64 for most of the values in the geo location grouping 
(https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04). In my 
comparison sections I note that some precision (at the very extremes) may be 
lost when converting from other geo location formats that use string (or double 
for w3c) to decimal64. Given that mention of loss of extreme precision, the 
reviewer was asking if some justification for the decimal64 should be given in 
the document.

What are the advantages to using decimal64 for floating point numbers vs using 
a string with a pattern "[0-9]+(\.[0-9]+)?" (convert that to yang pattern 
language). The advantage of using a string is that the precision of the value 
is not restricted by the model. Does the YANG decimal64 values have a concise 
binary format that can be more efficiently transported or stored in binary 
form? If so is this the only advantage, and is it enough of one to limit the 
precision in the model?

It's definitely worth noting that the precision of the decimal64 values seem 
vastly adequate for geo location data (e.g., for Cartesian coordinates and 
height values which are measured in meters the fractional digits is 6 which 
means the surface could be up to 9 billion kilometers large (or away from for 
height) and the precision is to the micrometer. For ellipsoidal coordinates 
there are 12 fractional digits for the degrees.

Thanks,
Chris.


signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod