On Nov 2, 2011, at 4:34 AM, Stephen Kent wrote:

> At 6:29 PM -0700 11/1/11, Terry Manderson wrote:
>> On 31/10/11 11:59 PM, "Stephen Kent" <[email protected]> wrote:
>> 
>> 
>>>> 
>>>> I understand why you want to, but don't come to the same conclusion as to
>>>> the mechanism.
>>>> 
>>>> Is that really the IETF's job?
>>> 
>>> SIDR was tasked by the SEc ADs to develop an alg transition architecture.
>>> The authors believe that uniform milestones are necessary as part of
>>> a credible plan.
>>> 
>> 
>> Architecture, yes. Structured approach, yes. To both of those I agree.
>> Having the IETF define the dates when algorithms shift. I am not convinced.
> 
> An architecture that ignores the need to have a global, uniform set of 
> milestones for transition phases is incomplete.

Having a model that requires independent administrative entities (the CA 
operators here) in the Internet to obey a traffic cop sounds a little... hard 
to swallow (operationally).  I also remain quite unconvinced.  I think this 
indicates that there is a misalignment in the design, not a problem in the 
above question.

> 
>> >> Call me a dirty rotten cynic but I just don't see this operational aspect 
>> >> of
>> >> one or more running RPKI hierarchies as part of the IETF. Although you can
>>>> prove me wrong, and I'll concede to an already enacted example where dates
>>>> were set for some artifact.
>>> 
>>> We have to have two, parallel hierarchies to avoid a flag day. This
>>> is not a situation where every CA can decide, locally, when to
>>> transition, because the the alg change affect ALL RPs.
>> 
>> We are talking years. The overlap will be significant. And I disagree - in
>> this case every CA has to consciously decide - there may well be a situation
>> that a mid term operational impact requires an important CA in the middle of
>> the chain to delay. That then renders all dates specified in any RFC next to
>> meaningless.
> 
> Yes, we are talking years. No, it cannot be a local, per-CA decision, because
> the transition affects all RPs. I anticipate that the stakeholders, CAs and 
> RPs, will have the ability to comment on the proposed dates, and that the 
> IETF/IESG will take into account these comments when developing the timeline. 
> If a major problem arises that makes it infeasible for CAs to adhere t the 
> timeline, a new RFC can be issued.

So, to make sure I understand: if operational issues arise that cause an 
independent administrative entity (one of the CA operators) to need to delay an 
operational action, they need to get an RFC published?  I must have 
misunderstood?

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

Reply via email to