Subject: [sidr] CP changes in response to WGLC comments

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Nov 2009 12:25:35 -0500

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,
and that can be validated using certificates issued under this PKI.

------

Section 1.4.4 revised text (removed references to SIDR WG)

An RPKI signed object is a digitally-signed object, declared to be 
such by a standards track RFC.

-------

Section 9.12.1 revised text (removed reference to RIRs and IANA, 
replaced with IETF)

The procedure for amending this CP is via written notice from the 
IETF in the form of a new Standards Track, BCP RFC that updates or 
obsoletes this document.

------

Sectioon 9.12.2 revised text (removed reference to RIRs and IANA, 
replaced with IETF)

The IETF will provide at least one month's advance notice of any 
changes to this CP.

-------

Section 9.12.3 revised text (removed reference to RIRs and IANA, 
replaced with IETF)

If the IETF judges that changes to the CP do not materially reduce 
the acceptability of certificates issued for RPKI purposes, there 
will be no change to the CP OID. If the IETF judges that changes to 
the CP do materially change the the acceptability of certificates for 
RPKI purposes, then there will be a new CP OID.

Section 13.2 (removed last two informative references)

---

From: John Curran <[email-masked]>
Date: Wed, 4 Nov 2009 09:53:35 -0800

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 operational practices, this has  
potential to be impacting for the RPKI service provider and ISP's  
relying upon such certs.   In order to protect those relying ISPs in  
the case of a CP change which causes RPKI providers to exit the  
business, the 9.12.2 implementation time period to should be long  
enough to allow ISP's to move to an RPKI providers now complying with  
the new CP document.  I'd recommend 6 months advance notice rather  
than one for this reason.

Thanks,
/John

On Nov 4, 2009, at 9:25 AM, Stephen Kent wrote:

> the CP do materially change the the acceptability of certificates  
> for RPKI purposes, then there will be a new CP OID.
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Nov 2009 12:05:38 -0600

> child/IANA/RIR/ISP name game issue.

yep, all good

> relying upon such certs.

amusing that you use the term ISP when you like the document getting rid
of proper noun taxa.

> In order to protect those relying ISPs in the case of a CP change
> which causes RPKI providers to exit the business, the 9.12.2
> implementation time period to should be long enough to allow ISP's to
> move to an RPKI providers now complying with the new CP document.  I'd
> recommend 6 months advance notice rather than one for this reason.

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 which my grandparent swings the
resources from which my resources are drawn.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 4 Nov 2009 14:30:47 -0400 (Eastern Daylight Time)

> resources from which my resources are drawn.

Randy, as I read John's note, when he says "RPKI service provider" he 
means the CertsRUs business which the ISP has outsourced all its cert 
handling activity to.

It sounds to me like you were reading that as an upstream ISP.

--Sandy

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Nov 2009 13:41:16 -0600

> It sounds to me like you were reading that as an upstream ISP.

oops!  sorreeee.

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 grandparent(s) choose new parent(s)?

randy

---

From: John Curran <[email-masked]>
Date: Wed, 4 Nov 2009 11:45:40 -0800

On Nov 4, 2009, at 10:05 AM, Randy Bush wrote:
> ...

Correct; I agree that's the desired result, regardless of parent  
failure.

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.

/John

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Nov 2009 13:52:40 -0600

> 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/from a rpki provider?  i suspect it will be down in the
weeds, and reliability/reputation, price, ease of operation, ... will
predominate.

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?

randy

---

From: John Curran <[email-masked]>
Date: Wed, 4 Nov 2009 11:55:31 -0800

> the criteria on which i and my grandparent(s) choose new parent(s)?

Use case:

1) New CP comes out and specifies minimum standards in the area of  
Facility, Management, And Operational Controls (rather the delegation  
of such to the CPS)

2) Existing RPKI service providers need to assess this and decide  
implications therein

3) If existing RPKI providers can't/won't meet the requirements, and  
exit the business, they want to do so within 1 month due to 9.12.2 (to  
prevent having non-CP compliant certs out there)

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...

Hence, my suggestion that 30 days notice is rather short.
/John

---

From: John Curran <[email-masked]>
Date: Wed, 4 Nov 2009 11:58:16 -0800

> implement a new set of ops requirements.  but does not the current  

You can't invest in the deployment of some types of requirements  
(liability, costs) until the need is certain, i.e. post approval.

Randy - Can you explain the concerns with having a longer time period  
in the document?

/John

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Nov 2009 14:19:52 -0600

> (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 means a change to
the cp, it would be good to have it fixed very quickly.  then again,
it's the running code that really needs to be fixed.  

otoh, as the cp carries a legal liability tie-in, i can see that the
rpki provider wants a long window in which both old and new requirement
sets are valid.

> the field,  to scramble with the grandparent to select new service  

if someone mid-chain turns off, certs/roas below will no longer
validate.  so swinging from the grandparent must be make before break.

> Hence, my suggestion that 30 days notice is rather short.

i have no strong disagreement with a wider window.  i remain confused by
your characterization of the need.

randy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Nov 2009 15:27:04 -0500

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.
>
>be made subject (with one month's notice) to changes to the CP made 
>by the IETF.  As the CP specifies operational practices, this has 
>enough to allow ISP's to move to an RPKI providers now complying 
>with the new CP document.  I'd recommend 6 months advance notice 
>rather than one for this reason.
>
>Thanks,
>/John

John,

Fair point.  I thought about the 1 month value when I was editing the 
text, having not looked at it for a long time. I thought that the 
IESG/RFC process was sufficiently long that anyone who was watching 
would have a lot more than 1 month advance notice :-). However, not 
everyone who might be affected would necessarily be tracking a 
proposed change, and the change would, not be definite until approved 
by the IESG. So, I think this is very reasonable change this value to 
be 6 months.

Steve

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Nov 2009 14:28:15 -0600

> validate.  so swinging from the grandparent must be make before break.

following this line of thought, should an rpki provider be required to
give a significant re-parenting time window before stopping service?

randy

---

From: Roque Gagliano <[email-masked]>
Date: Sun, 8 Nov 2009 06:44:00 +0900

Randy,
> give a significant re-parenting time window before stopping service?

Wouldn't that be part of their private contractual relationship?

Roque

> randy

-------------------------------------------------------------
Roque Gagliano
LACNIC
[email-masked]
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE