[ncc-services-wg] Independent Resource procedure and implementation

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Daniel,

Thank you for your mail.

To address your first and second points, the RIPE Database is a public
database. The aut-num objects that you mention are maintained by the
Local Internet Registry (LIR) or the End User and have been assigned by
the RIPE NCC over a number of years. This means that the information
contained in the RIPE Database might be outdated or inaccurate.

However, as a consequence of this project, many LIR organisation name
changes have been initiated by RIPE NCC members and contact details have
been updated by many LIRs, including recently set-up ones. This
contributes to the improved quality of RIPE Database data. RIS data
would have to be compared with the RIPE Database information,
bringing us back to the points listed above.

The RIPE NCC is also working on a project to enhance the quality of its
registration data in order to help resolve similar cases in the future.
Creating a separate process for 'small' and 'larger' LIRs would not be
cost effective. Furthermore, the RIPE NCC is impartial and
neutral to all its members.

In the case you mention, where an LIR uses one AS Number for its
infrastructure, the LIR is requested to select "My Infrastructure" on
the interface provided. No further action is requested from them. I am
sorry to hear that you see this as an abuse.

To address your concerns related to the software, the current
implementation of "single sign on" enables you to log in once using:

- - Certificate AND password for certification *or*
- - Just password (or both) for policy 2007-01

It does not currently allow login using only a certificate.

We believe that this is a good thing. The ability to sign in using just
'certificate' degrades the security of the portal; users could generate
such certificates without pass-phrases and then anyone with access to
their computer could log in.

Being an 'external user' and representing many LIRs results in having
to log in as 'primary' user for each of them. This was recognised during
the development of this project as a point for improvement. In the new
version of the LIR Portal, which we are currently working on, this will
be handled in a more user friendly way.

Unfortunately, we could not integrate completely with the LIR Portal in
the timeframe given to implement policy 2007-01. We decided not to make
further developments to the legacy code base of the current LIR Portal
because we already had plans to entirely rebuild the LIR Portal.

We are currently working on the LIR Portal migration project. One of the
first milestones will be to make the integration between old and new
seamless for users.

With regards to the RIPE NCC audit you mention, I can ensure you that
this is just a coincidence.

I apologise for any inconvenience caused by the LIR Portal integration
and appreciate the feedback on our services. If you have any further
questions or feedback please don't hesitate to contact me.

Kind regards,

Andrea Cima
RIPE NCC



Daniel Suchy wrote:
> Hello,
> 
> I would like to open discussion related to "Action Required: Contractual
> Relationship for Independent Resource Assignments" emails, that almost
> all LIRs received from RIPE NCC in the past. I have some notes from
> perspective of small LIR (or from perspective of person helping running
>  multiple small LIRs).
> 
> My first note points to system in general. Although RIPE NCC has many
> required informations in own existing databases already, it requires
> additional action from LIR in general. Typical small LIR has one or more
> PA allocations and exactly _one_ autonomous system registered. In RIPE
> database, there are records matching allocated PA prefix and ASN (route
> objects with proper origin AS and related inetnum objects, many ASNs has
> paired LIRs org: in aut-num object). In addition, RIS service (with
> history!) can be used for verification of these informations obtained
> automatically from database.
> For incomprehensible reason, RIPE NCC doesn't use these informations at
> all and instead of this abuses ALL LIRs with submiting simple form with
> exactly one record within it. I thing RIPE RCC has enough resources
> (financial and human) to do that automatically.
> 
> My second note points to implementation of this new tool. I discovered,
> that I'm not able to "new" tool used for confirmation. I'm using PKI
> login feature and I have one identity paired with more LIRs. Although
> I'm able login to the LIR portal and modify everything I need with my
> certificate, I'm _NOT_ able to update informations on "Independent
> Resources" page.
> The main reason is, that RIPE NCC created new and separated (!) tool
> instead of simple integration of new feature/functionality to existing
> LIR portal. So, instead of reusing existing code used for LIR portal
> authentication, new outside code was developed for this new tool. And
> this new code doesn't implement all authentication features from LIR
> portal. In my point of view, this is quite unprofessional approach of
> modern application development. Aplications should be multi-layer,
> allowing easy new feature implementation.
> 
> I reported this issue to RIPE NCC on friday last week, but first
> "answer" I received yesterday from RIPE NCC was initiation of audit in
> one LIR. Just fortuitous event? I don't believe. I have no problems with
> audit itself, I have all records, but this takes some additional time
> (and of course, money). Just because I claimed some problems to RIPE NCC
> staff due to problematic internal _implementation_ of new policy.
> 
> Ok, I would like to open public discussions about this problem. There
> are some questions to answer and discuss:
> * why RIPE NCC just doesn't use informations from RIPE database in case
> of their availability and verifiability, why abuses small LIRs instead
> * why aren't RIS data used for automatic obtaining of requested
> informations, where this can be applicable
> * why RIPE NCC didn't integrate "confirmation" tool to existing LIR
> portal and  why new outside application with _limited_ functionality was
> developed instead of reusing of existing code and functionality
> * what architecture is used for LIR portal in general, can be there
> easily implemented new features
> 
> Of course, I understand, that there are large LIRs and some historic
> mess, where this action may be required due to lack of records in
> existing databases. But, I think this is NOT a case of LIRs started in
> past couple of years, where all required data should be available.
> 
> With regards,
> Daniel
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqf5bwACgkQXOgsmPkFrjPxfwCeNJWIiYb07uIXA1yW6sFnRNmJ
qZwAn1JnBd+sjuGEX5zKe2cI2kkz3D93
=pDo0
-----END PGP SIGNATURE-----