Re: [Int-dir] Intdir early review of draft-ietf-bier-ping-08

[Greg Mirsky <[e-mail]>]

Hi Brian,
thank you for your thorough review and helpful feedback. Please find my
notes below, tagged GIM2>>.

Regards,
Greg

On Wed, May 10, 2023 at 12:08 PM Brian Haberman <[e-mail]>
wrote:

> Hi Greg,
>        Most of these changes look good. Just a few minor follow-ups...
>
> On 5/8/23 12:17 PM, Greg Mirsky wrote:
> > Hi Brian,
> > and again, thank you for your review, helpful comments, and questions. I
> > reworked the IANA Considerations section throughout. Please review the
> new
> > working version or diff and let me know if the updates are satisfactory
> and
> > address your concerns. Also, answers to your questions are inline below
> > under the GIM>> tag. The new version of the draft
> > <https://datatracker.ietf.org/doc/draft-ietf-bier-ping/> also includes
> > updates addressing comments from Rtg and Sec areas.
> > Please let me know what you think.
> >
> > Regards,
> > Greg
> >
> > On Fri, Apr 14, 2023 at 3:36 PM Brian Haberman via Datatracker <
> > [e-mail]> wrote:
> >
> >> Reviewer: Brian Haberman
> >> Review result: Almost Ready
> >>
> >> I am an assigned INT directorate reviewer for
> draft-ietf-bier-ping-08.txt.
> >> These comments were written primarily for the benefit of the Internet
> Area
> >> Directors. Document editors and shepherd(s) should treat these comments
> >> just
> >> like they would treat comments from any other IETF contributors and
> resolve
> >> them along with any other Last Call comments that have been received.
> For
> >> more
> >> details on the INT Directorate, see
> >> https://datatracker.ietf.org/group/intdir/about/
> >> <https://datatracker.ietf.org/group/intdir/about/>.
> >>
> >> Based on my review, the document IS NOT ready to go to IETF Last Call
> and
> >> therefore CANNOT be forwarded to the IESG
> >>
> >> There are a number of issues that I think should be addressed before
> >> advancing
> >> this document...
> >>
> >> 1. IANA Considerations - The draft calls out in section 5 the creation
> of a
> >> registry and three sub-registries without giving any guidance on how
> those
> >> registries should be managed, per RFC 8126. It is also unclear is
> section
> >> 5.3
> >> is calling for the creation of an IANA registry or not.
> >>
>
> The new section 5 is mostly good in my mind...
>
>   * The subsections under Sec 5.4 seem to have an inconsistency in what
> is stated in the allocation policy and what is documented in the tables
> that will serve as the initial entries. For example, 5.4.1 says "5 - 175
> IETF Review", but the table says "3 - 175". I believe "3 - 175" is the
> correct range.
>
GIM2>> Thank you for catching this. You are correct, the table is the
primary source. Fixed.

>
> >> 2. Section 3.1
> >>
> >>      * It is unclear if the two header formats described here both
> occur in
> >> a
> >>      transmitted frame or if the second header format is a modified
> version
> >> of
> >>      the first header. If it is the former, it seems odd to have to
> >> duplicate
> >>      versions, message type, protocol, and reserved fields.
> >>
> > GIM>> Thank you for pointing that out. Indeed, these are the same. I've
> > updated the figures. Please let me know if it helped to make the text
> > clearer.
> >
> >>
> >>       * Is there a requirement that the timestamp formats be the same in
> >> both
> >>       the Echo Request and the Echo Reply? If not, is there a
> requirement
> >> that
> >>       BFRs MUST support both formats?
> >>
> > GIM>> A good question. I believe that there is no requirement for the
> > Sender and Responder to use the same timestamp format, as the format used
> > can be explicitly indicated for each actor separately. As a result, a BFR
> > can support one format or both. The decision of which one to use may be
> > based on the comparison of the accuracy of the timestamp each method
> > provides.
> >
>
> Any concerns with routers not supporting/recognizing all specified
> timestamp formats?
>
GIM2>> RFC 8877  <https://datatracker.ietf.org/doc/rfc8877/>provides an
excellent analysis of timestamp formats being used in known networking
protocols:

   - NTPv4 64-Bit Timestamp Format (RFC 5905)
   - NTPv4  32-Bit Timestamp Format (RFC 5905)
   - The PTPv2 64-Bit Truncated Timestamp Format

It seems like the situation where a networking system doesn't support
either NTPv4 or PTPv2 format is highly unlikely. WDYT?

>
> Regards,
> Brian
>