Adding IPs to 4.10 at the moment is functionally just throwing them away. At
ARIN 52 John Sweeting said that 4.10 has a greater than 30 year runway, and I
haven't seen anything since that suggests that's changed.
I'm not taking a stance on any of these proposals, just wanted to add that
clarificat
Every (non-legacy) ARIN ASN involves paying at least $250/year, so the concern
about abandoned organizations seems misplaced. The large number of 16bit ASNs
ARIN gets returned every year seems to support this as well (80% of ASNs ARIN
issued in 2023 were 16 bit).
Also, as with IP addresses, just b
Hi Bill and David,
Those are the 2 reasons for nibble alignment that I was aware of. Personally, I
think once we get to a large enough allocation size those reasons aren't worth
the wasted address space, but as that's not the purpose of this policy so we
should probably agree to disagree on that p
n oder ihren Inhalt auf
> welche Weise auch immer zu verwenden.
>
> This e-mail may contain confidential and/or privileged information. If you are
> not the intended recipient of this e-mail, you are hereby notified that
> saving, distribution or use of the content of this e-mail in any way
Hi David,
If I may, why do you believe nibble alignment is important? I agree that it is
generally preferable, but once we get to requests of a certain size (I would say
>/24, personally), I think the benefits are outweighed by conservation concerns.
John Sweeting at ARIN 53, as well as Chris Wood
Hi Owen,
The purpose isn't to remove the restrictions on use from the Special Purpose
sections (e.g. 4.4 / 4.10), but to make other sections that reference those
sections cleaner and easier to read. For example, 4.1.8 currently reads:
"Organizations which hold more than a /20 equivalent of IPv4 s
Hi all,
As the author of this policy I just wanted to chime in with a few responses:
First, as has been mentioned before, this change only applies to the amount of
space that may be given in a single allocation. If an organization is using its
IPv6 space efficiently (as defined later in Section 6
I support this policy as written.
Tyler
AS53727
On Fri, 2024-06-21 at 13:54 -0400, ARIN wrote:
> The following Draft Policy has been revised:
>
> * ARIN-2024-4: Internet Exchange Point Definition
>
> Revised text is below and can be found at:
>
> https://www.arin.net/participate/policy/drafts/
This seems like a big improvement. However, given that the requirements to
qualify for MDN are the same for IPv4 and IPv6, would it make sense to split
that out into a common location (maybe a new top level section, or a Section 2
definition)? Then the protocol specific differences (e.g. how being
I agree that we should work toward replacing all instances of "ISP" with "LIR"
in the entirety of the NRPM, and then retire 6.5.1a. However, my understanding
was that for IPv4, ARIN staff considered only LIRs that have a physical network
of some kind to be ISPs, and that therefore the 2 terms are n
What is the "massive hole in policy" that is closed by mandating the use of
Ethernet as the L2 protocol? The only concern I've seen raised in this (or the
IX definition) discussion was around Virtual IXes, but every virtual IX I know
uses Ethernet anyways. Plus, since they're virtual, even if they
>
> The language as proposed protects the future viability of a very established
> and very successful model. Let's not create a back door for address space
> that could harm that model over a philosophical desire to be protocol agnostic
> or future-proof.
>
> Regard
I like Owen's proposed language. I think it strikes the right balance between
being restrictive enough to prevent purely virtual IXes (which are cool, but
shouldn't qualify under 4.4) while not being overly prescriptive on how IX
operators need to design and run their IXes.
As a point of discussio
I support this change, but have a few suggestions:
1) I'd use Critical Internet Infrastructure (CII) as the official term for this
section; Critical Infrastructure seems a bit too vague.
2) Instead of "ARIN will reserve", should we change it to "ARIN has reserved",
since the reservation has alread
I support this change as written, assuming section is properly capitalized (e.g.
not capitalized).
Tyler O'Meara
AS53727
On Tue, 2024-05-21 at 12:27 -0400, ARIN wrote:
> On 16 May 2024, the ARIN Advisory Council (AC) accepted “ARIN-prop-334: 6.5.1a
> Definition Update” as a Draft Policy.
>
> Dra
Overall I support this change, but I have a few nitpicks:
1) We should only include abbreviations/other names for the term if they're
actually used in the NRPM; I think future text that uses this definition would
be clearer if we selected a single acronym.
2) I would remove the reference to Ethern
To make this discussion concrete, I've written a quick proposed text below at
the end of this email. The main changes I made:
* Removed the term "micro-allocation", as /24s are now the default allocation.
* Moving the section granting gTLD operators justification of a /23 to a
different section
* R
I would consider both the non-globally routed peering LAN, as well as a /24 for
globally routed administrative uses (IXManager, Looking Glass, even the IX's
website) to be valid uses for 4.4 space.
In my opinion, any use of IPs on the peering LAN, so long as it's used to peer
on the IX, is legitim
I figure I'll chime in with my opinion.
The number 1 priority for remaining IPv4 addresses should be to enable the
transition to IPv6. NRPM Section 4.10 already covers this well, and should that
pool of addresses get in danger of being depleted, Section 4.1.7 gives this pool
priority over general
Replying to just the following part:
> Well, that's another discussion. Newcomers don't have any and cannot do
> anything without a minimal IPv4 even if they prefectly deploy IPv6.
> Trying to force things only towards IPv6 ignoring the practical side sounds
> more like ideology.
Any organizatio
Overall, I support this change as I think it resolves a common source of
confusion and helps to clean up legacy terminology and phrasing.
I did have a couple of comments:
In the change to section 4.2.2, the word "automatically" was dropped. I think
the "automatically" qualifier helps to get acros
Both Bill and John's definitions seem reasonable to me.
Tyler
On Thu, 2024-02-08 at 06:50 -0800, William Herrin wrote:
> On Thu, Feb 8, 2024 at 5:37 AM John Curran wrote:
> > An Organization Identifier (Org ID) is an identifier assigned to entities
> > that wish to participate in the Internet Nu
That's an interesting point Roman, but I think that ship may have
already sailed.
If a privacy law covers the registrant of an Org ID, presumably it also
covers POC records as well, which are also published in WHOIS. Do we
need to prohibit POC records from being natural persons as well
(genuine qu
I agree with Owen here. Per the problem statement, this draft policy is
intended solely to improve clarity, and not to effect any material
change in the NPRM. As such, I would propose that the phrase "business,
non-profit corporation, or government entity" in the proposed draft
policy be replaced w
24 matches
Mail list logo
