![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Geoff,
Is everyone happy with this course of action?works for me
Good.
I would avoid this - the problem is that if a future rfc3330 revision drops another block from the reserved set, then this raises the question of if you really meant it if the explicit documentation is missing.
I'd like to push back a little on this. My personal preference is a specification style which makes everything very explicit. If a block has been used for examples, I think we owe it to the reader to say what its fate was. I do agree though that we should not set a precedent that every block not listed in RFC 3330(bis)* needs to be explicitly mentioned or else they are still somehow reserved. But maybe there is a way to write the text that this becomes clearer. How about this:
Note that 128.66.0.0/16 has been used for some examples in the past. However, this role was never specified formally and RFC 3330 confirmed that this block has no special role by not listing it. Jari
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.