A Profile for Route Origin Authorizations (ROAs)
draft-ietf-sidrops-rfc6482bis-09

Thank you for the work on this document.

Many thanks to Jim Fenton for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/woc94KH6VzpJs4sQpo5IuvTDZPc/.

There was some discussion of SHOULD vs. MUST in the context of this document, and a preference for SHOULD in order not to immediately render older implementations invalid or to support backward compatibility.  I'm sympathetic to this position, but in such situations I would prefer that we be explicit that this is the only "out" allowed by the SHOULD.  Otherwise, we are technically allowing new implementations of the old way to claim compliance.

I agree with the other ADs that mentioned the SHOULD -> MUST

** Section 4.  Editorial.  

OLD
A ROA is formally defined as

NEW
A ROA is formally defined in an ASN.1 module [X.680] as:

** Section 4.3.3

   In order to produce
   and verify this canonical form, the process described in this section
   SHOULD be used to ensure information elements are unique with respect
   to one another and sorted in ascending order.

Why are these canonicalization procedures not mandatory?  Shouldn’t s/SHOULD/MUST/?

# Éric Vyncke, INT AD, comments for draft-ietf-sidrops-rfc6482bis-08

Thank you for the work put into this document. ROA are indeed critical for the security and stability of the Internet. As usual for a -bis document, I reviewed only the diffs.

Please find below 2 non-blocking COMMENT points.

Special thanks to Chris Morrow for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status. 

Other thanks to Haoyu Song, the Internet directorate reviewer (at my request), please consider this int-dir review (even for just a nit):
https://datatracker.ietf.org/doc/review-ietf-sidrops-rfc6482bis-07-intdir-telechat-song-2023-11-01/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## IPv6 Examples

No need to reply, but I regret that this I-D only uses IPv4 examples in the normative part in 2023... The IPv6 example in appendix B is a nice one though.

## Section 4.3.2.2

When can an operator deviate from the SHOULD in `The maxLength element SHOULD NOT be encoded if the maximum length is equal to the prefix length.` ? I.e., why is it not a MUST ?

Thanks for this document.  I found it clear and easy to understand.

Regards,
Rob