2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders)
Dear Colleagues, The new version (3.0) of the proposal 2008-08 has been published. The draft document for the proposal and the impact analysis have also been published. The proposal will now undergo a two weeks Review Phase as explained in the previous message available at: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00022.... 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 We strongly encourage you to read the draft document text and send comments, ideas, feedback to address-policy-wg@ripe.net before 23 February 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC
Dear Working Group, as you might have noticed, this proposal is nicknamed "the icelandic saga" because it goes on and on and on and on... We'd really like to bring this to conclusion, and for that, we need *feedback from the community*. So please let us know: - this is what you want to see implemented - you're in favour of the general principle, but this specific wording is not what you want - you're in favour of the general principle, want some details changed, but agree to pospone that to the next round of certificate-related proposals (like "this proposal does not cover PI" - yes, we know, the plan was to "start with the easy bits = PA"). - you're completely opposed to this proposal (in that case, giving some background why you don't want it would be very helpful) thanks, Gert Doering APWG chair On Wed, Feb 09, 2011 at 03:00:35PM +0100, Emilio Madaio wrote:
Dear Colleagues,
The new version (3.0) of the proposal 2008-08 has been published.
The draft document for the proposal and the impact analysis have also been published.
The proposal will now undergo a two weeks Review Phase as explained in the previous message available at:
http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00022....
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
We strongly encourage you to read the draft document text and send comments, ideas, feedback to address-policy-wg@ripe.net before 23 February 2011.
Regards
Emilio Madaio Policy Development Officer RIPE NCC
-- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 9 February 2011 14:13, Gert Doering <gert@space.net> wrote: As epic as this is, my problem with that document is that it contains things like "Resource Public Key Infrastructure (RPKI) certificates over their Provider Aggregatable" which I think I understand, but feels like I might be reading it wrong (I think over is the wrong word) "RIPE NCC members in good standing" Not seen 'in good standing' defined anywhere "Certificates will be issued with a validity period of up to 18 months or as otherwise stated in the RIPE NCC Certificate Practice Statement." which is silly and should loose the whole 18 months bit (or the practice statement bit)
- you're in favour of the general principle, but this specific wording is not what you want
most definitely J -- James Blessing 07989 039 476
On Wed, 2011-02-09 at 14:21 +0000, James Blessing wrote:
On 9 February 2011 14:13, Gert Doering <gert@space.net> wrote:
As epic as this is, my problem with that document is that it contains things like
"Resource Public Key Infrastructure (RPKI) certificates over their Provider Aggregatable"
which I think I understand, but feels like I might be reading it wrong (I think over is the wrong word)
Well, we have to decide where we stop with explanations. I have to admit that we assumed that members would be aware of what an RKPI certificate was (at least in general terms) and also that they knew what Provider Aggregatable space was. We did expand the acronyms, at least.
"RIPE NCC members in good standing"
Not seen 'in good standing' defined anywhere
True, although this form of words is pretty universally understood to mean "having paid their bill and not having been suspended for any reason". The full rules on membership are defined in the Articles of Association, (ripe-514)
"Certificates will be issued with a validity period of up to 18 months or as otherwise stated in the RIPE NCC Certificate Practice Statement."
which is silly and should loose the whole 18 months bit (or the practice statement bit)
This derives from the fact that when this version of the policy was written, the CPS had still not been finalised. The intent of the statement is "the CPS takes precedent if it exists, otherwise 18 months" which seems a sensible way of putting in a default. Nigel
On Wed, 9 Feb 2011, Gert Doering wrote:
Dear Working Group,
as you might have noticed, this proposal is nicknamed "the icelandic saga" because it goes on and on and on and on...
We'd really like to bring this to conclusion, and for that, we need *feedback from the community*. So please let us know:
- this is what you want to see implemented
want to see this implemented. One question; what happens after the validity period of the certificate expires? Jac -- Jac Kloots Network Services SURFnet bv
Hi Jac,
One question; what happens after the validity period of the certificate expires?
You have an invalid certificate :) But at that point in time you will also have received a new certificate with a new validity period. As long as you still meet the criteria for receiving the certificate of course. - Sander
Sander, On Wed, 9 Feb 2011, Sander Steffann wrote:
Hi Jac,
One question; what happens after the validity period of the certificate expires?
You have an invalid certificate :)
That's the obvious answer.
But at that point in time you will also have received a new certificate with a new validity period.
And this will be a new policy, the current doesn't state any policy about this? I was aiming at the fact that this policy doesn't give any clue about what happens when the validity period expires while the Abstract of the proposal does mention 'how these certificates should be maintained'. Expiring certificates are part of this, expering due to CRL's is mentioned, but expering due to validity period is open. Jac -- Jac Kloots Network Services SURFnet bv
Hi,
But at that point in time you will also have received a new certificate with a new validity period.
And this will be a new policy, the current doesn't state any policy about this?
It states 'Certificates will at all times reflect the registration status of the resource.', so as long as the registration status is ok you can get certificates for it. - Sander
On 9 Feb 2011, at 15:22, Jac Kloots wrote:
On Wed, 9 Feb 2011, Gert Doering wrote:
Dear Working Group,
as you might have noticed, this proposal is nicknamed "the icelandic saga" because it goes on and on and on and on...
We'd really like to bring this to conclusion, and for that, we need *feedback from the community*. So please let us know:
- this is what you want to see implemented
want to see this implemented.
One question; what happens after the validity period of the certificate expires?
The validity set on a certificate is 18 months, but it is automatically renewed every 12 months for as long as you have resources registered. Like it says in the Policy proposal:
Certificates will at all times reflect the registration status of the resource.
This means when new resources are added to your registry, an updated certificate listing the new set of resources is automatically issued. When you return resources to the RIPE NCC, a new, updated certificate is issued and the old one is revoked. It is not possible for a resource certificate to exist listing no resources at all. So when you seize to be an LIR and all of your resources are returned to the RIPE NCC, the result is that the certificate and all child objects automatically disappear from the repository. This exactly matches the business processes of the RIPE NCC. Cheers, Alex
Alex, On Wed, 9 Feb 2011, Alex Band wrote:
One question; what happens after the validity period of the certificate expires?
The validity set on a certificate is 18 months, but it is automatically renewed every 12 months for as long as you have resources registered. Like it says in the Policy proposal:
This is exactly what I was looking for, the 12 month automatically renewal mechanisme. As this is a policy, shouldn't this be stated in this policy? Regards, Jac -- Jac Kloots Network Services SURFnet bv
On 9 Feb 2011, at 16:51, Jac Kloots wrote:
Alex,
On Wed, 9 Feb 2011, Alex Band wrote:
One question; what happens after the validity period of the certificate expires?
The validity set on a certificate is 18 months, but it is automatically renewed every 12 months for as long as you have resources registered. Like it says in the Policy proposal:
This is exactly what I was looking for, the 12 month automatically renewal mechanisme. As this is a policy, shouldn't this be stated in this policy?
This is described in the Certification Practice Statement: http://www.ripe.net/lir-services/resource-management/certification/cps/view See section 4.2.2. Approval of certificate applications The validity and renewal of certificates is operational (this is why it in described as such in the CPS), because it needs to match with other RIPE NCC business processes. You'll notice that the six months grace period is exactly matching to the different billing phases an LIR enters when their membership is not renewed. These phases last six months in total, after which the RIPE NCC will starts the process of closing the LIR and de-register their resources. The result being that their certificate is revoked (because no resources = no resource certificate). -Alex Reference: http://www.ripe.net/lir-services/member-support/info/billing/billing-fees-li...
- you're in favour of the general principle, want some details changed, but agree to pospone that to the next round of certificate-related proposals (like "this proposal does not cover PI" - yes, we know, the plan was to "start with the easy bits = PA").
Why is it stated :
This proposal only applies to IPv4 ALLOCATED PA blocks that were issued by the RIPE NCC and excludes early registration and legacy space, as well as blocks marked as ALLOCATED UNSPECIFIED or ALLOCATED PI.
That was one of the topics I noticed when I used the certification website for my own LIR. ( After some peer pressure by a guy named Alex B. ) I would think/argue that this would be more useful for specifically PI, rather than just doing it for PA. And to make things probably worse for the discussion, I would think that having the LIR manage this on behalf of their PI customers, might not be a bad idea, also because the location of the online certification site is in the LIR portal and this could be seen as one of the tasks a LIR does on behalf for their customers. PI LIR customers that doesn't want their specific LIR to deal with their certification process, could either change LIR or change to a Direct Assignment End-User, but I'm guessing that would be a very small group of all PI customers. It is my experience that PI customers don't want to deal with the 'RIPE stuff' and/or are not very responsive into sorting their stuff out, as long as they have access to their addresses/objects. And yes, I do realize that having a third party in the middle (the LIR) might be seen as an additional security risk, specifically in dealing with certificates, but that could be a different discussion. If the CA-TF isn't planning to change the policy to include ALLOCATED PI, is there a set time-frame on when this will be proposed / implemented ? Regards, Erik Bais Erik Bais | A2B Internet BV | +31 299 707 115 ( Office ) | +31 6 5122 1952 ( Dutch cell ) | ebais@a2b-internet.com |
Hi, On Wed, Feb 09, 2011 at 04:50:20PM +0100, Erik Bais wrote:
- you're in favour of the general principle, want some details changed, but agree to pospone that to the next round of certificate-related proposals (like "this proposal does not cover PI" - yes, we know, the plan was to "start with the easy bits = PA").
Why is it stated :
This proposal only applies to IPv4 ALLOCATED PA blocks that were issued by the RIPE NCC and excludes early registration and legacy space, as well as blocks marked as ALLOCATED UNSPECIFIED or ALLOCATED PI.
As I said: "start with the easy bits". *This* proposal is "start with PA" (because the CA TF though that it would be easier to start with just a subset). When we get this done, the CA-TF - or anyone else who wants to driver this forward - can do another one for PI and/or ERX space. [..]
And to make things probably worse for the discussion, I would think that having the LIR manage this on behalf of their PI customers, might not be a bad idea, also because the location of the online certification site is in the LIR portal and this could be seen as one of the tasks a LIR does on behalf for their customers. PI LIR customers that doesn't want their specific LIR to deal with their certification process, could either change LIR or change to a Direct Assignment End-User, but I'm guessing that would be a very small group of all PI customers.
This sounds like a good rationale why we didn't cover PI in this initial proposal - more thought is needed. So please don't drag this specific thread into "how to do it with PI?" land, but focus on *this* proposal "do certificates for PA, or not?"
If the CA-TF isn't planning to change the policy to include ALLOCATED PI, is there a set time-frame on when this will be proposed / implemented ?
You're welcome to propose a parallel proposal for PI right away - but I think process-wise it would be easier to wait for a decision on this one, and then base the next on it. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi Gert, AP-WG Gert Doering wrote:
Dear Working Group,
as you might have noticed, this proposal is nicknamed "the icelandic saga" because it goes on and on and on and on...
We'd really like to bring this to conclusion, and for that, we need *feedback from the community*. So please let us know:
- this is what you want to see implemented
in principle, yes
- you're in favour of the general principle, but this specific wording is not what you want
exactly, in particular I am pretty unhappy to be asked to agree to a policy, because the NCC is - at the moment - feeling like having no policy mandate. But, at the same time, some quite important stuff is left to the CPS. My feeling is that that doesn't match. [...] I have sumbitted some suggestions and questions after the Rome meeting, based on the discussions there, (please see attachement) which do not seem to be reflected in the new version or being taken into account in the text.
thanks,
Gert Doering APWG chair
So, to sum it up, I do not oppose the idea or the proposal, but I think it is not good enough yet to become policy. If we can't do better, I'd prefer to continue on the basis of the provisional(?) CPS for now. Best regards, Wilfried.
Wilfried Woeber, UniVie/ACOnet wrote: [...]
So, to sum it up, I do not oppose the idea or the proposal, but I think it is not good enough yet to become policy. If we can't do better, I'd prefer to continue on the basis of the provisional(?) CPS for now.
Best regards, Wilfried.
After considering Rob's comment and Rüdiger's contribution, I'd like to change my position as quoted above to: Not perfect, flaws identitified and to be considered in a future version, but I support he proposal as circulated. Wilfried.
Hi, On 9 Feb 2011, at 6:00, Emilio Madaio wrote: [...]
The proposal will now undergo a two weeks Review Phase as explained in the previous message available at:
http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00022....
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2008-08
and the draft document at:
It would be useful if you could hyperlink from the draft policy document to the CPS and/or include the URL for the CPS in the body of the text. Incidentally, is the CPS considered an integral part of the policy? Section 5. 4. 4 implies that the CPS is likely to be updated in the future. If so, what kind of review will this WG be asked to do before a new CPS comes into effect? Also, what notice period is given before updating the CPS? Regards, Leo Vegoda
On 12 Feb 2011, at 00:46, Leo Vegoda wrote:
It would be useful if you could hyperlink from the draft policy document to the CPS and/or include the URL for the CPS in the body of the text.
That sounds like a a good idea.
Incidentally, is the CPS considered an integral part of the policy? Section 5.
The CPS is a practice statement that works within the boundaries of the Certification policy, but is not subject to the PDP. It merely describes how we implement the policy, i.e. what the RIPE NCC does operationally. Please see section "1.5.4. CPS approval procedures" of the CPS for details. We do, of course, value feedback on the CPS.
4. 4 implies that the CPS is likely to be updated in the future. If so, what kind of review will this WG be asked to do before a new CPS comes into effect? Also, what notice period is given before updating the CPS?
We don't have any strict notice period set for changes to the CPS. -Alex Band
I think that the proposed policy adequately covers the current certfication service: an hosted service for LIR's PA space. Two remarks: 1. full details of the current service are described in the Certification Practice Statement, which can be found at: www.ripe.net/lir-services/resource-management/certification/cps/ 2. given the development time of this proposal it is high time that work on the next version is started: up/down, PI space, legacy space. So, let's aprrove this proposed policy, and start working on a more comprhensive policy. Rob
participants (11)
-
Alex Band -
Emilio Madaio -
Erik Bais -
Gert Doering -
Jac Kloots -
James Blessing -
Leo Vegoda -
Nigel Titley -
Rob Blokzijl -
Sander Steffann -
Wilfried Woeber, UniVie/ACOnet