Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG

[Masato Yamanishi]

Hi David,

Oh, I thought I had replied, but seems not.

>Simply speaking not having the resources in MyAPNIC is equivalent as
to not having them at all.
>You do not have full control of the resources in the APNIC database,
>you do not control the RPKI or reverse delegation.

I'm afraid you just rephrased what you wrote previously, which was not
clear for me. So still unclear.
Let me ask more specifically.
What do you mean by "full control of the resources in the APNIC database"?
What do you mean by "control the RPKI or reverse delegation"?
Why your customer cannot or doesn't want to ask their upstream to manage
RPKI or reverse delegation?
Why your customer cannot or doesn't want to ask their upstream to point NS
record of assigned space to their customer?

>If someone wants it to be possible, I don't see the reason to why object
it?

NO. I don't think it is enough justification nor problem statement to
propose the policy, in particular for v4.

Still, against for this proposal.

Regards,
Matt


2017-08-23 21:01 GMT-07:00 David Hilario :

> Hi,
>
>
> On 23 August 2017 at 10:32, Masato Yamanishi  wrote:
> > Hi Proposer,
> >
> > I have same view as Mr. David Huberman.
> > From the problem statement of prop-119 which says,
> >
> >>1. Problem statement
> >>
> >>
> >>It is currently not possible for an organisation to receive a temporary
> >>transfer under the current policy framework. Some organisations do not
> >>want to have address space registered as assignments or sub-allocations,
> >>but would rather have the address space registered as "ALLOCATED PA".
> >
> >
> > or your message on Aug 17th,
> >
> >>It actually came up a few time from larger networks who tend to want
> >>that, it is a form of long term leasing for them, they want the
> >>resources into their registry out of convenience but also due to
> >>internal procedures, they for example only want to commit for a 5 year
> >>period while preparing their IPv6 and then return the space.
> >>
> >>The do not want to receive a sub-allocation or assignment, as it needs
> >>to be part of their LIR/registry for them to be able to count it into
> >>the network inventory and use the address.
> >>
> >>Some organisation have strict policies against use of external IP space.
> >
> >
> > or your another message on Aug 17th,
> >
> >>The policy came to be as we have had several large companies actually
> >>asking for such type of transfers.
> >>
> >>It is already a possibility in the RIPE region to do such transfers.
> >>
> >>It is really to cover a corner case where organisations are not able
> >>or interested in receiving the IP space in form of assignments or
> >>sub-allocations, but need them to be part of their own registry for
> >>full control of the space and only for a pre-set amount of time.
> >
> >
> > or your another message on Aug 18th,
> >
> >>If it is not registered to your LIR in your registry, you cannot send
> >>an email to helpd...@apnic.net as it is not your space to control in
> >>APNIC DB in the first place, but the space from your LIR that has
> >>issued the space to you, your LIR decides how to register it and which
> >>maintainers will be on it, you are not in full control.
> >>
> >>And ultimately for the ones using RPKI, it needs to be under their
> >>control to issue ROAs in MyAPNIC and not rely on any other parties for
> >>their own IP management.
> >
> >
> > I could not imagine concrete usecase or requesters of this policy as
> well as
> > the reason why you and/or they cannot live with current policy.
> > Rather, it sounds some kind of "nice to have" which is not enough
> > justification as the problem statement for v4 space in these days.
> >
>
> Simply speaking not having the resources in MyAPNIC is equivalent as
> to not having them at all.
> You do not have full control of the resources in the APNIC database,
> you do not control the RPKI or reverse delegation.
>
> So it is a bit more than simply "nice to have", but indeed, it would
> be nice to have.
>
> Being able to have full control for X amount of time would be "nice to
> have" for those who want to have it for their own organisation.
>
> If someone wants it to be possible, I don't see the reason to why object
> it?
>
>
> > Regards,
> > Masato
> >
> >
> >

Re: [sig-policy] [Sig-policy] New version of prop-116: Prohibit to transfer IPv4 addresses in the final /8 block

[Masato Yamanishi]

Hi Tomohiro and All,

While I support the rational of this proposal, I would like to suggest
excluding M&A transfer from the scope and allowing it as it is.
I don't think v4 space allocated from final /8 to the company which is a
target of M&A would become a deal breaker of "real" M&A.
Rather, people who work for that M&A will not find this policy or just
ignore it, then the company will be acquired, but the space cannot be
transferred, and whois data will not be updated.
I know that somebody may use M&A transfer with different intension, but I
think it is "collateral".

Regards,
Matt


2017-08-08 23:12 GMT-07:00 chku :

> Dear SIG members
>
> A new version of the proposal "prop-116: Prohibit to transfer IPv4
> addresses in the final /8 block" has been sent to the Policy SIG for
> review.
>
> It will be presented at the Open Policy Meeting at APNIC 44 which will
> be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15 September
> 2017.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-116
>
> You are encouraged to express your views on the proposal:
>
>  - Do you support or oppose the proposal?
>  - Do you see any disadvantages in this proposal?
>  - Is there anything in the proposal that is not clear?
>  - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
>
> ---
>
> prop-116-v004: Prohibit to transfer IPv4 addresses in the final /8 block
>
> ---
>
> Proposer:   Tomohiro Fujisaki
> fujis...@syce.net
>
>
> 1. Problem statement
> 
>
> There are a lot of transfers of IPv4 address blocks from 103/8
> happening, both within the APNIC region and among RIRs.
>
> Then number of transfer from 103/8 block are about 200, which is about
> 12% of the total number of transfers. This looks so high since APNIC
> manages about 40/8.
>
> And based on the information provided by APNIC Secretariat, number of
> transfers from the 103/8 block are increasing year by year.
>
> Updated by APNIC Secretariat on 27 January 2017:
>
> 1) M&A transfers containing 103/8 space
>
> +--+---+---+-
> |  |   Total   | Number of |
> | Year | Transfers |   /24s|
> +--+---+---+-
> | 2011 | 3 | 12 |
> | 2012 |10 | 46 |
> | 2013 |18 | 66 |
> | 2014 |   126 |498 |
> | 2015 |   147 |573 |
> | 2016 |63 |239 |
> | 2017 |45 |178 |
> +--+---++-
>
> 2) Market transfers containing 103/8 space
>
> +--+---+---+
> |  |   Total   | Number of |
> | Year | Transfers |   /24s|
> +--+---+---+
> | 2011 | 2 | 2 |
> | 2012 |21 |68 |
> | 2013 |16 |61 |
> | 2014 |25 |95 |
> | 2015 |67 |   266 |
> | 2016 |   103 |   394 |
> | 2017 |70 |   288 |
> +--+---+---+
>
> And also, transfers from the 103/8 block include:
>   - Take place within 1 year of distribution, or
>   - Multiple blocks to a single organization in case of beyond 1 year.
>
> Further, there is a case where a single organization have received 12
> blocks transfers from 103 range.
>
> see:  https://www.apnic.net/transfer-resources/transfer-logs
>
> From these figures, it is quite likely that substantial number of 103/8
> blocks are being used for transfer purpose.
>
> This conflicts with the concept of distribution of 103/8 block
> (prop-062), which is intended to accommodate minimum IPv4 address blocks
> for new comers.
>
> prop-062: Use of final /8
>   https://www.apnic.net/policy/proposals/prop-062
>
>
> 2. Objective of policy change
> -
>
> When stated problem is solved, distribution from 103/8 block will be
> consistent with its original purpose, for distribution for new entrants
> to the industry. Without the policy change, substantial portion of 103/8
> blocks will be consumed for transfer purpose.
>
>
> 3. Situation in other regions
> -
>
> None.
>
>
> 4. Proposed policy solution
> ---
>
> Prohibit transfer IPv4 addresses under /8 address block (103/8) which
> have not passed two years after its allocation/assignment. If the
> address block allocated to a LIR in two years is not needed any more, it
> must return to APNIC to allocate to another organization using final /8
> policy. This two years requirement will apply both market and M&A
> transfers.
>
> 5. Advantages / Disadvantages
> -
>
> Advantages:
>   - It makes 103/8 blocks available according to the original purpose,
> as distribution for new entr

Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG

[Masato Yamanishi]

Hi Proposer,

I have same view as Mr. David Huberman.
>From the problem statement of prop-119 which says,

>1. Problem statement
>
>
>It is currently not possible for an organisation to receive a temporary
>transfer under the current policy framework. Some organisations do not
>want to have address space registered as assignments or sub-allocations,
>but would rather have the address space registered as "ALLOCATED PA".


or your message on Aug 17th,

>It actually came up a few time from larger networks who tend to want
>that, it is a form of long term leasing for them, they want the
>resources into their registry out of convenience but also due to
>internal procedures, they for example only want to commit for a 5 year
>period while preparing their IPv6 and then return the space.
>
>The do not want to receive a sub-allocation or assignment, as it needs
>to be part of their LIR/registry for them to be able to count it into
>the network inventory and use the address.
>
>Some organisation have strict policies against use of external IP space.


or your another message on Aug 17th,

>The policy came to be as we have had several large companies actually
>asking for such type of transfers.
>
>It is already a possibility in the RIPE region to do such transfers.
>
>It is really to cover a corner case where organisations are not able
>or interested in receiving the IP space in form of assignments or
>sub-allocations, but need them to be part of their own registry for
>full control of the space and only for a pre-set amount of time.


or your another message on Aug 18th,

>If it is not registered to your LIR in your registry, you cannot send
>an email to helpd...@apnic.net as it is not your space to control in
>APNIC DB in the first place, but the space from your LIR that has
>issued the space to you, your LIR decides how to register it and which
>maintainers will be on it, you are not in full control.
>
>And ultimately for the ones using RPKI, it needs to be under their
>control to issue ROAs in MyAPNIC and not rely on any other parties for
>their own IP management.


I could not imagine concrete usecase or requesters of this policy as well
as the reason why you and/or they cannot live with current policy.
Rather, it sounds some kind of "nice to have" which is not enough
justification as the problem statement for v4 space in these days.

Regards,
Masato



2017-08-22 18:47 GMT-07:00 David Hilario :

> Hi,
>
> On Aug 23, 2017 1:42 AM, "David Huberman" 
> wrote:
>
> Hello,
>
> I oppose this proposal as written.
>
> I do not believe this policy proposal benefits network operations.
>
>
> All your resources would be under your APNIC account, you are in full
> control for everything from Database registration, RPKI and reverse DNS.
>
> There is some advantages to network operation, it is not purely
> administrative.
>
> I
>
>  believe it is intended to further the goals of the policy proposer and
> the company he owns/works at, which exists to earn money from the sale and
> leasing of IP address blocks (per their website).
>
>
> From a business point of view, this policy came as a reaction to requests
> from customers, yes.
>
> Policies are there to accommodate the distribution and operation of the
> various parties operating in the region.
>
> Some see a benefit in having a system like this in place, attacking the
> policy based on our company's services is a bit odd at best.
>
> Some organization's are not willing to buy IPv4 space as a form of
> permanent transfer, they do not believe in IPv4 remaining the dominant
> protocol for the years to come but do need some IPs for some expansion and
> projects that they can later simply return back, other giant internet
> organizations with too much money don't care and are currently buying up
> everything on offer.
>
> This proposal would help leveling that field a bit.
>
>
> If the policy proposal has shed light on some deficiencies in the
> Membership Agreement (found at: https://www.apnic.net/abou
> t-apnic/corporate-documents/documents/membership/membership-agreement/ ),
> then I suggest it would be helpful for the policy proposer to work with
> APNIC staff and/or the EC, rather than through the Policy SIG.
>
>
> I really don't follow your logic here.
>
>
> Thank you,
> David
>
> David Huberman | Principal Program Manager
> Oracle Cloud
> 1501 4th Ave #1800
> Seattle, WA 98101
> USA
>
>
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
> Regards,
> David Hilario
>
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
*

Re: [sig-policy] CONFER--as what happened today in policy discussion.

[Masato Yamanishi]

Hi All,

Even though I'm out-going Chair, let me raise a couple of important points
since it seems many Community members forgot or are ignoring them as too
heated-up now.

Firstly, Our Policy Development Process is based on "Consensus", NOT
"Voting" as clearly described in APNIC corporate document and web site.

https://www.apnic.net/about-apnic/corporate-documents/documents/policy-development/development-process/
https://www.apnic.net/community/policy/process/policy-development-process/

Then, Sec 5.1 of SIG guideline shows basic steps to ask consensus, criteria
to decide whether the proposal reached consensus, and how to address
objections. Since it is long text, let me refer most important part.
(Please see https://www.apnic.net/community/participate/sigs/sig-guidelines/
for full text)

2. If there are objections, the Chair can ask the dissenters to decide if
their objections are:

i. Minor objections

If the proposal goes forward, the dissenters believe that some problems may
occur for some members in the group.

*The participants should work together to see if the proposal can be
modified to overcome these minor objections.* However, it is not always
possible to overcome these objections. If this is the case, the Chair
should ask the dissenters if they are prepared to acknowledge that the
overall advantages of the proposal outweigh their objections and if the
dissenters are willing to stand aside.
ii. Major objections

If the proposal goes forward, the dissenters believe that major problems
will occur for parts of the community and that the proposal cannot be
adopted in its current format.

*The Chair should devote sufficient time for participants to discuss ways
to overcome major objections. As in the case of minor objections,
participants, including the proponent, should work together to develop
solutions that overcome the objections.*

As you can see, in case of major objections, it doesn't mention the
possibility of "cannot overcome".
While no further text, it means all major objections have to be addressed
to reach consensus by implications.
So, if somebody would scam CONFER (or even show-of-hands) somehow, a
proposal may not reach to consensus if major objections are raised and
cannot be addressed. However, in real, people are arguing # of supporters
instead of considering objections.
Lastly, in both of minor/major objections case, SIG guideline asks
participants including proponents and dissenters to work together as we can
address the proponents' problem as well as the dissenters' objections.
However, in these days, such co-working is very few and it is very sad
situation for me.

Regards,
Matt


2017-03-02 1:27 GMT-08:00 Ernest Tse :

> Dear all,
>
> Just want the clarify that, my company is support this policy.
> Is it still keep discuss at the next meeting or what ?
> And also, will APNIC to develop a better online vote system in the next
> meeting for voting this policy ?
>
> Best Regards,
>
>
> Ernest Tse
> Pacswitch Globe Telecom Ltd.
> // Web: http://www.pacswitch.com
> // Tel:  +852-21570550 <+852%202157%200550>
> //Mobile: +852-62536678 <+852%206253%206678>
> //Skype: codesixs
>
> On Thu, 02/03/2017 16.25, Lu Heng  wrote:
>
> Dear Community:
>
>
>
> Craig’s email opens as a community email addressing “Colleagues”, but
> later on the tone changes as he is not referring to me but addressing me by
> changing to “you” and “your organisation”
>
>
>
> Logic of the whole event was, APNIC staff’s comment during prop-118 could
> be misunderstood as implying publicly Larus Cloud Service was gaming the
> CONFER system during our colleague's presentation, when I confronted them
> with that after the session closed, I was asked directly in private if we
> did it.
>
>
>
> According to my reading of the Email of Craig, such behaviour is
> acceptable for APINIC staff. And the company or individual they are
> defaming have no rights to be angry, because the reputation of the
> individual or the company does not matter, the volume of the voice is more
> important than serious accusation or doubt made by APINIC staff.
>
>
>
> We value our reputation dearly, we value the community dearly, and bottom
> up process, community based policy development process are the core parts
> to the very existence of the RIR system, CONFER being a larger step forward
> towards more inclusive community, that would allow people who don't speak
> English well to express their opinion as well as others, are an important
> step both for the community as well as for APINIC.
>
>
>
> That is the reason, assuring anyone abuse the very core system of the
> community, is accusing someone manipulate the consensus process, it is the
> most serious crime you can accuse someone for in this community.
>
>
>
> And because of the seriousness, naturally we feel emotionally angry, and
> while we trying to explain, however we thereafter being confronted by APNIC
> staff with direct doubt and accusation of being liar, I am human, raise the
>

Re: [sig-policy] Policy SIG Chair and Co-Chair Nominations now open

[Masato Yamanishi]

Dear Community members,

Although we will have Chair election in next meeting, I will not run for
next term as I mentioned in last two meetings.
In addition, I will not be able to physically participate at this time, so
would like to ask Sumon, Co-chair, to work as acting Chair
and take Chair's responsibility till we will complete current PDP cycle as
described in SIG guideline.
(Meant if any proposal(s) will be reached consensus in next OPM, present it
or them to AMM and Last Call as well as follow up until be endorsed by EC
or pushed back to the community)

> Unless new Policy SIG Chairs and Co-Chairs are required immediately,
there will be a handover period.
> Outgoing Chairs and Co-Chairs are expected to follow proposals reaching
consensus at the current OPM, to the completion of the Policy Development
Process.

Regarding the proposal for revising SIG guideline, I could find a person
who kindly accepted to take it over.
Thus, we are revising it currently and will present it to the Community
shortly.
(and I might participate in that part remotely)

Lastly, I feel very sorry that I will not be able to meet each of you and
make my farewell,
but it was my great preasure to serve as Chair and Co-chair for 5+years and
work with this Community.

Regards,
Masato Yamanishi, Policy SIG Chair


2017-01-22 21:31 GMT-08:00 George Odagi :

> Dear Community Members,
>
> The APNIC Secretariat is now seeking volunteers to serve as Chair and
> Co-Chair of the APNIC Policy SIG.
>
> The SIG Guidelines prefer that Chair and Co-Chair terms end in alternate
> years to provide continuity if there is a change in leadership. We
> propose the Chair be elected for a two-year term. If a new Co-Chair is
> needed they will serve a one-year term.
>
> The deadline for nominations is:
> --
> 23:59 (UTC +10)
> Wednesday, 22 February 2017
>
> The responsibilities are outlined in Section 2.3 of the APNIC SIG
> Guidelines.
>
> https://www.apnic.net/sig-guidelines
>
> Nominations will be accepted only by using the following form:
>
> https://www.apnic.net/policy-sig/nominate
>
> The election will be the first agenda item of the APNIC Policy SIG
> meeting on Wednesday, 1 March 2017.
>
>
> Kind regards,
>
> George Odagi
> Internet Resource Analyst/Policy Support, APNIC
> e: god...@apnic.net
> p: +61 7 3858 3191
> f: +61 7 3858 3199
> www.apnic.net
> ___
> Join the conversation:   https://blog.apnic.net/
> ___
>
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] prop-116 returned to author for further consideration

[Masato Yamanishi]

Dear colleagues

Version 2 of prop-116: Prohibit to transfer IPv4 addresses in the final
/8 block, did not reach consensus at the APNIC 42 Open Policy Meeting.

The Policy SIG Chair returned the proposal to the author for further
work. The author may propose an amended version of the proposal at a
future meeting.


Proposal details


The proposal seeks to ensure the distribution of the 'Final /8' (103/8)
block is consistent with its original purpose, for distribution for new
entrants to the industry.

Proposal details, including the full text of the proposal, history, and
links to the APNIC 42 meeting archive, are available at:

 http://www.apnic.net/policy/proposals/prop-116

Regards

Masato and Sumon


---

prop-116-v002: Prohibit to transfer IPv4 addresses in the final /8 block

---

Proposer:   Tomohiro Fujisaki
fujis...@syce.net




1. Problem statement


There are a lot of transfers of IPv4 address blocks from 103/8
happening, both within the APNIC region and among RIRs.

Then number of transfer from 103/8 block are about 200, which is
about 12% of the total number of transfers. This looks so hight
high, since APNIC manages about 40/8.

And based on the information provided by APNIC secretariat, number
of transfers from the 103/8 block are increasing year by year.

Provided by George Kuo on the sig-policy ML at 8th September 2016:

1) M&A transfers containing 103/8 space

+--+---+---+-
|  |   Total   | Number of |
| Year | Transfers |   /24s|
+--+---+---+-
| 2011 | 3 | 12 |
| 2012 |10 | 46 |
| 2013 |18 | 66 |
| 2014 |   126 |498 |
| 2015 |   147 |573 |
| 2016 |45 |177 |
+--+---++-

2) Market transfers containing 103/8 space

+--+---+---+
|  |   Total   | Number of |
| Year | Transfers |   /24s|
+--+---+---+
| 2011 | 2 | 2 |
| 2012 |21 |68 |
| 2013 |16 |61 |
| 2014 |25 |95 |
| 2015 |67 |   266 |
| 2016 |56 |   206 |
+--+---+---+


And also, transfers from the 103/8 block include:
  - Take place within 1 year of distribution, or
  - Multiple blocks to a single organization in case of beyond 1 year.

Further, there is a case where a single organization have received 12
blocks transfers from 103 range.

see:  https://www.apnic.net/transfer-resources/transfer-logs

>From these figures, it is quite likely that substantial number of 103/8
blocks are being used for transfer purpose.

This conflicts with the concept of distribution of 103/8 block
(prop-062), which is intended to accommodate minimum IPv4 address blocks
for new comers.

prop-062: Use of final /8
https://www.apnic.net/policy/proposals/prop-062


2. Objective of policy change
-

When stated problem is solved, distribution from 103/8 block will be
consistent with its original purpose, for distribution for new entrants
to the industry. Without the policy change, substantial portion of 103/8
blocks will be consumed for transfer purpose.


3. Situation in other regions
-

RIPE-NCC has been discussing to prohibit transfer under the final /8
address block.


4. Proposed policy solution
---

Prohibit transfer IPv4 address under /8 address block (103/8).
If the address block allocated to a LIR is not needed any more, it have
to return to APNIC to allocate to another organization.

In the case of transfers due to M&A, merged organization can have
up to /22 IPv4 address in the 103/8 block. The 103/8 IPv4 address
more than /22  have to return to APNIC to allocate to another
organization.


5. Advantages / Disadvantages
-

Advantages:
  - It makes 103/8 blocks available according to the original purpose,
as distribution for new entrants (rather than being consumed for
transfer purpose)

  - IPv4 addresses under final /8 are not transferred to outside APNIC.

  - By prohibiting transfer them, it is possible to keep one /22 for
each LIRs state,  which is fair for all LIRs.

Disadvantages:

None.


6. Impact on resource holders
--

  - LIRs cannot transfer address blocks under 103/8. No big impact while
they use it.

  - Organizations which needs to receive transferred IPv4 can continue
to do so, outside 103/8 blocks (which should be made available for
new entrants)


7. References
-
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Proposal to revise SIG guidelines

[Masato Yamanishi]

Hi Randy,

Yes, there are so many ways, but we should choose one of them which can be
reached consensus by the community.
Since several people are now complaining about current election process,
I beleive we cannot say we have a consensus for that any more.
Thus this problem exist.

Regards,
Matt

2016-10-05 13:10 GMT+09:00 Randy Bush :

> > In addition, we need to consider a balance between openness and equality.
>
>
>
> or my version
>
>
>
> randy
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Proposal to revise SIG guidelines

[Masato Yamanishi]

Hi Randy,

Yes, I prefer this way to discuss and improve it :-)

Certainly, the openness is very important, and that is the reason why I
didn't add more conditions as other regions are doing.
<>
I just added voters should be registered participants including remote
ones, and I don't think it will be a barrier
since there is no charge for remote participants.

In addition, we need to consider a balance between openness and equality.
Certainly, we cannot secure the equality only by asking registration for
voters,
but at least we have more information about who have voting rights for each
election.
(I'm not saying voting results, like who voted to whom)
Currently, we don't have any information about who was eligible voter, who
voted actually, etc.
Without these information, I'm afraid we cannot secure the
equality even when we have a concern.

Regards,
Matt


2016-10-04 23:41 GMT+09:00 Randy Bush :

> let me put it another way.
>
> we say very broadly, to the entire world, that the policy sig is open,
> open, open.  so on what basis should we restrict who can vote?
>
> randy
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Proposal to revise SIG guidelines

[Masato Yamanishi]

Hi Randy,

I know two real frauds in past 5 years, and one of community members told
me there were more in past.
So, it is real issue.

Regards,
Matt


2016-10-04 19:01 GMT+09:00 Randy Bush :

> >> but what about the voter suppression issues?
> > I'm doubt current my proposal solves all possible issues
>
> are there actually any real issues?  have we had any actual problem with
> who votes for wg [co-]chairs?
>
> note my use of "voter suppression."  i am from a country where fear of
> voter fraud (when none has actually occurred) is being used to create
> systems and mechanisms to prevent significant portions of the population
> from voting.
>
> is there an actual real problem we have or are experiencing that the
> voter qualification part of your proposal addresses?
>
> randy
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Proposal to revise SIG guidelines

[Masato Yamanishi]

Hi Randy,

> this makes sense for the terms of service part.

Thank you for your understanding.

> but what about the voter suppression issues?

I'm doubt current my proposal solves all possible issues, but I have not
yet find better solution.
So, it is appreciated if you could more inputs as I can improve it.

Regards,
Matt



2016-10-04 18:27 GMT+09:00 Randy Bush :

> yamanishi san
>
> > So, can you support it if I will revise it as follows?
> >
> > 2. SIG Chair's term of service
> >  I would like to propose revising SIG Chair's term of service as follows.
> >  - Elections occur yearly. Chair elections and Co-Chair elections occur
> in
> >alternate years (same as current SIG guideline)
> >  - If Chair election and Co-Chair election are happen in same
> >year, Co-Chair's (or Co-Chairs') term of service should be one year
> >as Chair's and Co-Chairs' term of service are staggered
> >  - If current Chair/Co-Chair resigned or was removed, the succesor's
> >term should be remaining term of current Chair/Co-Chair
>
> this makes sense for the terms of service part.
>
> but what about the voter suppression issues?
>
> randy
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Proposal to revise SIG guidelines

[Masato Yamanishi]

Dear Jahangir,

Sorry, I just aware nobody has not yet answer for your question.

>Can you please clear up the question how to identify the individuals
entitlement who are previously registered APNIC conference and eligible on
site voting like APNIC 43 meeting ?

In on-site case, if the secretariat find a person not wearing the name tag,
just simply ask whether he or she is a registered participants of current
or previous APNIC conferences.
Since we don't need to maintain full list of eligible voters, I believe it
is enough.

Regards,
Matt


2016-09-23 23:46 GMT+09:00 Jahangir Hossain :

> Hi Adam and all ,
>
> I think some rules should be added for voting eligibility to avoid fraud
> (like NRO voting eligibility).
>
> Can you please clear up the question how to identify the individuals
> entitlement who are previously registered APNIC conference and eligible on
> site voting like APNIC 43 meeting ?
>
>
> *Regards / Jahangir *
>
>
>
>
>
> On Tue, Sep 6, 2016 at 7:09 AM, Adam Gosling  wrote:
>
>> Hi Randy
>>
>> Just a couple of references - inline
>>
>>  On 6/09/2016, 10:35, "Randy Bush"  wrote:
>>
>> hi:
>>
>> this kludge is not very well thought out.
>>
>> not that i am advocating, but an ietfish approach would be a
>> requirement
>> to have attended n previous meetings.  makes more sense to me than
>> this
>> proposal.  but ...
>>
>> The NRO NC election process a similar requirement.
>> Individuals who are on site and are registered for either the
>> current APNIC Conference they are attending, or have been registered for at
>> least one previous APNIC Conference since APNIC 10, are entitled to one
>> vote.
>> https://www.apnic.net/community/participate/elections/nro-
>> elections/nro-election-process
>>
>> Voting in EC elections is restricted to Members.
>>  https://www.apnic.net/community/participate/elections/ec/
>> voting/who-can-vote
>>
>> personally, i am not sure there is a real problem.  so what if the old
>> guard gets thrown out and some new unknown folk get elected.  it might
>> be a breath of fresh air.  what actual damage could some fresh blood
>> do?
>> some radical change in apnic across the board just might benefit the
>> internet.
>>
>> [ historical note: this descends from the first taipei meeting, where
>>   there were no voting restrictions.  a bunch of folk showed up just
>> for
>>   the ec election and voted in an outsider, shock and horror!  of
>>   course, all sorts of rules and restrictions to protect the old guard
>>   were immediately put in place. ]
>>
>> randy
>>
>>
>> *  sig-policy:  APNIC SIG on resource management policy
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>
>
>
> --
> *Regards / Jahangir *
>
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] New version of prop-116: Prohibit to transfer IPv4 addresses in the final /8 block (SECURITY=UNCLASSIFIED)

[Masato Yamanishi]

Dear Jahangir,

So, do you support prop-116-v002 as written or oppose?

Regards,
Matt


2016-10-02 16:12 GMT+09:00 Jahangir Hossain :

> Dear all ,
>
> I'm latecomer of the race to get IPv4 . So as a latecomer of  the
> community, may i have a last option or opportunity to get resources ?
>
> According to transfer statistics and member of this community, we are
> responsible for maintaining the number resources policy and update when
> needed for the community .
>
>
> *Regards / Jahangir *
>
> On Fri, Sep 30, 2016 at 4:04 PM, Hiroki Kawabata 
> wrote:
>
>> If the current situation of 103/8 distribution is different from the
>> intention
>> and concept of prop-062(*) as described in the proposal, I think we need
>> to discuss it
>> and revise the policy as necessary.
>>
>>   (*)103/8 block is intended to accommodate minimum IPv4 address block
>>  for new comers.
>>
>>  prop-062: Use of final /8
>>  https://www.apnic.net/policy/proposals/prop-062
>>
>> I think our community is responsible for maintaining the number resources
>> policy.
>> Regardless of IPv4 or IPv6, it is not appropriate to leave the policy
>> untouched,
>> and not to maintain what we have developed.
>>
>> Regards,
>> Hiroki
>>
>> Subject: Re: [sig-policy] New version of prop-116: Prohibit to transfer
>> IPv4 addresses in the final /8 block (SECURITY=UNCLASSIFIED)
>> From: Mark Foster 
>> Date: Tue Sep 27 2016 09:14:57 GMT+0900
>>
>> I agree that there's an element of 'deck chair rearrangement' but it's a
>>> reality that there is a commercial market for IPv4 and competitive value in
>>> having addresses available. To simply say 'who cares about IPv4, move on'
>>> will simply encourage predatory practices.
>>>
>>> I have no doubt that the M&A process will be used to abuse the process,
>>> and believe there needs to be a deterrent to the abuse of the bureaucratic
>>> process.
>>> But legitimate M&A needs to be permitted (having had to engage this
>>> process in the last couple of years due to organisational and commercial
>>> changes at my then-employer, I wouldn't want to see that process made any
>>> more complex than necessary).
>>>
>>> I think that the modified proposal has merit for that reason, and would
>>> support it.
>>>
>>> Mark.
>>>
>>>
>>> On Tue, Sep 27, 2016 at 8:50 AM, Alastair Johnson >> a...@sneep.net>> wrote:
>>>
>>> I agree with Mike. I don't support this proposal.
>>>
>>> AJ
>>>
>>> On Sep 26, 2016, at 2:26 PM, HENDERSON MIKE, MR <
>>> michael.hender...@nzdf.mil.nz <mailto:michael.hender...@nzdf.mil.nz>>
>>> wrote:
>>>
>>> The objectives of this proposal are laudable, but in my view policy
>>>> development for IPv4 is just ‘rearranging the deck chairs on the Titanic’:
>>>> a waste of time and effort.
>>>>
>>>> __ __
>>>>
>>>> __ __
>>>>
>>>> I do *not* support this proposal
>>>>
>>>> __ __
>>>>
>>>> __ __
>>>>
>>>> Regards
>>>>
>>>> __ __
>>>>
>>>> __ __
>>>>
>>>> */Mike/*
>>>>
>>>> __ __
>>>>
>>>> *From:*sig-policy-boun...@lists.apnic.net >>> sig-policy-boun...@lists.apnic.net> [mailto:sig-policy-bounces@lis
>>>> ts.apnic.net <mailto:sig-policy-boun...@lists.apnic.net>] *On Behalf
>>>> Of *Masato Yamanishi
>>>> *Sent:* Monday, 26 September 2016 11:06 p.m.
>>>> *To:* sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net
>>>> >
>>>> *Subject:* [sig-policy] New version of prop-116: Prohibit to
>>>> transfer IPv4 addresses in the final /8 block
>>>>
>>>> __ __
>>>>
>>>> Dear SIG members
>>>>
>>>> A new version of the proposal "prop-116: Prohibit to transfer IPv4
>>>> addresses in the final /8 block" has been sent to the Policy SIG for
>>>> review.
>>>>
>>>> Information about earlier versions is available from:
>>>>
>>>> http://www.apnic.net/policy/proposals/prop-116 <
>>>> http://www.apnic.net

Re: [sig-policy] Proposal to revise SIG guidelines

[Masato Yamanishi]

Kawabata-san (and maybe Randy),

So, can you support it if I will revise it as follows?


2. SIG Chair's term of service
 I would like to propose revising SIG Chair's term of service as follows.
 - Elections occur yearly. Chair elections and Co-Chair elections occur in
alternate years (same as current SIG guideline)
 - If Chair election and Co-Chair election are happen in same
year, Co-Chair's (or Co-Chairs') term of service should be one year
   as Chair's and Co-Chairs' term of service are staggered
 - If current Chair/Co-Chair resigned or was removed, the succesor's
term should be remaining term of current Chair/Co-Chair


Any thought?

Regards,
Matt



2016-09-28 15:52 GMT+09:00 Hiroki Kawabata :


> 2. SIG Chair's term of service
>> I would like to propose aligning Chair' term with Co-Chair's term, which
>> means that Chair and all Co-Chair will serve for same two years.
>> To keep this alighment, I would like to propose limiting the successor's
>> term to remaining term of current Chair/Co-Chair if current
>> Chair/Co-Chair resigned or was removed.
>>
>>
> If ALL current Chair/Co-Chair resigne or are removed at the same time
> and the another successor who don't know or share the background and
> situations of this forum become New Chair/Co-Chair, who do care for them?
>
> At the point of the stable/continuous forum management,
> I think that there is no need to revise the part of this guideline.
>
> Regards,
> Hiroki
>
>
> Subject: [sig-policy] Proposal to revise SIG guidelines
> From: Adam Gosling 
> Date: Mon Sep 05 2016 19:08:46 GMT+0900
>
>
>
>> Dear SIG members
>>
>> A proposal to modify the APNIC SIG Guidelines relating to the election
>> of SIG Chairs and Co-Chairs has been submitted for consideration at
>> APNIC 42 im Colombo, Sri Lanka.
>>
>>https://www.apnic.net/sig-chair-elections/proposed-revision.txt
>>
>> If agreed. these changes will affect all APNIC SIGs from APNIC 43 in Ho
>> Chi Minh City, Vietnam.
>>
>> Discussion and call for consensus will take place in the Policy SIG.
>>
>>https://www.apnic.net/mailinglists
>>
>> If successful in the Policy SIG, a consensus call will be made at the
>> APNIC Member Meeting. There will be no final Comment Period.
>>
>> To ensure those not travelling to APNIC 42 are able to participate in
>> the discussion, you are invited to comment on the Policy SIG Mailing
>> List before the conference.
>>
>> More background to this proposal is available at:
>>
>>    https://www.apnic.net/community/participate/sigs/chair-elections
>>
>> Regards
>>
>> Adam
>>
>>
>> ---
>>
>> Revising eligible voters of Chair election and Chair's term
>>
>> ---
>>
>> Proposer:   Masato Yamanishi
>>myama...@gmail.com
>>
>>
>> 1. Problem statement
>> 
>>
>> 1. Eligible voters in SIG Chair election
>> In current SIG guidelines, we have no rule or guideline about eligible
>> voters in SIG Chair election and we have two issues by the lack of such
>> rule.
>>
>> Firstly, we need to have clear guideline whether remote participants
>> have voting rights for SIG Chair election since current practice is
>> different in each election.
>>
>> Secondary, it can be used by fraud, like hijacking the position of Chair
>> agaist the Community by inviting many persons who never attend the
>> community discussion.
>>
>> 2. SIG Chair's term of service
>> While SIG guidelines says "Elections occur yearly. Chair elections and
>> Co-Chair elections occur in alternate years.", both elections were held
>> at same meeting in many cases, in particular when a current Co-Chair
>> stand for the position of Chair. With this current practice having both
>> elections at same meeting, we are not seeing any significant issues for
>> long time.
>>
>> In addition, there is no alternative condition for the successor's term
>> if current Chair/Co-Chair resigned or was removed though such
>> alternative condition is necessary to maintain staggered term as
>> requested by SIG guideline. (a.k.a. the successor's term of service is
>> same as remaining term of resigned or removed Chair)
>>
>>
>> 2. Objective of policy change
>> -
>>
>> The objective is preventing confusions related to remote partici

[sig-policy] New version of prop-116: Prohibit to transfer IPv4 addresses in the final /8 block

[Masato Yamanishi]

Dear SIG members

A new version of the proposal "prop-116: Prohibit to transfer IPv4
addresses in the final /8 block" has been sent to the Policy SIG for
review.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-116

You are encouraged to express your views on the proposal:

 - Do you support or oppose the proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Masato, Sumon

---

prop-116-v002: Prohibit to transfer IPv4 addresses in the final /8 block

---

Proposer:   Tomohiro Fujisaki
fujis...@syce.net




1. Problem statement


There are a lot of transfers of IPv4 address blocks from 103/8
happening, both within the APNIC region and among RIRs.

Then number of transfer from 103/8 block are about 200, which is
about 12% of the total number of transfers. This looks so hight
high, since APNIC manages about 40/8.

And based on the information provided by APNIC secretariat, number
of transfers from the 103/8 block are increasing year by year.

Provided by George Kuo on the sig-policy ML at 8th September 2016:

1) M&A transfers containing 103/8 space

+--+---+---+-
|  |   Total   | Number of |
| Year | Transfers |   /24s|
+--+---+---+-
| 2011 | 3 | 12 |
| 2012 |10 | 46 |
| 2013 |18 | 66 |
| 2014 |   126 |498 |
| 2015 |   147 |573 |
| 2016 |45 |177 |
+--+---++-

2) Market transfers containing 103/8 space

+--+---+---+
|  |   Total   | Number of |
| Year | Transfers |   /24s|
+--+---+---+
| 2011 | 2 | 2 |
| 2012 |21 |68 |
| 2013 |16 |61 |
| 2014 |25 |95 |
| 2015 |67 |   266 |
| 2016 |56 |   206 |
+--+---+---+


And also, transfers from the 103/8 block include:
  - Take place within 1 year of distribution, or
  - Multiple blocks to a single organization in case of beyond 1 year.

Further, there is a case where a single organization have received 12
blocks transfers from 103 range.

see:  https://www.apnic.net/transfer-resources/transfer-logs

>From these figures, it is quite likely that substantial number of 103/8
blocks are being used for transfer purpose.

This conflicts with the concept of distribution of 103/8 block
(prop-062), which is intended to accommodate minimum IPv4 address blocks
for new comers.

prop-062: Use of final /8
https://www.apnic.net/policy/proposals/prop-062


2. Objective of policy change
-

When stated problem is solved, distribution from 103/8 block will be
consistent with its original purpose, for distribution for new entrants
to the industry. Without the policy change, substantial portion of 103/8
blocks will be consumed for transfer purpose.


3. Situation in other regions
-

RIPE-NCC has been discussing to prohibit transfer under the final /8
address block.


4. Proposed policy solution
---

Prohibit transfer IPv4 address under /8 address block (103/8).
If the address block allocated to a LIR is not needed any more, it have
to return to APNIC to allocate to another organization.

In the case of transfers due to M&A, merged organization can have
up to /22 IPv4 address in the 103/8 block. The 103/8 IPv4 address
more than /22  have to return to APNIC to allocate to another
organization.


5. Advantages / Disadvantages
-

Advantages:
  - It makes 103/8 blocks available according to the original purpose,
as distribution for new entrants (rather than being consumed for
transfer purpose)

  - IPv4 addresses under final /8 are not transferred to outside APNIC.

  - By prohibiting transfer them, it is possible to keep one /22 for
each LIRs state,  which is fair for all LIRs.

Disadvantages:

None.


6. Impact on resource holders
--

  - LIRs cannot transfer address blocks under 103/8. No big impact while
they use it.

  - Organizations which needs to receive transferred IPv4 can continue
to do so, outside 103/8 blocks (which should be made available for
new entrants)


7. References
-
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] New Policy Proposal prop-116: Prohibit to transfer IPv4 addresses in the final /8 block

[Masato Yamanishi]

Dear Colleagues,

Regardding this prop-116, I have not yet seen any support, opposition, or
comment, except one clarification made by Mike Jager.
So, let me ask you to express your views for this proposal on the list more
since the meeting is reaching within 2 weeks.

Mike> Can you advise your opinion for prop-116 after seeing the number of
tranfers in 103/8 by market and M&A?

Regards,
Matt


2016-09-08 15:53 GMT+09:00 George Kuo :

> Hi Mike,
>
>
> On 7/09/2016 8:09 AM, Mike Jager wrote:
>
>> This proposal does not prohibit transfers due to M&A. Transfers of 103/8
>>>
>>> block due to M&A continues to be allowed, based on the M&A transfer
>>>
>>> procedures.
>>>
>>
>> I had always assumed that anyone trying to get more than one allocation
>> of 103/8 was creating a separate entity, obtaining APNIC membership,
>> receiving the 103/8 allocation, and then using the M&A process to transfer
>> it to their original entity.
>>
>> If this is the case, the proposal will be ineffective at stopping this.
>>
>> Does APNIC have any information on the relative number of transfers
>> within 103/8 that have happened as part of M&As?
>>
>>
> I have included two tables here for your reference. The numbers for Market
> transfers are available as part of the public transfer logs. (
> ftp://ftp.apnic.net/public/transfers/)
>
>
> 1) M&A transfers containing 103/8 space
>
> +--+---+---+-
> |  |   Total   | Number of |
> | Year | Transfers |   /24s|
> +--+---+---+-
> | 2011 | 3 | 12 |
> | 2012 |10 | 46 |
> | 2013 |18 | 66 |
> | 2014 |   126 |498 |
> | 2015 |   147 |573 |
> | 2016 |45 |177 |
> +--+---++-
>
> 2) Market transfers containing 103/8 space
>
> +--+---+---+
> |  |   Total   | Number of |
> | Year | Transfers |   /24s|
> +--+---+---+
> | 2011 | 2 | 2 |
> | 2012 |21 |68 |
> | 2013 |16 |61 |
> | 2014 |25 |95 |
> | 2015 |67 |   266 |
> | 2016 |56 |   206 |
> +--+---+---+
>
> Thanks,
>
> George K
>
>
>
>
> Cheers
>> -Mike
>> *  sig-policy:  APNIC SIG on resource management policy
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Proposal to revise SIG guidelines

[Masato Yamanishi]

Randy,

>> I would like to propose aligning Chair' term with Co-Chair's term,
>> which means that Chair and all Co-Chair will serve for same two years.

>could make for a tough transition if both are replaced at the same time.

I know that original intension of staggered term is mitigating such
transition difficulties,
but now we have another practice in SIG guideline as follows.

>Unless new Policy SIG Chairs and Co-Chairs are required immediately, there
will be a handover period. Outgoing Chairs and Co-Chairs are expected to
follow >proposals reaching consensus at the current OPM, to the completion
of the Policy Development Process.

In addition, other SIGs, NIR and Co-Operation SIG, are having Chair and
Co-Chair elections simultaneously at least past 4-5 years (maybe more).
Since SIG guideline is applied to these SIGs as well, a gap exist in there
and I would like to fix it.

Regards,
Matt



2016-09-05 19:52 GMT+09:00 Randy Bush :

> [ this is address policy? ]
>
> > Secondary, it can be used by fraud, like hijacking the position of
> > Chair agaist the Community by inviting many persons who never attend
> > the community discussion.
> > ...
> > I would like to propose limiting eligible voters of SIG Chair election
> > to registered participants of APNIC Conference where the election is
> > held.
> >
> > In this context, registered participants include remote participants
> > who register to Confer, or its successor in future.
>
> is there an unstated assumption that many persons could attend the
> meeting who are not registered locally or remotely?  does that
> assumption hold?
>
> > I would like to propose aligning Chair' term with Co-Chair's term,
> > which means that Chair and all Co-Chair will serve for same two years.
>
> could make for a tough transition if both are replaced at the same time.
>
> randy
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Proposal to revise SIG guidelines

[Masato Yamanishi]

Hi Skeeve,

Firstly, I don't think currend proposed solution is perfect, so I'm very
welcome to hear your suggestions how to fix these problems.

Certainly, just e-mail address is NOT enough for Confer registration, but
how can we set a rule in SIG guideline?
Require to identify himself/herself when registering?

Regards,
Matt

2016-09-06 9:41 GMT+09:00 Skeeve Stevens :

> I wouldn't, but many others would.  Don't wait until it's been abused
> before you have to clean it up.
>
>
> ...Skeeve
>
> *Skeeve Stevens - Senior IP Broker*
> *v4Now - *an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/v4now ;  linkedin.
> com/in/skeeve
>
> twitter.com/theispguy ; blog: www.theispguy.com ; Keybase:
> https://keybase.io/skeeve
>
>
> IP Address Brokering - Introducing sellers and buyers
>
> On Tue, Sep 6, 2016 at 10:38 AM, Adam Gosling  wrote:
>
>> Hi Skeeve
>>
>>
>>
>> I’m sure you wouldn’t do that, though. The Secretariat could add more
>> stringent registration requirements into Confer, or use an off-the-shelf or
>> online election platform. The question would always be convenience versus
>> validity.
>>
>>
>>
>> I internally raised the potential for somebody to game the system purely
>> to take advantage of the new travel support for SIG Chairs and so, at APNIC
>> 41 Paul Wilson suggested the community might want to review the procedures
>> to make sure they are comfortable with the new situation.
>>
>>
>>
>> Just to be clear, the Secretariat has no preference, opinion, or
>> objective in the outcome of this discussion. So don’t take anything I say
>> to be an endorsement of any outcome.
>>
>>
>>
>> Adam
>>
>>
>>
>>
>>
>>  On 6/09/2016, 10:18, "Skeeve Stevens"  wrote:
>>
>>
>>
>> This is worrying re Confer as I am quite sure I could register 100,000
>> people with unique addresses.
>>
>>
>>
>> We've entered a new era of bots - this would not be hard.
>>
>>
>>
>> ...Skeeve
>>
>>
>>
>> *Skeeve Stevens - Senior IP Broker*
>>
>> *v4Now - *an eintellego Networks service
>>
>> ske...@v4now.com ; www.v4now.com
>>
>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>>
>> facebook.com/v4now ; linkedin.com/in/skeeve
>>
>> twitter.com/theispguy ; blog: www.theispguy.com ; Keybase:
>> https://keybase.io/skeeve
>>
>> [image: mage removed by sender.]
>>
>> IP Address Brokering - Introducing sellers and buyers
>>
>>
>>
>> On Tue, Sep 6, 2016 at 9:14 AM, Adam Gosling  wrote:
>>
>> Hi Randy
>>
>>
>>  On 5/09/2016, 20:52, "Randy Bush"  wrote:
>>
>> >> [ this is address policy? ]
>>
>> No this is not address policy. The SIG Guidelines are the rules of
>> procedure for all SIGs. The proposal was also sent to the other SIG mailing
>> lists, but will be discussed in the Policy SIG as there is more agenda time
>> there.
>>
>> >> Secondary, it can be used by fraud, like hijacking the position of
>> >> Chair agaist the Community by inviting many persons who never
>> attend
>> >> the community discussion.
>> >> ...
>> >> I would like to propose limiting eligible voters of SIG Chair
>> election
>> >> to registered participants of APNIC Conference where the election
>> is
>> >> held.
>> >>
>> >> In this context, registered participants include remote
>> participants
>> >> who register to Confer, or its successor in future.
>>
>> is there an unstated assumption that many persons could attend the
>> meeting who are not registered locally or remotely?  does that
>> assumption hold?
>>
>> The Secretariat doesn’t physically check registrations at the door to the
>> Policy SIG sessions, I guess a bunch of extra people could wander in
>> without badges. I’m not sure if we would notice.
>>
>> At present remote participation (using the CONFER tool) only requires a
>> simple registration with unique email address. We tried more stringent
>> registration procedures with the Webcasting (like ARIN) and got a lot of
>> negative feedback.
>>
>>
>> > I would like to propose aligning Chair' term with Co-Chair's term,
>> > which means that Chair and all Co-Chair will serve for same two
>> years.
>>
>> could make for a tough transition if both are replaced at the same
>> time.
>>
>>
>> randy
>>
>>
>> *  sig-policy:  APNIC SIG on resource management policy
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>>
>>
>> *  sig-policy:  APNIC SIG on resource management policy
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>
>
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy maili

Re: [sig-policy] Proposal to revise SIG guidelines

[Masato Yamanishi]

Randy and Adam,

>>is there an unstated assumption that many persons could attend the
>>meeting who are not registered locally or remotely?  does that
>>assumption hold?

>The Secretariat doesn’t physically check registrations at the door to the
Policy SIG sessions, I guess a bunch of extra people could wander in
without badges. I’m >not sure if we would notice.

Even if the secretariat would try to check it, I'm afraid that we cannot
refuse non-registered person participating the discussion and election
since PDP says "Anyone may attend the meetings and participate in
discussions and the decision making." and there is no criteria for eligible
voters in SIG guideline.

Regards,
Matt


2016-09-06 8:14 GMT+09:00 Adam Gosling :

> Hi Randy
>
>
>  On 5/09/2016, 20:52, "Randy Bush"  wrote:
>
> >> [ this is address policy? ]
>
> No this is not address policy. The SIG Guidelines are the rules of
> procedure for all SIGs. The proposal was also sent to the other SIG mailing
> lists, but will be discussed in the Policy SIG as there is more agenda time
> there.
>
> >> Secondary, it can be used by fraud, like hijacking the position of
> >> Chair agaist the Community by inviting many persons who never attend
> >> the community discussion.
> >> ...
> >> I would like to propose limiting eligible voters of SIG Chair
> election
> >> to registered participants of APNIC Conference where the election is
> >> held.
> >>
> >> In this context, registered participants include remote participants
> >> who register to Confer, or its successor in future.
>
> is there an unstated assumption that many persons could attend the
> meeting who are not registered locally or remotely?  does that
> assumption hold?
>
> The Secretariat doesn’t physically check registrations at the door to the
> Policy SIG sessions, I guess a bunch of extra people could wander in
> without badges. I’m not sure if we would notice.
>
> At present remote participation (using the CONFER tool) only requires a
> simple registration with unique email address. We tried more stringent
> registration procedures with the Webcasting (like ARIN) and got a lot of
> negative feedback.
>
>
> > I would like to propose aligning Chair' term with Co-Chair's term,
> > which means that Chair and all Co-Chair will serve for same two
> years.
>
> could make for a tough transition if both are replaced at the same
> time.
>
>
> randy
>
>
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Proposal to revise SIG guidelines

[Masato Yamanishi]

Randy,

>personally, i am not sure there is a real problem.  so what if the old
>guard gets thrown out and some new unknown folk get elected.  it might
>be a breath of fresh air.  what actual damage could some fresh blood do?
>some radical change in apnic across the board just might benefit the
>internet.

If new unknown folk is a choice of the community, it is fine and I don't
see any problem.
However, the problem I'm trying to fix is someone can manipulate the
community's view
by inviting several persons who never and will not involve the community
discussion after the election.
(I'm always expecting new and fresh blood to Policy SIG Chair)

Regards,
Matt


2016-09-06 9:35 GMT+09:00 Randy Bush :

> hi:
>
> this kludge is not very well thought out.
>
> not that i am advocating, but an ietfish approach would be a requirement
> to have attended n previous meetings.  makes more sense to me than this
> proposal.  but ...
>
> personally, i am not sure there is a real problem.  so what if the old
> guard gets thrown out and some new unknown folk get elected.  it might
> be a breath of fresh air.  what actual damage could some fresh blood do?
> some radical change in apnic across the board just might benefit the
> internet.
>
> [ historical note: this descends from the first taipei meeting, where
>   there were no voting restrictions.  a bunch of folk showed up just for
>   the ec election and voted in an outsider, shock and horror!  of
>   course, all sorts of rules and restrictions to protect the old guard
>   were immediately put in place. ]
>
> randy
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Proposal to revise SIG guidelines

[Masato Yamanishi]

Hi All,

As you know, it is our current practice that Chair/Co-Chair doesn't
propose a policy by himself/herself in recent APNIC Policy SIG.

However, while it seems that many community members basically agreed with
these problem when I presented them at Singapore
<
https://conference.apnic.net/__data/assets/pdf_file/0006/58992/ambiguouts-points-in-pdp-2013027_1361972669.pdf
>,
nobody has picked them up and propose solutions even after 3 years.
In addition, I believe I'm one of persons who felt these problems most
seriously through my service as Co-Chair/Chair.
So, I decided to propose these solutions by myself.

Please note that I have asked Chair's responsibility of this proposal in
Policy SIG discussion to Sumon, Co-Chair,
to avoid a conflict of interests related with this proposal. Also, I will
not run Policy SIG Chair when my term will be end at APNIC 43 in next Feb
or Mar.
so that I don't have a conflict of interests in that meaning as well.

Thus, please accept my replies and comments for this proposal as one of
community views, not Chair's view.

Regards,
Matt



2016-09-05 19:08 GMT+09:00 Adam Gosling :

> Dear SIG members
>
>
>
> A proposal to modify the APNIC SIG Guidelines relating to the election
>
> of SIG Chairs and Co-Chairs has been submitted for consideration at
>
> APNIC 42 im Colombo, Sri Lanka.
>
>
>
> https://www.apnic.net/sig-chair-elections/proposed-revision.txt
>
>
>
> If agreed. these changes will affect all APNIC SIGs from APNIC 43 in Ho
>
> Chi Minh City, Vietnam.
>
>
>
> Discussion and call for consensus will take place in the Policy SIG.
>
>
>
> https://www.apnic.net/mailinglists
>
>
>
> If successful in the Policy SIG, a consensus call will be made at the
>
> APNIC Member Meeting. There will be no final Comment Period.
>
>
>
> To ensure those not travelling to APNIC 42 are able to participate in
>
> the discussion, you are invited to comment on the Policy SIG Mailing
>
> List before the conference.
>
>
>
> More background to this proposal is available at:
>
>
>
> https://www.apnic.net/community/participate/sigs/chair-elections
>
>
>
> Regards
>
>
>
> Adam
>
>
>
>
>
> ---
>
>
>
> Revising eligible voters of Chair election and Chair's term
>
>
>
> ---
>
>
>
> Proposer:   Masato Yamanishi
>
> myama...@gmail.com
>
>
>
>
>
> 1. Problem statement
>
> 
>
>
>
> 1. Eligible voters in SIG Chair election
>
> In current SIG guidelines, we have no rule or guideline about eligible
>
> voters in SIG Chair election and we have two issues by the lack of such
>
> rule.
>
>
>
> Firstly, we need to have clear guideline whether remote participants
>
> have voting rights for SIG Chair election since current practice is
>
> different in each election.
>
>
>
> Secondary, it can be used by fraud, like hijacking the position of Chair
>
> agaist the Community by inviting many persons who never attend the
>
> community discussion.
>
>
>
> 2. SIG Chair's term of service
>
> While SIG guidelines says "Elections occur yearly. Chair elections and
>
> Co-Chair elections occur in alternate years.", both elections were held
>
> at same meeting in many cases, in particular when a current Co-Chair
>
> stand for the position of Chair. With this current practice having both
>
> elections at same meeting, we are not seeing any significant issues for
>
> long time.
>
>
>
> In addition, there is no alternative condition for the successor's term
>
> if current Chair/Co-Chair resigned or was removed though such
>
> alternative condition is necessary to maintain staggered term as
>
> requested by SIG guideline. (a.k.a. the successor's term of service is
>
> same as remaining term of resigned or removed Chair)
>
>
>
>
>
> 2. Objective of policy change
>
> -
>
>
>
> The objective is preventing confusions related to remote participant as
>
> well as mitigating possible frauds in SIG Chair election by setting
>
> clear rule for eligible voters.
>
>
>
> In addition, we can also expect aligning SIG guideline with current
>
> practice as well as resolving unclearness of the successor's term when
>
> current Chair/Co-Chair resigned or was removed by revising SIG Chair's
>
> term of service.
>
>
>
>
>
> 3. Situation in other regions
>
> --

[sig-policy] New Policy Proposal prop-116: Prohibit to transfer IPv4 addresses in the final /8 block

[Masato Yamanishi]

Dear SIG members



The proposal "prop-116: Prohibit to transfer IPv4 addresses in the final

/8 block" has been sent to the Policy SIG for review.



It will be presented at the Open Policy Meeting at APNIC 42 in Colombo,

Sri Lanka on Wednesday, 5 October 2016.



We invite you to review and comment on the proposal on the mailing list

before the meeting.



The comment period on the mailing list before an APNIC meeting is an

important part of the policy development process. We encourage you to

express your views on the proposal:



- Do you support or oppose this proposal?

 - Does this proposal solve a problem you are experiencing? If so,

  tell the community about your situation.

 - Do you see any disadvantages in this proposal?

 - Is there anything in the proposal that is not clear?

 - What changes could be made to this proposal to make it more

  effective?





Information about this proposal is available at:



http://www.apnic.net/policy/proposals/prop-116



Regards



Masato and Sumon





---



prop-116-v001: Prohibit to transfer IPv4 addresses in the final /8 block



---



Proposer:   Tomohiro Fujisaki

fujis...@syce.net









1. Problem statement





There are a lot of transfers of IPv4 address blocks from 103/8

happening, both within the APNIC region and among RIRs.



The percentage of transfers from 103/8 block is over 10%, which looks so

high, since APNIC manages about 40/8. And also, transfers from the 103/8

block include:

  - Take place within 1 year of distribution, or

  - Multiple blocks to a single organization in case of beyond 1 year.



Further, there is a case where a single organization have received 12

blocks transfers from 103 range.



see:  https://www.apnic.net/manage-ip/manage-resources/transfer-
resources/transfer-logs



>From these figures, it is quite likely that substantial number of 103/8

blocks are being used for transfer purpose.



This conflicts with the concept of distribution of 103/8 block

(prop-062), which is intended to accommodate minimum IPv4 address blocks

for new comers.



prop-062: Use of final /8

https://www.apnic.net/policy/proposals/prop-062





2. Objective of policy change

-



When stated problem is solved, distribution from 103/8 block will be

consistent with its original purpose, for distribution for new entrants

to the industry. Without the policy change, substantial portion of 103/8

blocks will be consumed for transfer purpose.





3. Situation in other regions

-



RIPE-NCC has been discussing to prohibit transfer under the final /8

address block.





4. Proposed policy solution

---



Prohibit transfer IPv4 address under /8 address block (103/8). If the

address block allocated to a LIR is not needed any more, it have to

return to APNIC to allocate to another organization.



This proposal does not prohibit transfers due to M&A. Transfers of 103/8

block due to M&A continues to be allowed, based on the M&A transfer

procedures.





5. Advantages / Disadvantages

-



Advantages:

  - It makes 103/8 blocks available according to the original purpose,

as distribution for new entrants (rather than being consumed for

transfer purpose)



  - IPv4 addresses under final /8 are not transferred to outside APNIC.



  - By prohibiting transfer them, it is possible to keep one /22 for

each LIRs state,  which is fair for all LIRs.



Disadvantages:



None.





6. Impact on resource holders

--



  - LIRs cannot transfer address blocks under 103/8. No big impact while

they use it.



  - Organizations which needs to receive transferred IPv4 can continue

to do so, outside 103/8 blocks (which should be made available for

new entrants)



  - In case of M&A, organizations can transfer 103/8 blocks through M&A

transfer procedures





7. References
-
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Call for Presentations and Proposals for Policy SIG

[Masato Yamanishi]

Dear Colleagues,

The APNIC 42 Policy SIG session and Open Policy Meeting will be held in
Colombo, Sri Lanka on Wednesday, 5 October 2016.

http://conference.apnic.net/42/policy

If you have any ideas to improve policy, or wish to make an informational
presentation about an aspect of resource management, please follow the
instructions below.

The submission deadline for APNIC 42 is 26 August 2016.

Submit a Policy Proposal
--
Complete the online form at:
   http://www.apnic.net/community/policy/proposals/submit

Proposal a presentation

Send your synopsis to:
pol...@apnic.net


We look forward to and encourage your participation in the APNIC 42 OPM.

Kind regards

Masato and Sumon
APNIC Policy SIG Chairs
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Whois accuracy presentations in 2nd session

[Masato Yamanishi]

Dear colleagues,

You may have already aware that we will have a couple of presentations
about whois accuracy in 2nd session, 11:00-12:30AM Thu Feb  25th.
While they will be presented by APNIC staffs, the problem behind them came
from the Community indeed.

A couple of weeks ago, one draft proposal raising this issue was sent to
the Secretariat.
However, Chairs found that it was not ready for the community discussion
and the author doesn't intend to revise it.
After discussing with the author, the author agreed not to proceed it as
official proposal, instead APNIC staff will
present this problem as informal presentation.

As Chairs are asking APNIC staff to upload their presentations as soon as
possible,
please check them once published and feel free to express your opinions on
the list even before the SIG meeting.

Regards,
Masato and Summon
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Proposal authors withdraw prop-115

[Masato Yamanishi]

Dear colleagues,

Following the release of a new version and subsequent discussion on the
Policy SIG mailing list, the authors of prop-115 have withdrawn the
proposal.

The authors have requested time for an informational presentation to
discuss the issues identified in the prop-115 Problem Statement.

As a result the Policy SIG meeting at APNIC 41 has no active proposals
to consider. We will use the available time to discuss this proposal and
for other informational presentations related to the Policy SIG Charter.

There is a draft agenda published on the APNIC 41 website. Please monitor
this page for program updates.

https://conference.apnic.net/41/program#agenda

Regards,

Matt and Sumon
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Prop-115 revised.

[Masato Yamanishi]

Adam,

No, it's not your fault. Just timing issue.

Regards,
Matt

2016-02-10 7:55 GMT+09:00 Adam Gosling :

> Hello Masato, all
>
> Sorry for the delay, I was at home sick yesterday and as I was not
> expecting this new version, I hadn’t made any arrangements. So I did not
> see this email until this morning.
>
> I have posted the new version to the proposal status page.
> https://www.apnic.net/policy/proposals/prop-115
>
> Kind regards,
>
> Adam
>
> ___
> Adam Gosling
> Internet Policy Development Consultant, APNIC
> e: a...@apnic.net
> p: +61 7 3858 3142
> m: +61 421 456 243
> t: @bout_policy
> ___
>
> Join the conversation:   https://blog.apnic.net/
> ___
>
>
> On 10/02/2016, 02:37, "sig-policy-boun...@lists.apnic.net on behalf of
> Masato Yamanishi"  myama...@gmail.com> wrote:
>
> Then, I cannot receive it from the Secretariat and post it until tomorrow
> morning will come to Brisbane.
> Please be patient.
>
> Masato@iPhone
>
>
> On Feb 9, 2016, at 22:25, 藤崎智宏  wrote:
>
> Hi Skeeve,
>
> Thank you for your comment.
>
> Sure, and I'm sorry for confusion.
>
> We just informed submission of revised text, and main modification
> points where we would like to ask community comments and discussion
> here and in next meeting (Of course, any comments will be gratefully
> appreciated.).
>
> Our revised text will be appeared on the web soon.
>
> Yours Sincerely,
> ---
> Tomohiro Fujisaki
>
>
> 2016-02-09 21:51 GMT+09:00 Skeeve Stevens :
> >
> > Hi Tomohiro-san,
> >
> > With all respect, discussions are for the mailing list.  The policy-sig
> at APNIC isn't to think up policy, but to present a policy, discuss and
> tweak if necessary.
> >
> > You really should present your ideas here, and let us all discuss.  Yes,
> sometimes there is not much discussion, but you should at least try.
> >
> > I hope to see what your suggestions are.
> >
> >
> > ...Skeeve
> >
> > Skeeve Stevens - Senior IP Broker
> > v4Now - an eintellego Networks service
> > ske...@v4now.com ; www.v4now.com
> >
> > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> >
> > facebook.com/v4now ; linkedin.com/in/skeeve
> >
> > twitter.com/theispguy ; blog: www.theispguy.com ; Keybase:
> https://keybase.io/skeeve
> >
> >
> > IP Address Brokering - Introducing sellers and buyers
> >
> > On Tue, Feb 9, 2016 at 11:34 PM, 藤崎智宏  wrote:
> >>
> >> Dear all,
> >>
> >> We've posted new version of prop-115, and it will appear on the web
> soon.
> >>
> >> Main modification points are:
> >>  - remove IPv4 text
> >>  - propose several methods to register and distribute IPv6 assignment
> >>information  (thank you for your suggestion in the previous sig
> meeting)
> >>
> >> Authors discussed about methods, but could not reach a decision which to
> >> be used.  At this time, in the next sig meeting, we would like to
> discuss more
> >> about the methods and find a conclusion.
> >>
> >> We appreciate if you give us any comments or suggestions.
> >>
> >> Yours Sincerely,
> >> --
> >> Ruri Hiromi
> >> Tomohiro Fujisaki
> >> *  sig-policy:  APNIC SIG on resource management policy
>   *
> >> ___
> >> sig-policy mailing list
> >> sig-policy@lists.apnic.net
> >> http://mailman.apnic.net/mailman/listinfo/sig-policy
> >
> >
>
> *  sig-policy:  APNIC SIG on resource management policy
>   *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] New version of prop-115: Registration of detailed assignment information in whois DB

[Masato Yamanishi]

Dear SIG members

A new version of the proposal "prop-115: Registration of detailed
assignment information in whois DB" has been sent to the Policy SIG for
review.

The new text is copied below for your convenience. A marked-up
comparison to earlier versions is available from the proposal status
page at:

http://www.apnic.net/policy/proposals/prop-115

You are encouraged to express your views on the proposal:

 - Do you support or oppose the proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Masato, Sumon
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Prop-115 revised.

[Masato Yamanishi]

Then, I cannot receive it from the Secretariat and post it until tomorrow 
morning will come to Brisbane.
Please be patient.

Masato@iPhone


> On Feb 9, 2016, at 22:25, 藤崎智宏  wrote:
> 
> Hi Skeeve,
> 
> Thank you for your comment.
> 
> Sure, and I'm sorry for confusion.
> 
> We just informed submission of revised text, and main modification 
> points where we would like to ask community comments and discussion 
> here and in next meeting (Of course, any comments will be gratefully 
> appreciated.).
> 
> Our revised text will be appeared on the web soon.
> 
> Yours Sincerely,
> ---
> Tomohiro Fujisaki
> 
> 
> 2016-02-09 21:51 GMT+09:00 Skeeve Stevens :
> >
> > Hi Tomohiro-san,
> >
> > With all respect, discussions are for the mailing list.  The policy-sig at 
> > APNIC isn't to think up policy, but to present a policy, discuss and tweak 
> > if necessary.
> >
> > You really should present your ideas here, and let us all discuss.  Yes, 
> > sometimes there is not much discussion, but you should at least try.
> >
> > I hope to see what your suggestions are.
> >
> >
> > ...Skeeve
> >
> > Skeeve Stevens - Senior IP Broker
> > v4Now - an eintellego Networks service
> > ske...@v4now.com ; www.v4now.com
> >
> > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> >
> > facebook.com/v4now ; linkedin.com/in/skeeve
> >
> > twitter.com/theispguy ; blog: www.theispguy.com ; Keybase: 
> > https://keybase.io/skeeve
> >
> >
> > IP Address Brokering - Introducing sellers and buyers
> >
> > On Tue, Feb 9, 2016 at 11:34 PM, 藤崎智宏  wrote:
> >>
> >> Dear all,
> >>
> >> We've posted new version of prop-115, and it will appear on the web soon.
> >>
> >> Main modification points are:
> >>  - remove IPv4 text
> >>  - propose several methods to register and distribute IPv6 assignment
> >>information  (thank you for your suggestion in the previous sig meeting)
> >>
> >> Authors discussed about methods, but could not reach a decision which to
> >> be used.  At this time, in the next sig meeting, we would like to discuss 
> >> more
> >> about the methods and find a conclusion.
> >>
> >> We appreciate if you give us any comments or suggestions.
> >>
> >> Yours Sincerely,
> >> --
> >> Ruri Hiromi
> >> Tomohiro Fujisaki
> >> *  sig-policy:  APNIC SIG on resource management policy
> >>*
> >> ___
> >> sig-policy mailing list
> >> sig-policy@lists.apnic.net
> >> http://mailman.apnic.net/mailman/listinfo/sig-policy
> >
> >
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] FINAL REMINDER: APNIC Policy SIG Deadline is 15 January 2016

[Masato Yamanishi]

Dear Colleagues,

This is a final reminder for the submission of proposals to be
considered for consensus at the APNIC 41 Open Policy Meeting in
Auckland, New Zealand.

If you have a proposal for a policy change that would improve IP address
and ASN management in the region, please follow the instructions below
to submit your proposal before 23:59 (UTC +10) on 15 January 2016.

Only proposals submitted by this date will be considered for consensus
at the Auckland Policy SIG meeting

How to submit your Policy Proposal
-

There are two ways to submit a policy proposal:

1. Use the online form at:
https://www.apnic.net/community/policy/proposals/submit-a-policy-proposal

2. Send your proposal in TEXT format to .
https://www.apnic.net/community/policy/proposals/proposal_template.txt

If you have identified an issue, but do not know the solution, you are
able to complete the Problem Statement part of the proposal submission
form and ask the community to help develop the best solution.


More information
-

Learn more about the APNIC 41 OPM:

http://conference.apnic.net/41/policy

Guideline for proposal authors

https://www.apnic.net/community/policy/guidelines/authors

APNIC's PDP is explained at:

http://www.apnic.net/community/policy/process

View current and past policy proposals at:

http://www.apnic.net/policy/proposals


We look forward to and encourage your participation in the APNIC PDP.


Kind regards
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] An interesting policy question

[Masato Yamanishi]

Lu,

> I am sorry to say, but "Same thing" is not correct here, I have never
attack Chair before, saying same thing might imply you are agreeing that I
have done so before.

I meant same thing as Skeeve mentioned by himself.
It was not my intension to decide whether your behavior in somewhere else
is appropriate or not unless it was done in here.

Regards,
Masato Yamanishi
APNIC Policy SIG Chair


2015-12-06 21:56 GMT+09:00 Lu Heng :

> Hi Chair
>
> On Sun, Dec 6, 2015 at 1:53 PM, Masato Yamanishi 
> wrote:
>
>> Skeeve,
>>
>> Please don't forget that I'm neutral for anybody's opinion in here
>> including Lu and Owen,
>> and I warned your behavior calling somebody unappropreately, not your
>> opinion.
>>
>> including attacking the Chair when he doesn't agree with them.  Is this
>> what you want to happily let him do to APNIC lists?
>>
>>
>> Of course not, but I'm afraid you are doing same thing on this list right
>> now.
>>
>
> I am sorry to say, but "Same thing" is not correct here, I have never
> attack Chair before, saying same thing might imply you are agreeing that I
> have done so before.
>
> This is an accusation he just made without any ground and any relation to
> this ongoing policy discussion, I hope you would agree.
>
>>
>> Masato@iPhone
>>
>>
>> On Dec 6, 2015, at 21:25, Skeeve Stevens  wrote:
>>
>> Masato,
>>
>> I don't care if you are the Chair or not.  Do not use your position to
>> accuse someone of personally attacking someone when they are not.  If you
>> were being a fair Char, then I'd also expect you to deal with your friend
>> Randys passive aggressive insinuations - which you never do, so just back
>> off.
>>
>> I suggest you go research Lu's posts on ARIN and Ripe over the last year
>> and you will see the antagonistic approach he uses to turn lists into
>> battles, including attacking the Chair when he doesn't agree with them.  Is
>> this what you want to happily let him do to APNIC lists?
>>
>> I for one thank Owen for informing us that Lu was trying to start the
>> same/similar arguments on this list has he has done on other RIR lists.  I
>> hardly think we need to rehash the same debates unless they are particular
>> reference to APNIC and its policy.
>>
>> ...Skeeve
>>
>> *Skeeve Stevens - Senior IP Broker*
>> *v4Now - *an eintellego Networks service
>> ske...@v4now.com ; www.v4now.com
>>
>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>>
>> facebook.com/v4now ;  <http://twitter.com/networkceoau>
>> linkedin.com/in/skeeve
>>
>> twitter.com/theispguy ; blog: www.theispguy.com ; Keybase:
>> https://keybase.io/skeeve
>>
>>
>> IP Address Brokering - Introducing sellers and buyers
>>
>> On Sun, Dec 6, 2015 at 10:51 PM, Masato Yamanishi 
>> wrote:
>>
>>> Skeeve,
>>>
>>> As the Chair, let me warn you that calling somebody "trouble maker" on
>>> the list is a personal attack and it conflicts with APNIC Code of Conduct
>>> as shown in below.
>>>
>>> <
>>> https://www.apnic.net/community/participate/mailinglists/code-of-conduct
>>> >
>>>
>>> Masato@iPhone
>>>
>>>
>>> On Dec 6, 2015, at 20:22, Skeeve Stevens  wrote:
>>>
>>> Says another trouble maker :)
>>>
>>>
>>> ...Skeeve
>>>
>>> *Skeeve Stevens - Senior IP Broker*
>>> *v4Now - *an eintellego Networks service
>>> ske...@v4now.com ; www.v4now.com
>>>
>>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>>>
>>> facebook.com/v4now ;  <http://twitter.com/networkceoau>
>>> linkedin.com/in/skeeve
>>>
>>> twitter.com/theispguy ; blog: www.theispguy.com ; Keybase:
>>> https://keybase.io/skeeve
>>>
>>>
>>> IP Address Brokering - Introducing sellers and buyers
>>>
>>> On Sun, Dec 6, 2015 at 10:09 PM, Randy Bush  wrote:
>>>
>>>> > you seem like a trouble maker.
>>>>
>>>> ad homina are not appropriate
>>>>
>>>> randy
>>>>
>>>
>>> *  sig-policy:  APNIC SIG on resource management policy
>>>   *
>>> ___
>>> sig-policy mailing list
>>> sig-policy@lists.apnic.net
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>>
>>>
>>
>> *  sig-policy:  APNIC SIG on resource management policy
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>
>
> --
> --
> Kind regards.
> Lu
>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] An interesting policy question

[Masato Yamanishi]

Skeeve,

Please don't forget that I'm neutral for anybody's opinion in here including Lu 
and Owen,
and I warned your behavior calling somebody unappropreately, not your opinion.

> including attacking the Chair when he doesn't agree with them.  Is this what 
> you want to happily let him do to APNIC lists?

Of course not, but I'm afraid you are doing same thing on this list right now.

Masato@iPhone


> On Dec 6, 2015, at 21:25, Skeeve Stevens  wrote:
> 
> Masato,
> 
> I don't care if you are the Chair or not.  Do not use your position to accuse 
> someone of personally attacking someone when they are not.  If you were being 
> a fair Char, then I'd also expect you to deal with your friend Randys passive 
> aggressive insinuations - which you never do, so just back off.
> 
> I suggest you go research Lu's posts on ARIN and Ripe over the last year and 
> you will see the antagonistic approach he uses to turn lists into battles, 
> including attacking the Chair when he doesn't agree with them.  Is this what 
> you want to happily let him do to APNIC lists?
> 
> I for one thank Owen for informing us that Lu was trying to start the 
> same/similar arguments on this list has he has done on other RIR lists.  I 
> hardly think we need to rehash the same debates unless they are particular 
> reference to APNIC and its policy.
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/v4now ; linkedin.com/in/skeeve
> twitter.com/theispguy ; blog: www.theispguy.com ; Keybase: 
> https://keybase.io/skeeve
> 
> IP Address Brokering - Introducing sellers and buyers
> 
>> On Sun, Dec 6, 2015 at 10:51 PM, Masato Yamanishi  wrote:
>> Skeeve,
>> 
>> As the Chair, let me warn you that calling somebody "trouble maker" on the 
>> list is a personal attack and it conflicts with APNIC Code of Conduct as 
>> shown in below.
>> 
>> <https://www.apnic.net/community/participate/mailinglists/code-of-conduct>
>> 
>> Masato@iPhone
>> 
>> 
>>> On Dec 6, 2015, at 20:22, Skeeve Stevens  wrote:
>>> 
>>> Says another trouble maker :)
>>> 
>>> 
>>> ...Skeeve
>>> 
>>> Skeeve Stevens - Senior IP Broker
>>> v4Now - an eintellego Networks service
>>> ske...@v4now.com ; www.v4now.com
>>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>>> facebook.com/v4now ; linkedin.com/in/skeeve
>>> twitter.com/theispguy ; blog: www.theispguy.com ; Keybase: 
>>> https://keybase.io/skeeve
>>> 
>>> IP Address Brokering - Introducing sellers and buyers
>>> 
>>>> On Sun, Dec 6, 2015 at 10:09 PM, Randy Bush  wrote:
>>>> > you seem like a trouble maker.
>>>> 
>>>> ad homina are not appropriate
>>>> 
>>>> randy
>>> 
>>> *  sig-policy:  APNIC SIG on resource management policy 
>>>   *
>>> ___
>>> sig-policy mailing list
>>> sig-policy@lists.apnic.net
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
> 
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] An interesting policy question

[Masato Yamanishi]

Understood.
I just want to make sure you have a right to ask deleting it.

Masato@iPhone


On Dec 6, 2015, at 21:00, Randy Bush  wrote:

>> As shown in APNIC Code of Conduct, you can ask APNIC to delete
>> comments if you want.
> 
> i am strongly against this.  an archive should be a true archive.
> 
> randy
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] An interesting policy question

[Masato Yamanishi]

Lu and Owen,

I'm doubt that "elsewhere" and "one of the lists" is good way to express your 
opinion to the Community.
Please make a reference clear, if you want to continue this discussion.

Masato@iPhone
APNIC Policy SIG Chair


> On Dec 6, 2015, at 18:22, Owen DeLong  wrote:
> 
> Lu, as I stated elsewhere, I did read your post, but I do not trust you.
> 
> Owen
> 
>> On Dec 6, 2015, at 01:13 , h...@anytimechinese.com wrote:
>> 
>> I have explained the reasoning of asking it fairly well in one of the list 
>> and Owen just didn't read it and speculate my action, fair warning, read to 
>> Owen, do not speculate people's action on public space without ground.l, 
>> especially such action was already explained publicly. 
>> 
>>> On 6 Dec 2015, at 5:06 AM, Owen DeLong  wrote:
>>> 
>>> Fair warning, Lu asked the identical question on the ARIN list and (I 
>>> presume the RIPE list since he left RIPE in all
>>> the key places in the one he posted to ARIN).
>>> 
>>> It seems to me that he may be doing some form of registry policy shopping.
>>> 
>>> Owen
>>> 
 On Dec 4, 2015, at 06:07 , Skeeve Stevens  wrote:
 
 Hi Lu,
 
 1st: I would say no.  There are no followups after allocation and there 
 should not be due to the many complication issues that can happen.
 
 2nd: I would say no.  The changing of network infrastructure should NOT 
 invalidate the original request which is approved. 
 
 
 
 ...Skeeve
 
 Skeeve Stevens - Senior IP Broker
 v4Now - an eintellego Networks service
 ske...@v4now.com ; www.v4now.com
 Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
 facebook.com/v4now ; linkedin.com/in/skeeve
 twitter.com/theispguy ; blog: www.theispguy.com ; Keybase: 
 https://keybase.io/skeeve
 
 IP Address Brokering - Introducing sellers and buyers
 
> On Fri, Dec 4, 2015 at 8:12 PM, Lu Heng  wrote:
> Hi
> 
> I have an policy question regarding the "need".
> 
> We all know when RIR makes approves assignment LIR made if it is beyond 
> LIR's assignment window, while the "need" has changed, the assignment 
> become invalid.
> 
> The question come to what the definition of need, as a young people here, 
> I am a bit confused, Below I have few examples, please enlighten me if 
> anyone has an thought about it.
> 
> First one:
> 
> Company A provides 100 customer dedicated server service at location A, 
> RIR makes an assignment for 100 IP for his infrastructure, if, under 
> condition that no other factor was changed, Company A moved his 
> infrastructure to location B, but still providing same service to same 
> customer, does the company's action need to be notified  to RIR? And does 
> this action considered invalid the original assignment?
> 
> Second one:
> 
> Company A provides web hosting service, but any casted in 3 location, and 
> has provided the evidence of 3 location to the RIR during the time the 
> company getting valid assignment, then A decided to cut 3 location to 2 
> location, does this invalid original assignment and need to be notified 
> to RIR?
> 
> So the bottom line is, what is the definition of need, is it defined as 
> the service you are providing or defined as whole package of any of 
> original justification material was provided, if was the later, then does 
> it imply that anything, including location of the infrastructure, 
> upstream providers etc has changed due to operational need, it will be 
> considered as change of purpose of use and need to be notified to RIR?
> 
> What should be the right interpretation of the policy by then?
> 
> 
> -- 
> --
> Kind regards.
> Lu
> 
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
 
 *  sig-policy:  APNIC SIG on resource management policy
*
 ___
 sig-policy mailing list
 sig-policy@lists.apnic.net
 http://mailman.apnic.net/mailman/listinfo/sig-policy
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] An interesting policy question

[Masato Yamanishi]

Lu and Randy,

As shown in APNIC Code of Conduct, you can ask APNIC to delete comments if you 
want.

(Skip)
APNIC does not routinely monitor or moderate the discussions on the APNIC 
Mailing Lists. However, APNIC reserves the right to delete or redact comments 
that contain content that APNIC considers to be unacceptable. This includes 
(but is not limited to) any content that:
Is being used to abuse, harass, stalk, or threaten others
Is libellous, knowingly false, or misrepresents another person
Infringes upon a copyright or trademark
Violates an obligation of confidentiality
Violates the privacy of others including posting emails of others without their 
permission
Uses derogatory or inflammatory language
If APNIC exercises its right to delete or redact a comment, it will say so and 
explain why. If you believe that a comment on the Mailing Lists contain content 
that is unacceptable, please notify APNIC by emailing pr [at] apnic.net.

Masato@iPhone
APNIC Policy SIG Chair



> On Dec 6, 2015, at 20:22, Skeeve Stevens  wrote:
> 
> Says another trouble maker :)
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/v4now ; linkedin.com/in/skeeve
> twitter.com/theispguy ; blog: www.theispguy.com ; Keybase: 
> https://keybase.io/skeeve
> 
> IP Address Brokering - Introducing sellers and buyers
> 
>> On Sun, Dec 6, 2015 at 10:09 PM, Randy Bush  wrote:
>> > you seem like a trouble maker.
>> 
>> ad homina are not appropriate
>> 
>> randy
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] An interesting policy question

[Masato Yamanishi]

Skeeve,

As the Chair, let me warn you that calling somebody "trouble maker" on the list 
is a personal attack and it conflicts with APNIC Code of Conduct as shown in 
below.



Masato@iPhone


> On Dec 6, 2015, at 20:22, Skeeve Stevens  wrote:
> 
> Says another trouble maker :)
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/v4now ; linkedin.com/in/skeeve
> twitter.com/theispguy ; blog: www.theispguy.com ; Keybase: 
> https://keybase.io/skeeve
> 
> IP Address Brokering - Introducing sellers and buyers
> 
>> On Sun, Dec 6, 2015 at 10:09 PM, Randy Bush  wrote:
>> > you seem like a trouble maker.
>> 
>> ad homina are not appropriate
>> 
>> randy
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Deadline for new Policy Proposals

[Masato Yamanishi]

Dear Colleagues,

APNIC policies are decided by community members and implemented by the
APNIC staff. 

The Policy Development Process (PDP) is a way for anybody to propose a
policy change and participate in the decisions.

This begins when somebody submits a Policy Proposal to the APNIC Policy
SIG before the deadlines established in the PDP.

For proposals to be discussed at APNIC 41 in Auckland, New Zealand, the
deadline is Friday, 15 January 2016.

If you have an idea to improve APNIC IP address and ASN policy, please
follow the instructions below to submit your proposal before the
deadline.


How to submit your Policy Proposal
-

There are two ways to submit a policy proposal:

1. Use the online form at:
  http://www.apnic.net/community/policy/proposals/submit

2. Send your proposal in TEXT format to .
  http://www.apnic.net/community/policy/process/proposal_template.txt

If you have identified an issue, but do not know the solution, you are
able to complete the Problem Statement part of the proposal submission
form and ask the community to help develop the best solution.


More information
-

Learn more about the APNIC 41 OPM:

   http://conference.apnic.net/41/policy

Guideline for proposal authors

 https://www.apnic.net/community/policy/guidelines/authors

APNIC's PDP is explained at:

   http://www.apnic.net/community/policy/process

View current and past policy proposals at:

   http://www.apnic.net/policy/proposals


We look forward to and encourage your participation in the APNIC PDP.


Kind regards

Masato, Sumon
Policy SIG Chairs

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] End of Comment Period for prop-114: Modification in the ASN eligibility criteria

[Masato Yamanishi]

Dear colleagues

The four-week final comment period for the proposal 'Modification in the
ASN eligibility criteria' has ended.

During the comment period there was continued support for the proposal.
The Chairs therefore deem that consensus has been maintained
on the proposal.

We formally request that the APNIC Executive Council endorse this
proposal.

For a detailed history of this proposal see:

http://www.apnic.net/policy/proposals/prop-114

Regards


APNIC Policy SIG Chairs

Masato, Sumon


---

prop-114-v003: Modification in the ASN eligibility criteria

---

Proposer:  Aftab Siddiqui
   aftab.siddi...@gmail.com

   Skeeve Stevens
   ske...@eintellegonetworks.com


1. Problem statement


   The current ASN assignment policy states two eligibility criteria and
   that both criteria should be fulfilled in order to obtain an ASN. The
   policy seems to imply that both requirements i.e. multi-homing and
   clearly defined single routing policy must be met simultaneously,
   this has created much confusion in interpreting the policy.

   As a result organizations have either provided incorrect information
   to get the ASN or barred themselves from applying where they still
   have a valid justification for obtaining an ASN.


2. Objective of policy change
-

   In order to make the policy guidelines simpler we are proposing to
   modify the text describing the eligibility criteria for ASN
   assignment by providing alternate criteria to obtaining an ASN.


3. Situation in other regions
-

ARIN:
It is not mandatory but optional to be multi-homed in order get ASN

RIPE:
Policy to remove multi-homing requirement is currently in discussion
and the current phase ends 12 February 2015 (awaiting Chair decision)
Policy - https://www.ripe.net/ripe/policies/proposals/2014-03

LACNIC:
Only inter-connect is mandatory not multi-homing

AFRINIC:
It is mandatory to be multi-homed in order to get ASN.


4. Proposed policy solution
---

An organisation is eligible for an ASN assignment if:

- they are currently multi-homed, OR

- have previous allocated provider independent address space by
  APNIC, AND intend to multi-home in the future


5. Advantages / Disadvantages
-

Advantages:

By adding the additional criteria of Guidelines managed by APNIC
Secretariat, this would enable the Secretariat to make decisions
based on common or rare use cases, but that may still be a valid
request.

Disadvantages:

It may be perceived that this policy would enable members to obtain
ASN’s more easily, and in return cause faster consumption of ASN’s
in the region.  Given the relative ease of obtaining an ASN with
‘work around’ methods, we do not perceive this will actually have
any effect.


6. Impact on resource holders
-

No impact on existing resource holders.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] End of Comment Period for prop-113: Modification in the IPv4 eligibility criteria

[Masato Yamanishi]

Dear colleagues

The four-week final comment period for the proposal 'Modification in the
IPv4 eligibility criteria' has ended.

During the comment period there was continued support for the proposal.
The Chairs therefore deem that consensus has been maintained
on the proposal.

We formally request that the APNIC Executive Council endorse this
proposal.

For a detailed history of this proposal see:

http://www.apnic.net/policy/proposals/prop-113

Regards


APNIC Policy SIG Chairs

Masato, Sumon




prop-113-v003: Modification in the IPv4 eligibility criteria



Proposer:  Aftab Siddiqui
   aftab.siddi...@gmail.com

   Skeeve Stevens
   ske...@eintellegonetworks.com


1. Problem statement


The current APNIC IPv4 delegation policy defines multiple
eligibility criteria and applicants must meet one criteria to be
eligible to receive IPv4 resources. One of the criteria dictates
that “an organization is eligible if it is currently multi-homed
with provider-based addresses, or demonstrates a plan to multi-home
within one month” (section 3.3).

The policy seems to imply that multi-homing is mandatory even if
there is no use case for the applicant to be multi-homed or even
when there is only one upstream provider available, this has created
much confusion in interpreting this policy.

As a result organizations have either tempted to provide incorrect
or fabricated multi-homing information to get the IPv4 resources or
barred themselves from applying.


2. Objective of policy change
-

In order to make the policy guidelines simpler we are proposing to
modify the text of section 3.3.


3. Situation in other regions
-

ARIN:
There is no multi-homing requirement

RIPE:
There is no multi-homing requirement.

LACNIC:
Applicant can either have multi-homing requirement or interconnect.

AFRINIC:
There is no multi-homing requirement.


4. Proposed policy solution
---

Section 3.3: Criteria for small delegations

An organization is eligible if:

- it is currently multi-homed, OR

- currently utilising provider (ISP) assignment of at least a /24,
  AND intends to be multi-homed, OR

- intends to be multi-homed, AND advertise the prefixes within
  6 months

Organizations requesting a delegation under these terms must
demonstrate that they are able to use 25% of the requested addresses
immediately and 50% within one year.


5. Advantages / Disadvantages
-

Advantages:

Simplifies the process of applying for IPv4 address space for small
delegations and delays the immediate requirement for multi-homing as
determined to be appropriate within the timeframe as detailed in
Section 3.3.


Disadvantages:

There is no known disadvantage of this proposal.


6. Impact on resource holders
-

No impact on existing resource holders.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] The status of APNIC's IPv4 resources

[Masato Yamanishi]

Owen and All,

> I think this is an appropriate time frame for runout of this pool as it
will be at least that long before new entrants are not > in need of some
way to communicate with the legacy IPv4 internet.

In 2010, I was told that the transition would be end in 5 years.
In 2000…… Where are we right now?
I bet my 5 cents that we just started long long way.

Regards,
Masato Yamanishi


2015-09-15 2:36 GMT+09:00 Owen DeLong :

>
> On Sep 14, 2015, at 01:59 , Masato Yamanishi  wrote:
>
> Dear Colleagues,
>
> In Jakarta, Geoff Huston presented the status of our IPv4 resources, in
> particular about exhaustion and transfer,
> and some participants asked to summarize and post it to the list for
> further discussion.
>
> Following is Chairs' summary of the presentation and discussion.
>
> 1. Status of APNIC Final /8 pool (103/8)
>- Will run out ~4-5 years
>
>
> I think this is an appropriate time frame for runout of this pool as it
> will be at least that long before new entrants are not in need of some way
> to communicate with the legacy IPv4 internet.
>
> 2. Status of IANA Recovered pool (non-103)
>- Will run out in next 7 months+
>- IANA may allocate additional space in every 6 months
>- This pool will repeatedly ‘run-out’ as IANA delegates more space and
> it is distributed by APNIC
>- May need policy to deal with temporary exhaustion of the non-103 pool
>  -> Close the door when exhausted or create the waiting list and put
> further applications to there?
>
>
> I really don’t care what we do here. What would be the default action if
> no policy change is enacted? Can we get clarification from staff on that?
> Absent that being a particularly bad outcome (unlikely), I say let’s not
> focus on rearranging the IPv4 deck chairs any further.
>
> 3. Some address spaces in 103/8 were transferred within 12months since
> initial allocation
>- There is no policy to prohibit it while the Secretariat asks in
> review process
>
>
> Closing the door after the horses have left the barn is likely pointless.
> The community specifically chose to exclude this concern from the transfer
> policy during its development (it’s not like it was not discussed), so I
> say let’s spend this energy getting IPv6 deployed rather than rearranging
> the IPv4 deck chairs any further.
>
> Owen
>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Prop-115 returned to author for further consideration

[Masato Yamanishi]

Aftab and All,

I'm very sorry that I didn't express myself well in the meeting and in the
report,
(please understand that Adam and I should make this report in 15mins)
but I expect the author to improve prop-115 based on the discussion and the
survey result.

Regards,
Masato Yamanishi
APNIC SIG Chair

2015-09-14 22:13 GMT+09:00 Aftab Siddiqui :

>
> I believe, "pushed back to mailing list for discussion" and "returned the
> proposal to authors for further consideration" are two different things.
>
> *From Transcript:*
>
> So I need to decide how to proceed with this proposal
>
> itself.
>
> Let me push back this proposal to the mailing list
>
> and also ask to have such survey to the AMM this
>
> evening.  Is it okay?
>
>
> *From AMM Report:*
>
>
> [image: Screenshot 2015-09-14 23.07.34.png]
>
>
>>
>> Version 3 of prop-115: Registration of detailed assignment information
>> in whois DB, did not reach consensus at the APNIC 40 Open
>> Policy Meeting.
>>
>> The Policy SIG Chair requested the Secretariat conduct further research
>> into the problem statement and returned the proposal to the authors for
>> further consideration.
>>
>>
> Best Wishes,
>
> Aftab A. Siddiqui.
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Discussion before vs after asking consensus

[Masato Yamanishi]

Thanks Adam,

Of course, I meant prop-114 and 115, not 104 and 105.

Masato@iPhone

> On Sep 15, 2015, at 10:01, Masato Yamanishi  wrote:
> 
> Yes, I know.
> Do I need to fix it?
> 
> Masato@iPhone
> 
>> On Sep 15, 2015, at 09:46, Adam Gosling  wrote:
>> 
>> Hello Masato,
>> 
>> I think you mean (one opposition for prop-114 and one support for prop-115) 
>> 
>> Not 104 and 105.
>> 
>> Adam
>> 
>> 
>> 
>> 
>> On 14/09/2015 18:28, "sig-policy-boun...@lists.apnic.net on behalf of Masato 
>> Yamanishi" > myama...@gmail.com> wrote:
>> 
>> Dear Colleagues,
>> 
>> While now I'm seeing a lot of comments on the list and it is good thing,
>> let me ask you to state these comments before asking consensus in OPM.
>> 
>> While I have announced three proposal discussed in Jakarta, only two comments
>> (one opposition for prop-104 and one support for prop-105) were made on the 
>> list.
>> http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/08/
>> Even in the meeting, the discussion was not so active compared to previous 
>> meetings.
>> 
>> Without enough comments and discussions before asking consensus, authors 
>> cannot
>> improve their proposals in timely manner. Also, few discussion makes 
>> difficult for Chairs
>> to gauging community's opinion. As a result, proposals may need more 
>> meetings to
>> reach consensus or fail. Certainly, "no interest" is one of possible 
>> opinions,
>> but it is not easy to distinguish them from "not yet been interested" or 
>> "just hesitate".
>> 
>> IMO, current situation is not bottom-up discussion and rather it looks like 
>> a voting
>> for the agenda which were provided by somebody.
>> 
>> So, please express your opinion and have productive discussion before asking 
>> consensus
>> in Auckland and future meetings.
>> 
>> Thank you for your understanding.
>> 
>> Regards,
>> Masato Yamanishi
>> APNIC Policy SIG Chair
>> 
>> 
>> 
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Discussion before vs after asking consensus

[Masato Yamanishi]

Yes, I know.
Do I need to fix it?

Masato@iPhone

> On Sep 15, 2015, at 09:46, Adam Gosling  wrote:
> 
> Hello Masato,
> 
> I think you mean (one opposition for prop-114 and one support for prop-115) 
> 
> Not 104 and 105.
> 
> Adam
> 
> 
> 
> 
> On 14/09/2015 18:28, "sig-policy-boun...@lists.apnic.net on behalf of Masato 
> Yamanishi"  myama...@gmail.com> wrote:
> 
> Dear Colleagues,
> 
> While now I'm seeing a lot of comments on the list and it is good thing,
> let me ask you to state these comments before asking consensus in OPM.
> 
> While I have announced three proposal discussed in Jakarta, only two comments
> (one opposition for prop-104 and one support for prop-105) were made on the 
> list.
> http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/08/
> Even in the meeting, the discussion was not so active compared to previous 
> meetings.
> 
> Without enough comments and discussions before asking consensus, authors 
> cannot
> improve their proposals in timely manner. Also, few discussion makes 
> difficult for Chairs
> to gauging community's opinion. As a result, proposals may need more meetings 
> to
> reach consensus or fail. Certainly, "no interest" is one of possible opinions,
> but it is not easy to distinguish them from "not yet been interested" or 
> "just hesitate".
> 
> IMO, current situation is not bottom-up discussion and rather it looks like a 
> voting
> for the agenda which were provided by somebody.
> 
> So, please express your opinion and have productive discussion before asking 
> consensus
> in Auckland and future meetings.
> 
> Thank you for your understanding.
> 
> Regards,
> Masato Yamanishi
> APNIC Policy SIG Chair
> 
> 
> 
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Prop-115 returned to author for further consideration

[Masato Yamanishi]

Skeeve,


2015-09-13 1:03 GMT+09:00 Skeeve Stevens :

> Masato-san,
>
> With the greatest respect for Tomohiro-san and Ruri-san and yourself, I am
> very disappointed with your decision to return prop-115 to the list AGAIN
> for discussion and for a survey.
>

It is up to you being disappointed with me as I'm serving for the whole
community, not only for you,
but please make your comments before the decision. It is second time,
Fukuoka then Jakarta,
that you have suddenly asked a change after the decision.
Also, please make your comments based on correct understanding. (see below)



> You asked for consensus on a Survey and asked who was FOR it - no one (I
> can see)... who was AGAINST - no one (I can see).  Your response was "since
> there is no objection to have such survey" - BUT there was no support
> either!
>

If you have checked the video more carefully, you would find there are a
couple of supports for the survey
and no against. (see 57:00-58:30 on youtube)



> You've chose to spend money and time of APNICs on something that no one
> cares about - at all.
>

I have confirmed to EC and the Secretariat that the survey can be done with
very small cost by using MyAPNIC.
I eager to discuss this point in AMM, but couldn't from time constraint.


You say below that the proposal did not reach consensus. NO ONE supporting
> it - apart from the authors is the definition of consensus - which is that
> it is *not* supported. It is also now at its third version and there is
> STILL no support. (for history see
> https://www.apnic.net/policy/proposals/prop-115)
>

While there is very few support (but not NO support) for this proposal as
it is on the list and from the floor,
there are some supports and no against when I asked only about "assignment
size" part.
It is one of reasons why I pushed it back to the list for further
discussion.



> It had no support even in Japan at APNIC 39 - does this not say something
> that a policy in the home country does not even get up?
>

Again, if you have checked the video more carefully, you would find there
was some strong supports
and one of them was actually non-japanese participants.


Masato, why are you keeping this proposal alive? to the point of spending
> money and resources on it.  This is starting to smell like you are looking
> out for a fellow countryman or APNIC wants it to happen.  I would hope as
> Chair this would not be the case, but all indications point to it as you
> will not let it die based on the overwhelming lack of support the proposal
> has.
>

Of course, I'm not such person. Another reason why I pushed it back to the
list is I was not sure whether the community has discussed it enough while
it is pretty new concept.

BTW, Tomohiro is working for NTT which is biggest competitor for my current
company.
So, why I didn't abandon his proposal as soon as possible if I were such
person?

Regards,
Masato Yamanishi
APNIC SIG Chair



> I have nothing against this policy as such... I just think that it is an
> overhead that the ISPs rather than APNIC needs to do.  I am not against
> it... or for it.  But I am against you trying to push along a policy on
> life-support until people get so bored someone supports it into existence.
>
> Community... if you support this proposal... then SHOW you do... here...
> now.  If you do NOT support it, then please (again) also state that you do
> not - before money is spent on it.
>
>
> ...Skeeve
>
> *Skeeve Stevens - Senior IP Broker*
> *v4Now - *an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/v4now ;  <http://twitter.com/networkceoau>
> linkedin.com/in/skeeve
>
> twitter.com/theispguy ; blog: www.theispguy.com ; Keybase:
> https://keybase.io/skeeve
>
>
> IP Address Brokering - Introducing sellers and buyers
>
> On Sun, Sep 13, 2015 at 1:15 AM, Masato Yamanishi 
> wrote:
>
>> Dear colleagues
>>
>> Version 3 of prop-115: Registration of detailed assignment information
>> in whois DB, did not reach consensus at the APNIC 40 Open
>> Policy Meeting.
>>
>> The Policy SIG Chair requested the Secretariat conduct further research
>> into the problem statement and returned the proposal to the authors for
>> further consideration.
>>
>> Proposal details
>> 
>>
>> This proposal seeks to require LIRs to register accurate filtering
>> information, such as IPv4 port-range information and IPv6 assignment
>> prefix size.
>>
>> Proposal details, including the full text of the proposal, history, and
>&g

[sig-policy] The status of APNIC's IPv4 resources

[Masato Yamanishi]

Dear Colleagues,

In Jakarta, Geoff Huston presented the status of our IPv4 resources, in
particular about exhaustion and transfer,
and some participants asked to summarize and post it to the list for
further discussion.

Following is Chairs' summary of the presentation and discussion.

1. Status of APNIC Final /8 pool (103/8)
   - Will run out ~4-5 years

2. Status of IANA Recovered pool (non-103)
   - Will run out in next 7 months+
   - IANA may allocate additional space in every 6 months
   - This pool will repeatedly ‘run-out’ as IANA delegates more space and
it is distributed by APNIC
   - May need policy to deal with temporary exhaustion of the non-103 pool
 -> Close the door when exhausted or create the waiting list and put
further applications to there?

3. Some address spaces in 103/8 were transferred within 12months since
initial allocation
   - There is no policy to prohibit it while the Secretariat asks in review
process

While 3rd point was not included in SIG Chair report presented in AMM as
the time was very limited,
I would like to ask you consider this point also.

It is very appreciated if you make a comment and discuss further.

Regards,
Masato Yamanishi
APNIC SIG Chair
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Discussion before vs after asking consensus

[Masato Yamanishi]

Dear Colleagues,

While now I'm seeing a lot of comments on the list and it is good thing,
let me ask you to state these comments before asking consensus in OPM.

While I have announced three proposal discussed in Jakarta, only two
comments
(one opposition for prop-104 and one support for prop-105) were made on the
list.
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/08/
Even in the meeting, the discussion was not so active compared to previous
meetings.

Without enough comments and discussions before asking consensus, authors
cannot
improve their proposals in timely manner. Also, few discussion makes
difficult for Chairs
to gauging community's opinion. As a result, proposals may need more
meetings to
reach consensus or fail. Certainly, "no interest" is one of possible
opinions,
but it is not easy to distinguish them from "not yet been interested" or
"just hesitate".

IMO, current situation is not bottom-up discussion and rather it looks like
a voting
for the agenda which were provided by somebody.

So, please express your opinion and have productive discussion before
asking consensus
in Auckland and future meetings.

Thank you for your understanding.

Regards,
Masato Yamanishi
APNIC Policy SIG Chair
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Final Comment Period for prop-114: Modification in the ASN eligibility criteria

[Masato Yamanishi]

Dear colleagues

Version 3 of prop-114: Modification in the ASN eligibility criteria,
reached consensus at the APNIC 40 Open Policy Meeting and later at the
APNIC Member Meeting (AMM).

This proposal will now move to the next step in the APNIC Policy
Development Process and is being returned to the Policy SIG mailing list
for the final Comment Period.

At the end of this period the Policy SIG Chairs will evaluate comments
made and determine if the consensus reached at APNIC 40 still holds. The
Chairs may extend the Comment Period to a maximum of eight (8) weeks to
allow further discussion.

If consensus holds, the Chair of the Policy SIG will ask the Executive
Council to endorse the proposal for implementation.

   - Send all comments and questions to: 
   - Deadline for comments:  23:59 (UTC +10) Sunday, 11 October 2015



Proposal details


This is a proposal changes the criteria for AS number requests from
end-user organizations considering multihoming.

Proposal details, including the full text of the proposal, history, and
links to the APNIC 40 meeting archive, are available at:

 http://www.apnic.net/policy/proposals/prop-114

Regards

Masato and Sumon

---

prop-114-v003: Modification in the ASN eligibility criteria

---

Proposer:  Aftab Siddiqui
   aftab.siddi...@gmail.com

   Skeeve Stevens
   ske...@eintellegonetworks.com


1. Problem statement


   The current ASN assignment policy states two eligibility criteria and
   that both criteria should be fulfilled in order to obtain an ASN. The
   policy seems to imply that both requirements i.e. multi-homing and
   clearly defined single routing policy must be met simultaneously,
   this has created much confusion in interpreting the policy.

   As a result organizations have either provided incorrect information
   to get the ASN or barred themselves from applying where they still
   have a valid justification for obtaining an ASN.


2. Objective of policy change
-

   In order to make the policy guidelines simpler we are proposing to
   modify the text describing the eligibility criteria for ASN
   assignment by providing alternate criteria to obtaining an ASN.


3. Situation in other regions
-

ARIN:
It is not mandatory but optional to be multi-homed in order get ASN

RIPE:
Policy to remove multi-homing requirement is currently in discussion
and the current phase ends 12 February 2015 (awaiting Chair decision)
Policy - https://www.ripe.net/ripe/policies/proposals/2014-03

LACNIC:
Only inter-connect is mandatory not multi-homing

AFRINIC:
It is mandatory to be multi-homed in order to get ASN.


4. Proposed policy solution
---

An organisation is eligible for an ASN assignment if:

- they are currently multi-homed, OR

- have previous allocated provider independent address space by
  APNIC, AND intend to multi-home in the future


5. Advantages / Disadvantages
-

Advantages:

By adding the additional criteria of Guidelines managed by APNIC
Secretariat, this would enable the Secretariat to make decisions
based on common or rare use cases, but that may still be a valid
request.

Disadvantages:

It may be perceived that this policy would enable members to obtain
ASN’s more easily, and in return cause faster consumption of ASN’s
in the region.  Given the relative ease of obtaining an ASN with
‘work around’ methods, we do not perceive this will actually have
any effect.


6. Impact on resource holders
-

No impact on existing resource holders.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Final Comment Period for prop-113: Modification in the IPv4 eligibility criteria

[Masato Yamanishi]

Dear colleagues

Version 3 of prop-113: Modification in the IPv4 eligibility criteria,
reached consensus at the APNIC 40 Open Policy Meeting and later at the
APNIC Member Meeting (AMM).

This proposal will now move to the next step in the APNIC Policy
Development Process and is being returned to the Policy SIG mailing list
for the final Comment Period.

At the end of this period the Policy SIG Chairs will evaluate comments
made and determine if the consensus reached at APNIC 40 still holds. The
Chairs may extend the Comment Period to a maximum of eight (8) weeks to
allow further discussion.

If consensus holds, the Chair of the Policy SIG will ask the Executive
Council to endorse the proposal for implementation.

   - Send all comments and questions to: 
   - Deadline for comments:  23:59 (UTC +10) Sunday, 11 October 2015



Proposal details


This is a proposal changes the criteria for IPv4 address requests from
end-user organizations considering multihoming.

Proposal details, including the full text of the proposal, history, and
links to the APNIC 40 meeting archive, are available at:

 http://www.apnic.net/policy/proposals/prop-113

Regards

Masato and Sumon




prop-113-v003: Modification in the IPv4 eligibility criteria



Proposer:  Aftab Siddiqui
   aftab.siddi...@gmail.com

   Skeeve Stevens
   ske...@eintellegonetworks.com


1. Problem statement


The current APNIC IPv4 delegation policy defines multiple
eligibility criteria and applicants must meet one criteria to be
eligible to receive IPv4 resources. One of the criteria dictates
that “an organization is eligible if it is currently multi-homed
with provider-based addresses, or demonstrates a plan to multi-home
within one month” (section 3.3).

The policy seems to imply that multi-homing is mandatory even if
there is no use case for the applicant to be multi-homed or even
when there is only one upstream provider available, this has created
much confusion in interpreting this policy.

As a result organizations have either tempted to provide incorrect
or fabricated multi-homing information to get the IPv4 resources or
barred themselves from applying.


2. Objective of policy change
-

In order to make the policy guidelines simpler we are proposing to
modify the text of section 3.3.


3. Situation in other regions
-

ARIN:
There is no multi-homing requirement

RIPE:
There is no multi-homing requirement.

LACNIC:
Applicant can either have multi-homing requirement or interconnect.

AFRINIC:
There is no multi-homing requirement.


4. Proposed policy solution
---

Section 3.3: Criteria for small delegations

An organization is eligible if:

- it is currently multi-homed, OR

- currently utilising provider (ISP) assignment of at least a /24,
  AND intends to be multi-homed, OR

- intends to be multi-homed, AND advertise the prefixes within
  6 months

Organizations requesting a delegation under these terms must
demonstrate that they are able to use 25% of the requested addresses
immediately and 50% within one year.


5. Advantages / Disadvantages
-

Advantages:

Simplifies the process of applying for IPv4 address space for small
delegations and delays the immediate requirement for multi-homing as
determined to be appropriate within the timeframe as detailed in
Section 3.3.


Disadvantages:

There is no known disadvantage of this proposal.


6. Impact on resource holders
-

No impact on existing resource holders.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Prop-115 returned to author for further consideration

[Masato Yamanishi]

Dear colleagues

Version 3 of prop-115: Registration of detailed assignment information
in whois DB, did not reach consensus at the APNIC 40 Open
Policy Meeting.

The Policy SIG Chair requested the Secretariat conduct further research
into the problem statement and returned the proposal to the authors for
further consideration.

Proposal details


This proposal seeks to require LIRs to register accurate filtering
information, such as IPv4 port-range information and IPv6 assignment
prefix size.

Proposal details, including the full text of the proposal, history, and
links to the APNIC 40 meeting archive, are available at:

 http://www.apnic.net/policy/proposals/prop-115

Regards

Masato and Sumon




prop-115-v003: Registration of detailed assignment information in
   whois DB


Proposer:   Ruri Hiromi
hir...@inetcore.com

Tomohiro Fujisaki
fujis...@syce.net


1. Problem statement


Recently, there are some cases need to get IP address assignment
information in more detail to specify user IP address.

Without this information, operators cannot filter out specific
address range, and it might lead to 'over-filter' (i.e. filtering
whole ISP's address range).

For example:

1) 'Port' range information in IPv4

   ISPs are using 'CGN' or other kinds of IPv4 address sharing
   technology with assignment of IP address and specified port
   range to their users.

   In this case, port information is necessary to specify one user.

   ex) 192.0.2.24/32 1-256 is for HomeA
   192.0.2.24/32 257-511 is for HomeB

   or 192.0.2.0/24 1-65536 is shared address of ISP-X
   minimum size is /32

2) address assignment size information in IPv6

   The IPv6 address assignment size may be different from ISP and
   its service estimation. Address assignment prefix size will be
   necessary.

   ex) 2001:db8:1::0/56 is for HomeA
   2001:db8:1:1::0/48 is for HomeB

   or 2001:db8:1::/36's minimum size is /56


2. Objective of policy change
-

Lots of operators look a record when harmful behavior coming to
their network to identify its IP address confirming it can be
filtered or not.

The goal is providing more specific information to support these
actions.


3. Situation in other regions
-

No same regulation/discussion can be seen in other regions.


4. Proposed policy solution
---

Provide accurate filtering information generated from whois DB.

For IPv4, propose to add 'port range' information to IP address
entry.

For IPv6, propose to provide 'assignment prefix size' information
for specific IPv6 address.


5. Advantages / Disadvantages
-

Advantages:

 - operators can set filtering by IP address based on correct assignment
   information base.

 - users who share same address space can be avoid to be including bulk
   filtering.

Disadvantages:

 - registration rule will move to more strict manner.

 - strict watch and control in registration of database records.

 - additional record or option will be considered.

 - privilege for withdrawing detailed information will be set for these
   records.


6. Impact on APNIC
--

This might be beyond the scope of using whois DB and appropriate
changes in policy document or guidance to whois DB will be needed.

Some kind of modification cost in whois DB might be needed to set
access privilege to the detailed information.

Some kind of modification cost in whois DB might be needed in
Help message/Warning/Alert when whois DB has non-privileged access.

Some kind of promotion cost might be needed in announcing.

Need cooperation and support from members(ISPs).

7. Other Consideration
--

For the security reason, this detailed records may be able to see
only by operators.(some kind of user control/privilege setting is
needed)

For hosting services, /32 in IPv4 and /128 in IPv6 registration
should be discussed based on its operability and possibility. But a
harmful activities to filter by IP addresses are coming from hosting
services as well. Here it seemed to be some demands.

Some ISP use IRR DB to notice their filter policy towards BGP
community with "remarks" filed in aut-num record. Need more
discussion among APNIC members on using whois DB versus IRR DB.

Start a pilot project for research its demands and effectiveness
in APNIC region. APNIC is a worthy body to lead this pilot project.

There are some opinions that it is not suitable to handle those
issues at the Internet Registrie

Re: [sig-policy] Agenda at Jakarta meeting

[Masato Yamanishi]

Dear SIG members,

> In addition, we have three informal presentations.
>
> - IPv4 transfer analysis by Geoff Huston
> - Change of address - when transfers go wrong by Jim Cowie
> - IP addressing and IoT/M2M services by Tomohiro Fujisaki

Tomohiro kindly shared his preliminary presentation also, you can refer it
from
<<https://conference.apnic.net/data/40/IoT_addressing.pptx>>
He will show several points which should be considered in addressing for
IoT/M2M.
It is very appreciated if you review it and post your comments to the list
even before the meeting.

Regards,
Masato


2015-08-21 18:35 GMT+09:00 Masato Yamanishi :

> Dear SIG members,
>
> We have posted the agenda at Jakarta meeting on the conference web site.
> <<https://conference.apnic.net/40/program#agenda/day8>>
>
> As you can see, we will discuss and ask consensus for following three
> official proposals.
>
> - prop-113: Modification in the IPv4 eligibility criteria
> - prop-114: Modification in the ASN eligibility criteria
> - prop-115: Registration of detailed assignment information in Whois DB
>
> In addition, we have three informal presentations.
>
> - IPv4 transfer analysis by Geoff Huston
> - Change of address - when transfers go wrong by Jim Cowie
> - IP addressing and IoT/M2M services
>
> All of them are useful inputs to consider future policy, in particular
> Geoff's one will show
> current usage and trends of our last /8 and predict it might be run out in
> mid term (2-5 years).
> 2-5 years is not extremely long for major policy discussion as we have
> experienced in transfer,
> now is good chance to begin considering about post exhaustion, I believe.
> You can find his presentation at
> https://www.evernote.com/l/AGArXQblYYlHPo_NNAB624ati3lDttvq8Is
> It is very appreciated if you review it and post your comments to the list
> even before the meeting.
>
> Lastly, we have two more community consultations from the Secretariat.
> - Consultation on Policy Documentation
> - Whois update from the Secretariat
>
> That is all I have currently and I hope to see you in Jakarta.
>
> Regards,
> Masato Yamanishi
> Policy SIG Chair
>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Agenda at Jakarta meeting

[Masato Yamanishi]

Dear SIG members,

> - prop-113: Modification in the IPv4 eligibility criteria
> - prop-114: Modification in the ASN eligibility criteria
> - prop-115: Registration of detailed assignment information in Whois DB

You can find proposals under discussion on
<<https://www.apnic.net/community/policy/proposals>>

Regards,
Masato Yamanishi
Policy SIG Chair



2015-08-21 18:35 GMT+09:00 Masato Yamanishi :

> Dear SIG members,
>
> We have posted the agenda at Jakarta meeting on the conference web site.
> <<https://conference.apnic.net/40/program#agenda/day8>>
>
> As you can see, we will discuss and ask consensus for following three
> official proposals.
>
> - prop-113: Modification in the IPv4 eligibility criteria
> - prop-114: Modification in the ASN eligibility criteria
> - prop-115: Registration of detailed assignment information in Whois DB
>
> In addition, we have three informal presentations.
>
> - IPv4 transfer analysis by Geoff Huston
> - Change of address - when transfers go wrong by Jim Cowie
> - IP addressing and IoT/M2M services
>
> All of them are useful inputs to consider future policy, in particular
> Geoff's one will show
> current usage and trends of our last /8 and predict it might be run out in
> mid term (2-5 years).
> 2-5 years is not extremely long for major policy discussion as we have
> experienced in transfer,
> now is good chance to begin considering about post exhaustion, I believe.
> You can find his presentation at
> https://www.evernote.com/l/AGArXQblYYlHPo_NNAB624ati3lDttvq8Is
> It is very appreciated if you review it and post your comments to the list
> even before the meeting.
>
> Lastly, we have two more community consultations from the Secretariat.
> - Consultation on Policy Documentation
> - Whois update from the Secretariat
>
> That is all I have currently and I hope to see you in Jakarta.
>
> Regards,
> Masato Yamanishi
> Policy SIG Chair
>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Agenda at Jakarta meeting

[Masato Yamanishi]

Dear SIG members,

We have posted the agenda at Jakarta meeting on the conference web site.
<<https://conference.apnic.net/40/program#agenda/day8>>

As you can see, we will discuss and ask consensus for following three
official proposals.

- prop-113: Modification in the IPv4 eligibility criteria
- prop-114: Modification in the ASN eligibility criteria
- prop-115: Registration of detailed assignment information in Whois DB

In addition, we have three informal presentations.

- IPv4 transfer analysis by Geoff Huston
- Change of address - when transfers go wrong by Jim Cowie
- IP addressing and IoT/M2M services

All of them are useful inputs to consider future policy, in particular
Geoff's one will show
current usage and trends of our last /8 and predict it might be run out in
mid term (2-5 years).
2-5 years is not extremely long for major policy discussion as we have
experienced in transfer,
now is good chance to begin considering about post exhaustion, I believe.
You can find his presentation at
https://www.evernote.com/l/AGArXQblYYlHPo_NNAB624ati3lDttvq8Is
It is very appreciated if you review it and post your comments to the list
even before the meeting.

Lastly, we have two more community consultations from the Secretariat.
- Consultation on Policy Documentation
- Whois update from the Secretariat

That is all I have currently and I hope to see you in Jakarta.

Regards,
Masato Yamanishi
Policy SIG Chair
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] prop-114: Modification in the ASN eligibility criteria to be discussed at APNIC 40

[Masato Yamanishi]

Dear SIG members

## It is NOT new version, just a reminder that this proposal will be
discussed at APNIC 40

Version 3 of this proposal was posted to the mailing list during
APNIC 39. The proposal did not reach consensus and discussion will
continue at APNIC 40.


Information about earlier versions is available from:

https://www.apnic.net/policy/proposals/prop-114

You are encouraged to express your views on the proposal:

 - Do you support or oppose the proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Masato



---

prop-114-v003: Modification in the ASN eligibility criteria

---

Proposer:  Aftab Siddiqui
   aftab.siddi...@gmail.com

   Skeeve Stevens
   ske...@eintellegonetworks.com


1. Problem statement


   The current ASN assignment policy states two eligibility criteria and
   that both criteria should be fulfilled in order to obtain an ASN. The
   policy seems to imply that both requirements i.e. multi-homing and
   clearly defined single routing policy must be met simultaneously,
   this has created much confusion in interpreting the policy.

   As a result organizations have either provided incorrect information
   to get the ASN or barred themselves from applying where they still
   have a valid justification for obtaining an ASN.


2. Objective of policy change
-

   In order to make the policy guidelines simpler we are proposing to
   modify the text describing the eligibility criteria for ASN
   assignment by providing alternate criteria to obtaining an ASN.


3. Situation in other regions
-

ARIN:
It is not mandatory but optional to be multi-homed in order get ASN

RIPE:
Policy to remove multi-homing requirement is currently in discussion
and the current phase ends 12 February 2015 (awaiting Chair decision)
Policy - https://www.ripe.net/ripe/policies/proposals/2014-03

LACNIC:
Only inter-connect is mandatory not multi-homing

AFRINIC:
It is mandatory to be multi-homed in order to get ASN.


4. Proposed policy solution
---

An organisation is eligible for an ASN assignment if:

- they are currently multi-homed, OR

- have previous allocated provider independent address space by
  APNIC, AND intend to multi-home in the future


5. Advantages / Disadvantages
-

Advantages:

By adding the additional criteria of Guidelines managed by APNIC
Secretariat, this would enable the Secretariat to make decisions
based on common or rare use cases, but that may still be a valid
request.

Disadvantages:

It may be perceived that this policy would enable members to obtain
ASN¹s more easily, and in return cause faster consumption of ASN¹s
in the region.  Given the relative ease of obtaining an ASN with
Œwork around¹ methods, we do not perceive this will actually have
any effect.


6. Impact on resource holders
-

No impact on existing resource holders.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] prop-113: Modification in the IPv4 eligibility criteria to be discussed at APNIC 40

[Masato Yamanishi]

Dear SIG members

## It is NOT new version, just a reminder that this proposal will be
discussed at APNIC 40

Version 3 of prop-113 was posted to the mailing list after Version 2 had
failed
to reach consensus at APNIC 39. It will be considered for consensus at
APNIC 40.


Information about earlier versions is available from:

https://www.apnic.net/policy/proposals/prop-113

You are encouraged to express your views on the proposal:

- Do you support or oppose the proposal?
- Is there anything in the proposal that is not clear?
- What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Masato







prop-113-v003: Modification in the IPv4 eligibility criteria



Proposer:  Aftab Siddiqui
   aftab.siddi...@gmail.com

   Skeeve Stevens
   ske...@eintellegonetworks.com


1. Problem statement


The current APNIC IPv4 delegation policy defines multiple
eligibility criteria and applicants must meet one criteria to be
eligible to receive IPv4 resources. One of the criteria dictates
that ³an organization is eligible if it is currently multi-homed
with provider-based addresses, or demonstrates a plan to multi-home
within one month² (section 3.3).

The policy seems to imply that multi-homing is mandatory even if
there is no use case for the applicant to be multi-homed or even
when there is only one upstream provider available, this has created
much confusion in interpreting this policy.

As a result organizations have either tempted to provide incorrect
or fabricated multi-homing information to get the IPv4 resources or
barred themselves from applying.


2. Objective of policy change
-

In order to make the policy guidelines simpler we are proposing to
modify the text of section 3.3.


3. Situation in other regions
-

ARIN:
There is no multi-homing requirement

RIPE:
There is no multi-homing requirement.

LACNIC:
Applicant can either have multi-homing requirement or interconnect.

AFRINIC:
There is no multi-homing requirement.


4. Proposed policy solution
---

Section 3.3: Criteria for small delegations

An organization is eligible if:

- it is currently multi-homed, OR

- currently utilising provider (ISP) assignment of at least a /24,
  AND intends to be multi-homed, OR

- intends to be multi-homed, AND advertise the prefixes within
  6 months

Organizations requesting a delegation under these terms must
demonstrate that they are able to use 25% of the requested addresses
immediately and 50% within one year.


5. Advantages / Disadvantages
-

Advantages:

Simplifies the process of applying for IPv4 address space for small
delegations and delays the immediate requirement for multi-homing as
determined to be appropriate within the timeframe as detailed in
Section 3.3.


Disadvantages:

There is no known disadvantage of this proposal.


6. Impact on resource holders
-

No impact on existing resource holders.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] New version of prop-115: Registration of detailed assignment information in whois DB

[Masato Yamanishi]

Dear SIG members

A new version of the proposal "prop-115: Registration of detailed
assignment information in whois DB" has been sent to the Policy SIG for
review.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-115

You are encouraged to express your views on the proposal:

 - Do you support or oppose the proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Masato




prop-115-v003: Registration of detailed assignment information in
whois DB


Proposer:   Ruri Hiromi
hir...@inetcore.com

Tomohiro Fujisaki
fujis...@syce.net


1. Problem statement


Recently, there are some cases need to get IP address assignment
information in more detail to specify user IP address.

Without this information, operators cannot filter out specific
address range, and it might lead to 'over-filter' (i.e. filtering
whole ISP's address range).

For example:

1) 'Port' range information in IPv4

   ISPs are using 'CGN' or other kinds of IPv4 address sharing
   technology with assignment of IP address and specified port
   range to their users.

   In this case, port information is necessary to specify one user.

   ex) 192.0.2.24/32 1-256 is for HomeA
   192.0.2.24/32 257-511 is for HomeB

   or 192.0.2.0/24 1-65536 is shared address of ISP-X
   minimum size is /32

2) address assignment size information in IPv6

   The IPv6 address assignment size may be different from ISP and
   its service estimation. Address assignment prefix size will be
   necessary.

   ex) 2001:db8:1::0/56 is for HomeA
   2001:db8:1:1::0/48 is for HomeB

   or 2001:db8:1::/36's minimum size is /56


2. Objective of policy change
-

Lots of operators look a record when harmful behavior coming to
their network to identify its IP address confirming it can be
filtered or not.

The goal is providing more specific information to support these
actions.


3. Situation in other regions
-

No same regulation/discussion can be seen in other regions.


4. Proposed policy solution
---

Provide accurate filtering information generated from whois DB.

For IPv4, propose to add 'port range' information to IP address
entry.

For IPv6, propose to provide 'assignment prefix size' information
for specific IPv6 address.


5. Advantages / Disadvantages
-

Advantages:

 - operators can set filtering by IP address based on correct assignment
   information base.

 - users who share same address space can be avoid to be including bulk
   filtering.

Disadvantages:

 - registration rule will move to more strict manner.

 - strict watch and control in registration of database records.

 - additional record or option will be considered.

 - privilege for withdrawing detailed information will be set for these
   records.


6. Impact on APNIC
--

This might be beyond the scope of using whois DB and appropriate
changes in policy document or guidance to whois DB will be needed.

Some kind of modification cost in whois DB might be needed to set
access privilege to the detailed information.

Some kind of modification cost in whois DB might be needed in
Help message/Warning/Alert when whois DB has non-privileged access.

Some kind of promotion cost might be needed in announcing.

Need cooperation and support from members(ISPs).

7. Other Consideration
--

For the security reason, this detailed records may be able to see
only by operators.(some kind of user control/privilege setting is
needed)

For hosting services, /32 in IPv4 and /128 in IPv6 registration
should be discussed based on its operability and possibility. But a
harmful activities to filter by IP addresses are coming from hosting
services as well. Here it seemed to be some demands.

Some ISP use IRR DB to notice their filter policy towards BGP
community with "remarks" filed in aut-num record. Need more
discussion among APNIC members on using whois DB versus IRR DB.

Start a pilot project for research its demands and effectiveness
in APNIC region. APNIC is a worthy body to lead this pilot project.

There are some opinions that it is not suitable to handle those
issues at the Internet Registries (IRs), but we think it should be
registered in the IRs database since that is part of assignment
information.

References
--

TBD
*  sig-policy

[sig-policy] Reminder: Policy Proposal Deadline is Friday, 31 July 2015

[Masato Yamanishi]

Dear Colleagues,

This is a final reminder to submit Policy Proposals for APNIC 40 OPM in
Jakarta, Indonesia. The deadline for submissions is:

Friday, 31 July 2015.

Only proposals submitted by this date will be considered for consensus
at the Jakarta Policy SIG meeting

Please note that this date is just over two weeks away.

Regards,

Masato
APNIC Policy SIG Chair


How to submit your Policy Proposal
-

There are two ways to submit a policy proposal:

1. Use the online form at:
   http://www.apnic.net/community/policy/proposals/submit

2. Send your proposal in TEXT format to .
   http://www.apnic.net/community/policy/process/proposal_template.txt

If you have identified an issue, but do not know the solution, you are
able to complete the Problem Statement part of the proposal submission
form and ask the community to help develop the best solution.


More information
-

Learn more about the APNIC 40 OPM:

http://conference.apnic.net/40/policy

Guideline for proposal authors

https://www.apnic.net/community/policy/guidelines/authors

APNIC's PDP is explained at:

http://www.apnic.net/community/policy/process

View current and past policy proposals at:

http://www.apnic.net/policy/proposals

I look forward to and encourage your participation in the APNIC PDP.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Call for APNIC Policy Proposals

[Masato Yamanishi]

Dear Colleagues,

APNIC policies are decided by community members and implemented by the
APNIC staff.

The Policy Development Process (PDP) is a way for anybody to propose a
policy change and participate in the decisions.

This begins when somebody submits a Policy Proposal to the APNIC Policy
SIG before the deadline set by the Chair.

For proposals to be discussed at APNIC 40 in Jakarta, Indonesia, the
deadline is Friday, 31 July 2015.

If you have an idea to improve APNIC IP address and ASN policy, please
follow the instructions below to submit your proposal before the
deadline.


How to submit your Policy Proposal
-

There are two ways to submit a policy proposal:

1. Use the online form at:
   http://www.apnic.net/community/policy/proposals/submit

2. Send your proposal in TEXT format to .
   http://www.apnic.net/community/policy/process/proposal_template.txt

If you have identified an issue, but do not know the solution, you are
able to complete the Problem Statement part of the proposal submission
form and ask the community to help develop the best solution.


More information
-

Learn more about the APNIC 40 OPM:

http://conference.apnic.net/40/policy

Guideline for proposal authors

  https://www.apnic.net/community/policy/guidelines/authors

APNIC's PDP is explained at:

http://www.apnic.net/community/policy/process

View current and past policy proposals at:

http://www.apnic.net/policy/proposals


I look forward to and encourage your participation in the APNIC PDP.


Kind regards

Masato
APNIC Policy SIG Chair
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Workshop on Internet of Things for Ambient Assisted Living - IEEE GLOBECOM 2015, San Diego, CA, USA, Dec 6 - 10, 2015

[Masato Yamanishi]

Dear colleagues,

I'm doubt this post fits in the charter of APNIC Policy SIG and following how 
it is posted.

Masato Yamanishi
Policy SIG Chair

2015/05/05 22:12、"iotaal...@gmail.com"  のメッセージ:

> CALL FOR PAPERS (apologies for multiple copies)
> 
> IEEE International Workshop on Internet of Things for Ambient Assisted Living 
> (IoTAAL)
> In conjunction with IEEE GLOBECOM 2015, San Diego, CA, USA, Dec 6 - 10, 2015.
>   
> http://www.tlc.dii.univpm.it/iotaal/
>  
> MOTIVATION AND SCOPE 
> Ambient Assisted Living (AAL) encompasses technical systems, infrastructures, 
> and services to support elderly people in their daily routine, to allow an 
> independent and safe lifestyle, as long as possible, via the seamless 
> integration of information and communication technologies within homes and 
> residences. Effective AAL solutions require appropriate ICT algorithms, 
> architectures and platforms, that cannot leave out of consideration the 
> development of new and innovative approaches, particularly in the area of 
> pervasive and mobile systems. The Internet of Things (IoT) paradigm is 
> leading to smart objects being capable of identifying, locating, sensing and 
> connecting, and thus opening possibilities for new forms of communication 
> between people and things, and things themselves. This workshop aims to 
> investigate the potential benefits gained when specializing the IoT for AAL, 
> to avoid redundancy and leverage the harmonization of the technological 
> approaches towards an increased Quality of Life for the current and future 
> ageing populations.
>  
> TOPICS OF INTEREST
> The focus of this workshop is on proposals of architectures, methods, 
> techniques, protocols, components and tools addressing the IoT paradigm to 
> support the Ambient Assisted Living requirements. These may include, but are 
> not limited to, the following topics:
> - IoT communications for AAL and Enhanced Living Environments
> - Mobile solutions for AAL
> - IoT enabled signal acquisition, analysis, and processing for activity 
> identification and recognition in AAL
> - Smart Ad Hoc Networks and Wireless Sensor Networks (WSNs) for AAL
> - Distributed sensing and alarming technologies for AAL
> - IoT devices (smart objects) and cyber-physical systems for AAL
> - E-healthcare, telemedicine and tele-monitoring through IoT in AAL systems
> - AAL networks and systems architectures
> - Green networking in IoT for AAL
> - Security, privacy, and trustworthiness management in IoT for AAL
> - Information processing for AAL communications
> - Interoperability among IoT and AAL platforms
> - Cloud and Mobile Cloud for AAL
> - Algorithms and techniques for IoT enabled AAL data analytics
> - Big data management in AAL
> - IoT applications, systems, and testbeds for AAL
> - Standardization activities of IoT for AAL
> - Future directions in IoT for AAL
> 
> IMPORTANT DATES
> Paper submission deadline: July 1, 2015 (strict)
> Acceptance/rejection announcement: September 1, 2015
> Final workshop papers due: October 1, 2015
>  
> SUBMISSION OF PAPERS
> All final submissions should be written in English with a maximum paper 
> length of six (6) printed pages (10-point font) including figures without 
> incurring additional page charges (maximum 1 additional page with over length 
> page charge of USD100 if accepted). Papers exceeding 7 pages will not be 
> accepted at EDAS. You may also use one of the following templates for 
> Microsoft Word: A4, US letter. Only PDF files will be accepted for the review 
> process, and all submissions must be done through EDAS (link TBA).
> Standard IEEE conference templates for LaTeX formats are found at here:
> http://www.ieee.org/conferences_events/conferences/publishing/templates.html
> If you have any questions regarding the submission of manuscripts, please 
> contact the Workshop Program Chairs.
> Important IEEE Policy Announcement: The IEEE reserves the right to exclude a 
> paper from distribution after the conference (including its removal from IEEE 
> Explore) if the paper is not presented at the conference.
> Plagiarism policy: Papers should not contain plagiarized material and have 
> not been submitted to any other conference/workshop at the same time (double 
> submission). These matters are taken very seriously and the IEEE 
> Communications society will take action against any author who engages in 
> either practice. Follow the link to learn more:
> http://www.ieee.org/publications_standards/publications/rights/Multi_Sub_Guidelines_Intro.html
>  
> ORGANIZING COMMITTEE
> Workshop co-chairs:
> - Susanna Spinsante (Università Politecnica delle Marche – ITALY)
> - Joel Rodrigues (Instituto de Telecomunicacoes, University of Bei

[sig-policy] prop-115 returned to mailing list

[Masato Yamanishi]

Dear colleagues

Version 2 of prop-115: "Registration of detailed assignment information
in whois DB", did not reach consensus at the APNIC 39 Policy SIG and
was returned to the mailing list for further discussion.

Problem Statement:
--

Use of IPv4 address sharing technologies and IPv6, make it difficult
to filter out a specific address range. This leads operators to
'over-filter' (i.e. filtering whole ISP's address range).


Proposal details, including the full text of the proposal, history, and
links to previous versions are available at:

http://www.apnic.net/policy/proposals/prop-115

Regards

Masato
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] prop-114 returned to mailing list

[Masato Yamanishi]

Dear colleagues

Version 3 of prop-114: "Modification in the ASN eligibility criteria",
did not reach consensus at the APNIC 39 Policy SIG and was returned to
the mailing list for further discussion.

Problem Statement:
--

Multi-homing is mandatory for small IPv4 delegations to end-sites
(assignments). Requesters might obtain multi-homing when it is not
required, fabricate multi-homing information in their request, or
not apply for the space they need.


Proposal details, including the full text of the proposal, history, and
links to previous versions are available at:

http://www.apnic.net/policy/proposals/prop-114

Regards

Masato
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] prop-113 returned to mailing list

[Masato Yamanishi]

Dear colleagues

Version 2 of prop-113: "Modification in the IPv4 eligibility criteria",
did not reach consensus at the APNIC 39 Policy SIG and was returned to
the mailing list for further discussion.

Problem Statement:
--

Multi-homing is mandatory for small IPv4 delegations to end-sites
(assignments). Requesters might obtain multi-homing when it is not
required, fabricate multi-homing information in their request, or
not apply for the space they need.


Proposal details, including the full text of the proposal, history, and
links to previous versions are available at:

http://www.apnic.net/policy/proposals/prop-113

Regards

Masato
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] prop-112 abandoned at APNIC 39 Policy SIG

[Masato Yamanishi]

Dear colleagues

Version 1 of prop-112: "On demand expansion of IPv6 address allocation
size in legacy IPv6 space", did not reach consensus at the APNIC 39
Policy SIG and was abandoned.

Problem Statement:
--

IPv6 blocks reserved for subsequent delegations to Legacy holders
prior to the introduction of Sparse Allocation may remain
inaccessible and unused.

Proposal details, including the full text of the proposal, history, and
links to previous versions are available at:

http://www.apnic.net/policy/proposals/prop-112

Regards

Masato
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] New version of prop-114: prop-114: Modification in the ASN eligibility criteria

[Masato Yamanishi]

Dear SIG members

A new version of the proposal “prop-114: prop-114: Modification in the
ASN eligibility criteria" has been sent to the Policy SIG for review.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-114

You are encouraged to express your views on the proposal:

 - Do you support or oppose the proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Masato



--

prop-114-v003: Modification in the ASN eligibility criteria

--

Proposer:  Aftab Siddiqui
 aftab.siddi...@gmail.com

 Skeeve Stevens
 ske...@eintellegonetworks.com


1. Problem statement
-

   The current ASN assignment policy states two eligibility criteria and
   that both criteria should be fulfilled in order to obtain an ASN. The
   policy seems to imply that both requirements i.e. multi-homing and
   clearly defined single routing policy must be met simultaneously,
   this has created much confusion in interpreting the policy.

   As a result organizations have either provided incorrect information
   to get the ASN or barred themselves from applying where they still
   have a valid justification for obtaining an ASN.


2. Objective of policy change
--

   In order to make the policy guidelines simpler we are proposing to
   modify the text describing the eligibility criteria for ASN
   assignment by providing alternate criteria to obtaining an ASN.


3. Situation in other regions
-

ARIN:
It is not mandatory but optional to be multi-homed in order get ASN

RIPE:
Policy to remove multi-homing requirement is currently in discussion
and the current phase ends 12 February 2015 (awaiting Chair decision)
Policy - https://www.ripe.net/ripe/policies/proposals/2014-03

LACNIC:
Only inter-connect is mandatory not multi-homing

AFRINIC:
It is mandatory to be multi-homed in order to get ASN.


4. Proposed policy solution


An organisation is eligible for an ASN assignment if:

- they are currently multi-homed, OR

- have previous allocated provider independent address space by
  APNIC, AND intend to multi-home in the future


5. Advantages / Disadvantages
-

Advantages:

By adding the additional criteria of Guidelines managed by APNIC
Secretariat, this would enable the Secretariat to make decisions
based on common or rare use cases, but that may still be a valid
request.

Disadvantages:

It may be perceived that this policy would enable members to obtain
ASN’s more easily, and in return cause faster consumption of ASN’s
in the region.  Given the relative ease of obtaining an ASN with
‘work around’ methods, we do not perceive this will actually have
any effect.


6. Impact on resource holders


No impact on existing resource holders.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] New version of prop-113: Modification in the IPv4 eligibility criteria

[Masato Yamanishi]

Dear SIG members

A new version of the proposal “prop-113: Modification in the IPv4
eligibility criteria" has been sent to the Policy SIG for review.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-113

You are encouraged to express your views on the proposal:

 - Do you support or oppose the proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Masato




--

prop-113-v003: Modification in the IPv4 eligibility criteria

--

Proposer:  Aftab Siddiqui
 aftab.siddi...@gmail.com

 Skeeve Stevens
 ske...@eintellegonetworks.com


1. Problem statement


The current APNIC IPv4 delegation policy defines multiple
eligibility criteria and applicants must meet one criteria to be
eligible to receive IPv4 resources. One of the criteria dictates
that “an organization is eligible if it is currently multi-homed
with provider-based addresses, or demonstrates a plan to multi-home
within one month” (section 3.3).

The policy seems to imply that multi-homing is mandatory even if
there is no use case for the applicant to be multi-homed or even
when there is only one upstream provider available, this has created
much confusion in interpreting this policy.

As a result organizations have either tempted to provide incorrect
or fabricated multi-homing information to get the IPv4 resources or
barred themselves from applying.


2. Objective of policy change
--

In order to make the policy guidelines simpler we are proposing to
modify the text of section 3.3.


3. Situation in other regions


ARIN:
There is no multi-homing requirement

RIPE:
There is no multi-homing requirement.

LACNIC:
Applicant can either have multi-homing requirement or interconnect.

AFRINIC:
There is no multi-homing requirement.


4. Proposed policy solution


Section 3.3: Criteria for small delegations

An organization is eligible if:

- it is currently multi-homed, OR

- currently utilising provider (ISP) assignment of at least a /24,
  AND intends to be multi-homed, OR

- intends to be multi-homed, AND advertise the prefixes within
  6 months

Organizations requesting a delegation under these terms must
demonstrate that they are able to use 25% of the requested addresses
immediately and 50% within one year.


5. Advantages / Disadvantages
-

Advantages:

Simplifies the process of applying for IPv4 address space for small
delegations and delays the immediate requirement for multi-homing as
determined to be appropriate within the timeframe as detailed in
Section 3.3.


Disadvantages:

There is no known disadvantage of this proposal.


6. Impact on resource holders
---

No impact on existing resource holders.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] New version of prop-113: Modification in the IPv4 eligibility criteria

[Masato Yamanishi]

Dear SIG members

A new version of the proposal “prop-113: Modification in the IPv4
eligibility criteria" has been sent to the Policy SIG for review.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-113

You are encouraged to express your views on the proposal:

 - Do you support or oppose the proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Masato




--
prop-113-v002: Modification in the IPv4 eligibility criteria
-

Proposer:   Aftab Siddiqui
  aftab.siddi...@gmail.com

  Skeeve Stevens
  ske...@eintellegonetworks.com


1. Problem statement
-

The current APNIC IPv4 delegation policy defines multiple
eligibility criteria and applicants must meet one criteria to be
eligible to receive IPv4 resources. One of the criteria dictates
that “an organization is eligible if it is currently multi-homed
with provider-based addresses, or demonstrates a plan to multi-home
within one month” (section 3.3).

The policy seems to imply that multi-homing is mandatory even if
there is no use case for the applicant to be multi-homed or even
when there is only one upstream provider available, this has created
much confusion in interpreting this policy.

As a result organizations have either tempted to provide incorrect
or fabricated multi-homing information to get the IPv4 resources or
barred themselves from applying.


2. Objective of policy change
--

In order to make the policy guidelines simpler we are proposing to
modify the text of section 3.3.


3. Situation in other regions


ARIN:
There is no multi-homing requirement

RIPE:
There is no multi-homing requirement.

LACNIC:
Applicant can either have multi-homing requirement or interconnect.

AFRINIC:
There is no multi-homing requirement.


4. Proposed policy solution


Section 3.3: Criteria for small delegations

An organization is eligible if:

- it is currently multi-homed

OR,

- currently utilising provider (ISP) assignment of at least a /24,

AND

- intends to be multi-homed

OR,

- intends to be multi-homed

AND

- advertise the prefixes within 6 months



5. Advantages / Disadvantages
--

Advantages:

Simplifies the process of applying for IPv4 address space for small
delegations and delays the immediate requirement for multi-homing as
determined to be appropriate within the timeframe as detailed in
Section 3.3.

Disadvantages:

There is no known disadvantage of this proposal.


6. Impact on resource holders
-

No impact on existing resource holders.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] New version of prop-114: Modification in the ASN eligibility criteria

[Masato Yamanishi]

Dear SIG members

A new version of the proposal “prop-114: Modification in the ASN
eligibility criteria" has been sent to the Policy SIG for review.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-114

You are encouraged to express your views on the proposal:

 - Do you support or oppose the proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Masato



--
prop-114-v002: Modification in the ASN eligibility criteria
--

Proposer: Aftab Siddiqui
aftab.siddi...@gmail.com

   Skeeve Stevens
   ske...@eintellegonetworks.com


1. Problem statement
-

The current ASN assignment policy states two eligibility criteria
and that both criteria should be fulfilled in order to obtain an
ASN. The policy seems to imply that both requirements i.e.
multi-homing and clearly defined single routing policy must be met
simultaneously, this has created much confusion in interpreting the
policy.

As a result organizations have either provided incorrect information
to get the ASN or barred themselves from applying where they still
have a valid justification for obtaining an ASN.


2. Objective of policy change
--

In order to make the policy guidelines simpler we are proposing to
modify the text describing the eligibility criteria for ASN
assignment by providing alternate criteria to obtaining an ASN.


3. Situation in other regions


ARIN:
It is not mandatory but optional to be multi-homed in order get ASN

RIPE:
Policy to remove multi-homing requirement is currently in discussion
and the current phase ends 12 February 2015 (awaiting Chair
decision)

Policy - https://www.ripe.net/ripe/policies/proposals/2014-03

LACNIC:
Only inter-connect is mandatory not multi-homing

AFRINIC:
It is mandatory to be multi-homed in order to get ASN.


4. Proposed policy solution
---

An organization is eligible for an ASN assignment if:

 - they are currently multi-homed OR

 - meet one of the other criteria in the guidelines managed by the
   APNIC Secretariat


5. Advantages / Disadvantages
-

Advantages:

By adding the additional criteria of Guidelines managed by APNIC
Secretariat, this would enable the Secretariat to make decisions
based on common or rare use cases, but that may still be a valid
request.

Disadvantages:

It may be perceived that this policy would enable members to obtain
ASN’s more easily, and in return cause faster consumption of ASN’s
in the region.  Given the relative ease of obtaining an ASN with
‘work around’ methods, we do not perceive this will actually have
any effect.



6. Impact on resource holders
---

No impact on existing resource holders.



Proposed Draft Guidelines
(to be created as a numbered document by APNIC)


The below are example of guidelines that could be considered for
alternate needs justification.

The intention to multi-home in the future

The applicant is participating in elastic fabrics where the
requirements to connect to ‘on demand’ service providers may require
ASN/BGP connectivity

Regional limitation of obtaining multi-homing connectivity in the
‘immediate’ term, but want to design their networks for this capability

Have a single unique routing policy different to their upstream, but yet
are single-homed
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Policy SIG session schedule

[Masato Yamanishi]

Skeeve,

Unfortunately, I don't think we can change the schedule in this meeting.
I'm asking about future meetings.

Regards,
Masato

2015-03-01 18:46 GMT-08:00 Skeeve Stevens :

> Masato-san,
>
> Are you suggesting that we are able to change either Policy or Lightening
> talks for this event?  I would love to go to both.
>
> I think this is only really a problem at Apricot events, not APNIC events.
>
>
> ...Skeeve
>
> *Skeeve Stevens - Senior IP Broker*
> *v4Now - *an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/v4now ;  <http://twitter.com/networkceoau>
> linkedin.com/in/skeeve
>
> twitter.com/theispguy ; blog: www.theispguy.com
>
>
> IP Address Brokering - Introducing sellers and buyers
>
> On Mon, Mar 2, 2015 at 11:18 AM, Masato Yamanishi 
> wrote:
>
>> Dear All,
>>
>> While this point was raised by Jessica, Skeeve, and Dean during the ML
>> discussion,
>> it is also big question for me, which day and time-slot is best for
>> Policy SIG.
>>
>> Historically, we have SIG session somewhere in Thu.
>> However, do you think it is a barrier for wider participation?
>> (e.g. many operators are leaving in Thu PM?)
>>
>> Also, which session should not be in parallel with Policy SIG?
>> (I also don't want to miss Lightning talks as Skeeve mentioned)
>>
>> Please share your thoughts on this list and/or offline in Fukuoka.
>>
>> Regards,
>> Masato Yamanishi
>> APNIC Policy SIG Chair (Acting)
>>
>> *  sig-policy:  APNIC SIG on resource management policy
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Policy SIG session schedule

[Masato Yamanishi]

Dear All,

While this point was raised by Jessica, Skeeve, and Dean during the ML
discussion,
it is also big question for me, which day and time-slot is best for Policy
SIG.

Historically, we have SIG session somewhere in Thu.
However, do you think it is a barrier for wider participation?
(e.g. many operators are leaving in Thu PM?)

Also, which session should not be in parallel with Policy SIG?
(I also don't want to miss Lightning talks as Skeeve mentioned)

Please share your thoughts on this list and/or offline in Fukuoka.

Regards,
Masato Yamanishi
APNIC Policy SIG Chair (Acting)
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Requirements for Subsequent ASN Requests

[Masato Yamanishi]

Understood your point. Thx.

Regards,
Masato Yamanishi

2015-02-26 18:19 GMT-06:00 Owen DeLong :

> I’m not opposed to qualifying some cases where private AS may also work,
> because in those cases, frankly, I think most organizations will either use
> a private AS rather than go to the trouble of applying, or, they may have a
> good reason (future plans, etc.) for wanting to get a public AS and not
> have to re-run all their peering sessions later.
>
> Owen
>
> On Feb 26, 2015, at 13:40 , Masato Yamanishi  wrote:
>
> Owen,
>
> I don't want to discuss too much details since I'm acting chair,
> but I'm afraid that "unique routing policy" is vague and it may qualify
> some usecases that private AS may also work.
> So, what is the definition or understanding for "unique routing policy" in
> ARIN?
>
> Masato Yamanishi
>
> Feb 26, 2015 3:14 PM、Owen DeLong  のメッセージ:
>
> Yes, I was well aware of that. Is there anything you believe to be
> incorrect in my comments as a result? Otherwise, I’m not sure what you are
> getting at.
>
> I believe a unique routing policy or multiple peers is sufficient
> justification.
>
> Absent that, I believe that an entity which qualifies for PI and intends
> to multihome later should legitimately be able to obtain an ASN to simplify
> their build-out in anticipation of later multihoming.
>
> This last part, is, IMHO, the only change that should be contemplated vs.
> the current existing policy.
>
> Owen
>
> On Feb 26, 2015, at 9:45 AM, Masato Yamanishi  wrote:
>
> Owen and Usman,
>
> In following comments, did you consider we are discussing "public" AS
> numbers?
> Since we are discussing "public" AS, we should have some kind of
> justifications why it should be globally unique.
>
> Regards,
> Masato
>
>
> 2015-02-25 18:39 GMT-06:00 Owen DeLong :
>
>> Usman, since an AS is defined as “A collection of prefixes with a common
>> routing policy”, what would you use one for if not to connect to other
>> autonomous systems? If you are connecting to a single other autonomous
>> system, then, arguably it is impossible for your prefixes to have a
>> distinct routing policy and you are, therefore, part of that other AS. If
>> you are connecting to multiple other autonomous systems, then, you are, by
>> definition multihomed.
>>
>> If you have some better way to manage this, I’m all ears.
>>
>> Owen
>>
>> On Feb 25, 2015, at 16:26 , Usman Latif  wrote:
>>
>> ASN is an identifier for an autonomous system - so theoretically
>> speaking, an ASN should have no dependency on multihoming or single homing
>> However, what we need is a better way to regulate assignment of ASNs so
>> their allocation doesn't become wasteful..
>>
>> Regards,
>> Usman
>>
>>
>> On 26 Feb 2015, at 11:16 am, Skeeve Stevens  wrote:
>>
>> Hi Secretariat,
>>
>> I would like to understand the policy/secretariats view on the
>> justification/requirements of subsequent ASN resource requests.
>>
>>
>>
>> ...Skeeve
>>
>> *Skeeve Stevens - Senior IP Broker*
>> *v4Now - *an eintellego Networks service
>> ske...@v4now.com ; www.v4now.com
>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>> facebook.com/v4now ;  <http://twitter.com/networkceoau>
>> linkedin.com/in/skeeve
>> twitter.com/theispguy ; blog: www.theispguy.com
>>
>> IP Address Brokering - Introducing sellers and buyers
>>
>> *  sig-policy:  APNIC SIG on resource management policy
>>   *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>> *  sig-policy:  APNIC SIG on resource management policy
>>   *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>>
>> *  sig-policy:  APNIC SIG on resource management policy
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>
>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Masato Yamanishi]

Skeeve,

As acting chair, I'm neutral for each proposal, but even for me, proposed text 
sounds everybody can get AS by just saying "I need it within 6 months" without 
any explanation howto use it.
If your intension is covering more usecases, but not allowing for everyone, can 
you tweak proposed text?

> 4. Proposed policy solution
> ---
> 
> An organization is eligible for an ASN assignment if it:
>  - Is planning to use it within next 6 months

Masato Yamanishi


Feb 25, 2015 6:03 PM、Skeeve Stevens  のメッセージ:

> Dean,
> 
> What you are saying is your rose coloured view of this.
> 
> "You say they can get an ASN anytime they need one for operation purposes".  
> I am saying that the case exists that operators will want to do this - 
> WITHOUT the requirement for being multi-homed.
> 
> The requirement for being multi-homed, 'as written' causes members to either 
> lie to provide false information or find a way around the restriction (using 
> HE or someone else) to choose how they wish to manage their network.
> 
> You choosing to ignore this use case or situation doesn't make it go away 
> because you don't understand why they would want to manage their network in 
> that way.
> 
> 
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/v4now ; linkedin.com/in/skeeve
> twitter.com/theispguy ; blog: www.theispguy.com
> 
> IP Address Brokering - Introducing sellers and buyers
> 
>> On Thu, Feb 26, 2015 at 8:55 AM, Dean Pemberton  
>> wrote:
>>> On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens  wrote:
>>> 
>>> 
>>> I'm asking that the policy reflect an operators choice to decide how they 
>>> manage their networks should they choose to do it that way.
>> 
>> I believe we've entered the point of diminishing returns here.
>> 
>> It has been shown multiple times in this thread that there is no barrier to 
>> getting an ASN if one is required under the current policy.  This fact has 
>> been supported by the current hostmasters.  Operators currently have the 
>> freedom to choose how to manage their networks, they can choose to get an 
>> ASN anytime they need one for operational purposes.
>> 
>> There is no change in policy required.
>> 
>> I strongly oppose this policy as written.
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Requirements for Subsequent ASN Requests

[Masato Yamanishi]

Owen,

I don't want to discuss too much details since I'm acting chair,
but I'm afraid that "unique routing policy" is vague and it may qualify some 
usecases that private AS may also work.
So, what is the definition or understanding for "unique routing policy" in ARIN?

Masato Yamanishi

Feb 26, 2015 3:14 PM、Owen DeLong  のメッセージ:

> Yes, I was well aware of that. Is there anything you believe to be incorrect 
> in my comments as a result? Otherwise, I’m not sure what you are getting at.
> 
> I believe a unique routing policy or multiple peers is sufficient 
> justification.
> 
> Absent that, I believe that an entity which qualifies for PI and intends to 
> multihome later should legitimately be able to obtain an ASN to simplify 
> their build-out in anticipation of later multihoming. 
> 
> This last part, is, IMHO, the only change that should be contemplated vs. the 
> current existing policy.
> 
> Owen
> 
>> On Feb 26, 2015, at 9:45 AM, Masato Yamanishi  wrote:
>> 
>> Owen and Usman,
>> 
>> In following comments, did you consider we are discussing "public" AS 
>> numbers?
>> Since we are discussing "public" AS, we should have some kind of 
>> justifications why it should be globally unique.
>> 
>> Regards,
>> Masato
>> 
>> 
>> 2015-02-25 18:39 GMT-06:00 Owen DeLong :
>>> Usman, since an AS is defined as “A collection of prefixes with a common 
>>> routing policy”, what would you use one for if not to connect to other 
>>> autonomous systems? If you are connecting to a single other autonomous 
>>> system, then, arguably it is impossible for your prefixes to have a 
>>> distinct routing policy and you are, therefore, part of that other AS. If 
>>> you are connecting to multiple other autonomous systems, then, you are, by 
>>> definition multihomed.
>>> 
>>> If you have some better way to manage this, I’m all ears.
>>> 
>>> Owen
>>> 
>>>> On Feb 25, 2015, at 16:26 , Usman Latif  wrote:
>>>> 
>>>> ASN is an identifier for an autonomous system - so theoretically speaking, 
>>>> an ASN should have no dependency on multihoming or single homing
>>>> However, what we need is a better way to regulate assignment of ASNs so 
>>>> their allocation doesn't become wasteful..
>>>> 
>>>> Regards,
>>>> Usman
>>>> 
>>>> 
>>>>> On 26 Feb 2015, at 11:16 am, Skeeve Stevens  wrote:
>>>>> 
>>>>> Hi Secretariat,
>>>>> 
>>>>> I would like to understand the policy/secretariats view on the 
>>>>> justification/requirements of subsequent ASN resource requests.
>>>>> 
>>>>> 
>>>>> 
>>>>> ...Skeeve
>>>>> 
>>>>> Skeeve Stevens - Senior IP Broker
>>>>> v4Now - an eintellego Networks service
>>>>> ske...@v4now.com ; www.v4now.com
>>>>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>>>>> facebook.com/v4now ; linkedin.com/in/skeeve
>>>>> twitter.com/theispguy ; blog: www.theispguy.com
>>>>> 
>>>>> IP Address Brokering - Introducing sellers and buyers
>>>>> *  sig-policy:  APNIC SIG on resource management policy   
>>>>> *
>>>>> ___
>>>>> sig-policy mailing list
>>>>> sig-policy@lists.apnic.net
>>>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>>> *  sig-policy:  APNIC SIG on resource management policy
>>>>*
>>>> ___
>>>> sig-policy mailing list
>>>> sig-policy@lists.apnic.net
>>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>> 
>>> 
>>> *  sig-policy:  APNIC SIG on resource management policy 
>>>   *
>>> ___
>>> sig-policy mailing list
>>> sig-policy@lists.apnic.net
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>> 
>> 
> 
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Requirements for Subsequent ASN Requests

[Masato Yamanishi]

Owen and Usman,

In following comments, did you consider we are discussing "public" AS
numbers?
Since we are discussing "public" AS, we should have some kind of
justifications why it should be globally unique.

Regards,
Masato


2015-02-25 18:39 GMT-06:00 Owen DeLong :

> Usman, since an AS is defined as “A collection of prefixes with a common
> routing policy”, what would you use one for if not to connect to other
> autonomous systems? If you are connecting to a single other autonomous
> system, then, arguably it is impossible for your prefixes to have a
> distinct routing policy and you are, therefore, part of that other AS. If
> you are connecting to multiple other autonomous systems, then, you are, by
> definition multihomed.
>
> If you have some better way to manage this, I’m all ears.
>
> Owen
>
> On Feb 25, 2015, at 16:26 , Usman Latif  wrote:
>
> ASN is an identifier for an autonomous system - so theoretically speaking,
> an ASN should have no dependency on multihoming or single homing
> However, what we need is a better way to regulate assignment of ASNs so
> their allocation doesn't become wasteful..
>
> Regards,
> Usman
>
>
> On 26 Feb 2015, at 11:16 am, Skeeve Stevens  wrote:
>
> Hi Secretariat,
>
> I would like to understand the policy/secretariats view on the
> justification/requirements of subsequent ASN resource requests.
>
>
>
> ...Skeeve
>
> *Skeeve Stevens - Senior IP Broker*
> *v4Now - *an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/v4now ;  
> linkedin.com/in/skeeve
> twitter.com/theispguy ; blog: www.theispguy.com
>
> IP Address Brokering - Introducing sellers and buyers
>
> *  sig-policy:  APNIC SIG on resource management policy
>   *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
> *  sig-policy:  APNIC SIG on resource management policy
>   *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] New Version of prop-115-v001: Registration of detailed assignment information in whois DB

[Masato Yamanishi]

Dean,

I totally agree that we should focus on the problem statement itself in
Fukuoka
since this problem statement has something new concept for Policy SIG
and Fukuoka will be first meeting.

However, I don't think this proposal needs to be withdrawn to focus on the
problem statement in Fukuoka.

Certainly, in past meeting, we made it clear that we can discuss "problem
statement only presentation" first,
but that is optional.

Regards,
Masato


2015-02-24 14:41 GMT-06:00 Dean Pemberton :

> Yeah I think this is a bit of a radical proposal to accept at present.
> I'm not convinced we should be supporting CGN in this way, nor am I a
> fan of seeing more and more information make it into Whois which might
> not be the best place.
>
> I would like to hear more from Hiromi-san about the problem statement
> and how this might be solved, but I'm not at all sure I would support
> the current proposal.
>
> Would it be possible to withdraw the proposal and use the scheduled
> time during the Policy Sig for an informational session to allow
> Hiromi-san to present to the community the problem here?
>
>
> Dean
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
>
> To promote the Internet's benefits and uses, and protect its potential.
>
>
> On Wed, Feb 25, 2015 at 6:11 AM, Owen DeLong  wrote:
> > I don’t believe the proposal offers enough benefit to be worth what
> > implementation would likely
> > cost.
> >
> > First, I am sincerely hoping that CGN is an extremely temporary
> situation.
> > I’m not sure
> > it should be worth the effort to recode the registry to support it.
> >
> > Second, I’m wondering if there’s any real advantage to having this level
> of
> > detail on
> > residential subscribers that don’t even get full addresses, since we
> don’t
> > really tend
> > to have it for single-address subscribers now.
> >
> > IMHO, best to just let each ISP keep this information for themselves as
> the
> > relevant contact
> > for abuse and such is usually the ISP and not the residential user
> anyway.
> >
> > Owen
> >
> > On Feb 23, 2015, at 10:53 , Masato Yamanishi  wrote:
> >
> > Dear Colleagues,
> >
> > And, here is prop-115. No comment has not been made for this proposal.
> >
> > If reached consensus, it may needs significant change for whois database.
> > I just reviewed implementation impact assessment by the Secretariat,
> > and it says it might take more than 6 months.
> > I think same thing will happen for whois database of each NIRs.
> > And if your company have a system linked with APNIC/NIR whois database,
> it
> > will be impacted also.
> >
> > As Chair, I'm always very neutral for each proposal, including prop-115.
> > However, I would like to emphasis prop-115 should be discussed more
> widely
> > as it has wide impact.
> > It is very appreciated if you will express your views.
> >
> > Regards,
> > Masato Yamanishi, Policy SIG Chair (Acting)
> >
> >
> > 2015-02-04 14:52 GMT-06:00 Masato Yamanishi :
> >>
> >> Dear SIG members
> >>
> >> The Problem statement "Registration of detailed assignment information
> >> in whois DB" has been assigned a Policy Proposal number following the
> >> submission of a new version sent to the Policy SIG for consideration.
> >>
> >> The proposal, "prop-115-v001: Registration of detailed assignment
> >> information in whois DB" now includes an objective and proposed
> solution.
> >>
> >> Information about this and earlier versions is available from:
> >>
> >> http://www.apnic.net/policy/proposals/prop-115
> >>
> >> You are encouraged you to express your views on the proposal:
> >>
> >>  - Do you support or oppose this proposal?
> >>  - Does this proposal solve a problem you are experiencing? If so,
> >>tell the community about your situation.
> >>  - Do you see any disadvantages in this proposal?
> >>  - Is there anything in the proposal that is not clear?
> >>  - What changes could be made to this proposal to make it more
> >>effective?
> >>
> >>
> >>
> >> Regards,
> >>
> >> Masato
> >>
> >>
> >>
> >> 
> >> prop-115-v001: Registration of detailed assignment information in
> >>whois DB
> &g

Re: [sig-policy] New Version of prop-115-v001: Registration of detailed assignment information in whois DB

[Masato Yamanishi]

Dear Colleagues,

And, here is prop-115. No comment has not been made for this proposal.

If reached consensus, it may needs significant change for whois database.
I just reviewed implementation impact assessment by the Secretariat,
and it says it might take more than 6 months.
I think same thing will happen for whois database of each NIRs.
And if your company have a system linked with APNIC/NIR whois database, it
will be impacted also.

As Chair, I'm always very neutral for each proposal, including prop-115.
However, I would like to emphasis prop-115 should be discussed more widely
as it has wide impact.
It is very appreciated if you will express your views.

Regards,
Masato Yamanishi, Policy SIG Chair (Acting)


2015-02-04 14:52 GMT-06:00 Masato Yamanishi :

> Dear SIG members
>
> The Problem statement "Registration of detailed assignment information
> in whois DB" has been assigned a Policy Proposal number following the
> submission of a new version sent to the Policy SIG for consideration.
>
> The proposal, "prop-115-v001: Registration of detailed assignment
> information in whois DB" now includes an objective and proposed solution.
>
> Information about this and earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-115
>
> You are encouraged you to express your views on the proposal:
>
>  - Do you support or oppose this proposal?
>  - Does this proposal solve a problem you are experiencing? If so,
>tell the community about your situation.
>  - Do you see any disadvantages in this proposal?
>  - Is there anything in the proposal that is not clear?
>  - What changes could be made to this proposal to make it more
>effective?
>
>
>
> Regards,
>
> Masato
>
>
>
> 
> prop-115-v001: Registration of detailed assignment information in
>whois DB
> 
>
> Proposer:  Ruri Hiromi
>hir...@inetcore.com
>
>Tomohiro Fujisaki
>fujis...@syce.net
>
>
> 1. Problem statement
> 
>
> Recently, there are some cases need to get IP address assignment
> information in more detail to specify user IP address.
>
> With out this information, operators cannot filter out specific
> address range, and it might lead to 'over-filter' (i.e. filtering
> whole ISP's address range).
>
> For example:
>
> 1) 'Port' range information in IPv4
>
> ISPs are using 'CGN' or other kinds of IPv4 address sharing
> technology with assignment of IP address and specified port
> range to their users.
>
> In this case, port information is necessary to specify one user.
>
> ex) 192.0.2.24/32 1-256 is for HomeA
> 192.0.2.24/32 257-511 is for HomeB
>
> or 192.0.2.0/24 1-65536 is shared address of ISP-X
> minimum size is /32
>
> 2) address assignment size information in IPv6
>
>The IPv6 address assignment size may be different from ISP to
>ISP, and address ranges in one ISP. Address assignment prefix
>size will be necessary.
>
>ex) 2001:db8:1::0/56 is for HomeA
>2001:db8:1:1::0/48 is for HomeB
>
>or 2001:db8:1::/36's minimum size is /56
>
>
> 2. Objective of policy change
> -
>
> Lots of operators look a record when harmful behavior coming to
> their network to identify its IP address confirming it can be
> filtered or not.
>
> The goal is providing more specific information to support these
> actions.
>
>
> 3. Situation in other regions
> -
>
> No same regulation/discussion can be seen in other regions.
>
>
> 4. Proposed policy solution
> ---
>
> Provide accurate filtering information generated from whois DB.
>
> For IPv4, propose to add 'port range' information to IP address
> entry.
>
> For IPv6, propose to provide 'assignment prefix size' information
> for specific IPv6 address.
>
>
> 5. Advantages / Disadvantages
> -
>
> Advantages:
>
>  - operators can set filtering by IP address based on correct assignment
>information base.
>
>  - users who share same address space can be avoid to be including bulk
>filtering.
>
> Disadvantages:
>
>  - registration rule will move to more strict manner.
>
>  - strict watch and control i

[sig-policy] [Gentle reminder] Policy SIG is reaching on next Thu

[Masato Yamanishi]

Dear Colleagues,

While 4 proposals will be discussed in Fukuoka on next Thu,
there is no comment/discussion in past 2 weeks on this list.

It is good if you were celebrating Chinese new year, but I would like to
encourage you, in particular those who have not yet, to express your views
for each proposal.

I will send another e-mail to each proposal to refresh your memory and make
the point clear.

Regards,
Masato Yamanishi, Policy SIG Chair (Acting)
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] New Version of prop-115-v001: Registration of detailed assignment information in whois DB

[Masato Yamanishi]

Dear SIG members

The Problem statement "Registration of detailed assignment information
in whois DB" has been assigned a Policy Proposal number following the
submission of a new version sent to the Policy SIG for consideration.

The proposal, "prop-115-v001: Registration of detailed assignment
information in whois DB" now includes an objective and proposed solution.

Information about this and earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-115

You are encouraged you to express your views on the proposal:

 - Do you support or oppose this proposal?
 - Does this proposal solve a problem you are experiencing? If so,
   tell the community about your situation.
 - Do you see any disadvantages in this proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more
   effective?



Regards,

Masato




prop-115-v001: Registration of detailed assignment information in
   whois DB


Proposer:  Ruri Hiromi
   hir...@inetcore.com

   Tomohiro Fujisaki
   fujis...@syce.net


1. Problem statement


Recently, there are some cases need to get IP address assignment
information in more detail to specify user IP address.

With out this information, operators cannot filter out specific
address range, and it might lead to 'over-filter' (i.e. filtering
whole ISP's address range).

For example:

1) 'Port' range information in IPv4

ISPs are using 'CGN' or other kinds of IPv4 address sharing
technology with assignment of IP address and specified port
range to their users.

In this case, port information is necessary to specify one user.

ex) 192.0.2.24/32 1-256 is for HomeA
192.0.2.24/32 257-511 is for HomeB

or 192.0.2.0/24 1-65536 is shared address of ISP-X
minimum size is /32

2) address assignment size information in IPv6

   The IPv6 address assignment size may be different from ISP to
   ISP, and address ranges in one ISP. Address assignment prefix
   size will be necessary.

   ex) 2001:db8:1::0/56 is for HomeA
   2001:db8:1:1::0/48 is for HomeB

   or 2001:db8:1::/36's minimum size is /56


2. Objective of policy change
-

Lots of operators look a record when harmful behavior coming to
their network to identify its IP address confirming it can be
filtered or not.

The goal is providing more specific information to support these
actions.


3. Situation in other regions
-

No same regulation/discussion can be seen in other regions.


4. Proposed policy solution
---

Provide accurate filtering information generated from whois DB.

For IPv4, propose to add 'port range' information to IP address
entry.

For IPv6, propose to provide 'assignment prefix size' information
for specific IPv6 address.


5. Advantages / Disadvantages
-

Advantages:

 - operators can set filtering by IP address based on correct assignment
   information base.

 - users who share same address space can be avoid to be including bulk
   filtering.

Disadvantages:

 - registration rule will move to more strict manner.

 - strict watch and control in registration of database records.

 - additional record or option will be considered.

 - privilege for withdrawing detailed information will be set for these
   records.


6. Impact on APNIC
--

This might be beyond the scope of using whois DB.


7. Other Consideration
--

For the security reason, this detailed records may be able to see
only by operators.(some kind of user control/privilege setting is
needed)

For hosting services, /32 in IPv4 and /128 in IPv6 registration
should be discussed based on its operability and possibility. But a
harmful activities to filter by IP addresses are coming from hosting
services as well. Here it seemed to be some demands.


References
--

TBD
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] [New Problem Statement] prop-115: Registration of detailed assignment

[Masato Yamanishi]

Dear SIG members

A Problem Statement, identified as "prop-115: Registration of detailed
assignment information in whois DB" has been sent to the Policy SIG for
review and further discussion, or development by the community.

It  will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka,
Japan on Thursday, 5 March 2015.

We invite you to review and comment on the proposal on the mailing list
before the meeting.

The purpose of submitting a Problem Statement is to reflect that the
author(s) are unsure exactly what policy changes are required to
Resolve the stated problem.

It is an invitation to discuss the severity of the problem and to discuss
possible solutions, whether they are through policy changes, or some
other mechanism.

I would encourage those who share the author’s view that this problem
should be resolved to participate in the discussion by posting their views
and suggestions to the list.

Regards,

Masato




-
prop-115-v001: Registration of detailed assignment information in
   whois DB
-

Proposer:  Ruri Hiromi
   hir...@inetcore.com

   Tomohiro Fujisaki
   fujis...@syce.net


1. Problem statement


Current information in Whois DB does not have enough, detailed
record if operator in an network use it for filtering.

To cover this, we propose modification towards whois DB.

1) IPv4 address assignment information has "minimum assignment
   network space/or declare shared address" and "port number" which
   for shared address space.

   ex) 192.0.1.24/32 1-256 is for HomeA
   192.0.1.24/32 257-511 is for HomeB

 2) IPv6 address assignment information also has "minimum assignment
network space"

ex) 2001:db8:1::0/56 is for HomeA
2001:db8:2::0/48 is for HomeB

 3) for the security reason, this detailed records may be able to
see only operators.(some kind of user control is needed)


2. Objective of policy change
-

Under community development


3. Situation in other regions
-

Under community development


4. Proposed policy solution
---

Under community development


5. Advantages / Disadvantages
-

Advantages:
Under community development


Disadvantages:
Under community development



6. Impact on resource holders
-

Under community development


7. References
-
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Masato Yamanishi]

Dear SIG members

The proposal "prop-114: Modification in the ASN eligibility criteria"
has been sent to the Policy SIG for review.

It  will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka,
Japan on Thursday, 5 March 2015.

We invite you to review and comment on the proposal on the mailing list
before the meeting.

The comment period on the mailing list before an APNIC meeting is an
important part of the policy development process. We encourage you to
express your views on the proposal:

 - Do you support or oppose this proposal?
 - Does this proposal solve a problem you are experiencing? If so,
  tell the community about your situation.
 - Do you see any disadvantages in this proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more
  effective?


Information about this proposal is available at:

http://www.apnic.net/policy/proposals/prop-114


Regards,

Masato





---
prop-114-v001: Modification in the ASN eligibility criteria
---

Proposer: Aftab Siddiqui
  aftab.siddi...@gmail.com

  Skeeve Stevens
  ske...@eintellegonetworks.com


1. Problem statement


The current ASN assignment policy dictates two eligibility criteria
and both should be fulfilled in order to get an ASN. The policy
seems to imply that both requirements i.e. multi-homing and clearly
defined single routing policy must be met simultaneously, this has
created much confusion in interpreting the policy.

As a result organizations have either provided incorrect information
to get the ASN or barred themselves from applying.


2. Objective of policy change
-

In order to make the policy guidelines simpler we are proposing to
modify the text describing the eligibility criteria for ASN
assignment by removing multi-homing requirement for the organization.


3. Situation in other regions
-

ARIN:
It is not mandatory but optional to be multi-homed in order get ASN

RIPE:
Policy to remove multi-homing requirement is currently in discussion
and the current phase ends 12 February 2015
Policy - https://www.ripe.net/ripe/policies/proposals/2014-03

LACNIC:
only inter-connect is mandatory not multi-homing

AFRINIC:
 It is mandatory to be multi-homed in order to get ASN.


4. Proposed policy solution
---

An organization is eligible for an ASN assignment if it:
 - Is planning to use it within next 6 months


5. Advantages / Disadvantages
-

Advantages:

Removing the mandatory multi-homing requirement from the policy will
make sure that organizations are not tempted to provide wrong
information in order to fulfil the criteria of eligibility.

Disadvantages:

No disadvantage.


6. Impact on resource holders
-

No impact on existing resource holders.


7. References
-
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] [New Policy Proposal] prop-113: Modification in the IPv4 eligibility criteria

[Masato Yamanishi]

Dear SIG members

The proposal "prop-113: Modification in the IPv4 eligibility criteria"
has been sent to the Policy SIG for review.

It  will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka,
Japan on Thursday, 5 March 2015.

We invite you to review and comment on the proposal on the mailing list
before the meeting.

The comment period on the mailing list before an APNIC meeting is an
important part of the policy development process. We encourage you to
express your views on the proposal:

 - Do you support or oppose this proposal?
 - Does this proposal solve a problem you are experiencing? If so,
  tell the community about your situation.
 - Do you see any disadvantages in this proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more
  effective?


Information about this proposal is available at:


http://www.apnic.net/policy/proposals/prop-113

Regards

Masato




prop-113-v001: Modification in the IPv4 eligibility criteria


Proposer:   Aftab Siddiqui
aftab.siddi...@gmail.com

Skeeve Stevens
ske...@eintellegonetworks.com


1. Problem statement

The current APNIC IPv4 delegation policy defines multiple
eligibility criteria and applicant must meet one to be eligible to
receive IPv4 resources. One of the criteria dictates that “an
organization is eligible if it is currently multi-homed with
provider-based addresses, or demonstrates a plan to multi-home
within one month” (section 3.3).

The policy seems to imply that multi-homing is mandatory even if
there is no use case for the applicant to be multi-homed or even
when there is only one upstream provider available, this has created
much confusion in interpreting this policy.

As a result organizations have either tempted to provide incorrect
or fabricated multi-homing information to get the IPv4 resources or
barred themselves from applying.


2. Objective of policy change
-

In order to make the policy guidelines simpler we are proposing to
modify the text of section 3.3.


3. Situation in other regions
-

ARIN:
There is no multi-homing requirement

RIPE:
There is no multi-homing requirement.

LACNIC:
Applicant can either have multi-homing requirement or interconnect.

AFRINIC:
There is no multi-homing requirement.


4. Proposed policy solution
---

Section 3.3: Criteria for small delegations
An organization is eligible if it is currently multi-homed or
inter-connected with provider (ISP)-based addresses, or demonstrates
a plan to advertise the prefixes within 3 months.


5. Advantages / Disadvantages
-

Advantages:

Removing the mandatory multi-homing requirement from the policy will
make sure that organizations are not tempted to provide wrong or
fabricated multi-homing information in order to fulfil the criteria
of eligibility.

Disadvantages:

There is no known disadvantage of this proposal.


6. Impact on resource holders
-

No impact on existing resource holders.


7. References
-
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space

[Masato Yamanishi]

Dear SIG members

The proposal "prop-112: On demand expansion of IPv6 address allocation
size in legacy IPv6 space" has been sent to the Policy SIG for review.

It  will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka,
Japan on Thursday, 5 March 2015.

We invite you to review and comment on the proposal on the mailing list
before the meeting.

The comment period on the mailing list before an APNIC meeting is an
important part of the policy development process. We encourage you to
express your views on the proposal:

 - Do you support or oppose this proposal?
 - Does this proposal solve a problem you are experiencing? If so,
  tell the community about your situation.
 - Do you see any disadvantages in this proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more
  effective?


Information about this proposal is available at:

http://www.apnic.net/policy/proposals/prop-112

Regards

Masato




--
prop-112-v001: On demand expansion of IPv6 address allocation size in
   legacy IPv6 space
--


Proposer:Tomohiro Fujisaki
 fujis...@syce.net


1. Problem statement


IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6
address allocation and assignment policy"[1].

In late 2006, sparse address allocation mechanism has implemented
to manage APNIC IPv6 address pool. The block `2400:::/12' has
managed with this mechanism.

Before 2006, /29 was reserved for all /32 allocations by sequential
allocation method made from those old /23 blocks (Legacy IPv6
block).

These reserved blocks might be kept unused in the future.


2. Objective of policy change
-

This proposal modifies the eligibility for organizations in the
legacy IPv6 block to extend their IPv6 address space up to a /29
(/32 -/29) by request basis.


3. Situation in other regions
-

RIPE-NCC:
The policy "Extension of IPv6 /32 to /29 on a per-allocation vs
per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can
get up to /29 by default.


4. Proposed policy solution
---

- define 'legacy IPv6 address blocks'
  2001:0200::/23
  2001:0c00::/23
  2001:0e00::/23
  2001:4400::/23

- Add following text in the policy document:

  for Existing IPv6 address space holders

  LIRs that hold one or more IPv6 allocations in the legacy IPv6
  address blocks are able to request extension of each of these
  allocations up to a /29 without meeting the utilization rate for
  subsequent allocation and providing further documentation.


5. Advantages / Disadvantages
-

Advantages:

  It is possible to utilize address blocks which is potentially
  unused into the future.


Disadvantages:

  Some people may argue this will lead to inefficient utilization of
  IPv6 space since LIRs can obtain huge address size unnecessarily.
  However, this will not happen because larger address size needs
  higher cost to maintain that address block.


6. Impact on resource holders
-

  NIRs must implement this policy if it is implemented by APNIC.


7. References
-

  [1] IPv6 address allocation and assignment policy
  http://www.apnic.net/policy/ipv6-address-policy
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] APNIC 39 Policy Proposal Deadline: 30 January 2015

[Masato Yamanishi]

Dear Colleagues,

I have been asked from some delegates to extend the deadline since they
have not yet finished their proposal.
I think it is reasonable to accept it, so I would like to extend the
deadline until Mon. Feb 2nd 2015.

Regards,
Masato Yamanishi
APNIC Policy SIG Chair (Acting)


Masato (Matt) Yamanishi
Cell: +1-213-361-4855

2015-01-28 0:00 GMT-06:00 Masato Yamanishi :

> Dear Colleagues,
>
> While I have heard that some people are preparing policy proposals, the
> deadline is reaching this Friday.
> So, please be sure to post the proposal to before the end of Friday Jan 30
> 2015 if you have it.
> (please see "How to submit" in previous message if you need)
>
> Also, I'm changing my e-mail from myama...@japan-telecom.com to
> myama...@gmail.com in next few weeks.
> So, please don't be surprised even if I will send a message from there.
>
> Masato Yamanishi
> APNIC Policy SIG Chair (Acting)
>
>
>
> 2015-01-15 16:09 GMT-06:00 Masato Yamanishi :
>
>> Dear Colleagues,
>>
>> This is a reminder that the deadline to submit Policy Proposals for
>> APNIC 39 is Friday, 30 January 2015
>>
>> Only proposals submitted by this date will be discussed at the meeting.
>>
>> Regards,
>>
>> Masato
>> APNIC Policy SIG Chair (Acting)
>>
>>
>> How to submit your Policy Proposal
>> -
>>
>> There are two ways to submit a policy proposal to the Policy SIG Chairs:
>>
>> 1. Use the online form at:
>>http://www.apnic.net/community/policy/proposals/submit
>>
>> 2. Send your proposal in TEXT format to .
>>http://www.apnic.net/community/policy/process/proposal_template.txt
>>
>> If you are unsure of the solution to your policy issue, whether your
>> policy idea has merit, or if it is covered by existing policy, you are
>> encouraged to complete only the Problem Statement part of your proposal.
>> The community can then assist in developing the best solution.
>>
>>
>> More information
>> -
>>
>> APNIC's PDP is explained at:
>>
>> http://www.apnic.net/community/policy/process
>>
>> How to participate in policy discussions:
>>
>> http://www.apnic.net/community/policy/process/how-to-participate
>>
>> View current and past policy proposals at:
>>
>> http://www.apnic.net/policy/proposals
>>
>>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] APNIC 39 Policy Proposal Deadline: 30 January 2015

[Masato Yamanishi]

Dear Colleagues,

While I have heard that some people are preparing policy proposals, the
deadline is reaching this Friday.
So, please be sure to post the proposal to before the end of Friday Jan 30
2015 if you have it.
(please see "How to submit" in previous message if you need)

Also, I'm changing my e-mail from myama...@japan-telecom.com to
myama...@gmail.com in next few weeks.
So, please don't be surprised even if I will send a message from there.

Masato Yamanishi
APNIC Policy SIG Chair (Acting)



2015-01-15 16:09 GMT-06:00 Masato Yamanishi :

> Dear Colleagues,
>
> This is a reminder that the deadline to submit Policy Proposals for
> APNIC 39 is Friday, 30 January 2015
>
> Only proposals submitted by this date will be discussed at the meeting.
>
> Regards,
>
> Masato
> APNIC Policy SIG Chair (Acting)
>
>
> How to submit your Policy Proposal
> -
>
> There are two ways to submit a policy proposal to the Policy SIG Chairs:
>
> 1. Use the online form at:
>http://www.apnic.net/community/policy/proposals/submit
>
> 2. Send your proposal in TEXT format to .
>http://www.apnic.net/community/policy/process/proposal_template.txt
>
> If you are unsure of the solution to your policy issue, whether your
> policy idea has merit, or if it is covered by existing policy, you are
> encouraged to complete only the Problem Statement part of your proposal.
> The community can then assist in developing the best solution.
>
>
> More information
> -
>
> APNIC's PDP is explained at:
>
> http://www.apnic.net/community/policy/process
>
> How to participate in policy discussions:
>
> http://www.apnic.net/community/policy/process/how-to-participate
>
> View current and past policy proposals at:
>
> http://www.apnic.net/policy/proposals
>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] APNIC 39 Policy Proposal Deadline: 30 January 2015

[Masato Yamanishi]

Dear Colleagues,

This is a reminder that the deadline to submit Policy Proposals for
APNIC 39 is Friday, 30 January 2015

Only proposals submitted by this date will be discussed at the meeting.

Regards,

Masato
APNIC Policy SIG Chair (Acting)


How to submit your Policy Proposal
-

There are two ways to submit a policy proposal to the Policy SIG Chairs:

1. Use the online form at:
   http://www.apnic.net/community/policy/proposals/submit

2. Send your proposal in TEXT format to .
   http://www.apnic.net/community/policy/process/proposal_template.txt

If you are unsure of the solution to your policy issue, whether your
policy idea has merit, or if it is covered by existing policy, you are
encouraged to complete only the Problem Statement part of your proposal.
The community can then assist in developing the best solution.


More information
-

APNIC's PDP is explained at:

http://www.apnic.net/community/policy/process

How to participate in policy discussions:

http://www.apnic.net/community/policy/process/how-to-participate

View current and past policy proposals at:

http://www.apnic.net/policy/proposals
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] APNIC 39 Policy Proposal Deadline: 30 January 2015

[Masato Yamanishi]

Dear Colleagues,

APNIC policies are determined by an open, transparent, and bottom-up
consensus-based Policy Development Process (PDP). Anybody can propose a
policy change, participate in the discussion of proposed changes, and
express their support or objection for any proposal.

This PDP begins when somebody submits a Policy Proposal, or a problem
statement to the APNIC Policy SIG Chairs. Once considered and accepted
by the SIG Chairs, the proposal must be posted to Policy SIG mailing
list at least four weeks before the APNIC 39 Policy SIG meeting in
Fukuoka, Japan on Thursday, 5 March 2015.

To be considered for consensus at the APNIC 39 OPM, policy proposals
must be submitted by Friday, 30 January 2015.


How to submit your Policy Proposal
---

There are two ways to submit a policy proposal to the Policy SIG Chairs:

1. Use the online form at:

http://www.apnic.net/community/policy/proposals/submit

2. Send your proposal in TEXT format to .

http://www.apnic.net/community/policy/process/proposal_template.txt

If you are unsure of the solution to your policy issue, whether your
policy idea has merit, or if it is covered by existing policy, you are
encouraged to complete only the Problem Statement part of your proposal.
The community can then assist in developing the best solution.


More information
---

Learn more about the APNIC Policy Sig:

http://www.apnic.net/policy-sig

How to participate in policy discussions:

http://www.apnic.net/community/policy/process/how-to-participate

APNIC's PDP is explained at:

http://www.apnic.net/community/policy/process

View current and past policy proposals at:

http://www.apnic.net/policy/proposals


We look forward to and encourage your participation in the APNIC PDP.


APNIC Policy SIG (Acting) Chair

Masato
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] The findings through community discussions in APNIC 38

[Masato Yamanishi]

SIG members,

As you know, we had two community discussions, one about APNIC Survey result
in APNIC 38 and another about consensus definitions.
(If you are not familiar with APNIC Survey result, please refer
https://conference.apnic.net/38#apnicsurveyresult)

Through these discussions, we identified following possible barriers to
further participation in APNIC Policy discussion.

1.  English may be a barrier for non-native english speakers
2.  Particularly Non-members are not participating

Regarding the language barrier, the floor’s comments are;
- Simultaneous and/or document translation by professional
interpreters/translators may not help (while they are quite expensive) since
the context may lost
- Active participants could translate and promote proposals within their
domestic communities
- Need to consider other solutions also
If you could discuss this point in your local communities, in particular in
non-english communities,
and give feedback to the list, it is very helpful to consider further
solutions

Regarding non-members’ participation, participants thought;
- We need to better understand why. Have more research?
- Promoting PDP is a possible solution
Another community discussion about consensus definitions also showed that we
may need to promote our PDP more instead of improving the documents.
Two possible solutions to promote PDP were raised in the session, which are;
- Producing a introductory video about PDP
- Make more use of the flowchart
(http://www.apnic.net/community/policy/process)
But these are views mainly from current active participants, so I would like
to ask more comments/thoughts on this list.
Also, it is very appreciated if you could ask it to your local community
including non-APNIC members and provide feedback to the list as well.

Lastly, if you have any other barriers/issues to participate APNIC Policy
SIG, please feel free to share it to Policy SIG mailing list

(Am I ask it to other lists also?)

Regards,
Masato Yamanishi, Acting Chair, APNIC Policy SIG




*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Resignation as Policy SIG chair

[Masato Yamanishi]

Dear Andy and SIG members,

I'm very sorry to hear your resignation, but I would like to express our
appreciation for your service, in particular for last 3 years as Policy SIG
Chair and NRO NC, on behalf of the community.

SIG members>
Please join me in thanking Andy for his great chairmanship and excellent
cooperation work.

Masato Yamanishi
Policy SIG co-chair

Sep 19, 2014 10:18 PM、Andy Linton  のメッセージ:

I've decided to stand down as chair of the APNIC Policy SIG. I'm doing this
for a number of reasons which I'll go into in this mail. I was not able to
attend APNIC38 as I am currently in the UK but to be honest even if I'd
been in New Zealand I'm not sure that I would have made the trip to
Brisbane.

Several meetings ago Randy Bush put a proposal in front of the Policy SIG
suggesting that the time had come to abandon the making of policy in the
current form. I chaired the session that discussed this matter. We had a
session which ended in confusion and acrimony and the debate ended at that
point.

I will say that while Randy and I disagreed over the mechanism of how to
disband/radically change the current process, I am in full support of the
core idea proposed in prop-103. I believe the current process is failing
the community and it should be wound up and replaced with some other
mechanism.

At APNIC38, my colleague Masato Yamanashi was returned unopposed as
co-chair and I am confident that he will handle the role of Chair until the
meeting in Fukuoka next February where the community can decide if they
want to continue with the current mechanism or not. My resignation now will
give plenty of time for any debate on this.

I believe that we are now at the stage where we are having a face to face
meeting of the Policy SIG mainly to validate the legitimacy of having a
meeting of APNIC every six months. There's little of substance that
couldn't be discussed on line and there are very few people taking part in
debate on address policy because there is really very little to discuss.

I believe that APNIC's job is and should continue to be a registry with a
lightweight structure. I believe APNIC has changed into a quasi political
body that spends vast amounts of time and money travelling to Internet
Governance meetings where they meet other similar entities and they all
tell each other what a fabulous job they're doing of governing the
Internet.

You may agree with them doing that - that's fine. I don't and I think it's
time for me to step aside and let them get on with it. You could say I
should stay and help to try to fix things but I simply don't have the time
or enthusiasm.

I can do no better that quote from a paper from Milton Mueller: Stewardship
and the Management of Internet Protocol Addresses (
www.internetgovernance.org/pdf/CyberDialogue2012_Mueller.pdf). I don't
agree with everything Mueller says but this encapsulates the problem very
well:

"But here we face the exact same problem as before: all reforms in IP
address governance structure must come from the RIRs themselves. The ASO of
ICANN is nothing more than the NRO, and the NRO is nothing more than a
combination of the staff and CEOs of the RIRs. And why would the RIRs
initiate or institute reforms that would put themselves out of business?
The RIRs have many merits as organizations, but they are also quite
entrenched, with tens of millions of dollars in annual revenues, a growing
number of jobs, and an important place for their managers in the overall
Internet governance regime. If this structure is to be dramatically
changed, the impetus will not and cannot come from the RIRs themselves."

I'd like to thank all those in the community who I've worked with over the
years. I count very many of you as friends and I'm sure we'll catch up
sometime in the future.

andy

*  sig-policy:  APNIC SIG on resource management policy
  *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] prop-111 abandoned at APNIC 38

[Masato Yamanishi]

Dear colleagues

Version 4 of prop-111: Request-based expansion of IPv6 default
allocation size, did not reach consensus at the APNIC 38 Policy SIG and
was abandoned.

Proposal details


This proposal would have modified the eligibility for an organization to
expand an existing allocation, or receive an initial IPv6 allocation up
to a /29 on a request basis.

Proposal details, including the full text of the proposal, history, and
links to previous versions are available at:

http://www.apnic.net/policy/proposals/prop-111

Regards

Masato
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size

[Masato Yamanishi]

Dear SIG members

A new version of the proposal “prop-111: Request-based expansion of IPv6
default allocation size has been sent to the Policy SIG for review.

There are changes to section 4. Proposed policy solution only.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-111

You are encouraged to express your views on the proposal:

 - Do you support or oppose the proposal?
 - Is there anything in the proposal that is not clear?
 - What change could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Andy and Masato



--
prop-111-v004 Request-based expansion of IPv6 default allocation size
--

Author: Tomohiro Fujisaki
fujis...@syce.net


1. Problem statement


IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6
address allocation and assignment policy"[1]. It's better to
expand this minimum allocation size up to /29 (/32 - /29) since:

- Before sparse allocation mechanism implemented in late 2006, /29
was reserved for all /32 allocations by sequential allocation
method made from those old /23 blocks. These reserved blocks
might be kept unused in the future.

- Sparse allocation mechanism was implemented in late 2006 with a
/12 allocation from the IANA. Under the sparse allocation
mechanism, there is no reservation size defined, and the space
between allocations continues to change, depending on the
remaining free pool available in APNIC.

However, the "APNIC guidelines for IPv6 allocation and
assignment requests"[2] stated:

"In accordance with APNIC's "IPv6 address allocation and
assignment policy", where possible, subsequent delegations to the
same resource holder are made from an adjacent address block by
growing the delegation into the free space remaining, unless
disaggregated ranges are requested for multiple discrete
networks."

So, it is expected that allocation up to /29 is guaranteed for
consistency with allocations above. Based on the current
situation, contiguous allocation of /29 can still be accommodated
even under the sparse allocation mechanism (Current /32
allocations from the /12 block can grow up to /24 at this stage).

- After amended HD Ratio (0.94) and base calculation size (/56) was
introduced (prop-031 and prop-033), to obtain address blocks larger
than /32 and to request additional address blocks became harder
especially for small and middle size ISPs.

- For traffic control purpose, some LIRs announce address blocks
longer than /32 (e.g. /35). However, some ISPs may set filters to
block address size longer than /32 since some filtering
guidelines recommend to filter longer prefix than /32([3][4]). If
LIRs have multiple /32, they can announce these blocks and its
reachability will be better than longer prefix.

- If an LIR needs address blocks larger than /32, LIRs may tend to
announce as a single prefix if a /29 is allocated initially at
once. i.e., total number of announced prefixes in case 1 may be
smaller than in case 2.

case 1:
The LIR obtains /29 at the beginning of IPv6 network construction.

case 2:
The LIR obtains /32, and /31, /30 additionally with the subsequent
allocation mechanism.

2. Objective of policy change
-

This proposal modifies the eligibility for an organization to
receive or extend an IPv6 address space up to a /29 (/32 -/29) by
explaining how the extended space up to /29 will be used.


3. Situation in other regions
-

RIPE-NCC:
The policy "Extension of IPv6 /32 to /29 on a per-allocation vs
per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get
up to /29 by default.


4. Proposed policy solution


- Change the text to "5.2.2 Minimum initial allocation size" of
current policy document as below:

Organizations that meet the initial allocation criteria are
eligible to receive an initial allocation of /32. The organizations
can receive up to /29 by providing utilization information of the whole
address space.

- Change /32 to /29 in "5.2.3 Larger initial allocations”

Initial allocations larger than /29 may be justified if:

- Add following text as 5.3.4

5.3.4 Extend existing allocations to /29
LIRs that hold one or more IPv6 allocations are able to request
extension of each of these allocations up to a /29 without meeting
the utilization rate for subsequent allocation by providing their network
plan to show how the whole address space will be used.


5. Explain the advantages of the proposal
-

- It is possible to utilize address blocks which is potentially
  unused into the future.

- Organizations can design their IPv6 networks more flexibly.

- It will be possible for LIRs to control traffic easier.


6. Explain the disadvantages of

Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size [SECURITY=UNCLASSIFIED]

[Masato Yamanishi]

Owen and Mike,

It is very clear. Thank you.

Rgs,
Masato

On 2014/09/03 15:00, "HENDERSON MIKE, MR" 
wrote:

> Masato,
>  
> My position is exactly aligned with Owen’s:
> “I do not support the proposal as written. I would support it if /28s were
> issued whenever possible and /29s were only issued in cases where the existing
> assignment or allocation cannot be expanded to at least /28.”
> 
>  
>  
> Regards
>  
>  
> Mike
>  
> 
> From: Owen DeLong [mailto:o...@delong.com]
> Sent: Thursday, 4 September 2014 9:27 a.m.
> To: Masato Yamanishi
> Cc: HENDERSON MIKE, MR; sig-pol...@apnic.net
> Subject: Re: [sig-policy] New version of prop-111: Request-based expansion of
> IPv6 default allocation size [SECURITY=UNCLASSIFIED]
>  
> 
> On Sep 3, 2014, at 2:12 PM, Masato Yamanishi 
> wrote:
>  
> 
> Hi Mike,
> 
>  
> 
> Thank you for you comment and let me clarify your one point.
> 
>  
> 
> On 2014/09/02 16:07, "HENDERSON MICHAEL, MR"  <mailto:michael.hender...@nzdf.mil.nz> > wrote:
> 
>  
>> 
>> I do not favour IPv6 allocations on “non-nibble” boundaries, I believe that
>> allocations ought to be made on “nibble” (i.e. 4-bit) boundaries. On that
>> basis, the next allocation larger than /32 would be /28, not /29.
>> 
>> Address masking and calculation on /29 boundaries will in my view be quite
>> nasty, and the size of the IPv6 address space is sufficiently large that we
>> need not, and therefore should not, impose such inconveniences on ourselves.
>> 
>>  
>> 
>> Hence, in my IPv6 allocation world, a resource holder who has a demonstrated
>> need (for whatever value of ‘need’ seems appropriate) for address space
>> larger than /32, should be allocated a /28.
>> 
>> If they are ‘growing’ an existing /32, then the new /28 would very preferably
>> be one that includes the currently-allocated /28.
>> 
>>  
>> 
>>  
>> 
>> However, I understand the current situation is that the ‘legacy’ IPv6 address
>> allocation was for smaller allocations within blocks on /29 boundaries, if I
>> read the Proposition correctly.
>> 
>> As a special case only, I would support the allocation of these ‘legacy /29’
>> blocks. The provisos being that firstly they do fall into this ‘legacy’
>> category, and that secondly it is not possible (owing to allocation to a
>> third party) to allocate a /28 to the relevant resource holder
>> 
>>  
>> 
>>  
> 
>  
> 
> But this proposal is NOT ONLY for the special case.
> 
> Every organizations, which are new comers, “legacy” IPv6 space holder, and
> existing IPv6 space holder with sparse allocation mechanism,
> 
> will be eligible for /29 by providing necessary information as shown in Sec.4.
> 
>  
> Which I believe is a flaw in the proposal.
> 
> 
> 
>  
> 
> So, can you share your preference for current proposed text as it is?
> 
>  
> I do not support the proposal as written. I would support it if /28s were
> issued whenever possible and /29s were only issued in cases where the existing
> assignment or allocation cannot be expanded to at least /28.
> 
>  
> 
> Owen
> 
> 
> 
>  
>> 4. Proposed policy solution
>> 
>>  
>> - Change the text to "5.2.2 Minimum initial allocation size" of
>> current policy document as below:
>>  
>> Organizations that meet the initial allocation criteria are
>> eligible to receive an initial allocation of /32. The organizations
>> can receive up to /29 by providing utilization information of the whole
>> address space.
>>  
>> - Add following text in the policy document:
>>  
>> for Existing IPv6 address space holders
>>  
>> LIRs that hold one or more IPv6 allocations are able to request
>> extension of each of these allocations up to a /29 without meeting
>> the utilization rate for subsequent allocation by explaining
>> how the whole address space will be used.
>>  
> 
> Rgs,
> 
> Masato
> *  sig-policy:  APNIC SIG on resource management policy
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
> http://mailman.apnic.net/mailman/listinfo/sig-policy
> <http://mailman.apnic.net/mailman/listinfo/sig-policy>
>  
> The information contained in this Internet Email message is intended for the
> addressee only and may contain privileged information, but not necessarily the
> official views or opinions of the New Zealand Defence Force.  If you are not
> the intended recipient you must not use, disclose, copy or
> distribute this message or the information in it.  If you have received this
> message in error, please Email or telephone the sender immediately.


*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size [SECURITY=UNCLASSIFIED]

[Masato Yamanishi]

Hi Mike,

Thank you for you comment and let me clarify your one point.

On 2014/09/02 16:07, "HENDERSON MICHAEL, MR" 
wrote:

> I do not favour IPv6 allocations on “non-nibble” boundaries, I believe that
> allocations ought to be made on “nibble” (i.e. 4-bit) boundaries. On that
> basis, the next allocation larger than /32 would be /28, not /29.
> Address masking and calculation on /29 boundaries will in my view be quite
> nasty, and the size of the IPv6 address space is sufficiently large that we
> need not, and therefore should not, impose such inconveniences on ourselves.
>  
> Hence, in my IPv6 allocation world, a resource holder who has a demonstrated
> need (for whatever value of ‘need’ seems appropriate) for address space larger
> than /32, should be allocated a /28.
> If they are ‘growing’ an existing /32, then the new /28 would very preferably
> be one that includes the currently-allocated /28.
>  
>  
> However, I understand the current situation is that the ‘legacy’ IPv6 address
> allocation was for smaller allocations within blocks on /29 boundaries, if I
> read the Proposition correctly.
> As a special case only, I would support the allocation of these ‘legacy /29’
> blocks. The provisos being that firstly they do fall into this ‘legacy’
> category, and that secondly it is not possible (owing to allocation to a third
> party) to allocate a /28 to the relevant resource holder
>  
>  

But this proposal is NOT ONLY for the special case.
Every organizations, which are new comers, “legacy” IPv6 space holder, and
existing IPv6 space holder with sparse allocation mechanism,
will be eligible for /29 by providing necessary information as shown in
Sec.4.

So, can you share your preference for current proposed text as it is?

> 4. Proposed policy solution
> 
> 
> - Change the text to "5.2.2 Minimum initial allocation size" of
> current policy document as below:
> 
> Organizations that meet the initial allocation criteria are
> eligible to receive an initial allocation of /32. The organizations
> can receive up to /29 by providing utilization information of the whole
> address space.
> 
> - Add following text in the policy document:
> 
> for Existing IPv6 address space holders
> 
> LIRs that hold one or more IPv6 allocations are able to request
> extension of each of these allocations up to a /29 without meeting
> the utilization rate for subsequent allocation by explaining
> how the whole address space will be used.
> 
Rgs,
Masato


*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size

[Masato Yamanishi]

Dear Colleagues,

While next APNIC meeting is reaching 3 weeks later, we saw just couple of
comments for this revised proposal.

Our process for reaching consensus relies on hearing the opinions of those
who can only take part via this list
as well as those who can attend the Policy SIG sessions at the APNIC
meetings.

It would be very helpful for the community to hear any opinions including
favor or against.

Regards,
Policy SIG Chairs,


On 2014/07/31 11:42, "Masato Yamanishi"  wrote:

> Dear SIG members
> 
> A new version of the proposal “prop-111: Request-based expansion of IPv6
> default allocation size has been sent to the Policy SIG for review.
> 
> Information about earlier versions is available from:
> 
> http://www.apnic.net/policy/proposals/prop-111
> 
> You are encouraged to express your views on the proposal:
> 
>  - Do you support or oppose the proposal?
>  - Is there anything in the proposal that is not clear?
>  - What changes could be made to this proposal to make it more effective?
> 
> Please find the text of the proposal below.
> 
> Kind Regards,
> 
> Andy and Masato
> 
> 
> --
> prop-111-v003 Request-based expansion of IPv6 default allocation size
> --
> 
> Author: Tomohiro Fujisaki
> fujis...@syce.net
> 
> 
> 1. Problem statement
> 
> 
> IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6
> address allocation and assignment policy"[1]. It's better to
> expand this minimum allocation size up to /29 (/32 - /29) since:
> 
> - Before sparse allocation mechanism implemented in late 2006, /29
> was reserved for all /32 allocations by sequential allocation
> method made from those old /23 blocks. These reserved blocks
> might be kept unused in the future.
> 
> - Sparse allocation mechanism was implemented in late 2006 with a
> /12 allocation from the IANA. Under the sparse allocation
> mechanism, there is no reservation size defined, and the space
> between allocations continues to change, depending on the
> remaining free pool available in APNIC.
> 
> However, the "APNIC guidelines for IPv6 allocation and
> assignment requests"[2] stated:
> 
> "In accordance with APNIC's "IPv6 address allocation and
> assignment policy", where possible, subsequent delegations to the
> same resource holder are made from an adjacent address block by
> growing the delegation into the free space remaining, unless
> disaggregated ranges are requested for multiple discrete
> networks."
> 
> So, it is expected that allocation up to /29 is guaranteed for
> consistency with allocations above. Based on the current
> situation, contiguous allocation of /29 can still be accommodated
> even under the sparse allocation mechanism (Current /32
> allocations from the /12 block can grow up to /24 at this stage).
> 
> - After amended HD Ratio (0.94) and base calculation size (/56) was
> introduced (prop-031 and prop-033), to obtain address blocks larger
> than /32 and to request additional address blocks became harder
> especially for small and middle size ISPs.
> 
> - For traffic control purpose, some LIRs announce address blocks
> longer than /32 (e.g. /35). However, some ISPs may set filters to
> block address size longer than /32 since some filtering
> guidelines recommend to filter longer prefix than /32([3][4]). If
> LIRs have multiple /32, they can announce these blocks and its
> reachability will be better than longer prefix.
> 
> - If an LIR needs address blocks larger than /32, LIRs may tend to
> announce as a single prefix if a /29 is allocated initially at
> once. i.e., total number of announced prefixes in case 1 may be
> smaller than in case 2.
> 
> case 1:
> The LIR obtains /29 at the beginning of IPv6 network construction.
> 
> case 2:
> The LIR obtains /32, and /31, /30 additionally with the subsequent
> allocation mechanism.
> 
> 2. Objective of policy change
> -
> 
> This proposal modifies the eligibility for an organization to
> receive or extend an IPv6 address space up to a /29 (/32 -/29) by
> explaining how the extended space up to /29 will be used.
> 
> 
> 3. Situation in other regions
> -
> 
> RIPE-NCC:
> The policy "Extension of IPv6 /32 to /29 on a per-allocation vs
> per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get
> up to /29 by default.
> 
> 
> 4. Proposed policy solution
> 
> 
> - Change the text to "5.2.2 Minimum initial alloca

[sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size

[Masato Yamanishi]

Dear SIG members

A new version of the proposal “prop-111: Request-based expansion of IPv6
default allocation size has been sent to the Policy SIG for review.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-111

You are encouraged to express your views on the proposal:

 - Do you support or oppose the proposal?
 - Is there anything in the proposal that is not clear?
 - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Andy and Masato


--
prop-111-v003 Request-based expansion of IPv6 default allocation size
--

Author: Tomohiro Fujisaki
fujis...@syce.net


1. Problem statement


IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6
address allocation and assignment policy"[1]. It's better to
expand this minimum allocation size up to /29 (/32 - /29) since:

- Before sparse allocation mechanism implemented in late 2006, /29
was reserved for all /32 allocations by sequential allocation
method made from those old /23 blocks. These reserved blocks
might be kept unused in the future.

- Sparse allocation mechanism was implemented in late 2006 with a
/12 allocation from the IANA. Under the sparse allocation
mechanism, there is no reservation size defined, and the space
between allocations continues to change, depending on the
remaining free pool available in APNIC.

However, the "APNIC guidelines for IPv6 allocation and
assignment requests"[2] stated:

"In accordance with APNIC's "IPv6 address allocation and
assignment policy", where possible, subsequent delegations to the
same resource holder are made from an adjacent address block by
growing the delegation into the free space remaining, unless
disaggregated ranges are requested for multiple discrete
networks."

So, it is expected that allocation up to /29 is guaranteed for
consistency with allocations above. Based on the current
situation, contiguous allocation of /29 can still be accommodated
even under the sparse allocation mechanism (Current /32
allocations from the /12 block can grow up to /24 at this stage).

- After amended HD Ratio (0.94) and base calculation size (/56) was
introduced (prop-031 and prop-033), to obtain address blocks larger
than /32 and to request additional address blocks became harder
especially for small and middle size ISPs.

- For traffic control purpose, some LIRs announce address blocks
longer than /32 (e.g. /35). However, some ISPs may set filters to
block address size longer than /32 since some filtering
guidelines recommend to filter longer prefix than /32([3][4]). If
LIRs have multiple /32, they can announce these blocks and its
reachability will be better than longer prefix.

- If an LIR needs address blocks larger than /32, LIRs may tend to
announce as a single prefix if a /29 is allocated initially at
once. i.e., total number of announced prefixes in case 1 may be
smaller than in case 2.

case 1:
The LIR obtains /29 at the beginning of IPv6 network construction.

case 2:
The LIR obtains /32, and /31, /30 additionally with the subsequent
allocation mechanism.

2. Objective of policy change
-

This proposal modifies the eligibility for an organization to
receive or extend an IPv6 address space up to a /29 (/32 -/29) by
explaining how the extended space up to /29 will be used.


3. Situation in other regions
-

RIPE-NCC:
The policy "Extension of IPv6 /32 to /29 on a per-allocation vs
per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get
up to /29 by default.


4. Proposed policy solution


- Change the text to "5.2.2 Minimum initial allocation size" of
current policy document as below:

Organizations that meet the initial allocation criteria are
eligible to receive an initial allocation of /32. The organizations
can receive up to /29 by providing utilization information of the whole
address space.

- Add following text in the policy document:

for Existing IPv6 address space holders

LIRs that hold one or more IPv6 allocations are able to request
extension of each of these allocations up to a /29 without meeting
the utilization rate for subsequent allocation by explaining
how the whole address space will be used.


5. Explain the advantages of the proposal
-

- It is possible to utilize address blocks which is potentially
  unused into the future.

- Organizations can design their IPv6 networks more flexibly.

- It will be possible for LIRs to control traffic easier.


6. Explain the disadvantages of the proposal


Some people may argue this will lead to inefficient utilization of
IPv6 space since LIRs can obtain huge address size unnecessarily.
How

[sig-policy] Call for Proposal deadline Friday, 8 August 201

[Masato Yamanishi]

Dear Colleagues,

This is a reminder that for policy proposals to be considered for
consensus at the APNIC 38 OPM in Brisbane Australia, policy proposals
must be submitted within the next two weeks.

This is a final reminder to submit Policy Proposals for APNIC 38. The
deadline for submissions is:

Friday 8 August 2014.

Only proposals submitted by this date will be discussed at the APNIC 38
Policy SIG.

Please note that this date is now 2 weeks away.

Regards,

Andy, Masato
APNIC Policy SIG Chairs


How to submit your Policy Proposal
-

There are two ways to submit a policy proposal to the Policy SIG Chairs:

1. Use the online form at:
   http://www.apnic.net/community/policy/proposals/submit

2. Send your proposal in TEXT format to .
   http://www.apnic.net/community/policy/process/proposal_template.txt

If you are unsure of the solution to your policy issue, whether your
policy idea has merit, or if it is covered by existing policy, you are
encouraged to complete only the Problem Statement part of your proposal.
The community can then assist in developing the best solution.


More information
-

Learn more about the APNIC 38 OPM:

http://conference.apnic.net/38/policy

How to participate in policy discussions:

http://www.apnic.net/community/policy/process/how-to-participate

APNIC's PDP is explained at:

http://www.apnic.net/community/policy/process

View current and past policy proposals at:

http://www.apnic.net/policy/proposals


We look forward to and encourage your participation in the APNIC PDP.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] FW: [apnic-talk] Demonstrated Need Transfers - Seeking Opinions

[Masato Yamanishi]

All,

Sorry duplicate copy, but let me share it as I believe it is helpful for
understanding current situation about demonstration needs in Inter-RIR
transfer.

Rgs,
Masato Yamanishi
APNIC Policy SIG Co-chair


On 14/06/06 15:35, "Masato Yamanishi"  wrote:

> Elvis and all,
> 
> Sorry for late reply, but I had a chance to talk with some of ARIN AC members
> and ARIN staff, so let me share their feedbacks.
> 
> 1. It is ARIN staffs' responsibility to show the implications of current ARIN
> policy and they think current proposed idea on apnic-talk,
>  which removes DN only from Intra-RIR transfer, is not compatible with
> ARIN transfer policy as it is,
>  since ARIN requires DN for both of Inter and Intra RIR transfer case.
> 
> 2. Even if ARIN staff would think it is compatible, ARIN community may raise a
> issue that it can be used to milk ARIN's remaining pool.
>  So, adding more restrictions for Intra-RIR transfer of address spaces
> which were transferred from other RIRs (e.g. DN requirement, 12months
> restriction)
>  may be helpful to relax their concern.
> 
> 3. ARIN's concern for milking is applicable only before the exhaustion of
> their remaining pool and it is expected to happen
>  at the end of this year or the beginning of next year. So, we may see
> different discussion after that.
> 
> I hope it helps your understanding and discussion.
> 
> Rgs,
> Masato Yamanishi
> 
> 
> On 14/06/04 7:39, "Elvis Velea"  wrote:
> 
>>   
>>  Hi Masato,
>>  
>>  I was really hoping that someone from ARIN will respond to either my e-mail
>> or yours.
>>  
>>  Anyway, while we are waiting for them to respond, I would like to notify the
>> community on the latest developments in the RIPE region.
>>  
>>  As mentioned in my previous message, 2012-02 has been withdrawn and Sandra
>> Brown has sent a new policy proposal to the RIPE community, 2014-05. This
>> policy proposal enables Inter-RIR transfers between the RIPE region and the
>> other regions with active Inter-RIR transfer policies (ARIN and APNIC for
>> now).
>>  
>>  I already talked to Sandra during the previous RIPE Meeting and discussed
>> the possible ways forward for what is now known as 2014-05.  While Sandra is
>> supposed to be our competition :-) I would nevertheless like to acknowledge
>> the great work she has done for 2014-05 and would like to invite her to
>> (maybe) send the same or a very similar policy proposal in the APNIC region
>> as well. If she does not have time for it, I would like to come up with a
>> similar proposal in the APNIC region to be discussed before and during the
>> meeting in Brisbane.
>>  Basically, her proposal is asking the RIPE NCC to create an operational
>> procedure and work with the other RIRs to allow Inter-RIR transfers. (if
>> incoming transfers to the RIPE region from ARIN/APNIC will require need based
>> justification, the RIPE NCC will request it's member/LIR to provide the
>> justification).
>>  
>>  As far as I have seen and heard from various people in this community, DN
>> for post-exhaustion has already been removed once and only added because ARIN
>> had it in their policy. If we work on a new policy proposal, maybe we can
>> remove DN for everything else but ARIN incoming IPs (for as long as ARIN will
>> keep DN in their policy) and still be compatible with RIPE and ARIN policies
>> regarding Inter-RIR transfers.
>>  
>>  Kind regards,
>>  Elvis
>>  
>>   
>> On 28/05/14 09:01, Masato Yamanishi wrote:
>>  
>>  
>>>  
>>>  
>>>  
>>> Elvis and All,
>>>  
>>> 
>>>  
>>>  
>>> Regarding inter-RIR transfer with ARIN, Sec 8.4 of ARIN NRPM says,
>>>  
>>> 
>>>  
>>>  
>>> 8.4. Inter-RIR Transfers to Specified Recipients
>>>  
>>>  
>>> 
>>> Inter-regional transfers may take place only via RIRs who agree to the
>>> transfer and share reciprocal, compatible, needs-based policies.
>>>  
>>>  
>>> 
>>>  
>>>  
>>> So, it means APNIC policy should be accepted as "reciprocal, compatible,
>>> needs-based policies" by ARIN community
>>>  
>>> to keep Inter-RIR transfer between ARIN and APNIC.
>>>  
>>> 
>>>  
>>>  
>>> 
>>>  
>>>  
>>>> > The policy proposal would remove DN for transfers between APNIC members.
>>>> Basically, no DN for Intra-RIR transfers 

Re: [sig-policy] RIPE Policy Text for Inter-RIR Transfers - 2014-05

[Masato Yamanishi]

Skeeve,

> I don't agree at all.  There may be many who might have an opinion on this
policy but do not follow RIR policy proposals.  I brought it here because it has
an effect on the APNIC region and people may provide a local context and opinion
which I or others may take back to the RIPE list.

If so, can you express this intension when you originally posted, instead of
just copying the URL?

I think many people misunderstood that you are proposing same policy in
APNIC also.

Rgs,
Masato Yamanishi
APNIC Policy SIG Co-Chair



On 14/06/05 14:43, "Skeeve Stevens"  wrote:

> 
> On Fri, Jun 6, 2014 at 3:37 AM, Sander Steffann  wrote:
>> Hi John,
>> 
>> Op 5 jun. 2014, om 16:54 heeft John Curran  het volgende
>> geschreven:
>> 
>>> > On Jun 5, 2014, at 7:24 AM, Skeeve Stevens 
>>> wrote:
>>> >
>>>> >> Here is the policy text being proposed in RIPE for Inter-RIR Transfers -
>>>> 2014-05
>>>> >>
>>>> >> https://www.ripe.net/ripe/policies/proposals/2014-05
>> 
>> I think this policy should be discussed on the RIPE address policy mailing
>> list. Feedback in other places does not have much effect ;)  CC'ing APWG now.
>> 
> 
>  Sander,
> 
> I don't agree at all.  There may be many who might have an opinion on this
> policy but do not follow RIR policy proposals.  I brought it here because it
> has an effect on the APNIC region and people may provide a local context and
> opinion which I or others may take back to the RIPE list.
> 
> Any discussion is good, no matter where it takes place.
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com ; www.v4now.com <http://www.v4now.com/>
> 
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/v4now <http://facebook.com/v4now>  ;
> <http://twitter.com/networkceoau> linkedin.com/in/skeeve
> <http://linkedin.com/in/skeeve>
> 
> twitter.com/theispguy <http://twitter.com/theispguy>  ; blog:
> www.theispguy.com <http://www.theispguy.com/>
> 
> 
> IP Address Brokering - Introducing sellers and buyers
> 
> *  sig-policy:  APNIC SIG on resource management policy
> * ___ sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy


*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] APNIC 38 Policy Proposal Deadline 8 August 2014

[Masato Yamanishi]

Dear Colleagues,

APNIC policies are determined by an open, established, and bottom-up
consensus Policy Development Process (PDP). Anybody can propose a policy
change, participate in the discussion of proposed changes, and express
their support or objection for any proposal.

This PDP begins when somebody submits a Policy Proposal, or a problem
statement to the APNIC Policy SIG Chairs. Once considered and accepted
by the SIG Chairs, the proposal must be posted to Policy SIG mailing
list at least four weeks before the APNIC 38 Policy SIG meeting in
Brisbane, Australia on Thursday, 18 September 2014.

To be considered for consensus at the APNIC 38 OPM, policy proposals
must be submitted by Friday 8 August 2014.


How to submit your Policy Proposal
-

There are two ways to submit a policy proposal to the Policy SIG Chairs:

1. Use the online form at:
   http://www.apnic.net/community/policy/proposals/submit

2. Send your proposal in TEXT format to .
   http://www.apnic.net/community/policy/process/proposal_template.txt

If you are unsure of the solution to your policy issue, whether your
policy idea has merit, or if it is covered by existing policy, you are
encouraged to complete only the Problem Statement part of your proposal.
The community can then assist in developing the best solution.


More information
-

Learn more about the APNIC 38 OPM:

http://conference.apnic.net/38/policy

How to participate in policy discussions:

http://www.apnic.net/community/policy/process/how-to-participate

APNIC's PDP is explained at:

http://www.apnic.net/community/policy/process

View current and past policy proposals at:

http://www.apnic.net/policy/proposals


We look forward to and encourage your participation in the APNIC PDP.


APNIC Policy SIG Chairs

Andy and Masato



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Consensus Measurement

[Masato Yamanishi]

Izumi and All,

Let me add one more point.

Since the consensus is vital part of our PDP, don't we need to describe it
in PDP document, not in SIG guideline?

Rgs,
Masato




On 14/05/27 21:06, "Izumi Okutani"  wrote:

>Yamanishi-san, all,
>
>
>Thanks for your feedback Yamanishi-san.
>
>Describing consensus more clearly - I am happy to work on it. Since
>there is already an IETF document, we can perhaps use it as the basis
>rather than defining from scratch?
>
>Clarifying who expressesd what opinion
>> However, since it is specific issue for e-consensus, we can discuss this
>> point more during the trial.
>
>Sure. I think credibility of what is expressed through e-consensus is
>important when it is not visible to others. If this can be ensured, I am
>open to hear other ideas.
>
>
>Izumi
>
>(2014/05/28 12:21), Masato Yamanishi wrote:
>> Izumi and All,
>> 
>> Sorry for late reply.
>> 
>>> 1) When there is a big difference in discussions and positions
>>> expressed by e-consensus, Chair/Co-Chair will not only judge based
>>> on e-consensus (which is what we do today)
>> 
>> I can confirm it, but please also see my comments for next point.
>> 
>> 
>>> 2) Describe consensus more explicitly than we do today both during
>>> Policy SIG and on Policy Development Website
>> 
>> I think these points are not only for e-consensus but also applicable
>>for
>> current "show of hands"
>> since your have a concern about a description of "consensus" itself.
>> 
>> As of today, what we have as written text is only Section 5.1 in SIG
>> guideline,
>> 
>>(https://www.apnic.net/community/participate/join-discussions/sigs/sig-gu
>>id
>> elines.pdf).
>> 
>> It says;
>> 
>>  The show of hands is not a vote. It is a way of broadly gauging
>> opinion.
>> 
>> and also;
>> 
>>  If there are objections, the Chair can ask the dissenters to
>>decide if
>> their objections are:
>> 
>>  i. Minor objections
>> If the proposal goes forward, the dissenters believe that some
>> problems may occur for some members in the group.
>> The participants should work together to see if the proposal
>>can be
>> modified to overcome these minor objections.
>> However, it is not always possible to overcome these
>>objections. If
>> this is the case, the Chair should ask the dissenters
>> if they are prepared to acknowledge that the overall advantages
>>of
>> the proposal outweigh their objections
>> and if the dissenters are willing to stand aside.
>> 
>>  ii. Major objections
>> If the proposal goes forward, the dissenters believe that major
>> problems will occur for parts of the community
>> and that the proposal cannot be adopted in its current format.
>> 
>>  The Chair should devote sufficient time for participants to discuss
>> ways to overcome major objections.
>>  As in the case of minor objections, participants, including the
>> proponent, should work together
>>  to develop solutions that overcome the objections.
>> 
>> 
>> I am doubt current description is enough, but Chairs cannot add or
>>modify
>> SIG guideline by the sole discretion.
>> So, can you or somebody suggest better description if we will set a
>> community consultation in next meeting?
>> 
>> 
>>> 2) Ensure ways to confirm who expressed what opinion, in case there is
>>> big difference in what was discussed and expression of position
>>> through e-consensus
>>> (if this can be done by registration and chair/co-chair can follow
>>> up if necessary, that is fine)
>> 
>> Under current PDP and SIG guideline, I'm not sure Chairs nor the
>> Secretariat have an authority to investigate
>> each community member's favor even if it was expressed anonymously.
>> And also, I'm afraid some community members may not want to give such
>> authority to Chairs nor the Secretariat.
>> However, since it is specific issue for e-consensus, we can discuss this
>> point more during the trial.
>> 
>> Rgs,
>> Masato
>> 
>> 
>> 
>> 
>> 
>> On 14/05/23 4:16, "Izumi Okutani"  wrote:
>> 
>>> Hi all,
>>>
>>>
>>> Thanks to everyone who shared their thoughts. It's helpful to know
>>>there
>>> are a few others who share the same concern.
>>>
>>> I th

Re: [sig-policy] Consensus Measurement

[Masato Yamanishi]

Randy and Dean,



On 14/05/21 1:22, "Randy Bush"  wrote:

>> And even if today's chairs are able to use it as a single input into
>> their decision making process, I think that it maybe too tempting a
>> fall back for future chairs.
>
>$100 says that we will be voting within five years


IMO, another problem is the consensus and Chairs' decision making process
are not well described in SIG guideline
(and almost nothing in PDP), so Chairs have too much flexibility when
making decision.
I think 100% fixed rule is not appropriate for our community, but do you
have any idea to improve current description?

Rgs,
Masato Yamanishi
APNIC Policy SIG Co-Chair


>
>this is a bad path
>
>randy
>*  sig-policy:  APNIC SIG on resource management policy
>*
>___
>sig-policy mailing list
>sig-policy@lists.apnic.net
>http://mailman.apnic.net/mailman/listinfo/sig-policy


*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Consensus Measurement

[Masato Yamanishi]

Izumi and All,

Sorry for late reply.

> 1) When there is a big difference in discussions and positions
> expressed by e-consensus, Chair/Co-Chair will not only judge based
> on e-consensus (which is what we do today)

I can confirm it, but please also see my comments for next point.


> 2) Describe consensus more explicitly than we do today both during
> Policy SIG and on Policy Development Website

I think these points are not only for e-consensus but also applicable for
current "show of hands"
since your have a concern about a description of "consensus" itself.

As of today, what we have as written text is only Section 5.1 in SIG
guideline,
(https://www.apnic.net/community/participate/join-discussions/sigs/sig-guid
elines.pdf).

It says;

The show of hands is not a vote. It is a way of broadly gauging
opinion.

and also;

If there are objections, the Chair can ask the dissenters to decide if
their objections are:

i. Minor objections
   If the proposal goes forward, the dissenters believe that some
problems may occur for some members in the group.
   The participants should work together to see if the proposal can be
modified to overcome these minor objections.
   However, it is not always possible to overcome these objections. If
this is the case, the Chair should ask the dissenters
   if they are prepared to acknowledge that the overall advantages of
the proposal outweigh their objections
   and if the dissenters are willing to stand aside.

ii. Major objections
   If the proposal goes forward, the dissenters believe that major
problems will occur for parts of the community
   and that the proposal cannot be adopted in its current format.

The Chair should devote sufficient time for participants to discuss
ways to overcome major objections.
As in the case of minor objections, participants, including the
proponent, should work together
to develop solutions that overcome the objections.


I am doubt current description is enough, but Chairs cannot add or modify
SIG guideline by the sole discretion.
So, can you or somebody suggest better description if we will set a
community consultation in next meeting?


> 2) Ensure ways to confirm who expressed what opinion, in case there is
> big difference in what was discussed and expression of position
> through e-consensus
> (if this can be done by registration and chair/co-chair can follow
> up if necessary, that is fine)

Under current PDP and SIG guideline, I'm not sure Chairs nor the
Secretariat have an authority to investigate
each community member's favor even if it was expressed anonymously.
And also, I'm afraid some community members may not want to give such
authority to Chairs nor the Secretariat.
However, since it is specific issue for e-consensus, we can discuss this
point more during the trial.

Rgs,
Masato





On 14/05/23 4:16, "Izumi Okutani"  wrote:

>Hi all,
>
>
>Thanks to everyone who shared their thoughts. It's helpful to know there
>are a few others who share the same concern.
>
>I think this can actually be addressed by what I suggested.
>
>In general, I think this is a good initiative to support wider
>participation in the process, with also helping the Chair to get the
>sense of room in the course of the discussions.
>
>I also agree this is just one method on how to get a fee of the people
>and doesn't change to overall process nor meaning of the consensus.
>Show of hands/humming.e-cosensus, whatever we use, as long as it's
>clearly explained how they will be taken into account in the context of
>consensus buidling, it doesn't really matter what tool we use.
>
>
>So Andy/Masato, if you could confirm below, it would clear my concerns:
>
> 1) When there is a big difference in discussions and positions
>expressed by e-consensus, Chair/Co-Chair will not only judge based
>on e-consensus (which is what we do today)
>
> 2) Describe consensus more explicitly than we do today both during
>Policy SIG and on Policy Development Website
>
> 2) Ensure ways to confirm who expressed what opinion, in case there is
>big difference in what was discussed and expression of position
>through e-consensus
>(if this can be done by registration and chair/co-chair can follow
> up if necessary, that is fine)
>
>
>I trust they will addressed be from reading between the lines of your
>e-mails but it is still helpful to have a clear message and confirmation.
>
>I am happy to support trying this for the next meeting if it is clear
>and confirmed they will be addressed.Thanks!
>
>
>Izumi
>
>(2014/05/21 17:41), Andy Linton wrote:
>> On Wed, May 21, 2014 at 7:13 AM, Skeeve Stevens 
>>wrote:
>> 
>>> All,
>>>
>>> I support Izumi in this concern.
>>>
>>> I agree that electronic measurement is a good idea... BUT, yes, people
>>> will think it is a vote.  If the Chairs go against this 'vote', people
>>>will
>>> get grumpy and there will be all sorts of issues... especially when a
>>>vote
>>> is 

Re: [sig-policy] Consensus Measurement

[Masato Yamanishi]

Izumi,

Sorry, I forgot to answer one of your questions.

>Would the next Policy SIG totally be based on button pressing including
>those at the venue?

Yes, we plan to ask by e-consensus system for both of physical
participants and remote participants.
However, we also use traditional way (showing hands for physical
participants and chat for remote participants)
as I mentioned in previous e-mail.

Also, it is not just "pressing button".
It will have more flexible questions and choices as we are doing in
traditional way.


Rgs,
Masato Yamanishi
Policy SIG co-chair



On 14/05/19 19:52, "Masato Yamanishi"  wrote:

>Izumi,
>
>Thank you for raising your concern.
>
>I'm afraid many of your concerns come from misunderstanding,
>let me clarify current Chairs' understanding for the e-consensus system.
>
>1. As same as traditional "showing hands", it is one of factors when
>deciding the consensus
> As we did in past, Chairs will also consider,
>  - Discussion on the mailing list
>  - Discussion in the meeting
> Also, Chairs may ask the reason if there are some oppositions, and
>consider those reasons
> when deciding the consensus.
>
>2. The questions and choices are configurable on demand
> It is NOT binary (nor ternary) choice. Normally, we present 5
>choices, which are
> Strongly support/Support/Neutral/Oppose/Strongly Oppose, but actually
>the question and options
> are configurable on demand. So, chairs may set additional questions,
>like
> "if this point is modified, what do you think?", or "which do you
>prefer original one or modified one?",
> or add more options, like "I can't live with (or without) this".
> And these changes can be made during the session as we did in past
>"showing hands".
>
>3. It is NOT voting
> As mentioned above, it is just one of factors in deciding the
>consensus while voting is final result.
> Also, the Secretariat and Chairs are trying to find good way to show
>the results
> since showing the numbers is not good idea apparently.
>
>4. Registration is required
> While current chat system doesn't require any registration, this
>e-consensus will require registration.
> However, we need to consider the level of verification during
>registration,
> since strict verification may have negative impact for our openness.
>
>
>5. Next few meetings will be a trial
> Chairs will ask the consensus by both ways (showing hands and
>e-consensus system),
> and compare results to measure its advantage and disadvantage, in
>particular following aspects.
>   - Does the number of participants increase or decrease?
>   - Does the e-consensus system show same results as traditional
>"showing hands" or different?
>   - Does the anonymousness of e-consensus system have negative impact
>for further discussion?
>   - Is it possible to cheat easily?
>
>Also, please consider that current chat system may not be enough as a tool
>asking consensus to remote participants.
>When we had remote hubs, we normally saw 20-30 remote participants and
>many of them participated in the consensus.
>However, now we are seeing just 1 or 2 support or opposition through the
>chat in last few meetings.
>
>It is very appreciated if you could share any idea or thoughts to improve
>it.
>
>Rgs,
>Masato Yamanishi
>Policy SIG co-chair
>
>
>
>
>On 14/05/15 8:35, "Izumi Okutani"  wrote:
>
>>Hi all,
>>
>>
>>I have a few comments about the idea discussed in Policy SIG at APNIC37
>>about replacing show of hands with pressing buttons online.
>>
>>Consensus Measurement
>>https://conference.apnic.net/data/37/community-consultation-on-consensus-
>>m
>>easurement_1393475895.pdf
>>
>>These are the points I discussed with my colleagues in JPNIC and
>>would be interested to hear from the Secretariat, Chair/Co-Chair and
>>others on this list.
>>
>>
>>* Support the motivation of encouraging more participation from remote
>>participants.
>>
>>* On the other hand, we have some concerns as below:
>>
>>  - Less transparency in the process
>>  - Consensus is not voting but pressing buttons but may encourage
>>misunderstanding
>>  - Anonymous voting may allow multiple voting per person
>>
>>* Suggestions:
>>  - Ensure Chair/Co-Chair will not only make decisions based on button
>>pressed results but consider the contents of discussions in making
>>consensus decisions. (As it is today)
>>
>>  - Clearly explain the above, and press

Re: [sig-policy] Consensus Measurement

[Masato Yamanishi]

Izumi,

Thank you for raising your concern.

I'm afraid many of your concerns come from misunderstanding,
let me clarify current Chairs' understanding for the e-consensus system.

1. As same as traditional "showing hands", it is one of factors when
deciding the consensus
 As we did in past, Chairs will also consider,
  - Discussion on the mailing list
  - Discussion in the meeting
 Also, Chairs may ask the reason if there are some oppositions, and
consider those reasons
 when deciding the consensus.

2. The questions and choices are configurable on demand
 It is NOT binary (nor ternary) choice. Normally, we present 5
choices, which are
 Strongly support/Support/Neutral/Oppose/Strongly Oppose, but actually
the question and options
 are configurable on demand. So, chairs may set additional questions,
like
 "if this point is modified, what do you think?", or "which do you
prefer original one or modified one?",
 or add more options, like "I can't live with (or without) this".
 And these changes can be made during the session as we did in past
"showing hands".

3. It is NOT voting
 As mentioned above, it is just one of factors in deciding the
consensus while voting is final result.
 Also, the Secretariat and Chairs are trying to find good way to show
the results
 since showing the numbers is not good idea apparently.

4. Registration is required
 While current chat system doesn't require any registration, this
e-consensus will require registration.
 However, we need to consider the level of verification during
registration,
 since strict verification may have negative impact for our openness.


5. Next few meetings will be a trial
 Chairs will ask the consensus by both ways (showing hands and
e-consensus system),
 and compare results to measure its advantage and disadvantage, in
particular following aspects.
   - Does the number of participants increase or decrease?
   - Does the e-consensus system show same results as traditional
"showing hands" or different?
   - Does the anonymousness of e-consensus system have negative impact
for further discussion?
   - Is it possible to cheat easily?

Also, please consider that current chat system may not be enough as a tool
asking consensus to remote participants.
When we had remote hubs, we normally saw 20-30 remote participants and
many of them participated in the consensus.
However, now we are seeing just 1 or 2 support or opposition through the
chat in last few meetings.

It is very appreciated if you could share any idea or thoughts to improve
it.

Rgs,
Masato Yamanishi
Policy SIG co-chair




On 14/05/15 8:35, "Izumi Okutani"  wrote:

>Hi all,
>
>
>I have a few comments about the idea discussed in Policy SIG at APNIC37
>about replacing show of hands with pressing buttons online.
>
>Consensus Measurement
>https://conference.apnic.net/data/37/community-consultation-on-consensus-m
>easurement_1393475895.pdf
>
>These are the points I discussed with my colleagues in JPNIC and
>would be interested to hear from the Secretariat, Chair/Co-Chair and
>others on this list.
>
>
>* Support the motivation of encouraging more participation from remote
>participants.
>
>* On the other hand, we have some concerns as below:
>
>  - Less transparency in the process
>  - Consensus is not voting but pressing buttons but may encourage
>misunderstanding
>  - Anonymous voting may allow multiple voting per person
>
>* Suggestions:
>  - Ensure Chair/Co-Chair will not only make decisions based on button
>pressed results but consider the contents of discussions in making
>consensus decisions. (As it is today)
>
>  - Clearly explain the above, and pressing the button is not voting:
>on APNIC's PDP webpage and at Policy SIG by Chair/Co-Chair
>
>  - Identity of who pressed what button must be trackable.
>At least, Chair/Co-Chair and the secretariat should be able to
>identify and track who pressued and expressed what opinion.
>This is to reduce the risk of multiple voting by a single person,
>and allow Chair/Co-Chair to clarify the intention with indivisual(s)
>if necessary.
>
>* Question:
>I heard the secretariat is preparing to try this from the next meeting.
>If this is true, how would this work in APNIC38:
>Would the next Policy SIG totally be based on button pressing including
>those at the venue?
>
>
>Thanks,
>Izumi/JPNIC
>*  sig-policy:  APNIC SIG on resource management policy
>*
>___
>sig-policy mailing list
>sig-policy@lists.apnic.net
>http://mailman.apnic.net/mailman/listinfo/sig-policy


*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure abandoned

[Masato Yamanishi]

Dear colleagues,

Version 2 of prop-110: Designate 1.2.3.0/24 as Anycast to support DNS
Infrastructure, reached consensus at the APNIC 37 Policy SIG, but did
not reach consensus at the APNIC 37 Member Meeting.

The authors have indicated they do not wish to proceed with the
proposal.

With very little indication of strong support for the proposal on this
list, it seems unlikely the current proposal can reach consensus and
will be abandoned.


Proposal details


The objective of this proposal was to permit the use 1.2.3.0/24 as
anycast addresses to be used in context of scoped routing to support the
deployment of DNS resolvers.

Proposal details including the full text of the proposal, history, and
links to mailing list discussions are available at:

   http://www.apnic.net/policy/proposals/prop-110

Regards,

Masato




*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy