[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,

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