Good catch Tom,
Acee, the trick is to go to 6340 and look in the references :-)
[IEEE.754.2008] Institute of Electrical and Electronics Engineers,
"Standard for Floating-Point Arithmetic",
IEEE Standard 754, August 2008.
A
> -----Original Message-----
> From: Acee Lindem (acee) [mailto:acee@xxxxxxxxx]
> Sent: 12 December 2014 18:14
> To: t.p.
> Cc: adrian@xxxxxxxxxxxx;
draft-ietf-ospf-te-metric-extensions.all@xxxxxxxxxxxxxx;
> ietf@xxxxxxxx
> Subject: Re: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt> (OSPF
Traffic
> Engineering (TE) Metric Extensions) to Proposed Standard
>
> Hi Tom,
>
> On Dec 12, 2014, at 1:08 PM, t.p. <daedulus@xxxxxxxxxxxxx> wrote:
>
> > On the question of Floating-Point, there is now 754-2008, which is a
> > tighter spec and is used in RFC6340.
>
> What is 754-2008?
>
> Thanks,
> Acee
>
>
>
> >
> > At a tangent, the issue of floating-point support has surfaced a number
> > of times in YANG and, to date, has always been rejected, reckoning that
> > suppport for 64-bit decimal is adequate for data modelling. The
> > interactions with XPath (which is used as a basis for YANG constraint
> > statements), where floating-point is allowed, have caused a number of
> > discussions, some ongoing, about the comparison of a floating-point
> > number to a 64-bit decimal one. Something to be aware of should you ever
> > want to model this in YANG.
> >
> > Tom Petch
> >
> >
> > ----- Original Message -----
> > From: "Adrian Farrel" <adrian@xxxxxxxxxxxx>
> > To: <draft-ietf-ospf-te-metric-extensions.all@xxxxxxxxxxxxxx>
> > Cc: <ospf@xxxxxxxx>; <ietf@xxxxxxxx>
> > Sent: Wednesday, December 10, 2014 11:07 PM
> >
> >> All,
> >>
> >> I reviewed this document as AD and found a few small points that I
> > have asked
> >> the authors to address as IETF last call comments.
> >>
> >> Adrian
> >>
> >> ===
> >>
> >> Please look for places where you have "proposed" something and change
> >> that to "defined".
> >>
> >> ---
> >>
> >> It would be good to include a reference for encoding floating point
> >> integers. The usual is (I think)...
> >>
> >> IEEE, "IEEE Standard for Binary Floating-Point Arithmetic",
> >> Standard 754-1985, 1985 (ISBN 1-5593-7653-8).
> >>
> >> ---
> >>
> >> Section 4.2.5
> >>
> >> Implementations MAY also permit the configuration of a static (non
> >> dynamic) offset value (in microseconds) to be added to the measured
> >> delay value, to facilitate the communication of operator specific
> >> delay constraints.
> >>
> >> On the third reading I got it! I'm slow (I have a high delay :-)
> >>
> >> The point here is that the measured value and the static value are
> > added
> >> together and the sum is transmitted in this field. I'd suggest...
> >>
> >> Implementations MAY also permit the configuration of a static (non
> >> dynamic) offset value (in microseconds) to be added to the measured
> >
> >> delay value before encoding into this TLV, to facilitate the
> >> communication of operator specific delay constraints.
> >>
> >> Similarly in 4.2.6.
> >>
> >> ---
> >>
> >> 4.2.7 appears out of sequence. But since it repeats the content of
> >> 4.2.4 I suggest you merge them and talk about the plurality of fields.
> >>
> >> ---
> >>
> >> Section 7
> >>
> >> "Sections 6 and 7 provide" should be 5 and 6.
> >>
> >> ---
> >>
> >> Section 10
> >>
> >> "As per (RFC3630), unrecognized TLVs should be silently ignored"
> >>
> >> There has been confusion about what 3630 means by "silently ignored".
> >> In particular, some enthusiastic implementations thought this meant
> > the
> >> TLVs should be stripped from the LSA before it is propagated. I think
> > it
> >> is worth the few words to explicitly state that this is not the case.
> >>
> >> ---
> >>
> >> Section 13
> >>
> >> RFC 4203 is used in a normative way, please move it to the other
> >> section.
> >>
> >>
> >>
> >