Hi all,
Resurrecting this after many weeks. We've reviewed all the comments and
have netted out with the following. Thoughts?
*Add the text between asterisks to 8.1*
*8.1. PrinciplesNumber resources are nontransferable and are not assignable
to any other organization unless ARIN has
> On Oct 21, 2021, at 20:05 , David Farmer via ARIN-PPML
> wrote:
>
> The problem I have with that is it strongly implies IPv6 isn’t ever
> transferable, even though it is through section 8.2.
If IPv6 becomes more generally transferrable, then section 2 can be updated
along side the other
That works for me.
Owen
> On Oct 21, 2021, at 19:06 , Chris Woodfield wrote:
>
> I think Joe’s got a good suggestion that I would support - define
> “transferable number resources” as IPv4 addresses and ASNs in Section 2, and
> go from there.
>
> -C
>
>> On Oct 21, 2021, at 5:39 PM,
The problem I have with that is it strongly implies IPv6 isn’t ever
transferable, even though it is through section 8.2.
A few thoughts;
1. Adding that resource types are considered “separately and
independently”, should eliminate the need to use the awkward “and/or”
construction, and we should
On Thu, Oct 21, 2021 at 22:06 Chris Woodfield wrote:
> I think Joe’s got a good suggestion that I would support - define
> “transferable number resources” as IPv4 addresses and ASNs in Section 2,
> and go from there.
>
> -C
>
Sort of saying the same thing differently. Im looking for the easy
I think Joe’s got a good suggestion that I would support - define “transferable
number resources” as IPv4 addresses and ASNs in Section 2, and go from there.
-C
> On Oct 21, 2021, at 5:39 PM, Martin Hannigan wrote:
>
>
>
> On Thu, Oct 21, 2021 at 14:53 Chris Woodfield
On Thu, Oct 21, 2021 at 14:53 Chris Woodfield wrote:
> I support this edit, for same reasons others have mentioned.
>
> If I’m recalling yesterday’s presentation correctly, it was ARIN Staff and
> Legal, not the AC, that determined that this language could not be
> implemented an editorial
> On Oct 21, 2021, at 11:53 , Chris Woodfield wrote:
>
> I support this edit, for same reasons others have mentioned.
>
> If I’m recalling yesterday’s presentation correctly, it was ARIN Staff and
> Legal, not the AC, that determined that this language could not be
> implemented an
I don’t believe it changes current practice, therefore it should qualify as
editorial.
(Things which clarify current practice and don’t change how ARIN handles
registration processes).
Nonetheless, I think the proposal is better with the amendment, so even if that
means it goes through the
On Thu, Oct 21, 2021 at 11:53:34AM -0700, Chris Woodfield wrote:
> I support this edit, for same reasons others have mentioned.
Same.
> If I???m recalling yesterday???s presentation correctly, it was
> ARIN Staff and Legal, not the AC, that determined that this language
> could not be
I support this edit, for same reasons others have mentioned.
If I’m recalling yesterday’s presentation correctly, it was ARIN Staff and
Legal, not the AC, that determined that this language could not be implemented
an editorial change, so that’s not up for debate here.
One possible adjustment
I agree with Owen re: the editorial nature of the changes. However, I
support it moving forward. I don't support the Farmer suggestion. That is
possibly a material change that should undergo the rigors of "the process"
on its own.
Warm regards,
-M<
On Thu, Oct 21, 2021 at 11:33 AM Owen
I support this amendment.
Owen
> On Oct 20, 2021, at 12:45 , David Farmer via ARIN-PPML
> wrote:
>
> I support this proposal as currently written.
>
> However, regarding Kevin Blumberg's comment at the ARIN 48 discussion of this
> policy earlier today; How about adding a paragraph like
Policy ARIN-2021-4: Clarifications to Sections
8.3, 8.4 and 8.5.6
I support this proposal as currently written.
However, regarding Kevin Blumberg's comment at the ARIN 48 discussion of this
policy earlier today; How about adding a paragraph like the following to
section 8.1, Principles;
When
I support this proposal as currently written.
However, regarding Kevin Blumberg's comment at the ARIN 48 discussion of
this policy earlier today; How about adding a paragraph like the following
to section 8.1, Principles;
When number resources of multiple types, IPv4, IPv6, and/or ASNs, are
Gotcha, thx. I interpret the existing text the same as the new text (based
on the original intent when it was written), and presume ARIN has been
doing the same, but I could see how other interpretations could've been
valid.
I support the policy as written.
-Scott
On Tue, Aug 24, 2021 at 9:51
On Tue, Aug 24, 2021 at 9:23 AM Scott Leibrand wrote:
> I support these changes, but would like to hear from anyone who thinks they
> would change (vs. just clarify) anything.
Hi Scott,
In the original text, it's unclear whether the AS numbers are intended
to be independently transferrable. In
+1
I support these changes, but would like to hear from anyone who thinks they
would change (vs. just clarify) anything.
Scott
> On Aug 24, 2021, at 8:43 AM, Owen DeLong via ARIN-PPML
> wrote:
>
> I don’t understand how these are non-editorial in nature other than possibly
> the one to
I don’t understand how these are non-editorial in nature other than possibly
the one to 8.5.6 which technically narrows the scope to no longer accidentally
(and absurdly) include IPv6 space reassigned to customers in an IPv4
calculation.
As such, I support the changes (they add clarity and
On 19 August 2021, the ARIN Advisory Council (AC) accepted "ARIN-prop-299:
Clarifications to Sections 8.3, 8.4 and 8.5.6" as a Draft Policy.
Draft Policy ARIN-2021-4 is below and can be found at:
https://www.arin.net/participate/policy/drafts/2021_4/
You are encouraged to discuss all
20 matches
Mail list logo
