IPv6 prefix delegation BCOP document v.7
Dear BCOP TF, Version 7 of IPv6 prefix delegation BCOP document was issued some time ago and I would like to propose that we move forward towards making this document a stable RIPE BCP document. https://www.sinog.si/docs/draft-IPv6pd-BCOP-v7.pdf We received quite a number of comments in RIPE IPv6 WG and now it seems that v.7 of the document is satisfactory enough (judging from lack of additional comments). Should we go forward and issue a week long last call and then try to move forward together with RIPE IPv6 WG and get a document number from RIPE NCC? Cheers, Jan
Greetings. The current version is OK, but it *might* be improved by saying that the advice in it contradicts various RFCs, and list those RFCs. Pro: - Readers of the BCOP who implement it will likely be told "you're doing it wrong, RFC AAAA and BBBB say to do it differently". Having your readers blindsided is bad. - Listing the differences shows that you thought about them, so no one can accuse you of not knowing about RFC AAAA and BBBB. Con: - You cause your readers to question your conclusions without being able to prove why your conclusions are better than those in the RFCs. This could lead your readers to think "I will wait until everyone agrees", which unfortunately translates into "I will make no changes to my configurations ever". So, yes, I'm ambivalent about this proposal. --Paul Hoffman
On 21/08/2017 16:40, Paul Hoffman wrote:
Greetings. The current version is OK, but it *might* be improved by saying that the advice in it contradicts various RFCs, and list those RFCs.
Hey, Thnx for pointing it out... We thought about that, but decided not to go this path, as we would just like to document what is the current best operational practice that avoids problems while deploying IPv6 in in real production world. Fighting with RFC's would not help in this case, because if we do that - we would have to go into endless arguing why RFC recommendation is sometimes different than reality.
Pro:
- Readers of the BCOP who implement it will likely be told "you're doing it wrong, RFC AAAA and BBBB say to do it differently". Having your readers blindsided is bad.
Are you sure that we at the end even say something that is not compliant with RFCs? Recommending /56 and /48 as prefix delegations is a valid option according to RFCs and static way of assignments are also. We may be a little harsh on other options, but we just want to save operators from many troubles that comes with such decisions.
- Listing the differences shows that you thought about them, so no one can accuse you of not knowing about RFC AAAA and BBBB.
In complete honesty - operators rarely reads and sticks to every word in RFCs when it comes to deployment of any of new protocols and solutions - they use what is available from vendors and try to figure out how to deploy it in least painful way - and this is where BCOP documents come to play ;)
Con:
- You cause your readers to question your conclusions without being able to prove why your conclusions are better than those in the RFCs. This could lead your readers to think "I will wait until everyone agrees", which unfortunately translates into "I will make no changes to my configurations ever".
...and that is the reason why BCOP documents needs to be a product of community and published with quite solid consensus from experts in the field. There are reasons why we are on version 7 of the draft and many people in the acknowledgements section ;)
So, yes, I'm ambivalent about this proposal.
Thank you very much! After we publish this one - we'll be looking at what's the next speed bump in operators deployment of IPv6 - and try to address it. If there are any ideas what this is (or should be), please send the idea and we'll have a look, form a good team and start working on a next thing ;) Cheers and thnx, Jan
--Paul Hoffman
-- Jan Zorz Internet Society mailto:<zorz@isoc.org> ------------------------------------------ "Time is a lake, not a river..." - African
participants (3)
-
Jan Zorz - Go6 -
Jan Zorz - ISOC -
Paul Hoffman