On Thu, Nov 02, 2023 at 09:04:19PM +0100, Jim Fenton wrote: > >> 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))'. > > The size bound on the ROAIPAddress is a good enhancement. But in RFC > 6482, there was an element explicitly defined called IPAddress which > was defined as a BIT STRING. But in this draft, I find no element > named IPAddress, and I’m concerned with the fact that the text in Sec. > 4.3.1 refers to IPAddress. Ah, I see what you mean! The IPAddress Type is defined in section 2.2.3.8 of RFC 3779 (which is referenced in the next section, section 4.3.2.1 of draft-ietf-sidrops-rfc6482bis-07) At the time of writing 4.3.2 was intended as a high level introduction, with each subsection providing more technical detail. Do you have suggestions to adhere to the princple 'explain on first use'? (which I assume you are after?) > >> 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? > > Made up example: Suppose two entries have the same plen and mlen. > Entry A has a lower afi and entry B has a lower addr. Which comes > first? Comparator step 1 is "Data elements with a lower afi value precede data elements with a higher afi value", therefor in your made-up example Entry A would come first. It seems you see benefit in emphasizing that the numbered list is the actual order dictating the precedence in the (currently non-existent) preamble leading up to the numbered list in section 4.3.3.1 Should I add a sentence like "The below numbered list signifies the order of precedence for comparator implementations" ? Kind regards, Job -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
