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

Hi all,

Outside of the detail from Denis and Tore, the discussion on this one seems
quite limited, yet there is more than a hint that the proposed change
conflicts with some core fundamental goals of the registry and the
overarching purpose of the policy as is today. This is clearly an area of
contention.

I'm more than comfortable in saying that the policy interpretation by the
RIPE NCC as detailed in the dialog between Tore and Angela is VERY
surprising to me. It appears to go against conventional or widely accepted
interpretation of the current policy (and those before it) and as an example
the direction / sentiment set out within their own Database Training
materials or videos:-

https://www.youtube.com/watch?v=0RI5W3hqBug&list=PLC964CD89C4AE0337
https://www.youtube.com/watch?v=w6oUf7j4SME&list=PLC964CD89C4AE0337&index=7

As I've mentioned before, the policy as-is does appear open to
interpretation in terms of what CONTENT goes into an End User Assignment
INETNUM registration. I'm not saying that's wrong but I think it's important
to distinguish between that and those who choose not to register anything;
the latter being non-compliance or at least not able to adequately
demonstrate that their assignments are regularly maintained.

So whilst the policy isn't prescriptive in how you achieve the "must", it
does seems like many have found a common approach with using a blend of the
mandatory and optional attributes to satisfy the requirements of End user
registration, in particular for each non-individual & non-P2P assignments.
However contrary to this, it seems like there is a developing/developed view
that if the attribute isn't mandatory, it doesn't count in the wider
context. Whereas in reality the accepted convention is more a case of "if
this mandatory attribute is populated this way", "use this optional
attribute this way". It's not strict compliance but fulfils the objective.

Yet, if we aren't actually required to publish end user names (based on the
Q&A transcript provided by Tore), why are so many doing so? Rightly or
wrongly, it would suggest to me there is some form of compliance or
enforcement drift and therefore quite a gulf between the INTENT of the
policy and what the enforced minimum requirements actually are. Or perhaps
that same many have got it wrong, overreaching on what needs to be
published, yet they don't think they have which emphasises the problem (if
this discussion alone doesn't already prove that!).

For me it comes down to this. As a community & considering the permitted
exceptions (individuals & P2P assignments):-

1) Is the publication of End User entities for an assignment important?
2) Is the publication of a prefix assignment boundary between end users
important?

If the answer to either of those is yes, then I don't think this proposal
should go forward in its current form & the current RIPE NCC interpretation
of the current policy as shared by Tore should be challenged. 

If the answer to both is no, then it has legs but only for those reasons.
Justifying it because some LIRs don't do what they are supposed to do isn't
sufficient. That's what the Assisted Audit is for right? I recognise that
the time between assignment & reassignment for some service providers is now
substantially shorter, but arguably the likes of Virtual Service providers
are better equiped than most to deal with that. Spinning things up and
tearing them down is afterall their day to day. 

In either case, does consideration toward best practice & holding to higher
standards have any weight?
https://datatracker.ietf.org/doc/html/rfc3013#section-4.1

There is a side piece to this too & an area I commented on a couple of weeks
ago regarding End User interests on the publication or not of their Business
Name. Armed with the information now that publication of the End user names
isn't mandatory (although previously believed to be a requirement -
arguments challenging this aside) does explicit consent now need to be
obtained to continue with that practice, if the LIR choses to continue with
that approach? If the publication of an End User isn't backed up by a policy
which we are bound to comply with contract / Terms & Conditions then
continuing creates an exposure for new and existing entries? Given what is
being discussed, the proposal or even the existing policy should be modified
to be clear as to whether there is a condition here or not and in what
form(s) this must take. I say this because the discussion being had here and
the efforts made on those INETNUM entries which are there now (ours
included) would indicate it isn't as clear as we thought it was. 

This discussion has made me feel uncertain about the existing policy but
also juding the proposal because of it. The answers to those 2 questions is
key.

Either way, I want to make sure I'm falling on the right side of the policy
& be able to justify how much or little effort we put in to the registry
entries. Referencing some of the detail in this discussion as a means to
determine that doesn't feel adequate.

Many thanks,
Brian 



-----Original Message-----
From: address-policy-wg <address-policy-wg-bounces at ripe.net> On Behalf Of
denis walker
Sent: Thursday, September 28, 2023 11:31 AM
To: Tore Anderson <tore at fud.no>
Cc: address-policy-wg at ripe.net
Subject: Re: [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

-- 

To unsubscribe from this mailing list, get a password reminder, or change
your subscription options, please visit:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe
.net%2Fmailman%2Flistinfo%2Faddress-policy-wg&data=05%7C01%7Cbrian.storey%40
gamma.co.uk%7C2da065f0adae46dcb9c308dbc00e1fc3%7C743a5d9f11234f3f8fcf5766b8a
d8bf9%7C0%7C0%7C638314939120399679%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fXEe
nEm7tmtgXCFJsgLGbcHyJMjOjghY%2F29nKvjUf5s%3D&reserved=0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20230929/a6e812a1/attachment.p7s>