Hi Charlie, Gotcha. That sounds okay.
Cheers, Tal. On Mon, Feb 11, 2019 at 4:14 PM Charlie Perkins < [email protected]> wrote: > Hello Tal and all, > > I thought it would be better to make the length fields count nibbles > instead of octets, since we don't have EXP any more. A 4-bit length field > then allows up to 64 bits precision, which should be enough for most > purposes. > > Do you think that would be O.K.? > > Regards, > Charlie P. > > > On 2/11/2019 5:13 AM, Tal Mizrahi wrote: > > Hi Charlie, > > Thanks for reviewing the packet timestamp draft. > > Your suggestion makes sense to me. > > Just a minor question regarding your example below ("If we had a 12-bit > timestamp format..."): > The DTL and OTL fields specify the length of the DT and OT fields in > octets, and therefore the length of DT and OT is a multiple of 8 bits. So > the DT and OT can't be 12 bits long, right? > > Cheers, > Tal. > > On Sat, Feb 9, 2019 at 4:25 AM Charlie Perkins < > [email protected]> wrote: > >> Hello Tal and all, >> >> I have read draft-ietf-ntp-packet-timestamps-05.txt. This is an >> excellent document. >> >> Our previous timestamp format in draft-ietf-6lo-deadline-time-03.txt >> offers a lot of flexibility in a compact format, but maybe that much >> flexibility is not needed. I would like to suggest that we use the >> timestamp template in draft-ietf-ntp-packet-timestamps-05.txt, but with >> possibly fewer bits than the 32-bit NTP format. As I understand it, that >> format divides the available number of bits evenly between integral seconds >> and fractional seconds. So, for instance, if we had an 8-bit timestamp >> format, that would allow for 16 seconds total duration denominated in >> sixteenths of a second (i.e., time units of about 64 milliseconds). That >> would be pretty good for most purposes. If we had a 12-bit timestamp >> format, that would allow for 64 seconds denominated in units of >> approximately 16 milliseconds. If the optional Origination Time is >> included, then we would mandate that the OT has the same time unit as the >> DT. In this case, that translates to meaning that the number of bits for >> fractional seconds is the same, but we could allow the OT to have fewer >> bits for the integer number of seconds. >> >> If we go this way with predefined time designations according to the NTP >> draft format, we don't need the Exp field. It is also possible that an >> asymmetric number of bits would be considered to satisfy the specified >> NTP-related format (i.e., not the same number of bits for fractional >> seconds as for integer seconds). In that case, we could use a new field to >> locate the binary point. We can make the definitions so that this new >> information still fits within the space of the Deadline-6LoRHE format. One >> could argue that this new field is analogous to the Exp field. >> >> draft-ietf-ntp-packet-timestamps-05.txt mandates certain details in the >> Security Considerations which we will need to obey. It also suggests >> inclusion of material about synchronization. I think we also have to do >> consider doing that. >> >> What do you think? >> >> Regards, >> Charlie P. >> On 1/3/2019 5:02 AM, Tal Mizrahi wrote: >> >> Hi Suresh, authors, >> >> >> I would suggest to follow the timestamp specification template of >> Section >> >> 3 in draft-ietf-ntp-packet-timestamps-05. >> >> >I think the semantics of the DT and OT fields are a bit different from >> the >> >NTP packet timestamps and there are also resource constraints in the >> >6lo world that might make the 64 bit formats expensive. I will let the >> >authors and the WG comment further on this. >> >> >> I agree that the NTP timestamp format does not fit here. >> My comment was that DT and OT should be defined according to the >> timestamp specification template (section 3 in the packet timestamp draft). >> This is a *generic template* for defining all kinds of timestamp formats. >> The template was defined in order to make sure that when you define a >> timestamp format you do not forget important details. >> Just to clarify, I am not suggesting to change the timestamp formats of >> DT and OT, but only to specify them in a clear and unambiguous manner. >> >> Thanks, >> Tal. >> >> >> >> >> On Wed, Jan 2, 2019 at 11:00 PM Suresh Krishnan <[email protected]> >> wrote: >> >>> Hi Tal, >>> >>> On Dec 23, 2018, at 3:49 AM, Tal Mizrahi <[email protected]> >>> wrote: >>> >>> Hi, >>> >>> I am not a 6lo native, but I reviewed the draft specifically from a >>> timestamp formatting perspective. >>> In the NTP working group we currently have a draft in WGLC that presents >>> guidelines for defining timestamp formats. >>> https://tools.ietf.org/html/draft-ietf-ntp-packet-timestamps-05 >>> >>> I believe that the definitions of the timestamps (DT and OT) >>> in draft-ietf-6lo-deadline-time should be more detailed. For example, >>> aspects about the epoch and the potential effect of leap seconds are >>> currently not described in the current draft. >>> >>> >>> Good point. Authors, can you add some further descriptive text around >>> these fields. >>> >>> I would suggest to follow the timestamp specification template of >>> Section 3 in draft-ietf-ntp-packet-timestamps-05. >>> >>> >>> I think the semantics of the DT and OT fields are a bit different from >>> the NTP packet timestamps and there are also resource constraints in the >>> 6lo world that might make the 64 bit formats expensive. I will let the >>> authors and the WG comment further on this. >>> >>> Thanks >>> Suresh >>> >>> > _______________________________________________ > 6lo mailing [email protected]https://www.ietf.org/mailman/listinfo/6lo > >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
