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/address-policy-wg@ripe.net/
[address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
- Previous message (by thread): [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
- Next message (by thread): [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Kurt Erik Lindqvist
kurtis at kurtis.pp.se
Thu Jun 17 09:58:21 CEST 2004
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-16, at 12.02, amar at telia.net wrote: > > >> Why not? If I have a large infrastructure, or is in the start-up phase >> or going through a network merger etc. I might have a lot of internal >> infrastructure but not many customer allocations. I fail to see why we >> would not include own allocations as those will be coming out of your >> block anyway. > > The policy states that You can assign a /48 per POP - lets say > a "broadband POP". If that should include the users asignments > or not is not defined. Right. And I am arguing that those /48s should be included in the 200 limit. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNFPIaarNKXTPFCVEQI/lgCg2AMfFbKbRljx9vJGfBdzf7/zNsQAn2rq B0DIIaq+XYHNPoc9ATyFXN4K =FFGL -----END PGP SIGNATURE-----
- Previous message (by thread): [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
- Next message (by thread): [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]