[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[Paul McNary]

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:jcurran at arin.net]
> *Sent:* Monday, July 17, 2017 12:25 PM
> *To:* Tony Hain
> *Cc:* arin-ppml at arin.net
> *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 <alh-ietf at tndh.net 
> <mailto:alh-ietf at tndh.net>> 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 (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170717/c807dc96/attachment.htm>