Jabber scribe: Job Snijders
Minute taker: Nathalie Trenaman
Full session:

Chris Morrow
Keyur Patel

0) Agenda bashing and Chair's slides - [5 minutes]

1) Tim Bruijnzeels - [15 minutes]

2) Randy Bush - [10 minutes]

3) Alexander Azimov - [10 minutes]

3) Randy Bush - [10 minutes]

4) Di Ma - [10 minutes]

5) Di Ma - [10 minutes]
Distributing RPKI Validated Cache in JSON over HTTPS

6) Oliver Borchert - [15 minutes]


Tim Bruijnzeels 
Geoff Huston: rsync was a mistake from the beginning. Problem is reliable flooding of information. I'm not sure if RRDP is the solution. Are we not replacing one bad thing with another? Are there alternatives that do reliable flooding? This doesn't seem to change a lot;
Tim: At this moment supporting rsync is impacting people
Ruediger: I oppose using BGP for flooding. Maybe reseach groups can look into alternatives. We need to have a roadmap to move forward. The repositories have to move first, but Relying Parties can't be left behind. A fixed timeschedule will not work. 
Di Ma: I like your idea, I'm wondering if you think it is easy to support delta protocol.
Tim: I think the tricky part is generating the files. I agree with Ruediger, we should build operational experience. RIPE NCC has extensive experience with RRDP
Di Ma: Delta is working much better than rsynch in our testbed
Randy: Is there another sequense that doesn't drop things on the floor?
Tim: I want RP software to move forward. A roadmap might get outdated in an RFC. 
Job: It is good if IETF, in a BCP, writes down that rsync is not preferred. State why we don't like rsync for this purpose.
Rob: The problem to completely remove rsync, is hashes. Our CA code was designed badly. There are a few interesting characteristics on the RP side, especially for large repositories like RIPE NCC.I think RRDP is mature enough to move forward. 
Tim: I will send an adoption call to the list. 

Randy Bush -
Ruediger: I seem to remember Steve Kent did a draft that allowed some outside signalling of this being in process. And criteria for relying Parties that want to check if the certification system looks reliable. It looks suspicious if a resource is claimed by two parties. As far as RIRB keeping of data is seems straightforward to have a marker of this is outgoing and potentially a time limit and have this published. 
Randy: Send code! 
Job: A point of clarification, are you talking intra-RIR or inter-RIR?
Randy: For me it was between RIRs.
Job: There may be use cases that the transfer half completes . 
Randy: We have to help the RIRs
Tim: I think we should talk off-line. I think there might be a simpler solution. I don’t think you need to signal the intent. And I’m not sure if this is the right way to do it.
Ruediger: For an attempt of code, I get the idea that the RIRs presented us with an applicability statement as an internet draft that pointed to a certain file for potential conflicts in RPKI. It would be very simple to add another column to that file that states the resource is moving. …add another entry in the file…
Tim: On the break side, there is no grace period.  You can communicate to a child that something will be shrunk, go clean up. That is one thing you can think of. On the initiating side, there are a lot of offline processes involved, so I’m not sure the RPKI should be driving this. 
Keyur: Randy, where do we go from here? Do you want to issue a call on this? 
Randy: What we strongly agreed on is the second bullet: “And helping the RIRs to become unstuck from the “only one-LIR-per-resource problem”, which is not pushing a document. 
Randy: This idea is from Nick Hilliard, credits where credits are due. 

Alexander Azimov
Randy Bush: I promised to do the RPKI Router protocol when the object was clearly designed and the profile would not greatly change. 
Alexander: I agree, and since we changed the profile, we have a stable version of our object. 
Randy: I think the draft needs reading of other people as there seems some of the authors are in disagreement of its clarity. 
Tim: I read the profile draft. Only the customer AS needs to be present on the End entity certificate in the signed object. I recommend not to include anything else, because if you do, then you run an unnecessary risk. 
Alexander: Thank you for the comments
Tim: The text currently says that the  object is valid as long as the customer AS is in the set that is on the EE certificate. I would suggest to keep the EE certificate small in terms of resources. You only need the customer AS there. 

The usage of Maxlength
Alexander Azimov 
Ruediger: There is no question, the correct default for ROAs is a simple ROA that is equal to the prefix length. The max length longer might be something that should be available in expert mode. 
Alexander: How do you see this, in the light of the egress draft, if the default policy is not working for the lease 
Ruediger: I have to think about it. If you want to parse routes that are invalid For customers the egress policy will ensure I will not accept invalids except when we have a special agreement, if there is an egress side. 
Alexander: The target for the egress draft is leaves, so we have to keep it simple. : 
Jeff Haas: The MaxLength is advised to the global internet, this is what the global internet should be seeing, the misconfigurations we tend to see here are often things you want to have for scoped purpose in many cases, like the blackholes. The two things that can be done here at the parties that are next to each other can configure something into their system that we are willing to ignore the RPKI statement. The other thing that could be done is to provide a hint. 
Job: It is tricky to fiddle with the semantics of MaxLength. Some things are what they are. You identified blackholing. For that we have a different approach where we make blackhole route requests rely on less specific routes which then can be pumped through the Origin Validation procedure. It maybe that for the blackhole problem, we might not need the sidrops WG but the GROW WG. If there are other use cases we need to allow this conversation to continue.  

Di Ma
Chris: Ask the list for Last Call

Di Ma 
Distributing RPKI Validated Cache in JSON over HTTPS
Jeff Haas: I’m confused by the deployment scenario. It this attempting to populate the caches that are supplying the inet router to the routers themselves?
Di: No, this mechanism is designed for the synchronisation, so that is the use case. It has nothing to do with the route.
Ruediger: We ended up with some other format intermediate for the validated payload out of the crypto system, and yes, such standardised interface, we have different validators producing the same stuff. It has some advantages for scaling the feeding of many routers. The validated crypto payload has other potential interesting uses. 

Oliver Borchert
Job Snijders: Unfortunately, I’m not sure if you’re heading in the right direction with the merge. There is extreme controversy on the “communities” draft. Perhaps you stepped into something that doesn’t smell nice. It will complicate your goal.
Oliver: The only part of the merger is that we take the eBGP signalling into the BGPSEC transfer, and for BGPSEC that makes perfect sense. 
Job: I understand where you’re coming from, but the sidrops working group does not get to redefine what transifity means in BGP attributes. That is outside our scope. Non-transitive extended community will not convert to transitive. I recommend not to proceed with the merge. 
John Scudder: I would personally take no offence if you obsoleted RFC8097. The second thing, can you go back to the error slide, that looks like a downgrade attack, because if you take the numerically highest one that is the least desirable validation state and that is less desirable than the lack of signalling of any validation state. We can take it to the list
Oliver: We have 2 validation states there, now I have the problem which one to prefer. There is some discussion needed. I shouldn’t see more than one attribute. 
Randy: As John said, obsoleting RFC8097 is not harmful, there is a subsequent RFC that throws away a significant part of RFC8097. it was ill advised, RFC8097 is one of a small number of RFCs which has my name on it which I formally reject in the working group last call and IETF last call. 
Jeff Haas: I own an implementation with a policy engine that has this stuff. You don’t want to put both in the same community, the primary reason for this is that there is a lot of people that have policy out there that says “match community 4300, bunch of zeroes and then number one, two or three. And it is done as an exact match thing. I suggest to keep both. 
Keyur: Jeff raises a good point to keep both. 
Oliver: Indeed, good points.
Doug Montgomery : I don’t understand the thread scenario. Isn’t that a vulnerability? 
John: I don’t want to try to defend it as an attack. Putting it in more neutral language, the error handling that was proposed is less stringent. You changed the semantics to something that will accept routes that were previously rejected. I think that Jeffs comment moves the whole thing. 
Chris: You will do more work on this?
Oliver: Yes.
Job: A question about procedure. The draft ieft-sidrops-validating-bgpspeaker did not reach consensus, what is the current status in the working group?
Chris: I believe the end result was that the authors had to work on it, or the working group would not move forward on it.
Job: Should we still consider it a Working Group document?
Randy: It’s not an adopted as a wg document.
Job: it is, we inherited it from sidr. 
Chris: Let’s take it to the mailing list.