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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 08 Dec 2021 14:38:59 -0800

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.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 13 Dec 2021 13:29:36 +0000

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 <[email-masked]>
> Sent: Wednesday, 8 December 2021 23:39
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Al Morton <[email-masked]>; [email-masked]
> Subject: Benjamin Kaduk's No Objection on draft-ietf-ippm-ioam-data-16: (with
> COMMENT)
> 
> 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.)
> 
> 
> 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.
> 
>