Hi, Carlos,

Perhaps I've misunderstood your draft but to me it seems to claim that there are 2 areas that could cause problems.

1. Page 4-5 discusses possible errors by CAs in issuing certificates
   that could cause subordinate certificates to fail validation. With
   regard to exploring adverse actions, what I meant is that your draft
   describes an adverse action (possibly several depending on how one
   interprets your text) that can be done by a CA by error (or
   maliciously or because of an attack).  And I believe the adverse
   action draft covers this or could be extended to cover it, if the WG
   feels the current text does not adequately describe this case (or
   cases).
2. Page 5-7  talks about resource transfers as a source of concern. The
   way in which resource transfers can/will cause problems and the
   resulting impact will depend on how the WG decides to handle the
   transfers, the order of the actions, who does what, etc.   So while
   your draft does not define how transfers should be done, Randy's
   draft struck me as potentially addressing the issue or at the very
   least providing the necessary basis for evaluating its seriousness
   and what to do about it.

Karen




On 11/5/15 8:59 PM, Carlos M. Martinez wrote:
Karen,

I disagree with your position. Our draft does not explore adverse
actions nor discuses transfers.

It is not the same topic.

-Carlos

On 11/6/15 5:53 AM, Karen Seo wrote:
Folks,

I think the authors have brought up some pertinent issues which have
helped inspire other work which subsumes them.  So I thank them but
agree that it seems appropriate to drop this draft since those issues
are now being covered in other documents and those documents have
additional detail.  Randy's I-D discusses INR transfers.  Steve's draft
on adverse action provides a detailed analysis of the "operational
fragility" of the RPKI in the face of attacks and errors.  So, if the
adverse actions draft is adopted by the WG,  we (the WG) could use the
requirements stemming from these two IDs as the basis for a solution(s)
document.  Just personal preference, but I also find having one document
per topic/issue (at least when they're as complex as is the case with
the threat analysis) easier to follow and would also like to separate
defining of issues and their requirements from describing the solution.

Respectfully,
Karen

On 11/3/15 4:21 AM, Christopher Morrow wrote:
During the meeting today (tues 11/3/2015) one of the authors of:
    draft-ietf-sidr-rpki-validation-reconsidered

noted that after the last set of updates and over the history of the
document (2+yrs) there's been no real support nor direction from the
working-group. Additionally, all co-authors noted that the lack of
support and direction meant that abandoning the draft seemed like the
best current direction.

The primary author: Geoff Huston ([email protected]) is willing to toss
the XML over the fence to another author/editor if there is interest,
or to let the draft expire/die if no one is willing to take up the
pencil.

Over the next three weeks let's discuss the direction/end-goal and
determine if 'abandon' or 'new author' is the best course of action
here.

-chris
sidr-co-chair

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to