Re: [Sidrops] WGLC - draft-ietf-sidrops-rfc6482bis - ENDS: July 17, 2023 (07/17/2023)

[Christopher Morrow <[e-mail]>]

On Sat, Jul 22, 2023 at 11:41 AM Tim Bruijnzeels <[e-mail]> wrote:
>
> Hi
>
> > On 21 Jul 2023, at 22:56, Christopher Morrow <[e-mail]> wrote:
> >
> >>
> >> All ROA’s are republished “regularly” (on average a yearly cycle).
> >>
> >> However to get this implemented you would need the installed base of CA software
> >> to be updated, then wait for this rollover to happen. If I recall there was nor
> >> threat being mitigated here --- I would not do a flag day "to practice" if this
> >> is for aesthetic reasons.
> >
> > seems fair, yes I agree you'd want to delay until all publishers were updated.
> > that's a relatively small field of software and actually a relatively
> > small field of users.
> >
> > This is some of the same argument about making v6 changes ~15 yrs
> > back: "vast install base!!"
> > :)
> >
> > My point in bringing this up was REALLY:
> >  1) if this is causing code complexity and possible mishandling of
> > data we should fix it sooner rather than later.
> >  2) if there is nothing here but 'ugh I need to test this so I have
> > to sort both before compares!' - ok, cool... err, that's light duty as
> > a problem
> >
> > Ties sounds like they say: "Meh, there is not a PROBLEM, just a
> > nice-to-have perhaps"
>
> As a CA implementer... I have no objection to adding ordering when encoding in a future release if it helps some RP implementations.
>
> But I will need a better description of what order to use. I get that RFC 3779 orders by start addresses and puts IPv4 before IPv6. But in this case, there can be multiple prefixes with the same start address, e.g. if both 10.0.0.0/20 and 10.0.0.0/24 are present. It needs to be clear what the tiebreaker is (shorter prefix first or last?).
>

understood.

> >> Also, I like order, but is it a 'nice to have' (makes testing and such
> >> simpler) or:
> >> "boy for reason x, y, z this is actually important there's a ton of
> >> complex code to
> >>  handle this unordered list and the tech-debit over time would be
> >> nice to clean up!"
> >>
> >>
> >> In my implementation this check _caused_ additional complexity because of the
> >> check that had to be implemented.
> >
> > :) ok.
> >
> > So, 1 person says: "meh, not important".
>
>
> I think it's out of scope for this -bis.
>

oh sure, I did something I often do (and have yet to learn NOT to do)
I asked a question and ended up conflating 2 things :(
sorry about that.

> Or well... there could be a RECOMMENDED or KINDLY ASKED ;) to order, but if the objective would be to start rejecting unordered ROAs then this is a breaking change. That needs a clearly formulated plan - even if, in this case, we may be able to avoid a version increase because the actual object encoding is not changed. I don't think we can do this as part of the LC of this document. Perhaps a separate document would work, or LC is cancelled for now, and we take the time to discuss.
>
> Speaking for myself on the time to discuss... I had a few moments to reply today, but I won't have time to really think this all through until late August.
>
>
> Tim