Send ARIN-PPML mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Draft Policy ARIN-2013-4: RIR Principles (Owen DeLong)
2. Re: Draft Policy ARIN-2013-4: RIR Principles (William Herrin)
3. Re: Draft Policy ARIN-2013-4: RIR Principles (John Curran)
4. Re: Draft Policy ARIN-2013-4: RIR Principles (Jason Schiller)
----------------------------------------------------------------------
Message: 1
Date: Thu, 30 May 2013 13:45:10 -0400
From: Owen DeLong <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
>
>>
>> RFC-2050 3.1 says:
>>
>> "IP addresses are valid as long as the criteria continues to be met."
>
> One might construe this statement to directly invalidate existing legacy
> allocations which would now be in ARIN's policy through this policy. Others
> might be worried that this opens the door wider to changing policy to
> retroactively revoke allocations or assignments by changing "criteria".
> Furthermore, I believe this idea is already handled by existing NRPM text and
> the RSA.
>
>>
Whether one construes it that way or not, the reality is that said statement
has always applied to resource allocations/assignments even back when it was
just kept in Jon Postel's notebook.
As such, I support preserving that statement in the ARIN policy proposal.
Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130530/50b50f5e/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 30 May 2013 14:21:09 -0400
From: William Herrin <[email protected]>
To: Owen DeLong <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
Message-ID:
<cap-gugu377apvxabw3etpbvmp8hpa5xi2tow87fdhx_wmze...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 30, 2013 at 1:45 PM, Owen DeLong <[email protected]> wrote:
>> RFC-2050 3.1 says:
>>
>> "IP addresses are valid as long as the criteria continues to be met."
>>
>>
>> One might construe this statement to directly invalidate existing legacy
>> allocations which would now be in ARIN's policy through this policy. Others
>
> Whether one construes it that way or not, the reality is that said statement
> has always applied to resource allocations/assignments even back when it was
> just kept in Jon Postel's notebook.
>
> As such, I support preserving that statement in the ARIN policy proposal.
Hi Owen,
I construe the NRPM (including any changes we might make to it) to
apply to resources under an RSA and requests for ARIN action which
would require the resources to first come under RSA. Should ARIN
construe things differently, they're welcome to try their luck in
court.
I read the language in both the proposal and in 2050 to mean that
resources assigned under the registry's rules are subject to review
under the registry's rules. The legacy addresses weren't assigned
under any version of ARIN's rules. Unless there's some part of the
language that seems targeted at disrupting that status quo, take the
advice that comes out of this topic every time it's brought up: let
sleeping dogs lie.
Regards,
Bill Herrin
--
William D. Herrin ................ [email protected] [email protected]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
------------------------------
Message: 3
Date: Thu, 30 May 2013 19:15:51 +0000
From: John Curran <[email protected]>
To: William Herrin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
On May 30, 2013, at 2:21 PM, William Herrin <[email protected]> wrote:
Bill - I have no recommendation or suggestion regarding the Draft
Policy text, but need to reply to several of your remarks for clarity.
> I construe the NRPM (including any changes we might make to it) to
> apply to resources under an RSA and requests for ARIN action which
> would require the resources to first come under RSA.
The policies set by the community in this region (i.e. the NRPM)
apply to all resources in the registry. ARIN will operate the
registry in accordance with such policies.
> Should ARIN
> construe things differently, they're welcome to try their luck in
> court.
As the registry does get operated in accordance with policies set
by the community and the IP address blocks exist as entries in the
registry, your assertion above is inverted; i.e. you would be the
one seeking appropriate counsel and legal recourse if you believe
you have rights to the contrary of the policy set by the community.
ARIN performs a legal review on draft policies to see that they
conform with legal requirements, but you may have innovative beliefs
that you'd like to try to assert (which is why there are courthouses.)
> I read the language in both the proposal and in 2050 to mean that
> resources assigned under the registry's rules are subject to review
> under the registry's rules. The legacy addresses weren't assigned
> under any version of ARIN's rules.
For a more in-depth consideration of this topic, I might suggest
reviewing this recent article in the ABA Business Law Today on IP
number transfers -
<http://apps.americanbar.org/buslaw/blt/content/2013/05/article-03-edelman.shtml>
Thanks!
/John
John Curran
President and CEO
ARIN
------------------------------
Message: 4
Date: Thu, 30 May 2013 16:36:36 -0400
From: Jason Schiller <[email protected]>
To: Andrew Dul <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
Message-ID:
<CAC4yj2VYMVxyDkm-risMkjafa_4=6o9a31davvhkbg4pccc...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Andrew,
I think there is one very important point that you make that is worth
calling out separately:
Andrew writes:
JS> RFC-2050 3.1 says:
JS>
JS> "IP addresses are valid as long as the criteria continues to be met."
AD> One might construe this statement to directly invalidate existing
legacy allocations
AD> which would now be in ARIN's policy through this policy. Others might
be worried
AD> that this opens the door wider to changing policy to retroactively
revoke allocations
AD> or assignments by changing "criteria". Furthermore, I believe this
idea is already
AD> handled by existing NRPM text and the RSA.
What should we do here?
My goal was to have a "universal section" that documented the principles of
"stewardship"
originally documented in RFC-2050 and be one place people could point to
(instead of RFC-2050
in the event that the stewardship language in 2050 is deprecated). I know
the definition of
stewardship has evolved, and documented in other places, all based on the
spirit of RFC-2050.
It felt to me like this is a current principle of stewardship.
I am not trying to invent some new restriction on legacy address holders.
If the community feels
this creates some new ability to revoke legacy allocations, then we should
consider some language
to indicate that is not the case.
If the current RSA / NRPM text documents this principle, then I'd like for
you (or someone) to lift out
that text, and add it to this section.
The goal is to have all the principles in one section, and in the event
that this becomes global, or
adopted in multiple regions, they may lack the text you are thinking of.
So my questions to the community:
1. Does this create some new restriction on legacy address holders?
1A. if yes, should this new restriction be avoided?
Please provide draft text on what exclusions should apply to legacy
addresses.
2. Is there already good text in the RSA / NRPM about this principle?
2A. If yes please quote the text.
2B. What text would you lift and include here? How would you generalize it
into a principle?
Thanks,
__Jason
On Thu, May 30, 2013 at 1:25 PM, Andrew Dul <[email protected]> wrote:
> Hi Jason,
>
>
> On 5/28/2013 9:04 PM, Jason Schiller wrote:
>
> Andrew thanks for your feed back.
>
> I want to point out that much of this language comes from either
> RFC-2050 or the current PDP or NRPM. I tired to change the language as
> little as possible, except where we have commonly agreed on new language
> such as "efficient utilization" instead of conservation. I thought that
> might be the most uncontroversial starting point. I am not opposed to
> changing it, especially if it makes the text less controversial.
>
> I didn't have any of those docs in front of me when reviewing the
> proposal, so I didn't specifically note they were "existing policy text."
> In general, I'm in favor of reusing text where it makes sense. I will say
> that there probably always is room for improvement, and 2050 is now pretty
> dated so updating the language to be more relevant to today's practices &
> principles is probably a step forward.
>
>
> ---
>
> WRT the LIR/ISP I agree, we should adopt whatever we think the standard
> term should be.
>
> ---
>
> WRT using number resources instead of IP address space I would have to
> take a careful look and make sure we are not applying principles that make
> sense with respect IP addressing to ASNs if they don't make sense. It is
> not clear to me if you think these changes should be throughout the text,
> or only in section 0.1.
>
>
> I probably wasn't totally consistent in my initial comments. Since this
> is "RIR Principles" I believe this policy proposal should refer in general
> to number resources unless the statements directly apply only to a subset
> of Internet number resources.
>
>
> ---
>
> Andrew writes:
> > I think this section [0.1. Efficient utilization based on need
> (Conservation)]
> > should have an explicit reference to the difference
> > in conservation techniques for IPv4 and IPv6. A proposed sentence might
> > be something like this... "Conservation goals may vary due to the
> > technical differences between IP number resources pools, for example the
> > relatively limited size of the IPv4 address pool causes a desire to see
> > the number space more highly utilized compared to the vast availability
> > of IP numbers within the IPv6 address pool."
>
> I made a conscious effort to keep this text in section 0.4 for clarity.
>
> From the draf policy section 0.4:
> "For example, efficient utilization becomes a more prominent issue than
> aggregation as the IPv4 free pool depletes and IPv4 resource availability
> in any transfer market decreases. Conversely, because the IPv6 number space
> is orders of magnitude larger than the IPv4 number space, the scale tips
> away from efficient utilization towards hierarchical aggregation for IPv6
> number resources."
>
> Does that text fulfill your suggestion of "Conservation goals may vary
> due to the technical differences between IP number resources pools, for
> example the relatively limited size of the IPv4 address pool causes a
> desire to see the number space more highly utilized compared to the vast
> availability of IP numbers within the IPv6 address pool."
>
> Do you have concerns about where this text is located?
>
>
> I realized later that I inserted similar "IPv4 is different that IPv6"
> into multiple sections, since I thought it applied in unique ways to each
> section. Perhaps for clarity it should only be in section 0.4 Stewardship,
> since this is the section that talks about balance between different
> elements and goals? I'm also OK with it being only in one section, but I
> would want it to somehow illuminate specifically that conservation varies
> based on number resource.
>
> Perhaps just add the statement w/o example? "Conservation goals may vary
> due to the technical differences between IP number resources pools."
>
> Not a showstopper for me, if it isn't in 0.1.
>
> Building on Bill's comments in his notes, I think there might be room
> toward using the term sustainability in these principles. That term is
> well known in "corporate speak" and might be closer to the RIR's goals &
> principles compared with other words.
>
> ---
>
> Andrew writes:
> > "Utilization rate of address space will be an important factor in
> > justifying need for IP number resources. However, utilization rates
> > will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
> > number resource pools."
>
> Again, I made a conscious effort to keep this text in section 0.4 for
> clarity, and would quote the same text.
>
> Does that meet your concern about your proposed text?
>
> Do you have concerns about where this text is located?
>
>
> Perhaps just keeping it all in 0.4 is best.
>
>
>
> Should I repeat the paragraph in 0.1, 0.1.1, and 0.4?
>
> I wouldn't repeat the paragraph.
>
> ---
> Andrew writes:
> >> In order to promote increased usage of Internet number resources,
> >> resource holders will be required to provide an accounting of
> >> resources currently held demonstrating efficient utilization. Internet
> >> number resources are valid as long as the criteria continues to be
> >> met. The transfer of Internet number resources from one party to
> >> another must be approved by the regional registries. The party trying
> >> to obtain the resources must meet the same criteria as if they were
> >> requesting resources directly from the IR.
> >>
> >> All Internet number resource requests are subject to audit and
> >> verification by any means deemed appropriate by the regional registry.
> >>
> >
> > I suspect the above two paragraphs may be lightning rods against the
> > policy proposal. May I suggest the following single paragraph in lieu
> > of the above two paragraphs.
> >
> > In order meet the Principles and Goals of the Internet Registry System,
> > resource holders may be required from time to time to provide an
> > accounting and current usage of resources currently held. The RIRs
> > shall set policies to define these accounting mythologies as part of
> > their community driven policy process.
>
> I'm not sure why you think these two paragraphs are lightening rods.
>
> RFC-2050 3.3 says:
> "To promote increased usage of address space, the registries will
> require an accounting of address space previously assigned to the
> enterprise, if any."
>
>
> I believe including text that says orgs must keep records of how the use
> address space is totally appropriate. Record keeping doesn't necessarily
> "proposed increased usage" but does provide accountability and transparency
> which I believe should be one of the goals of the registry system.
>
>
>
> RFC-2050 3.1 says:
>
> "IP addresses are valid as long as the criteria continues to be met."
>
>
> One might construe this statement to directly invalidate existing legacy
> allocations which would now be in ARIN's policy through this policy.
> Others might be worried that this opens the door wider to changing policy
> to retroactively revoke allocations or assignments by changing
> "criteria". Furthermore, I believe this idea is already handled by
> existing NRPM text and the RSA.
>
>
> RFC-2050 4.7 says
>
> "The transfer of IP addresses from one party to another must be
> approved by the regional registries. The party trying to obtain
> the IP address must meet the same criteria as if they were
> requesting an IP address directly from the IR."
>
> I believe this "policy" element is best handled in the details section
> of the NRPM rather than the principles section. ARIN's policies already
> define transfers. Having a generic "RIRs shall determine IP number
> resources transfer policies through their community drive policy
> development process." might be a good addition to this proposal.
>
>
> RFC-2050 4.4 says:
> "All IP address requests are subject to audit and verification
> by any means deemed appropriate by the regional registry."
>
> I just remember for multiple years discussing policy 2007-14 & others
> when we put into policy existing auditing and review practices. Since
> ARIN's policies and RSA already talk about audit procedures, I also thought
> this was not necessary. The language "by any means deemed appropriate by
> the regional registry" is a wide open door that many I believe won't like.
> By using text to say auditing is done by the community through adopted
> policy you limit an RIR's auditing to specifically what the community wants
> the registry to do.
>
>
> And there is lots of text about conservation in RFC-2050 and
> efficient utilization in the NRPM.
>
> Can you elaborate on the lightening rod potin?
>
> See above comments.
>
> I can only guess you are suggesting that the community wants
> to depart from the principles in RFC-2050, but think you must
> mean something else.
>
> What am I missing here?
>
>
> Hopefully my comments above illuminate the concerns I had about the text.
> Basically it comes down to "modernizing" the 2050 text/principles, and
> keeping principles in the principles section and not putting specific
> policy in the principles section.
>
>
>
> Andrew writes:
> >> 0.2. Hierarchical aggregation (Routability)
> >>
> >> Policies for managing Internet number resources must support
> >> distribution of globally unique Internet addresses in a hierarchical
> >> manner, permitting the routing scalability of the addresses.
> >
> > Should the RIR's goals be "LISP agnostic"? That is if LISP becomes the
> > predominant routing methodology in the future, one would not necessarily
> > expect the goals of the RIRs to change.
> >
> > Suggested change to end of first sentence.
> >
> > ... permitting the routing scalability of the addresses as required by
> > the current technical limitations of global routing protocols.
>
> I think this change is good even w/o considering LISP.
> Imagine we have new holographic memory that can hold orders of
> magnitude more data and decrease read time
>
> ---
>
> Andrew writes:
> >
> >> 0.3. Uniqueness (Registration)
> >>
> >> c) to ensure that a provider has exhausted a majority of
> >> its current CIDR allocation, thereby justifying an additional
> >> allocation d) to assist in IP allocation studies.
> >
> > Suggested revision for "C"
> >
> > to allow a LIR to demonstrate and disclose reassignment of IP number
> > resources to third-parties
>
> I think the point is to demonstrate reassignment data to
> demonstrate efficient utilization.
> But I also think that point is covered in section 0.1.1, So the rewrite
> here is ok.
>
> ---
>
> Andrew writes:
> > Perhaps add a statement specifically about Stewardship
> >
> > "Stewardship of IP number resources is the balance of overseeing and
> > protecting the interests of all Internet stakeholders to further the
> > development and expansion of the Internet and the Internet Registry
> System."
>
> I do not oppose this text.
>
> Andrew also writes...
> >
> > justified need as a conflicting goal should be explicitly mentioned.
> >
> > "It should be noted that efficient utilization, justified need, and
> >hierarchical aggregation are often conflicting goals."
>
> I'm not sure this parses correctly... This sounds to me like there are
> conflicts between all three:
>
> efficient utilization vs justified need vs hierarchical aggregation.
>
> How about:
> "It should be noted that efficient utilization based on justified need,
> and
> hierarchical aggregation are often conflicting goals."
>
>
>
> -
>
>
> On Tue, May 28, 2013 at 2:19 PM, Andrew Dul <[email protected]> wrote:
>
>> I support adding these guiding principles to the NRPM, furthermore I
>> would support efforts to introduce this policy in all RIR regions to
>> make this a global policy.
>>
>> Comments on the proposed text in-line below.
>>
>> Andrew
>>
>> On 5/17/2013 9:53 AM, ARIN wrote:
>> > Draft Policy ARIN-2013-4
>> > RIR Principles
>> >
>> > On 16 May 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-187
>> > RIR Principles" as a Draft Policy.
>> >
>> > Draft Policy ARIN-2013-4 is below and can be found at:
>> > https://www.arin.net/policy/proposals/2013_4.html
>> >
>> >
>> > ## * ##
>> >
>> >
>> > Draft Policy ARIN-2013-4
>> > RIR Principles
>> >
>> > Date: 17 May 2013
>> >
>> > Problem Statement:
>> >
>> > The original text in RFC 2050 both "describes the registry system for
>> > the distribution of globally unique Internet address space and
>> > registry operations" and provides "rules and guidelines [principles]
>> > governing the distribution of this address space."
>> >
>> > The currently proposed update (RFC2050bis) "provides information about
>> > the current Internet Numbers Registry System used in the distribution
>> > of globally unique Internet Protocol (IP) address space and autonomous
>> > system (AS) numbers" and "provides information about the processes for
>> > further evolution of the Internet Numbers Registry System."
>> >
>> > This means that the guiding principles of stewardship are not
>> > currently being carried forward into the new document. The goals of
>> > Conservation (efficient utilization based on need), Routability
>> > (hierarchical aggregation), and Registration (uniqueness) are as
>> > important, if not more so, now that the transition to IPv6 is upon us.
>> > This can be rectified by documenting these principles in RIR policy.
>> >
>> > Policy Statement:
>> >
>> > Section 0: Principles and Goals of the Internet Registry System
>> >
>> > 0.1. Efficient utilization based on need (Conservation)
>> >
>> > Policies for managing Internet number resources must support fair
>> > distribution of globally unique Internet address space according to
>> > the operational needs of the end-users and Internet Service Providers
>> > operating networks using this address space. The registry should
>> > prevent stockpiling in order to maximize the conservation and
>> > efficient utilization of the Internet address space.
>>
>> This section should use the new proposed convention of "LIR/ISP" as
>> being developed in ARIN-2013-5.
>>
>> s/this address space/IP number resources/r
>> s/Internet address space/IP number resources/r
>>
>> I think this section should have an explicit reference to the difference
>> in conservation techniques for IPv4 and IPv6. A proposed sentence might
>> be something like this... "Conservation goals may vary due to the
>> technical differences between IP number resources pools, for example the
>> relatively limited size of the IPv4 address pool causes a desire to see
>> the number space more highly utilized compared to the vast availability
>> of IP numbers within the IPv6 address pool."
>>
>> >
>> > 0.1.1. Documented Justified Need (Needs Based)
>> >
>> > Assignment of Internet number resources is based on documented
>> > operational need. Utilization rate of address space will be a key
>> > factor in number resource assignment. To this end, registrants should
>> > have documented justified need available for each assignment.
>> > Organizations will be assigned resources based on immediate
>> > utilization plus expected utilization.
>>
>> Utilization rate is much more important for IPv4 than IPv6.
>>
>> Suggested revision for "Utilization rate of address space will be a key
>> factor in number resource assignment."
>>
>> "Utilization rate of address space will be an important factor in
>> justifying need for IP number resources. However, utilization rates
>> will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
>> number resource pools."
>>
>> >
>> > In order to promote increased usage of Internet number resources,
>> > resource holders will be required to provide an accounting of
>> > resources currently held demonstrating efficient utilization. Internet
>> > number resources are valid as long as the criteria continues to be
>> > met. The transfer of Internet number resources from one party to
>> > another must be approved by the regional registries. The party trying
>> > to obtain the resources must meet the same criteria as if they were
>> > requesting resources directly from the IR.
>> >
>> > All Internet number resource requests are subject to audit and
>> > verification by any means deemed appropriate by the regional registry.
>> >
>>
>> I suspect the above two paragraphs may be lightning rods against the
>> policy proposal. May I suggest the following single paragraph in lieu
>> of the above two paragraphs.
>>
>> In order meet the Principles and Goals of the Internet Registry System,
>> resource holders may be required from time to time to provide an
>> accounting and current usage of resources currently held. The RIRs
>> shall set policies to define these accounting mythologies as part of
>> their community driven policy process.
>>
>>
>> > 0.2. Hierarchical aggregation (Routability)
>> >
>> > Policies for managing Internet number resources must support
>> > distribution of globally unique Internet addresses in a hierarchical
>> > manner, permitting the routing scalability of the addresses. This
>> > scalability is necessary to ensure proper operation of Internet
>> > routing, although it must be stressed that routability is in no way
>> > guaranteed with the allocation or assignment of IPv4 addresses.
>> >
>>
>> Should the RIR's goals be "LISP agnostic"? That is if LISP becomes the
>> predominant routing methodology in the future, one would not necessarily
>> expect the goals of the RIRs to change.
>>
>> Suggested change to end of first sentence.
>>
>> ... permitting the routing scalability of the addresses as required by
>> the current technical limitations of global routing protocols.
>>
>> > 0.3. Uniqueness (Registration)
>> >
>> > Provision of a public registry documenting Internet number resource
>> > allocation, reallocation, assignment, and reassignment is necessary to:
>> >
>> > a) ensure uniqueness and to to provide operational staff with
>> > information on who is using the number resource b) to provide a
>> > contact in case of operational/security problems (e.g. Law
>> > Enforcement) c) to ensure that a provider has exhausted a majority of
>> > its current CIDR allocation, thereby justifying an additional
>> > allocation d) to assist in IP allocation studies.
>>
>> Suggested revision for "C"
>>
>> to allow a LIR to demonstrate and disclose reassignment of IP number
>> resources to third-parties
>>
>> >
>> > It is imperative that reassignment information be submitted in a
>> > prompt and efficient manner to facilitate database maintenance and
>> > ensure database integrity.
>> >
>> > 0.4. Stewardship
>> >
>> > It should be noted that efficient utilization and hierarchical
>> > aggregation are often conflicting goals. All the above goals may
>> > sometimes be in conflict with the interests of individual end-users or
>> > Internet Service Providers. Care must be taken to ensure balance with
>> > these conflicting goals given the resource availability, relative size
>> > of the resource, and number resource specific technical dynamics, for
>> > each type of number resource. For example, efficient utilization
>> > becomes a more prominent issue than aggregation as the IPv4 free pool
>> > depletes and IPv4 resource availability in any transfer market
>> > decreases. Conversely, because the IPv6 number space is orders of
>> > magnitude larger than the IPv4 number space, the scale tips away from
>> > efficient utilization towards hierarchical aggregation for IPv6 number
>> > resources.
>>
>> Perhaps add a statement specifically about Stewardship
>>
>> "Stewardship of IP number resources is the balance of overseeing and
>> protecting the interests of all Internet stakeholders to further the
>> development and expansion of the Internet and the Internet Registry
>> System."
>>
>> Also...
>>
>> justified need as a conflicting goal should be explicitly mentioned.
>>
>> "It should be noted that efficient utilization, justified need, and
>> hierarchical aggregation are often conflicting goals."
>>
>> Use the new LIR/ISP convention instead of "Internet Service Providers"
>>
>>
>>
>> >
>> > Comments:
>> >
>> > a. Timetable for implementation: immediately
>> >
>> > b. I believe that it would be beneficial for IANA to adopt these
>> > principles as well, and encourage the community to consider a global
>> > policy proposal.
>> > _______________________________________________
>> > 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.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|[email protected]|571-266-0006
>
>
>
--
_______________________________________________________
Jason Schiller|NetOps|[email protected]|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130530/e77a8b59/attachment.html>
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 95, Issue 16
*****************************************
