Skip to main content

Last Call Review of draft-ietf-sidr-adverse-actions-03
review-ietf-sidr-adverse-actions-03-opsdir-lc-wu-2017-01-02-00

Request Review of draft-ietf-sidr-adverse-actions
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-01-10
Requested 2016-12-20
Authors Stephen Kent , Di Ma
I-D last updated 2017-01-02
Completed reviews Secdir Last Call review of -03 by Brian Weis (diff)
Genart Last Call review of -03 by Dan Romascanu (diff)
Opsdir Last Call review of -03 by Qin Wu (diff)
Assignment Reviewer Qin Wu
State Completed
Request Last Call review on draft-ietf-sidr-adverse-actions by Ops Directorate Assigned
Reviewed revision 03 (document currently at 04)
Result Has issues
Completed 2017-01-02
review-ietf-sidr-adverse-actions-03-opsdir-lc-wu-2017-01-02-00
Hi, Authors:
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document analyzes a number of circumstances which attacks or errors can
have significant impacts on routing. CA acting based on established policy will
be deemed as adverse action, new ROA or router certificate conflicting with old
ROA or router certificate will also be deemed as adverse action I am wondering
how do you distinguish instances of competition that are not adverse actions
from instance of competition that are adverse action? How do you distinguish
remedial action due to attack or mistake by CA from adverse action defined in
this document?

Section 1 tells us:
“
In many cases, such actions may be hard to distinguish
   from mistakes or attacks, other than with respect to the time
   required to remedy the adverse action.  (Presumably the CA will take
   remedial action when a mistake or an attack is detected, so the
   effects are similar in these cases.  If a CA has been legally
   compelled to effect an adverse change, remediation will likely not be
   swift.)

”
That is to say, the difference between adverse action and mistake or attacks is
mistake or attack has quick remediation to be followed while reverse action
not. Section 2.2 further tells us: “ The
   RPKI incorporates manifests to enable RPs to detect suppression and/
   or substitution of (more recent) publication point objects, as the
   result of a mistake or attack
”
I feel confused, do we really care how to distinguish adverse action from
mistake or attack? Since RP can detect suppression or substitution publication
point objects, should RP view them as adverse action or some kind of errors, or
RP view them as mistake or attack. How do you distinct adverse action from
mistake, attack by CA? Whether it is former or latter case or we don’t care the
difference between adverse action and mistake or attack, I think the document
should make this explicitly clear and also make the text consistent in the
document.

Here are a few editorial comments:
Nits and Editorial Issues:
1.      Section 1.1 Terminologies
ROA and RP, EE,CA, RPKI and other terms are frequently used in this document,
suggest to add these acronyms or abbreviations in the section 1.1. 2.     
Section 2.1, A-1.2 Suppression s/3779 extensions/[RFC3779] extensions 3.     
Section 3.1 From the current title of section 3.1, section 3.2, section 3.3,
section 3.4, it is not clear the difference between scenario A, B, C, D.
S/Scenario A/Scenario A: INR holder manages both CA and repository publication
point 4.      Section 3.2 s/Scenario B/Scenario B:INR holder manages CA, parent
or other entity manages repository publication point 5.      Section 3.3
s/Scenario C/Scenario C:INR holder manages repository publication point, parent
or other entity manages CA 6.      Section 3.4 s/Scenario D/Scenario D: parent
entity manages both CA and repository publication point

-Qin