From jan at go6.si Tue Aug 8 11:02:23 2017 From: jan at go6.si (Jan Zorz - Go6) Date: Tue, 8 Aug 2017 11:02:23 +0200 Subject: [bcop] Version 6 of IPv6 prefix delegations BCOP is out Message-ID: <50e7ae7f-4cb5-48a8-8a0a-40fb299e588e@go6.si> Dear RIPE BCOP TF, We received offline some good and valuable comments from MarcoH, addressed them and issued the version 6 of the document draft. https://sinog.si/docs/draft-IPv6pd-BCOP-v6.pdf Please, read and comment, if you think that we need to carry on with editing this document. If not, I would like to see if we can reach a consensus to move forward and ask RIPE staff to do the language check and publish this document as RIPE BCP. Any comments? Suggestions? For v6_pd_BCOP co-authors team, Jan ?or? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3976 bytes Desc: S/MIME Cryptographic Signature URL: From jan at go6.si Mon Aug 21 12:18:40 2017 From: jan at go6.si (Jan Zorz - Go6) Date: Mon, 21 Aug 2017 12:18:40 +0200 Subject: [bcop] IPv6 prefix delegation BCOP document v.7 Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3976 bytes Desc: S/MIME Cryptographic Signature URL: From paul.hoffman at icann.org Mon Aug 21 16:40:35 2017 From: paul.hoffman at icann.org (Paul Hoffman) Date: Mon, 21 Aug 2017 14:40:35 +0000 Subject: [bcop] [Ext] IPv6 prefix delegation BCOP document v.7 In-Reply-To: References: Message-ID: <167C7835-2951-468F-BFA9-886566C8A536@icann.org> 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 From zorz at isoc.org Mon Aug 21 16:56:54 2017 From: zorz at isoc.org (Jan Zorz - ISOC) Date: Mon, 21 Aug 2017 16:56:54 +0200 Subject: [bcop] [Ext] IPv6 prefix delegation BCOP document v.7 In-Reply-To: <167C7835-2951-468F-BFA9-886566C8A536@icann.org> References: <167C7835-2951-468F-BFA9-886566C8A536@icann.org> Message-ID: <7ba79a31-8eda-157b-82d5-40aee2db1790@isoc.org> 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: ------------------------------------------ "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: From benno at NLnetLabs.nl Tue Aug 22 15:44:12 2017 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Tue, 22 Aug 2017 15:44:12 +0200 Subject: [bcop] Abstract of the MANRS BCOP In-Reply-To: <5309160f-9bae-1ab4-facc-661573a253c9@isoc.org> References: <5309160f-9bae-1ab4-facc-661573a253c9@isoc.org> Message-ID: This reminder is directed to the BCOP TF mailing list subscribers. In the BCOP TF meeting we announced a period of last comments on the extended MANRS BCOP abstract draft and to publish this as a RIPE document. We want to close the comments period in two weeks and move the draft further in the process to make it a RIPE document. Note that the draft is an abstract of the MANRS BCOP and references the full MANRS BCOP that includes examples and can be extended in the future. The MANRS extended abstract published as a RIPE document will be a stable document. Best regards, ? Benno > On 8 May 2017, at 13:31, Andrei Robachevsky wrote: > > Hi, > > The final version of the MANRS BCOP has been published on the MANRS > website: https://www.manrs.org/bcop/. Both a PDF and an online versions > are available. > > However, to bring the bcop process to an official closure, chairs > suggested that instead of publishing the MANRS BCOP as a RIPE document, > that might be too constrained, we publish just an abstract. And once the > BCOP global repository is in place, we can put it there in whatever > format is most convenient. > > I am attaching the abstract for your review and comments. > > Regards, > > Andrei > <20170508-MANRS-BCOP-abstract.txt><20170508-MANRS-BCOP-abstract.docx> -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/