This is why I suggested the 10.44.x.x and 192.168.44.x
blocks -- the '*44*'
is a consistent clue for documentation, and yet would not be
routable beyond the LAN if copied.
This may be a topic for the TAC
On Mon, Apr 5, 2021 at 12:45 PM Antonios Chariton (daknob) via 44Net <
44net(a)mailman.ampr.org> wrote:
I’ve seen a company that had problems with people
copy pasting blindly and
not changing the settings use something equivalent to 44.256.0.0. Since 256
is not valid, it could break, and you’d go back and see you needed to
replace something. Interesting solution that was guaranteed to work :)
On 5 Apr 2021, at 21:40, Jason McCormick via
44Net <
44net(a)mailman.ampr.org> wrote:
RFC5737 doesn't support this use case which
is why I asked in the first
place about a dedicated documentation block to begin
with.
The point of having a 44Net documentation block
is so that it's
painfully obvious that "YOUR ALLOCATION GOES HERE".
The point of posting
stuff on the GitLab server and hopefully other places is precisely to "copy
documentation" and use it. Yes, there will always be those people who
literally apply no thought to cutting-and-pasting in something but we can't
do anything about that. My interest is having configuration that someone
CAN literally copy/paste, make some very minor tweaks, and get their system
running. Using a random RFC5737 address block which likely most people have
never heard of isn't going to be helpful in reducing the learning curve and
confusion.
However using the test space probably makes sense
since that is the
literal allocation titles of RFC5737 are TEST-NET-1, -2, and -3.
> For what it's worth, I will be using 44.128.50.0/24 for my stuff.
>
> Jason
------------------------------
John D. Hays - K7VE
Kingston, WA
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org