Re: [Last-Call] Artart last call review of draft-ietf-sidrops-rfc6482bis-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Jim,

Thank you for taking the time to review this document!

On Mon, Oct 16, 2023 at 10:12:05PM -0700, Jim Fenton via Datatracker wrote:
> Reviewer: Jim Fenton
> Review result: Ready with Nits
> 
> I'm the assigned ARTART reviewer for this draft. I have little prior
> familiarity with RPKI and ROAs but have a few broader comments.
> 
> 1. idnits found several issues with the draft. 16 lines are too long,
> which caused them to be cut off on the rendering I read, most
> importantly in the ROA formal definition in Section 4. [RFC6268] is
> referenced at line 180, and needs to be included as a reference.

I added a normative reference to RFC6268.

> 2. Section 4.3.2 says that ROAIPAddress contains IPAddress elements
> while (if I'm reading the definition correctly) it contains BIT STRING
> elements. RFC 6482 defined an IPAddress element as a BIT STRING but
> that definition was removed; perhaps the text didn't keep up with
> that.

I think the 'BIT STRING' you are looking for is present via the
'ROAIPAddress' -> 'address' definition. Previously the 'BIT STRING' was
an unconstrained definition, in this -bis document its bounded by the
maximum possible length which is dependent on whether the contained
address is IPv4 or IPv6, done like this 'BIT STRING (SIZE(0..len))'. 

> 3. RFC 4291 may be a normative reference due to the MUST NOT in Section 4.3.1.

I moved the RFC4291 reference from the informative to the normative
reference section.

> 4. I couldn't understand how to do the comparison in Sections 4.3.3
> and 4.3.3.1. Specifically, what is the precedence between
> afi/addr/plen/mlen? It seems like that might be the order, but I don't
> see it specified anywhere (other than perhaps in the example
> implementations, which are informative).

I am not 100% sure what exactly you are looking for. I don't think the
order in which to test the equivalence of the afi/addr/plen/mlen data
elements matters. Can you please elaborate?

> Otherwise, the document is clear and well-written.

Thank you, i queued up the changes here:
https://github.com/job/draft-rfc6482bis/commit/07a6644aa19f55d56124ef528f6e5b60fc14dd89

Kind regards,

Job

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux