Subject: [regext] RDAP preference on abuse reporting

From: Alessandro Vesely <[email-masked]>
Date: Mon, 14 Feb 2022 19:54:12 +0100

Hi,
dunno if this is the right place to ask...

I wrote a small utility to get abuse address(es) via RDAP.[*]  Today someone 
told me that APNIC only has one abuse address, the other address in the same 
vcardArray is not supposed to be used for abuse reporting.  The addresses can 
be discriminated by one having pref=1 and the other no pref.  AFAIK, pref is 
described in Section 5.3 of RFC 6530.  However, it is still not very clear how 
to use it in this particular case.  Which of the following is better for abuse 
reporting:

* When email addresses are ordered by preference use only the most preferred,

*  When email addresses are ordered by preference use all except the least 
preferred, or

* When email addresses are ordered by preference use the upper half of them.

Note that the result is the same in the APNIC case.

Best
Ale
-- 

[*] abuserdap, part of ipqbdb,
http://svn.savannah.gnu.org/viewvc/ipqbdb/trunk/abuserdap.c
see man page at https://savannah.nongnu.org/support/?110246

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 15 Feb 2022 13:28:17 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Alessandro Vesely
> Sent: Monday, February 14, 2022 1:54 PM
> To: [email-masked]
> Subject: [EXTERNAL] [regext] RDAP preference on abuse reporting
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> Hi,
> told me that APNIC only has one abuse address, the other address in the
> same vcardArray is not supposed to be used for abuse reporting.  The
> addresses can be discriminated by one having pref=1 and the other no pref.
> AFAIK, pref is described in Section 5.3 of RFC 6530.  However, it is still 
> not
> very clear how to use it in this particular case.  Which of the following is
> better for abuse
> reporting:
>

[SAH] Could you show us the JSON data structure that you're referring to? 
That'll better help us understand the RDAP response.

Section 5.3 of RFC 6350 doesn't say anything about using only the 
most-preferred address(es). My suggestion with respect to 6350 is that you 
should start with the most preferred address, use the next one if that doesn't 
work, and so on. That suggestion might change depending on what we see in the 
RDAP response.

Scott

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 15 Feb 2022 19:07:57 +0100

Hi,

On Tue 15/Feb/2022 14:28:17 +0100 Hollenbeck, Scott wrote:
>> * When email addresses are ordered by preference use all except the least preferred, or
>>

The example we were talking about is this:
https://rdap.apnic.net/ip/136.185.8.145
which has:

           [
             "email",
             {},
             "text",
             "[email-masked]"
           ],
           [
             "email",
             {
               "pref": "1"
             },
             "text",
             "[email-masked]"
           ]

Compare that with the whois version:
https://wq.apnic.net/static/search.html?query=136.185.8.145
which has a prominent comment:

% Abuse contact for '136.185.0.0 - 136.185.255.255' is [email-masked]'

and afterwards has:

role: ABUSE BHARTITELEMEDIAIN
address: Bharti Airtel Ltd.
country: ZZ
phone: +000000000
e-mail:	[email-masked]
admin-c: NS282-AP
tech-c:	NS282-AP
nic-hdl: AB914-AP
remarks: Generated from irt object IRT-BHARTI-TELEMEDIA-IN
abuse-mailbox: [email-masked]
mnt-by:	APNIC-ABUSE
last-modified:	2020-05-16T21:36:43Z
source:	APNIC

> most-preferred address(es). My suggestion with respect to 6350 is 
> that you should start with the most preferred address, use the next 
> one if that doesn't work, and so on. That suggestion might change 
> depending on what we see in the RDAP response.

The program's intention is to provide an email address for automated abuse reports.  It seems clear to me that the intention of APNIC is to provide the address of the responsible person for human-generated escalated support.  Did they overinterpret RFC 6350?  Or maybe they meant further specify PREF t some point.  I know Byron participated to the discussion.

I just saw now a new draft for JSContact.  However, it neither says whether PREF is to be used to discriminate automatic email messages.

Best
Ale
--

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 15 Feb 2022 18:23:34 +0000

> From: Alessandro Vesely <[email-masked]>
> Sent: Tuesday, February 15, 2022 1:08 PM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: [regext] RDAP preference on abuse reporting
>
> >> I wrote a small utility to get abuse address(es) via RDAP.[*]  Today
> >> someone told me that APNIC only has one abuse address, the other
> >> address in the same vcardArray is not supposed to be used for abuse
> >> reporting.  The addresses can be discriminated by one having pref=1 and
> the other no pref.
> >> AFAIK, pref is described in Section 5.3 of RFC 6530.  However, it is
> >> still not very clear how to use it in this particular case.  Which of
> >> the following is better for abuse
> >> reporting:
> >>
> https://secure-
> web.cisco.com/1c_nTuKekZk59w0wfIpkFx8t1CZeXY4DolMyhNEdZQkD2yjDIh
> mMthVeMz-
> rBuu5WgpYPqXn0DWuJ4dsCRjLePgKCI66KJAwl71aiW7Z3q7QacUWrUq7gckRb
> M-06XhwNaHFdRuJ00sH6BcV-p1xRVfu-qu-mRL9VSOznJJFa037rUvkB0_u9-
> 5niG9Lb8wiQc_OgP7d6i9EMIzCmaaRZbAZp3O2iTSiZ3dSlkn-
> Xt5MMF8AxqGVaN4kiRD__KIDO/https%3A%2F%2Frdap.apnic.net%2Fip%2F
> 136.185.8.145
> which has:
>
>            [
>              "email",
>              {},
>              "text",
>              "[email-masked]"
>            ],
>            [
>              "email",
>              {
>                "pref": "1"
>              },
>              "text",

[SAH] According to what I read in 6350, "[email-masked]" is the 
preferred address and "[email-masked]" is the least preferred address 
because it omits the pref parameter.

> https://secure-web.cisco.com/1ODCHjK8pZn1FEkH787OrWs7-
> 2vqLQE9k1ZPKOwdIBysTqHHGEFIlRmh5NmY5JnNqR5dKowQjFW-TaasRvN-
> BoiIcOekHmuLI6bwcg4fo_3ZZacP1c_JEwvUj6MgbC10Wgeg_fUeT0t4Fi4YHjZp
> hwUJ5YokMF1hf6gUABG7OLmuXGJrMI-
> fC2YwDgGqOS4QD63Flm1kp7IBL4pFAzVFFgZjiQxv7I3MNy7LhjjBFuGBeJT0WI
> wI6mvG11zfBMS7T/https%3A%2F%2Fwq.apnic.net%2Fstatic%2Fsearch.html
> %3Fquery%3D136.185.8.145

[SAH] OK, this is consistent with the RDAP representation.

> last-modified:	2020-05-16T21:36:43Z

[SAH] ...and this could be confusing because WHOIS doesn't include anything to 
indicate priority. As a human reader, though, the comment tells me which 
address is preferred.

> > most-preferred address(es). My suggestion with respect to 6350 is that
> > you should start with the most preferred address, use the next one if
> > that doesn't work, and so on. That suggestion might change depending
> > on what we see in the RDAP response.
>
> The program's intention is to provide an email address for automated abuse
> reports.  It seems clear to me that the intention of APNIC is to provide the
> address of the responsible person for human-generated escalated support.
> Did they overinterpret RFC 6350?  Or maybe they meant further specify PREF
> t some point.  I know Byron participated to the discussion.
>
> I just saw now a new draft for JSContact.  However, it neither says whether
> PREF is to be used to discriminate automatic email messages.

[SAH] I'll leave that point for Mario to address. I don't think ANY of these 
representations include a method to identify an address to received automated 
messages.

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 16 Feb 2022 15:54:01 +0100

Hi Alessandro,

plase see my comments below prefixed with [ML]

Il 15/02/2022 19:23, Hollenbeck, Scott ha scritto:
>> From: Alessandro Vesely<[email-masked]>
>> To: Hollenbeck, Scott<[email-masked]>;[email-masked]
>>>> From: regext<[email-masked]>  On Behalf Of Alessandro Vesely
>>>>
> [SAH] According to what I read in 6350,"[email-masked]"  is the
> preferred address and"[email-masked]"  is the least preferred address

[ML] Agreed. The most preferred address is the one having the pref 
parameter with the lowest value.

So if you want to sort the abuse email addresses by the pref parameter 
the order will be the following:

1) Firstly, the email addresses ordered per the pref parameter from the 
lowest to the highest

2) Then, email addresses without the pref parameter in whatever order 
you want (maybe in the order of appearance)

>> abuse-mailbox:[email-masked]
>> mnt-by:	APNIC-ABUSE

[ML] The PREF parameter in vCard as well as the the "preference" type in 
JSContact have the same meaning:

    A preference value MUST be an integer number in the range 1 and 100.
    Lower values correspond to a higher level of preference, with 1 being
    most preferred.  If no preference is set, then the contact
    information MUST be interpreted as being least preferred.

The meaning is that it can be used to convey an order of preference in a 
collection of objects. That's it.

That said, vCard and JSContact are two representations for contact 
cards. They cannot provide special meaning depending on the context the 
contact card is used in.

If you need something to clearly discriminate an object compared to 
another, you can use value extensions.

For example, in vCard you can use an x-name for the value of the TYPE 
parameter. Similarly, in JSContact you can define a vendor-specific 
value for the Context data type.

If needed, property extensions can also be defined in both the 
representations.

Anyway, in my opinion, this is a matter of RDAP profiles.

APNIC can state in its profile that the abuse email address is only the 
preferred email address (I mean the only one with the pref parameter) in 
the list of email addresses of the contact with the abuse role.

Another registry can opt for providing the list of email address sorted 
by preference, another one can set no preference order at all.

In JSContact, you can conventionally use a given key  to assign a 
special meaning to an entry of the "emails" map. For example, you can 
use the key "abuse-mailbox" to identify the abuse mail address 
regardless the value of the "preference" member.

For what is worth, I would proceed as in the following:

1) If a contact with the abuse role exists:

1.a)  If at least one pref parameter exists, I would return only the 
most preferred email address;

1.b)  If the pref parameter is missing, I would return all the email 
addresses in order of appearance.

2) If a contact with the abuse role is missing, I would return no abuse 
email address

Hope It could be helpful.

Best,

Mario

>
> Scott
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 20 Feb 2022 13:17:21 +0100

On Wed 16/Feb/2022 15:54:01 +0100 Mario Loffredo wrote:
> 1.a)  If at least one pref parameter exists, I would return only the most 
> preferred email address;
> 
> 1.b)  If the pref parameter is missing, I would return all the email addresses 
> in order of appearance.
> 
> 2) If a contact with the abuse role is missing, I would return no abuse email 
> address
> 

Yup, that's an applicable hint.  I'd suggest to publish it as a default profile 
in the next RFC.  (I don't know how to get profiles, let alone parsing them. 
Having a default profile allows to make sense of APNIC's preferences.)

Best
Ale
--

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 21 Feb 2022 08:30:53 +0100

Hi alessandro,

Il 20/02/2022 13:17, Alessandro Vesely ha scritto:
>> 2) If a contact with the abuse role is missing, I would return no 
>> abuse email address
>>
> Yup, that's an applicable hint.  I'd suggest to publish it as a 
> default profile in the next RFC.  (I don't know how to get profiles, 
> let alone parsing them. Having a default profile allows to make sense 
> of APNIC's preferences.)

Don't think this is a matter of an RFC.

What I suggested, it can be valid as a general rule applicable to every 
RDAP respone provided that the server returns a contact with the abuse role.

For example, it can be applied to APNIC's abuse contacts as well as to 
the abuse contacts returned by the gTLDs' RDAP servers according to what 
is stated in Section 2.4.5 of 
https://www.icann.org/en/system/files/files/rdap-response-profile-15feb19-en.pdf

Best,

Mario

Web: http://www.iit.cnr.it/mario.loffredo

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 21 Feb 2022 09:54:56 +0100

Hi Mario,

On Mon 21/Feb/2022 08:30:53 +0100 Mario Loffredo wrote:
>> Yup, that's an applicable hint.  I'd suggest to publish it as a default 
>> profile in the next RFC.  (I don't know how to get profiles, let alone 
>> parsing them. Having a default profile allows to make sense of APNIC's 
>> preferences.)
> 

Why not?

> What I suggested, it can be valid as a general rule applicable to every RDAP 
> response provided that the server returns a contact with the abuse role.

So the missing paragraph about "pref" could be filed as an erratum to RFC7483?

> For example, it can be applied to APNIC's abuse contacts as well as to the 
> abuse contacts returned by the gTLDs' RDAP servers according to what is stated 
> in Section 2.4.5 of 

Apart from that document not mentioning preferences, IMHO it is important that 
"pref" has a standard meaning.  If users need to gather it from specific 
profiles, the very concept of a "grand unified specification"[*] would get cracked.

Best
Ale
-- 

[*] Mentioned in WEIRD's charter
https://datatracker.ietf.org/wg/weirds/about/

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 21 Feb 2022 11:34:14 +0100

Hi Alessandro,

Il 21/02/2022 09:54, Alessandro Vesely ha scritto:
>>>> 1.a)  If at least one pref parameter exists, I would return only 
>>>> the most preferred email address;
>>>>
>>>> 1.b)  If the pref parameter is missing, I would return all the 
>>>> email addresses in order of appearance.
>>>>
>>> let alone parsing them. Having a default profile allows to make 
>>> sense of APNIC's preferences.)
>>

Because, since the pref parameter can be added to many VCARD properties 
that can be included in the RDAP response, what is stated in 
https://datatracker.ietf.org/doc/html/rfc6350#section-5.3 seems enough 
to me.

Special meaning of the pref parameter with regard to the specification 
of the abuse mailbox should be decided by each registry autonomously.

That said, it seems to me that the APNIC's response is not ambiguous as 
it appears clear (at least to me) which is the preferred abuse mailbox.

>
>
>> What I suggested, it can be valid as a general rule applicable to 
>> every RDAP response provided that the server returns a contact with 
>> the abuse role.
>
>
What should such a missing paragraph say beyond what is stated in 
section 5.3 of RFC6350 ?

>> For example, it can be applied to APNIC's abuse contacts as well as 
>> to the abuse contacts returned by the gTLDs' RDAP servers according 
>> to what is stated in Section 2.4.5 of 
> Apart from that document not mentioning preferences, IMHO it is 
> important that "pref" has a standard meaning.  If users need to gather 
> it from specific profiles, the very concept of a "grand unified 
> specification"[*] would get cracked.
>
The "pref" parameter already has a standard meaning defined in RFC 6350.

What I suggested is only an implementation of that general rule in this 
specific case. Nothing else.

Best,

Mario

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 21 Feb 2022 18:25:26 +0100

Hi Mario,

On Mon 21/Feb/2022 11:34:14 +0100 Mario Loffredo wrote:
> Because, since the pref parameter can be added to many VCARD properties that 
> can be included in the RDAP response, what is stated in 
> https://datatracker.ietf.org/doc/html/rfc6350#section-5.3 seems enough to me.
> 
> Special meaning of the pref parameter with regard to the specification of the 
> abuse mailbox should be decided by each registry autonomously.
> 
> That said, it seems to me that the APNIC's response is not ambiguous as it 
> appears clear (at least to me) which is the preferred abuse mailbox.

Yes, having seen that a pref parameter exists, its usage can be inferred.  I 
didn't know about it (and haven't yet fixed the program which extracts it from 
the RDAP response.)

> What should such a missing paragraph say beyond what is stated in section 5.3 
> of RFC6350 ?

Perhaps, the first paragraph of Appendix A.1 could have had an additional 
sentence saying something like so:

     For automated usage, it is recommended that, if preference is specified,
     only the most preferred element be used.

Best
Ale
--

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 22 Feb 2022 08:29:53 +0100

Hi Alessandro,

please find my comment below.

Il 21/02/2022 18:25, Alessandro Vesely ha scritto:
>>>>> default profile in the next RFC.  (I don't know how to get 
>>>>> profiles, let alone parsing them. Having a default profile allows 
>>>>> to make sense of APNIC's preferences.)
>>>>
>> Because, since the pref parameter can be added to many VCARD 
>> properties that can be included in the RDAP response, what is stated 
>> in https://datatracker.ietf.org/doc/html/rfc6350#section-5.3 seems 
>> enough to me.
>>
>> Special meaning of the pref parameter with regard to the 
>> specification of the abuse mailbox should be decided by each registry 
>> autonomously.
>>
>> That said, it seems to me that the APNIC's response is not ambiguous 
>> as it appears clear (at least to me) which is the preferred abuse 
>> mailbox.
>
>
> Yes, having seen that a pref parameter exists, its usage can be 
> inferred.  I didn't know about it (and haven't yet fixed the program 
> which extracts it from the RDAP response.)
>
>
> Perhaps, the first paragraph of Appendix A.1 could have had an 
> additional sentence saying something like so:
>
Sorry but, honestly, I don't see the need for that.

IMO, it would make more sense to recommend servers to specify a 
preference when more instances of the same property are provided.

But specifying a preference is a possible option for the servers to 
convey that a given value is considered the most suitable in a collection.

Therefore, from server side, I would add nothing. As I said in my 
previous mails, additional requirements can be defined by each RDAP profile.

For example, since the proposal of provisioning the abuse mailbox seems 
something accepted by every RIR according to what is described in 
https://www.ripe.net/participate/policies/proposals/2019-04, RIRs can 
agree on a

common way to include it in the RDAP response (maybe they're just doing 
this, please members from RIRs have a voice if you think !)

 From client side, clients can simply make their own decisions based on 
the information returned by the server.

Anyway, I invite the other WG members to manifest their own opinion.

Best,

Mario