isThereClarity's comments

Daniel Karrenberg, co-author of RFC1918, said this 2017-10-06 on the NANOG mailing list:

  > On 05/10/2017 07:40, Jay R. Ashworth wrote:
  > > Does anyone have a pointer to an *authoritative* source on why
  > >
  > > 10/8
  > > 172.16/12 and
  > > 192.168/16
  > >
  > > were the ranges chosen to enshrine in the RFC? ...
  > 
  > The RFC explains the reason why we chose three ranges from "Class A,B &
  > C" respectively: CIDR had been specified but had not been widely
  > implemented. There was a significant amount of equipment out there that
  > still was "classful".
  > 
  > As far as I recall the choice of the particular ranges were as follows:
  > 
  > 10/8: the ARPANET had just been turned off. One of us suggested it and
  > Jon considered this a good re-use of this "historical" address block. We
  > also suspected that "net 10" might have been hard coded in some places,
  > so re-using it for private address space rather than in inter-AS routing
  > might have the slight advantage of keeping such silliness local.
  > 
  > 172.16/12: the lowest unallocated /12 in class B space.
  > 
  > 192.168/16: the lowest unallocated /16 in class C block 192/8.
  > 
  > In summary: IANA allocated this space just as it would have for any
  > other purpose. As the IANA, Jon was very consistent unless there was a
  > really good reason to be creative.
  > 
  > Daniel (co-author of RFC1918)

https://web.archive.org/web/20190308152212/https://mailman.n...

I am a user of puppet and have used many of the community puppet modules developed under the Vox Pupuli group ( They have 175 modules on puppet forge: https://forge.puppet.com/modules/puppet ). Looks like I've missed the news and they're (soft) forking puppet as OpenVox; does the following appear right?

Summary of what I can find: It seems Perforce have announced they will stop providing open source puppet's public binaries and the public package repositories. Private access to their binaries will require either developer license (with one of the limits being 25 nodes) or a commercial license. Secondly, they are reducing public source code contributions to Puppet. A response to this by Overlook InfraTech / Vox Pupuli has resulted in a fork called OpenVox.

Regarding the first issue, Perforce's halt to providing open source puppet's public binaries / package repos: Posted on the "Puppet By Perforce" blog 2024-11-07 https://www.puppet.com/blog/open-source-puppet-updates-2025

> In early 2025, Puppet will begin to ship any new binaries and packages developed by our team to a private, hardened, and controlled location.

> Community contributors will have free access to this private repo under the terms of an End-User License Agreement (EULA) for development use. There will be no license changes for the open source version of Puppet.

This is backed up by nightlies suspended from 2024-11-06 https://nightlies.puppet.com/apt/dists/index.html . From the blog post, it would appear that access to binaries is only going to be free for 25 nodes.

> The new development license is an EULA that allows developers free access to our hardened Puppet releases (up to 25 nodes). Capacities higher than 25 nodes will require a Puppet Labs Support Commercial License.

> Community developers will continue to have access to binaries and packages for development purposes under a new developer license (EULA).

Releases prior to the annoucement appear available, but there is no statement suggesting that will remain in the blog post. I have a few dozen physicals and a few dozen VMs running puppet but don't have a commercial license, so this will impact me.

Regarding the second issue, reducing public source code contributions to Puppet, there is this from the same blog post:

> We will release hardened Puppet releases to a new location and will slow down the frequency of commits of source code to public repositories.

Regarding the community response, it seemed to start with providing community packages and has become the "soft fork"? From https://voxpupuli.org/openvox/

> OpenVox started life as a Puppet™ mirror by Overlook InfraTech to continue providing community packages when Perforce discontinued public packaging efforts in late Fall of 2024. It soon became clear that they were also moving all further Puppet™ development to internal forks and ceasing development on open source Puppet™. A community fork using Overlook InfraTech's packaging pipeline was the inevitable response.

> We consider OpenVox a soft-fork because we intend to maintain downstream compatibility for as long as we are able. As such, we've created a Puppet™ Standards Steering Committee to set the direction of features and language evolutions and have invited Perforce to participate.

Perhaps, but there’s a light hearted moment going on.

Context

- https://www.man7.org/linux/man-pages/man7/roff.7.html

- https://man7.org/linux/man-pages/man1/more.1.html

- https://man7.org/linux/man-pages/man1/less.1.html

- https://man7.org/linux/man-pages/man1/apropos.1.html

sendmail 8.18.1 includes patches to correct this behaviour (and options to turn it back on) due to its role in SMTP smuggling, CVE-2023-51765. See https://ftp.sendmail.org/RELEASE_NOTES

  sendmail is now stricter in following the RFCs and rejects
  some invalid input with respect to line endings
  and pipelining:
  ...snip...
  - Accept only CRLF . CRLF as end of an SMTP message
    as required by the RFCs, which can disabled by the
    new srv_features option 'O'.
  - Do not accept a CR or LF except in the combination
    CRLF (as required by the RFCs).  These checks can
    be disabled by the new srv_features options
   'U' and 'G', respectively.  In this case it is
   suggested to use 'u2' and 'g2' instead so the server
   replaces offending bare CR or bare LF with a space.
   It is recommended to only turn these protections off
   for trusted networks due to the potential for abuse.

From my understanding of that abstract, it's the _pre-agricultural_ erosion rates are lower than assumed, so the tolerance value for agricultural land has been set too high.

From the conclusion:

> We find that pre-agricultural erosion rates in the midwestern United States are on the order of 0.0001–0.1 mm yr–1. Soil loss tolerance values of 1 mm yr–1 are one to four orders of magnitude higher than pre-agricultural erosion rates. Similarly, the agricultural erosion rates are 10–1000 times greater than the preagricultural erosion rates. Our results indicate that tolerable soil erosion, as currently defined, will lead to the depletion of midwestern soils.