Randy,
following this line of thought, should an rpki provider be required to
give a significant re-parenting time window before stopping service?
Wouldn't that be part of their private contractual relationship?
Roque
randy
___
sidr mailing list
>> You've got the time left over, after the RPKI service provider exits
>> the field, to scramble with the grandparent to select new service
>> providers...
> if someone mid-chain turns off, certs/roas below will no longer
> validate. so swinging from the grandparent must be make before break.
fo
At 9:53 AM -0800 11/4/09, John Curran wrote:
Steve -
In general, these changes are fine, and address the naming
parent/child/IANA/RIR/ISP name game issue.
One issue which is raised is that a RPKI service provider now may
be made subject (with one month's notice) to changes to the CP made
> You can't invest in the deployment of some types of requirements
> (liability, costs) until the need is certain, i.e. post approval.
so we have noticed :(
> Can you explain the concerns with having a longer time period in the
> document?
as we deploy, if we find a serious ops problem that me
On Nov 4, 2009, at 11:52 AM, Randy Bush wrote:
otoh, i can see that an rpki-provider might want longer than a month
to
implement a new set of ops requirements. but does not the current
ietf
process provide years?
You can't invest in the deployment of some types of requirements
(liabili
On Nov 4, 2009, at 11:41 AM, Randy Bush wrote:
...
but, in that case, is not the largest part of the problem still
getting
the grandparent(s) to swing the covering resource set(s) to new
parent(s)? is not the cp-compliance issue but one very small part
of of
the criteria on which i and my
> My point is that 1 month is a very short time to implement potentially
> significant operational changes from an updated CP, so unless there's
> a reason for such a short time frame I'd recommend something longer.
but, in the real world, is cp-compliance a major criterion on which i
will move to
On Nov 4, 2009, at 10:05 AM, Randy Bush wrote:
...
seems to me thatm if my parent goes out of business, the scramble is
to
build the peerings with the parent(s) to which my grandparent swings
the
resources from which my resources are drawn.
Correct; I agree that's the desired result, rega
>> i am confused. i do not understand the relationship of a parent going
>> out of business (irrespective of reason) with the time for an rpki
>> instance to meet a new cp.
>>
>> seems to me thatm if my parent goes out of business, the scramble is to
>> build the peerings with the parent(s) to whi
On Wed, 4 Nov 2009, Randy Bush wrote:
In general, these changes are fine, and address the naming parent/
child/IANA/RIR/ISP name game issue.
yep, all good
One issue which is raised is that a RPKI service provider now may
be made subject (with one month's notice) to changes to the CP made b
> In general, these changes are fine, and address the naming parent/
> child/IANA/RIR/ISP name game issue.
yep, all good
> One issue which is raised is that a RPKI service provider now may
> be made subject (with one month's notice) to changes to the CP made by
> the IETF. As the CP specifie
Steve -
In general, these changes are fine, and address the naming parent/
child/IANA/RIR/ISP name game issue.
One issue which is raised is that a RPKI service provider now may
be made subject (with one month's notice) to changes to the CP made by
the IETF. As the CP specifies operati
Changed status to be Best Current Practice from Informational
(consistent with eventual BCP designation)
In Section 1.7 revised text (removed references to SIDR WG)
RPKI signed object - Digitally signed data object (other than a
certificate or CRL) declared to be such by a standards track RFC,
13 matches
Mail list logo
