Re: [sig-policy] New Version of prop-115-v001: Registration of detailed
Yes, it is what I want to the list.
I wanted to know about this question, is this proposal beyond the scope
of using whois db?
But if it is so, I want to have opinions where is the best place to
discuss and what we can choose for universal common information resource
to check?
Regards,
On 2015/03/03 8:55, David Woodgate wrote:
>
> I do not support this proposal, on the basis that it seems its intent is
> to extend the scope of the APNIC whois database well beyond its
> traditional scope.
>
> I believe the purpose of the APNIC database is to assert the
> authorisation of an assignee to use specified IP addresses, for purposes
> such as route validations or route dispute resolutions. The database
> only relates to the network layer identifiers that APNIC is chartered to
> administrate (i.e. IP addresses and AS numbers).
>
> APNIC does not administrate or register the use of transport-layer
> identifiers (TCP or UDP ports); APNIC does not have the charter to state
> that certain TCP/UDP ports have been duly assigned and provide any
> authority for their use. Also, standard Internet routing does not
> function on the basis of TCP/UDP ports.
>
> I therefore feel that any recording of any TCP/UDP port assignments
> would be outside of the scope of APNIC's business.
>
> Regards,
>
> David Woodgate
>
> On 1/03/2015 11:30 PM, Ajay Kumar wrote:
>> Personally,I don't see any benefit,which community may be getting
>> after accepting this proposal. I don't support this proposal.
>> Regards,
>> Ajai Kumar
>>
>> On 24 February 2015 at 22:41, Owen DeLong <owen at delong dot com
>> <mailto:owen at delong dot com>> 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 <myamanis at gmail dot com
>>> <mailto:myamanis at gmail dot com>> 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 <myamanis at gmail dot com
>>> <mailto:myamanis at gmail dot com>>:
>>>
>>> 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
>>> hiromi at inetcore dot com <mailto:hiromi at inetcore dot com>
>>>
>>> Tomohiro Fujisaki
>>> fujisaki at syce dot net <mailto:fujisaki at syce dot 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 <http://192.0.2.24/32> 1-256 is for
>>> HomeA
>>> 192.0.2.24/32 <http://192.0.2.24/32> 257-511 is
>>> for HomeB
>>>
>>> or 192.0.2.0/24 <http://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 at lists dot apnic dot net <mailto:sig-policy at lists dot apnic dot net>
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>> * sig-policy: APNIC SIG on resource management
>> policy *
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy at lists dot apnic dot net <mailto:sig-policy at lists dot apnic dot net>
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>>
>>
>> * sig-policy: APNIC SIG on resource management policy *
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy at lists dot apnic dot net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
--
===================================
株式会社インテック
先端技術研究所 研究開発部
廣海（ひろみ）緑里