Is there a text of this latest draft? Interested in knowing what the PDU formats will be if the 2 fields are removed...
> RPKI-RTR Protocol by Randy Bush > -- Newest version removed the fields Color and Source > -- This draft has running code (both client and server) > -- This draft is ready to move forward to WGLC -Forhad -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sandra Murphy Sent: Wednesday, December 08, 2010 9:23 AM To: [email protected] Subject: Re: [sidr] IETF79 minutes OK, so now the minutes are below. They were on the web site when I said they were, so I was half right. --Sandy On Tue, 7 Dec 2010, Sandra Murphy wrote: > Below are the minutes that I just uploaded to the meeting proceedings site. > Many thanks to Matt Lepinski and Karen O'Donaghue for being the minute > takers. > > The proceeding URL for sidr is: > http://www.ietf.org/proceedings/79/minutes/sidr.txt. > > If you have any modifications or additions, please post them to the list. > Updates to IETF79 minutes are due by Jan 5, 2011. > > --Sandy, with wg chair toque on. > --------- SIDR --------- Minutes: Matt Lepinski and Karen O'Donogue Sandy: There has been so much traffic on ROA Validation, I am not yet comfortable saying that the working group has reached consensus on ROA Validation draft RPKI-RTR Protocol by Randy Bush -- Newest version removed the fields Color and Source -- This draft has running code (both client and server) -- This draft is ready to move forward to WGLC Certificate Profile by Karen Seo -- Karen Seo: ... Presents slide on Overview Paragraph 2 -- Geoff : IANA currently runs a special purpose IPv4 registry, and thus has the ability to allocate -- Randy : It is not our prerogative to state policy for IANA -- Terry M: Currently IANA is interested in this text, please send the revised text to IANA for review -- Andre: Make the text in this section as simple as possible -- Geoff: The current text implies exclusivity that doesn't exist (IANA does not allocate only to the RIRs) ... But I think that Andre's version is too short, I want more words [Note: Randy and Geoff agree on what's wrong with the text this is unprecedented] -- Tim (SEC AD): We should not let one paragraph keep this document from moving forward out of the working group. We need to make this shortly -- Sandy: What about 6to4, how does that work in our architecture? -- Randy: This is just anycast ... if it needs to be validated, whoever owns the space (IANA) should issue a ROA to everyone who wants to originate it -- Russ: Or we can just define an "Any" ROA -- Randy: We do not want to go with wildcard ROAs Many Documents Updated by Geoff -- Keyroll is ready for WGLC -- Res-Cert is ready for WGLC -- Repos-Struct is ready for WGLC -- Russ H: I think that CMS Signing Time is the right answer, ... but you need some text in the security considerations that indicates what happens if someone gets their clock screwed up and signs something way in the future -- Provisioning Protocol is ready for WGLC -- Geoff presents about ROA-Validation -- Geoff: The simplest text that conforms to the current BGP spec is that if the aggregator field is present, then it is the origin (This is the text in the -07 version) -- Randy: Can we not speak to AS-SETs and then they'll go away? -- Sandy Chair: No -- Sandy Chair: I don't care what the answer is on AS-SETs but there needs to be an answer -- Rutiger V: Can we just say that if there is an AS-SET, then we don't evaluate -- Dave W: I believe there may be implementations of Pordosh's draft (which draft) which addresses this AS-SET issue -- Sandy Chair: If you come across such an implementation, can you ask them to provide their implementation experience to the list -- Rob A: We need text that says ROAs don't apply to AS-SETs Can Sandy Murphy as an individual put forward a statement that says "to hell with AS-SETs and ROAs", and then we can all agree with her and the chairs will be happy and we're done -- John S: I think Warren's draft will progress through IDR and will cease to be watered and down and will have the effect of making sure we no longer need to have these conversations I think there are about 6 routes in the wild that exhibit this particular pathology I think that Geoff has misinterpreted the BGP appendix on proxy aggregation, but it doesn't matter because we've spent way too much time on this already -- No one in the room objects to saying that "UNKNOWN" is always the result if there is an AS-SET in the path -- RPKI-Algs is ready for WGLC -- RPKI-Manifests is ready for WGLC Publication Protocol by Sam W -- This was adopted as a working group item There appear to be no significant updates to the technical content of the document -- Please read the document and provide feedback (document has not received sufficient review yet) Local Trust Anchor by Steve K -- Has not yet been published as a working group document, but there is working group concensus to accept the document -- No significant changes since Stockholm -- Sandy Chair: How does this work with Net-10 space, and leaks of Net-10 announcements -- Steve K: The RPKI will help people ignore leaks of Net-10 announcements ... both with this draft or without this draft, things just work Algorithm Transition by Steve K -- Rob A: Our test bed experience indicates that negotiating the parent child relation is challenging ... I'm not sure what the best trade-offs is, I'll have to think about it and get back to the list -- Randy: agrees with Geoff [shockingly] that this just works when you have a top-down algorithm transition ... The problem that Rob was worried about was the establishment/exchange of business PKI certificates for the up/down protocol -- Rob A: One thing where thing where we might want to extend the provisioning protocol is ... <scribe missed Rob's point> -- Andre: My can't you have a mixed validation path A-B-A-B-A Answer: Until we get near the end of the transition we can't assume that all relying parties understand B ... therefore until you reach this point (Phase 4 in the document) there must be an A-only chain for all resources -- Randy: Note that the time for this is measured in years -- Steve K: This is complicated stuff, we the authors will do another simplifying spin, but after that we will need reviewers -- Sandy Chair: I think that this document needs to have text about validating routes -- Steve K: I think that once we define validation of certificates, then validation of BGP routes just works -- The chairs will ask on the list for working group adoption -- Geoff: The current draft version is deeply flawed and should be revised before we accept it -- Randy: Drafts don't need to be perfect before the working group decides to work _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
