Re: [routing-wg] [address-policy-wg] REMINDER; WAS Re: 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders)
Dear Colleagues,
The new version of RIPE Policy Proposal 2008-08, "Initial Certification Policy for Provider Aggregatable Address Space Holders", was published on 9 February 2011. The time period for community review ends on 23 February 2011.
Some feedback was sent to the Address Policy Working Group mailing list. However, to maintain the discussion, we strongly recommend that you share your ideas and comments and clearly let the community know if you:
- Support the implementation of the proposal I support the implementation of the proposal;
Dear colleagues, I apologize for my bad habits and tradition for sending comments at the very last minute. please find additional comments below that point out some problems and some ideas regarding required work.
- Support the general principle of the proposal but would prefer another wording - Support the general principle with some details changed but agree to postpone this discussion until another stage of the policy proposal review. (This is an initial proposal that covers only PA resources. If the community supports extending certification to all resources, then another version of the proposal will be necessary.) - Do not support the proposal (please explain your motivations)
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2008-08
and the draft document at:
http://www.ripe.net/ripe/policies/proposals/2008-08/draft
Please send an email with your comments to address-policy-wg@ripe.net by 23 February 2011.
Best regards, Emilio Madaio
My "vote" on the proposal is: I agree to the policy proposal (consisting of "Summary", "Policy Text", and "Rationale") and want to see it fully executed as a minimum first step of implementing full RPKI support by RIPE NCC fitting into the global RPKI infrastructure. This MUST NOT be delayed any further (considering the long time this has been worked AND having missed a committed delivery date [Jan 1 2011] already. I have more comments (which may seem to dilute the primary statement, but hopefully help to fix problems and make more progress) This policy is simpler and more limited than would seem adequate and desirable in today's situation; it was more appropriate when initial versions were proposed. Even while some open ends are recognized the initial policy should be put in place to clearly indicate that the RIPE community is in control of setting policy for the operation of the NCC RPKI service; however we also need to recognize there is a challenge to deal here with more complexity and deeper technical detail compared with [most] other RIPE policies; this includes even the question of just how to identify/separate community and user relevant policy from implementation details. I see need for discussion of the NCC's impact analysis and other related documents (potentially including the process for document control). I have one clear and simple problem (=objection) to the NCC's impact analysis: I do not understand how the NCC can conclude that "this proposal only applies to IPv4 ..."; I do not see such restriction in the language of the proposal - and I'm sure that contributors to the proposal certainly would have expressed this unambiguously if that had been the intention. So I would like to emphasize that the intended policy OF COURSE covers both address families - and the definition of RPKI anyway! Inclusion of IPv6 is a MUST! If RIPE NCC has not yet implemented support of IPv6 they need to tell us the expected delivery date! As related documents I see (a) CPS (b) "... Deregistration of Internet number resources" (c) Certification Service Terms and Conditions (d) Certification Repository Terms and Conditions The need for (a) and (b) has been pointed out for more than 2 years; progress has been slow and late. Having a CPS is a standard requirement for serious [R]PKI CAs. I don't remember that there has been any mentioning of something like (c) and (d) in previous discussion and so they show up as somewhat of a surprise. The documents and their relation need some discussion, in particular with regard to how functions are distributed and to identify (and place) the relevant policy pieces. Somewhat as an example I'd like to mention: The elaborate standard structure that is defined for the CPS clearly includes parts that are defining user relevant policy details (some of which came up in the discussion of this policy proposal) as well as documentation of lots of implementation details that clearly should be left completely in the NCC's responsibility. (c) duplicates parts of the CPS and claims priority over the CPS and classifies the CPS as "explanatory document" - this looks questionable to me. Is it really acceptable that no notifications about replacements for revoked certificates are provided? (maybe OK for hosted service; hard to believe with full RPKI distributed CAs) For meeting the challenges and more satisfactory and satisfying results we need to establish a more detailed activity plan and focussed work. Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv@NIC.DTAG.DE
Dear Wilfried and Rudiger, thank you very much for your feedback and contribution to the review of the proposal on the mailing list. I hereby will try to clarify furthermore the Impact Analysis performed and published in the Review Phase. The policy text specifically states: " Following guidelines are to apply only for certification of Provider Aggregatable (PA) address space that are held by the RIPE NCC members in good standing. " Purely in terms of policy analysis, in the RIPE NCC service region Provider Aggregatable address space is defined only in the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", ripe-509, available at http://www.ripe.net/ripe/docs/ripe-509 Hence, according to the existing policies approved by the RIPE community, only IPv4 address space can be Provider Aggregatable. As Rudiger highlighted, we are challenged with this proposal to identify/separate community relevant policies from implementation details. The explanation given in the RIPE NCC's Understanding belongs only to the former: community relevant policies. The Understanding is meant to clarify to the community what the NCC reads in the proposal in order to give some information on how it would be implemented. The goal of the Impact Analysis is to provide relevant supporting information to facilitate the discussions. In this case, it leads into a deeper consideration of what the proposal means and the community's intentions on the whole Certification Service. I am already in touch with the proposer on this matter. Yours and all the other feedbacks presented during the last two weeks of Review Phase are going to be considered together with the Address Policy WG chairs and the next step of the policy making process will be announced to the community accordingly to the PDP. Best Regards Emilio Madaio Policy Development Officer On 2/24/11 12:00 AM, Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 wrote:
Dear colleagues,
I apologize for my bad habits and tradition for sending comments at the very last minute.
Dear Colleagues,
The new version of RIPE Policy Proposal 2008-08, "Initial Certification Policy for Provider Aggregatable Address Space Holders", was published on 9 February 2011. The time period for community review ends on 23 February 2011.
Some feedback was sent to the Address Policy Working Group mailing list. However, to maintain the discussion, we strongly recommend that you share your ideas and comments and clearly let the community know if you:
- Support the implementation of the proposal I support the implementation of the proposal; please find additional comments below that point out some problems and some ideas regarding required work.
- Support the general principle of the proposal but would prefer another wording - Support the general principle with some details changed but agree to postpone this discussion until another stage of the policy proposal review. (This is an initial proposal that covers only PA resources. If the community supports extending certification to all resources, then another version of the proposal will be necessary.) - Do not support the proposal (please explain your motivations)
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2008-08
and the draft document at:
http://www.ripe.net/ripe/policies/proposals/2008-08/draft
Please send an email with your comments to address-policy-wg@ripe.net by 23 February 2011.
Best regards, Emilio Madaio
My "vote" on the proposal is:
I agree to the policy proposal (consisting of "Summary", "Policy Text", and "Rationale") and want to see it fully executed as a minimum first step of implementing full RPKI support by RIPE NCC fitting into the global RPKI infrastructure. This MUST NOT be delayed any further (considering the long time this has been worked AND having missed a committed delivery date [Jan 1 2011] already.
I have more comments (which may seem to dilute the primary statement, but hopefully help to fix problems and make more progress)
This policy is simpler and more limited than would seem adequate and desirable in today's situation; it was more appropriate when initial versions were proposed. Even while some open ends are recognized the initial policy should be put in place to clearly indicate that the RIPE community is in control of setting policy for the operation of the NCC RPKI service; however we also need to recognize there is a challenge to deal here with more complexity and deeper technical detail compared with [most] other RIPE policies; this includes even the question of just how to identify/separate community and user relevant policy from implementation details.
I see need for discussion of the NCC's impact analysis and other related documents (potentially including the process for document control).
I have one clear and simple problem (=objection) to the NCC's impact analysis: I do not understand how the NCC can conclude that "this proposal only applies to IPv4 ..."; I do not see such restriction in the language of the proposal - and I'm sure that contributors to the proposal certainly would have expressed this unambiguously if that had been the intention. So I would like to emphasize that the intended policy OF COURSE covers both address families - and the definition of RPKI anyway! Inclusion of IPv6 is a MUST! If RIPE NCC has not yet implemented support of IPv6 they need to tell us the expected delivery date!
As related documents I see
(a) CPS (b) "... Deregistration of Internet number resources" (c) Certification Service Terms and Conditions (d) Certification Repository Terms and Conditions
The need for (a) and (b) has been pointed out for more than 2 years; progress has been slow and late. Having a CPS is a standard requirement for serious [R]PKI CAs. I don't remember that there has been any mentioning of something like (c) and (d) in previous discussion and so they show up as somewhat of a surprise. The documents and their relation need some discussion, in particular with regard to how functions are distributed and to identify (and place) the relevant policy pieces.
Somewhat as an example I'd like to mention: The elaborate standard structure that is defined for the CPS clearly includes parts that are defining user relevant policy details (some of which came up in the discussion of this policy proposal) as well as documentation of lots of implementation details that clearly should be left completely in the NCC's responsibility. (c) duplicates parts of the CPS and claims priority over the CPS and classifies the CPS as "explanatory document" - this looks questionable to me. Is it really acceptable that no notifications about replacements for revoked certificates are provided? (maybe OK for hosted service; hard to believe with full RPKI distributed CAs)
For meeting the challenges and more satisfactory and satisfying results we need to establish a more detailed activity plan and focussed work.
Regards, Ruediger
Ruediger Volk
Deutsche Telekom AG -- Internet Backbone Engineering
E-Mail: rv@NIC.DTAG.DE
participants (2)
-
Emilio Madaio -
Ruediger Volk, Deutsche Telekom T-Com - TE141-P1