- db-wg - mailman.ripe.net

RE: [apnic-talk] Status field for inet6num objects
by Michael.Dillon＠radianz.com 13 Jun '02

13 Jun '02

>For me these two phrases, DELEGATED-TO-LIR and >ASSIGNED-TO-END-USER, hit the spot precisely! >excellent suggestion Guy! >Is it appropriate to request consideration of these terms as replacements >for ASSIGNED and ALLOCATED? Wouldn't it be a good idea to standardize the terminology with ARIN and others? In that case, the term LIR would be considered obscure and meaningless. Since all LIRs are service providers of some sort, either ISPs or an internal network service provider, I think that a standard terminology should try to use generic terms. That would mean either DELEGATED-TO-SVC-PROVIDER or DELEGATED-TO-NSP if you like acronyms (Network Service Provider). In any case, because the distinction between "allocated" and "assigned" has been unclear in the past and because there is a significant shift in terminology from "allocated" to "delegated" this change should be incorporated in an informational RFC. This document would help in clarifying that there is indeed a difference between the two states of an address block and would also help in promoting the use of this terminology amongst the community that deal with IP address delegations and assignments. DELEGATED-TO-NSP and ASSIGNED-TO-USER are two terms that would be clear worldwide. Michael Dillon Network Product Engineering Radianz

2 1

Re: [apnic-talk] Status field for inet6num objects
by Geoff Huston 13 Jun '02

13 Jun '02

>To clarify, the values that APNIC would prefer to use are: > >ALLOCATED PORTABLE >ALLOCATED NON-PORTABLE >ASSIGNED PORTABLE >ASSIGNED NON-PORTABLE > >As I mentioned before, these values would be consistent with those in >IPv4 (which take effect in August when the migration to version 3 of the >RIPE database is complete). > >Comments? I would be in favour of this clarity in the field regarding PORTABLE and NON_PORTABLE. However, the distinction between "ALLOCATED" and "ASSIGNED" is perhaps a bit subtle. regards, Geoff

6 5

Re: [hostmaster-staff] Re: [apnic-talk] Status field for inet6num objects
by Michael.Dillon＠radianz.com 13 Jun '02

13 Jun '02

>Allocation and assign do have definitions - could these be improved >to clarify the meaning? Or does 'delegate' simply convey a much >clearer intention with the address space? Delegation is clearer for two reasons. Firstly, it implies that the the delegator is passing on some responsibility for the address space. The organization receiving a delegation is responsible for managing and administering the addresses. In the case of an assignment, this is less true. For instance, ISPs regularly reassign addresses after a customer disconnects and everyone seems to understand that addresses assignments are controlled by the assigner and can be withdrawn. The second reason has more to do with psychology. Because the terms "allocation" and "assignment" are similar in meaning and visually similar, they are easily confused by a lot of people. They both begin with "a" followed by a double consonant and end with a latin suffix. Of course, clear definitions are always a good thing as well. Michael Dillon Network Product Engineering Radianz

1 0

RE: [apnic-talk] Status field for inet6num objects
by kevin.bates＠bt.com 12 Jun '02

12 Jun '02

seems better but not perfect - the important thing is to get all databases looking the same and using the same terms? strictly speaking it is not "ASSIGNED-TO-END-USER" its "ASSIGNED-TO-SUBNET-USER" for example it could be part of a DHCP dial up pool and thus only " leased" for the duration of that connexion. > At 11:56 AM 6/12/2002, Guy Davies wrote: > >I tend to agree with Nigel, although I'd go for something even > >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know > >they're a bit verbose but they're absolutely clear ;-) It also makes > >clear that addresses assigned to an LIR in the role of END-USER are > >exactly that. That way, an individual who is struggling with English > >as a second language (or even their first language ;-) can be > >absolutely clear of the status of a range of addresses. > > This is an excellent idea. However I would use > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > That way we clarify the subtle difference while > maintaining consistency with existing documentation. > > (If I remember correctly the term DELEGATED was suggested at the time, > but not used because of its usage in the DNS context as well as > the connotation of total transfer of authority over the resource which > is not quite the case.) > > Daniel

2 1

RE: [apnic-talk] Status field for inet6num objects
by Geoff Huston 12 Jun '02

12 Jun '02

> > This is an excellent idea. However I would use > > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > > That way we clarify the subtle difference while > > maintaining consistency with existing documentation. > > > > (If I remember correctly the term DELEGATED was suggested at the time, > > but not used because of its usage in the DNS context as well as > > the connotation of total transfer of authority over the resource which > > is not quite the case.) To me "DELEGATED-TO-LIR" makes sense, as it infers that the process of further delegation can be used with sub-blocks and/or atomic units can be "ASSIGNED-TO-END-USERs with the inference that no further sub assignments are anticipated. Geoff

1 0

RE: [apnic-talk] Status field for inet6num objects
by Michel Py 12 Jun '02

12 Jun '02

> Anne Lord wrote: > There is no PI in IPv6. > This can't be said often enough. We are working on two new types of v6 addresses that are neither PA nor PI for multihoming. Please keep in mind that PA does not provide enough functionality; if no multihoming protocol is released in a timely manner you will inevitably have PI, or whatever you want to call everyone becoming a LIR. Michel.

1 0

MD5-PW auth scheme is available in the RIPE Database
by Andrei Robachevsky 17 May '02

17 May '02

Dear Colleagues, [apologies for duplicate messages] Following the request from the RIPE Community a new auth scheme based on MD5-crypt algorithm was implemented and put into production today, 16 May 2002. Implementation details can be found in the proposal circulated in the db-wg mailing list http://www.ripe.net/ripe/mail-archives/db-wg/20020401-20020701/msg00011.html. We also created another FAQ entry "How to use MD5-PW auth scheme in my mntner?" (http://www.ripe.net/ripencc/faq/database/qa5.html#13). The RIPE Database Reference Manual will be updated soon. You may use Crypt CGI interface (http://www.ripe.net/cgi-bin/cgicrypt.pl.cgi) to convert your passphrase to MD5-PW string. Regards, Andrei Robachevsky DB Group RIPE NCC

3 3

Phasing out MAIL-FROM auth scheme
by Andrei Robachevsky 16 May '02

16 May '02

Dear Colleagues, [apologies for duplicate messages] The MAIL-FROM authentication scheme is very weak. Forging RFC2822 headers can be done very easily. With the existence of more secure "auth" schemes in the RIPE Database, it does not make much sense to support it any more. The proposal to phase out the MAIL-FROM authentication scheme was presented to the to the Database Working group. You may find the original proposal at http://www.ripe.net/ripe/mail-archives/db-wg/20020101-20020401/msg00066.html The timeline for this transition presented below was discussed and approved at the RIPE 42 meeting. Please see the minutes of the DB-WG session http://www.ripe.net/ripe/wg/db/minutes/ripe-42.html. To make this transition more smooth we prepared a page with step by step instructions how to update the mntner objects to remove the MAIL-FROM auth scheme. It can be found at http://www.ripe.net/db/MD5-HOWTO.html Regards, Andrei Robachevsky DB Group Manager RIPE NCC Transition phases ================== Use of MAIL-FROM is phased out in four steps, on the following dates: Phase 1: 16 May 2002 - 12 June 2002 Notifying mntners with MAIL-FROM auth scheme -------------------------------------------- An announcement presenting this transition and encouraging the owners of the mntners to remove MAIL-FROM auth scheme from their objects will be sent on 16 May, 2002. The announcement will point to instructions how to update the mntner objects to remove the MAIL-FROM auth scheme. The distribution list will be compiled from e-mail addresses listed in "upd-to:", "mnt-nfy:" attributes of the mntners, as well as using contact information (e-mail) from "admin-c:" and "tech-c:" references. Phase 2: 13 June 2002 - 10 July 2002 Rejecting updates for mntner objects containing MAIL-FROM auth scheme --------------------------------------------------------------------- When updating maintainers the new version must not contain MAIL-FROM "auth:" attributes, otherwise this will be reported as a syntax error. This means that you cannot create any new MAIL-FROM "auth:" attributes, either in new or existing maintainers. Phase 3: 11 July 2002 - 7 August 2002 Rejecting using the MAIL-FROM auth scheme for authorisation ----------------------------------------------------------- When processing an update for an object protected by a mntner that contains MAIL-FROM auth scheme, this scheme will be ignored. That means that if mntner defines other auth schemes different from MAIL-FROM, the credentials relevant to these schemes may be used. If the only auth scheme defined is MAIL-FROM, no update can be authorised by such mntner. Phase 4: 8 August 2002 Cleanup ------- The mntners still containing "auth:" attribute with the MAIL-FROM auth scheme will be modified so that such attributes will be removed from the objects. Before this a final call will be sent to the owners of these mntners ("upd-to:", "mnt-nfy:" attributes of the mntners, as well as to the contacts from "admin-c:" and "tech-c:" references). A "remarks:" attribute will be added with clear explanation of the situation. In case a mntner contains only one "auth" scheme, which is MAIL-FROM, it will be locked and cannot be used by the owner.

2 1

Anti-spam policy for ripe-dbm@ripe.net mailbox
by Andrei Robachevsky 13 May '02

13 May '02

Dear Colleagues, Starting from Monday, 20 May 2002, an anti-spam filtering policy for ripe-dbm(a)ripe.net mailbox will be implemented. Messages not explicitly directed to ripe-dbm(a)ripe.net, that is not containing this e-mail address in "To:" or "Cc:" fields of the mail header will be filtered out and not processed. Spam messages constitute up to a half of the ripe-dbm mailbox, and it takes some of our resources to identify and delete them. If you have any questions or concerns please contact RIPE Database Administration at ripe-dbm(a)ripe.net. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 1

Requests to the RIPE DB Administration are now ticketised
by Andrei Robachevsky 03 May '02

03 May '02

Dear colleagues, [apologies for multiple messages] As was announced at the RIPE 42 meeting starting from the next week, 6 May 2002, questions and requests directed to the RIPE Database Administration (ripe-dbm(a)ripe.net) will be processed using a ticketing system. This will allow us to track your requests more efficiently and further improve the quality of support we provide to you. No automatic acknowledgements will be sent to you. In replies from the ripe-dbm the subject line will be modified by prepending a ticket number: Re: NCC#2002044160 <original subject> Please preserve this ticket number in your further correspondence with the ripe-dbm. No other changes should be visible to you. This will not affect submissions sent to the RIPE Database at auto-dbm(a)ripe.net. If you have any more questions regarding this issue please don't hesitate to contact ripe-dbm(a)ripe.net. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0