[bcop] [Ext] IPv6 prefix delegation BCOP document v.7

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: <https://lists.ripe.net/ripe/mail/archives/bcop/attachments/20170821/77923dbe/attachment.p7s>