Status: As per data tracker
  LTA Uses cases is probably Chris Morrow's fault
  Question over tree-validation draft - Chair to follow up
  
  
1) draft-ietf-sidrops-route-server-rpki-light

   Job Snijders: Unauthorised BGP propagation of a more specific route of an exchange would case some routing damage, and the marking of it without recourse to a ROA would be a poor move - they should always be encouraged to drop invalids.
   Response: use a seperate draft?
   Respose: The aim it to document a standard best operator practice for exchanges
   Job: why use an extended community to tag announcements? Why is current practice not sufficient? Why do you need an RFC
   Response: We think it is widely applicable and merits an RFC
   Asimov: If you already have two methods that already achieve IX filtering, why propose a third method?
   Response: RPKI has a more solid foundation over IRR filtering.
   Asimov: Do you believe that your customers will use BGP communities foe this prupose?
   Response: We have customers already doing this and want to standardise this
   Rudiger Volk: Did not produce a draft on how to use the expanded code space to describe policies as leading to a BCP on common ways to describe routing intent - far better than the old extended communities. The open community attribute does not need to await vendor support for this. i.e. anyone can get an AS code point to mark their communities.
   Rudiger: Which trust anchors are you using to generate your community-based marks?
   Response: We leave trust to the customers
   Doug Montgomery: Scope - all of these drscriptions of actions of fropping and tagging are actions already now - whats the purpose
   Response: standardised mechanisms
   
  Chairs: there is a bunch of followup conversations here, all of which chould be on the mailing list
  
2) Origin Validation Policy Considerations for Dropping Invalid Routes
  Keyur Patel: As an implementer would you ever get a request to NOT consider the Decision Process? Maybe you should provide that flexibility in the draft
  Keyur Patel: How many levels should you recurse through tio find the covering valid aggregate?
  Response: No limit specified
  Warren: What happens when the covering aggregate flaps?
  John Scudder: Question on multi-homing example - the generic observation is that we can't just easily dismiss this problem
  Job Snijders: There is ZERO deployment of origin validation. The observation is whether there is an incremental path towards deployment that does not cause spurious drops
  Randy: Don't do it at exchange points
  [timeout]
  Chairs: take this to the mailing list
  
3) https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-00
  Rob Austein: the main purpose seems of be for unplanned key rolls - yes?
  Rob Austein: why 24 hous? What is the problem in making it longer?
  Rob Austain: We should think about unplanned key rolls
  Tim: We should be aware of the increlental load on Relying Parties if we make this process more convoluted
  
4) https://tools.ietf.org/html/draft-tbruijnzeels-sidrops-https-tal-00
  really really minor change to RFC7730
  ship it
  
5) RIPE NCC RPKI Validator 3 architecture
  Rob Austein: when implementing the client side of RDP and using RIPE's database on the server side I noticed different behaviour - the difference between full and incrmental trnsfer - do you have imokementation experience?
  Tim: not sure we encountered that
  Tim: support of validation reconsidered: we had it in an earlier version of the code. We have not done it in this code yet. The moment we publish a certificate with a new OIDs in it then things will break. The transition is unclear and we are not clear how to approach this.
  
6) draft-ietf-sidrops-rp-00  
  no questions