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]/
[bcop] [Ext] IPv6 prefix delegation BCOP document v.7
- Previous message (by thread): [bcop] [Ext] IPv6 prefix delegation BCOP document v.7
- Next message (by thread): [bcop] Abstract of the MANRS BCOP
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jan Zorz - ISOC
zorz at isoc.org
Mon Aug 21 16:56:54 CEST 2017
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 at isoc.org> ------------------------------------------ "Time is a lake, not a river..." - African -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4201 bytes Desc: S/MIME Cryptographic Signature URL: </ripe/mail/archives/bcop/attachments/20170821/77923dbe/attachment.p7s>
- Previous message (by thread): [bcop] [Ext] IPv6 prefix delegation BCOP document v.7
- Next message (by thread): [bcop] Abstract of the MANRS BCOP
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ BCOP Archives ]