This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ncc-services-wg@ripe.net/
[ncc-services-wg] Policy proposal for services to legacy Internet resource holders
- Previous message (by thread): [ncc-services-wg] Policy proposal for services to legacy Internet resource holders
- Next message (by thread): [ncc-services-wg] Policy proposal for services to legacy Internet resource holders
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nigel Titley
nigel at titley.com
Wed Aug 29 13:43:44 CEST 2012
Gert, As usual you've done your excellent analysis and statement On 29/08/2012 11:21, Gert Doering wrote: > Hi, > > On Wed, Aug 29, 2012 at 11:08:27AM +0100, Nigel Titley wrote: >> This actually raises an interesting issue. Are there any circumstances >> in which RIPE policy would apply to legacy space? Could, for example, >> the AP-WG unilaterally propose a policy that annexed legacy space? > > I don't think so. > > APWG policy governs under which rules the RIPE NCC gives out (and possible > takes back from) internet numbers from the RIPE NCC "pool" to "consumers" > - and this sort of obviously only applies to numbers that the RIPE NCC has > been given authority over, via the IETF->IANA->RIPE NCC chain of delegation. Good.... and presumably the legacy holders could voluntarily agree to submit to address policy, although it would seem that section 6.3 of the proposed policy limits the actions of legacy holders in this respect and indeed it attempts to place bounds on the authority of the community itself for all time (which always gives me pause for thought). > >> I've heard this suggested several times. And of course, if RIPE policy >> doesn't apply to legacy space, why are the legacy holders raising a >> proposal at all? > Now, the RIPE NCC provides services to legacy address space holders that > happen to be in the RIPE service region: > > - RIPE database and routing registry > "who 'owns' it and who is authorized to announce it?" > - reverse DNS delegation > - potentially: RPKI certificates > > due to the way RPSL-authentication and DNS tree'ing work, this is not > easy to do in a non-hierarchical structure, so "having this done by > the RIPE NCC" makes sense from a technical point of view. > > OTOH, I can see that the NCC wants to see some money in exchange for > the expenses running all this (and that seems to make sense as well :-) ). Yes, and bear in mind ultimately the RIPE NCC membership should be consulted about this. It's their money providing the service. > > Now, the policy proposal raised here is not an *address space* policy > proposal, but an *ncc service* policy proposal - which governs the way > the NCC runs their, uh, services. And I think this is a reasonable > approach - find something that the ERX holder community and the RIPE > NCC is happy with, walk it through an open consensus process, and then > nobody can argue that the RIPE NCC is going out and bullying/blackmailing > ERX holders over their addresses... I agree completely with this. This is obvious the best approach, but I still have some reservations about the wording of the proposal as so far seen. Perhaps when it is formally published we could discuss this. > > (As far as I understand the system, the ERX space would still not be > part of the "normal" APWG policy regime - like "RIPE *address* policies > have no influence on how the addresses are distributed by the holder's > organizationo to 3rd parties" and "no audits", etc.) > Yes, and this proposal explicitly says that this will be the case for all time. Nigel
- Previous message (by thread): [ncc-services-wg] Policy proposal for services to legacy Internet resource holders
- Next message (by thread): [ncc-services-wg] Policy proposal for services to legacy Internet resource holders
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]