On the question of Floating-Point, there is now 754-2008, which is a tighter spec and is used in RFC6340. 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. > > >