[ncc-services-wg] 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 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 at 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 at NIC.DTAG.DE
>