This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] Decision on NWI-4 INETNUM status values
- Previous message (by thread): [db-wg] Decision on NWI-4 INETNUM status values
- Next message (by thread): [db-wg] Decision on NWI-4 INETNUM status values
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Leo Vegoda
leo at vegoda.org
Mon Apr 4 20:42:40 CEST 2022
HI Denis, On Mon, Apr 4, 2022 at 10:45 AM denis walker <ripedenis at gmail.com> wrote: > On Mon, 4 Apr 2022 at 19:08, Leo Vegoda <leo at vegoda.org> wrote: [...] > > > If there are no objections to this, the co-chairs now ask the RIPE NCC > > > to produce an impact/implementation report to add this new status > > > value and include the business rules to restrict it's use. We will > > > then seek a final approval from the community on the report. > > > > I don't object to addressing this. But I think there are some implicit > > assumptions in the text from 2016. > > > > I'd like to understand if there is a technical need for exact match > > assignments that duplicate all the contact and other information from > > the /24 allocation. Or is the issue that there is some policy or > > administrative need? > > This suggestion avoids the need to duplicate any contact or other > details. No additional objects need to be created. The status is > changed from 'ALLOCATED PA' to 'ALLOCATED-ASSIGNED PA' in the > allocation object. "descr:' and "country:" are multiple attributes so > the end user can be identified here. If the end user has their own > abuse contact that can be represented with an "abuse-c:" in the > allocation object. The resource holder's abuse contact is still > referenced through their referenced ORGANISATION object. So it allows > a whole allocation to be documented in the database as an assignment > without having to duplicate any data or create multiple objects. I think we might be misunderstanding each other. I am trying to understand the reason two layers of registration are needed if everything being registered is identical. In the olden days, some ISPs offered static IP dial-up accounts and we'd just add a description to that effect in the inetnum for the allocation. No need to create any extra registrations. I'd like to understand if there is any technical or business need for an exact match registration that couldn't be accommodated with a simple change to business rules. Thanks, Leo
- Previous message (by thread): [db-wg] Decision on NWI-4 INETNUM status values
- Next message (by thread): [db-wg] Decision on NWI-4 INETNUM status values
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]