Hi Acee, > Can you guys indicate how you would like to see this comment reflected in the > draft? Are you suggesting to change he encoding to 64 bits for the new > bandwidth sub-TLVs? There's a float-32, a float-64, and a float-128. I think 32 bits is adequate. All you need to change is to add the citations. Adrian > On Dec 12, 2014, at 1:16 PM, Adrian Farrel <adrian@xxxxxxxxxxxx> wrote: > > > 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. > >>>> > >>>> > >>>> > >>> > >