[{"author": "Job Snijders", "text": "

Minutes here https://notes.ietf.org/notes-ietf-118-sidrops

", "time": "2023-11-10T14:34:00Z"}, {"author": "Chris Morrow", "text": "

1) aspa through successful lastcall
\n2) fix up 8210 to accommodate that
\n3) put 8210 through lastcall

", "time": "2023-11-10T14:34:54Z"}, {"author": "Jeffrey Haas", "text": "

I disagree with job about not permitting prefix length variations

", "time": "2023-11-10T14:57:06Z"}, {"author": "Jeffrey Haas", "text": "

Efficiency for rib reevaluation from rpki rtr is one of the reasons to permit other than exact length records in the database

", "time": "2023-11-10T15:04:31Z"}, {"author": "Doug Montgomery", "text": "

We have that terminology problem through out the history of SIDR. We needed correction RFCs to explain \"drop, reject, etc\" was really keep and mark as ineligible for selection as best path.

", "time": "2023-11-10T15:04:52Z"}, {"author": "Doug Montgomery", "text": "

Will SLURM need to be updated for prefix lists?

", "time": "2023-11-10T15:06:14Z"}, {"author": "Jeffrey Haas", "text": "

Use bgp normative terms. Ask idr for help with a lexicon if needed

", "time": "2023-11-10T15:06:19Z"}, {"author": "Doug Montgomery", "text": "

\"ineligible\" RFC4271 section 9.1.1

", "time": "2023-11-10T15:08:33Z"}, {"author": "Job Snijders", "text": "

@Jeffrey Haas how we encode in ASN.1 on the wire, and how the RTR PDU is constructed & packed is separate things.

", "time": "2023-11-10T15:20:41Z"}, {"author": "Jeffrey Haas", "text": "

But strongly related.

\n

The audio stream is unlistenable from my current location. I\u2019ll have to respond you session discussion in more detail when I can review it later.

", "time": "2023-11-10T15:22:53Z"}, {"author": "Ties de Kock", "text": "

We have seen users create ROAs for a very dense set of /48's within a /32. Making a _sparse_ set of prefixes explicit is OK, making a _dense_ set of prefixes explicit in a ROA is less elegant.

", "time": "2023-11-10T15:26:07Z"}, {"author": "Ties de Kock", "text": "

This probably could be made more elegant. But to my knowledge it is not a significant problem at the moment

", "time": "2023-11-10T15:26:43Z"}, {"author": "Chris Morrow", "text": "

'elegant' meaning what?

", "time": "2023-11-10T15:32:34Z"}, {"author": "Ties de Kock", "text": "
\n

'elegant' meaning what?

\n
\n

A more compact encoding. Or use more options during encoding. Right now it is all additive, some scenario's you can probably describe better when you can subtract from what is authorised as well.

", "time": "2023-11-10T15:35:58Z"}, {"author": "Randy Bush", "text": "

ii want an anti-ROA!!!

", "time": "2023-11-10T15:37:12Z"}, {"author": "Ties de Kock", "text": "

I can see the cases where it is a more efficient encoding. [Yet] As a CA operator, I do not see the need [at the moment]

", "time": "2023-11-10T15:37:44Z"}, {"author": "Job Snijders", "text": "

RPKI Prefixlist is a working group document; at this point in time I personally think the current flat list is the most elegant approach - but I'm happy to review proposals that make the encoding more efficient provided we can get there without sacrificing our kidneys for complexity.

", "time": "2023-11-10T15:38:28Z"}, {"author": "Ties de Kock", "text": "

(I was talking about ROAs)

", "time": "2023-11-10T15:38:40Z"}, {"author": "Chris Morrow", "text": "

ah... I mean you COULD do something like randy's anti-roa, but you COULD also publish chunks of a /32 as: /40 -> /48 ASN0

\n

with subnet holes as /48 exact (for instance) for proper Origin.

\n

I don't think that's actually better though. (still have to publish the exact end-site ROA)

", "time": "2023-11-10T15:40:39Z"}, {"author": "Doug Montgomery", "text": "

Question for Carlos / LACNIC - if you permit an organization with a re-assigned/re-allocated address block from a provider, without creating a new ResCert for that specific sub-block, do you limit the range of prefixes that customer could create through UI/APIs? The aggregate cert would permit broader ROAs.

", "time": "2023-11-10T15:51:09Z"}, {"author": "Chris Morrow", "text": "

the roa count as a problem I dont' really understand I guess.

\n

no human is thinking / remembnering / etc these things, robots do, and robots have craploads of memory.

\n

and databases understand how to keep track/index items of interest.

", "time": "2023-11-10T15:55:23Z"}, {"author": "Chris Morrow", "text": "

so the conversation is that 'robots do not have databases' which I think is also false.

", "time": "2023-11-10T15:57:27Z"}, {"author": "Randy Bush", "text": "

but do they dream of electric certificates?

", "time": "2023-11-10T15:58:13Z"}, {"author": "Chris Morrow", "text": "

this is also a fair question.. we don't want them doing the wrong thing, so we have protections... tests.

", "time": "2023-11-10T15:58:44Z"}]