[address-policy-wg] 2023-04 Are anonymised assignment objects valid?

 Colleagues

I know this is a very long email and no one has the time to read it,
but I have at least put my points on record.

This proposal claims to only be about adding a new, optional status
value. It is claimed it doesn't permit anything else that isn't
already possible with the current address policy. In particular it is
claimed you can already have anonymous assignments in the RIPE
Database. Some people do create such objects. The RIPE NCC audits
don't question such objects. But is that right?

There has been so much false and misleading information about this
issue. I am going to have one last attempt to put the record straight.
Then, if no one else cares, why should I? I have a bathroom to
build...

We are talking about one sentence in the current address policy that
this proposal removes. A sentence that is the heart of assignment
policy. The core of the public registry of public IP addresses. An
English sentence that is so clear and obvious, it simply cannot be
misunderstood or (mis)interpreted. And yet I am having to write an
essay to try to explain what this clear sentence means.

"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."

Let me break it down into smaller segments to explain it's meaning:

'End User has a network'   - a network for an End User
'using public address space'   - the address space for the network is
part of the public Internet
'must be'   - MUST, not can, should, may, possibly, perhaps...MUST
'registered separately'   - registered in the RIPE Database in a
separate object, all alone
'contact details'   - information that allows you to make contact with
'of the End User'   - the End User who you want to contact

This sentence only has one possible meaning. And that meaning says you
cannot have an End User assignment in the RIPE Database that does not
allow you to make contact with the End User (subject to the specified
exceptions). This sentence and meaning are so clear it is impossible
to write it any clearer.

What matters today is the actual wording of the current address
policy. But to understand some of that, we need to look at how we got
here and some of the early definitions that are no longer included in
the policy. So let's start with a history lesson. With my information
archeologist's hat on, I've gone all the way back to 1990 to
understand what the terminology in the address policy and the RIPE
Database means.

In the first version of the address policy ripe-065
RIPE NCC Internet Numbers Registration Procedures
Publication date: 01 Jul 1992

It says:
"This document describes the procedures for the reassignment of IP
network numbers from blocks obtained from the RIPE Network Coordination
Centre."
...
"Full information about reassigned network numbers must be reported
back to the RIPE NCC and the US NIC in full RIPE database format (ref
ripe-13)."

Then in ripe-13
RIPE Databases
Publication date: 28 Aug 1990

It describes the network objects to include these attributes:

-----------
tc -name of technical contact.
This must be the same string as in the corresponding *pn entry.
There must be such a person entry!

ac -name of administrative contact.
This must be the same string as in the corresponding *pn entry.
There must be such a person entry!

de -description of the network.
Give organisation and place.
Postal address and country are not needed, they can be found via the contacts.
The country is given in *cy.
-----------

Then in an example it includes:

-----------
*de: CWI Ethernet (Classical)
*de: Amsterdam
*de: Netherlands
-----------

So right from the start of registration we have had description
attributes giving information about the name and location of the
assignment holder.

Then we move a few hops to ripe-136
European Internet Registry Policies And Procedures
Publication date: 24 May 1996

This is starting to look a bit like modern address policy.
Interestingly it actually defines some of the terms we have lost touch
with over time. If you ask most people now what an admin-c contact is
they don't know. Which is why many objects have the same entry for
both tech-c and admin-c. But that is often wrong.

Some definitions:

End users are those organizations operating networks in which the
address space is used. End users must provide and update registration
data for the address space assigned to them.

Local IRs are typically operated by Internet Service Providers (ISPs).
Local IRs hold allocations of address space for assignment to end
users. In some cases, the local IR assigning the address space is not
run by the ISP that will provide connectivity. It is important to note
that maintenance of the administrative information regarding the
assigned address space is the responsibility of the IR that makes the
assignment, and not of the ISP providing the connectivity.

Requesters - In addition to these key players in the Internet Registry
System, there are often consultants who set up and manage networks for
end users.

netname - a short, but semantically meaningful name

descr - A short description of the organisation that will use the
assigned addresses, in one or more fields. Typically the name of the
organisation.

admin-c - administrative contact persons. The administrative person
specified in the admin-c field must be physically located at the site
of the network.

[Clearly the original definition of the admin contact means it must be
someone at the site of the end user. This, with the descr fields,
identifies and provides contact information for the end user.]

tech-c - technical contact persons. The technical person specified in
the tech-c field may be a network support person located on site, but
could also be a consultant that maintains the network for the
organisation.

Submission of objects to the database is the final and required step
in making an assignment. This step makes the assignment definite, and
makes public information regarding the assignment available to anyone
seeking it.

[Again it is clear from the early days that the public registry was
not only an operators phone book for solving network issues. Maybe
this will bring to an end those endless arguments about whether LEAs
have a right to access and use the information in the RIPE Database.
"available to anyone seeking it"]

>From ripe-140
European Internet Registry Policies and Procedures
Publication date: 06 Sep 1996

Just for further clarity it describes the admin-c of an aut-num object as:

"The administrative contact should be physically located at the
enterprise requesting the AS number."
which further clarifies the difference between the tech-c and admin-c generally.

ripe-159 (29 Jul 1997) adds that the admin-c
"The person does not have to have technical knowledge of the network."

Then we get to ripe-234
IPv4 Address Allocation and Assignment Policies In The RIPE NCC Service Region
Publication date: 14 Jun 2002

This is where we first get the differentiation between DSL connections
and public networks.
"However, four or more addresses (e.g. /30 or more) used on the End
User's network need to be registered separately with the contact
details of the End User."
Almost the exact wording we still use today, 21 years later.

Then ripe-288
IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region
Date: 28 October 2003

We now have the exact wording that we have today (it is even in paragraph 6.2):
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
So we have had this principle with the exact same wording for 20
years. Every version of the address policy since then has included
this exact line.
(Incidentally one of the authors of this document was Leo, now
co-chair of this WG)

All these documents have been co-written by many people including the
RIPE NCC founder, RIPE NCC CEO, RIPE chair, RIPE co-chair, AP-WG
co-chair, former DB-WG co-chair, yet we seem to have collectively
forgotten what many of these terms mean.

So now let's come back to the present. How do these definitions change
our perspective? The first thing to note is that these definitions are
no longer written into the policy. They disappeared over 20 years ago.
But, in the absence of any definitions in the current policy, and no
community consensus over that time to change any of these definitions,
it seems reasonable to apply those definitions from earlier versions
of the same policy document. Especially as the database documentation
still makes the clear distinction between a tech-c and an admin-c in
line with those early definitions.

Let's again look at that typical company operating a network with
public address space. They may be technically competent, in which case
the tech-c will provide contact details for their own engineers. If
they don't have the technical skills someone else will manage the
network for them. That could be the LIR, or an ISP (seperate from the
LIR) who provides the connectivity services, or an independent
consultant. Whoever it is, they should be listed as the tech-c contact
person. When it comes to the admin-c, we now know who this is meant to
be. It is someone, with or without technical skills, who is physically
located at the site of the enterprise operating the network. Having
that person's contact details, combined with the descr attributes that
optionally specify the name and location of the organisation, we
satisfy the current policy requirement "registered separately with the
contact details of the End User".

When an LIR manages the network for the End User, to replace both the
tech-c and admin-c with the LIR's contact details is wrong, according
to the current policy. The admin-c should always be a contact from the
End User's site. As many LIRs do get that bit wrong, they often
compensate by adding full name and address details of the End User in
the descr attributes. That makes them still compliant with current
policy as the assignment object still has the contact details of the
End User. There are so many objects in the database like this. If the
labour intensity of maintaining this data is one of the driving forces
behind this proposal, why do so many LIRs put all that optional data
into their objects? That takes a lot of effort. If an assignment is
cancelled then re-assigned to another customer, they have to change
the object to update this optional data. Without the optional data the
same object would still be valid for the next customer without any
update. They do it because they read the policy and understand that
line ("When an End User has a network using public address space this
must be registered separately with the contact details of the End
User.") and knew they must include contact details for the End User.

During this debate it has been said that the contacts are "the tech-c
and admin-c, nothing more, nothing less". That is just wrong. Nothing
in the current or any previous version of the address policy has ever
said that. You cannot just invent conditions like this, out of
nowhere. The descr attributes are contacts. A referenced organisation
object provides contacts. There are other options for contact
information. But the bottom line is, the assignment object MUST
contain the End User's contacts (subject to the specified exceptions).
So it is not policy compliant to have an assignment object that does
not have contact details of the End User. If the RIPE NCC does not
question this during an audit, they have got it wrong. They may have
got it wrong for many years, but it is still wrong. We should not
change the policy just because mistakes have not been corrected for a
long time.

So the answer to the main question is (finally), this proposal makes
significant changes to assignment policy and allows the creation of
anonymised assignment objects that the current policy does not allow.
I will go further than this. If the current policy was correctly
applied, it is not possible to aggregate assignments as they will all
have different admin-c contacts.

That means the question the community needs to consider is if it is
now acceptable to allow anonymised assignment objects in the RIPE
Database, possibly in significant numbers? If this proposal is
accepted and the definition of admin-c is changed to what many people
actually think it is, then the only End Users who will be publicly
contactable are those who manage their own networks. Potentially ALL
others can be anonymised, with or without aggregation.

Now just to finish off I will address the Q&A.

On Tue, 26 Sept 2023 at 15:41, Tore Anderson <tore at fud.no> wrote:
>
> Hi Denis,
>
> It would appear to me that your opposition to 2023-04 is largely based
> on the premise that it introduces a new possibility for anonymous
> assignments, a change which you do not want to see happen. This premise
> also appears to underpin many of your musings in your «The bigger
> picture» message.

Then you didn't read it.

> I disagree with this premise, as I believe this
> possibility is already there in current policy.

"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."

>
> Rather than decide to agree to disagree on that point, or endlessly
> quarrel about it, I realised that it does not really matter what you or
> I believe the policy requirements are - what matters is the RIPE
> NCC's understanding of the policy and how they are implementing it. So
> I simply asked their Policy Officer (Angela) to clarify this.

What matters is are they implementing it correctly?

>
> Her answers, which I with permission quote in full along with my
> questions below, unequivocally confirms that that current policy does
> indeed allow assignments to be registered anonymously in the RIPE
> database. Hence, your opposition to proposal 2023-04 in this regard
> appears to rest on a fundamentally flawed assumption.

"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."

>
>
>    Tore: «The context here is an IPv4 assignment that is not made to an
>    individual and that is not used solely for the connection of an End
>    User to a service provider.
>
>    1. Does current address policy as implemented by the NCC allow an End
>    User to delegate/outsource the contact information represented by the
>    mandatory "tech-c" and "admin-c" attributes to another entity,
>    typically (but not necessarily) the issuing LIR? (There does not appear
>    to be any disagreement on this point, but I include this question
>    anyway in case we are both wrong.)»
>
>    Angela: «Yes, you are correct. An End User is allowed to
>    delegate/outsource the contact information represented by the mandatory
>    "tech-c" and "admin-c" attributes to another entity, typically (but not
>    necessarily) the issuing LIR.»

No it is not correct. The administrative person specified in the
admin-c field must be physically located at the site of the network.
Therefore it cannot be outsourced.

>
>    Tore: «2. Assuming "yes" to question 1, for an assignment where the
>    "tech-c" and "admin-c" has been delegated in this manner: Does current
>    address policy require the corresponding "inetnum" database object to
>    contain some additional contact information, that is not delegated to a
>    third party, i.e., it must be refer to a point of contact that is
>    handled in-house by the End User him/herself?»
>
>    Angela: «The current address policy does not require the corresponding
>    "inetnum" database object to contain some additional contact
>    information that is not delegated to a third party.
>    LIRs can use the “netname” attribute to link assignments to end users
>    and their contact details in internal records.

"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."

>
>    There is a particular case: when the RIPE NCC receives a request for
>    assigning an AS number to an End User using a PA assignment, the IPv4
>    network to be announced by the requested AS must be registered in an
>    “inetnum” object showing the End User’s name. This can be in the
>    "descr” attribute or recursively in the "org" object added as
>    attribute.»

This does not apply to most of the assignments in the database where
the optional descr attributes have been added with name and address of
the End User

>
>    Tore: «3. Assuming "yes" to question 2, what kind of other contact
>    information is required, and in which "inetnum" database attribute(s)
>    must it be located? Here are some possible examples off the top of my
>    head, would any or all of these satisfy the policy requirement for an
>    in-house non-delegated contact information?
>      1. A street address
>      2. A (snail) mail address
>      3. An e-mail address
>      4. A fax number
>      5. A phone number»
>
>    Angela: «The answer to question 2 was “no’, however one way to record
>    End Users’ contact details is to create an “org” object to be added as
>    optional attribute in the “inetnum” object.
>    In “org” objects name, address and email are mandatory.
>    In “inetnum” objects the mandatory contact information are “admin-c”
>    and “tech-c”.»

"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."

>
>    Tore: «4. Assuming "yes" to question 2, is it mandatory to identify the
>    End User by name, or would it be sufficient with, e.g., a street
>    address without an organisation name (assuming there is only a single
>    entity located at that address), a post box snail mail address, a
>    generic user123 at gmail.com e-mail address, or a phone/fax number that is
>    not listed in the white or yellow pages?»
>
>    Angela: «The answer to question 2 was “no’,...»

"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."

>
>    Tore (in a new e-mail): «I will ask you a couple of follow-up questions
>    just to make absolutely, 150%, certain I do not misunderstand you and
>    end up misrepresenting you to the mailing list:
>
>    1. When you write «LIRs can use the “netname” attribute to link
>    assignments to end users and their contact details in internal
>    records», this "can" is a MAY, not a MUST, to use IETF lingo? That
>    is, the LIR is free to instead use the "inetnum" attribute, i.e.,
>    the IP address(es), to link the assignment to the End User in their
>    internal record? If that is the case, would it be correct to say
>    that the LIR are free to set the "netname" attribute to essentially
>    anything, including a meaningless string of random characters?»
>
>    Angela: «Your interpretation is correct, the answer is yes to all
>    three questions.
>    Please also consider that the "netname" is not required to be
>    unique, LIRs can use the same one for multiple assignments.»
>
>    Tore: «2. When you write «one way to record End Users’ contact
>    details is to create an “org” object to be added as optional
>    attribute in the “inetnum” object», this is also a MAY, not a MUST?
>    That is, the LIR is free to omit the "org" attribute, even though
>    the only other contact information contained in the object is the
>    (LIR-delegated) "tech-c" and "admin-c" attributes?»
>
>    Angela: «Yes, the LIR is free to omit the "org" attribute, even
>    though the only other contact information contained in the object is
>    the (LIR-delegated) "tech-c" and "admin-c" attributes.
>    If the LIR requests an AS number on behalf of an end user to
>    announce a PA assignment, then the PA assignment MUST include the
>    legal name of the end user in the "descr" attribute or in the '"org"
>    object set as "org" attribute in the "inetnum" object.»
>

"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
The administrative person specified in the admin-c field must be
physically located at the site of the network.

>    Tore: «3. To use a concrete example: Let's say «SuperLIR GmbH»
>    delegated 192.0.2.0/25 to the End User «CarFactory GmbH».
>    (CarFactory GmbH is not an individual, and the assignment is not
>    used solely for the connection to the provider, nor to justify an
>    application for an AS number). SuperLIR inserts the following
>    minimal database object:
>
>    inetnum:  192.0.2.0 - 192.0.2.128
>    netname:  ABCDEFGHIJKLMNOPQRSTUVWXYZ
>    country:  DE
>    admin-c:  SUPERLIR-NOC-RIPE
>    tech-c:   SUPERLIR-NOC-RIPE
>    status:   ASSIGNED PA
>    mnt-by:   SUPERLIR-MNT
>    source:   RIPE
>
>    In the event of an audit, SuperLIR GmbH will be able to inform the
>    RIPE NCC auditors that this object has been delegated to CarFactory
>    GmbH.
>
>    Is the above registration compliant with current IPv4 address
>    policy, or will the auditors demand any kind of changes be made?»
>
>    Angela: «The above registration compliant with current IPv4 address
>    policy. During an audit we could ask the LIR whether the assignment
>    is still in use. It does not matter for the RIPE NCC who is using
>    the assignment, as long as the LIR is maintaining the registration
>    up to date and is able to contact the end user. This means that if
>    the LIR moves the assignment delegation from CarFactory GmbH to
>    another end user in the same country for which is acting as "admin-
>    c" and "tech-c", the "inetnum" object would still be valid. It is
>    the LIR's responsibility to keep their internal records up to date
>    accordingly with the new end user.»

"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
The above object is not compliant and the audit should pick that up

>
>
> In light of the above, I hope that you will reconsider your opposing
> arguments and either withdraw them or restate them in a way that does
> not rely on this incorrect assumption. Anticipating this, I will only
> address your remaining points that are not based on the
> misunderstanding that 2023-04 opens up for anonymous assignments.
>

My assumption is correct.

cheers
denis
co-chair DB-WG