Is there any sound?
", "time": "2022-07-27T14:16:27Z"}, {"author": "Michael Hollyman", "text": "Video and Sound are both gone for me
", "time": "2022-07-27T14:16:49Z"}, {"author": "Doug Montgomery", "text": "Not for me audio in: 0kbps
", "time": "2022-07-27T14:16:52Z"}, {"author": "Kotikalapudi Sriram", "text": "yes, no sound or video
", "time": "2022-07-27T14:17:10Z"}, {"author": "Koen van Hove", "text": "I only see the slides, but no video or audio
", "time": "2022-07-27T14:17:15Z"}, {"author": "Jeffrey Haas", "text": "issue raised in room
", "time": "2022-07-27T14:17:18Z"}, {"author": "Lorenzo Miniero", "text": "Looking into this
", "time": "2022-07-27T14:17:20Z"}, {"author": "Mikhail Puzanov", "text": "no sound
", "time": "2022-07-27T14:17:35Z"}, {"author": "Keyur Patel", "text": "can u hear Chris?
", "time": "2022-07-27T14:17:52Z"}, {"author": "Mikhail Puzanov", "text": "I can hear, yes
", "time": "2022-07-27T14:18:20Z"}, {"author": "Jeffrey Haas", "text": "hopefully you have audio now.
", "time": "2022-07-27T14:18:23Z"}, {"author": "Koen van Hove", "text": "Yes
", "time": "2022-07-27T14:18:25Z"}, {"author": "Jeffrey Haas", "text": "ideally video will happen soon
", "time": "2022-07-27T14:18:46Z"}, {"author": "Koen van Hove", "text": "Video working
", "time": "2022-07-27T14:19:19Z"}, {"author": "Michael Hollyman", "text": "Dancing must have worked :)
", "time": "2022-07-27T14:19:20Z"}, {"author": "Alexander Azimov", "text": "Video++
", "time": "2022-07-27T14:19:22Z"}, {"author": "Koen van Hove", "text": "Just keep dancing :-)
", "time": "2022-07-27T14:19:28Z"}, {"author": "Chris Morrow", "text": ":)
", "time": "2022-07-27T14:19:57Z"}, {"author": "Nathalie Trenaman", "text": "Right, we're live :D
", "time": "2022-07-27T14:22:00Z"}, {"author": "Alexander Azimov", "text": "No slides at meetecho
", "time": "2022-07-27T14:30:54Z"}, {"author": "Koen van Hove", "text": "@Alexander we are currently on slide 9
", "time": "2022-07-27T14:31:12Z"}, {"author": "Alexander Azimov", "text": "I don't see any :( It was gone several slides ego
", "time": "2022-07-27T14:31:35Z"}, {"author": "Alexander Azimov", "text": "ok, page refresh hepled
", "time": "2022-07-27T14:32:11Z"}, {"author": "Christian Veenman", "text": "Slides are still visible to me on meetecho
", "time": "2022-07-27T14:32:13Z"}, {"author": "Christian Veenman", "text": "Check :)
", "time": "2022-07-27T14:32:16Z"}, {"author": "Ties de Kock", "text": "Sheets dropped in the room as well.
", "time": "2022-07-27T14:33:45Z"}, {"author": "Ties de Kock", "text": "And back.
", "time": "2022-07-27T14:33:52Z"}, {"author": "Nathalie Trenaman", "text": "aaaaaand gone :D
", "time": "2022-07-27T14:35:04Z"}, {"author": "Nathalie Trenaman", "text": "And Back...
", "time": "2022-07-27T14:35:16Z"}, {"author": "Warren Kumari", "text": "... and we think we know why... issues with Chris' laptop disconnecting and reconnecting from network.
", "time": "2022-07-27T14:40:10Z"}, {"author": "Warren Kumari", "text": "Going to see if Keyur can present instead...
", "time": "2022-07-27T14:40:48Z"}, {"author": "Keyur Patel", "text": "one more blip and I can take over. As of now its holding up?
", "time": "2022-07-27T14:41:33Z"}, {"author": "Warren Kumari", "text": "It will happen again - known issue with Linux and IPv6 on the wireless...
", "time": "2022-07-27T14:42:20Z"}, {"author": "Warren Kumari", "text": "Apologies all, chris is changing to a wired connection....
", "time": "2022-07-27T14:43:13Z"}, {"author": "Doug Montgomery", "text": "What is meant by a \"sticky\" RPKI object? Remains valid for a interval independent of its presence in the repositories?
", "time": "2022-07-27T14:45:12Z"}, {"author": "Rob Austein", "text": "Agreed that if we go this way we probably want new objects
", "time": "2022-07-27T14:45:35Z"}, {"author": "Chris Morrow", "text": "Tom is in the room and ready for slides/etc?
", "time": "2022-07-27T14:47:30Z"}, {"author": "Ties de Kock", "text": "Sticky RPKI objects or sticky behaviour in the RP.
", "time": "2022-07-27T14:48:09Z"}, {"author": "Rob Austein", "text": "Uh oh, he said \"heuristics\"
", "time": "2022-07-27T14:48:18Z"}, {"author": "Tom Harrison", "text": "yep
", "time": "2022-07-27T14:48:55Z"}, {"author": "Randy Bush", "text": "geoff making same point as ben. and they're correct.
", "time": "2022-07-27T14:49:32Z"}, {"author": "Alexander Azimov", "text": "++ to Geoff
", "time": "2022-07-27T14:49:34Z"}, {"author": "Doug Montgomery", "text": "Or as Igor noted, sticky in the BAR-SAV update algorithm.
", "time": "2022-07-27T14:50:03Z"}, {"author": "Ties de Kock", "text": "@Doug: And all sources have this risk of temporary unavailability, it feels like a candidate for a general mechanism
", "time": "2022-07-27T14:51:10Z"}, {"author": "Jeffrey Haas", "text": "The better point Geoff is partially making is that routing, as we have it in BGP, doesn't give us the full connectivity graph to let us solve this problem. We get only what bgp chooses to pass along.
", "time": "2022-07-27T14:51:16Z"}, {"author": "Nathalie Trenaman", "text": "Oh, yeas, gentle reminder: By default I will not incorporate your chat comments in the minutes. (The will be kept in a separate doc) If you explicitly want your comment recorded in the minutes, please go to the mic q.
", "time": "2022-07-27T14:51:26Z"}, {"author": "Jeffrey Haas", "text": "And thus supplementing routing state is all the hack we can do right now.
", "time": "2022-07-27T14:51:29Z"}, {"author": "Koen van Hove", "text": "If one were to keep \"sticky\" objects in the event a publication point is unavailable, then the question I have is whether it's feasible to sustain e.g. a DDoS attack for longer than that duration.
", "time": "2022-07-27T14:53:50Z"}, {"author": "Chris Morrow", "text": "Tom, do you want to share/drive your slides?
", "time": "2022-07-27T14:54:26Z"}, {"author": "Ties de Kock", "text": "@Koen: my view would be that stickiness is just needed to allow manual intervention
", "time": "2022-07-27T14:54:37Z"}, {"author": "Jeffrey Haas", "text": "Here's a core observation: when you're mitigating ddos, you want whatever tools can help you with the pain. Simply programming SAV as part of the mitigation dynamically is a reasonable tool.
", "time": "2022-07-27T14:54:55Z"}, {"author": "Christian Veenman", "text": "I think so as well. If it's sticky for a long enough time, manual intervention could take place, maybe to extend it or do something else
", "time": "2022-07-27T14:55:16Z"}, {"author": "Jeffrey Haas", "text": "So, rather than try to cover EVERYTHING by default, you can cover things that are safe for strict urpf by default (at edges) and then dynamically add stuff for mitigation purposes.
", "time": "2022-07-27T14:55:44Z"}, {"author": "Jeffrey Haas", "text": "but that tool basically comes down to \"is the source of this attack traffic coming from spoofed addresses or not?\" And thus you need the full matrix of discovery tools on a per-incoming-interface basis.
", "time": "2022-07-27T14:56:21Z"}, {"author": "Koen van Hove", "text": "@Jeffrey Haas That makes sense, but am I right in assuming that that is mainly when something is already happening, i.e. not in \"normal\" operation
", "time": "2022-07-27T14:57:03Z"}, {"author": "Jeffrey Haas", "text": "The issue is the cost. urpf on active forwarding state was a \"for free\" feature in terms of fib state capacity - just with additional lookup in forwarding
", "time": "2022-07-27T14:57:42Z"}, {"author": "Warren Kumari", "text": "<no hats> ... but if it doesn't work perfectly under all conditions (including the \"oh, yeah, that space isn't handled by BGP/ASPA/whatever\" is that stuff breaks, and people turn it off. This has to work perfectly under all cases, or the cure is worth than the disease </no hats>
", "time": "2022-07-27T14:57:45Z"}, {"author": "Jeffrey Haas", "text": "anything else as supplemental costs resources you probably don't want to spend by default.
", "time": "2022-07-27T14:57:59Z"}, {"author": "Ties de Kock", "text": "\"optimising for few support calls\"
", "time": "2022-07-27T14:58:17Z"}, {"author": "Jeffrey Haas", "text": "Warren, if you saw my recent talk at nanog on flowspec, you probably have a sense of my opinion there. :-)
", "time": "2022-07-27T14:58:43Z"}, {"author": "Chris Morrow", "text": "where is BAR/SAV appropriat to use? (at actal edge/stubs? in the core of the dfz? between where 'feasible'?)
\nCosts are drastically different, as is complexity in the choice you make above.
", "time": "2022-07-27T15:06:01Z"}, {"author": "Ties de Kock", "text": "There are ~500 rpki-client instances on nlnog-ring we see, that may influence this chart as well.
", "time": "2022-07-27T15:06:37Z"}, {"author": "Chris Morrow", "text": "i'd argue that: \"unless you are talking about the stub/edge\" the cost and complexity is 'very high'.
\nAnd at the stub/edge you don't need a 'new' feature, you just need to turn on uRPF strict. (that LAN port can only source the configured address blocks as sources)
", "time": "2022-07-27T15:07:26Z"}, {"author": "Kotikalapudi Sriram", "text": "Ben/Keyur: Any Update that travels sideways peer-to-peer within the customer cone of interest and moves upward to be seen at the AS performing SAV - that is a route leak and BARSAV has effectively built-in checks to reject such prefixes by using ASPA data. RFC 9234 also drops such route leaks and helps BARSAV.
", "time": "2022-07-27T15:07:42Z"}, {"author": "Warren Kumari", "text": "@Chris: Or, even, \"I haz 3 prefixes, and I can write an ACL\", no URPF magic needed..
", "time": "2022-07-27T15:08:32Z"}, {"author": "Rob Austein", "text": "Can hear Tim, not Chris
", "time": "2022-07-27T15:08:54Z"}, {"author": "Chris Morrow", "text": "warren, yes - of course 'somtimes bespoke acls are hard' to do across the board.. but yes, there is already a solution here, that really is straight forward... and lives at the 'correct' place in the stack.
", "time": "2022-07-27T15:10:38Z"}, {"author": "Ben Maddison", "text": "@Kotikalapudi Sriram you assume the two policy graphs are the same, this is not necessarily true. trivial example being the \"upstream only\" transit customer
", "time": "2022-07-27T15:10:41Z"}, {"author": "Job Snijders", "text": "I understand researchers would love to see rpki-client version numbers, but the trade-off in which such information then also is volunteered to potential adversaries doesn't seem favorable. Ports of the rpki-client implementation are kept up-to-date and distributed through common package repositories such as EPEL, HomeBrew, Debian/APT, FreeBSD ports, etc; my hope (and expectation) is that operators use unattended-upgrades to pull in updates in a timely fashion.
@Chris: Yup. My point was that much of the edge is \"simple\", and if they won't do a 3 line acl, or strict urpf, I cannot see why we think that they would be willing to do something \"magic\" for source address stuff.
", "time": "2022-07-27T15:12:41Z"}, {"author": "Koen van Hove", "text": "You can distill the version for rpki-client somewhat, as newer versions (7.5 and above I believe, might have also been 7.4) send the \"Accept-Encoding: identity\" header instead of the \"Accept-Encoding: gzip\" header.
", "time": "2022-07-27T15:13:24Z"}, {"author": "Chris Morrow", "text": "warren: yes, exzctly.
", "time": "2022-07-27T15:13:27Z"}, {"author": "Christian Veenman", "text": "@Ben Would the \"upsteam only\" case mean that the origin of a prefix (for which to do SAV) in question would not be in the computed customer cone (using ROAs and ASPA)? Or am I misunderstanding something?
", "time": "2022-07-27T15:13:39Z"}, {"author": "Jeffrey Haas", "text": "Effectively, for urpf, if you could implement bcp 38 - do it. But since people aren't doing it, some networks want to do it by proxy a few hops away.
", "time": "2022-07-27T15:13:55Z"}, {"author": "Jeffrey Haas", "text": "The 15% number basically tells you a number of parties that could do it simply don't.
", "time": "2022-07-27T15:14:18Z"}, {"author": "Ben Maddison", "text": "Christian Veenman said:
\n\n\n@Ben Would the \"upsteam only\" case mean that the origin of a prefix (for which to do SAV) in question would not be in the computed customer cone (using ROAs and ASPA)? Or am I misunderstanding something?
\n
Yes, exactly
", "time": "2022-07-27T15:14:32Z"}, {"author": "Warren Kumari", "text": "@Job: Maybe, but from looking at the same argument for DNS servers -- attackers generally will just send all attacks at all servers. It's easier to send an attack and hope that it works than to check implementation & version, choose right attack, send attack, etc.
", "time": "2022-07-27T15:14:59Z"}, {"author": "Randy Bush", "text": "@warren: that is exacly what i see. it's easier to use a bomb than a rifle
", "time": "2022-07-27T15:15:43Z"}, {"author": "Warren Kumari", "text": "Perhaps if you are trying to be stealthy.. but, generally attackers have a throw away host, and just spew attacks... Yah.
", "time": "2022-07-27T15:15:51Z"}, {"author": "Rob Austein", "text": "Yep
", "time": "2022-07-27T15:16:00Z"}, {"author": "Ties de Kock", "text": "..and a competent attack may still be able to differentiate behaviour based on heuristics.
", "time": "2022-07-27T15:16:11Z"}, {"author": "Kotikalapudi Sriram", "text": "@Chris@Warren: A good review of scenarios where ACL, strict uRPF etc. work fine is available in RFC 8704.
", "time": "2022-07-27T15:16:29Z"}, {"author": "Jeffrey Haas", "text": "Observations from my job 12 years ago is that when you can't get your attack through with spoofing, you just stop bothering with spoofing.
", "time": "2022-07-27T15:16:44Z"}, {"author": "Randy Bush", "text": "strict urpf is a notorious failure.
", "time": "2022-07-27T15:16:54Z"}, {"author": "Rob Austein", "text": "AIA has always had to be only informational because of this rollover problem, which has existed since day one
", "time": "2022-07-27T15:17:06Z"}, {"author": "Chris Morrow", "text": "randy: \"in the core\"
", "time": "2022-07-27T15:17:08Z"}, {"author": "Jeffrey Haas", "text": "^
", "time": "2022-07-27T15:17:19Z"}, {"author": "Randy Bush", "text": "the edge does not need uprf; they just need to not forward packets not from their own prefixes.
", "time": "2022-07-27T15:18:18Z"}, {"author": "Job Snijders", "text": "AIA is also used for discovery in some cases, for instance it makes RSC validation easier
", "time": "2022-07-27T15:18:43Z"}, {"author": "Randy Bush", "text": "btw, fwiw, tim's preso is very supportable
", "time": "2022-07-27T15:18:52Z"}, {"author": "Rob Austein", "text": "It's fine to use AIA for discovery, that's why we kept it. But we concluded a long time ago in RP interop testing that you can't use it as a validation check (ie, you can't reject just because it doesn't match) because otherwise you can never roll keys. Tim was at that table in the terminal room however many years ago that was :)
", "time": "2022-07-27T15:19:45Z"}, {"author": "Job Snijders", "text": "yes
", "time": "2022-07-27T15:20:18Z"}, {"author": "Chris Morrow", "text": "randy: the 'do not forward' can either be: \"do an acl\" or \"do urpf strict\"
", "time": "2022-07-27T15:20:22Z"}, {"author": "Randy Bush", "text": "@chris: and which of those requires less of the router?
", "time": "2022-07-27T15:21:00Z"}, {"author": "Jeffrey Haas", "text": "In many forwarding asics, urpf is cheaper than filtering. The equation morphs somewhat on edge devices.
", "time": "2022-07-27T15:21:36Z"}, {"author": "Chris Morrow", "text": "they are kinda the same, really..
\nI think it's a trade off for: \"one line and done\" vs \"now I have ot config every interface spcially... \"
Strict uRPF gets tricky for people to debug -- I recently had an issue with a friend's enterprise who was doing uRPF and then built a GRE tunnel to a remote office. Suddenly the best route to the prefix was not the same as the one from the prefix, and they had much confusion and sad. Of course, their \"router\" was provided by ISP, and so they had no idea that it was doing magic. Anyway, I suspect I've found a rathole / soapbox.
", "time": "2022-07-27T15:22:10Z"}, {"author": "Randy Bush", "text": "i need to focus on this preso because i care
", "time": "2022-07-27T15:22:31Z"}, {"author": "Chris Morrow", "text": "but I think th eoverall point is:
\n \"If you do this at the edge it's very simple, if you attempt to do this away from the edge it gets progressively harder, more complex and more .... ineffective\"
^
", "time": "2022-07-27T15:23:07Z"}, {"author": "Jeffrey Haas", "text": "rfc 8704 applies more spackle. Spackle is not structural.
", "time": "2022-07-27T15:23:26Z"}, {"author": "Warren Kumari", "text": "Someone wants to contact Alexander about his cars warrantee
", "time": "2022-07-27T15:23:41Z"}, {"author": "Randy Bush", "text": "rpki-rtr was written independently of this discussion
", "time": "2022-07-27T15:26:38Z"}, {"author": "Ties de Kock", "text": "@Randy Bush what format matches best with rpki-rtr? Because that will be probably very close to the data visible on the routers
", "time": "2022-07-27T15:27:36Z"}, {"author": "Randy Bush", "text": "-07
", "time": "2022-07-27T15:27:52Z"}, {"author": "Rob Austein", "text": "I am extremely uncomfortable with requiring transit on different AFIs to be the same path when we damned well know that sometimes they are not. Maybe I misunderstood the question.
", "time": "2022-07-27T15:28:02Z"}, {"author": "Randy Bush", "text": "is there an operator in this room who has routers which use multi-protocol bgp? all the routers i have ever known separated v4 and v6 bgp sessions.
", "time": "2022-07-27T15:29:19Z"}, {"author": "Rob Austein", "text": "I do not seem to have a working microphone today so not joining mike queue with above (\"extremely uncomfortable\") comment
", "time": "2022-07-27T15:30:52Z"}, {"author": "Warren Kumari", "text": "Shall I relay?
", "time": "2022-07-27T15:31:49Z"}, {"author": "Rob Austein", "text": "Please
", "time": "2022-07-27T15:31:56Z"}, {"author": "Job Snijders", "text": "I wonder whether people will work on a rfc6482bis to split out IPv4 and IPv6 into separate Content-Types (ROA4 and ROA6) Signed Objects? :-)
", "time": "2022-07-27T15:32:28Z"}, {"author": "Warren Kumari", "text": "Sorry for standing at mic. Old habits die had. Sitting down till my turn....
", "time": "2022-07-27T15:35:00Z"}, {"author": "Ties de Kock", "text": "But prefixes are always v4 or v6, so you can not have duplication of information there? Next to omitting the AFI (=> If omitted, the authorization is valid for both IPv4 and IPv6 announcements). You can still have explicit information for v4 or v6 in the object.
", "time": "2022-07-27T15:36:10Z"}, {"author": "Chris Morrow", "text": "Robot Randy is not understandable
", "time": "2022-07-27T15:37:01Z"}, {"author": "Koen van Hove", "text": "Is it only my audio glitching?
", "time": "2022-07-27T15:37:01Z"}, {"author": "Job Snijders", "text": "The microphone is broken @Randy Bush you sound like a robot
", "time": "2022-07-27T15:37:03Z"}, {"author": "Christian Veenman", "text": "Sound suddenly going back here
", "time": "2022-07-27T15:37:04Z"}, {"author": "Geoff Huston", "text": "YOu are highly distorted Randy
", "time": "2022-07-27T15:37:06Z"}, {"author": "Warren Kumari", "text": "RANDY: Your audio broken.
", "time": "2022-07-27T15:37:09Z"}, {"author": "Warren Kumari", "text": "Try toggling mute?
", "time": "2022-07-27T15:37:23Z"}, {"author": "Job Snijders", "text": "It is entirely inaudible
", "time": "2022-07-27T15:37:25Z"}, {"author": "Christian Veenman", "text": "bad*
", "time": "2022-07-27T15:37:27Z"}, {"author": "Randy Bush", "text": "gimme a sec
", "time": "2022-07-27T15:37:34Z"}, {"author": "Warren Kumari", "text": "Never seen that failure before...
", "time": "2022-07-27T15:37:48Z"}, {"author": "Jeffrey Haas", "text": "Professor Hawking's voice plugin failure.
", "time": "2022-07-27T15:38:16Z"}, {"author": "Randy Bush", "text": "mic fixed i hope
", "time": "2022-07-27T15:39:06Z"}, {"author": "Koen van Hove", "text": "Regarding compressing data: are there any estimates regarding how much data is used/saved (in absolute/relative terms)?
", "time": "2022-07-27T15:39:08Z"}, {"author": "Job Snijders", "text": "There are ~ 80,000 ASNs in the default freezone. With -07 that translates to 160,000 objects (assuming maximum deployment), with -08 it translates to 80K objects.
", "time": "2022-07-27T15:40:16Z"}, {"author": "Rob Austein", "text": "Real measurement? Not that I know of. Seat of the pants: everything but manifests and CRLs tends to be pretty small, and keys dominate over payload.
", "time": "2022-07-27T15:40:24Z"}, {"author": "Job Snijders", "text": "yeah, only 38 bytes of the 1763 bytes are the actual payload (called \"eContent\" or \"Encapsulated Content\") in the example ASA object in Tim's testbed
", "time": "2022-07-27T15:43:09Z"}, {"author": "Koen van Hove", "text": "So that's ~160 MB as opposed to ~320 MB?
", "time": "2022-07-27T15:43:25Z"}, {"author": "Randy Bush", "text": "excuse me if i do not worry if it will fit in 640k
", "time": "2022-07-27T15:44:16Z"}, {"author": "Alexander Azimov", "text": "\n\nThere are ~ 80,000 ASNs in the default freezone. With -07 that translates to 160,000 objects (assuming maximum deployment), with -08 it translates to 80K objects.
\n
Is it a problem?
", "time": "2022-07-27T15:44:25Z"}, {"author": "Ties de Kock", "text": "There is also an intermediate solution, not having \"no afilimit means 4+6\" but have v4+v6 in the object explicitly.
", "time": "2022-07-27T15:44:35Z"}, {"author": "Jeffrey Haas", "text": "The on the wire format for rpki-rtr has some implications on the receiver. Not comparing vs. current proposal, but by analogy original multi-protocol bgp had a safi for unicast, multicast, and unicast+multicast. the U+M use cases introduced a huge numbers of ambiguities and the choice was eventually to remove it to clear that up.
", "time": "2022-07-27T15:44:46Z"}, {"author": "Jeffrey Haas", "text": "The short form of the issue is if you advertised U+M, what is your withdraw procedure if you withdraw anything besides U+M?
", "time": "2022-07-27T15:45:30Z"}, {"author": "Ties de Kock", "text": "@Jeff: RPKI will generally atomically (from an RP's perspective) replace the complete object with a new one. So the withdraw is possible.
", "time": "2022-07-27T15:46:10Z"}, {"author": "Jeffrey Haas", "text": "The goal, imo, is simple rpki-rtr receive code. We have a historic impact of such things. I'd suggest the simpler format.
", "time": "2022-07-27T15:46:49Z"}, {"author": "Job Snijders", "text": "Keep in mind we are not talking about RTR, but about ASN.1 notation of the X509 objects
", "time": "2022-07-27T15:47:09Z"}, {"author": "Jeffrey Haas", "text": "Understood. But object format had a possibility of bleeding into the protocol at some point.
", "time": "2022-07-27T15:47:35Z"}, {"author": "Jeffrey Haas", "text": "I know that's not (currently) under debate.
", "time": "2022-07-27T15:47:46Z"}, {"author": "Job Snijders", "text": "I think statements about simplicity/complexity are somewhat subjective in nature, unfortunately we don't have a good way to measure it.
", "time": "2022-07-27T15:49:09Z"}, {"author": "Jeffrey Haas", "text": "That's what they said about safi 3 too. :-)
", "time": "2022-07-27T15:50:09Z"}, {"author": "Chris Morrow", "text": "there are very real measures of code complexity, or did you mean something else?
", "time": "2022-07-27T15:52:12Z"}, {"author": "Jeffrey Haas", "text": "I'll wait for sriram to comment before jumping in queue.
", "time": "2022-07-27T15:52:35Z"}, {"author": "Koen van Hove", "text": "Loud and clear
", "time": "2022-07-27T15:52:46Z"}, {"author": "Chris Morrow", "text": "note: \"6 mins remains in meeting\"
", "time": "2022-07-27T15:54:24Z"}, {"author": "Jeffrey Haas", "text": "To possibly bypass need for mic, \"what is the fate of deprecate-as-set?\" A: I have owed Sriram text for some time.
", "time": "2022-07-27T15:56:17Z"}, {"author": "Jeffrey Haas", "text": "The two main items in need of work is proper text to do surgery on RFC 4271, and secondarily to add a rpki-origin friendly version of as-path aggregation procedures.
", "time": "2022-07-27T15:57:11Z"}, {"author": "Jeffrey Haas", "text": "To repeat a comment from one of sriram's first presentations: it doesn't matter if you deprecate or not. rpki features such as the one being discussed for aspa, effectively is killing the feature by killing the routes that have a set.
", "time": "2022-07-27T15:58:31Z"}, {"author": "Ben Maddison", "text": "yes, agreed
", "time": "2022-07-27T15:59:28Z"}, {"author": "Chris Morrow", "text": "zero minuts left.
", "time": "2022-07-27T16:00:17Z"}, {"author": "Chris Morrow", "text": "room is going to eject all callers shortly.
", "time": "2022-07-27T16:00:32Z"}, {"author": "Jeffrey Haas", "text": "You can have a set, if you want to. But if your friends don't accept sets, and you send sets, then they're no peers of thine.
", "time": "2022-07-27T16:01:01Z"}]