> This is, explicitly, the case you mentioned, no? On second reading, yes it is.
> The point of pain from the past was actually the phrasing in 2.6 I don't see the problematic phrasing in the old version of 2.6. Can you point it out please? > The end-user will, in general, only hold one PI assignment covering their needs at a time. Perhaps the policy could be reworded to make this clearer. ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Thu, 29 Aug 2024 at 11:01, Tobias Fiebig via address-policy-wg < [email protected]> wrote: > > Moin, > > > > The new text for 2.6 seems to not allow assignment of a /64 to an > > appliance connected to the End User's network. As a VPS provider (and > > as many other VPS providers do) I allocate a /64 to every VPS that > > the customer is free to use however they want within the VPS. > > The policy says that the purpose is to allow this (imo correctly so) > > but on the most pedantic reading the policy itself doesn't seem to > > allow that. > > Using, most likely, PA at the moment, I guess. ;-) > > Despite, the policy states: > > Providing connectivity to another entity inside the assignment holder’s > network located at the same geographical End Site as the holder’s > network with a prefix size of /56 or longer from the assignment is not > considered a sub-assignment. This includes letting visitors connect to > the assignment holder's network, providing static addresses when > connecting a server or appliance to an assignment holder's network, > > This is, explicitly, the case you mentioned, no? > > > Tiny nit: 2.6 should make an explicit reference to "best practices" > > being IETF BCP157, just for clarity for the uninformed reader. > > Can be fixed. > > > > I think 7.1 should be explicit that prefixes shorter than a /48 can > > be assigned to one End Site, as this has been a major pain point in > > the past. > > The general rule of thumb is one /48 per end-site, unless addressing > (2.7) or routing reasons require more. The point of pain from the past > was actually the phrasing in 2.6, where an oxford comma was missing, > restricting it to addressing needs only in practice. > > > > The nibble boundary assignment mechanism is neat, I like it! > > Thanks. > > > Does "All previously issued PI assignments must be returned to the > > RIPE NCC after renumbering once the new PI assignment has been issued > > or an existing one was extended" mean to imply that an End User will > > only ever receive 1 PI assignment under this new policy but that it > > can be expanded as much as is needed to accommodate addressing needs? > > If so this should be more explicit. > > The end-user will, in general, only hold _one_ PI assignment covering > their needs at a time. Exceptions are: > > - A more specific policy permits more Assignments, e.g., if the IXP PI > policy would explicitly note PI prefixes to be additionally assigned, > due to the override of more specific policy (2nd par 7.1; Also there to > resolve the issue that, at the moment, the IXP policy is incompatible > with the general policy, as it allows /64 assignments) > - The end-user had received PI before the updated policy came into > effect and keeps (justified!) extending the renumbering period; Still, > _return_ is mandated, as this means the resources can no longer be > transferred (to counter hoarding). > - For the period of time during renumbering, given the prior resources > have not been assigned prior to the new version of the policy being > implemented. > > Furthermore, held PI can only be extended if unused space allows so, > see 7.1.2. Otherwise, a new assignment satisfying the addressing needs > will be made (with, recommended at least, an additional nibble left > unused for subsequent growth), and the EU has to renumber. > > Finally, the maximum size of PI is locked at 'a nibble less than the > smallest allocation', i.e., there cannot be a PI assignment larger than > a /36. > > > I support this policy and look forward to its refinement and > > implementation. > > Thank you, appreciated. > > With best regards, > Tobias > ----- > To unsubscribe from this mailing list or change your subscription options, > please visit: > https://e.as207960.net/w4bdyj/ZRhbv0gIFFblAIZg > As we have migrated to Mailman 3, you will need to create an account with > the email matching your subscription before you can change your settings. > More details at: https://e.as207960.net/w4bdyj/OCe9syVNvTrY5YAF
smime.p7s
Description: S/MIME Cryptographic Signature
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
