[ppml] the "other" policy proposals

Sat Apr 7 03:51:17 EDT 2007

Hi Ed,

First thanks for the inputs. Then, clarification regarding 2006-7.

My original proposal was probably closer to the text that you're suggesting,
and not restricted to "new". However the previous round of comments in the
list was appearing as most of the folks participating prefer what we have
now.

In favor of the existing text I will say that those that supported the
previous version also should support this one (seems to me better to have
this than nothing), as it is somehow more restrictive, but at least a first
step towards the objective, and if deemed necessary, we could propose in the
future, if this version gets approved, new modifications.

And to make it very clear this is NOT intended at all to be a new path for
PI.

Last, to explain again the intend of the proposal: There are ISPs (not
end-users) that can't start IPv6 services unless they start also before with
IPv4 and they come back for IPv6. But is even more important to realize that
ISPs may have plans for less than 200 customers (and a good business plan
behind even if this is not the ARIN question to look at) and still have the
right to access to IPv6 (and looking to their upstream is not a solution as
they may want to avoid depending on addresses from others to avoid
renumbering or to allow multihoming).

In the last meeting "open policy" session, a couple of folks (ISPs) clearly
indicated that they are in this situation. I wish they speak up *now*
especially if they aren't coming to the meeting.

Regarding 2007-4: All policies are "interim" in the sense that they are
subjected to changes. So why the other policies don't say so ? It is a
question of fairness and avoiding what some folks when reading the policy
could consider as "oh IPv6 is still interim, not good, let's wait". I will
say that if we are not in favor of this change, we should write interim in
all the other policies also.

Regards,
Jordi

> De: Edward Lewis <Ed.Lewis at neustar.biz>
> Responder a: <ppml-bounces at arin.net>
> Fecha: Fri, 6 Apr 2007 13:47:24 -0400
> Para: <ppml at arin.net>
> CC: <ed.lewis at neustar.biz>
> Asunto: [ppml] the "other" policy proposals
> 
> http://www.arin.net/policy/proposals/2006_7.html
> 
> Undecided
> 
> Q: if I did support the proposal, I'd make the new text
> 
> can justify intent to announce the requested IPv6 address space within one
> year
> 
> I don't think that this has to be an organization "new" to the business.
> 
> But I wonder what the intent is - is this supposed to be the means
> for getting Provider Independent space?  I'd really be cautious about
> allowing this new avenue to be open only to those unfamiliar with the
> Internet.
> 
> http://www.arin.net/policy/proposals/2007_1.html
> http://www.arin.net/policy/proposals/2007_2.html
> http://www.arin.net/policy/proposals/2007_3.html
> 
> For as much as is on the surface, but against if the method appears in WhoIs.
> 
> This is a dumb question, but these are to be implemented in order, 1,
> 2, 3, and if 1 is not approved 2 fails, if 2 fails, 3 fails, right?
> 
> "Because the specific wording of the documentation may be subject to
> debate, and is in no way interdependent upon the documentation of the
> other two methods, it is being proposed in a separate policy, so that
> consensus may be more easily reached." ... but the "intentionally
> left blank" comments are interdependent and the "UPDATES TO" in the
> first policy mention the other two approaches.
> 
> Will ARIN match the security mechanism used in the response to the
> security of the object?  If a POC uses PGP, ARIN responds with PGP,
> if the POC uses X509, will ARIN?
> 
> Will the authentication method in use by a POC be exposed in WhoIs?
> (I hope not, so as not to advertise the mail-from users).
> 
> http://www.arin.net/policy/proposals/2007_4.html
> 
> Undecided.
> 
> I don't know.  Has the policy really been changed - or maybe I should
> ask, does ARIN have interim policies?
> 
> Is RFC 2373bis now RFC 3513?  Are the references up to date?
> 
> http://www.arin.net/policy/proposals/2007_5.html
> 
> For.
> 
> This I am for - I think that ARIN policies ought to care solely about
> the justification to get more space (or retain space) and not how
> assigned/allocated space is redelegated.
> 
> http://www.arin.net/policy/proposals/2007_6.html
> 
> For.
> 
> Sounds good too - speaking not from hands-on experience, if a user
> only needs a /24 meaning that's enough for their addressing needs and
> they can get someone to route it, then why waste 75%?  I did have an
> earlier question on this (whether it is true that a /24 is considered
> "always" routable.)
> 
> http://www.arin.net/policy/proposals/2007_7.html
> 
> For this one, my earlier question was answered.
> 
> http://www.arin.net/policy/proposals/2007_8.html
> 
> Undecided.  This caused a lot of concern on my part.  I'd have to go
> reread what I already wrote a month back.
> 
> http://www.arin.net/policy/proposals/2007_9.html
> 
> For that one.
> 
> http://www.arin.net/policy/proposals/2007_10.html
> 
> For that.
> 
> http://www.arin.net/policy/proposals/2007_11.html
> 
> Fer that.
> 
> http://www.arin.net/policy/proposals/2007_12.html
> 
> Comments elsewhere...
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> Sarcasm doesn't scale.
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.