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