thank you, thank you, thank you, for your review. > Comment 1) The validation state terminology used in this draft is not > consistent with the terminology of draft-sidr-pfx-validate. That > draft uses states: valid, invalid, not found, whereas this draft uses > states: valid, invalid, unknown. Do we want these to be consistent > across i-ds? The 3 states are defined in draft-sidr-pfx-validate but > are not defined here. We should either define them or point to the > definition in draft-sidr-pfx-validate where they are defined.
thanks. will do. are you happy with "not found?" i have had to sit through meetings with a bunch of folk discussing this until i had to leave the room, and definitely have lost any opinion i might have ever had on the subject. > I will refer to this as state "not found" in the remainder of my > comments. whack me now, as i will make the change after more coffee. > Comment 2) Some suggested text below for the opening of section 5. > > Section 5. Routing Policy > > Background > > Currently, the origin status information is not verified. With the > incremental deployment of RPKI, we will transition to origin > validation comprised of three states: valid, invalid and not found > [see draft-sidr-pfx-validate]. We specify a relative preference > associated with each state as follows: i am thinking of softening to s/We specify/In the absense of other designed policy, we recommend/ > Announcements with valid origins SHOULD be preferred over those with > *not found* or invalid origins. > > Announcements with *not found* origin SHOULD be preferred over those > with invalid origins. > > Announcements with invalid origins MAY be used, but SHOULD be less > preferred than those with valid or *not found*. > > During the RPKI transition period, relative preference is introduced > to manage the uncertainty associated with a system in flux. As the > RPKI transition moves forward, the number of origin validations with > state "not found" will decrease. thanks > Reasonable application of local policy should be designed *to* > eliminate the threat of unroutability of prefixes due to ill-advised > or incorrect certification policies. thanks > 2) As origin validation will be rolled out over years coverage will be > spotty for a long time. Hence a normal operator's policy should > not be overly strict, perhaps preferring valid announcements and > giving very low preference, but still using, invalid announcements. > > Suggestion: > As origin validation will be rolled out *incrementally* coverage will > be *incomplete* for a long time. Hence an *word deleted* operator's > policy should not be overly strict, perhaps preferring valid > announcements, *attaching a lower preference to but still using, not > found announcements* and giving very low preference, but still using, > invalid announcements. > > I deleted the word "normal" since I don't know what normal is. I > think you need to point out here that they will use all three, valid, > invalid and not found announcement. For some reason it is missing > from this paragraph but is correctly included in the list below. i pretty much agree with all this. but let me explain my weaseling and 'normal.' in the back of my mind, i have operators who do weird things such as security research, monitoring of the state of the validation world, ... who may do strange things such as prefer invalid. perhaps i should not be weaseling about that and stick to vanilla, chocolate, and strawberry? > "Reasonable application of local policy should be designed *to* > eliminate the threat of unroutability of prefixes due to ill-advised > or incorrect certification policies." > > What is ill-advised as opposed to incorrect? Does ill-advised means > one kind of error and incorrect another? If they are really one > problem, then just use one term. two problems. one is incorrect, erroneous, ... another is the set of issues devolving from the x.509 base requiring altrustic action by a chain of organizations. a significant number of operators, including me on odd days of the week, are extremely worried about ICANN, RIR, ... policies with regard to the RPKI. think things such as legacy space, RIR 'customers' in conflict with the RIR, ... > Comparison of draft-sidr-pfx-validate section 6 called "deployment > considerations": > > I'm confused by the relationship of this draft to > draft-sidr-pfx-validate section 6 called "deployment considerations". > Is this the operational section and therefore should > draft-sidr-pfx-validate reference draft-sidr-origin-ops? probably a reference from pfx-validate would be good. i'll have a talk with the authors :) > The deployment guidance is not the same in sidr-pfx-validate as it is > in sidr-origin-ops in the sense that there are no SHOULDs or > MUSTs. The deployment considerations in sidr-pfx-validate are just > advice. Here is the specific text from draft-sidr-pfx-validate: > > 6. Deployment Considerations > > "Once a route is received from an EBGP peer it is categorized > according the procedure given in section 2. Subsequently, routing > policy as discussed in section 3 > <http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-00#section-3> > can be used to take action based on the validation state. > > Policies which could be implemented include filtering routes based on > validation state (for example, rejecting all "invalid" routes) or > adjusting a route's degree of preference in the selection algorithm > based on its validation state. The latter could be accomplished by > adjusting the value of such attributes as LOCAL_PREF. > > In some cases (particularly when the selection algorithm is > influenced by the adjustment of a route property that is not > propagated into IBGP) it could be necessary for routing correctness > to propagate the validation state to the IBGP peer. This can be > accomplished on the sending side by setting a community or extended > community based on the validation state, and on the receiving side > by matching the (extended) community and setting the validation > state." i am not sure if this conflicts with or even overlays origin-ops. it is not suggesting policy, merely discussing mechanisms. clue bat please. and thanks again! randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
