Maybe the rule could be SWIP for a /48 or more if the downstream customer
also has an ASN so that they can receive BGP announcements, otherwise
SWIP would not be required.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Mon, 17 Jul 2017, Paul McNary wrote:
Tony
Do you mean BGP instead of BCP. I agree that IP's that are BGP routable
should be the proper place
to place the SWIP requirement. Anything not BGP routable should be considered
local routed.
Paul
On 7/17/2017 4:25 PM, Tony Hain wrote:
John,
I think we are in violent agreement here, other than the ARIN membership is
the wrong venue (not broad enough to encompass the appropriate community)
for the base statement that SWIP data must exist for a routing entry. If
the appropriately broad community established that BCP; a policy
enforceable by ARIN staff would be ???complies with community established
BCP???s related to routing???.
The only problem I have with the general braindead conservation mindset
that says a /48 is non-consumer, and must be SWIPed while longer values
would be only consumer and therefore exempt. As far as it goes, if a
consumer convinced the ISP they had a technical need for a /36, that should
be exempt based on consumer protection. Length has nothing to do with it.
Identifiable routing slot contact info is the ???need??? here, so anything
that is not broken out doesn???t ???need??? SWIP data. That said, this
whole paragraph, and most of the current discussion belongs in another
venue.
Tony
*From:*John Curran [mailto:[email protected]]
*Sent:* Monday, July 17, 2017 12:25 PM
*To:* Tony Hain
*Cc:* [email protected]
*Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of
Assignment Registration requirements between IPv4 and IPv6
On 17 Jul 2017, at 11:20 AM, Tony Hain <[email protected]
<mailto:[email protected]>> wrote:
John,
So you are OK with a policy that says ARIN is required to revoke
address space if other ISP???s choose to accept it into the routing
table, but there is no SWIP for it? To me that says you are making
a statement about ???how things are routed??? by requiring a database
entry before it gets accepted into routing.
I have no problem with a BCP to the effect that the data SHOULD
exist, but as a policy this has ARIN stomping right on the line it
claims to avoid.
Tony -
ARIN number resource policy must be germane to administration of the
registry;
i.e. if you want a policy that says an address block will only be issued
for a certain
reason (and that reason includes some routing characteristic, such as
multihoming)
then ARIN will have parties represent that they intend to use in accordance
with
that requirement, and will investigate representations that appear to be
fraudulent.
For example, a policy that states that "IPv6 blocks will have SWIP
performed for any
sub-delegations which are going to be individually announced by the ISP"
would be
a policy which is enforceable, since the ISP is representing that they???ll
do ???X" under
certain circumstances, and it???s trivial to revoke if they fail to follow
through and we
receive a fraud report from the community calling attention to that fraud.
Just remember, any characteristic or behavior that you intend to promulgate
in this
manner effectively effective defines or extends the scope of ARIN???s
mission, so it???s
worth being very cautious and very certain before proposing such??? The
fact that
parties need IP address space mean that they have little effective remedy
to the
implications of community-developed number policy, and so requirements that
aren???t
directly and clearly related to ARIN???s mission (e.g. ???requester agrees
that they will
put a statute of ARIN???s CEO in their lobby within 12 months of
issuance???) are likely
to be found out of scope by ARIN???s Board of Trustees...
Thanks!
/John
John Curran
President and CEO
American Registry of Internet Numbers
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
