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