Minutes IETF101: sidrops
minutes-101-sidrops-00

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