Re: [ippm] Benjamin Kaduk's No Objection on draft-ietf-ippm-ioam-data-16: (with COMMENT)

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Ben,

Once more: Thanks a lot for your comments!

We've just posted a new revision of draft-ietf-ippm-ioam-data (https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-17).

Revision -17 avoids the discussion of leap seconds for any of the timestamp formats that IOAM uses. Per what you inspired in your note below, this makes the timestamp related sections consistent - and it avoids duplicating the original standards. The discussion of leap seconds was beyond the scope of what draft-ietf-ippm-ioam-data is focused on, given that draft-ietf-ippm-ioam-data is to specify the data fields for IOAM. draft-ietf-ippm-ioam-data isn't to specify how the content of the timestamp fields is created. That is clearly the job of the specs that define the different formats.  Hope that things are clean now.

Thanks again.

Cheers, Frank

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <[e-mail]>
> Sent: Wednesday, 8 December 2021 23:39
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Al Morton <[e-mail]>; [e-mail]
> Subject: Benjamin Kaduk's No Objection on draft-ietf-ippm-ioam-data-16: (with
> COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-ippm-ioam-data-16: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Many thanks for the many updates in the -16, and my apologies for the delay in
> reballoting.
> 
> I'm happy to report that the changes all look good to me, but do have one
> comment that seems to remain valid:  In Section 6.3 where we discuss the
> POSIX-based timestamp format, I think we do need to say that it is affected by
> leap seconds (analogously to how we do for the NTP format), per the guidance
> in RFC 8877.  I see in the email thread that there was some desire to defer to
> 8877 rather than try to reproduce a lot of it here (and inevitably end up with an
> incomplete treatment); in that case, perhaps the Section 6.2 discussion should
> be trimmed so that we provide an analogous level of detail on all three
> timestamp formats.
> 
>