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/[email protected]/
[address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting
- Previous message (by thread): [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting
- Next message (by thread): [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Kai 'wusel' Siering
wusel+ml at uu.org
Wed May 16 16:46:57 CEST 2018
On 16.05.2018 14:19, JORDI PALET MARTINEZ via address-policy-wg wrote: > Hi all, > > I've been asked to state what is the problem. > > I think it was clear in my slides, but anyway, here we go with all the problems I see: > > 1) The current policy text says "Providing another entity with separate addresses (not prefixes)". > To me this is inconsistent addresses instead of an address vs not-prefixes. I think I mentioned this on 2016-04 already; any single address is always a prefix as well, /128 in v6. But your slide 3 shows nicely why I strictly oppose more meddling with this paragraph. We went from 42 words in »2.6 Assign« to 98 in the current policy text, which your proposal would boost to a staggering 134 words. And that's without the necessary – but yet missing – definitions of »non-permanently« or what happens on links that are not »operated« by the assigment holder (i. e. a link a peer operates cannot use numbers from my assignment?). Not to mention the loophole that narrow band services are explicitely are allowed now — given 100 GBit/sec links are common these days, 10 to 100 MBit/sec is definitely narrow band today, right? But there is a point everyone seems to happily ignore: The text discussed last time, as well as this time, changes the basic definition of what an assignment is and "to assign" means. As such, that definition applies everywhere where the policy document talks about assignments. Like e. g. in »5.4.3. Assignment to operator's infrastructure«: »An organisation (i.e. ISP/LIR) may assign a network prefix per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.« The more text we put into 2.6, the more difficult it will become to not violate the policy, for End Users, ISPs and even for LIRs. Any change to "2.6 Assign" applies to PA and PI space alike. > 3) If we allow sub-assignments, what is then the difference in between IPv6 PA and PI ? You are barking at the wrong tree. "2.6 Assign" applies to PI and PA and disencourages sub-assignments (of any assigned space) "to other parties" anyway. > So, I think it is clear we have not just one problem? I do not see a real problem with the text of ripe-699 – unless I start nit-picking and take the policy apart, word by word. If one *wants*, the *intention* of the policy can be understood. If one does not want to understand the intention, more words will simply make things worse, not better. Regards, -kai
- Previous message (by thread): [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting
- Next message (by thread): [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]