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

[Brian Haberman <[e-mail]>]

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.

>> 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?

Regards,
Brian