[ppml] Policy Porposal 2003-1b
Owen DeLong
owen at delong.com
Tue Mar 25 17:51:15 EST 2003
OK... I've received some really good feedback on 2003-1a. Almost all the
feedback I have received on this version has been positive. The negative
feedback falls into three categories...
1. They seem to support what I intended the policy to say, but they
didn't think the policy said it. Usually this was a perception that
the policy put ARIN in the position of judging abuse and revoking
resources for abuse. I don't think that's appropriate, nor do I
think anyone has come up with a sufficiently concrete definition
of abuse to make that feasible. I attempted to put some guidelines
in for a relatively restrictive definition of abuse to prevent
ARIN from revoking resources if abuse was _NOT_ present. Further,
even if a network is abusing, if they are providing a valid and
usable abuse contact which is reachable, ARIN's job is over, and
the resolution of any dispute should be up to the respective network
owners. ARIN's role ends with facilitating the communication between
the parties.
2. They seem to support the requirements, but they don't think ARIN
should be allowed to revoke resources and they don't feel that any
enforcement provisions should be made. Frankly, in my opinion,
without enforcement provisions, this policy won't accomplish
much. As such, I will keep the provisions in, and if someone
wants to bring an amendment to remove them to a vote at the
policy meeting, that's fine. Otherwise, we'll agree to disagree
and leave the decision to a vote.
3. They believe this policy will create legal expenses beyond ARIN's
capabilities and that the ARIN board will have to reject the
enforcement provisions of this policy to avoid legal complications.
I haven't been able to get any advice from ARIN on that issue, but
I hope something will be forthcoming soon. It is my hope that since
ARIN will only be revoking resources as a result of failure to meet
a contractual obligation to keep current functional contact
information available, the anticipated legal hassles would be
minimal. I am hoping that ARIN's legal staff and board will concur.
That having been said, below is the revised 2003-1b to attempt to clarify
the
issues raised by groups 1 and 3. I hope that the people in group 2 will
realize that all I am attempting to enforce is a requirement for responsive
abuse contacts and come to support that.
I will be at the meeting in Memphis. In order to provide people a
fair opportunity to review the policy prior to the meeting, this will
be the last revision. This version will be presented at the meeting.
(I may make syntactic or typographical corrections prior to the
meeting if they come to my attention). There seems to be pretty good
consensus around 2003-1a, and this only represents minor changes to that
version. I received approximately three times as many positive comments
as I did negative comments. Of the negative comments, 2/3's of them
fell into group 1. Only one person fell into group 3. There were two
people in group 2.
>> Came from 2003-1
> Came from 2003-1a
New for 2003-1b
>>
> Policy Proposal 2003-1a: Required Performance of Abuse Contact
>>
>> 1. Statement of proposed Policy:
>>
> For the purposes of this policy, the following terms shall apply:
>
> ORG An organization or organizational unit which receives one or more
> resources from ARIN, whether by allocation or assignment. In either
> case, the ORG in question shall bear full responsibility under
> this policy for meeting the requirements thereof and bearing
> any consequences of failure to meet said responsibilities.
>
> This shall apply to the ORG to which ARIN directly allocated the
> resource, or to another ORG, which, has received from the previous
> ORG a transfer of the resources under ARIN's transfer policies.
> A simply SWIP of an assignment to an ORG which does not have
> a contractual relationship with ARIN shall not constitute such
> a transfer.
>
> MAINTAINER
> The appointed POC units which have authority and access to make
> changes to the ARIN held data regarding a resource owned by a
> particular ORG.
>
> POC A point of contact, whether human or role.
>
> ABUSE CONTACT
> This policy makes no effort to define Abuse. It is the opinion
> of the author of this policy that such a definition should come
> from the IETF and not from ARIN. It is the intent of this policy
> to set standards for the response required from an abuse contact
> without addressing the actions required by said contact. Again,
> it is the opinion of the author that said actions are outside
> of ARIN's scope and belong within the IETF.
>
> An ABUSE contact is a POC for an ORG which is associated with an
> ARIN issued resource as the POC responsible for addressing issues
> of abuse originating at or from the resource in question.
>
> RESOURCE
> In the case of ARIN, resources currently include ASNs and IPv4
> and IPv6 address ranges which are allocated or assigned to
> registered ORGs.
>
> ASN An autonomous system number
>
> IPv4 Internet Protocol Version 4
>
> IPv6 Internet Protocol Version 6
>
> Proposed Policy
>
> For any given RESOURCE in the ARIN database, ARIN shall require at least
> one and allow multiple ABUSE CONTACTS to be listed. For at least one
> ABUSE CONTACT in each resource, ARIN shall require and maintain at least
> the following information:
>
> 1. Individual or Role
>
> 2. If Individual, full name
>
> 3. Address valid for Legal Service
> Must support physical delivery, registered mail, or both,
> and shall indicate which is acceptable.
>
> 4. Email Address.
>
> 5. A list of "normal business hours" specified in terms of the
> time zone applicable to the address in item 3 or in UTC, with
> an indication of whether DST should be considered. These
> hours should comprise at least 30 hours per week.
>
> 6. A phone number
>
> 7. A URL where the ORG maintains a web site listing it's ABUSE
> POLICIES.
>
> Each ORG shall be required to meet the following standards with respect
> to the performance and responsiveness of the required ABUSE CONTACT,
> and each ABUSE CONTACT which contains all of the data specified above.
> In cases where the language cannot be logically applied to a ROLE account,
> it shall mean all individuals assigned by the ORG in question to read the
> email or answer the phone calls to the addresses/numbers listed in the
> ABUSE CONTACT.
>
> 1. With the exception of sudden events of large call volume,
> shall staff adequately to have live humans answer calls
> to the listed abuse contact phone number during the hours
> indicated in the contact record.
>
> 2. Shall have a human being read and respond to abuse complaints
> received by email within 48 hours of receipt (for complaints
> received Sun-Thu), and, within 96 hours for complaints
> received Fri-Sat.
>
> 3. Shall be capable of taking action or immediately contacting
> a person capable of taking action to stop any reported abuse
> which is in violation of any of the following:
>
> A. Any definition of network abuse published by the
> IETF. (This shall not be construed to include any
> minor failure to comply with an RFC, but shall only
> apply to things the IETF has specifically defined as
> abuse).
>
> B. Any definition of network abuse determined by the
> ORG to be abuse in any of their own published AUPs.
>
> C. Any definition of network abuse which meets all of the
> following criteria:
>
> 1. Is defined as abuse in a policy published
> on the complaining networks ABUSE CONTACT
> URL.
>
> 2. Can be defined in terms that would allow most
> routers to block the abuse in question through
> the use of packet filters or other commonly
> available technology.
>
> (Commonly available technology for this purpose
> means a feature that is present and can be
> reasonably implemented in the majority of
> backbone router types in use on the Internet
> at the time of complaint.)
>
> 3. Is not a standard response to traffic being
> received from the complaining network.
>
It should be noted that this requirement is for the capability
to take action to be present. It does not require the individual
in question to take the desired action. That matter is between
the parties. The ARIN agreement requires the contact to be
available to respond.
> 4. Shall respond to the complaint as soon as
> practicable with information on what actions are
> being taken to stop the abuse.
>
> Further, if an entity believes an ORG is not living up to the requirements
> set forth in this policy, they should be able to notify ARIN of the issue,
> including detailed documentation of the efforts made to contact the ORG
> and the results thereof. Any complaint received by ARIN which does not
> include the required information should receive only a form-reply from
> ARIN indicating what information is required to verify the complaint.
>
> In the event of a valid complaint, ARIN shall attempt to contact the ORG
> in question and notify them of the complaint. If ARIN is able to contact
> the ORG in question, ARIN should wait two weeks and contact the
> complainant. If the complainant is satisfied, no further action is
> required by ARIN. If the complainant is not satisfied, ARIN staff shall
> make a determination whether the complaint meets the definitions of abuse
> in 3 above. Further, the ARIN staff shall make a determination if the
> response and actions taken by the ORG in question meet the requirements
> of the policy.
> If the ARIN staff determines that the complaint meets the
> requirements and that the response of the ORG in question has not met the
> requirements of this policy, the ARIN staff shall inform the ORG of these
> facts, specifically indicating what additional response and/or action is
> necessary to comply. The ORG shall then have 5 business days or a longer
> reasonable time as determined by the ARIN staff to comply. If the ORG
> remains out of compliance, then the ARIN staff shall revoke each and
> every specific resource listed in the complaint and determined to be out
> of compliance with this policy.
>
> If a resource is revoked under this policy, it shall be referred to the
> ARIN ABUSE COUNCIL for final determination. The ORG in question shall
> have 30 days to present their side of the issue to the council in written
> form via email. The ORG in question may at any time prior to the 30 days
> indicate that they have submitted all desired information and terminate
> the 30 day period 24 hours after sending that email. After the 30 days
> has expired or the ORG has terminated the 30 day period as described,
> the ABUSE COUNCIL shall have 10 days to make a final determination on
> the revocation. The ABUSE COUNCIL may affirm the revocation, in which
> case, it becomes permanent. The ABUSE COUNCIL may overturn the
> revocation, in which case, the resources are to be immediately returned
> to the ORG in question. The ABUSE COUNCIL may decide to grant the
> ORG in question an extension for compliance. In that case, the council
> shall set a date by which the ORG must comply. The resource(s) will
> be immediately returned to the ORG in question. If, at the date in
> question, the ORG is determined by ARIN staff to still not be in
> compliance, the resources shall again be revoked. The ORG may again
> appeal this decision to the ABUSE COUNCIL as described.
>
> The ARIN BOARD shall nominate candidates to participate in the ABUSE
> COUNCIL. The ABUSE COUNCIL shall have 5 members. Each member shall be
> for a 2 year term. The first time, 3 members shall have 2 year terms, and
> 2 shall have 1 year terms. The ARIN BOARD shall nominate not less than
> two, nor more than three times the number of vacant seats. In the first
> election, the three candidates receiving the most votes shall be elected
> for 2 years. The community at large shall be allowed to vote, similar to
> the ASO AC election process. The election shall be conducted as a "Vote
> for no more than N" where N is the number of available seats (5 the first
> time, 2 the following year, 3 the year after, and so on). The ABUSE
> COUNCIL shall not be required to conduct physical meetings, and there
> shall be no compensation paid to the ABUSE COUNCIL by ARIN.
>
> If a complaint comes up against an ORG to which an ABUSE COUNCIL member
> has ties which could create a conflict of interest, then that members
> place on the ABUSE COUNCIL shall be filled by a member of the ARIN BOARD
> chosen at random with respect to that specific complaint.
>
> The ARIN BOARD shall serve as the ABUSE COUNCIL until such time as one
> can be elected. In no event shall there be less than 30 days from the
> public release of all candidates statements and nominations to the close
> of the voting. The ARIN BOARD shall set the annual election date, and
> shall nominate candidates each year at least 60 days prior to the election
> date. Voting shall be conducted for not less than 30 days leading up to
> the election date.
>
> The ABUSE COUNCIL changes shall take effect 5 days after the election
> date.
>
>
>> 2. Argument for the proposal and general discussion of the issue.
>>
>> Issue:
> When trying to resolve issues of abuse, three things are
> important:
>
> 1. Being able to pass the abuse information along to a
> meaningful contact at the originating ORG.
>
> 2. The originating ORG taking appropriate action to
> stop the abuse.
>
> 3. Meaningful contact from the originating ORG explaining
> what was done.
>
> Many ORGs today have built elaborate automated systems for handling
> abuse complaints. It is not uncommon for these systems to fail to
> meet items 1 and 2 above. It is almost unheard of for them to meet
> item 3. It is time for us to move the Internet beyond the idea that
> the victims of abuse should just have to accept those costs as part
> of being connected. The organizations where abuse originates must
> be required to address abuse originating from resources within their
> responsibility.
This policy primarily addresses items 1 and 3. It is limited in it's
ability
to meet item 2 by the following factors:
+ No clear definition of what constitutes abuse. Although there
is some definition included in this policy, that is intended
to be overly vague and should only be used to exclude acts
which are _NOT_ abuse from triggering revocation.
+ No policy or guidance from IETF or ICANN on abuse
+ The registries have not been assigned an abuse-related role
other than the maintenance of contact information for resources
they allocate.
+ Significant additional controversy in the community regarding
the definition of abuse and who determines the definition of
abuse.
As such, this policy attempts to make a strong first step by addressing
items 1
and 3 as completely as possible, facilitating a better effort towards item 2
by the parties involved.
>
>>
>> Argument in favor:
>> When an automated system fails, it becomes important to be able
>> to reach a human being capable of intervening or contacting
>> an intervener. It is OK if the POC information (address,
>> phone number, etc.) is a work number, or NOC, or even a
>> switchboard, as long as it is a point of contact which leads
>> to a real person with some ability to close the loop. It does
> not have to lead to a specific real person, but it must be possible
> to engage human intervention through this process.
>>
>> Problems:
>
> Most of the objections to the original version of this policy
> represented the need for ROLE accounts and the desire not to
> release personal information. I think this amended proposal
> addresses both of those concerns. Other concerns raised were
> the definition of abuse. While this policy does not define
> abuse, I think it provides decent metrics for determining abuse
> through the IETF and through each networks AUP. Further, it
> shifts the definition of abuse to the perspective of the
> receiving network, allowing each network to define what traffic
> they are willing to accept in a public and accessible manner.
> Further, it avoids overly burdensome definitions of abuse by
> only requiring originating ISPs to take action to stop abuse
> if the policy defines abuse in terms which reasonably allow
> the ISP to configure that definition into their routers to
> prevent the origination of such abuse, and, then, only after
> the abuse has occurred and generated a complaint.
Additionally, it avoids taking any action based on abuse.
It requires both abuse and a failure to meet a contractual
obligation to maintain valid abuse contacts in order for
an ORG to have their resources revoked. Hopefully this
provides a balanced approach to requiring valid contact
information. Given valid contact information, the parties
involved should be able to resolve abuse situations in
good faith. In any case, the RIRs role is limited to
facilitating the contact and they have no involvement
in the actual determination of abuse or it's resolution.
>
>
>> 3. Proposed timetable for implementation:
>>
>> Once this proposal is ratified, ARIN should update it's registration
>> services agreement to reflect the new policy within 30 days. Existing
>> ORG and other bodies should receive notification of the change and the
>> requirement to comply during that same period. They should be required
>> to comply within 90 days of the date the notification is sent to the
>> existing ADMIN-C.
>>
>> After that time has elapsed, ARIN staff should be expected to investigate
>> and take further appropriate action on any complaint received about lack
>> of appropriate ABUSE CONTACT(s) in any resource record.
>>
>> Appropriate action is left to the discretion of the ARIN AC, but should
>> include ARIN staff contacting the ORG in question by any means reasonably
> available to ARIN, and, possibly revoking resources found to be out of
> compliance.
>
>>
More information about the ARIN-PPML
mailing list