Proposal 2024-01: Your Input needed!
Moin, TL;DR: If you: - Support the proposal; OR - Are ok with the proposal/see no issue in moving it forward; OR - Can live with the proposal if thereafter a thorough cleanup effort of the whole policy starts, please speak up now. ------------- The extended discussion phase of 2024-01 is drawing closer to its end. After the presentation at the last meeting there was a lot of positive feedback, and a couple of people promised to write on the mailinglist (which, contrary to offline comments, counts). The major comment during the session was Gert noting that the proposal uses a lot of text. My counter point was that the grown policy we currently have necessitates that amount of text to account for all the corner cases and (excuse my German) 'Sonderlocken' we created over the decades. My point on that is that fixing this needs a more comprehensive revision of the policy foundation, which will take us several years; My suggestion is: - Implement 2024-01 - Start working on the more fundamental clean-up thereafter, as this will take long In any case, I do need some feedback from you; Otherwise, this will not be able to move in any direction. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
Moin, I agree with others that the entire policy collection needs - at the least - a bit of a cleanup. That doesn't mean it all needs to be done at once, on the contrary - doing it in smaller chunks is more manageable for all. In re Gert's comment on a lot of text being used; this is only a valid criticism if the extra text is unnecessary - I don't think it is. I support the proposal in its current state and wish for its adoption. Q ------------------------------ 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, 14 Nov 2024 at 08:38, Tobias Fiebig via address-policy-wg < address-policy-wg@ripe.net> wrote:
Moin,
TL;DR: If you: - Support the proposal; OR - Are ok with the proposal/see no issue in moving it forward; OR - Can live with the proposal if thereafter a thorough cleanup effort of the whole policy starts, please speak up now. -------------
The extended discussion phase of 2024-01 is drawing closer to its end.
After the presentation at the last meeting there was a lot of positive feedback, and a couple of people promised to write on the mailinglist (which, contrary to offline comments, counts).
The major comment during the session was Gert noting that the proposal uses a lot of text. My counter point was that the grown policy we currently have necessitates that amount of text to account for all the corner cases and (excuse my German) 'Sonderlocken' we created over the decades.
My point on that is that fixing this needs a more comprehensive revision of the policy foundation, which will take us several years;
My suggestion is: - Implement 2024-01 - Start working on the more fundamental clean-up thereafter, as this will take long
In any case, I do need some feedback from you; Otherwise, this will not be able to move in any direction.
With best regards, Tobias
-- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://e.as207960.net/w4bdyj/XscoyvTD4ZWrORgR 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/g0k5BWNMl2rmyVRC
+1 On 14 November, 2024 09:12 CET, Q Misell via address-policy-wg <address-policy-wg@ripe.net> wrote: Moin, I agree with others that the entire policy collection needs - at the least - a bit of a cleanup.That doesn't mean it all needs to be done at once, on the contrary - doing it in smaller chunks is more manageable for all. In re Gert's comment on a lot of text being used; this is only a valid criticism if the extra text is unnecessary - I don't think it is. I support the proposal in its current state and wish for its adoption. Q______________________________________________________________________________ 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, LEI 875500FXNCJPAPF3PD10. ICO register №: 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, 14 Nov 2024 at 08:38, Tobias Fiebig via address-policy-wg <address-policy-wg@ripe.net> wrote: Moin, TL;DR: If you: - Support the proposal; OR - Are ok with the proposal/see no issue in moving it forward; OR - Can live with the proposal if thereafter a thorough cleanup effort of the whole policy starts, please speak up now. ------------- The extended discussion phase of 2024-01 is drawing closer to its end. After the presentation at the last meeting there was a lot of positive feedback, and a couple of people promised to write on the mailinglist (which, contrary to offline comments, counts). The major comment during the session was Gert noting that the proposal uses a lot of text. My counter point was that the grown policy we currently have necessitates that amount of text to account for all the corner cases and (excuse my German) 'Sonderlocken' we created over the decades. My point on that is that fixing this needs a more comprehensive revision of the policy foundation, which will take us several years; My suggestion is: - Implement 2024-01 - Start working on the more fundamental clean-up thereafter, as this will take long In any case, I do need some feedback from you; Otherwise, this will not be able to move in any direction. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl ----- 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/
Hi, On Thu, Nov 14, 2024 at 09:12:31AM +0100, Q Misell via address-policy-wg wrote:
In re Gert's comment on a lot of text being used; this is only a valid criticism if the extra text is unnecessary - I don't think it is.
Why do you think duplicating the definition of "end site" is needed, or reasonable? This is a definition of a legal or physical entity, it needs to be totally independent of "what are you going to do with it". I promised to send more review and will... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
This is a definition of a legal or physical entity, it needs to be totally independent of "what are you going to do with it".
For the purpose of this policy a definition of a legal entity seems useless to me. RIPE policy for assignment is almost always based on how the space is being used, not abstract legal concepts. ------------------------------ 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, 14 Nov 2024 at 11:52, Gert Doering <gert@space.net> wrote:
Hi,
On Thu, Nov 14, 2024 at 09:12:31AM +0100, Q Misell via address-policy-wg wrote:
In re Gert's comment on a lot of text being used; this is only a valid criticism if the extra text is unnecessary - I don't think it is.
Why do you think duplicating the definition of "end site" is needed, or reasonable? This is a definition of a legal or physical entity, it needs to be totally independent of "what are you going to do with it".
I promised to send more review and will...
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On Thu, Nov 14, 2024 at 12:33:48PM +0100, Q Misell wrote:
This is a definition of a legal or physical entity, it needs to be totally independent of "what are you going to do with it".
For the purpose of this policy a definition of a legal entity seems useless to me. RIPE policy for assignment is almost always based on how the space is being used, not abstract legal concepts.
"end site" needs to be something which is tangible and well-defined. It is not a different thing for IPv4, IPv6, PA or PI. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 14. 11. 24 12:38, Gert Doering wrote:
Hi,
On Thu, Nov 14, 2024 at 12:33:48PM +0100, Q Misell wrote:
This is a definition of a legal or physical entity, it needs to be totally independent of "what are you going to do with it".
For the purpose of this policy a definition of a legal entity seems useless to me. RIPE policy for assignment is almost always based on how the space is being used, not abstract legal concepts.
"end site" needs to be something which is tangible and well-defined. It is not a different thing for IPv4, IPv6, PA or PI.
Agreed... my suggestion would be to define the "end-site" in a separate policy document - and define it once for good. Cheers, Jan
Moin, On Thu, 2024-11-14 at 13:54 +0100, Jan Zorz - Go6 wrote:
Agreed... my suggestion would be to define the "end-site" in a separate policy document - and define it once for good.
Which is, as I said, on my todo. However, the plan will take some time, which is why I believe that fixing the operational issue of PI assignments first, and then starting the general policy overhaul is more reasonable. The idea would be an approach that allows for (even sometimes radical) improvements, clarifications, and re-formating, without disrupting existing policies, while still enabling a small-badge-principle for changes. I'd be happy to have you join such an effort. :-) (Also: With the current plan it should be far easier to have smaller/contained documents that can be completed in a reasonable time with reasonable effort.) With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
Moin,
On Thu, 2024-11-14 at 13:54 +0100, Jan Zorz - Go6 wrote:
Agreed... my suggestion would be to define the "end-site" in a separate policy document - and define it once for good.
Which is, as I said, on my todo. However, the plan will take some time, which is why I believe that fixing the operational issue of PI assignments first, and then starting the general policy overhaul is more reasonable. Yes, agreed. Let's fix the PI first and then think of fixing the bigger
On 14. 11. 24 14:10, Tobias Fiebig via address-policy-wg wrote: thing - so I agree that your proposal should be accepted and implemented. Cheers, Jan
Hello Gert,
Why do you think duplicating the definition of "end site" is needed, or reasonable? This is a definition of a legal or physical entity, it needs to be totally independent of "what are you going to do with it".
First, end-site is _not_ a definition of a "legal or physical entity", see the discussion that, for example, may make two physically distinct locations one end-site; It is more a description of a relationship of an entity needing addresses to those physical/topological locations. This also leads to the core of the issue, why I want to separate this definition: 'end-site' is interwoven with assignment policies. However, the addressing needs between PI and PA holders differ, mostly due to the nature of PI as an independently routed resource. An 'end- site' for PA may very well be a single host (there may be two CPEs in a single physical end-site), while for PI that end-site should only get a single /48. Similarly, there is a major concern about PI being abused by ISPs for providing dialup/ISP services with PI. Splitting the end-site definitions between PA and PI makes it significantly easier to clearly distinguish that.
I promised to send more review and will...
As I said before, really appreciated! Also, please do not understand the following as criticism. I just want to highlight the difficult situation delayed feedback puts me in as a proposer. However, the PDP has several deadlines that need to be held, and I already have Angela in my inbox asking how I want to proceed. ;-) I understand that this likely is 'one of those things that is really important, and I need to get to it, but then suddenly $dayjob and $everything-else reality hit' for you (which i sadly have too many of as well); However, if the input comes too late it makes it difficult to handle it within the PDP framework. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
Afternoon, As it stands, I agree with Q here, and this policy is a good first step in the right direction. Overhauling everything in one go is not feasible, and this is the first brick to build a solid foundation with. I wish to see the proposal adopted and support it. Kind regards, and wishing you all a nice Thursday, Jori Vanneste On November 14, 2024 9:12:31 AM GMT+01:00, Q Misell via address-policy-wg <address-policy-wg@ripe.net> wrote:
Moin,
I agree with others that the entire policy collection needs - at the least
- a bit of a cleanup.
That doesn't mean it all needs to be done at once, on the contrary - doing
it in smaller chunks is more manageable for all.
In re Gert's comment on a lot of text being used; this is only a valid
criticism if the extra text is unnecessary - I don't think it is.
I support the proposal in its current state and wish for its adoption.
Q
------------------------------
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, 14 Nov 2024 at 08:38, Tobias Fiebig via address-policy-wg <
address-policy-wg@ripe.net> wrote:
Moin,
TL;DR: If you:
- Support the proposal; OR
- Are ok with the proposal/see no issue in moving it forward; OR
- Can live with the proposal if thereafter a thorough cleanup effort
of the whole policy starts,
please speak up now.
-------------
The extended discussion phase of 2024-01 is drawing closer to its end.
After the presentation at the last meeting there was a lot of positive
feedback, and a couple of people promised to write on the mailinglist
(which, contrary to offline comments, counts).
The major comment during the session was Gert noting that the proposal
uses a lot of text. My counter point was that the grown policy we
currently have necessitates that amount of text to account for all the
corner cases and (excuse my German) 'Sonderlocken' we created over the
decades.
My point on that is that fixing this needs a more comprehensive
revision of the policy foundation, which will take us several years;
My suggestion is:
- Implement 2024-01
- Start working on the more fundamental clean-up thereafter, as this
will take long
In any case, I do need some feedback from you; Otherwise, this will
not be able to move in any direction.
With best regards,
Tobias
--
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tobias@fiebig.nl
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:
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/g0k5BWNMl2rmyVRC
Hi all, I support a change of the current policy. We had a case ourselves (Anycast services) where we preferred a aggregatable prefix rather than individual /48s. Unfortunately, we could not convince the RIPE NCC during the discussion and ultimately opted for separate /48s instead of delaying the project further. In our network design a sub allocation from our PA space was not feasible. I can agree with Gert's concerns that the new policy version is very detailed. I fear that this problem might require a broader, more global perspective and may not be resolved easily. One potential solution might be to amend the policy to allow LIRs with PA space to more easily acquire larger PI allocations for infrastructure purposes. This would help in our mentioned case above. The question remains whether such a distinction would be desirable and broadly acceptable. There was also a discussion somewhere regarding the statement in section 2.9.2: "a Layer 2 connection between two End Sites does not make them one End Site as long as both End Sites have different routing policies." In my opinion, the "Layer 2" should simply be removed. The precise nature of the connection is irrelevant for this paragraph. As long as we have no alternative proposal, I fully support the current one and would like to see it accepted. Regards, Bene On 11/14/24 08:38, Tobias Fiebig via address-policy-wg wrote:
Moin,
TL;DR: If you: - Support the proposal; OR - Are ok with the proposal/see no issue in moving it forward; OR - Can live with the proposal if thereafter a thorough cleanup effort of the whole policy starts, please speak up now. -------------
The extended discussion phase of 2024-01 is drawing closer to its end.
After the presentation at the last meeting there was a lot of positive feedback, and a couple of people promised to write on the mailinglist (which, contrary to offline comments, counts).
The major comment during the session was Gert noting that the proposal uses a lot of text. My counter point was that the grown policy we currently have necessitates that amount of text to account for all the corner cases and (excuse my German) 'Sonderlocken' we created over the decades.
My point on that is that fixing this needs a more comprehensive revision of the policy foundation, which will take us several years;
My suggestion is: - Implement 2024-01 - Start working on the more fundamental clean-up thereafter, as this will take long
In any case, I do need some feedback from you; Otherwise, this will not be able to move in any direction.
With best regards, Tobias
-- Karlsruher Institut für Technologie (KIT) Scientific Computing Center (SCC) Benedikt Neuffer Netze und Telekommunikation (NET) Zirkel 2 Gebäude 20.20 Raum 156 76131 Karlsruhe Telefon: +49 721 608-46342 Fax: +49 721 608-47763 E-Mail: benedikt.neuffer@kit.edu Matrix: @iv4011:kit.edu Web: https://www.scc.kit.edu Sitz der Körperschaft: Kaiserstraße 12, 76131 Karlsruhe KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft Signaturversion: 24.3.0 beta
Hi all, I did not comment on this proposal earlier, as I had nothing to amend. I support this policy exactly as it has been proposed. Please accept and implement it. Further adjustments and clarifications (regarding end-sites etc) we can do afterwards, in smaller increments. Thanks and all the best, Matthias Fetzer On 11/14/24 08:38, Tobias Fiebig via address-policy-wg wrote:
Moin,
TL;DR: If you: - Support the proposal; OR - Are ok with the proposal/see no issue in moving it forward; OR - Can live with the proposal if thereafter a thorough cleanup effort of the whole policy starts, please speak up now. -------------
The extended discussion phase of 2024-01 is drawing closer to its end.
After the presentation at the last meeting there was a lot of positive feedback, and a couple of people promised to write on the mailinglist (which, contrary to offline comments, counts).
The major comment during the session was Gert noting that the proposal uses a lot of text. My counter point was that the grown policy we currently have necessitates that amount of text to account for all the corner cases and (excuse my German) 'Sonderlocken' we created over the decades.
My point on that is that fixing this needs a more comprehensive revision of the policy foundation, which will take us several years;
My suggestion is: - Implement 2024-01 - Start working on the more fundamental clean-up thereafter, as this will take long
In any case, I do need some feedback from you; Otherwise, this will not be able to move in any direction.
With best regards, Tobias
Hi, On Sat, Nov 16, 2024 at 05:11:23PM +0100, Matthias Fetzer wrote:
Further adjustments and clarifications (regarding end-sites etc) we can do afterwards, in smaller increments.
Rushing bad text and hoping someone will fix it afterwards is not really how policy development should be done. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (8)
-
Benedikt Neuffer
-
Gert Doering
-
Jan Zorz - Go6
-
Jori Vanneste
-
Matthias Fetzer
-
Max Emig
-
Q Misell
-
Tobias Fiebig