RE: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt> (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard

["Adrian Farrel" <[e-mail]>]

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:[e-mail]]
> Sent: 12 December 2014 18:14
> To: t.p.
> Cc: [e-mail];
[e-mail];
> [e-mail]
> 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. <[e-mail]> 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" <[e-mail]>
> > To: <[e-mail]>
> > Cc: <[e-mail]>; <[e-mail]>
> > 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.
> >>
> >>
> >>
> >